"我直接跟 AI 说不就行了，干嘛还要写文档？"

这大概是每个刚开始 Vibe Coding 的人都会有的想法。而且说实话，这个想法听起来很合理——既然 AI 能听懂人话，为什么还要写什么产品需求文档（PRD）？直接在 Cursor 里用中文聊不就完了？

我一开始也是这么想的。然后我做了三个项目，每个项目都在进行到一半的时候变成了一坨乱七八糟的东西。不是代码质量的问题——AI 生成的代码其实都挺工整的。问题是，我自己都不知道这个项目到底要做成什么样了。

第一个项目，做了一个小工具，做到第三天的时候我发现自己已经跟 AI 说了上百条指令，但这些指令之间经常矛盾。"加一个用户登录"——好了。"算了登录太复杂，改成匿名就行"——好了。"还是加上登录吧，但要简化"——好了。AI 每次都很配合，但项目已经被这些前后矛盾的指令搅成了一锅粥。

第二个项目更典型。我帮朋友做一个小电商，一开始说好只做商品展示，后来朋友说"能不能加个购物车"，然后"能不能加个支付"，然后"能不能加个优惠券"——每一次加功能我都是直接在 Cursor 里说一句话，从来没有在任何地方写下来"这个项目到底要做什么"。结果做到第二周，我和朋友对这个项目的理解已经完全不一样了。他觉得这是一个"能卖东西的店铺"，我觉得这是一个"商品展示页"。

这两次经历让我悟到一个道理：在 Vibe Coding 时代，PRD 不是变得不重要了，而是变得更重要了。

为什么 PRD 在 Vibe Coding 里更重要

传统开发的时候，一个项目从需求到上线，中间有一大堆环节：产品经理写需求、设计师画原型、开发评审、写技术方案、排期、开发、测试、上线。这些环节看起来很繁琐，但它们有一个隐藏的好处：每个环节都在帮你强制想清楚。设计师问你"这个按钮点了去哪"，你被迫想清楚了交互流程；开发说"这个功能要做两周"，你被迫想清楚了优先级。

Vibe Coding 把这些环节全部跳过了。你跟 AI 说一句话，它直接给你代码。没有人问你"这个按钮点了去哪"，没有人问你"这个功能值不值得做两周"。这种效率的提升，代价是你必须自己完成那些"强制想清楚"的工作。

PRD 就是帮你完成这个工作的工具。

你可以把 PRD 想象成一张地图。没有地图的时候，你就是在丛林里凭感觉走路——每走一步都觉得方向大概对，但走了一个小时之后回头看，你走了一个大圈又回到原点了。有了地图，你每走一步都知道自己在哪、要往哪去、还有多远。

而且这张地图不只是给你自己看的，更重要的是给 AI 看的。当你把 PRD 写好之后，你可以在每次跟 AI 对话的时候引用它："根据 PRD 第 3 条，帮我实现文章列表功能"。这样 AI 就不会每次都在猜你要做什么，因为答案就在 PRD 里。

"给人看的 PRD" vs "给 AI 看的 PRD"

话说回来，Vibe Coding 场景下的 PRD 和传统产品经理写的 PRD 是不一样的。

传统 PRD 是给团队看的。它需要考虑"非技术人员能不能读懂"、"设计师能不能理解交互意图"、"开发能不能评估工时"。所以传统 PRD 里会有大量的流程图、原型图、用户故事、验收标准等等。

Vibe Coding 的 PRD 是给AI + 你自己看的。它的目标不太一样：

给 AI 看的 PRD 有三个核心要求：

第一，结构化。 AI 读结构化文本比读散文高效得多。用标题、列表、表格来组织信息，而不是写一大段话。

第二，具体。 "界面要好看"这种话对 AI 毫无意义。"首页采用单栏布局，最大宽度 800px，正文字号 16px，行高 1.8，深色模式下背景色 #1a1a2e"——这才是 AI 能执行的描述。

第三，有边界。 告诉 AI 什么要做，更要告诉它什么不做。"不需要用户登录"、"不使用任何 CSS 框架"、"不要加动画效果"——这些否定性的约束往往比肯定性的需求更重要，因为它们阻止 AI 自作主张加你不想要的东西。

PRD 不是束缚，是导航

有些人可能会觉得：写 PRD 多麻烦啊，我就想赶紧开始做。

写 PRD 的价值不是保证一个固定百分比的提速，而是提前暴露范围、边界和验收标准。先花十几分钟写清这些信息，通常能减少“做了拆、拆了改、改了又拆”的返工；实际节省多少取决于项目复杂度和需求稳定性。

PRD 也不是一次写完就不动了的。Vibe Coding 的 PRD 是活的文档。你一开始写一个初版，做着做着发现某些功能不合理，回去改 PRD，然后继续做。但至少你有一个地方可以改，有一个"当前方向"可以参考，而不是全靠脑子记。

这就像开车。没有导航的时候你也能开到目的地，但你要一直想路线、一直做决策、一直怕走错。有了导航，你的大脑被释放出来，可以专注于"开好每一段路"，而不是同时还要想"下一个路口转哪边"。PRD 就是 Vibe Coding 的导航。