一项 Skill，所有智能体

博客 · 阅读时间 5 分钟

如今没人只用一个 AI 智能体。你用一个工具写代码，用另一个工具审查，而且多半只差一个不顺心的下午，就会去试第三个——因为团队里有人对它赞不绝口。这没什么不好，说明市场健康。不好的是它对你精心写下的那些指令造成的影响。

假设你写了一项确实很好的 Skill：一份代码审查清单、一份故障处理手册、一份规定团队如何撰写提交信息的内部风格指南。如果这项 Skill 只是以一段文本的形式粘贴在某个工具的设置里，那么实际上它现在已经是that tool'sSkill 了。想在别处使用就得重新录入，而重新录入就意味着它会开始分叉——这份改一处，那份调一点，直到「那项 Skill」其实变成了三项略有差别、只是同源的 Skill。

指令不该在意是谁在读它

在软件的其他每一层，这都是早已解决的问题。写得好的函数不在意由谁调用。设计良好的 API 不在意客户端是浏览器还是脚本。你给 AI 智能体的指令，本质上就是一套行为 API——没有理由让它与 Claude、ChatGPT 或 Codex 的耦合程度，超过一个 REST 接口与某个浏览器的耦合。

如今这件事之所以可行，是因为客户端自身已经收敛到一种获取工具和上下文的共同方式：MCP。任何支持它的客户端都可以向服务器询问「你有哪些 Skill」和「把这个给我」，而服务器无需知道、也不必关心究竟是哪个智能体在询问。可移植的 Skill 正是活在这道接缝上——它不是为某个工具打造的插件，而是通过多个工具早已支持的协议所提供的内容。

当 Skill 成为唯一真相来源，会发生什么

把 Skill 放在一处，每个客户端就都成了读者，而不是副本。在审查清单里修好一个问题，下一个加载它的智能体——无论是哪一个——都会拿到修正。没人需要记住三份粘贴副本中哪一份是最新的，因为只有一份。

对 Skill 而言，可移植性不是锦上添花。它是「你在维护的一条指令」与「你反复重写的一条指令」之间的区别。

这正是 Skilnu 的全部想法：Skill 存放在注册表中、通过 MCP 提供，于是 Claude、ChatGPT、Codex——乃至你明年会用的任何工具——加载的都是同一项 Skill，而且是今天的版本，不是某人碰巧记得更新的那个版本。

试一试

如果比起论述你更想看具体操作，教程 Use one skill in Claude, ChatGPT, and Codex 会用几分钟演示如何把一项 Skill 同时连接到这三者。