第 2 章 需求与成功标准

学习目标

• 将“运行良好”这种模糊需求，转化为包含数据、指标、基准值与测量方法的、可判定的成功标准。
• 不仅关注准确率，还同时确立一致性、语气、个人信息处理、延迟、成本等多维度的标准。
• 以输入·输出契约明确功能接收的输入与返回的输出，并写明超出范围的输入与格式错误的处理规则。
• 权衡质量、延迟与成本，选择合适的架构设计方案（模型、输出长度、流式传输、批处理）。
• 将面向用户的失败体验编写为需求，并区分上线阻断标准与改进目标。

引言

某份策划案的需求栏中曾写着这样一句话：“AI 摘要必须准确、自然，且响应迅速。”然而在上线前一个月，开发团队发问：“准确率达到 91% 算准确吗？”，销售团队则表示“客户期望的是 99%”，设计师也追问：“‘迅速’到底是指几秒？”大家都没有错，只是需求被写成了无法判定的表述。

AI 功能以概率方式运行，因此无法承诺“绝不出错”，而是承诺“在指定数据上、用指定方法测量时，达到该比例以上”。Claude 官方文档指出，成功的 LLM 应用程序始于明确定义成功标准，而围绕该标准设计评估闭环则是核心所在。本章探讨的正是这一闭环的前半部分——即如何界定何为“成功”。

首先，我们将学习可判定标准的条件及其多个维度，并练习将模糊需求转化为量化数字的流程；接着，探讨输入·输出契约以及质量、延迟与成本之间的权衡，并学习如何将面向用户的失败体验编写为具体需求；最后，将所有标准划分为上线阻断标准与改进目标，汇总整合为一份完整的需求文档。

核心概念

AI 功能的需求有何不同

传统功能的需求非真即假、界限分明，例如“点击按钮后跳转至支付页面”。而 AI 功能的需求则具有“大部分正确、小部分出错”的特性，例如“准确识别咨询类型”。因此，AI 需求还需要额外包含以下三点：

1. 以比率表述的标准。 不是单纯的“答对”，而是“在 1,000 条评估集上，正确率达到 95% 以上”。
2. 测量方法。 由谁、与什么进行比对、如何判定。
3. 出错时的承诺。 出错的 5% 会如何呈现给用户、又该如何处理。

打个比方，传统需求就像设计图纸，而 AI 需求更接近质量检验规范。工厂无法将不良品率降为零，因此必须同时规定不良率上限、检验方法以及不良品处理流程。

可判定的成功标准

Claude 官方文档提出了良好成功标准的四项条件：必须具体（specific）、可衡量（measurable）、可实现（achievable）且与目标相关（relevant）。应当明确具体，例如用“准确的情感分类”代替“性能优良”；采用数字或定义明确的标尺进行衡量；依据行业基准、前期实验结果或专家经验设定目标；并且契合用户的实际需求。

同篇文档中的示例清晰展示了两者之间的差异：

良好的标准必须包含四项要素：衡量什么（指标）、在何处（数据）、达到何种程度（基准值）、如何操作（测量方法）。缺少任何一项，团队在会议上都会重新对数字产生争议。如果能同时注明与何者进行对比（基线），还能进一步合理解释为何设定该基准值。上表中情感分类的示例便是连同基线（比当前提升 5%）一并注明的形式。

成功标准的多重维度

Claude 官方文档指出，大多数功能都需要依据多个成功标准进行评估，并列举了以下常见维度：

如果仅以准确率为唯一标准，就会忽略其他维度的失败。为了提高准确率而使用更大规模的模型，延迟和成本便会恶化；若回答写得过长，相关性可能会下降。只有为各个维度分别设立标准，才能看清彼此之间做出了怎样的权衡与取舍。

精确率与召回率

对于执行“识别捕获”类任务的功能（如疑似欺诈、垃圾信息、紧急请求检测），精确率与召回率比单纯的准确率更加重要。按照 Google PAIR 指南的定义，精确率是指被判定为正例的样本中实际为正例的比例，而召回率则是实际为正例的样本中被成功捕获出来的比例。

PAIR 指南指出，权衡假正例与假负例的代价是决定用户体验的关键抉择，并告诫切勿机械地给予两者同等权重。由于这两个指标往往难以同时提升，因此必须在需求中明确每项功能究竟优先保障哪一方。若希望综合考量两者的平衡，通常使用的指标是 F1 分数（精确率与召回率的调和平均数）。

将模糊需求转化为标准的步骤

当接到诸如“摘要必须充分体现意图”这类需求时，可按以下步骤进行转化：

1. 拆解含义。 与提出需求方共同拆解，理清“意图”究竟是指解决承诺、后续跟进措施，还是指特定的语气态度。
2. 转化为可观察的行为。 例如“摘要中完整包含了后续措施（由谁、于何时、做什么）”。
3. 确定测量方法。 若有标准答案则通过代码比对；若需要主观判断，则制定评分量规（列出各分项判定标准与分值等级的评分标准表）并指定评分者（人工评分，或与人工比对校准后的 LLM 评分器）。
4. 确定数据。 从实际业务记录中抽取的评估集，明确其规模与构成。
5. 确定基线与基准值。 测量当前水平（基线），并根据依据设定切实可行的基准值。

Claude 官方文档说明，即便是伦理或安全等较为“模糊”的主题也可以进行量化，定性标尺只要与定量指标结合并保持一致使用，同样极具价值。在转化过程中，与需求提出方达成共识，其重要性往往超越数字本身。

输入契约

输入契约是明确该功能接收何种输入的约定，需详细写明支持的语言、文件类型、长度、必填信息以及拒收信息。若缺乏输入契约，该功能便会去处理未经检验的输入，即使输出结果糟糕，用户也无法得知原因。

对于输入范围，有些可以在发送给模型前进行检查（如格式、长度），但也有些必须读取内容后方可判断（如“针对不支持业务的提问”）。前者可通过预先校验拦截，后者则通过意图分类或模型判断过滤并导向预设指引路径，该判定机制本身也需经由评估集予以验证。支持的输入范围必须与评估验证过的范围保持一致。若要支持未经评估的语言或长度，应先将该类输入纳入评估集并通过标准后，再行扩大支持范围。Google PAIR 指南建议，应利用错误状态向用户明确说明 AI 究竟需要何种输入。

输出契约

输出契约是明确该功能以何种形式返回何种内容的约定。若是供人阅读的界面，需规定长度与结构；若是供下游系统调用的结果，则需写明字段、格式以及空值处理规则。

对于传递给其他系统的输出，必须遵循格外严格的规范。Claude 官方文档说明，结构化输出（structured outputs）通过受限解码（强制仅生成符合模式 Schema 的 token 的方式），在绝大多数情况下均能保证响应严格遵循 JSON Schema。然而文档也指出，在请求被拒绝（stop_reason 为 refusal）或达到输出长度上限（max_tokens）的情况下，输出可能无法匹配 Schema；此外，并不保证字符串枚举值（enum, const）的大小写，即使无报错正常结束的响应，也可能出现仅大小写不同的取值。因此，比对枚举值时应不区分大小写，且避免单独定义仅大小写有别的不同枚举值。正因如此，输出契约中除了 Schema 之外，还必须附带“验证失败的结果不得直接使用，应重新处理或转交人工”的处理规则。

[输出契约示例]
格式: JSON {"item": 字符串, "quantity": 整数, "unit_price": 整数}
空值: 无法辨识的字段设为 null，切勿臆测填充
验证: Schema 验证失败、被拒绝、达到长度上限 → 不发送至下游系统，进入重试队列
失败告警: 1 小时内重试队列超过 20 件时向负责人发送告警

即使准确率再高，一旦格式不符，下游系统便会崩溃。准确率与格式规范属于两项截然不同的需求。

质量·延迟·成本的权衡

质量、延迟与成本之间虽互为权衡取舍的关系，但可调节的杠杆有多种。Claude 官方文档建议，应先找到在不受约束条件下良好运行的配置方案，然后再着手降低延迟；因为若过早压缩延迟，将无法探明系统的最佳性能上限。

衡量延迟时，需区分完整响应结束的时间与首个 token 输出所需时间（TTFT，Time To First Token）。用户在屏幕前等待的功能对 TTFT 敏感，而向下游系统传递结果的功能则更看重整体耗时。成本应按“单次成本 × 月处理量”进行核算，并与预算进行比对。

面向用户的失败体验

AI 功能必然存在一定比例的失败，在失败发生的瞬间用户会看到什么，正是需求的一部分。Google PAIR 指南指出，用户所感知的错误与他们对系统的预期紧密相关，并将错误划分为系统局限、上下文错误以及背景错误。指南建议，应聚焦于失败后用户能够做些什么，并在发生失败时允许用户接手完成任务。

采用流式传输时，失败可能会在响应输出的中途发生。Claude 官方文档解释称，在流式响应中，即便正常响应（200）已开始，中途依然可能报错。因此，如何呈现“输出到一半的回答”也必须纳入需求当中。仅仅显示“无法回答”的界面虽然不会被计入错误回答的比率中，却会阻碍用户的正常流程。结合使用日志观察失败页面出现后的用户行为（流失、重试、电话咨询），便能清楚显现失败体验所带来的真实代价。

上线阻断标准与改进目标

各项标准的重要性不尽相同。上线阻断标准是指只要未达标、无论其他指标多么优异都绝不上线的硬性底线；而改进目标则是指上线后逐步提升的期望水准。

若阻断标准过多，上线日期将被无限期推迟；若阻断标准过少，则极易引发事故。NIST AI RMF 建议组织确定并记录其风险承受水平（MAP 1.5）。阻断标准正是将这一风险承受水平转化为具体的量化数字。此外还存在另一种选择：若仅有特定类型的输入未能达到标准，且具备将该类型转交人工处理的路径，那么将该类型排除在范围之外的“有条件上线”，便成了介于阻断与改进之间的务实折中方案。

基准值的设定依据

基准值绝非凭商务谈判敲定的数字。Claude 官方文档建议，应以行业基准、前期实验、AI 前沿研究以及专家经验为依据，且目标的设定应立足于当前前沿模型的能力，不可脱离现实。在实际业务中，常用的依据有以下三项：

1. 当前水平（基线）。 当前人工或既有系统所能达到的水准。若人工客服的分类准确率为 93%，那么将 AI 目标设定为 99% 显然缺乏有力依据。
2. 出错代价。 单次出错所造成的损失。潜在损失越大，设定标准应越高，或需引入人工复核环节。
3. 小规模实验。 基于 50~100 个样本运行得出的测试结果。以此提前评估设定的标准是否具备可实现性。

竞品在宣传中所宣称的数据因测量方法未知，很难作为可靠依据。

需求文档的结构

按以下结构编写 AI 功能的需求文档，能够极大地方便评审与判定：

1. 目标与用户：使用者是谁，用于何种目的
2. 输入契约：接收项、拒选项、超出范围处理
3. 输出契约：格式、空值、验证失败处理
4. 成功标准：各维度的指标·数据·基准值·测量方法（包含基线）
   4-1. 上线阻断标准
   4-2. 改进目标
5. 失败体验：各失败场景下的界面及后续操作
6. 延迟·成本：TTFT/整体耗时、单次成本 × 处理量
7. 法规要求：告知·标识、个人信息处理条件
8. 待定事项：待明确定义的需求、负责人及截止期限

深入阅读

想要缩减为单一指标的诱惑

管理层通常想要一个单一的数字：“所以到底是几分？”对多个维度进行加权平均得出的综合分数虽然便于汇报，却非常危险。因为像个人信息泄露这样的拦截标准，会被其他维度的高分所掩盖。如果准确率 95 分、语气 90 分、个人信息 40 分的加权平均分是 80 分，那么这 80 分看起来就像是可以发布的信号。

拦截标准不计入平均分，而是单独判定。如果需要综合分数，也仅限于已全部通过拦截标准的功能，用于展示各项改进目标的演变趋势。报告的第一行必须是“全部通过五项拦截标准”，综合分数则排在之后。

错误的大小也是标准

并非所有错误都具有相同的分量。Claude 文档的多维度标准示例中，有一项指出“90% 的错误并非严重错误，而仅停留在造成不便的程度”。即便两项功能的准确率完全相同，但其错误答案究竟是“换一种表达重新提问即可的程度”，还是“给出了错误承诺金额的程度”，两者的发布裁决也会截然不同。

因此，成熟的需求会按严重程度划分错误并设立标准。例如，将严重错误（错误的金额·期限·资格说明）限制在 0.5% 以下，将轻微错误（表达生硬）作为改进目标。严重程度的定义本身也是需求的一部分，因此需要附带示例一同写入。

一致性何时成为需求

如果面对同一个问题每次都给出不同的回答，用户就会失去信任。特别是在规章引导、价格说明、资格判定等理所当然“相同条件对应相同答案”的领域，一致性与准确率同等重要。Claude 文档将一致性列为成功标准的一个维度，并建议我们自问：当连续两次提出相同问题时，得到语义相似的回答究竟有多重要。

反之，在头脑风暴或文案候选这类以多样性为核心价值的功能中，强求一致性反而会降低实用价值。对一致性的要求必须源自功能本身的目的，并且请记住：一致性高并不意味着准确。系统也可能会始终如一地输出相同的错误答案。

工作场景

月晕游戏的举报分类

游戏公司“月晕游戏”计划使用 AI 对每天收到的 2 万件玩家举报（辱骂、外挂作弊、支付问题等）进行分类，并发送给对应部门。最初的需求仅仅是“准确分类举报”。

策划人员首先划分了维度：分类准确率、紧急举报（现金诈骗·个人信息泄露）检测、延迟、成本。准确率方面，他们以上个月由人工分类的 3,000 件举报作为评估集，写明“11 个类别的完全匹配率在 92% 以上”。由于人工负责人员目前的匹配率为 94%，因此并没有要求达到 100% 的依据。

紧急举报则进行了单独处理。紧急举报虽然仅占总量的 0.3%，但一旦漏报就会导致实际的财产损失。被分类为紧急的举报均由负责人员重新复核，因此误报是可以承受的。于是，他们将“紧急举报召回率 98% 以上”定为发布拦截标准。精确率则是根据负责人员每天 300 件的复核能力倒推计算出来的。实际的紧急举报每天大约 60 件，若要使归类为紧急的件数不超过 300 件，精确率就必须在 20% 以上。他们将这一“精确率 20% 以上”记录为运营条件。而被废弃的方案则是“仅将整体准确率 95% 以上作为唯一的拦截标准”，因为仅占 0.3% 的紧急举报会被淹没在整体准确率中，难以察觉。

他们还加入了输出契约：分类结果仅允许输出 11 个类型代码之一，其他任何值或格式错误都会被发送至“未分类队列”由人工处理。最后，“分类理由语句的自然度”被定为改进目标。由于对应部门并不阅读理由而是直接查看原文，因此没有理由以此阻碍发布。

野花来信的贺卡文案

鲜花速递服务“野花来信”策划了一项新功能：订购者选择收件人和场合后，AI 会推荐三条留言贺卡文案。最初的需求是“快速生成感人文案”。

策划人员对“感人”进行了拆解。从订购者访谈中提炼出的要点是：“符合场合（吊唁中没有祝贺用语）”、“收件人称谓恰当”、“长度适中（能写进卡片）”。前两项成为了拦截标准。在吊唁场合混入祝贺表达的错误哪怕只有一起也会引发严重的投诉，因此他们写明“吊唁场合出现祝贺表达为 0 起（通过禁用词列表对所有文案进行代码检查），其他场合不符的情况控制在 0.5% 以下”。卡片长度作为输出契约（每条文案 80 字以内），而文案的温馨程度则作为规则量表评分的改进目标。

“快速”被转换为了 TTFT 标准。由于订购者会在屏幕前等待，因此决定采用流式传输，以便在 2 秒内显示第一条文案。在评估中，较小的模型全部通过了拦截标准，因此他们选用小型模型替代大模型，降低了单次请求成本。被废弃的方案则是“通过设置较低的 max_tokens 来控制长度”，因为这会导致句子在中间被截断，根本无法用于贺卡。

易错点

1. “只要准确率就足够了。” 延迟、成本、语气、个人信息处理往往与准确率脱钩变动。应针对每个维度设立各自的标准。
2. “有了数字就是好标准。” 如果测量方法不可靠（如生成模型的自我评估）或与目的无关（如越短越好），即便有具体的数字也是糟糕的标准。
3. “把所有标准都设为发布拦截标准就安全了。” 如果把不影响正常使用的质量指标也作为拦截项，发布就会无限期推迟。只有会引发实际损害的标准才属于拦截标准。
4. “只要准确率高就不需要格式校验。” 格式是独立于准确率的需求。即使使用结构化输出，也可能因系统拒绝或长度限制而发生偏差。
5. “缩减 max_tokens 就能让回答短小精炼。” 一旦触及长度限制，句子就会在半途中被截断。长度应当由提示词和输出契约来规约。
6. “速度有问题就换用小型模型。” 如果达到质量标准的模型仅有一个，应通过流式传输或控制输出长度来降低感知延迟。
7. “无法回答时直接拒绝就万无一失了。” 没有引导后续操作的拒绝只会阻断用户，并将服务成本转移到其他渠道。

要点速览

• 优秀标准 = 指标 + 数据 + 基准值 + 测量方法，以及作为基准值依据的基线。必须能够让其他人进行判定。
• 成功标准应从多个维度（准确率、一致性、相关性、语气、个人信息、上下文利用、延迟、成本）建立。
• 识别捕捉类功能应在精确率与召回率之间，优先保障错误代价更高的一方。
• 输入契约应与通过评估验证的范围保持一致，超出范围的输入应在处理前予以告知。
• 输出契约中除 Schema 外，还需写明校验失败·拒绝·长度限制的处理规则。
• 延迟应区分 TTFT 与总耗时，并通过流式传输·输出长度·模型选择·批处理来进行调节。
• 针对每个失败节点，都要将用户的后续操作作为需求写入文档。
• 拦截标准仅限触及法律·合同·实际损害的指标，其余均为改进目标。缺乏明确定义时应从定义做起。

查阅官方文档

• Claude Docs — Define success criteria and build evaluations：优秀成功标准的条件、反面与正面标准示例、常见的成功标准维度。
• Claude Docs — Structured outputs：Schema 符合性保障与例外情况（拒绝、max_tokens）。
• Claude Docs — Reducing latency：基线延迟与 TTFT、模型选择、输出长度、流式传输。
• Claude Docs — Batch processing：非实时批量任务的成本与处理耗时。
• Google PAIR Guidebook — User Needs + Defining Success：精确率与召回率、假阳性与假阴性的代价。
• Google PAIR Guidebook — Errors + Graceful Failure：用户感知的错误、错误状态、失败后的后续操作。
• NIST AI RMF — Core：MAP 1.5（风险容忍水平的确定与记录）。

自测

2-1. 请写出优秀的成功标准中必须包含的四个要素，并写出作为基准值依据建议一并记录的内容。

2-2. 请将“回答必须迅速”转换为可判定的标准；如果该功能需要用户在屏幕前等待，请说明应使用哪种延迟指标。

2-3. 请分别用一句话定义精确率和召回率。

2-4. 某项功能旨在从医院预约短信中识别“取消预约请求”并自动删除预约。被识别出的项目将在无需人工确认的情况下直接执行。此时应当将哪个指标作为发布拦截标准来坚守？为什么？

2-5. 即便使用了结构化输出，也必须在输出契约中写明校验失败处理规则，请结合两种情境说明其原因。

2-6. 请将下列各项划分为发布拦截标准与改进目标：(甲) 咨询摘要中残留客户银行账号的比例 (乙) 摘要语句的简练度评分 (丙) 写错退款期限的比例。

2-7.（设计）请选择一个常用的 AI 功能，以表格形式列出三种失败节点以及在各个节点向用户呈现的后续操作。

实操练习