Mistral 给 skill 上了版本管理，我这一百多版规则手册还在拿 git 硬扛
哈喽，我是飞飞。
先撇清一下。这两天我连着写了 AI 味泛滥、Claude 反思功能，都是内容和模型那摊事。今天换个方向，聊聊我天天在写的那堆 skill，怎么把它们管住别改乱。
起因是 Mistral 出了个东西叫 Studio。它干的事，说白了，就是把你的 prompt 和 skill 当成正经的生产资产来管。我一看，愣了两秒：这不就是我拿 git 硬管了大半年的那摊活吗。
Studio 把 skill 当资产
先说 Mistral 这套是干嘛的。
按官方说法，Studio 给你的 prompt 和 skill 做一套集中的档案。每一版都是不可变的，改坏了能一键回滚。谁改的、什么时候改的，都有审计日志记着。还能给资产打分类标签、标明归谁负责。
更狠的是它那个可观测性。线上跑出来一个结果，你能顺着它倒查回是哪一版 prompt、哪一版 skill 产出的。非技术的人也能直接在里头改、在里头测，改好了打个标签推到线上，原来的 CI/CD 流程照走不误。
一句话，它把「prompt 和 skill 是随手写的脚本」这个认知，改成了「它们是要上治理的资产」。
我那套土法管了一百多版
看到这我笑了，因为这套活我一直在干，只不过用的是土办法。
我有十几个 skill 天天串起来跑，还有一本防 AI 味的规则手册，叫 WRITING_LESSONS。这本手册我改了一百多回，攒了一百多条规矩。我怎么管版本的？全靠 git。每改一条规则就提交一次，写一句为什么改。想回滚，就翻 git log。
分类和所有权我也有土法。通用的 skill 放全局目录，跟项目绑死的放项目里提交 git，判断标准就一句：换个项目还用得上吗。
至于审计，我的审计是肉眼加一条命令。我全局 skill 攒到七十多个的时候，开始乱触发：写 Docker 脚本它去调设计评审，写文章因为带了代码块触发安全审计。后来我定了条规矩，每两三周跑一下 ls 数个数，超过十五个就精简一轮。
这套东西的分量，得等你想换模型的时候才摸得着。我试过把底座从一家模型换到另一家，十几个 skill 调工具吐出来的格式立马飘了，得挨个重校。光把那套防 AI 味的 grep 规则重新调顺，我就磨了好几个晚上。这种一晚一晚磨出来、外人看不见的厚度，才是别人抄不走的家底。打那次以后，我就把这堆 skill 当正经资产看了。
你看，Studio 表里那几栏，我这边全有对应的。只不过我的是手搓的、散的。
我缺的是回溯那一环
对下来我心里有底了一半，也虚了一半。
有底的是，版本、分类、所有权这些，我拿 git 加手动规矩基本兜住了。虚的是它那个可观测回溯，我是真没有。
我这边的情况是这样：一篇稿子跑出来 AI 味没压干净，我只能靠经验猜是哪条规则松了，翻 git 一条条比对。它那套能直接告诉你，这个结果是三天前那一版 skill 产出的。这一环，就是把「出了问题查半天」变成「出了问题一眼定位」。
对我这种一个人跑一整条流水线的，这一环省的不是力气，是那种查不到根、只能凭手感的心虚。
改一处会牵动全线
为什么我这么在意版本和回溯，得说说那本规则手册的分量。
它是我所有写稿 agent 共用的一个脑子。写稿、润色、配图那几个 skill，全都读它。我在里头改一条，整条线跟着变。改对了，全线一起变好；改错了，全线一起翻车。
我踩过这个坑。有回我把一条扫「不是 X 是 Y」对仗的规则写太宽，结果它把正文里正常的疑问句也当成对仗揪出来，一批稿子集体误伤。这种错，因为是共用的，波及面特别大。
再往前，我配图那个 skill content-artist 也栽过。一开始我没在规则里写死「只许写截图占位、绝不许自己上传或塞图床链接」，结果 agent 自作主张，把图床链接直接塞进正文，还漏图。我把这条抠成死规矩，它才老实。这些规矩没一条是我一开始就想周全的，全是一次次被 agent 坑出来的。
好在这本手册不全靠我手动喂。我专门写了个 skill 叫 content-training，每写完一篇稿，它把这篇踩的新坑自动提炼成一条规则，回写进手册。我每踩一次坑，这套系统就自己收紧一点，这也是我敢让流水线大半无人值守跑的底气。可它有个副作用：规则进得快，谁也没空回头删。
还有个更隐蔽的负债：规则只进不出，越攒越多，总有几条过时了、收太宽了、跟别的重复了。沉淀和修剪本来就是一对，光沉淀不修剪，这本手册迟早变成谁也不敢动的一坨。
所以对一个共用的、还在天天变的资产，能追溯、能回滚、能看清谁动过，就不是锦上添花了。
一个人要不要上治理
说到这我得替另一头说句话。
你可能会想：不就是十几个 skill 吗，至于上这么重的一套治理？这话不假。我一个人跑，git 加几条手动规矩，八成场景够用了。Studio 那套不可变版本、审计日志、可观测回溯，明显是给一个团队几十号人同时改一份 prompt 的场面准备的。
那要不要上，我的判断就一条：看你那份 prompt 或 skill，改一处会不会牵动一大片。
如果它就是你自己偶尔用一下的小脚本，改坏了自己重写就行，那 git 都算重的。可要是它变成了好几个人、好几条流程共用的东西，一处改动能波及一大片，那这套治理迟早得上，早上比晚上省事。
我自己现在卡在中间。一个人跑，但十几个 skill 加一本一百多条的规则手册，那份共用度已经高到让我开始想要那个可观测回溯了。哪天真要再拉一两个人一起改这套流水线，git 加脑子记的土法，估计头一周就得崩。
先给最常改那个记账
真要动手，别一上来就搭一整套。先挑一个东西开刀。
挑你改得最勤、又最怕改坏的那一个 prompt 或 skill。每次改都用 git 提交一次，提交说明写清为什么改，别写「更新一下」。再拿个文件记一笔账，写清这东西归谁负责、上一版为什么被推翻。就这两下，你就有了一套最简版的版本管理加审计，往后想回滚、想查谁动过，都有据可依。
skill 从手搓脚本长成要治理的资产，这个转变是躲不掉的。你手里的 prompt 用得越勤、共用的人越多，这一天来得越快。
想问问你：你的 prompt 或 skill 是怎么管版本的，还是压根没管、全靠脑子记？有没有因为随手改一处，把下游一批东西带崩过？评论区聊聊。