AI 项目需求与验收：从业务目标到可测试指标

AI 项目需求不能只写“接入大模型，让回答更智能”。可交付的需求必须同时说明业务目标、目标角色、使用场景、输入输出、非目标、风险边界和衡量指标；验收则要用固定样本、明确阈值、人工规则和系统性约束证明这些目标是否达成。

先说结论

一份可执行的 AI 项目需求至少回答六个问题：

1. 为什么做：要改善哪项业务结果，当前基线是什么；
2. 谁来用：目标角色拥有什么数据权限和决策责任；
3. 何时使用：触发场景、前置条件和主流程是什么；
4. 系统交付什么：输出格式、证据、置信处理和失败反馈；
5. 明确不做什么：自动化边界、高风险禁区和本期范围；
6. 如何证明完成：离线质量、线上业务、性能、成本与安全如何验收。

本文只解决“做什么、做到什么程度算完成”。它不解释 Agent 内部运行机制，也不替代具体 RAG、模型 Client 或部署方案。技术架构应在需求和验收边界确定后选择。

适合谁，不适合谁

本文适合：

• 需要把“做一个企业知识库/客服助手/Agent”变成开发任务的产品与技术负责人；
• 已经做出 Demo，却无法说明是否达到上线标准的开发者；
• 准备用可验证材料展示 AI 项目能力的求职者。

你原来的工程经验就是起点：前端和客户端经验可用于定义交互与人工接管，后端经验可用于权限和一致性，测试经验可用于评估集与回归，运维经验可用于容量、观测和回滚。

本文不适合：

• 已有完整需求，只想实现某个模型 API 的开发者；
• 只想了解 Workflow、Agent 与多 Agent 如何选型的人；
• 需要通用 UI 原型或传统 CRUD 字段说明的人。

为什么 AI 项目更容易在验收时失焦

传统系统常能用确定输入对应确定输出来验收。AI 输出具有概率性，同一问题可能有多种合格答案，也可能语言流畅但事实错误。因此不能只验收“接口返回 200”或“页面能对话”，而要同时验证：

• 任务质量：答案是否正确、完整、有依据；
• 系统行为：不确定时是否拒答或请求澄清；
• 业务效果：是否真的节省时间、提高解决率或降低错误；
• 工程约束：延迟、成本、权限、安全和可追踪性是否达标。

边界也很重要：指标不是越多越好。每个指标都应能对应一个业务风险或决策，否则只会增加评测维护成本。

需求模板：从目标到边界

1. 业务目标与当前基线

不要写：

建设智能客服系统，提升用户体验。

改写为：

面向售后客服，在不自动执行退款的前提下，为标准售后问题生成带知识来源的回复草稿。目标是缩短客服查找资料和起草回复的时间；首期先记录建议采纳率、单工单处理时长和人工纠错类型，以上线前两周人工流程数据作为基线。

如果还没有可信基线，不要编造“提升 50%”。先把“采集基线”写成上线前任务，再根据试运行结果设置阈值。

2. 用户角色与权限

同一个“客服助手”至少可能涉及：

角色	需要的能力	不应获得的能力
一线客服	查询公开知识、生成草稿	查看其他租户数据、直接退款
主管	查看质检统计、审批高风险建议	修改系统审计记录
知识管理员	发布和下线知识	代替客服处理订单
运维人员	查看调用链和脱敏日志	在日志中读取完整敏感信息

角色定义必须落到数据范围和动作权限，不能只写岗位名称。

3. 场景、输入与输出

用“当……系统应……”描述主场景：

当一线客服打开一个包含订单号的售后工单时，系统应在当前客服有权访问该订单的前提下，检索有效知识，生成一份回复草稿，并为关键结论附上来源。若订单号缺失、权限不足或知识冲突，系统应明确提示原因，不得编造订单状态。

需要明确：

• 输入来自哪里，哪些字段必填；
• 输出给谁，结构是文本、JSON 还是待确认动作；
• 引用、时间和数据版本如何展示；
• 缺失、冲突、低置信与超时如何处理。

4. 非目标

非目标用于阻止范围悄悄扩张。示例：

• 首期不自动发送回复，只生成草稿；
• 不处理退款审批、赔付承诺等高风险决策；
• 不回答知识库之外的通用问题；
• 不训练自有基础模型；
• 不承诺覆盖所有历史工单语言。

反例：“系统应尽量回答所有问题。”这既无法验收，也鼓励模型越过证据边界。

5. 约束与依赖

至少记录：

• 可使用的数据源、数据责任人和更新频率；
• 模型或供应商是否允许处理目标数据；
• 峰值请求量、响应时间和预算边界；
• 登录、租户隔离、审计和保留期限；
• 人工确认、回滚与降级路径；
• 外部系统不可用时的用户体验。

指标体系：不要只看“准确率”

离线任务质量

根据任务选择指标，不要机械套用：

任务风险	可用指标	注意事项
知识问答	事实正确、引用支持、问题覆盖	流畅度不能替代事实性
信息抽取	字段级精确率、召回率、格式通过率	关键字段可设置更高权重
分类路由	各类别精确率、召回率、混淆矩阵	关注少数但高风险类别
Agent 执行	任务成功率、步骤数、工具错误恢复率	必须检查副作用是否正确
内容生成	规则符合率、人工采纳率、修改类型	“看起来不错”不可复现

离线评估集应包含正常样本、边界样本、对抗样本和失败样本，并保存期望行为。期望行为不一定是给出答案，也可以是拒答、澄清或转人工。

线上业务指标

上线指标要能回答“用户是否因此做得更好”，例如：

• 建议采纳率及采纳前修改比例；
• 单任务完成时长；
• 一次解决率和转人工率；
• 因 AI 建议导致的返工或投诉；
• 不同角色、场景下的使用率。

线上指标容易受用户结构、季节和流程变化影响，不能把所有变化都归因于模型。至少保留发布版本、对照时间段和样本量。

系统性指标

包括端到端延迟、超时率、可用性、单任务成本、缓存命中、限流、敏感信息泄露、越权调用和审计完整率。具体阈值应根据业务基线和风险设定，不应复制别人的数字。

一个完整验收示例

以下示例用于展示结构，数值需要项目团队用真实基线确认。

项目：售后知识回复助手

业务目标

在不自动发送、不执行退款的前提下，减少客服查找知识和起草标准回复的时间，同时保证关键结论有可访问的有效来源。

目标角色

拥有目标工单和订单读取权限的一线客服；知识管理员负责测试集答案和来源有效性。

非目标

• 不直接向客户发送消息；
• 不进行退款、赔付或责任判定；
• 不使用已失效或客服无权访问的知识；
• 不用生成结果替代主管审批。

验收数据

• 从真实问题脱敏形成固定评估集；
• 按常见问题、资料缺失、知识冲突、越权请求、诱导指令分层；
• 评估集版本冻结，新增线上失败样本进入下一版本，不能静默修改旧样本期望。

功能验收案例

Given 客服有权访问订单 A，且有效知识明确说明七天退货条件
When  客服请求生成该订单的退货咨询回复
Then  系统生成草稿，引用有效知识，区分已知订单事实与政策条件
And   不承诺退款结果，不自动发送消息

Given 客服无权访问订单 B
When  请求根据订单 B 生成回复
Then  系统拒绝读取与生成订单结论
And   记录授权失败事件，但日志不包含订单敏感详情

Given 两份有效知识对同一政策表述冲突
When  请求生成确定答案
Then  系统不自行选择有利版本
And   展示冲突来源并转交知识管理员

质量验收

• 由业务负责人确定关键结论正确率和引用支持率阈值；
• 高风险样本单独设门禁，不允许被大量简单样本平均掩盖；
• 格式、拒答、澄清和越权行为使用自动规则检查；
• 开放式答案由至少一名业务评审按统一量表评分，争议样本记录原因。

工程验收

• 在约定并发下记录延迟分布、超时率和单任务成本；
• 所有模型、检索和工具调用具备可关联的追踪 ID；
• 敏感字段在提示、日志和评测数据中按规则处理；
• 模型或数据源不可用时降级为原人工流程；
• 新版本未通过回归集时不能扩大流量。

把验收变成发布门禁

推荐四层门禁：

1. 静态门禁：提示模板、Schema、权限配置和敏感字段规则检查；
2. 离线门禁：固定评估集对比当前版本与候选版本；
3. 影子或小流量门禁：不影响真实决策或只向少量用户开放；
4. 扩大流量门禁：业务、质量、性能、安全指标均未恶化再逐步放量。

每次评测要保存应用版本、模型配置、提示版本、知识版本和评估集版本。否则“上周通过、今天失败”时无法判断哪一层发生变化。

常见误区与失败边界

误区一：把功能列表当需求

“支持对话、知识库、Agent、MCP”只是技术名词清单，没有说明用户任务。先写用户在什么条件下获得什么结果，再决定是否需要这些能力。

误区二：只验收几个演示问题

演示样本通常已被开发者反复调试，不能代表真实分布。验收集要分层抽样，并加入缺失信息、冲突、越权和提示注入等反例。

误区三：用平均分掩盖高风险错误

系统可能在 99 个简单问题上正确，却在一个退款问题上越权承诺。高风险类别应独立设门禁，必要时要求零容忍或强制人工确认。

误区四：需求阶段承诺未经验证的提升

没有当前基线、样本和试运行数据时，精确承诺收益只是猜测。可以先承诺采集方式、评估流程和上线决策规则，再用真实数据确定目标值。

失败边界

出现以下情况应暂停开发或缩小范围：

• 业务负责人无法定义什么是合格输出；
• 没有合法、可维护的数据源；
• 错误后果高，却没有人工兜底和回滚；
• 无法获得代表性评估样本；
• 只要求“替代多少人”，却不描述任务质量和责任边界。

可执行检查清单

需求完整性

• [ ] 业务目标对应可观察的当前问题
• [ ] 当前基线存在，或已安排基线采集
• [ ] 目标角色、数据范围和动作权限明确
• [ ] 主场景、异常场景、输入和输出已定义
• [ ] 非目标与高风险禁区已写入范围
• [ ] 数据、模型、外部系统和人工流程依赖已确认

验收设计

• [ ] 每个业务目标至少对应一个结果指标
• [ ] 评估集包含正常、边界、失败和对抗样本
• [ ] 正确回答、拒答、澄清和转人工都有期望行为
• [ ] 高风险类别独立设门禁，不只看平均分
• [ ] 延迟、成本、权限、安全和审计均有验收项
• [ ] 指标阈值来自业务风险或真实基线，并记录负责人

发布与回归

• [ ] 应用、模型、提示、知识和评估集均可追踪版本
• [ ] 候选版本与当前版本在同一评估集上比较
• [ ] 上线采用影子、小流量或分阶段放量
• [ ] 失败时可降级到确定流程或人工处理
• [ ] 线上失败样本经过审核后进入回归集

下一步

回到 AI 项目 Hub 按目标选择下一步：企业知识库方向进入 RAG 项目，工具型 Agent 方向进入 AI 面试官 Agent，AI Coding 方向进入 AI Harness 工程化。先让需求和验收决定架构，再选择模型与框架。