第 11 章 价值评估与评测体系：如何算清 AI 的账
“AI 到底给我们带来了什么？”
这是企业管理者最终必然会问的问题。而在 AI 稳定性这件事上，大多数团队没有一个令人信服的答案——他们有感受，有案例，有截图，但没有数字。
这不只是汇报的问题。更深层的原因是：没有评测，就没有改进的方向。 你不知道哪个场景在退化，不知道某次提示词修改是进步还是退步，不知道投入的人力和成本是否值得。
本章分两部分：上半部分讲如何算清成本与 ROI（让你能回答“值不值得”）；下半部分讲如何建立评测体系（让你能回答“好不好”和“有没有在变好”）。
本章职责：为已进入最小闭环的用例定义成本、质量、采用、风险与运行证据，并据此决定扩大、改进、暂停、降级或退役。它不替代第 6 章对任务、样本、人审和回退的首次设计；相反，关键测量口径应在第 6 章启动试点前写入立项卡，不能在试点结束后才挑选有利数字。若无法建立可比基线、说明样本范围或区分已实现收益与容量代理，就不应对外或向管理层宣称 ROI 已被验证。
先用三笔账把讨论说清楚
管理层常用“值不值得”“能替掉什么”“出了问题谁买单”来问 ROI。可以先把这些问题翻译为三笔讨论账，再进入本章的正式 TCO、收益和评测口径：
| 讨论账 | 先问什么 | 必须回到的正式证据 |
|---|---|---|
| 损失账 | 错误、重试、等待、审核、接管、返工和没有被采用的输出，正在增加什么负担或风险？ | 可归属 TCO、失败记录、接管/回退记录及风险事件边界。 |
| 代替账 | AI 实际减少、辅助或转移了哪一个人工动作？它是否只是把负担转给审核者、下游或客户？ | 可比的端到端基线、任务量、采用情况和容量去向。 |
| 验收账 | 输出是否达到事先的质量标准并被实际采用；哪种不可接受错误、边界或回退问题会否决扩大？ | 验证清单、Rubric、代表性样本、人工审核和阶段决定记录。 |
三笔账不是新的财务公式，也不能把探索中的顺利输出、演示或节省小时数直接变成 ROI。它们只帮助不同角色先对齐问题；已实现财务收益、容量价值代理与运行证据仍须按后文口径分别核算。面向更短的管理层说明，可先看ROI 专题页。
立项时还可以保留一项可否定的业务结果或新能力假设：除了节省时间，这项工作若更快、更准或以原来无法覆盖的粒度完成，可能改善什么客户结果、服务水平、收入机会、风险或工作能力；出现什么可观察信号就说明该假设不成立。它不是第四本“账”，也不是收入承诺，只用于避免团队把局部效率当成唯一业务问题。该假设应回写到用例立项卡，并与质量、采用、风险和回退证据一起被否定或保留。
第一部分：算清 AI 的账
一、成本的全貌：不只是订阅费
企业在计算 AI 成本时，最常犯的错误是只算“工具订阅费”。但 AI 工作流的 总拥有成本（TCO，Total Cost of Ownership） 至少应覆盖以下持续成本与按规则分摊的一次性成本：
| 成本类型 | 具体内容 | 容易被忽视的原因 |
|---|---|---|
| 直接工具成本 | API Token 费用、SaaS 订阅费、模型调用费 | 账单上看得见，相对容易统计 |
| 人工验证成本 | 每次输出后人工检查、修改、审核所花的时间 | 没有单独计时，被算进“正常工作时间” |
| 错误修复成本 | AI 输出错误导致的返工、客户投诉处理、危机公关 | 偶发性，容易被当作“例外”处理 |
| 维护成本 | Prompt 更新、知识库维护、人员培训、版本管理 | 分散在多人时间中，难以汇总 |
| 上下文与工具运营成本 | 检索/索引、上下文包、工具/MCP/连接器维护、记忆/状态、日志、评测和变更回归 | 常被隐藏在平台、工程、知识 Owner 和审核人的零散工作中 |
| 实施、共享与退出成本 | 集成、数据准备、迁移、一次性安全/合规审查、共享平台分摊、培训/变革、恢复演练与退役准备 | 常被错误归入其他项目，或只在上线前一次性记录 |
核算公式：
月度 AI 工作流总成本 = 直接工具成本 + 人工验证/接管成本 + 错误处理成本 + 维护成本 + 上下文/检索/工具/记忆与控制运营成本 + 一次性与共享成本的可追溯分摊 + 退出/恢复准备成本注意： 不要跳过“人工验证成本”和“上下文/工具运营成本”。前者包括人工核验、审批、接管和回退；后者包括让 Agent 取得正确上下文、维护连接器、限制工具返回、处理记忆失效、留存日志和运行回归的投入。具体占比必须依据本组织的任务量、风险和运行记录核算，不能仅用模型账单代表总成本。
规模化前先看单位任务和尾部成本
月度总账能说明投入规模，却可能掩盖“任务量增加后是否仍划算”。同一套工作流在低负载时可能主要由固定配置成本构成，在高负载时则可能被长上下文、工具调用、失败重试、排队、人工接管或异常处理拉高成本。不要预设 Token 成本必然不可承受，也不要因为单次 Demo 很便宜就假设可以线性复制；应按完成一个满足质量要求、且被实际采用的任务来观察成本与负担。
单位任务可归属总成本 = 观察期内可归属总成本 ÷ 观察期内通过验证且被实际采用的任务数分母只计入合格且被实际采用的任务；失败、重试、未采用输出、人工接管和异常处理的成本仍保留在分子中。若任务尚处于探索轨，也可以记录“每次尝试成本”和“每次学习得到的结论”，但不得据此宣称运行单位经济性已经成立。
| 要同时观察的量 | 为什么不能只看平均值 | 最低记录方式 |
|---|---|---|
| 每任务输入/输出量与模型、工具调用 | 上下文、模型路由或工具路径变化会改变直接成本。 | 按任务类型记录输入/输出量、调用次数和直接账单口径。 |
| 重试、无效调用与失败任务 | 单次成功案例会掩盖循环、超时和未被采用输出的成本。 | 记录重试次数、失败原因、熔断/终止和是否计入观察期成本。 |
| 人工审核、接管与返工 | 自动步骤变快，可能把负担转移到审核或下游。 | 记录端到端人工分钟数、接管原因和最终处理方式。 |
| 正常负载与高峰负载 | 高峰时的排队、限流、人工可用性和异常比例可能不同。 | 至少按任务量或时间窗口分组比较，而非只汇总一个平均数。 |
| 固定成本与可变成本 | 配置、集成和维护不会与调用量完全同比变化。 | 写明分摊规则，并在任务量显著变化时复算。 |
| 质量、采用与业务结果 | 最低直接成本的路径可能因质量下降而没有真实价值。 | 与本章第二部分的质量、采用、风险和已实现收益证据共同查看。 |
在决定扩大前，业务 Owner、技术 Owner 与使用者至少应能解释：哪类任务的单位成本在上升；失败和重试是否已被完整计入；高峰或异常条件下是否仍有人工接管能力；以及即使单位成本下降，是否因质量、风险或业务结果不成立而应暂停、缩小或换回较低自主性的方式。
二、价值的量化：三种可测量的维度
AI 工作流带来的价值，可以从三个维度量化：
维度 1：时间节省
最直接的价值，也最容易测量。
测量方法：
- 在引入 AI 前，按任务类型、复杂度、人员经验、时间窗口和异常情形记录端到端基线（T_before）。对低风险、同质的探索性试点，可先从少量代表性样本起步；这不是用于财务结论的固定充分样本量。
- 引入 AI 后，在相同或可比条件下记录端到端时间（T_after），包括准备上下文、等待、AI/工具运行、人工验证、修改、审批、接管、返工和必要的回退。
- 容量释放估计 = (T_before - T_after) × 可比期间的实际完成量。若要主张因果改善或做财务决策，应结合分阶段试点、对照组、A/B、前后趋势或其他能处理季节性、任务结构和采用率变化的设计。
常见错误： 只计算 AI 生成时间，忘记计算人工验证时间；或把不同难度、不同人员和不同业务负荷下的平均值直接相减。真实企业现场研究确实使用每小时解决问题数、每周 Pull Request、审查时间、构建成功和错误率等端到端流程数据，但研究也会报告采用率、任务差异和统计局限。1 2
维度 2：质量提升
通常比时间节省更难量化，但对于很多场景（如客服回复质量、文档准确率）更重要。
测量方法（选一种）：
- 对比 AI 辅助前后，客户满意度评分的变化
- 对比人工审核发现错误的频率（错误率下降多少）
- 对比内部评审通过率（第一次提交通过的比例）
维度 3：容量释放
AI 可能让同样的人员在相同时间内处理更多工作，或释放部分容量用于服务、改进或其他任务；这不自动等于可以减少一个岗位、预算或外包合同。
测量方法：
- 记录引入 AI 前后，同一团队处理的任务总量
- 或记录完成同等任务量，所需的人力变化
三、ROI 计算框架
月度投资回报率（Monthly ROI）：
已实现财务 ROI = (已实现财务收益 - 可归属月度总成本) / 可归属月度总成本 × 100%
已实现财务收益 = 已验证的现金支出减少 + 已验证的增量贡献利润 + 经批准口径估算的已避免损失
容量价值代理 = 节省的端到端小时数 × 组织确认的容量价值系数“节省小时数 × 平均时薪”可以作为容量价值代理，但不自动等于已实现财务收益。只有当释放时间确实转化为减少加班、外包、招聘、闲置、现金支出，或带来可验证的处理量、收入、服务水平或风险损失变化时，才可按事先约定的归因规则纳入已实现财务 ROI。未货币化的容量、质量、体验、学习和风险控制应单列呈现，不应为了得出一个 ROI 百分比而强行折算。
教学演算：先把一笔负 ROI 的账算完整
教学情景，数字均为虚构，不是行业基准、建议报价或效果承诺。 假设某客服团队在受控范围内试用 AI 生成工单分类和内部回复初稿；最终对外发送仍由人工客服决定。下表仅演示口径如何填写，不能据此判断任何真实团队的成本、收益或准入资格。
| 月度项目 | 教学填写值 | 计算或记录依据 | 应如何解释 |
|---|---|---|---|
| 直接工具成本 | 2,000 元 | 当月订阅和调用账单 | 只是一项可见成本。 |
| 人工验证/接管成本 | 6,000 元 | 40 小时 × 150 元/小时 | 记录审核、修改、升级和回退，不只记录生成等待时间。 |
| 知识维护成本 | 1,200 元 | 8 小时 × 150 元/小时 | 包括规则、示例、来源或版本更新。 |
| 错误处理成本 | 800 元 | 教学设定的近三月平均值 | 真实项目应使用实际事件记录，不能凭印象补数。 |
| 上下文与工具运营分摊 | 1,000 元 | 教学设定的当月分摊 | 要说明分摊规则，避免重复计入其他项目。 |
| 可归属月度总成本（TCO） | 11,000 元 | 2,000 + 6,000 + 1,200 + 800 + 1,000 | 这是本例 ROI 的分母。 |
| 容量价值代理 | 9,000 元 | 节省 60 小时 × 150 元/小时 | 单列观察；尚未形成现金或经批准的业务结果，不并入财务收益。 |
| 已实现财务收益 | 5,000 元 | 已验证的外包支出减少 | 只有实际减少且归因规则已约定，才可计入。 |
| 已实现财务 ROI | -54.5% | (5,000 - 11,000) ÷ 11,000 | 负值不自动说明项目失败；它说明本月已实现收益不足以覆盖全部可归属成本。 |
这个例子的正确汇报不是“节省了 60 小时，所以 ROI 为正”，而是：“本月可归属全成本为 11,000 元，已实现财务收益为 5,000 元，容量价值代理为 9,000 元，二者没有合并计算。是否继续取决于质量、采用、控制、人工接管和后续可验证的业务结果。”如果该团队无法说明 60 小时最终用于什么、外包支出是否确实减少、错误成本如何取得，或人工审核已超过可接受负担，就应把这些记为不确定项或暂停条件，而不是把示例中的数字替换为乐观估计。
真实填写时，至少要替换四类变量：本组织的人工完全成本与分摊规则、任务量与复杂度、已实现收益的归因证据、以及错误后果和维护投入。数字会因行业、岗位、季节、采用程度和风险控制要求显著不同；本演算用于避免漏算和误并口径，不提供通过线或预期回报。
向管理层汇报的简洁版本：
“本季度，我们在[场景 A]和[场景 B]上运行 AI 工作流。可归属全成本为 X 元；在可比范围内，端到端处理时间变化为 Y，质量/风险指标为 Z。已验证财务收益为 W 元，容量价值代理为 V 元，两者未合并计算。下一阶段是否扩大，取决于预先约定的质量、控制和业务结果闸门。”
这个表述的关键不是把所有收益压缩成单一数字，而是让成本、已实现收益、容量代理、质量和证据边界可以被复核。Klarna 等企业公开案例同时报告处理量、时长、客户体验、容量等价和预计财务影响，说明多维测量在实践中被使用；但其中数值属于当事方披露，不能外推为其他企业的目标或财务结论。3
第二部分：建立评测体系
四、核心指标体系：基础结果与 Agent 运行信号
以下五个指标来自附录 B，构成所有用例的基础结果视图。涉及检索、工具、记忆或 Agent 时，还应增加上下文、工具和接管信号；这些不是跨团队统一 KPI，而是帮助团队识别“最终文本看起来正常、运行控制却已失效”的早期迹象。
| 指标 | 定义 | 目标或触发条件如何设定 | 为什么重要 |
|---|---|---|---|
| 一次通过率 | 输出一次性通过验证清单的次数 / 总执行次数 | 依据基线、错误后果、审核能力和阶段门设定；高影响场景不应仅因平均值达标而放宽控制 | 衡量稳定性的核心指标 |
| 实际采用率 | 被直接或小改后使用的输出数 / 总输出数 | 结合任务覆盖、人工替代方式、用户选择和质量反馈设定；需区分“被接受”与“被迫使用” | 衡量实际业务价值（通过了检查但没人用 = 质量标准脱离业务） |
| 平均总耗时 | 从提交任务到获得可用输出的完整时间 | 与可比人工基线、服务等级、任务难度和审核负担比较，不设跨场景统一比例 | 衡量效率提升 |
| 失败类型分布 | 各类失败原因（幻觉/格式/遗漏/过期知识）的占比 | — | 指导改进方向 |
| 知识更新及时率 | 按时完成知识库更新的次数 / 应更新次数 | 由用例风险、变化速度和 Owner 能力确定 | 衡量知识维护质量 |
| 来源可定位与异常拦截（涉及上下文/Agent 时） | 来源、版本、范围可定位，以及过期、冲突、越权或信息不足被正确停止/转人工的情况 | 由风险边界和 Golden Set 确定 | 衡量上下文是否可解释、可复核、可安全停止 |
| 工具/记忆运行信号（涉及工具/记忆时） | 工具参数/返回异常、无效调用、记忆纠错与失效、接管和恢复情况 | 由运行合约和控制卡确定 | 衡量行动面和状态面是否仍受控 |
每个用例在第一次设指标时，应同时写下三项反证说明：这个指标可能掩盖什么；即使它改善，什么情形仍应暂停或缩小；出现解释分歧时由谁组织核对、谁能基于自身责任阻断继续。 这三项应进入用例立项卡、健康卡或阶段决策记录，不需要另建一套看板。
| 指标组 | 可能误读 | 即使改善仍应暂停/缩小 | 解释与阻断责任 |
|---|---|---|---|
| 通过率、Rubric、失败分布 | 平均值掩盖高后果样本、审核口径变化或未覆盖的失败类型。 | 不可接受错误、关键维度评分分歧、边界/历史失败样本退化，或审核人无法解释结果。 | 业务 Owner 组织业务与 Rubric 核对；知识 Owner 可阻断来源/规则不明的使用；技术/安全 Owner 可阻断控制失效。 |
| 采用率、耗时、成本 | 被迫采用、返工转移到下游、只测生成时长或遗漏维护/风险成本。 | 使用者无法安全审核、人工负担不可承受、业务结果未改善，或以降低控制换取速度/成本。 | 业务 Owner 与使用者解释端到端影响；业务赞助人决定资源；技术 Owner 解释平台和运行成本。 |
| 知识、来源、上下文与运行信号 | 有版本/有日志被误当成仍然有效、仍在授权范围或已经安全运行。 | 来源失效/冲突、权限越界、接管/熔断失效、异常未被记录，或第二使用者无法按资产复现。 | 知识、上下文、技术/安全 Owner 分别解释本领域证据，并可先行停止其负责范围；业务 Owner 负责业务降级与人工替代。 |
五、评分量表（Rubric）：让“好”变得可以测量
一次通过率需要一个前提：明确定义什么样的输出算“通过”。
验证清单给出的是“是/否”判断（格式是否正确、有没有事实错误）。但很多输出的质量是连续的，需要用评分量表（Rubric）来处理。
设计一个 Rubric 的四步法：
第 1 步：确定评测维度
根据任务类型选 3–5 个维度。例如客服回复场景：
- 准确性（信息是否正确）
- 完整性（是否覆盖了所有要点）
- 适当性（语气是否符合品牌调性）
- 简洁性（是否简洁，没有废话）
第 2 步：为每个维度定义评分等级
可从 3 级评分（合格/良好/优秀）开始，也可按任务使用二元、四级或其他可解释等级；等级数不是质量保证。
以“准确性”为例：
- 1 分（不合格）：包含明显的事实错误，或使用了过期信息
- 2 分（合格）：信息基本正确，但有一处模糊表述
- 3 分（优秀）：所有信息准确，表述清晰无歧义
第 3 步：计算综合得分与通过阈值
例如 4 个维度各 3 分，总分 12 分，可以先用 9 分作为教学演示。正式通过阈值应由错误代价、关键维度的最低分、监管/合同要求、人工接管能力和历史样本分布共同确定；不能把 75% 作为通用质量门槛。
第 4 步：定期校验评分一致性
让两个或以上评审人分别对同一批样本评分，检查**评审者间一致性（Inter-rater Agreement）**与分歧类型。可按评分尺度和样本量选择原始一致率、Cohen's kappa、加权 kappa、Krippendorff's alpha 或组内相关系数（ICC）。不存在通用的 70% 通过线；若关键维度分歧会改变发布、对外沟通或高影响决定，应先由业务 Owner 组织澄清 Rubric，知识 Owner 核对规则/来源，适用的技术/安全角色核对控制边界，再培训评审人并复测。分歧、依据和结论应写入评测记录；无法达成可解释结论时，不提升阶段。
六、从人工检查到半自动化评测
纯人工评测在低频场景可行，但当任务量增大时，你需要把部分评测自动化。
可以自动化的评测项
| 检查类型 | 自动化方法 |
|---|---|
| 格式检查 | 用正则表达式检查输出是否符合预定格式（如 JSON 结构、必须包含的字段） |
| 禁止词检查 | 检查输出中是否包含禁止使用的词语或表述 |
| 长度检查 | 检查输出是否在规定的字数范围内 |
| 结构完整性 | 检查必须出现的章节标题、关键词是否存在 |
LLM-as-Judge：用 AI 评测 AI
对于“合理但难以用规则判断”的质量维度（如语气、逻辑连贯性），可以用另一个 LLM 作为评审。
LLM-as-Judge 的标准提示词结构：
你是一个专业评审员。请根据以下评分标准，对以下输出进行评分。
【任务描述】
[说明这个 AI 工作流的任务是什么]
【评分标准】
[粘贴你的 Rubric，含各维度定义和评分等级]
【待评测的输出】
[粘贴 AI 的输出内容]
请对每个维度给出分数（1/2/3）和一句理由，最后给出综合判断（通过/不通过）。LLM-as-Judge 的注意事项：
- LLM 评审本身也有误差，置信度不等于正确性。应按风险分层抽取人工复核样本，并比较一致性、假通过、假拒绝、漂移和高风险样本覆盖；20% 只能作为某些探索性试点的起点，不是通用充分比例
- 不适合用于高风险决策的评测（如判断法律合规性）
- 建议定期用人工重新校验 LLM 的评审标准是否在漂移
七、评测数据的记录与使用
评测的价值，不在于当下的数字，而在于趋势。
最简单的评测记录表（按运行节奏填写）：
| 日期 | 场景/版本 | 执行范围 | 质量与采用结论 | 主要失败/风险信号 | 上下文/工具/记忆变化与异常 | 本期证据如何改变信心 | 本期改进动作与证据 |
|---|---|---|---|---|---|---|---|
| 提高 / 降低 / 暂不改变；依据： |
每次记录都应说明证据让团队对哪一项假设更有信心、降低信心，还是暂不能判断，并写出依据。一次顺利演示、一次异常或一条平均指标都不足以单独推翻或确认用例价值；结论必须结合样本范围、风险后果、人工审核、依赖变化和回退表现更新。若证据无法改变任何判断，通常说明指标、样本或记录方式尚未服务于下一次决定。
三个用评测数据做的最重要的决策：
- 停止或限量：出现不可接受错误、无法解释的质量退化、来源/权限异常、接管失效或证据不足时，考虑暂停扩大、转人工或回退。
- 升级：只有当业务价值、质量、人工审核负担、来源/工具控制、接管和运行证据均满足用例闸门时，才考虑扩大范围或提高自主性。
- 改进：当失败或运行信号呈现重复模式时，针对任务定义、上下文、知识、工具、记忆、验证或培训进行专项改进，并在变更后回归。
评测后的反证式决策卡
维护边界： 本表是本手册关于“继续、缩小改进、暂停或退役”的最低事实、反证问题与解释/阻断权限的唯一权威版本。高管执行摘要只保留管理者应追问的问题，阶段闸门只描述阶段与证据；若未来改动决策规则，应先修改本表，再同步其他入口。
| 决策 | 不能只看什么 | 继续前必须能回答什么 | 记录与决定权限 |
|---|---|---|---|
| 继续或扩大 | 单次回归、平均通过率、节省时间或正向反馈。 | 改善是否覆盖代表性、边界和历史失败样本？人工审核、来源、权限、接管和第二使用者能否承受扩大后的范围？ | 业务 Owner 提出并记录；业务赞助人按授权决定资源/范围；知识、技术/安全 Owner 可阻断各自控制缺口。 |
| 缩小并改进 | “还有一些指标不错”或“已经投入很多”。 | 失败能否定位并回退？是否有修复 Owner、明确依据、回归样本和完成期限？ | 业务 Owner 与相关 Owner 记录范围、修复和下次复核；无可行修复路径时转暂停。 |
| 暂停、回退或退役 | 不愿承认失败、Demo 效果、调用量或孤立的成本收益。 | 是否存在不可接受错误、证据无法解释、关键 Owner/依据/回退缺失，或维护负担超过可验证价值？人工替代是否可用？ | 任何使用者可触发暂停；技术/安全 Owner 可先行停用权限或运行；业务 Owner 决定业务处置并留下理由。 |
八、从单用例数据到组合决策
当只有一个用例时，计算该用例的 TCO、质量和采用率即可。当多个 Skill、工作流或 Agent 同时运行时，管理层还需要回答：哪些用例值得继续投资源，哪些只是局部便利，哪些因为共享知识、共享平台或共享维护人而带来了组合风险。
1. 不要把所有“节省时间”直接相加为财务收益
不同用例的节省时间可能来自同一批员工，也可能只是把工作从一个环节转移到另一个环节。组合汇报时，应区分以下三类信息：一是各用例的流程效率证据，即端到端耗时、返工和处理量变化；二是可被验证的业务结果证据，如客户满意度、积压下降、收入周期、成本避免或风险损失减少；三是尚未货币化的能力建设投入，如知识整理、培训、平台与维护。
因此，组合层面的 ROI 不应简单把每个用例的“节省工时×时薪”累加。只有当时间释放确实转化为可观察的处理量、成本减少、收入改善或风险避免时，才应谨慎作为财务价值汇报；其余可先作为流程和产能证据记录。
1.1 先检查指标会奖励什么行为
指标既是观察工具，也可能改变团队的行为。若管理层只奖励“项目上线、调用量、登录次数、演示效果或看起来节省的时间”，使用者可能倾向于扩大范围、绕过人工检查、隐藏失败，或把工作转移给下游。组合评审至少应把下表中的问题写入记录；这不是评价个人动机，而是检查当前度量会不会把用例推向错误方向。
| 当前被强调的信号 | 可能诱发的偏差 | 应补看的反证或行为证据 |
|---|---|---|
| 调用量、登录次数、已启动场景数 | 为使用而使用，或将不适合的任务硬塞给 AI。 | 哪些任务被正确转人工、暂停或拒绝；是否存在未被采用的输出及其原因。 |
| 生成耗时或表面节省时间 | 压缩审核，或把返工转移到下游。 | 端到端人工负担、返工、异常、接管与业务方实际采用。 |
| 单次演示或正向案例 | 忽略边界、失败和共享依赖带来的成本。 | 代表性/失败样本、回退表现、维护负担与第二使用者复现。 |
当激励与业务结果、可解释质量、正确暂停或安全试错冲突时，业务赞助人和业务 Owner 应先调整本用例的成功口径、资源安排或沟通方式，再讨论扩大投入。不要以更强的汇报压力逼迫团队把不确定信号写成正向结论。
2. 组合评审应做四类决定
| 决定 | 应看什么证据 | 典型动作 |
|---|---|---|
| 加大投入 | 业务价值已验证；质量、采用和维护稳定；可复用资产明确 | 扩大问题类型、使用者或相邻团队；补充支持能力 |
| 继续改进 | 业务问题真实但质量、知识、成本或采纳仍有可修复缺口 | 限制范围，安排明确 Owner 与改进期限 |
| 暂停或降级 | 风险、维护负担或质量问题大于当前收益 | 回退人工流程或降为辅助使用，保留证据与复盘 |
| 退役 | 价值消失、被更优方案替代、维护不可承受或风险不可接受 | 停止权限与运行，归档资产，按政策处置数据与日志 |
用例组合台账、阶段闸门和月度评审模板见附录 A 第 18、20、21 节；第 8 章和第 12 章分别说明扩展节奏与组合治理机制。
3. 把评测结果接入发布与运行决策
一次通过率、Rubric 或单次回归结果本身不是终点。企业需要把“为什么做、怎样运行、如何测试、能否发布、发布后是否健康”连成一条可追溯的控制链：用例立项卡定义业务假设与停止条件；工作流合约定义运行边界；上下文包、记忆合约和工具控制卡定义信息面、状态面与行动面；Golden Set 定义应测哪些真实、边界和失败情形；回归报告比较新旧版本；发布登记限制范围并设观察期；用例健康卡持续判断扩大、维持、改进、暂停或退役。
| 资产 | 它回答的问题 | 使用时点 |
|---|---|---|
| 用例立项卡 | 这个业务问题是否值得做，成功或停止意味着什么 | 设计前与阶段变更前 |
| 工作流合约 | 流程怎样运行，谁在何处验证、接管和回退 | 多人试点或正式运行前 |
| 上下文包、记忆合约与工具控制卡 | 此刻允许依据什么、可保存什么、可查询或执行什么，以及如何限制和回退 | 设计、试点、连接器接入或高影响变更前 |
| Golden Set | 什么样的正常、边界、失败和异常行为必须被验证 | 试点、变更和事件复盘前 |
| 回归报告 | 新版本相对稳定版本是否退化，是否可发布 | 变更、修复或阶段提升前 |
| 发布登记 | 允许谁在何范围使用，何时停止和如何回退 | 每次受控上线或范围扩大时 |
| 用例健康卡 | 当前业务价值、质量、成本、风险和维护是否仍支持继续运行 | 与用例运行频率、风险和变更节奏相称的运行会与组合评审 |
附录 A 第 25、26、29、30、31、32、48–51 节分别提供这些资产。它们不要求每个低风险内部试点都做成复杂项目：范围越小、风险越低，记录越轻；但涉及对外沟通、写入、权限扩大、敏感数据或高影响决策时，证据和审批也必须随之加强。
九、本章行动清单
本月建立基础：
- [ ] 计算你当前最主要 AI 场景的 总拥有成本（包含验证时间成本）
- [ ] 在下一轮试点前只选择 1–3 个阶段指标，写清基线、样本范围、记录责任人、阈值和暂停条件；同时写下可能误读、即使改善仍需暂停的情形，以及解释分歧的组织/阻断角色；第 6 章的最小闭环不得等待本章读完才开始测量
- [ ] 为该场景设计一个 3–5 维度的评分量表（Rubric）
- [ ] 从真实或脱敏历史任务中建立一个最小 Golden Set，至少覆盖正常、边界与历史失败样本
- [ ] 按用例运行频率、变更节奏和风险等级填写评测记录，直至覆盖足以支持阶段决策的正常、边界、失败和变更样本
- [ ] 为下一次 Prompt、上下文包、知识、记忆、模型、工具或连接器变更预先指定回归报告、发布登记和回退版本
建立向管理层汇报的能力：
- [ ] 用本章的 ROI 公式，计算你运行时间最长的那个 AI 场景的季度 ROI
- [ ] 准备一份不超过一页的 AI 价值汇报模板，包含：成本、价值、质量指标、下一步改进计划
当重复频率、人工评测负担或变更速度已使人工全量检查不可持续时：
- [ ] 为格式、禁止词、结构完整性等确定性要求建立自动化检查，并验证其漏报与误报
- [ ] 评估是否可以引入 LLM-as-Judge，并按风险分层设计人工校验、漂移监测和停止条件
本章小结
算清 AI 的账，需要同时看两个维度：成本的全貌（不只是订阅费）和价值的量化（不只是感受）。
评测体系的建立，不需要一步到位。从按运行节奏填写一张简单的评测记录表开始，然后逐步引入 Rubric、自动化检查和 LLM-as-Judge。
最重要的一点：评测数据是用来做决策的，不是用来证明 AI 的价值给领导看的。 如果数据告诉你一个场景在退化，你就需要根据数据做出停止或改进的决策，而不是选择性地只汇报好看的数字。
证据不足时的正确表述： “我们观察到一个待验证的时间、质量或采用信号，尚不能将其视为财务收益或扩大依据。” 先缩小范围、补齐基线与样本，再决定是否继续；不把未经验证的容量估计、Demo 或单次成功写成 ROI 结论。