你是不是也这样拿到一个新的 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 的表现比从零设计要好得多。标注循环最关键环节这是工作流程中最独特、最有价值的部分。流程Claude 写完计划后在编辑器中打开 plan.md直接在文档中添加内联注释—— 纠正假设、拒绝方案、添加约束、提供领域知识发送指令“我在文档中添加了一些注释处理所有注释并相应更新文档。还不要实施”重复 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文档中完成。关键策略从提案中挑选当 Claude 识别多个问题时逐一处理“对于第一个只用 Promise.all不要过度复杂化对于第三个提取到单独函数以提高可读性忽略第四和第五个不值得增加复杂性”削减范围当计划包含锦上添花的功能时主动删减“从计划中删除下载功能我现在不想实现”保护现有接口当知道某些东西不应改变时设置硬约束“这三个函数的签名不应改变调用者应适应而不是库”覆盖技术选择有时有 Claude 不知道的特定偏好“使用这个模型而不是那个或使用这个库的内置方法而不是写自定义的”Claude 处理机械执行你做判断。计划预先捕获大决策选择性指导处理实施期间出现的小决策。单次长会话在单次长会话中运行研究、规划和实施而不是拆分成单独的会话。一次会话可能从深度阅读文件夹开始经历三轮计划标注然后运行完整实施全部在一次连续对话中。优势到说实施所有内容时Claude 已经花了整个会话建立理解研究期间阅读文件、标注循环中精炼心智模型、吸收领域知识修正当上下文窗口填满时Claude 的自动压缩保留足够的上下文继续计划文档持久化产物在压缩中完整保真地存活下来可以随时指向它作者表示没有遇到大家说的50%上下文窗口后的性能下降。一句话总结工作流程深度阅读写计划标注计划直到正确然后让 Claude 不停顿地执行整个流程同时检查类型。没有魔法提示词没有精心设计的系统指令没有聪明的技巧。只是一个将思考与打字分离的纪律性流程研究防止 Claude 做出无知的更改计划防止它做出错误的更改标注循环注入你的判断实施命令让它在所有决策做出后不中断地运行试试这个工作流程你会惊讶于在没有标注计划文档的情况下你是如何用编码代理交付任何东西的。