当 AI 开始写代码时，很多人以为是「一键生成」，但现实往往是一堆错误。一位开发者发现，让 AI 先写计划再执行，能避免 90% 的错误。这不是魔法，而是软件工程的老智慧在 AI 时代的重生。

AI 编程的常见陷阱

直接让 AI 写代码的常见结果是什么？Hacker News 上的一位开发者吐槽：「AI 像一个不理解公司流程的实习生，会忽略缓存层、重复逻辑，甚至破坏整个系统。」这不是夸张，《How I Use Claude Code》中描述了一个典型场景：当开发者简单地让 AI「添加分页功能」时，AI 可能写出能跑但破坏现有架构的代码——比如忽略 ORM 约定、重复已有逻辑、或绕过缓存层。

这种问题的根源在于，AI 缺乏对整个系统的理解。它能理解单个函数，但无法把握全局架构。就像让一个刚毕业的实习生直接修改核心系统，而不先了解系统全貌。一位 Hacker News 用户尖锐指出：「LLM 不会真正理解你的系统，它只是在预测下一个词。当它遇到模糊描述时，会自动填充错误的假设。」

「计划-执行」分离的工作流

Boris Tan 的工作流核心很简单：永远不让 AI 写代码前，先审核并批准书面计划。具体分三步：

1. 深度研究：让 AI 详细阅读代码库，生成 research.md 报告
2. 详细计划：基于研究，生成 plan.md，包含代码片段、文件路径、权衡分析
3. 反复批注：在 plan.md 中直接添加注释修正问题，重复直到计划完美，再执行

这个方法的关键是「分离思考与执行」。正如 Hacker News 用户所说：「当 AI 在纸上写下计划时，它会暴露自己的假设。如果计划里说『用 PUT 请求』，但实际应该用 PATCH，这时候就能修正，而不是等代码写完才发现。」

有趣的是，这并不是新方法。Google 的 Antigravity、Amazon 的 Kiro、GitHub 的 Spec Kit 等工具都内置了类似功能。Hacker News 上一位开发者吐槽：「Boris 以为自己发明了新流程，其实 Claude Code 的 Plan Mode 早就支持了。」但 Boris 的贡献在于，他把这种模式系统化、文档化，并强调了「批注计划」这个关键细节——在计划文件中直接标注问题，而不是在聊天中反复解释。

为什么这个方法有效

技术上，这利用了 LLM 的注意力机制。当 AI 被要求「deeply」、「in great details」时，它会更深入地分析上下文。《How I Use Claude Code》中提到：「没有这些词，Claude 会 skim（略读），只看函数签名就跳过。」

更深层的原因是，书面计划提供了共享可变状态。开发者可以在计划文件中直接标注问题，比如「这个字段不该是可选的」、「用 PATCH 而不是 PUT」，而不需要在聊天中反复解释。Hacker News 上有人指出：「在聊天中找决策痕迹像翻旧邮件，而计划文件是结构化、完整的规格说明。」

但这个方法也有争议。一位 Hacker News 用户尖锐提问：「10 万行计划文件？光读就要 66 小时！」事实是，多数人用分阶段任务控制 token 消耗，比如「每次只处理 1500 行代码的计划」。资深开发者指出：「计划不是为了写得详尽，而是为了暴露关键假设。」

实际应用中的变种流程

许多开发者对这个方法做了调整：

• 分阶段实施：不一次性写大代码，而是拆成小任务，每完成一个就验证
• 多 Agent 协作：一个 AI 写计划，另一个 AI 审查，第三个 AI 实现
• 测试驱动开发：先让 AI 写测试，再写实现代码
• GitHub Issue 替代计划文件：直接用 Issue 记录计划，方便追踪

一位开发者分享：「我用 AWS Kiro，它自动把需求→设计→任务→代码分层，每次只做一小步，错误率大幅下降。」另一位则说：「我让 Claude 先写测试，再写代码。如果测试失败，AI 必须修正。这比等代码写完再测试安全得多。」

成本也是一个考量。Hacker News 上有人指出：「10 万行计划文件？光读就要 66 小时！」实际上，多数人用分阶段任务控制 token 消耗，比如「每次只处理 1500 行代码的计划」。一位资深开发者建议：「把计划拆成可验证的阶段，每个阶段都是可运行的代码，这样即使出错也能快速回滚。」

安全与可靠性保障

单纯靠计划还不够。Hacker News 上专家强调：「需要限制 Agent 权限，比如只允许访问特定文件」，以及「用测试套件验证代码」。

一位开发者分享：「我让 AI 先写测试，再写代码。如果测试失败，AI 必须修正。这比等代码写完再测试安全得多。」更关键的是，计划阶段要显式列出「不确定项」。比如 AI 说「我假设这个 API 是同步的」，但实际是异步的，这时候就能提前发现。Hacker News 上有人指出：「这比等代码写完才发现问题省得多。」

安全专家补充：「权限管理必须严格。比如让 AI 只读特定文件夹，写入时只允许修改特定文件。否则它可能误删数据库或覆盖关键配置。」一位实际使用者分享：「我用 husky 钩子强制运行测试脚本，AI 提交的代码必须通过所有测试才能合并。」

未来展望

这个工作流背后是「规范驱动开发」（Spec-Driven Development）的兴起。GitHub 的 Spec Kit、OpenSpec 等工具都在推动这个方向。

未来，AI 编程可能更像「人机协作」：人类负责架构设计和关键决策，AI 负责机械执行。Hacker News 上一位资深开发者说：「这不改变软件工程本质，只是把『写文档』环节自动化了。」

就像汽车取代马车，但驾驶原理不变。AI 工具不是要取代开发者，而是让开发者从「写代码」转向「管理 AI」——这其实是软件工程的老智慧：先设计，再实现。一位开发者总结得精辟：「好代码从来不是写出来的，而是设计出来的。」