AI需求写进PRD常缩水成三句话，导致开发测试靠猜。本文提出将功能改写为任务，并补充六大模块：责任边界、输入契约、输出契约、质量标准、异常降级、反馈闭环，让AI需求真正可开发、可验收、可运营。

很多AI需求在会议里听起来都很完整：做一个智能问答，帮用户快速查制度；做一个内容生成助手，提高运营效率；做一个材料总结功能，让员工不用逐篇阅读。

可一旦写进PRD，内容往往迅速缩水成三句话：用户输入问题，系统调用大模型，页面展示生成结果。接下来，研发会追问知识从哪里来，测试会追问什么样的答案算通过，业务会追问答错了怎么办。产品经理只能再开一轮会，把PRD里没有写清楚的内容口头补上。

这不是因为产品经理不会写需求，而是传统PRD默认系统是确定性的：点击按钮就发生固定动作，输入相同条件就得到相同结果。AI产品却会受到上下文、知识版本、提示方式和模型状态影响，同一个问题可能得到不同表达，结果也很难只用“成功或失败”判断。

AI PRD真正要定义的，不是模型要说什么，而是AI在什么任务中承担哪一段责任，什么结果可以被接受，失败后谁来接管。

一、传统PRD为什么容易漏掉AI需求的关键部分

传统功能通常可以沿着“入口—操作—结果”来描述。比如用户点击导出，系统生成文件；用户提交表单，系统校验字段并更新状态。只要流程、字段和异常码写清楚，研发和测试就能形成相对一致的理解。

AI功能多了四种不确定性。

第一，用户输入不一定完整，系统可能需要追问；

第二，输出通常不是唯一答案，而是存在“可用程度”；

第三，结果质量依赖知识和上下文；

第四，模型可能生成看起来合理、事实上错误的内容。

如果PRD仍然只写页面和接口，团队就会把关键判断留到开发阶段临时决定。

最后常见的结果是：

• Demo能跑，真实数据进来后问题不断；
• 测试只能凭个人感觉判断；
• 上线后出现Bad Case，却不知道该改提示词、补知识、加规则，还是重新设计流程。

二、写AI需求前，先把“功能”改写成“任务”

许多PRD从“做一个AI助手”开始，这会让团队过早讨论入口、对话框和模型选型。更有效的起点，是先完成一句任务定义：谁在什么情况下，基于哪些信息，要完成什么工作，当前主要成本是什么，AI需要帮助到哪一步。

例如，“做一个智能总结”并不是任务。更清楚的写法是：客服主管每天抽查一批服务记录，需要识别用户主要问题、处理结论和待跟进事项，目前要逐条阅读；系统应从完整记录中生成结构化摘要，并标出原文依据，主管确认后再进入后续处理。

这句话已经带出了用户、触发条件、输入、输出、人工确认和后续动作。产品经理也更容易判断：模型负责归纳与生成，程序负责字段校验，用户负责最终确认。

判断需求是否写清楚，可以先问一句：如果去掉“AI、智能、大模型”三个词，团队是否仍然知道用户要完成什么工作。

三、AI PRD必须补上的六个模块

模块一：任务目标与责任边界

首先写清楚AI负责什么、不负责什么。是提供草稿、给出建议、完成结构化抽取，还是可以直接执行动作？哪些判断必须由规则完成，哪些结果必须由用户确认？

边界最好写成可执行的句子。例如：AI可以生成回复草稿，但不得自动发送；可以建议分类，但不得绕过权限修改正式数据；可以引用内部制度回答，但无可靠来源时必须明确说不知道。

模块二：输入与上下文契约

模型能看到什么，往往比模型本身更影响结果。PRD需要列出输入来源、字段解释、时间范围、权限范围和缺失处理。上下文可能来自用户输入、当前页面、历史记录、知识库和业务系统，不能笼统写成“获取相关信息”。

还要明确优先级：实时数据与历史材料冲突时以谁为准？缺少关键字段时继续生成、向用户追问，还是停止任务？如果输入超过长度限制，系统如何筛选、摘要或分批处理？

模块三：输出契约

不要只写“生成一段结果”。输出契约至少要定义结构、必填信息、禁止内容、证据形式、可编辑范围和后续去向。对于要进入业务流程的内容，结构化字段通常比一整段自然语言更容易验证和复用。

例如，服务记录总结可以固定为“问题类型、关键事实、处理结论、待办事项、原文依据”五部分；其中关键事实和结论必须可定位到原始记录，待办事项允许人工修改后再提交。

模块四：质量标准与验收样本

“准确”“自然”“符合业务要求”都不是可直接测试的标准。产品经理要把质量拆成维度：事实是否正确、关键信息是否完整、格式是否合规、表达是否适合、来源是否可靠、结果是否足以支持下一步。

同时准备一组代表真实分布的样本，包括常见情况、信息缺失、口径冲突、超长输入、边界问题和明确不能回答的内容。每个样本不一定只有一份标准答案，但必须有可接受条件和不可接受条件。

模块五：异常、降级与人工接管

AI产品的异常不只有接口报错。没有检索到依据、多个来源互相冲突、输出置信度低、模型拒答、工具调用失败、结果触发高风险规则，都应该在PRD里有对应策略。

降级也不是统一提示“系统繁忙”。有些情况可以只生成草稿，有些可以返回原始资料，有些需要保留已完成步骤并转人工。接管时还要携带输入、AI已做动作、失败原因和可继续位置，避免用户重新开始。

模块六：反馈与版本闭环

AI产品很难在第一版就固定下来。PRD需要提前设计用户如何采纳、修改、拒绝和反馈，而不是上线后再加一个模糊的点赞按钮。

更有价值的反馈包括：哪些字段被修改、用户为什么拒绝、最终采用了什么内容、任务是否顺利完成。每条结果还应能关联模型版本、提示版本、知识版本和规则版本，这样团队才能复现问题并判断改动是否有效。

四、把一句“智能总结”改写成可开发的需求

假设最初的需求只有一句：系统支持对一段服务记录进行智能总结。把它改写成AI PRD后，可以形成下面这组最小定义。

• 任务目标：帮助主管快速识别主要问题、处理结果和待跟进事项，减少逐条阅读时间；
• 输入范围：当前用户有权限查看的完整记录、用户基本标签和适用的处理口径；
• 输出结构：问题类型、关键事实、处理结论、待办事项、原文依据；
• 确定性规则：必填字段、敏感信息遮蔽、分类枚举和权限校验由程序执行；
• 人工确认：结果默认处于草稿状态，确认后才可保存并触发后续任务；
• 异常策略：材料不完整时标记缺失项；来源冲突时展示冲突内容；无法判断时转人工；
• 验收标准：关键事实不得凭空生成，核心字段完整率达到门槛，用户修改和拒绝原因可记录。

这份需求仍然没有规定模型必须逐字输出什么，却已经足够让研发设计上下文、让测试建立样本、让交互设计确认编辑方式，也让业务知道自己的复核责任。

五、需求评审时，产品经理要追问的十个问题

1. 用户最终要完成的是一个回答，还是一个业务任务？
2. AI负责建议、草拟、判断还是执行，责任到哪一步为止？
3. 输入信息从哪里来，是否完整、最新且符合权限？
4. 哪些确定性条件必须由规则或程序保证？
5. 输出是否需要结构化、引用来源或支持人工编辑？
6. 什么叫可用，谁来评价，最低门槛是多少？
7. 无依据、冲突、低置信度和工具失败时分别怎么办？
8. 高风险结果在哪个节点必须人工确认？
9. 上线后如何记录采纳、修改、拒绝和最终结果？
10. 模型、知识、提示和规则变化后，如何回归测试？

如果其中一半问题没有答案，通常不适合立刻进入完整开发。团队可以先用脱敏样本做验证，补齐任务定义和验收标准，再决定是否产品化。

六、AI PRD不是产品经理一个人的文档

AI需求的不确定性更高，PRD也更需要共同完成。业务负责人应提供真实样本、优秀结果和风险边界；算法或研发负责说明模型、检索和工具的可实现范围；测试参与设计样本集与边界用例；运营负责定义反馈标签和问题处理机制。

产品经理的职责不是替所有角色写答案，而是把这些答案组织成一个一致的任务系统：输入能否获得，输出能否验证，异常能否接管，反馈能否推动下一次迭代。

结语：AI PRD管理的是不确定性

传统PRD更像一份功能施工图，AI PRD则多了一层责任：管理结果的不确定性。它既不能把模型写成永远正确的规则引擎，也不能用“AI有概率出错”来回避产品设计。

当任务边界、上下文、输出契约、质量标准、异常策略和反馈闭环被写清楚，AI需求才真正具备可开发、可验收和可运营的基础。

产品经理最终交付的，不是一句聪明的提示词，也不只是一个聊天框，而是一套让AI在明确边界内稳定帮助用户完成工作的产品机制。