那时候我觉得没必要

我最早几乎只用 Codex 这一个 AI 助手。装 Skill 的办法很简单：把它放进该在的地方，装上就能用，用着顺手就留着。那时候我的全部家当，一只手数得过来，实在没为「管理」这件事操过心。

所以，当我看到有人分享一个做法——把 Skill 原件集中放进一个仓库，再让各个助手用软链接（说白了就是快捷方式）去引用它——我的第一反应是：这有必要吗？

工具就一件，专门给它建个仓库，再为它弄一堆链接，听起来纯属给自己添堵。当时我心里挺笃定：只有一个助手的时候，复制粘贴就是最省事的答案，把简单的事做复杂，那是没事找事。抱着这个想法，我一路用得很顺，直到助手的数量开始变化。

问题变多的那一天

转折发生在我手边的 AI 助手多起来之后。先是 Orca，接着是飞书里的各种 AI 助手，再往后，好多个助手同时住进我的电脑，各管一摊，互不通信。

同一个 Skill，要在每个助手那里各装一遍；第三方出了新版本，也要挨个去更新。更烦的是更新：今天 A 助手跟进了新版本，明天 B 助手又冒出来，一个 Skill 的新改动，我得在好几个地方重复同一遍操作，做完了还要挨个确认自己没漏掉谁。等我又新装一个助手、要把常用 Skill 重新配一遍的时候，心里只剩一句话：这可要了老命了。

麻烦从来不复杂，它只是重复。同样的事一遍遍做，每次都不难，架不住次数多。而且这类事不会因为熟练就变少——助手每多一个，同样的步骤就要重来一遍。重复跟着助手的数量涨，越攒越多。

一份原件，多处入口

这时候，我想起宝玉分享过的一个做法，大意是：把 Skill 原件集中保存，再用软链接让不同的入口共同引用它。链接放在这里：宝玉的这篇分享。

软链接听着唬人，其实就是快捷方式。原件只存一份，放进一个总仓库；每个助手的 Skill 目录里放着的，只是一个指回原件的快捷方式。改一处原件，所有入口一起生效；哪天删掉快捷方式，原件也毫发无损。

顺着这个思路，我搭了个叫 SkillManager 的项目。它做一件事：把我自己的、能跨助手使用的 Skill 原件收进总仓库，再按各助手的需要，生成一个个指回原件的快捷方式。它还会把每一条快捷方式都记下来——哪条通向哪份原件、给了哪个助手，日后查起来一目了然。

一套原件、多处入口。那个当初被我划走的思路，重新捡起来，居然一用就通。后来我回头看，这套做法最值钱的地方，是把「一份 Skill」和「多个助手」这两件原本互相打架的事拆开：原件还是那一份，入口却通到了每一个助手那里。

光有快捷方式还不够

快捷方式一多，新的麻烦又冒出来：哪些 Skill 能进总仓库？哪个快捷方式该发给哪个助手？总有些东西，不能一股脑全连上。这些问题靠复制粘贴解决不了，因为它们已经属于「管理」的范畴。

SkillManager 的办法，是给每个 Skill 配一张清单，写明它可以给哪些助手用。这就像给不同的手艺人配不同的工具箱：木匠拿木匠的，电工拿电工的，不会把整套家当都塞给每一个人。哪怕用了「通配」这种偷懒写法，也只对名单上能力合适的那几位生效，别的助手照样看不见。

还有一类 Skill，主人根本不是我。项目自带的、系统里的，各有各的归属。SkillManager 对它们默认只看不动，像搬家之前先检查东西写了谁的名字，写着项目或系统名字的，看一眼就放下，绝不动手搬。这类 Skill 不在我的清单上，动它等于动别人家的东西，出了乱子我也兜不住。

快捷方式解决的是「重复」，到了这一步，我不得不面对的其实是「规矩」：什么能进、什么不能进，发给谁、不发给谁，总得有个说法。

先给清单，留好退路

真正让我安心的是 SkillManager 做事的方式。

动手之前，它先列一份计划清单，把要做什么、要动哪里写得清清楚楚。我看过没问题，它才动手。遇到已经有真实内容的目录、来历不明的快捷方式、整个目录被当成一条别名连过来的情况，它都先停下来，当作冲突摆到我面前，等我来定，绝不自作主张去覆盖。

连「要不要收编一个 Skill」，它都默认先问我，不替我拿主意。每一步还留了退路：出了问题有路可退，等一切确认妥当，也有清理备份的步骤。我要做的，只是看着那份清单，一个个说「行」或者「不行」。

东西越多，越怕工具自作主张。宁可慢一点，每一步都经我点头，也不想哪天下错一步，把攒了这么久的 Skill 目录搅成一团。这份谨慎，恰恰是我愿意长期用它、也敢把它放心交出去的原因。

记得住更新，放得下备份

更新这件事，我一开始想靠记性，后来发现靠不住。Skill 版本一多，哪些更新过、哪些还停在旧版，光靠脑子记，迟早要乱。还是交给流程踏实。

第三方 Skill 进门的时候，SkillManager 先记下它当时的版本，像记账先记下这一笔，往后任何时候都查得到。想换新版本，要我先明确点头，它才肯推进；推进完还要回头检查，登记过的内容还在不在。没有这道手续，哪天第三方悄悄改了样，我根本察觉不到。

原件如今都集中在总仓库里，我又把整个仓库接到了 GitHub，云端多了一份备份，版本记录也随时可查。

我另外给仓库配了一条每日检查的流程：定时去看看第三方 Skill 有没有更新，有变化就更新账本；一旦发现登记过的 Skill 缺了东西，它就停下来报错，绝不把坏结果写进仓库。这条流程刚配好，还需要在远端跑一阵才算数，但方向我已经很确定——日常运转该靠机制，不该靠我哪天想起来。

启发或者能带走什么

说回最开始。当初那个觉得没必要的人没有错——工具只有一件的时候，复制就是最好的答案。人没有变，是东西变多了。

所以，我想把这段经历翻译成几件不写代码也能做的事：原件只放一处，别让文件、模板、素材散落在各处；每复制、安装一次，就顺手留个记录，哪怕只是写一行「今天给 X 装了什么」；等手边的东西多起来，先问「原件在哪里」，而不是「还要再复制几份」。

你不必搭一套 SkillManager。思路是一样的：把东西管起来，改一处能处处生效，每一步都看得见、留得住、退得回。等哪一天你的助手多起来，这句话大概会比任何工具都管用。