一个被低估的问题
上周跟一个做企业 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 的测试框架大概长这样：
| 测试类型 | 覆盖什么 | 怎么测 |
|---|---|---|
| 确定性测试 | 逻辑层代码、数据层输入 | 传统单元测试 |
| 工具契约测试 | AI 输出格式 | JSON Schema 校验 |
| 模糊测试 | 边界条件、异常输入 | 随机生成+监控 |
| 回归快照 | 迭代稳定性 | 输出对比+告警 |
| 端到端测试 | 真实业务场景 | 用户行为模拟 |
这套框架的目标不是追求 100%准确率，而是让准确率变得可观测、可迭代。
很多时候， Skill"翻车"不是因为技术不行，是因为不知道哪里会翻车。有了这套框架，至少知道该往哪儿看。
说在结尾
回到开头那个朋友的故事。他们后来做了什么？
"我们给 Skill 加了三层验证，"他说，"第一层检查输入格式，第二层检查输出结构，第三层用规则兜底。"
准确率没变，还是 92%。但客服工单降了 60%。
因为现在，当 Skill 不确定的时候，它会说"我不确定"，而不是瞎给答案。
这可能是企业 AI 落地最重要的一课：让 AI 知道自己不知道什么，比让 AI 知道更多更难，但也更有价值。
