你是不是也这样？

拿到一个新的 AI 编程工具，上来就直接丢给它一句：“帮我写个贪吃蛇游戏”或者“给这个页面加个搜索功能”。

然后呢？代码看似跑通了，一进项目全是 Bug。缓存层被忽略了，ORM 约定被打破了，甚至还在不知名的地方重复造了个轮子。

这不是 AI 笨，是你懒。

在大模型辅助编程这件事上，绝大多数人都犯了一个致命错误：把“思考”和“执行”混为一谈。

硅谷大佬 Boris Tane 在高强度使用了 9 个月 Claude Code 后，总结出了一套足以颠覆你认知的“人机隔离工作流”。

这套方法的核心只有一句话：在你审查并批准计划之前，绝不让 AI 写一行代码。

只要你能管住 AI 的手，它的效率能吓死你。

下面这套价值千金的 Research → Plan → Annotate → Implement 工作流，建议全文通读。
这篇文章分享了作者使用 Claude Code 9个月后总结的开发工作流程。核心原则是：在审查并批准书面计划之前，绝不让 Claude 直接写代码。这种将规划与执行分离的方式，能显著提升代码质量、减少token消耗，并保持对架构决策的控制。

完整工作流程（循环1-6次）

研究 → 规划 → 标注 → 任务清单 → 实施 → 反馈迭代

---

第一阶段：深度研究

每个任务都从深度阅读指令开始，要求 Claude 彻底理解代码库的相关部分，并将研究结果写入持久化的 markdown 文件（如 research.md），而不是口头总结。

示例提示词：

• “深入阅读这个文件夹，深刻理解它的工作原理、功能和所有细节。完成后，将你的学习和发现写成详细的 research.md 报告”
• “详细研究通知系统，理解其复杂性，写一份详细的 research.md 文档”
• “彻底研究任务调度流程，找出所有潜在bug，不要停止直到找到所有问题”

关键技巧：

• 使用强调词：“深入”、“详细”、“复杂性”、“彻底” —— 这些词能防止 Claude 浅层阅读
• 书面报告是审查界面 —— 可以验证 Claude 是否真正理解系统，在规划前纠正误解
• 这能防止最昂贵的失败模式：代码单独运行正常，但破坏了周围系统（如忽略缓存层、重复现有逻辑等）

---

第二阶段：规划

审查研究后，要求在单独的 markdown 文件中生成详细实施计划。

示例提示词：

• “我想构建一个新功能<名称和描述>，写一份详细的 plan.md 文档说明如何实现，包含代码片段”
• “列表端点应支持基于游标的分页而不是偏移量。写一份详细的 plan.md，在建议更改前阅读源文件，基于实际代码库制定计划”

计划文档包含：

• 方法的详细解释
• 显示实际更改的代码片段
• 将修改的文件路径
• 考虑因素和权衡

为什么用自己的 .md 文件而非内置计划模式？

• 内置计划模式功能有限
• Markdown 文件提供完全控制：可在编辑器中编辑、添加内联注释、作为项目的真实产物持久保存

实用技巧：
对于边界清晰的功能，如果在开源项目中见过好的实现，可以分享该代码作为参考：“这是他们实现可排序ID的方式，写一份 plan.md 解释我们如何采用类似方法”。有具体参考实现时，Claude 的表现比从零设计要好得多。

---

标注循环（最关键环节）

这是工作流程中最独特、最有价值的部分。

流程：

1. Claude 写完计划后，在编辑器中打开 plan.md
2. 直接在文档中添加内联注释 —— 纠正假设、拒绝方案、添加约束、提供领域知识
3. 发送指令：“我在文档中添加了一些注释，处理所有注释并相应更新文档。还不要实施”
4. 重复 1-6 次，直到计划完美

真实注释示例：

• “使用 drizzle:generate 进行迁移，不要用原始SQL” —— 领域知识
• “不对 —— 这应该是 PATCH，不是 PUT” —— 纠正错误假设
• “完全删除这一节，我们这里不需要缓存” —— 拒绝方案
• “队列消费者已经处理重试，所以这个重试逻辑是多余的。删除它，让它直接失败” —— 解释为什么要改
• “这是错的，visibility 字段应该在列表本身，而不是单个项目上。当列表公开时，所有项目都公开。相应地重构模式部分” —— 重定向整个章节

"还不要实施"的保护至关重要 —— 没有这句话，Claude 会在认为计划足够好时就跳到代码实现。

为什么这么有效？

• Markdown 文件作为共享可变状态 —— 可以按自己的节奏思考，精确标注问题所在，重新参与而不丢失上下文
• 不是通过聊天消息解释一切，而是指向文档中的确切位置并在那里写下修正
• 这与通过聊天消息引导实施根本不同：计划是可以整体审查的结构化完整规范；聊天对话需要滚动重建决策
• 三轮"我添加了注释，更新计划"可以将通用实施计划转变为完美契合现有系统的方案
• Claude 擅长理解代码、提出解决方案和编写实现，但它不知道你的产品优先级、用户痛点或愿意做出的工程权衡 —— 标注循环是注入这些判断的方式

任务清单

实施前，始终要求详细的任务分解：

“在计划中添加详细的待办事项列表，包含完成计划所需的所有阶段和单个任务 —— 还不要实施”

这创建了一个检查清单，作为实施期间的进度跟踪器。Claude 会在进行时标记已完成的项目，可以随时查看进度。

---

第三阶段：实施

计划就绪后，发出实施命令。作者提炼了一个跨会话重用的标准提示词：

“实施所有内容。完成任务或阶段后，在计划文档中标记为已完成。不要停止，直到所有任务和阶段都完成。不要添加不必要的注释或 jsdocs，不要使用 any 或 unknown 类型。持续运行 typecheck 确保不引入新问题。”

这个提示词编码了所有重要内容：

• “实施所有内容”：执行计划中的一切，不要挑选
• “标记为已完成”：计划是进度的真实来源
• “不要停止直到完成”：不要中途暂停确认
• “不要添加不必要的注释”：保持代码简洁
• “不要使用 any 或 unknown 类型”：保持严格类型
• “持续运行 typecheck”：尽早发现问题

到说"实施所有内容"时，每个决策都已做出并验证。实施变得机械化而非创造性。这是有意为之 —— 希望实施是无聊的。创造性工作发生在标注循环中。一旦计划正确，执行应该是直接的。

---

实施期间的反馈

Claude 执行计划时，角色从架构师转为监督者。提示词变得极其简短：

实施修正示例（通常一句话）：

• “你没有实现 deduplicateByTitle 函数”
• “你在主应用中构建了设置页面，应该在管理应用中，移动它”

前端工作最需要迭代 —— 在浏览器中测试并快速修正：

• “更宽”
• “仍然被裁剪”
• “有2px间隙”

视觉问题有时附上截图 —— 截图比描述更快传达问题。

经常引用现有代码：

• “这个表格应该看起来和用户表格完全一样，相同的标题、分页、行密度”

这比从头描述设计精确得多。成熟代码库中的大多数功能都是现有模式的变体。

当方向错误时，不要试图修补 —— 回滚并重新界定范围：

• “我回滚了所有内容。现在我只想让列表视图更简洁 —— 仅此而已”

回滚后缩小范围几乎总是比试图增量修复错误方法产生更好的结果。

---

保持主导地位

虽然将执行委托给 Claude，但从不给它完全自主权。绝大多数主动引导在 plan.md 文档中完成。

关键策略：

1. 从提案中挑选： 当 Claude 识别多个问题时，逐一处理：“对于第一个，只用 Promise.all，不要过度复杂化；对于第三个，提取到单独函数以提高可读性；忽略第四和第五个，不值得增加复杂性”

2. 削减范围： 当计划包含锦上添花的功能时，主动删减：“从计划中删除下载功能，我现在不想实现”

3. 保护现有接口： 当知道某些东西不应改变时设置硬约束：“这三个函数的签名不应改变，调用者应适应，而不是库”

4. 覆盖技术选择： 有时有 Claude 不知道的特定偏好：“使用这个模型而不是那个"或"使用这个库的内置方法而不是写自定义的”

Claude 处理机械执行，你做判断。计划预先捕获大决策，选择性指导处理实施期间出现的小决策。

---

单次长会话

在单次长会话中运行研究、规划和实施，而不是拆分成单独的会话。一次会话可能从深度阅读文件夹开始，经历三轮计划标注，然后运行完整实施，全部在一次连续对话中。

优势：

• 到说"实施所有内容"时，Claude 已经花了整个会话建立理解：研究期间阅读文件、标注循环中精炼心智模型、吸收领域知识修正
• 当上下文窗口填满时，Claude 的自动压缩保留足够的上下文继续
• 计划文档（持久化产物）在压缩中完整保真地存活下来，可以随时指向它

作者表示没有遇到大家说的50%上下文窗口后的性能下降。

---

一句话总结工作流程

深度阅读，写计划，标注计划直到正确，然后让 Claude 不停顿地执行整个流程，同时检查类型。

没有魔法提示词，没有精心设计的系统指令，没有聪明的技巧。只是一个将思考与打字分离的纪律性流程：

• 研究防止 Claude 做出无知的更改
• 计划防止它做出错误的更改
• 标注循环注入你的判断
• 实施命令让它在所有决策做出后不中断地运行

试试这个工作流程，你会惊讶于在没有标注计划文档的情况下，你是如何用编码代理交付任何东西的。