AI写PRD总翻车？不是AI不行，而是需求文档的接口错了。当代码生成从人转向AI，PRD这种“给人看”的格式正在过时。本文深入解析SPEC文档如何取代传统PRD，实现一个上午干完五天活的效率飞跃。

一、你有没有发现，AI写PRD总是差点意思

很多产品经理最近都在做同一件事：试着让AI帮自己写需求文档。

结果往往是——写出来的东西看着像模像样，真拿到开发面前一问，到处都是坑。边界不清、逻辑断层、异常状态全靠脑补，最后还得自己返工重写，反而更费时间。

于是很多人得出结论：AI写需求还不行，只能打个初稿，最终还是得靠人。

但这个结论可能错了。

不是AI不行，而是我们拿错了”接口”。我们还在用写给人看的PRD格式，去喂给需要精确指令的AI。这就像拿着软盘往USB接口里插——不是存储介质本身不好，是接口不对。

今天这篇文章想讲清楚一件事：AI时代，产品经理的需求输出方式正在发生一场底层范式转移。不是”用AI帮我写PRD”，而是PRD这个形态本身，已经开始过时了。

二、三种需求生产方式的本质差异

在展开之前，我们先把目前主流的三种需求生产方式放在一起对比，你会立刻看出差别在哪里。

第一种：传统PRD作业

这是过去十几年的标准打法。产品经理梳理业务需求，输出一份漂漂亮亮的PRD——包含背景、目标、用户故事、功能列表、交互原型、异常流程等等。然后丢给开发，开发看完文档，理解需求，再翻译成代码。

这个模式的核心特征是：文档的读者是人。正因为读者是人，所以文档里可以有很多”意会”的空间。开发看到一个功能描述，会自动脑补边界情况、异常处理、技术实现的可能性。产品经理写文档时也默认对方有行业经验、有业务理解，很多细节不用写得太死。

好处是灵活，人和人之间可以通过沟通补全信息。坏处是效率低，一份像样的PRD动辄写一两天，中间还要反复评审、对齐、改稿。

第二种：Vibe Coding（直接丢需求给AI）

AI火了之后出现的新玩法，最典型的就是Andrej Karpathy在2025年初提出的”Vibe Coding”——你用自然语言跟AI说”我想做一个小程序”，然后AI直接给你生成代码，你边看边改，直到满意为止。

放到产品侧就是：直接把业务需求丢给AI，让它连需求带代码一起出。

听起来很美，但实际用起来问题很大。没有边界约束的AI就像一匹脱缰的野马，它确实能给你输出东西，但输出的是不是你想要的，全靠运气。需求越复杂，跑偏的概率越高。最后你花在纠正方向上的时间，可能比自己写还多。

Vibe Coding适合小demo、个人项目，但放到正经的业务产研流程里，它的可控性太差了。

第三种：Spec Coding（SPEC文档驱动）

这是目前工业界正在快速普及的第三种方式，也是我自己实践下来效率提升最夸张的一种。

简单说就是：产品经理不再写PRD，而是写一份SPEC文档。这份文档不是写给人看的，是写给AI读的。它只保留AI生成代码真正需要的东西——核心逻辑、业务流程、边界条件、验收标准。原型不再内嵌在文档里，而是用HTML方式外挂关联。

开发拿到SPEC，评估没问题后，直接把这份文档丢给AI，就能生成可落地的代码。中间不需要再做一次”人类语言到AI指令”的翻译。

你可能已经看出来了：这三种方式的根本差别，不是工具先进程度，而是”需求的输出对象”变了。

三、真正的变化：接口已经从人变成了AI

这是我认为最关键的一个判断——很多人还没意识到，需求文档的”消费端”已经悄悄换人了。

过去写PRD，你面对的下游是开发工程师。人有想象力、有行业经验、有上下文理解能力，所以文档写得模糊一点没关系，大家开会聊两句就对齐了。

现在不一样了。越来越多的开发已经不再自己逐行写代码，而是把需求整理成prompt丢给AI生成。这意味着，需求的最终执行者，正在从人变成AI。

既然执行者变了，那给执行者的”输入格式”是不是也该变？

这就是为什么之前用AI写PRD总不好用的根本原因。我们抱着旧的接口思维不放——还是按照”给人看”的标准写需求，然后指望AI既能读懂人的弯弯绕，又能精确生成代码。这本身就是矛盾的。

3.1 人需要理解，AI需要界定

人读文档，会自动补全缺失的信息；AI读文档，你写什么它就执行什么，没写的它不会自己加。你给它一份写得”诗情画意”的PRD，它只能给你输出一份看起来很美但到处漏风的代码。

3.2 全链路都要跟着变

从全链路的视角看，这个变化的影响远不止”换个文档格式”这么简单。当需求的接口从人变成AI，整个产研协作链条的每个节点都要跟着调整。需求怎么写、原型怎么出、评审怎么开、测试怎么测——每一环都要重新设计。

只改一个节点，效果当然有限。但如果从整个链条一起发力，带来的就是数量级的效率提升。（关于AI时代的产研全链路协作方式，我会单独再写一篇文章详细拆解，这里先按下不表。）

四、SPEC和结构化PRD，到底有什么本质区别

肯定有人会问：SPEC不就是写得更结构化的PRD吗？把边界写清楚一点、格式规整一点，换个名字而已？

还真不是。这两者的底层逻辑完全不同。

4.1 PRD依赖人的”想象力补全”

PRD的默认假设是：读者是有经验的专业人士。所以文档里只需要写”做什么”，至于”哪些情况不做””异常怎么处理””边界在哪里”，开发会根据常识自己补。

一份PRD写出来，如果开发看完没有任何疑问，要么是需求太简单，要么是开发根本没看懂。正常情况下，PRD评审会的主要内容，就是开发一个个问边界、问异常、问特殊场景——这些都是PRD里没写清楚、需要靠人来补的部分。

这不是产品经理写得不认真，而是PRD这个形态本身的设计就是这样的。它是一份”协作文档”，不是一份”执行说明书”。

4.2 SPEC要求”边界锁死，不留脑补空间”

SPEC的默认假设是：读者是AI，它不会自己脑补。所以所有的边界、所有的异常、所有的约束条件，都必须写死在文档里。什么情况该做什么、什么情况不该做、输入输出分别是什么、错误码怎么定义——全部要明确。

一份合格的SPEC，应该是”读完之后没有任何疑问”的。如果AI读完还有歧义，那就是SPEC写得不合格。

这也带来了一个反直觉的结果：SPEC看起来比PRD”简单”，因为它去掉了大量描述性的内容、背景铺垫、交互页面说明；但实际上它的信息密度更高，因为每一句话都是AI执行需要的硬信息。

4.3 原型的存在方式也变了

传统PRD里，原型是文档的一部分，嵌在各个功能点旁边，用来辅助人理解交互。

SPEC模式下，原型不再内嵌，而是以HTML的形式独立存在，和SPEC文档做关联。因为AI不需要看图片式的原型来理解交互，它直接读HTML结构就能还原页面逻辑。

说穿了，PRD是给人看的”产品说明书”，SPEC是给AI读的”执行契约”。

前者追求的是”让人理解”，所以会加很多解释、铺垫、示意；后者追求的是”让机器精确执行”，所以只保留逻辑、流程、边界，多余的内容全部砍掉。

五、简单聊聊SPEC的起源

很多人以为SPEC是最近才冒出来的新概念，其实它的思想根源很深。

早在上世纪80年代，”契约式设计”（Design by Contract）的思想就已经提出了——软件的每个模块都应该有明确的前置条件、后置条件和不变量，就像法律合同一样，双方按契约执行。

到了2004年前后，这套思想和测试驱动开发（TDD）结合，逐渐形成了”规格先行”的开发理念：先精确描述系统的外部行为，再根据描述来实现和验证。

但真正让Spec Coding火起来的，是2025年AI编程工具的爆发。

2025年下半年到年底，亚马逊云科技、微软GitHub Copilot团队、谷歌DeepMind Codey团队、腾讯云智服等几乎所有大厂，几乎同时遇到了同一个问题：直接让AI写代码效率太低，返工率太高。

然后大家不约而同地找到了同一个解法：先写SPEC，再让AI按SPEC写代码。

这不是某个人的发明，而是工业界在实践中共同趟出来的路径。GitHub在2025年底推出了Spec Kit工具，Thoughtworks也在当年的技术雷达里把Spec-Driven Development列为重点关注的实践方向。

到今天，Spec Coding已经从少数人的探索，变成了AI时代的标准开发工作流之一。

六、我用SPEC的真实体验：一个上午干了五天的活

说回我自己的实践。

6.1 效率提升有多夸张

前段时间我集中试了一次全SPEC模式作业，结果把我自己都惊到了：一个上午，并行处理了5个需求。

这5个需求是什么级别？放在以前，每个需求从梳理到输出完整PRD+原型，我至少要花一整天。开发量换算下来，每个大概是32个开发工时的级别。

放到以前，这5个需求我得整整干一周。

6.2 我是怎么做到的

那天怎么干的？说起来也简单。

因为我之前已经搭建好了所在领域的知识库，接到需求后，我心里先有个方案雏形，然后直接开5个对话窗口，同时跟5个AI会话。每个窗口输出背景、确认方案、让AI生成SPEC文档和HTML原型，我只负责判断方向对不对、结果符不符合预期。

最耗时间的”写文档+画原型”这两步，整个被我砍掉了。

当然成本也不低——一上午烧了50多美金，用的是国外的大模型。但算一下人力成本，这个投入产出比简直是赚翻了。

6.3 省下来的时间用来干什么

更重要的是，当你不再被文档和原型的体力活困住，你会发现你有大量的时间和精力，去思考真正重要的问题：这个需求到底要不要做？有没有更优的解法？业务价值到底有多大？

七、AI正在把产品经理逼回”本质位置”

这也是我想聊的最后一个话题：AI时代，产品经理的价值到底在哪里？

7.1 表达层的能力正在被AI接管

过去很长一段时间，很多产品经理的核心竞争力是”文档写得漂亮””原型画得规范””流程梳理得清楚”。这些都是”表达层”的能力——把需求清晰地表达出来，传递给开发。

但现在，这些能力AI几乎都能做，而且做得比人快、比人规范。

那产品经理会不会被替代？我的判断是：只会写文档画原型的产品经理，大概率会越来越难。但真正的产品经理，价值反而会被放大。

因为AI接走的是”表达层”的工作，而产品经理真正的核心价值，在”判断层”。

7.2 产品经理真正的核心价值在”判断层”

什么是判断层？

——这个需求的本质是什么？用户真正的痛点在哪里？

——哪些场景值得做，哪些看起来热闹但没有价值？

——方案的边界在哪里？什么该做，什么坚决不做？

——怎么快速验证假设，怎么小成本试错落地？

这些事情，AI替不了你。

就像Vibe Coding为什么做不了正经项目？因为你只说”我想做一个小程序”，AI永远不知道你想要的到底是什么。但有了SPEC的约束，一切就都在你的预想中推进。

SPEC是AI的执行契约，但制定契约的人，还是你。

7.3 AI时代产品经理的两个核心特质

所以AI时代的产品经理，核心特质会变成两个：

第一个是好奇。对新工具、新方法的接纳程度，决定了你能把AI用到什么程度。别人还在手写PRD的时候，你已经在用SPEC并行处理5个需求了，这就是数量级的差距。

第二个是专业。对业务场景的深度理解，决定了你判断的质量。AI能帮你执行，但判断什么值得做、什么是对的需求，只能靠你对业务的理解。

表达能力不再是核心壁垒，判断力才是。

八、写在最后

当然，SPEC模式也不是开箱即用的银弹。

要真正发挥它的威力，你还需要配套一些基础设施。比如属于自己的领域知识库——有了知识库，AI生成的SPEC才不会脱离业务实际。还有相关的Skill技能配置、MCP连接等等，这些都是让AI准确理解上下文的关键。

关于怎么梳理和构建自己的领域知识库，我后面会单独写一篇文章分享，这里先留个坑。

还有前面提到的AI时代产研全链路协作方式——需求怎么流转、评审怎么做、测试怎么衔接、上线怎么验证——整个链条都要围绕”AI是执行者”这个新接口重新设计，这个话题也很大，后面再展开聊。

回到今天的主题。

很多人讨论AI对产品经理的影响，总喜欢走两个极端：要么说”产品经理要被淘汰了”，要么说”AI只是工具，核心还是人”。

我觉得都没说到点上。

真正发生的事情是：游戏规则变了。

以前的规则是，谁能把需求表达得更清楚、更规范、更漂亮，谁就是好产品经理。

新的规则是，谁能更快地找到真正有价值的需求、更准地判断方向、更高效地调动AI把事情落地，谁才是好产品经理。

古法写需求没有真的”死”，但它正在快速变成一种低效的旧方式。就像汽车出现之后，马车也没有立刻消失，但你知道，未来已经不属于它了。

接口已经变了。

越早适应新接口的人，越早吃到红利。