Claude 代码工作流：先计划，再执行
AI写代码前先书面规划，分离思考与执行，避免方向性错误，提升代码质量。
在人工智能辅助编程日益普及的今天，许多开发者都曾有过这样的体验：向 Claude 等 AI 助手提出一个复杂的编码需求，它迅速生成了一大段代码，但运行后却错误频出。于是，我们开始陷入“生成 - 报错 - 修复 - 再生成”的循环，对于稍复杂的任务，这种模式往往导致项目陷入僵局。开发者 Boris Tane 在经历了九个月的实践与摸索后，总结出了一套截然不同的工作流。这套流程的核心原则非常简单，却极具颠覆性：在 Claude 动手编写任何一行代码之前，必须首先产出一份经过反复推敲和标注的书面计划。其本质在于，将“思考”与“执行”这两个阶段彻底分离，从而大幅降低 AI 因误解意图而将代码引入歧途的概率。
问题的核心：隐蔽的系统性错误
大多数人使用 AI 编程时，往往只关注语法错误或运行时异常。然而，Boris 指出，AI 最大的失败并非产出无法运行的代码，而是产出那些在局部测试中看似正常、却对整个系统架构造成破坏的代码。例如，一个忽略了现有缓存机制的函数，虽然能完成计算，却可能在未来引发严重的性能瓶颈；一次未遵循 ORM 规范的数据迁移，可能埋下数据不一致的隐患；一个与系统中其他接口功能重复的 API，则会造成维护的混乱。这类错误安静、隐蔽，不会立即引发报错，因此也最难在后期排查和修复。它们不是“漏洞”，而是“设计缺陷”，其修复成本远高于普通的语法错误。
三步工作流：从理解到执行的精密控制
为了从根本上避免上述问题，Boris 的工作流被精心设计为三个明确的阶段。
第一阶段是深度研究。在着手任何新功能或修改之前，他会首先指令 Claude 去深入阅读相关的现有代码库。关键点在于，他要求 Claude 必须将理解的内容详细写入一个名为 research.md 的文档中，而非仅仅口头概括。他的指令中会密集使用“深入”、“细节”、“复杂性”等词汇，这并非无意义的修饰，而是明确告诉 AI 不要进行走马观花式的浏览。这份研究文档的真正读者是开发者本人，其核心目的是验证 Claude 是否准确理解了系统的上下文、依赖关系和潜在约束。任何误解都应当在这一步被识别和消除，而不是遗留到后续的代码实现阶段。
第二阶段是制定并迭代计划。基于研究结果，Claude 会生成一份初步的实施方案，即 plan.md。此时，Boris 并不会直接批准执行，而是会在编辑器中打开这份计划文档，像审阅稿件一样直接在上面添加批注。这些批注可能短至两个字，例如“不可行”，也可能是一段话，用于解释某个特定的业务约束，或纠正一个架构设计的方向。随后，他将带有批注的文档再次交给 Claude，并附上明确的指令：“我已添加了一些注释，请根据注释更新计划文档，先不要写代码。”
“先不要写代码”这句话是他每次都会强调的。因为 AI 一旦认为计划趋于完善，就会倾向于立即开始实现，而这个时机往往尚未成熟。这个“计划 - 批注 - 修订”的循环可能会重复一到六次。有观点认为，这种方式实质上是在将人类的专业判断和隐性知识注入到流程中：Claude 知道代码的语法和常见模式，但它不了解你产品的具体业务优先级、团队的技术偏好，或是你愿意在何处暂时接受技术债务。这个标注循环，正是将这些隐性知识转化为明确、可执行的指令的关键过程。当计划最终定稿后，他还会要求 Claude 将其分解为一个具体的待办事项清单，以便在后续实现阶段逐项追踪进度。
第三阶段是专注执行。当计划足够清晰和稳固后，才会进入代码实现阶段。此时，Boris 的指令变得非常标准化：“请全部实现，每完成一项就在计划文档中标记，直到所有任务完成前不要停止，并持续运行类型检查。”到了这一步，创造性和决策性的工作已经在前两个阶段完成，剩下的只是按图索骥的执行。他追求的是让执行过程变得“无聊”且可预测。在实现过程中，他的纠错反馈也变得极其简短，例如“你没有实现 deduplicateByTitle 函数”或“这个设置页应位于 admin 应用，而非主应用，请移动”。由于上下文（Context）依然存在，一句话便已足够。对于前端样式的调整，反馈甚至可能只有一个词：“更宽一点。”如果实现过程中出现重大架构问题，他的策略是直接回滚代码，然后缩小任务范围重新开始。经验表明，在清晰的范围内重做，几乎总是比在一个充满问题的代码堆上修修补补更加高效。
工作流的深层价值：持久化对齐与思维外化
有开发者曾提到，在使用 Claude 时，当上下文窗口消耗到一半左右，模型输出的质量可能会出现退化。然而，Boris 表示他很少遇到这个问题，其秘诀就在于 plan.md 这份文档。它作为一份持久化的、独立的“对齐文档”存在。即使会话的上下文被压缩或重置，这份文档始终存在，他可以随时让 Claude 重新读取它，从而确保思维的一致性和连续性。
这套流程并没有依赖任何神奇的“魔法提示词”（Magic Prompt）或复杂的工具链。它的本质是强制性地将模糊的思路逼到纸面上，通过反复的修订和标注，使其变得清晰、具体、无歧义。正如 Boris 所暗示但未明言的一点：这套流程要求开发者自己必须首先想清楚需求，AI 无法替代你完成这项核心的思考工作。
这套工作流最犀利之处，恰恰在于那句反复出现的“先不要写代码”。它戳破了一个常见的幻觉：我们以为 AI 在编程中的核心价值是“生成”，但其真正的价值在于“对齐”。代码写错了，编译器或测试会报错；但方向错了，却可能无人提醒。一个绕过了缓存层的函数，初期可能运行得飞快，却在三个月后导致整个系统在流量高峰时雪崩。Boris 真正在做的事情，是将 AI 从一名急于表现的“执行者”，训练成一位愿意接受反复审稿的“作者”——research.md 是初稿，plan.md 是修订稿，而人类的批注则是编辑的红笔。写作的秘密从来不是下笔如有神，而是不厌其烦地修改直至完善。AI 辅助编程，亦是同理。
原文链接： 让Claude写代码之前，先让它把想法写在纸上
