企业级 Skills 治理的最佳实践与避坑指南

Skill 这个概念自 Anthropic 于 2025 年 10 月发布论文以来，几乎已经成为 Agent 落地真实业务、产出真实价值、解决核心痛点的最重要组成部分。

但很多人对 Skill 的理解依旧停留在表层。比如只知道，一个长对话结束后，要给 Agent 说：「帮我把以上流程封装成一个 Skill。」好一点的，知道 Skill 的标准结构是 Skill.md、references、scripts 和 assets。

但追问一句，然后呢？如何迭代？如何把一个 20～40 分的 Skill 迭代到 60 分，甚至 90 分？

下面是几点企业级 Skills 治理的最佳实践和避坑指南，希望对你深入迭代 Skill 有启发。

一、懂 AI，也懂业务，还要用最好的 Agent

如果你是 AI 专家，就去访谈最懂这块业务的同事，把最佳实践挖出来，深入业务优化 Skill。如果你本身就是业务专家，能够把事情说清楚，就学会 Skill 技巧，配合 Agent 边用边给反馈，持续迭代效果。

最忌讳的是：自己不懂业务，也不太懂 AI，还不舍得用好的模型。

注意，创建时必须用最好的模型，使用时可以基于成本考量选择普通模型。70 分的理解配上最好的模型，能做出 80 分的 Skill；普通模型使用这个 Skill，也能发挥出 75 分的效果。可是，60 分的理解配上一般模型所创建的 Skill，最好的模型在使用时，可能连 60 分都发挥不出来。

二、输入输出定义清晰

这是非技术同学最容易踩的坑。你想做一个专业的 Skill，别急着写，先回答三个问题：输出的格式是什么？内容有哪些？给谁用、用来干什么？

输出定义清楚了，才能倒推输入是否完整和准确。

最近有个案例，说让 Agent 按评分标准给参赛文档打分，和评委打的分差异很大，于是怀疑 Skill 有问题。结果一看，Skill 没问题，是输入有问题。

评委打分时，除了文档和标准，还有选手现场答辩的表现、自己的偏好和经验。这些信息都没有喂给智能体，你让它怎么打出一样的分？

所以专业的做法是：定义输出，推导输入，捋出 SOP，进行定性和定量测试，再给用户使用，最后收集反馈、不断迭代。

三、触发条件和自由度要清晰

一个 Skill 在企业里能不能用，首先看触发条件。太含糊，会被误触发；太狭窄，该触发的时候又不触发，两者都是事故。

同理，name 和 description 也要规范。description 不能写得太长，很多智能体会直接截断。你写一万字，真正干活的时候可能信息全没了。命名也不要模糊。

还有自由度的问题。生产性、严谨的场景，自由度要压低。不要只用自然语言让 AI 操作平台，要给它 CLI、给它 MCP，按照严格的 SOP 执行，这样不容易出错。