夜雨聆风最近我在用Claude Code做一个功能，大概花了半天就跑通了。
然后我把这件事告诉了我们的产品，他说，那太好了，那这个需求你下周能上线吗？
我说，等等，我还没看完PRD呢。
他发给我的那份文档，洋洋洒洒写了二十多页，但我翻了半天，找不到一个关键问题的答案，用户在这个状态下，系统应该怎么处理？
文档里写的是，合理处理。
合理处理。。。
我当时就愣住了。
不是说产品不认真，他确实写了二十多页。问题是，这二十多页是写给人看的，不是写给AI执行的。
以前这没什么问题。以前我拿到一份模糊的PRD，我会去找产品聊，聊完我大概知道他想要什么，然后我自己脑补剩下的细节，写出来，再对一遍，改几轮，上线。
这个流程很慢，但它能跑通，因为中间有大量的人肉翻译在兜底。
但现在不一样了。
现在我有Claude Code，有Cursor，有一堆AI编程工具。我把需求描述清楚，AI能帮我把代码写出来，速度快到离谱。
问题是，AI没有「人肉翻译」这个能力。
我告诉Claude Code「合理处理」，它会猜。它的猜测基于互联网上的平均水准，不是基于我们产品的业务逻辑。猜出来的东西，我还得花时间改，改完还得跟产品对，对完发现理解偏了，再改。
所以你会看到一个很荒诞的现象，产品用AI写PRD，效率提升了。开发用AI写代码，效率也提升了。但整个项目的交付速度，几乎没变。
为什么？
因为中间那层「翻译」，还是靠人肉在扛。
我跟几个做开发的朋友聊过这个问题，大家的感受都差不多。
有个朋友在一家中型互联网公司，他说，我们现在的状态是，产品用AI生成PRD，我用Cursor写代码，但我们之间的沟通成本，比以前还高了。
我问他为什么。
他说，因为AI生成的PRD，看起来很完整，但里面有很多细节是AI自己填的，不是产品真正想清楚的。我拿到这份文档，以为产品想清楚了，结果开始写代码才发现，很多地方根本没有定论。
然后我去找产品确认，产品说，这个我也不确定，你觉得怎么合理怎么来吧。
你敢信？？？
我觉得他说的这个现象，很有代表性。AI让「写文档」这件事变得很容易，但「想清楚需求」这件事，AI帮不了你。
文档的体积变大了，但里面真正有效的信息密度，反而降低了。
说到这个，我想聊一个概念，PRD和Spec的区别。
这两个词，做产品的人可能更熟悉，但我觉得做开发的人也应该理解，因为这个区别，直接影响你跟产品的协作效率。
PRD，产品需求文档，是写给人看的。人有上下文推理能力，当遇到模糊描述时，技术会联系评审会上讨论的逻辑、设计稿里的标注，自己把模糊还原成完整规则。
Spec，规格说明书，是写给AI执行的。AI没有这个能力。它的「常识」是互联网平均水准，不是你的项目要求。你每留一个模糊点，它就猜一次。
你想想看，这两种文档，对AI来说，差别有多大。
我给Claude Code一份PRD，里面写着「用户体验要好」，它会猜。它猜出来的「好」，可能跟产品想的「好」完全不一样。
但如果我给它一份Spec，里面写着「输入错误密码后，按钮下方显示红色文字『邮箱或密码错误』，按钮恢复可点击状态，3秒后错误提示消失」，它能干得很漂亮。
这就是为什么，AI时代，Spec比PRD更重要。
但这里有一个很现实的问题，写Spec很费脑子。
把「用户体验要好」翻译成那一串具体的描述，需要产品真的把每一个细节都想清楚。
以前这些细节可以留给开发去脑补，因为开发有经验，知道「体验好」大概是什么意思。
但现在，如果你想让AI帮你执行，你就得把这些细节写出来。不写，AI就猜。猜出来的东西，你不一定满意。
这对产品来说是一个很大的思维转变，从「写给人看的文档」到「写给AI执行的合同」。
我理解这个转变很难。
因为很多时候，需求写不清楚，不是因为懒，是因为还没想清楚。
Spec的格式会暴露这个问题。你写不出验收标准，说明你自己都不知道做出来应该是什么样子。
这个暴露，短期内很痛苦，但长期来看，是好事。
回到协作这块，我觉得AI时代，产品和开发的协作模式，应该是这样的。
PRD负责对齐方向，回答「为什么做这个，做成什么样，为什么这样不那样」。这部分不需要很长，但必须想清楚。
然后按功能点，把每个需求转化成Spec格式，回答「具体怎么做，边界在哪，怎么验收」。这部分是给AI执行用的，必须精确。
AI按Spec执行，最后对照Spec验收。
听起来很简单，但这中间有一个关键动作，「把PRD转成Spec」，这件事现在大多数团队都没有在做。
为什么没有在做？
因为这个动作，需要产品和开发一起坐下来，把每一个功能点的细节都过一遍。这很费时间，也很费脑子。
但我觉得这个时间是值得花的。
因为后面AI执行的时候，猜测的空间小了，返工的概率低了，整体反而快了。
顺着上面的再聊聊，AI时代，产品经理这个角色，到底在往哪个方向进化？
我观察到两种趋势。
一种是「技术型产品」，懂技术，能写Spec，能直接跟AI协作，甚至能自己用Claude Code把原型跑出来。这种产品，跟开发的协作效率极高，因为他们说的话，AI能直接听懂。
另一种是「判断型产品」，不一定懂技术细节，但极其擅长判断，知道什么该做什么不该做，能在模糊中找到方向，能在选项爆炸的时候快速收敛。
这两种都有价值，但我觉得第二种在AI时代反而更稀缺。
因为执行这件事，AI越来越能干。但判断这件事，AI还差得远。
「这个功能用户真的需要吗」「这个方向三个月后还对吗」「这个决策背后的假设是什么」，这些问题，AI给不了答案。
能回答这些问题的人，才是AI时代真正的稀缺资源。
开发这边也在变。
以前开发的核心价值是「能把代码写出来」，现在这件事AI越来越能替代。
开发的新价值，我觉得在两个地方。
一个是「能把需求翻译成AI能执行的Spec」，这需要既懂业务又懂技术，是一个很难被替代的能力。
另一个是「能判断AI写出来的代码对不对」，不只是跑通，而是真的符合业务逻辑，没有安全漏洞，可以维护。
这两件事，都需要你真的理解业务，不只是会写代码。
说实话，这对很多只关注技术深度、不太关心业务的开发来说，是一个挑战。
但我觉得这个方向是对的。
AI时代，最有价值的开发，不是写代码最快的那个，而是最懂业务、最能跟产品对齐的那个。
说实话，我自己也还在摸索这套新的协作方式，可能有些想法还不成熟。
我现在跟产品协作的方式变了，我不再等着拿到一份完整的PRD然后开始写代码。
我们会先花一两个小时，把核心功能点的Spec一起写出来，把验收标准定清楚，把边界条件列出来。
这个过程很痛苦，因为会暴露很多「还没想清楚」的地方。
但这个痛苦是值得的。
因为后面AI执行的时候，猜测的空间小了，返工的概率低了，整体反而快了。
大时代啊，朋友们。
工具在变，流程在变，角色在变。
但有一件事没变，真正想清楚「做什么」，永远比「怎么做」更难，也更值钱。
AI让「怎么做」变得越来越便宜，但同时也让「做什么」的判断越来越贵。
这对那些只会执行的人来说，确实残酷。
但对那些真的懂用户、懂业务、能在模糊中找到方向的人，不管是产品还是开发，这是最好的时代。
回到开头那个「合理处理」，我后来跟产品聊了一个小时，把那个场景的每一种情况都过了一遍，写成了一份Spec。
Claude Code拿到这份Spec，一次就写对了。
文末给大家两个实用的工具，都是可以直接用的Prompt模板。
1. PRD生成器
如果你们团队还在用传统PRD，可以试试这个模板。我最近在用它生成PRD，效果还不错。
核心思路是，把原始素材（会议纪要、UI设计稿、竞品截图）转化成结构化的PRD文档。重点是四层信息提取，业务背景、核心规则、系统边界、待确认项，这四层信息提取清楚了，PRD基本就能写出来。
具体怎么用呢，你把会议记录、设计稿、讨论内容丢给AI，告诉它按这个框架生成PRD，它会逐节填充。关键是要让AI区分「已确定」和「待确认」，不能让它自己发明逻辑。
模板我放在这里了，你可以根据自己团队的PRD格式调整：
你是一个PRD写作助手。根据我提供的原始素材（会议纪要、UI设计稿、讨论记录等），帮我生成一份完整的PRD文档。## 信息提取原则读完所有素材后，提取四层信息：- 业务背景：为什么做？当前有什么问题？- 核心规则：关键业务逻辑、计算公式、判断条件- 系统边界：本期做什么、明确不做什么- 待确认项：素材中没有定论的内容，标注"待XX确认"## PRD结构### 需求背景- 问题现状：用户/业务侧痛点、系统侧缺失、竞品对比- 需求目标：要解决什么问题、期望效果、数据指标### 需求概述- 需求点拆分：按优先级（P0/P1/P2）拆分，区分前端/服务端/后台- 流程图：用文字流程图描述核心业务逻辑### 需求详情每个需求点单独描述，按受众分层：- 后台/运营需求：配置项字段、类型、说明、联动关系- 服务端需求：校验逻辑、计算公式、状态处理、异常处理- 前端需求：页面逐元素描述，展示条件、数据来源、交互行为## 关键原则- 所有信息来自素材，不自行发明逻辑- 遇到素材中没有定论的事项，写"待XX确认"- 受众分层描述，不混写2. PRD拆分器（PRD → 精简版 + Spec）
如果你想尝试写Spec，可以先用这个工具把现有的PRD拆分一下，看看效果。
核心思路是，把一份完整PRD拆成两份文档。PRD精简版保留「为什么做、做什么、谁来决策」，面向团队对齐。Spec提取「怎么做、边界在哪、怎么验收」，面向AI执行。
最关键的是验收标准的转化，把PRD里模糊的描述变成可操作的检查项。比如「登录成功后跳转」要转化成「输入正确邮箱密码点击登录，3秒内跳转到 /dashboard」。
模板在这里：
你是一个PRD拆分助手。接收一份完整PRD，拆分为两份文档：## 1. PRD精简版（面向团队对齐）保留以下内容：- 背景与目标：为什么做，目标指标- 范围决策：做什么、不做什么- 关键决策记录：重要决策及原因- 待确认事项：原PRD中模糊或未明确的内容## 2. Spec（面向AI执行）每个独立功能点生成一份Spec，包含六个字段：**目标（Goal）**- 格式：谁 + 怎么做 + 达成什么- 不写"做一个xx功能"，写具体的用户行为和结果**边界（Scope）**- 本次包含什么、不包含什么- 明确写"本次不包含"，防止AI过度实现**输入输出（I/O）**- 字段级别精度：字段名、类型、长度、必填、校验规则- 输出覆盖所有状态：成功/失败/异常/空状态**约束（Constraints）**- 技术约束：框架、组件库、接口规范- 安全约束：数据存储、权限控制- 设计约束：对应设计稿位置**验收标准（Acceptance Criteria）**- 每条都必须能用"打开页面/调接口"来验证- 不允许出现"体验良好""显示正确"这类模糊词- 转化示例： - PRD："登录成功后跳转" - Spec："✅ 输入正确邮箱密码点击登录，3秒内跳转到 /dashboard"**非目标（Non-Goals）**- 容易被误解为"应该有"但本次不做的功能- 防止AI顺手加功能## 转化原则- PRD里每一条功能描述，至少对应一条验收标准- 模糊描述必须转化为可验证的具体标准- 待确认项在两份文档中都要标注，不能自行填答案这两个工具我自己在用，你可以根据实际情况调整。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们，下次再见。
