需求文档才是源代码

给 AI 擦屁股的日常

每天用 Cursor 开发项目，流程是这样的：

一个需求一个需求地来。写提示词，盯着 AI 产出，验证结果。AI 绕圈了？翻代码，找问题，指出来，修复。

效率确实比以前高了。

人也比以前更累。

感觉自己一天到晚在给 AI 擦屁股。而且还必须一个个擦。

最近发现了 Vibe Kanban。

它能把大需求拆成多个子需求，然后同时启动多个 AI 编码。

页面很直观，就像项目管理的看板——这个我太熟悉了。

每天在看板提需求、安排 AI 开发、验收、提交。怎么看都像是产品经理在看板提需求，然后把 AI 当程序员，直接完成。

好处是什么？

原来程序员还需要把产品需求复制粘贴给 AI。现在不需要了。

Ravi Mehta 说得很准确：未来，需求文档才是最重要的。

代码？只要有需求文档，你可以生成各种代码。

就像程序员不会看汇编代码一样，产品经理也不需要看代码。

传统开发中，程序员写"源代码"，编译成机器能读的"目标代码"。源代码是真相，目标代码只是副产品。

现在呢？

我们写精心设计的提示词（也就是需求文档），AI 生成代码。然后我们保留代码，扔掉提示词。

这就像你把源代码撕了，然后小心翼翼地版本控制那个二进制文件。

反了。

代码，即使是优雅的代码，也只是需求文档的"有损投影"。就像反编译二进制文件不会给你原始注释和变量名一样，读代码也不会告诉你背后的完整意图。

但需求文档包含一切。

一个足够健壮的需求文档可以生成"好的 TypeScript、好的 Rust、服务器、客户端、文档、教程、博客文章，甚至播客"。

更重要的是，需求文档做到了代码做不到的事：它让人和机器在共同目标上对齐。

以前的流程：模糊想法 → 线框图 → 设计 → 工程师构建 MVP → 客户反馈 → 痛苦的需求修订 → 线框图 → 设计 → 重建 → 祈祷。

现在的流程：模糊想法 → 快速原型 → 客户反馈 → 清晰需求 → AI 辅助实现。

原型没有杀死需求文档。它们让需求文档变得更好。

而需求文档，正在成为新的源代码。

瓶颈不再是构建。是知道构建什么，以及让团队围绕这些需求对齐。

突然之间，谦卑的需求文档不再是短暂的文书工作。它成了产品管理的基础——它正在成为源代码本身。

William Gibson 说过："未来已经到来——只是分布不均。"

今天，AI 的收益极不均衡。有些事情——生成代码、文本、图像——已经实现了量子飞跃。它们以 AI 速度运行。其他事情——与客户交谈、发现他们的需求、说服他们购买——仍然以人类速度移动。

这种不均衡正在重塑产品团队。

聚光灯正在从实现工作转向理解工作。

那些一直让最好的产品经理脱颖而出的核心技能——理解用户需求、清晰定义问题、设计优雅解决方案——变得指数级更有价值。

最好的产品经理将这些洞察转化为需求文档——在日益自动化的开发世界中，这些需求文档对齐团队、指导实现，并作为持久的产物。