前言 #
最近在负责一个 Agent 产品，PRD 写到一半的时候我意识到一件事：以前那套写法，用在 Agent 上有点像拿螺丝刀拧钉子，不是完全不行，但就是使不上劲。功能列表、页面结构、交互流程这些老朋友依然在列，但 Agent 真正需要定义的东西，它们覆盖不到。
于是我把整份 PRD 推倒重写了一遍，把思路从「描述功能」切换到「描述决策」。这篇文章聊聊我为什么要换写法，以及换完之后的结构是什么样的。
传统 PRD 的盲区 #
传统 PRD 的底层假设是系统行为可预期，你定义好每个状态的流转路径就行了。这套方法在确定性的产品里很好使，但 Agent 产品天生带着不确定性：同样的用户输入，在不同上下文下可能对应完全不同的处理路径。
传统 PRD 在面对 Agent 时有几个明显的盲区：
意图理解没有定义。 传统产品里用户通过按钮、菜单、表单来表达意图，意图是显式的。Agent 产品里用户说的是自然语言，意图是隐式的1。「帮我查一下上个月的数据」可能是想看总览，可能是想对比环比，也可能是要导出给老板。如果不把意图空间先拆清楚，后面的设计就是空中楼阁。
工具调用的判断条件缺失。 很多 Agent PRD 会列一串工具能力：「支持知识库检索、支持搜索、支持调用工单系统。」但真正决定体验的是这些工具在什么条件下该调、按什么顺序调、调失败了怎么办2。工具调用本身就是一个产品决策，不能丢给研发自己去判断。
边界条件被当成异常处理。 传统产品里异常处理是兜底，放在文档最后补一段就行。但 Agent 产品里，信息不足、工具失败、数据冲突、幻觉风险这些情况不是小概率事件，而是每天都在发生的主流程的一部分3。把它们放到「异常处理」的框架下去写，本身就是一种误判。
换个思路：从决策流开始写 #
意识到这些问题之后，我把 PRD 的起点从「功能模块」换成了「决策流」。
核心思路是这样的：用户说了一句话之后，系统先判断意图是否清晰，不清晰就追问；清晰之后判断需不需要调工具；调完工具之后判断是不是高风险动作，是的话必须让用户确认。整条链路就是一系列判断节点。
我用 Mermaid4 画了一下这个逻辑：
graph TD
A([用户输入]) --> B{是否识别清晰意图}
B -- 否 --> C[追问补充信息]
B -- 是 --> D{是否需要外部工具}
D -- 否 --> E[直接生成结果]
D -- 是 --> F[调用知识库/搜索/业务系统]
F --> G{是否高风险动作}
G -- 是 --> H[请求用户确认]
G -- 否 --> I[执行并返回结果]
这不是一个放之四海皆准的模板，不同业务场景肯定要调整分支和判断条件。但它给了 PRD 一个骨架：每个菱形节点都是一个需要明确定义的判断规则，每个矩形节点都是一个需要写清楚的行为描述。
我怎么写意图拆解 #
意图拆解我一般用结构表来写，不是简单列几个意图名称就完事。每个意图至少要覆盖这些字段：意图名称、典型表达、真实目标、优先级、是否允许自动执行、是否需要二次确认。
举个实际例子。同样是「我无法登录」，背后至少有四种意图：忘记密码、账号被锁、新员工未开通、SSO 配置异常。这四种意图对应的处理路径完全不同。如果 PRD 只写一句「系统自动识别问题类别并创建工单」，研发在实现的时候只能靠猜。
拆完意图之后还有一件事很重要：信息不足时怎么办。用户可能一句话说了两个诉求，也可能关键信息完全没给。这时候是追问一轮直接给答案，还是追问到底？追问两轮还是不够信息，是降级回答还是报错？这些规则要提前定死，不能留到线上再调。
我怎么写工具调用 #
工具调用我不会写成能力清单，而是写成条件判断：
- 用户的问题是否涉及内部数据？涉及的话先查知识库，不涉及的话直接回答
- 知识库返回的结果是否足够回答用户的问题？不够的话再调搜索补全
- 是否涉及写操作（创建、修改、删除）？涉及的话必须经过用户确认
- 工具调用超时或返回异常，系统是降级回答、报错、还是保存草稿等用户重试
- 多个工具返回的结果互相矛盾，优先信哪个数据源
这里面每一个条件都是一个产品决策。写得越明确，研发实现的时候偏离就越小，上线后扯皮也越少。
每多调一个工具，就多一层延迟、多一个失败点。所以工具不是越多越好，能不调就不调。一句话能答明白的事情，非要绕三个工具再总结一遍，体验只会更差。
我怎么写边界条件 #
边界条件我现在的做法是和主流程同等对待，不是放在文档最后的补充章节，而是嵌入到每个判断节点里。
具体来说，我会关注几类：
- 信息不足：追问策略是什么，追问几轮后怎么收束
- 工具失败：每个工具挂了之后的降级方案
- 高风险动作：哪些操作必须确认、哪些可以自动执行、哪些永远不能自动执行
- 数据冲突：多个信息源结果矛盾时信谁的，还是展示给用户自己判断
- 幻觉控制：模型在没有充分依据时能不能生成内容，不能的话怎么告知用户
这些规则看起来枯燥，但它们才是 Agent 产品「可控」和「失控」的分界线。
完整的 PRD 结构 #
踩完一轮之后，我现在的 Agent PRD 大致按这个结构来写：
场景定义：为什么这个场景需要 Agent 而不是传统功能？如果一件事规则极稳定、输入极结构化、不需要多轮判断，其实不一定要上 Agent3。这一段可以过滤掉不少伪需求。
意图拆解：结构表，把每个场景下可能的意图、触发条件、优先级、处理方式列出来。
决策路径：就是上面那张 Mermaid 图展开的内容，每个判断节点要写清楚判断条件和分支走向。
工具调用规则：触发条件、禁止条件、调用顺序、失败降级。
边界条件：和主流程同等重要，嵌入到每个节点而不是单独成章。
结果定义：什么叫完成、什么叫部分完成、什么叫失败但有可用中间结果。
评估指标：意图识别准确率、工具调用成功率、任务完成率、人工接管率、结果采纳率，不能只看 DAU。
写在最后 #
回头看，传统 PRD 和 Agent PRD 最根本的区别在于：传统 PRD 描述的是系统在不同状态下的表现，Agent PRD 描述的是系统在不同判断下的行为。一个是静态的页面和流程，一个是动态的意图和决策。
想通这件事之后，写法自然就变了。如果你也在做 Agent 产品，不妨拿自己的 PRD 检查一下：意图拆清楚了吗？工具调用的判断条件写了吗？边界条件覆盖全了吗？如果有一个答不上来，问题大概不在文档，而在产品设计本身还没想透。