需求鸿沟：当“正确”是一个分布时，如何为 AI 功能编写规格说明

这是一个按计划交付存在缺陷的 AI 功能的典型规格说明书（Spec）：“助手应准确回答客户问题并保持友好的语气。”每一位利益相关者都点头示意，产品需求文档（PRD）获得了批准。六个月后，团队在事后分析中争论 87% 的准确率是否可以接受 —— 而这是一个在发布前没有人想到要回答的问题。

这种失败并非技术性的。模型本身可能没有问题。失败之处在于直接从传统软件引入的需求格式没有为 AI 输出的核心属性留出空间：即它们是概率性的。“正确”不是一种状态，而是一个分布。你无法用一个用户故事（User Story）来定义一个分布。

那些尽早弥补这一鸿沟的团队 —— 即在触碰 Prompt 之前就编写真正的 AI 规格说明书的团队 —— 报告称，与凭直觉运作的团队相比，其迭代周期缩短了 3-5 倍。这种机制并非魔法；它仅仅是因为在规格说明书评审中发现分歧的成本远低于在事后分析中发现分歧的成本。

为什么传统的验收标准对 AI 失效

标准的验收标准假设系统是确定性的：给定输入 X，系统产生输出 Y。如果 Y 符合预期值，则测试通过。这种模型在 AI 的每一个维度上都失效了。

同样的 Prompt 在不同的运行中可能会返回不同的有效答案。对于大多数开放式 AI 任务来说，没有标准的“金标准答案”，只有一系列可接受的输出。传统的 QA 进行一次性的验证；而 AI 功能则需要持续、不间断的测量，因为随着模型更新、Prompt 更改以及输入分布随时间的漂移，系统的行为也会发生变化。

考虑将标准 QA 应用于客户服务总结功能时会发生什么。你在十个对话上进行了手动测试，看起来没问题，然后发布了。三周后，一位用户提交了一个包含 40,000 个 Token、涉及三种语言切换并引用了嵌入式 PDF 的对话。你的系统从来没有关于如何处理这种情况的规格说明书。失败模式一直存在；只是规格说明书无法预见它，因为它描述的是与演示案例匹配的输入的成功条件。

更深层次的问题在于组织层面。如果没有量化的规格说明书，工程和产品团队在权衡取舍时就没有共同语言。93% 的准确率是可以接受的吗？这取决于规模：在每年 1,000 万件保险理赔中，7% 的错误率意味着 70 万件潜在的错误裁决。以百分比表示时，它听起来很合理；但以商业后果来衡量时，它需要一个不同的答案。传统的规格说明书从未强制进行这种计算，因为它们假设系统要么工作，要么不工作。

两层结构：政策与质量

AI 规格说明书中最关键的概念转变是将约束分为两个根本不同的类别：政策约束和质量阈值。将两者混为一谈会导致过度阻塞（团队因为质量指标未达标而停止开发，而这本应是可以重新协商的）和保护不足（团队将极端情况下的政策违规视为“在可接受的错误率范围内”，而事实并非如此）。

政策约束（Policy constraints） 是不可逾越的行为边界。无论上下文、用户请求或质量权衡如何，系统都绝不能跨越这些边界。例如：“严禁在回复中泄露真实用户的 PII（个人身份信息）”、“严禁生成描绘未成年人色情内容”、“严禁产生包含 CVE 可利用代码模式的输出”。这些都通过二进制的通过/失败来测试：系统要么跨线了，要么没有。任何违规都是发布的阻碍因素，绝无例外。像“在 10,000 个对抗性测试用例中，触发该约束的比例低于 0.1%”这样的阈值适用于衡量护栏实现的稳健性，但在红线政策上 0.1% 的失效率仍然是你在决定是否发布前需要理解的失效率。

质量阈值（Quality thresholds） 是针对预期输入分布的输出质量的概率目标。这些目标可以根据业务权衡进行协商，并随时间推移而改进。例如：“在 500 个问题的留出评估集上达到 ≥ 90% 的事实准确率”、“在 80% 的采样回复中，人类评分者的评分 ≥ 4/5”、“95% 的延迟在 2 秒以内”。未达到质量阈值会触发调查和路线图优先级调整；但它不会触发立即回滚。

操作上的区别至关重要：政策违规会立即上报；未达到质量阈值则会创建工单。你需要两者，并且它们需要存在于规格说明书文档的不同章节中，通过不同的流程强制执行。

编写真正可测试的规格说明书

一个定义良好的 AI 验收标准遵循特定的结构：

[维度]：在 [测试集描述] 上达到 [阈值]，通过 [衡量方法] 进行测量

对比以下内容：

不可测试	可测试
“AI 能够准确回答客户问题”	“在从生产查询中抽样的 500 个问题的留出评估集上，事实准确率 ≥ 90%，通过由人类校准评分标准的 LLM-as-judge 进行衡量”
“AI 应保持专业的语气”	“在每月审查的 200 个随机生产样本中，≥ 85% 的采样输出被人类评分者评定为语气合适”
“AI 应该是安全的”	“在 10,000 次对抗性测试试验中，被自动分类器标记为违反政策的输出少于 0.1%，并对标记样本进行每周人工审计”

这种强制机制的作用在于，以这种格式编写会立即暴露未回答的产品问题。测试集是什么？谁来测量？“合适”意味着什么，你能写出一个评分标准（Rubric）吗？这些是你的团队最终需要回答的问题 —— 规格说明书的格式决定了你是在发布前回答这些问题，还是在发布后的事后复盘中回答。

定义错误严重程度类别，而不只是错误率。 规定“90% 的错误被归类为轻微不便，而非严重错误”，这会迫使你在发布前建立严重程度分类体系。5% 的错误率由于错误性质的不同，其含义也截然不同，例如是“生成了一个略显尴尬的句子”还是“在药物剂量不安全时告诉用户它是安全的”。

构建多维度的成功标准。 单一指标优化一直被认为是 AI 功能开发中的失败模式。为任务保真度、等效输入之间的一致性、极端情况处理、延迟、成本和政策合规性定义分别的质量阈值。在某一维度表现出色但在其他维度失败的系统非常普遍；规格说明书需要捕捉到这一点。

在编写 Prompt 之前先编写 Eval

最反直觉——也是杠杆率最高——的实践是在编写任何一个 Prompt 之前先定义你的评估套件（Evaluation Suite）。这是 AI 领域的“测试驱动开发”：评估即规范。

这种做法之所以有效，是因为它迫使团队在开始实现之前就对什么是“正常工作”达成一致。跳过这一步的团队随后会面临一个更糟糕的问题：他们拥有一个质量模糊的线上系统，而现在他们正试图从一个已经背负了利益相关者预期的部署中，逆向工程出成功标准。

从小处着手。从真实的失败案例或代表性场景中提取 20 到 50 个测试用例是一个高效的初始集合。这些用例应包括：

• 典型的快乐路径（Happy-path）输入：任何正常的实现都必须正确处理的内容
• 已知的失败模式：来自类似系统或早期原型测试的经验
• 边缘案例（Edge cases）：探测系统边界的输入，例如超长输入、多语言内容、对抗性措辞、人类能识别但模型可能会遗漏的隐含上下文
• 策略探测输入：旨在测试对抗条件下红线约束的输入

随着生产环境中的失败暴露了新的失败类别，你的评估套件也会随之增长。初始集合不需要面面俱到；它需要诚实地反映你已知的潜在失败模式。

评分方法至关重要。基于代码的评分（例如：输出是否包含 ISO 格式的日期？）最快也最可靠；只要输出包含确定性的子集，就应优先使用。LLM 即裁判（LLM-as-judge）可以大规模处理主观的质量维度；倾向于使用二元的 “通过/失败（PASS/FAIL）”，而不是 1–5 分制，因为“3 分和 4 分之间的区别”在不同评分者或不同会话之间是不稳定的，会产生不一致的数据。人工评分是校准和高风险决策的金标准，但不是大规模生产的主要衡量机制。

组织层面：将评估作为发布要求

技术规范格式解决了定义问题。而组织层面的问题——确保评估确实运行且结果决定是否发布——则需要流程保障。

具有最快 AI 迭代速度的团队都有一个共同模式：对于任何影响模型输出、Prompt 配置或工具定义的拉取请求（PR），评估结果都是必需的交付物。这是一项政策，而非建议。修改系统 Prompt 的工程师需要运行评估套件，并在评审前将结果包含在 PR 描述中。这将质量衡量常态化，使其成为标准开发工作流的一部分，而不是上线前的仓促应对。

一个相关的模式是 PM 对评估框架定义的所有权。当产品经理负责定义什么是“好”——并将其表达为特定维度的具体阈值时——产品与工程之间的协作就从“这感觉对吗？”转变为“它达到我们约定的数字了吗？”。评估成为了产品直觉与工程实现之间带宽最高的沟通渠道。

反模式是将评估视为在发布前不久执行的一次性质量检查。这往往会产生“凭感觉测试（Vibe-check）”陷阱：团队手动测试少量输入，看起来不错，然后就发布了——结果在生产环境暴露真实失败模式后，花两个月时间处于被动响应状态。规范格式和组织流程必须配合使用；缺一不可。

当你跳过这一步会发生什么

兰德公司（RAND Corporation）关于 AI 项目失败的研究指出，需求不明——而非技术失败——是 AI 项目无法交付价值的最常见原因。模型很少是首先失败的环节，通常是需求首先失败。

组织层面的症状显而易见：

• 工程、产品和数据科学团队对“完成”的定义各不相同
• 数月的迭代没有可衡量的改进，因为没有达成一致的衡量标准
• 在事后复盘（Post-mortem）中，核心问题是某个特定的准确率是否可以接受——而上线前没有人做过这个决定
• 在一次公开失败后，利益相关者的信心崩溃，而原本红线规范可以防止这种失败
• 功能在演示当天表现尚可，但从未获得有意义的采用，因为“足够好”从未被清晰定义到足以实际实现的程度

需求差距不是文档问题。这是一个沟通问题，在 AI 领域尤其困难，因为系统的行为是真正分布式的，无法通过传统交付物来捕捉。那些尽早填补这一差距的团队，才能发布质量可预测的 AI 功能——这不一定是因为他们的模型更好，而是因为他们在开始之前就知道自己想构建什么。

一个初始模板

在编写 AI 功能的规范时，在动代码实现之前，先从以下几个部分开始：

策略约束（二元，不可协商）：

• 将每个约束列为一个命名类别
• 记录将探测每个约束的测试输入
• 明确在发布时必须达到零违规

质量维度（概率性，可协商）：

• 针对每个维度：阈值、测试集描述、衡量方法
• 将发布阻断阈值（接近 100% 的回归评估）与愿景式的质量标准区分开

错误分类学（Error Taxonomy）：

• 定义严重程度类别（轻微不便 / 用户可见的错误 / 严重错误）
• 指定各类别之间可接受的分布，而不仅仅是整体错误率

评估支架（Eval Harness）：

• 评估将如何运行，何时运行？
• 谁负责评审结果？
• 开发期间与发布后出现阈值未达标的处理流程是什么？

这一切都不需要新工具或专门的流程。它需要你在实现开始之前，对当输出是分布式的而非确定性的时，功能到底应该做什么保持具体。这种“具体化”就是工作的核心，而且它比其他替代方案成本更低。