在过去大约 9 个月的时间里，我一直将 Claude Code 作为我的主要开发工具。我所习惯的工作流与大多数人使用 AI 编程工具的方式截然不同。
大多数开发者的做法是：输入一个提示词（prompt），有时会使用“计划模式”（plan mode），修复错误，然后不断重复。而那些更资深的“重度在线”开发者可能会拼凑一些复杂的循环、MCP（模型上下文协议）或其他各种花哨的工具。
但在处理非琐碎的任务时，这些做法产生的结果往往是一团糟，甚至彻底崩溃。
我将要描述的工作流有一个核心原则：在审查并批准书面计划之前，绝不让 Claude 编写任何代码。 这种将“规划”与“执行”完全分离的做法，是我所做的最重要的事情。它能防止无谓的劳动，让我始终掌握架构决策权，并能以极少的 Token 消耗获得远超直接编写代码的效果。
这个工作流的循环通常是 1 到 6 次：研究 → 计划 → 标注 → 待办清单 → 实现 → 反馈与迭代。
第一阶段：研究 (Phase 1: Research)
任何有意义的任务都始于一个“深度阅读”指令。在进行任何操作之前，我都会要求 Claude 彻底理解代码库的相关部分。而且，我始终要求将研究结果写进一个持久化的 Markdown 文件（research.md），而不是仅仅在聊天窗口里给出一个口头总结。
常用的提示词示例：
- “深入阅读这个文件夹，透彻理解它的工作原理、功能以及所有细节。完成后，在
research.md中写一份详细的学习与发现报告。” - “详尽研究通知系统，理解其复杂性，并编写一份包含所有通知运作细节的
research.md文档。” - “梳理任务调度流程，深入理解并寻找潜在的 Bug。系统中肯定存在 Bug，因为它有时会运行本该被取消的任务。持续研究流程直到找到所有 Bug，不要停。完成后，在
research.md中记录详细发现。”
注意其中的措辞： “深入（deeply）”、“详尽（in great details）”、“复杂性（intricacies）”、“梳理所有细节”。这并非废话。如果没有这些词，Claude 会蜻蜓点水——它可能只读一下文件，看一眼函数签名的功能就跳过了。你需要明确发出信号：表面的阅读是不可接受的。
第二阶段：规划 (Phase 2: Planning)
一旦我对 research.md 中的研究结果感到满意，下一步就是制定计划。我会要求 Claude 基于研究发现，在 plan.md 文件中编写详细的实施计划。
我的指令通常是：
“基于 research.md 中的发现，为 [我们要做的任务] 编写一份详尽的 plan.md。计划应包含：
- 实现这一目标所需的所有步骤。
- 涉及到的文件及具体改动。
- 关键部分的伪代码或代码片段示例。
- 任何需要考虑的边缘情况或潜在风险。 在计划写完后立即停止，不要开始编写代码。”
让它在写完计划后停止至关重要。我需要一个可以审查、修改和迭代的“蓝图”，而不是一堆直接生成出来的、可能带有错误假设的代码。
标注循环 (The Annotation Cycle)
这是我工作流中最独特、也是我作为人类开发者贡献价值最大的环节。
当 Claude 写好计划后，我会在编辑器中打开它，并直接在文档中添加行内注释。这些注释会纠正 AI 的假设、拒绝某些方案、添加约束条件，或者提供 Claude 所不知道的领域知识。
注释的长度各异。有时只是在 Claude 标记为可选的参数旁写上“不是可选的”；有时则是长篇大论，解释业务限制或粘贴我期望的数据结构。
一些我添加注释的真实例子：
- 从方案中筛选： 当 Claude 提出多种解决问题的方法时，我会逐一决定：“对于第一种，直接用
Promise.all即可，别搞复杂了；对于第三种，为了可读性，将其提取成独立函数；忽略第四和第五种，不值得增加复杂度。” - 缩减范围（Trimming scope）： 当计划中包含一些“有了更好（nice-to-have）”的功能时，我会主动砍掉：“从计划中移除下载功能，我现在不想实现它。”
- 纠正架构决策： “不要把逻辑放在 API 路由里，创建一个新的 Service 类，这样我们可以更好地进行单元测试。”
我会把这些标注后的文件交给 Claude，让它更新计划。我们会这样往复 1-6 次，直到计划完美。
第三阶段：实现 (Phase 3: Implementation)
一旦计划通过批准，实施过程就变成了一个机械的、自动化的过程。我会使用一个预设的长提示词，让 Claude 一气呵成地执行整个计划。
核心指令模板：
“基于批准的 plan.md 实现所有功能。
- 完整实现： 按照计划执行，不要偷工减料。
- 记录进度： 每完成一项任务，就在
plan.md的待办清单中标记完成。 - 不要停止： 直到所有任务和阶段全部完成前，不要停下来寻求确认。
- 保持简洁： 不要添加不必要的注释或 JSDoc。
- 严谨类型： 禁止使用
any或unknown类型。 - 持续检查： 在过程中持续运行类型检查（typecheck），确保不引入新问题。”
这个提示词确保了 Claude 能够像一个高效率的初级工程师一样，在既定的轨道上全速前进。
实现过程中的反馈 (Feedback During Implementation)
尽管有了周密的计划，在实现过程中仍可能出现意外。如果 Claude 遇到了计划中未预见的障碍，它会停下来。这时我会介入：
- 快速纠偏： 如果它走错了方向，我会立即在聊天中指出，并让它重新调整。
- 实时决策： 某些微小的细节在规划阶段很难预见，我会在此刻给出决策。
保持主导地位 (Staying in the Driver’s Seat)
通过这种方式，我始终坐在“驾驶席”上。Claude 负责繁重的阅读、编写和类型对齐工作，而我负责最关键的事情：决策、架构和约束。
如果我不满意，我会直接修改 plan.md。这比在成百上千行生成好的代码中寻找逻辑错误要容易得多。
长会话模式 (Single Long Sessions)
我倾向于在一次长会话中完成任务。Claude Code 在处理上下文轮转和长对话方面做得很好。在单个会话中，它对整个任务的演进过程有最完整的记忆。
一句话总结这个工作流
深读代码，编写计划，不断标注直到计划正确，然后让 Claude 一气呵成地执行，过程中全程开启类型检查。
这就是全部。没有魔法般的提示词技巧，没有复杂的系统指令，也没有聪明的“黑科技”。只是一个纪律严明的流水线，将“思考”与“打字”彻底分离。
这种方法能防止 Claude 因为无知而乱改代码，也能防止它因错误决策而浪费 Token。尝试一下这个工作流，你会惊讶于在没有这份“标注计划书”之前，你竟然能用 AI 写出代码。