如何给公司做AI赋能--指标体系、安全门禁与成熟度阶梯
目录
《给公司做 AI 赋能》系列第 2 篇
”效果不错”不是目标
AI 项目的目标定义有个特殊的难处:传统软件的正确性是确定的,而 agent 的行为是概率的。很多团队因此走向两个极端——要么放弃量化(“大模型嘛,看感觉”),要么套用传统指标然后被反噬(用请求成功率衡量一个会礼貌地答错问题的系统)。
我们的做法是把目标拆成三层:**日常度量什么、发布卡什么、授权升级凭什么。**三层各有各的刻度,混在一起就会出事。
第一层:五大日常指标
- 任务量(按来源分类):变更工单、告警、状态同步、聊天里的临时请求,各多少。这是先行指标,不是质量指标——量大而成功率低,比量小而成功率高更糟。
- 任务成功率:DE 处理的任务中,不需要”上报即失败”兜底、也没有产生 bad case 的比例。关键细节:目标值按场景成熟度分层设定,不设全局常数。一个刚晋升到 AI-led 的场景,理应比一个稳定运行数月的场景承受更宽容的标准。
- 守护栏通过率:安全/合规/边界类测试的通过率。这个指标只有一个可接受的值:100%。守护栏没有”基本没问题”这一档——一条守护栏要么被强制执行,要么没有;任何一条失败都阻断发布。
- 技能触发精度:每个技能双向度量——该触发时触发了吗(真阳性率),不该触发时忍住了吗(假阳性率)。后者常被忽略,但更危险:从不触发的技能只是没用,过度触发的技能会在错误的输入上采取行动,并且持续消耗团队信任。
- 节省时间估算:每类任务估算”每单节省的人·分钟”,乘以量。诚实的用法是把它当方向性指标用于排优先级,不当成预算数字去承诺 ROI——它回答”DE 在哪里最省注意力”,不回答”值多少钱”。
单看任何一个数都会误导:量告诉你 AI 活跃在哪,成功率和守护栏告诉你这种活跃可不可信,触发精度告诉你活跃得对不对,时间估算把一切翻译成非技术干系人能权衡的语言。我们给周期报告立了条解读规则:量在涨而成功率持平或下跌,信号是暂停扩张,不是庆祝吞吐。
对机器的守护栏零容忍,对成长中的场景分层宽容——这个搭配不是技术设定,是价值观:**严格留给不可协商的底线,耐心留给正在学习的东西。**对人的团队,其实也该这样。
第二层:四条发布门禁
技能是版本化发布的软件,每个版本上线前过四道门,全部是硬性门禁而非建议分:
| 门禁 | 要求 |
|---|---|
| 场景覆盖 | 100%——声称能处理的每个场景,在快乐路径、错误路径、典型/边缘路径,以及每个适用的守护栏类别里各有至少一条测试用例 |
| 用例通过率 | 100%——没有”已知 flaky”豁免 |
| 对上一版不回退 | 新版本的成功率必须 ≥ 上一发布版——加了新能力也不许在老能力上倒退 |
| bad case 修复率 | 上一版本遗留的、发布时仍开放的 bad case,100% 修复并验证后才许发新版 |
前两条由评估框架在 CI 里自动检查,后两条依赖 bad case 追踪器在发布评审里人工核对。有人会觉得 100% 的覆盖和通过率太苛刻——我的经验是,对 agent 这种行为有随机性的系统,恰恰因为运行时你控制不了它,构建时的确定性一分都不能让。
Bad case:每一次失败都要变成一条回归测试
指标体系的backbone不是仪表盘,是 bad case 的闭环生命周期。每一次 DE 失败——答错、该拦没拦、不该上报的上报——走六个阶段:
发现上报 → 导师确认并分类 → 责任人修根因(是 KB 缺页、触发没中、工具调错,还是守护栏缺失——修根因,不是修症状)→ 导师沙箱复验 → 固化为评估框架里的永久测试用例进 CI → 关闭(此后回归测试再失败则自动重开)。
不可协商的一条规则:没有变成回归测试的 bad case 不算关闭——它只是在安静地等待复发。这条规则也让第二层的”bad case 修复率”门禁有了抓手:追踪器不是问题日志,是发布流程的一部分。
注意这个流程里”导师”出现了两次。让资深工程师做 AI 的导师而不是 AI 的监工,是这套机制里最被低估的设计:确认 bad case 需要判断”这是真缺陷还是对预期行为的误解”,复验需要经验,而这两件事恰好让人的专业判断留在了回路的关键位置上。
第三层:成熟度迭代——授权是挣来的,而且可以收回
场景(注意:是场景,不是整个技能,更不是整个 DE)分三层成熟度:
- human-led:DE 辅助——取证、起草、验算,人做决定和动作。
- AI-led:DE 端到端驱动,人在生效前检查输出。
- AI-independent:DE 独立完成,人不在例行回路中(上报通道永远保留)。
晋升按场景逐个进行,凭据是当前层级上有意义样本量的成功率证据,外加零开放的守护栏类 bad case。并且阶梯不是单向棘轮——线上成功率退化,场景就降级。
最容易被省略、我却最想强调的一条:晋升决定要像发布一样留档——谁批准的、依据什么证据(样本量、成功率、开放 bad case 数)、什么时间。因为”场景 X 从 human-led 升到 AI-led”改变的是 AI 无人值守的权限量,这正是信任架构说的”必须挣得且可追溯,而非默认拥有”的那类变更。把它做成正式的可审计事件而不是团队口头共识,未来某天你会感谢自己——通常是在出事后的复盘会上。
一个小习惯
写这套指标文档时,我们给每个示例数值都标了 (illustrative)——“任务成功率 ≥90%(示意)“。因为文档会流传,数字会脱离语境变成军令状。**在你还没有数据的时候,诚实地标注”这是示意”,是目标定义阶段最便宜的职业素养。**它同时给团队立了规矩:我们区分”框架”和”数字”,框架是承诺,数字要用自己的数据挣出来。
本篇清单
- 你的指标里,有没有一个”只有 100% 可接受”的底线指标?哪个?
- 成功率目标是分层的还是一刀切的?
- 触发精度量了双向吗?假阳性有人看吗?
- bad case 有生命周期吗?”修复但没固化成测试”的失败,在你的流程里算关闭吗?
- 给 AI 加权限的决定,留档吗?能降级吗?