周末在做一个 side project——用 Rust 写的 macOS 语音助手。项目一开始，我让 Claude 帮我生成了一份 ROADMAP。结果非常漂亮：7 个 milestone，每个都列出了具体的 feature、文件结构、依赖关系，连模块怎么拆都替我想好了。比我自己规划的要系统得多。

于是我说：按这个执行。

一切看起来很顺利

AI 执行得很快。M1 到 M7，一个接一个，代码量蹭蹭往上涨。我问它：测试写了吗？没有。那加上，coverage 做到 80%。很快也完成了。CI 全绿，编译通过，测试覆盖率达标。

看上去一切就绪，我让它打了个安装包，装到自己机器上准备试试。

打开应用——语音不工作。切到聊天模式——AI 的回复像个没有灵魂的客服，跟我精心写的人格定义完全不沾边。看了一眼系统托盘——根本没打包进去，安装包里压根就没有 UI。

这就是 AI 告诉我的“完成了”。

不得已，我开始自己一个功能一个功能地调。声音采集的格式跟 STT 服务对不上，WAV 解析器假设了固定的文件结构结果遇到 macOS 的非标输出就崩，回放不阻塞导致回声消除形同虚设——每一个都不是 ROADMAP 上能看到的问题，每一个都只有真正跑起来才会暴露。

调着调着，架构也做了大范围的调整。等我把核心功能一个个修到能用，回头一看，代码已经跟 ROADMAP 对不上了。有些 ROADMAP 上的模块被删了，有些没在 ROADMAP 上的功能被加了进来。

这时候我意识到一个问题：ROADMAP 已经不能告诉我这个项目的状态了。 我需要一个不同的东西。

PRD 打脸的那一刻

PRD 写完之后，我对着它做了一次 audit——逐条核对每个 functional requirement 的完成状态。

结果让我挺意外。

Text REPL 根本不在 PRD 里。 PRD 写得很明确：这是一个 voice-first 的应用，用户通过语音交互，”no button press, hotkey, or wake word is needed”。Text mode 只是 settings 里的一个备选项，不是核心交互路径。但 ROADMAP 把它放在了 M1 的第一个位置，于是它成了我写的第一个功能。

这还不是最离谱的。继续 audit，我发现了更多问题：

  • 人格定义文件花了大量心思编写，build 的时候也做了加密编译进 binary——但聊天路径根本没用它，用的是一段硬编码的通用 prompt
  • UI 模块代码写完了，但 release workflow 里没把它打包进应用 bundle，等于发版了也装不上
  • 好几个标记了“允许死代码”的函数，追溯来源全是 text REPL 的遗留

每一个都不是编译错误，每一个都不会让 CI 失败，但每一个都意味着产品目标没有达成。

AI 擅长规划执行，不擅长定义目标

回头看，问题不在 ROADMAP 本身的质量——它写得确实好，结构清晰，依赖合理，分阶段交付。问题在于，ROADMAP 回答的是“怎么做”和“按什么顺序做”，但它不回答“做这些对不对”。

AI 生成 ROADMAP 的时候，它的输入是我对项目的描述。它会基于这些信息推导出一个合理的执行计划，但它没有能力替我判断“Text REPL 对用户到底重不重要”。这个判断需要的是产品直觉和对用户场景的理解，不是逻辑推演。

更微妙的是，AI 生成的 ROADMAP 看起来太专业了，专业到让你放松了警惕。当一份计划的形式足够完美时，你会不自觉地信任它的内容。 每个 milestone 完成都有实质性的代码产出，测试通过，功能可用——但“能跑”和“做对了”之间的距离，比大多数人以为的要远得多。

这也是我自己的教训：我之前写过 Agent-Oriented Engineering，讨论人类工程师的角色要从 execution 转向 judgment。结果转头自己就犯了这个错——把 AI 生成的 execution plan 当成了 judgment 的替代品。

PRD 是你自己的判断

PRD 的价值不在于它的格式或篇幅，而在于它是你自己想清楚的东西。

写 PRD 的时候，我必须回答：“这个产品到底要解决什么问题？用户在什么场景下用它？什么功能是核心的，什么是锦上添花的？”这些问题 AI 帮不了你，因为答案来自你对用户场景的理解和取舍。

有了 PRD 之后，审视代码的视角完全不同了。ROADMAP 视角问的是“这个模块写了没有”，PRD 视角问的是“这个功能端到端达标了没有”。同样是人格定义文件，ROADMAP 视角看到的是“加密编译 ✓”，PRD 视角看到的是“聊天路径的 AI 人格跟定义不一致 ✗”。

ROADMAP 是自洽的——每个 milestone 都能独立验证。但自洽不等于正确。 一份脱离了产品目标的 ROADMAP，可以让你高效地做一堆错误的事情。

事后复盘

删掉 text REPL 的时候，我没有太多心疼。真正让我不舒服的是另一件事：如果一开始就先写 PRD 再让 AI 生成 ROADMAP，这些代码根本不会存在。背后的周末时间——设计、编码、测试、调试——本来可以花在 voice pipeline 的打磨上。

同样，人格定义没被聊天路径使用这个问题，如果我每次做完一个功能就对着 PRD 验一遍，当场就能发现。但 ROADMAP 里对应模块的 milestone 只写了“实现 SSE streaming + conversation history”，勾完就走了，没人检查输出内容是否符合产品定义。

正确的顺序

说到这里，我不是在否定 AI 生成 ROADMAP 的价值。它确实能帮你快速把模糊的想法变成可执行的计划。但顺序很重要：

  • 先写 PRD——自己想清楚要做什么、不做什么、什么算完成
  • 再让 AI 生成 ROADMAP——基于 PRD 的约束来规划执行路径
  • 定期用 PRD audit——每隔几个 milestone 停下来校准一次

PRD 是锚，ROADMAP 是航线，audit 是罗盘。三个都要有，但锚必须是你自己抛下去的，不能让 AI 替你抛。

停下来的成本

最后一个感悟：audit 这个动作本身的价值被严重低估了。

一次 audit，大概花了两个小时。结果呢？发现了 6 个 gap，其中 3 个在关键路径上。如果我一直按 ROADMAP 往前冲，这些问题可能到真正要用的时候才会暴露——到那时候修的成本是现在的十倍。

开发者天生不喜欢“停下来回头看”这件事。写新代码有多巴胺，审视旧代码只有焦虑。但这次经历让我确信：定期停下来用 PRD 校准一次，是投入产出比最高的工程活动之一。 成本是两个小时的审视，收益是避免在错误的方向上继续投入。

这次经历教会我的，不是“别写错代码”，而是“别在没有锚的海上全速前进”——哪怕那条航线是 AI 画的，看起来完美无缺。