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