让Claude写代码之前，先让它把想法写在纸上

红尘渡

【让Claude写代码之前，先让它把想法写在纸上】


快速阅读： 作者用了9个月摸索出一套Claude Code工作流，核心只有一条：在Claude动手写代码之前，必须先有一份经过反复标注修改的书面计划。这套流程把“思考”和“执行”彻底分开，大幅减少了AI把代码写跑偏的概率。

---

大多数人用AI写代码的姿势是这样的：输入需求，让它生成，报错了修一修，再生成，循环往复。复杂点的任务直接崩。

作者Boris Tane给出了一个反直觉的答案：AI最大的失败不是写出语法错误的代码，而是写出一个在局部跑通、却把整个系统搞坏的代码。一个忽略了现有缓存层的函数，一个没考虑ORM规范的数据迁移，一个跟别处重复的API接口。这类错误安静、隐蔽，最难排查。

他的解法分三步走。

第一步，让Claude先去读懂代码，把读到的东西写下来。 不是口头告诉你，是写进一个research.md文件。他的指令里密集出现“深入”、“细节”、“复杂性”这类词，不是废话，而是在告诉Claude：别走马观花。这份文档的真正用途是给他自己看的，验证Claude是否真的理解了系统，误解在这一步消灭，不等到代码里。

第二步，写计划，然后反复标注修改。 Claude生成plan.md之后，他在编辑器里直接往文档里加注释。两个字的也有：“不可选”。一段话的也有，比如解释某个业务约束，或者纠正一个架构方向。然后把文档扔回给Claude：“我加了一些注释，按注释更新文档，先不要写代码。”

“先不要写代码”这句话他每次都加。因为Claude一旦觉得计划差不多了就会冲动地开始实现，而这个时机通常不对。

这个循环可能重复一到六次。有观点认为，这种方式其实是在把人类的判断力注入进去：Claude知道代码怎么写，但不知道你的产品优先级，不知道你愿意接受哪些技术债。标注循环就是把这些隐性知识转化成明确指令的过程。

计划写好之后，再加一个待办清单，让Claude逐项打勾，方便追踪进度。

第三步，一口气让它实现完。 他的实现指令几乎每次都一样：“全部实现，完成一项就在计划文档里标记，不到所有任务完成不要停，持续运行类型检查。”到这一步，创造性的工作已经结束了，剩下的是执行。他想要执行变得无聊。

实现过程中他的纠错方式变得极度简短：“你没有实现deduplicateByTitle函数。”“这个设置页应该在admin应用里，不是主应用，移过去。”Context还在，一句话够了。前端调整更极端，有时候只发一个词：“更宽一点。”“还是裁到了。”

出了大问题就直接回滚，然后缩小范围重来。他的经验是，缩小范围之后重做，几乎总比在烂摊子上修补强。

有网友提到，很多人抱怨Claude在上下文窗口用到一半之后就开始退化，但他没遇到这个问题，因为plan.md作为持久化文档存在，即使上下文被压缩，文档还在，随时可以重新指向它。

整套流程没有魔法Prompt，没有复杂的工具链。本质就是一件事：在动手之前，把思路逼到纸面上，反复修到满意为止。

他没说的是：这套流程需要你自己先把需求想清楚，Claude帮不了你。

---

简评：

这套工作流最狠的地方在于那句“先不要写代码”。它戳破了一个幻觉：我们以为AI的价值是“生成”，其实是“对齐”。代码写错了能报错，方向错了没人拦你。一个绕过缓存层的函数，跑得比谁都顺畅，却在三个月后让整个系统雪崩。作者真正在做的事情，是把AI从“执行者”训练成“被审稿的作者”——research.md是初稿，plan.md是修订稿，人类批注是红笔。写作的秘密从来不是下笔如神，而是改稿改到吐。AI写代码，同理。

---

boristane.com/blog/how-i-use-claude-code/