产品经理的交付物，还要不要是一份文档？

每次评审会，研发对着原型逐条过，PRD打开着没人翻——你注意过吗？

这不是吐槽，这是一个值得追问的信号。

研发怎么看PRD

我试过站在研发的角度想这件事。如果我是开发，PRD在我眼里大概是这样的：

开发前

我先看原型。PRD太长了，我扫一眼背景和目标，细节等评审会上听PM讲。真有疑问，我直接问人，比翻文档快。

开发中

我写代码遇到边界情况，想查PRD——但文档里写的往往是正常流程，我卡住的恰恰是异常分支。而且PRD里的描述是自然语言，"当用户完成操作后跳转到结果页"——完成什么操作？跳转到哪个结果页？什么条件下跳？我还是得去找PM确认。所以与其翻文档，不如直接问。

开发后

上线了，出bug了，我想回看"当时怎么定的"——但PRD可能已经改了好几版，我也分不清哪个版本对应线上逻辑。文档里写的和实际代码之间，早就对不上了。

三个阶段，三种失望。开发前不看，开发中查不到，开发后信不过。

但这里有个更值得追问的问题：

PRD名义上是给研发看的，但研发其实不看——那它是给谁看的？

如果它的消费者都不在消费它，它到底在服务于什么？

PRD的三个"假功能"

既然研发视角已经暴露了问题，那不妨拆开来看——PRD到底承担了哪些功能？这些功能是不是真的在起作用？

第一个功能：开发参考。

PRD名义上是指导开发的。但实际上，研发看的是原型，PRD只是补充。评审会上大家对着原型逐条过，PRD里的文字描述，更多是原型上放不下的备注。换句话说，PRD在开发环节的角色，是原型的"脚注"——有它不嫌多，没它也能过。

一个"补充"性质的东西，占着PM最大的交付精力，这本身就不太对。

第二个功能：事后档案。

PRD的另一个作用是"回看规则"。上线之后出了问题，翻PRD看当时怎么定的。

但现实是：需求变了之后，你回去更新PRD了吗？大多数时候不会。改需求是在群里说一嘴、在评审会上改个原型、在代码里直接调了。PRD还停留在上一版——一个过时的档案，比没有档案更危险，因为它会误导。

所以"事后档案"这个功能，名义上有，实际上撑不住。它是一个静态的快照，而需求是动态的。

第三个功能：协作对齐。

PRD还有一个隐含的功能：让所有人"在同一页上"。写下来，对齐认知，避免理解偏差。

但真正对齐靠的是什么？是评审会上的口头沟通，是开发中遇到问题直接@PM问，是上线前走查时对着原型逐条确认。文档写下来那一刻，对齐就完成了——但之后需求一变，文档没跟上，"对齐"就又散了。PRD作为对齐工具，它的有效期大概就是评审会结束的那一瞬间。

三个功能，拆开看都是同一个问题：名义上有，实际没人用。

开发参考靠原型，事后档案会过时，协作对齐靠口头。

那追问就来了：如果PRD的三个功能都是假功能，PM花最多时间写的这个东西，到底在服务于谁？

一个可能的答案是：它服务于流程。公司需要一份文档来证明"需求经过了定义"，团队需要一个东西来"签收"。PRD的存在，更多是流程的凭证，而不是研发的工具。

但这就更不对了——如果PM的核心交付物只是在服务流程，而不是在服务产品本身，那这个交付物是不是该重新想想了？

不是写不好，是容器有问题

说到这里，一个自然的反应是：那是不是PRD写得不够好？是不是PM把需求写得更清晰、更完整、更结构化，问题就解决了？

我试过。把边界条件补全，把异常分支写清楚，把交互逻辑用表格列出来——写完之后，确实更"完整"了。但研发还是不看。不是因为他们懒，是因为即使写得再好，从一篇几千字的文档里找到自己要的那条规则，成本还是太高了。

这让我意识到，问题可能不在"写得好不好"，而在更底层的地方。

PRD是一个"文档"。文档这个形态，预设了一种消费方式——读。写的人假设：你会从头到尾读一遍，或者至少知道该去哪一节找答案。

但研发的真实消费方式不是"读"。开发中遇到一个边界问题，我需要的不是"读完整篇PRD然后自己找到答案"，而是"我有一个具体的问题，给我一个确定的回答"。这是问，不是读。

"读"和"问"的区别，比想象中大得多：

读是线性的

你得顺着作者的逻辑走，从背景读到需求，从正常流程读到异常处理。但研发遇到问题时，他不需要你的逻辑，他需要他的答案。

读是模糊的

自然语言天然有歧义——"当用户完成操作后跳转"，什么叫"完成"？什么条件下跳？读完之后还是不确定，还是得问人。

读是静态的

文档写完就固定了，但需求在变。你读到的可能是过时的信息，而你不知道它已经过时了。

所以PRD的问题，不是PM写得不够好，而是"文档"这个容器本身预设了错误的消费方式。你用"读"的形态去服务"问"的需求，就像用一本书去回答搜索引擎的查询——信息都在里面，但拿不出来。

那如果消费方式是"问"，PM的交付应该是什么形态？

从"写一篇完整的文章"到"构建可查询的知识结构"

回到那个问题：PM到底在交付什么？

如果承认研发的消费方式是"问"而不是"读"，那PM交付的就不应该是一篇"完整的文章"——因为文章是用来读的。PM交付的，本质上是一组可被消费的知识单元。

什么意思？

写PRD的时候，PM脑子里想的是：背景是什么、目标是什么、用户故事有哪些、正常流程怎么走、异常怎么处理、规则是什么。这些信息被组织成一篇文档，有章节、有层级、有前后文。

但研发真正消费的，不是这篇文档的"叙事"，而是里面散落的一个个具体的判断：这个字段校验规则是什么？这个状态下按钮能不能点？超时之后怎么处理？

这些判断，才是知识单元。它们本来就不需要被串成一篇文章，就像API文档不需要从头读到尾——你查你要的那个接口，拿到参数和返回值，然后关掉。

所以，PM的交付逻辑应该从"写一篇完整的文章"变成"构建一个可查询的知识结构"。这不是形态升级——把Word换成Notion不算——而是交付逻辑的根本重构：

从"我写你读"到"你问我答"。

写文章的逻辑是：我要把所有信息组织成一个连贯的叙事，让你跟着我的思路走。构建知识结构的逻辑是：我要把信息拆解成独立的、可定位的单元，让你在需要的时候能精准找到。

这两件事对PM能力的要求完全不同。写文章需要的是表达力——把事情说清楚、说完整、说得有逻辑。构建知识结构需要的是架构力——把复杂的需求拆解成原子化的规则，定义它们之间的关系，确保没有遗漏和矛盾。

举个简短的例子。同样是"用户登录"这个需求：

PRD的写法

一段叙述——"用户在登录页输入手机号和验证码，点击登录按钮。如果验证码正确，跳转到首页；如果验证码错误，提示'验证码有误'；如果验证码超时，提示'验证码已过期，请重新获取'。手机号格式不正确时，登录按钮置灰……"——信息都在，但混在一起，遇到问题你得通读一遍再自己定位。

知识结构的写法

拆成可独立查询的规则单元——字段校验规则3条、状态流转规则2条、异常处理规则4条。每条规则有触发条件、处理逻辑、关联规则。研发遇到"验证码超时怎么处理"，直接查到异常处理规则第3条，不需要翻完整篇文档。

这不是文笔问题，是架构问题。

那下一个追问就是：如果PM应该交付的是可查询的知识结构，这件事为什么一直没有发生？

AI不是原因，但让它第一次有了可能

答案很朴素：因为以前做不到。

把需求拆解成原子化的知识单元，定义它们之间的关系，让研发能精准查询——这件事的难点不在于"想不想"，而在于"怎么做"。在没有AI的年代，你要实现"可查询的知识结构"，要么自己搭一套规则引擎（成本极高，而且PM不具备这个能力），要么维护一个结构化的知识库（每次需求变更都要手动更新，维护成本比写PRD还高）。

所以PRD作为文档能活到今天，不是因为它好，而是因为替代方案更不现实。它是一个"局部最优解"——在给定的技术条件下，写一篇文档已经是性价比最高的选择了。

但AI改变了这件事的可行性边界。

当PM把需求拆解成结构化的知识单元之后，AI可以做到两件以前做不到的事：

第一，理解自然语言的查询。

研发直接问"验证码超时了怎么处理"，AI能理解意图，定位到对应的规则单元，给出确定的回答。这意味着什么？意味着研发不需要学会PM的语言体系——不用知道这条规则被归在"异常处理"还是"状态流转"下面；PM也不需要学会某种查询语法——不用把规则写成可检索的格式。中间的翻译层被AI吃掉了。

第二，保持和实现的一致性——但这是最难的部分。

理想状态是：PM更新一个知识单元，AI基于更新后的结构回答问题，永远指向最新版本。但现实没那么简单。需求变更时，改了A规则，B规则可能也要跟着改——登录规则变了，权限规则是不是也要调？AI能不能自动检测这些关联和矛盾？

坦白说，目前还做不到完全自动。但这恰恰是值得追问的方向：不是AI已经解决了这个问题，而是AI让这个问题第一次可以被系统地面对了。以前连"发现矛盾"都靠人肉，现在至少有了自动检测关联的可能性。

但这里要特别说清楚：这个变化不是AI带来的。PM早就该意识到"文档"这个容器有问题，早就该追问"研发到底怎么消费我的交付物"。AI没有创造这个需求，它只是让这个需求的满足第一次有了可行的实现路径。

换句话说，AI是加速器，不是原因。原因是PRD作为文档，本身就扛不住它被赋予的那些功能。

那回到PM自身，这意味着什么？

PM的核心能力，要从"写清楚"变成"结构化"。

"写清楚"是表达力——把复杂的需求用自然语言描述得清晰、完整、没有歧义。这个能力依然重要，但它不再是交付的核心。因为再清晰的描述，在"问"的消费方式下，都不如一个精准的定位来得有用。

"结构化"是架构力——把复杂的需求拆解成原子化的规则，定义它们之间的关系，确保没有遗漏和矛盾。这才是"可查询的知识结构"的底座。

不是每个PM都要变成工程师，但每个PM都需要学会像架构师一样思考：不是"我怎么把这件事说清楚"，而是"我怎么让这件事能被精准地找到和使用"。

而当交付物从"文档"变成"知识结构"，它服务的对象也变了——从服务于流程的签收凭证，变成了服务于产品本身的可查询底座。第二章追问的那个问题——"PRD到底在服务于谁"——到这里有了回答：

它应该服务于产品，而不是服务于流程。

PRD为什么还是文档？因为以前没有更好的选择。但"以前没有"不等于"以后也不该有"。

当你意识到问题不在内容而在容器，不在表达而在结构，不在流程而在产品——一个早就该来的变化，也许就可以开始了。