企业Skill的准确率，为什么总是上线即翻车？

推荐语

企业AI技能上线后准确率骤降？揭秘三大传统测试无法覆盖的结构性问题。

核心内容：
1. 企业AI技能测试中的三大结构性问题：自判卷偏差、随机性和负向增益
2. 传统测试方法在AI场景下的局限性分析
3. OpenClaw提出的确定性测试解决方案：分层测试策略

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

一个被低估的问题

上周跟一个做企业 AI 的朋友吃饭，他吐槽了一件事：他们公司花了两个月开发了一套 Agent Skills ，内部测试时准确率 92%，觉得稳了。结果上线第一周，客服工单涨了三倍。

"我们测试覆盖了 200 多个场景，"他说，"但用户用起来的姿势，跟我们想象的完全不一样。"

这个数字挺扎心的。更让人无语的是，这在企业 AI 圈子里根本不是什么新鲜事——我认识的几个做企业 AI 的团队，几乎都踩过这个坑。

Agent Skill 框架的研究显示，即使是 12B 规模的模型，技能选择的准确率也只能逼近 90%。而一旦涉及到实际业务场景，这个数字还会往下掉。问题不在模型能力，而在 Skill 本身的结构性缺陷。

传统测试逻辑在这里失效了

很多团队用传统软件测试的逻辑去验证 Skill ：给定输入 → 执行代码 → 检查输出。

听起来没问题，但实际上——完全是错的。 AI Skill 有三个传统测试根本覆盖不了的结构性问题，很多团队到现在都没意识到。

第一，自判卷偏差。

Skill 里经常需要 AI 自己做判断。比如一个客服 Skill ， AI 要判断用户是不是在投诉。问题来了——谁来验证 AI 的判断对不对？传统测试有标准答案，但 AI 判断的场景，答案本身就是 AI 生成的一部分。

有团队想了个办法：让另一个 AI 来当"判卷老师"。但这又引入了新问题——如果判卷的 AI 和答题的 AI 是同一个模型呢？或者同一个训练范式呢？这就像让学生自己给自己打分——荒谬，但很多团队就是这么干的。

第二，随机性。

同一个输入， AI 可能给出三个不同的输出。传统测试追求"确定输入得到确定输出"，但 AI Skill 天然就是概率性的。

一个金融风控 Skill ，对同一笔交易，早上跑准确率 87%，下午跑变成 83%。不是代码有问题，是大模型本身的状态波动。

第三，负向增益。

这是最容易被忽略的一点。有些 Skill ，单独测没问题，但加到 Agent 里之后，整体准确率反而下降了。

为什么？因为 Skill 之间会"打架"。一个 Skill 擅长 A 场景，另一个 Skill 擅长 B 场景，但当用户的问题介于 A 和 B 之间时，两个 Skill 可能都会被触发，或者都不触发。

这种问题，传统单元测试根本测不出来。

确定性测试：把不确定的变成确定的

那怎么办？ OpenClaw 的实践给出了一个方向：隔离非确定性组件，对确定性的部分做严格测试。

具体怎么做？

把 Skill 拆成三层：

对于逻辑层和数据层，用传统测试方法就行：单元测试、集成测试、回归测试。

但对于指令层，需要换一套打法。

工具契约测试：给 Skill 装上"红绿灯"

这个方法的核心思想是：不要测 AI 的输出对不对，测 AI 的输出格式对不对。

比如一个数据分析的 Skill ，预期 AI 输出的格式是：

{"analysis": "一句话结论","metrics": ["指标1", "指标2"],"recommendation": "建议"}

测试用例不关心"一句话结论"的内容是否正确，只关心这个字段存不存在、是不是字符串、长度是否合理。

这就像给 Skill 装了红绿灯。车（ AI 输出）开得对不对，不管；但车必须走规定的车道。

Claude 的企业级 Skills 文档里也提到了类似的思路： Skills 可以捆绑可执行的 Python 脚本，对于需要确定性和高可靠性的任务（比如数据排序或格式化），把这部分逻辑放在脚本里，而不是交给大模型。

模糊测试：让 Skill"见世面"

确定性有了，但还不够。 Skill 还得能扛住各种奇怪的输入。

模糊测试的做法是：随机生成大量边界条件的输入，看 Skill 会不会崩。

比如一个文档处理的 Skill ，正常输入是干净的文档。但模糊测试会喂给它：
- 混入了乱码的文档
- 编码错误的文档0
- 格式损坏的文档
- 超长（或者超短）的文档

这不是为了通过测试，是为了发现 Skill 的盲区。

一个真实案例：某团队的 Skill 在处理正常文档时准确率 95%，但一碰到编码错误的文档，直接抛异常。用户看到的不是"处理失败，请检查文档格式"，而是系统错误页面。

模糊测试的价值，就是把这些"想不到的坏情况"提前暴露出来。

回归快照：防止"修一个 bug ，生两个"

最后一个坑： Skill 迭代时的回归问题。

传统软件有回归测试，每次改代码之前跑一遍测试用例。但 AI Skill 有个特殊性——你改的是 Prompt ，但输出可能变了。

比如你把 Prompt 里的"请分析用户反馈"改成"请深入分析用户反馈"，看起来只加了一个词。但 AI 可能把"深入"理解为要写更长的分析，导致输出从 3 句话变成 10 句话，下游系统解析失败。

回归快照的做法是：每次 Skill 迭代后，把典型输入的输出保存下来（快照），下次迭代时对比。

如果输出格式变了，或者关键内容变了，立刻告警。

这比传统回归测试更严格。传统测试只关心"对不对"，回归快照还关心"变没变"。

一个能落地的测试框架

把上面几块拼起来，一个企业级 Skill 的测试框架大概长这样：

这套框架的目标不是追求 100%准确率，而是让准确率变得可观测、可迭代。

很多时候， Skill"翻车"不是因为技术不行，是因为不知道哪里会翻车。有了这套框架，至少知道该往哪儿看。

说在结尾

回到开头那个朋友的故事。他们后来做了什么？

"我们给 Skill 加了三层验证，"他说，"第一层检查输入格式，第二层检查输出结构，第三层用规则兜底。"

准确率没变，还是 92%。但客服工单降了 60%。

因为现在，当 Skill 不确定的时候，它会说"我不确定"，而不是瞎给答案。

这可能是企业 AI 落地最重要的一课：让 AI 知道自己不知道什么，比让 AI 知道更多更难，但也更有价值。