AI Native Builder

主题

第 8 章｜用评估与治理证明系统可控 ​

澄川项目组第一次汇报评估结果时，首页写着“24 条样本，20 条通过”。业务经理看完说：“已经八成多了，可以找几名销售试用。”

负责评估的同事没有同意。四条失败里，一条是客户原话被错误写成了成交日期建议；一条在写入结果未知时创建了第二个沙盒任务；还有一条把完整会议转写留在调试轨迹中。把这些失败和普通措辞错误放进同一个平均分，会得到一个好看的数字，也会作出危险的决定。

第 7 章证明系统能够在沙盒运行、停止和恢复。本章要回答更严格的问题：它在不同输入、不同故障和不同权限下，是否仍按约定行动？若答案是否定的，团队能否在影响真实用户之前发现、定位并阻止发布？

本章继续使用“澄川工业客户跟进助手”这一取材于内部实践的原创复合案例。样本、版本、运行结果、人数与阶段决定都是教学材料，不代表真实企业结果或行业标准。

评估对象是整套系统 ​

模型可以生成正确字段，工具却写错商机；模型也可以给出错误建议，而字段白名单及时拦住副作用。只看最终文本，会把这两种运行判成相反的结果。

澄川把一次评估任务拆成四个观察面。结果面检查字段建议是否符合事实、来源和业务语义；轨迹面检查系统用了哪些资料、工具和状态转换；环境面核对 CRM 最终是否发生预期变化；治理面检查身份、权限、人审、日志和停止机制是否真的生效。

一个测试样本因此不再只是“问题加参考答案”。它还需要初始环境、允许路径、禁止动作和最终状态。对于写入结果未知的样本，正确答案可能不是成功写入，而是保持 unknown、禁止再次提交并交给状态查询。

Anthropic 关于 Agent 评估的实践文章区分运行过程记录和最终环境结果：系统声称“预订成功”，不能替代环境中是否存在真实预订。这个区分也适用于澄川。工具返回一句 success，仍要由沙盒记录和写入凭据证明。

成功标准要在看到结果前写下 ​

如果团队先运行，再根据最好看的结果决定“什么算通过”，评估会变成解释成绩。澄川先写任务成功标准，再组装样本和评分方法。

字段建议要满足三个条件：只包含允许字段；每个事实能回到会议或批准资料；客户原话、公司能力和销售判断不能混成一种事实。没有足够依据时，系统应显示待确认或阻塞，不按语言流畅度补齐。

工具行为另有标准。预览不得产生写入；提交必须拥有有效审批、字段白名单、目标环境和记录版本；相同业务意图复用同一幂等键；外部结果未知时禁止创建新意图。最终状态必须能由 CRM 记录或写入凭据核对。

高风险失败直接阻止试点。任何未授权正式环境写入、重复副作用、敏感信息越界、绕过人工批准或对外承诺都必须先修复。普通字段遗漏可以进入修复清单，高风险失败不能用其他样本的高分抵消。

项目组还写下允许误差。辅助型流程本来就包含销售审阅，因此措辞修改不一定代表失败；若修改改变事实、责任人或业务状态，则属于实质错误。评审者必须记录修改类型，不能把所有编辑都算成同一种“人工改写率”。

这些门槛只服务于当前四字段、人工确认的 CRM 场景。若系统以后获得发信、报价或自动改阶段的权限，风险等级和成功标准必须重新评审。

用风险和真实任务组织样本 ​

项目组没有从网上找一批通用销售问题。第 5—7 章已经留下会议片段、资料冲突、人工修改和工具故障，这些材料成为首批评估任务。

首轮评估集有 24 个任务规格。这个数量只是为了让教学案例能够覆盖当前风险，不是统计充分性的保证。系统越成熟、任务分布越复杂，样本和重复试验都应增加。

类型数量澄川要验证的行为
正常8四个允许字段能引用正确来源并进入审阅
边界5模糊日期、缺负责人、否定表达不会被强行补全
上下文4资料缺失、过期或冲突时正确阻塞
工具故障3超时、记录版本变化和状态未知能够停止与恢复
权限与对抗2提示注入、越权环境和禁止字段被拒绝
历史回归2已修复的重复写入与错误来源不会再次出现

样本要覆盖正反两个方向。若只测试“该写入时能否写入”，团队可能把系统调成凡事都提交；还要测试“不该写入时能否停下”。同样，既要测试资料冲突会阻塞，也要测试资料一致时不会无故拒绝。

每个任务至少保存样本编号、来源类型、输入与初始状态、期望环境结果、允许路径、禁止动作、风险级别、评分器和数据版本。来自真实工作的材料必须先获得授权并脱敏；虚构或合成样本要保留标签，不能混进真实事件统计。

模型参与的环节存在随机波动。澄川对高风险和历史回归任务运行多次试验，分别报告“至少一次成功”和“每次都成功”的含义，不把挑出一次好结果当作稳定性。具体重复次数由风险、成本和决策用途决定。

四类评分器各自看一部分 ​

字段白名单、JSON 结构、审批身份、记录版本和最终 CRM 差异都能用代码判断。它们有清楚的真值，不需要让另一个模型凭印象打分。

客户需求是否准确、风险备注是否遗漏、行动项是否保留语气限制，需要业务人员按照量规判断。评审页面并排显示会议片段、原值、候选值和人工修改，避免专家只凭最终文案回忆上下文。

模型评分器适合先筛查大量开放文本，例如依据是否相关、需求是否覆盖，但它本身也会波动。项目组先用一组人工共识样本校准提示和评分锚点，再对高风险分歧进行人工复核。模型评分不能批准自己的高风险动作。

用户行为要到试点中观察。离线评估可以判断建议是否符合预期，不能证明销售愿意审阅、任务变快或业务结果改善。因此，本章只判断“是否可以开始受控试点”，业务价值留给第 9 章。

把评分器组合起来后，一个样本可以同时得到多种结果：规则检查通过，语义质量需要修改，环境状态正确，风险控制生效。团队保留分项结果，不急着压成一个总分。

第一次评估为什么没有通过 ​

EVAL-CC-01 运行工作流版本 0.3。24 个任务中，20 个按预期完成。两条普通失败来自语义判断：模型把客户设想的长期目标写成当前需求，又把外部联系人误作内部行动项负责人。

第三条是工具故障样本 T-018。第 7 章已经验证过“提交响应超时、状态查询找到凭据”的路径；这次故障让提交和随后的状态查询都超时。变更单进入 unknown 后，界面却重新启用了提交按钮。

测试脚本模拟用户再次点击。前端创建了新的幂等键，沙盒出现第二个任务。第一层超时处理正确，第二层恢复路径破坏了“未知状态不得创建新业务意图”的不变量。

第四条来自调试设置。为了排查资料检索，开发者临时打开完整载荷记录，T-022 的会议转写因此进入普通应用日志。访问者虽然仍是项目成员，但日志的用途、权限和保留期都超出了会议授权。

这两个结果都要求停止试点准备。团队没有发布“83% 通过”的结论，而是记录返工决定：重复副作用由技术负责人修复，日志越界由技术与数据负责人共同处理。业务经理看到的不再是一张总分图，而是风险、环境结果和责任人。

修复要进入回归，而不是停在说明里 ​

工作流版本 0.4 改了未知状态的所有出口。只要提交结果尚未协调，变更单保持冻结；界面和服务端都拒绝新提交。状态查询只有三种结论：找到原凭据并协调成功、明确确认未执行后使用原幂等键重试、仍未知并转人工。

日志改成字段白名单。常规轨迹只保存来源编号、必要摘要、状态和工具参数摘要；完整载荷进入受限的短期故障存储，并有访问审批与删除期限。审批令牌、凭证和无关会议内容永不进入普通轨迹。

修复没有只跑 T-018 和 T-022。项目组重跑全部 24 个任务，并重复执行高风险与历史回归任务。两条语义问题也被转成新回归样本，避免修复工具后忽略输出质量。

第二次运行中，22 个任务产生了可直接审阅的建议，另外两个按设计阻塞并转人工。若只看“生成了建议的比例”，这两个像失败；按任务契约看，它们没有足够依据，停止才是正确结果。所有设计中的高风险控制样本都按预期结束，但这仍不等于真实世界不会出现新风险。

治理必须出现在运行路径中 ​

NIST AI RMF Core用 Govern、Map、Measure、Manage 四个词组织 AI 风险管理，把治理当作贯穿整个生命周期的活动。放到澄川这里，这些词只有落到角色、配置和状态上才有用。

Govern（治理）解决的是谁能拍板的问题。业务负责人批试点范围，销售对提交内容负责，内容负责人维护资料，技术负责人管适配器，数据和安全角色定日志和授权规则。“项目很紧急”不能成为跳过专业审批的理由。

Map（映射）搞清楚用途和影响范围。当前系统只帮销售准备四个内部字段，人确认后才调确定性写入；不报价、不改商机阶段、不发外部消息。数据、动作、受影响对象都写进风险登记。

Measure（度量）就是本章讲的评估和监控：团队分别检查输出、轨迹、环境状态和人工决定，失败样本也保留。Manage（管理）则把发现的问题落实为动作——权限调整、停止、回退、事件处理、版本决定。

治理控制不能只写在项目说明中。字段白名单存在于服务端；试点用户和商机存在于权限策略；人工批准存在于 Approval 对象；停止开关能撤销写入身份；日志保留策略由存储配置执行。评估要测试这些控制是否能被绕过。

用一次事件演练检查“出事以后” ​

决定是否开始试点前，项目组没有刻意制造一次真实事故，而是在沙盒运行事件演练。演练材料假设某次更新疑似写入了禁止字段，并且监控在五分钟后报警。

值班人员先停用写入工具，把工作流降为只读预览，保留相关版本和轨迹。业务负责人核对受影响的商机范围，技术负责人查询写入凭据与实际差异，数据负责人检查是否有敏感内容进入日志。

演练发现通知名单里没有 CRM 管理员。即使团队查清原因，也没有人能及时批量核对和恢复记录。项目组补上角色、联系方式与授权动作，再重复演练，直到停止、调查、修复、恢复和通知都有人负责。

事件响应还要留下新的评估任务。若复盘只写“加强测试”，下一版仍无法检查改进是否存在。澄川为禁止字段、报警时延、工具降级和恢复权限分别增加了可执行检查。

演练检验的是团队在模拟条件下能不能按流程走通，真实出事时未必完全一样。但演练能提前发现通知名单缺人、权限不够、工具不好使这些问题，不必等到真出事才手忙脚乱地补。

当前系统可以进入小范围试点吗 ​

这是一次试点前评审，不是安全认证。评审者要同时查看评估版本、失败分类、权限配置、日志样本、故障运行和事件演练，不能只读一页汇报。

澄川团队决定“有条件开始辅助型试点”。试点只覆盖四名已授权销售、选定的现有商机和四个内部字段。AI 继续只提供建议和准备变更预览；销售确认后，确定性工具才获得一次性、字段受限的正式 CRM 写入权限。

价格、预计成交日期、正式商机阶段和外部消息继续禁止。每次写入都保留审批、幂等键和环境凭据；未知状态自动冻结；项目组在试点期间提供工作时段支持，并能随时撤销写入身份。

试点条件还包括：每日复查高风险轨迹，按周重跑回归集，任何未授权写入、重复副作用或敏感信息泄露立即停止；来源冲突与记录版本变化继续转人工。扩大试点前，团队必须根据真实使用和净价值重新作出决定，不能沿用本次结论。

这次评审没有证明用户会采用，也没有证明净价值为正。它只说明在当前样本与演练范围内，主要风险拥有可测试的控制，团队可以在有限真实任务中继续收集证据。

常见的评估假象 ​

第一种假象是只收集正常样本。跑出来全是对的，演示很漂亮，但真实输入里会出现的缺失、冲突、注入和权限变化一个都没测到，上线之后全是“新问题”。

第二种是只给最终答案打分。系统可能从错误资料里碰巧得出正确结论，或者文本生成对了但对象写错了——答案看着对，其实是危险的。轨迹和环境状态要分开查。

第三种是让一个模型给所有东西打分，等于把评分器自己的偏差当成了统一标准。能用代码确定对错的交给代码，需要专业判断的交给领域人员，模型评分可以用来扩大覆盖面，但必须校准。

第四种是用平均分处理风险。大量简单样本会把少量严重失败淹没掉。评审时先查有没有必须停下来的问题，再谈整体质量和可接受误差。

还有一种假象是觉得日志开得越多越安心。记录过量本身就是数据风险。轨迹只需要回答谁、在什么时候、用了什么版本、执行了什么动作、环境发生了什么变化；其他内容按故障排查需要单独授权。

把方法迁移到合同初审 ​

合同初审辅助系统也可以有很高的“准确率”，却漏掉一条高风险责任限制。若团队只统计条款识别平均分，这条遗漏会被几十条普通格式检查抵消。

更合适的评估先定义不可接受行为：自动批准、未引用当前模板、跨客户读取合同、把不确定条款写成确定结论。正常样本检查常见差异，边界样本检查复杂引用，权限样本检查项目隔离，故障样本检查条款库不可用时是否停止。

结果评分可以判断差异是否完整，轨迹复核检索了哪版模板，环境检查确认系统没有推进审批。法务人员校准语义量规，代码检查权限与状态。通过评估仍只支持受控初审，不能替代授权法务决定。

你的练习 ​

继续使用第 7 章的最小方案。先选择一个下一阶段必须作出的决定，再为它写清成功、允许误差和必须停止的问题。不要先定一个想要的通过率，再寻找容易通过的样本。

建立一组正常、边界、上下文、工具故障、权限或对抗样本。数量由任务分布和风险决定；若只做教学练习，可以从能够覆盖当前主要失败的最小集合开始，并明确它尚未证明什么。

为每条样本写初始状态、预期结果、允许路径、禁止动作和评分器。至少安排一次结果正确但轨迹错误的样本，以及一次模型文本看似失败、系统安全停止的样本。

运行评估后，选两条失败沿轨迹找到第一个偏离点。修复后重跑相关样本和核心回归集，再完成一次停止、通知、调查和恢复的桌面或沙盒演练。

你可以使用练习册中的评估样本和治理与事件演练，记录评估样本、权限、事件和是否开始试点的决定。

怎样判断答案是否合格 ​

先看必须停止的问题。任何越权、敏感数据泄露、重复副作用或无法停止的高风险路径，都不能由其他样本的高分抵消。

然后随机抽一条失败，请没有参与构建的人根据材料说明：预期是什么、首个偏离点在哪里、外部状态怎样、谁负责下一步。若只能听作者口头解释，轨迹还不够完整。

再改变一个版本：模型、指令、资料或工具任选其一。若评估不能说明需要重跑哪些样本，回归机制仍停留在“以后注意”。

合格作业最后应产生一个明确决定：通过、有条件通过、返工、暂停或终止，并写出范围、条件、负责人和下一次复审触发点。

本章小结：可以受控试点，不等于已经产生价值 ​

澄川没有被“20/24”说服。团队沿轨迹发现了未知状态下的重复写入风险和日志越界，修复状态机与日志策略，再用回归和事件演练验证控制。

团队最终只同意开展一个覆盖四个字段、保留人工确认、可以随时停止的辅助型试点。第 9 章将进入真实任务，观察谁尝试、谁采纳、谁放弃、谁绕开，并把节省时间与审阅、支持、风险和维护成本放在同一份决定里。

下一章：从试点到真实采用

本章来源与框架边界 ​

四个观察面、24 个样本、必须停止试点的失败和试点决定，是本书针对教学案例设计的方法，不代表上述机构给出的统一测试数量、通过条件或认证。真实项目应根据用途、风险、任务分布和组织要求设计评估，并接受相应专业评审。