PRD实战：AI订单履约助手V1.0（含范围合同）

AI PM 实战 · PRD 十节骨架 · 范围合同 · 验收口径 · 兜底预案

一句话价值：把前八篇的方法落成一份真实 PRD——用贯穿全系列的「AI 订单履约助手」走一遍：Problem Statement、范围一页纸、用户故事、验收口径、兜底预案，给你一份能直接抄的骨架。 

给管理者的三句话：① AI 项目的 PRD 和传统 PRD 的区别就两处：验收口径写"统计方式"、风险写"兜底预案"；② 范围合同（一页纸）比 PRD 正文更重要——它管变更，PRD 管实现；③ 交付物清单比功能列表更能保护团队：写清"交什么、不交什么"，扯皮时拿得出证据。 

开篇：方法都会了，文档长什么样

从第 ① 篇到第 ⑧ 篇，我们从"会做 Agent 不等于做好 AI 产品"一路讲到 Non-goal 和停止条件。方法都过完了，这篇落地：拿贯穿全系列的「AI 订单履约助手」项目，把八篇的方法组装成一份真实 PRD。

先说这个项目的背景（简化版）：某零售企业，订单履约涉及仓储、物流、客服三个环节。客服每天接到大量"我的订单到哪了""能不能改地址"的咨询，需要翻三个系统才能回答，单均 4 分钟。业务方要"智能工单"，我们用第 ⑥ 篇的清单挡掉了 Agent 方案，用第 ⑦ 篇的方法写清了 Problem Statement，用第 ⑧ 篇的方法圈定了 V1.0 范围。

现在的问题是：这些判断怎么变成一份开发团队能照着做、客户方能照着验收的文档？多数 PM 的 PRD 只有功能列表和原型图——这在 AI 项目里不够，缺了验收口径和兜底预案，上线就是扯皮的开始。

AI 项目的 PRD 和传统 PRD 的差别，说穿了就两处：验收口径要写"怎么统计"，风险要写"错了谁接"。其余部分（背景、用户故事、信息架构、里程碑）与传统 PRD 同构——会写传统 PRD 的人，补上这两处就能上手 AI 项目。

【核心观点】AI PRD 骨架 = 传统 PRD + 两个 AI 特有件

AI PRD 的骨架是十节：背景、范围一页纸、用户故事、功能需求、验收口径、兜底预案、信息架构、数据依赖、里程碑、风险。其中第五节和第六节是 AI 特有的，也是最容易被写成摆设的。

验收口径必须写清三件事：金标集多大、指标多少、怎么统计——"准确率 90%"是半句话，"在 800 条金标集上分类准确率 ≥95%，按周抽样统计"才是能验收的话。兜底预案必须写清：模型没把握时交给谁、系统挂了降级成什么、出错了怎么回滚。

还有一层保护：交付物清单。把项目要交的东西列成清单（PRD、范围合同、金标集、评测报告、上线检查清单、运维手册……），写清"交什么、不交什么"。功能列表会漂，交付物清单不会——它比功能列表更能保护团队，因为扯皮时你拿得出白纸黑字。

下一篇开始进入技术选型（RAG / Agent / Workflow 怎么选），但在那之前必须把 PRD 的地基打牢——选型选的是"怎么实现需求"，PRD 定的是"需求本身是什么"，顺序不能反。

【技术解析】PRD 十节骨架对照表

第五节验收口径要细到"四层指标"：功能层（分类是否正确）、效果层（准确率/召回）、效率层（单均时长、吞吐）、体验层（兜底率、投诉率）。只写第一层的是传统 PRD 写法——AI 项目的效果会退化，四层都要有基线。

写作顺序也有讲究：先写第 2 节范围合同，再写正文。范围是地基，功能是上层建筑——顺序反了，功能列表会把范围撑破。

【架构设计】AI 订单履约助手 V1.0 实例片段

把十节骨架填满要二十页，这里给三个最关键的节的实例片段，可以直接抄结构：

第 1 节 · Problem Statement：日均处理 200 单咨询的售后客服（谁），在订单履约高峰期（场景），80% 常见咨询要翻订单、仓储、物流三个系统才能回答，单均 4 分钟（问题），V1.0 做到咨询意图自动分类 + 话术一键回填，人工只处理 20% 长尾，单均降到 30 秒以内（凭什么算解决）。

第 2 节 · 范围一页纸：Goal——覆盖 20 类高频咨询的意图分类与话术推荐；Non-goal——不做自动回复、不接语音、不碰改价退款、不接企业微信、不做自定义报表；验收——800 条金标集上分类准确率 ≥95%，回填单均 ≤30 秒；停止条件——金标集不足 500 条或准确率 85% 持续两周，暂停回 Discovery。

第 5 节 · 验收口径：金标集 800 条（业务方标注，三方各 267 条交叉）；分类准确率 ≥95%、兜底率 ≤5%、单均回填时长 ≤30 秒；统计方式为每周从线上抽样 200 条人工复核，连续两周达标才算验收通过。

第 6 节兜底预案的实例：意图置信度低于阈值 → 转人工不打标；推荐服务不可用 → 降级为原三个系统查询页；答错投诉 → 一键回滚到纯人工流程，回滚时间 <10 分钟。三条预案，每条都有触发条件和动作。

十节不必等全部写满才评审——第 1、2、5、6 节写完就可以过第一轮评审，这四节定了项目的骨架和边界；其余六节跟着开发节奏补。PRD 是活文档，但活的部分是实现细节，死的部分是范围合同和验收口径。

【实践经验】这份 PRD 在评审会上救了一次场

V1.0 评审会上，客户方 IT 负责人看到"意图自动分类"就问："分类错了谁负责？答错了客户投诉算谁的？"会议室安静了五秒。PM 翻到第 6 节兜底预案，念了三条：置信度低转人工、服务降级有预案、答错投诉一键回滚——然后又翻到第 2 节 Non-goal："自动回复不在 V1.0 范围，所有对客话术人工确认后发出。"

IT 负责人点点头，问了一个技术问题就过了。后来他说："我不是要为难你们，是要看到你们想过最坏情况。多数供应商只讲能做什么，你们讲了错了怎么办——这让我放心。"那次评审一次通过，后面两期合作都是他们牵的线。

这就是 PRD 里兜底预案的价值：它不是在示弱，是在证明你想过最坏情况。B 端客户买的从来不是"最厉害的功能"，是"最坏情况下也有准备"的确定性。

项目最终 6 周交付，V1.0 上线后单均时长 4 分钟降到 28 秒，兜底率 3.2%。三个月后做全案复盘时，我们把交付物清单凑齐了 20 份——那份清单的用法，留到系列第 23 篇展开。

交付物清单要在 PRD 里单独列一节，写法是"文档名 + 交付时点 + 验收人"。它的作用在项目后半段才显出来：中期客户要加需求，我们对照清单指出"这属于变更，走第 2 节范围合同的流程"；验收时逐项对清单签收，不扯皮。功能列表描述的是产品，交付物清单约束的是协作——后者才是 PM 每天的战场。

【避坑指南】写 AI PRD 的五个坑

① PRD 只有功能列表，没有范围合同。功能会漂，范围合同管变更——先写第 2 节再写正文。

② 验收口径只写"准确率 90%"。半句话不能验收——金标集多大、指标多少、怎么统计，三样写全。

③ 不写兜底预案。"错了谁接"是 B 端客户最先问的问题——置信度、降级、回滚三条都要有。

④ P0/P1/P2 不标。需求一来就加——标注优先级，P0 才进 V1.0，其余进待办。

⑤ PRD 写完不评审。供在文档库里没人看——范围合同和验收口径必须过评审会，双方签字。

技术图：AI PRD 十节骨架

把这张骨架图存成 PRD 模板目录页。每次开新项目，先建十个空节——第 2 节范围合同和客户签字后，再动第 4 节功能列表。

总结：5 条能直接用上的判据

1. AI PRD = 传统十节骨架 + 两个 AI 特有件：验收口径（写统计方式）+ 兜底预案（错了谁接）。

2. 验收口径三要素：金标集多大、指标多少、怎么统计——"准确率 90%"只是半句话。

3. 四层指标都要有基线：功能、效果、效率、体验——AI 效果会退化，只测一层会漏判。

4. 写作顺序：先范围合同，后功能列表——范围是地基，顺序反了功能会撑破范围。

5. 交付物清单比功能列表更能保护团队——写清交什么、不交什么，扯皮时拿得出证据。

下一篇进入技术选型：一个需求该用 RAG、Agent 还是 Workflow？我们按"检索增强、自主规划、固定流程"三条线拆解，给你一张选型决策的底图。

相关阅读：

• MVP越小越容易成功：Non-goal与停止条件（系列第 08 篇）

• 从模糊需求到MVP：Problem Statement怎么写（系列第 07 篇）