你的 AI Skill 需要版本控制

博客 · 阅读时间 6 分钟

在包管理器出现之前，「使用别人的代码」意味着把一个文件复制到自己的项目里。这能用，直到原始文件修好了一个缺陷而你的副本没有，或者你的副本已经偏离到足以让合并回修复不再是复制粘贴的程度。对代码而言，我们几十年前就解决了这个问题。Skill 如今正在经历一模一样的问题，而且大多没有对应的解法。

随便问问，你会在各处看到同样的模式：一段用于审查合并请求的好提示词被粘贴进项目 A，接着又粘进项目 B，因为在那儿同样好用，然后第三次为另一种语言改了两行。那已经不是一项 Skill 了，而是三段有共同祖先的提示词——六个月后你无从判断哪一段才是「真正的那一段」，也无从知道给 A 打的补丁是否曾经传到过 C。

复制粘贴真正让你付出的代价

• 修复不会传播。 Find a mistake in the shared logic and you have to remember every place you pasted it, then go fix each one by hand.
• 没有 diff。 When two copies disagree, you can't tell what changed on purpose versus what someone forgot to update.
• 没有回滚。 A change that turns out to be wrong has already overwritten the version that worked.

这些都不是停止用其他 Skill 组合 Skill 的理由——把一套测试理念共享给五项针对不同语言的 Skill，或者把一份内部风格指南共享给十几项更具体的 Skill，恰恰是值得做的复用。这些只是理由，说明那些被共享的部分需要与代码依赖同等的规范：一个真正的版本号、一条明确声明的约束，以及一个让「当前版本」具有确切含义的地方。

把包管理器的模型用在指令上

把 Skill 当作包而非文本块来对待，整类问题就会像当年对代码那样消失：

• Skill 有版本号。改动它，版本号也随之改变。
• 另一项 Skill 可以带约束地依赖它（>=1.0.0），而不必嵌入它的内容。
• 发布依赖的更新，就会更新所有解析到它的 Skill——无需再去搜寻副本。
• 某个版本可以被标记为弃用，而不会破坏仍固定在它上面的内容。
• 有意的分叉会被记录为 fork，而不是一次无从追踪的复制粘贴。

这与 npm、pip 或 cargo 是同一种形态——并非因为 Skill 就是代码，而是因为「许多东西依赖于一个会随时间变化的共享事物」本就是同一个问题，与文件里装着什么无关。

只以粘贴文本形式存在的 Skill 没有谱系。经过版本化、可组合的 Skill 则拥有一段你真正能够推理的历史。

试一试

教程 Compose and version skills like code 会演示如何声明依赖、发布一次让所有依赖方自动获取的更新，以及在不丢失来源的前提下 fork 一项 Skill。