记录，让思考有迹可循

先描述问题#

把问题写成可观察的现象。例如：“在项目目录执行构建命令后，终端提示某个模块无法解析。”

同时记录预期行为、实际行为和最小复现步骤。避免只写“项目坏了”，因为那无法帮助之后的排查。

保留必要的环境#

记录会影响结果的版本和配置：

1
node --version
2
pnpm --version

如果某个行为依赖环境变量，只记录变量名和用途，不要把真实凭据写进公开笔记。

一次验证一个假设#

先给出假设，再记录用于验证它的操作。每次只改变一个条件，才能判断结果来自哪一个改动。

为结论写下边界#

“这样可以解决”还不够。补上一句适用版本、限制条件或仍未验证的场景，才能避免把偶然成功当成通用方案。

好的笔记不需要很长。只要能让另一个人，或者几个月后的自己，理解问题并重复关键步骤，就已经足够有价值。