7.1 PEV 交付闭环

本章导读

本 节 目 标

• 能执行范围控制的四条纪律，一次只解决一个可衡量的问题、不确定性不向下游传递、新增需求必须换出旧需求、先做窄而深再做宽而浅。
• 能按原型（让客户挑错）→实证（真数据真用户）→验证（对上预设指标）组织交付节奏，并在 WorkBuddy 上跑通每一环。
• 能在进场时定好效果、效率、采纳、合规四维验收标准，含拒答优于胡答、可溯源、人可接管三条兜底。
• 能用 L0–L4 框架判断项目进度和止损时机。

你一定见过这样的场景：项目启动会开得热闹，技术团队加班加点搭好了 Agent、接好了知识库、跑通了 RAG 链路，内部测试一切正常。到了验收日，客户业务方看了一眼说：「这个回答不对我们业务」「这个效率没提升」「这个没人愿意用」。项目卡住了。

问题出在哪里？技术和产品都没问题，交付和验收从一开始就没对齐。

AI 项目的交付与传统软件交付有一个本质区别：传统软件的功能边界是确定的——「登录按钮点了能登录」就是验收通过；而 AI 项目的输出是概率性的——「回答得对不对」高度依赖业务语境和用户预期。如果你等到项目尾声才去定义「什么叫好」，几乎必然翻车。

本章要解决的就是这个问题：怎么从进场第一天就把交付路径和验收标准钉死，让每一步都验得动、每一步都敢让客户挑错。我们会讲五个核心知识点——PEV 交付闭环、验收标准、L0–L4 成熟度、范围控制、Land and Expand。学完这一章，你应该能拿着一套框架去组织任何 AI 项目的交付节奏。

概念

PEV 是一套专为 AI 项目设计的交付节奏框架，三个字母分别代表：

为什么 AI 交付不能走传统的「需求→开发→测试→上线」瀑布模式？因为 AI 系统的输出无法在需求阶段完全定义清楚。你没法在合同里写「回答准确率 95%」然后就闭着眼睛开发——准确率取决于知识库质量、问题分布、用户问法、边界 case 的处理策略，这些只有在「跑起来」之后才知道。

PEV 的设计哲学是：把「让客户挑错」的环节尽量前置。原型阶段就暴露分歧，总比验收阶段才发现要便宜得多。

🖼 图：pev loop

在 WorkBuddy 上怎么跑 PEV：

原型阶段用「专家 + 资料库」快速搭一个能对话、能引用客户文档的助理，通常一两天就能给客户看；实证阶段接上连接器打通真实业务系统，让它读真数据；验证阶段用云端任务托管跑批量样本，把成功率、耗时统计出来。平台的价值就在于把 P 这一步压到「客户还有耐心的时间窗口」以内。

回到手上：在 WorkBuddy 上，一个下午就能走完一轮压缩版 PEV——第 1 小时用「专家 + 资料库」出原型，第 2 小时接真实数据暴露问题，第 3 小时对照预设指标验证。亲手把这一圈跑完，PEV 就从概念变成了肌肉记忆。

用法

PEV 三阶段的操作要点和交付物：

• 注意 ：周期建议是参考值。项目复杂度不同可以伸缩，但 三个阶段的顺序不能跳 。见过不少团队跳过 P 阶段直接做 E，结果跑了两周实证才发现「客户要的跟做的根本不是一个东西」。

示例

以 WorkBuddy 上交付一个「智能客服 Agent」为例，走一遍 PEV 全流程：

P 阶段（原型）：

在 WorkBuddy 上搭建一个最小可用的客服 Agent 原型，包含：

• 1 个 Skill：FAQ 问答（覆盖客户提供的 Top 20 高频问题）

• 1 个知识库：客户提供的 FAQ 文档（不做复杂 RAG，直接全文检索）

• 1 条兜底规则：知识库中找不到答案时，Agent 回复「这个问题我需要转人工」

把这个原型丢给客户业务方，让他们自己问、自己挑。别急着比 Agent 多聪明，这阶段的核心产出是暴露分歧——客户以为 Agent 该回答的问题，跟你以为的可能完全不同。

预期场景：

客户业务方："我问它'订单退不了怎么办'，它居然给我背了一段退货政策，我要的是操作步骤。"

FDE："对，这就是原型阶段要发现的。退货政策和操作步骤是两个不同的 Skill，我加一条。"

客户业务方："那'退款多久到账'呢？"

FDE："这个也要拆出来。"

P 阶段结束的标志：客户业务方确认「这些 Skill 覆盖了核心场景，方向是对的」。

E 阶段（实证）：

接入真实业务数据：

• 知识库从 20 条 FAQ 扩展到客户提供的完整 FAQ 库（可能几百条）

• 接入真实工单历史数据（如果有），做 RAG 的向量检索

• 找 5–10 个客户一线客服人员，用真实用户的问题来测试

这阶段要收集两类数据：

1. 客观指标 ：回答准确率、拒答率、平均响应时间、人工介入率

2. 主观反馈 ：客服人员觉得「这个回答能用吗」「有没有让你觉得不放心的时候」

E 阶段的核心是在真实数据分布下发现系统的边界。指标漂亮只是副产品。哪些问题 Agent 答得好？哪些答得离谱？拒答逻辑有没有误触发？

预期场景：

实证报告摘要：

- 测试问题数：200

- 回答准确率：78%（目标 85%，未达标）

- 拒答率：12%（目标 < 15%，达标）

- 主要问题：30% 的错误集中在"退货运费谁出"这一类问题

- 根因分析：知识库中关于退货运费的文档有矛盾（两份文档说法不同）

- 修复方案：协调客户业务方澄清规则，更新知识库

V 阶段（验证）：

用进场时定好的四维验收标准（详见下一节）逐条核对。注意，验收标准是进场第一天就定好的，不是现在临时找补的。

预期场景：

验收报告：

| 维度 | 标准 | 实测结果 | 判定 |

|------|------|---------|------|

| 效果 | 回答准确率 ≥ 85% | 86.5% | |

| 效果 | 拒答率 < 15% | 11.2% | |

| 效率 | 平均响应时间 < 3s | 2.1s | |

| 采纳 | 试点客服周活跃 > 80% | 83% | |

| 合规 | 拒答优于胡答 | 知识库无答案时 100% 转人工 | |

| 合规 | 可溯源 | 所有回答附带来源文档链接 | |

| 合规 | 人可接管 | 一键转人工平均耗时 < 5s | |

验收结论：通过

• 注意 ：V 阶段不通过怎么办？回到 E 阶段修复根因，不要在 V 阶段打补丁。验收阶段发现的问题，往往是 E 阶段的数据覆盖不够或知识库有矛盾，回去修源头比在这里调 Prompt 有效得多。

注意事项

• P 阶段不要追求完美 ：原型的目的是暴露分歧，不是炫技。如果你花两周搭了一个「什么都能答」的原型，可能说明你的范围太大了。

• E 阶段必须有真实用户参与 ：FDE 自己测不算实证。真实用户的问题分布、问法习惯、心理预期，跟开发者完全不同。

• V 阶段不接受临时改标准 ：验收标准是进场时定的。如果实测发现达不到，要么回去修，要么走变更流程重新签标准——但不能「反正差一点，就算过了」。