Google 给 skill 库上了 CI，我上周刚把四份清单变成四个脚本

Hello，我是飞飞。

Google 的 Agent Skills 团队发了篇复盘，讲他们怎么管那个 GitHub 上一万五千星的开源 skill 库：每个 skill 必须自带评估文件，提交要过 CI，每周全库回归一遍。

我读的时候一直在点头，点得有点心虚。

因为就在上周，我在自己的写作流水线上干了件一模一样的事，只是规模小得多：把四份「靠人记的清单」做成了四个脚本。每一个脚本背后，都是一次真实的翻车。

先撇清一下。我写过怎么把单个 skill 写得不飘，写过 Mistral 给 skill 上版本管理，更早还写过 Every 的复利工程。那三篇分别是工艺层、版本层、沉淀层。这篇是新的一层：规则已经有了，版本也管了，可谁来保证每次都照着做。

三次手工修复三次翻车

先讲把我打服的那个案例。

我那本写作规则库有一份 35 行的选题范式索引，每行指向正文里的一条规则。规则库天天在长，行号跟着漂，索引隔三差五就得修一轮。

我徒手修过三次，三次全翻了。

头一回，新插三条规则，34 个指针里 32 个失效，我一个个数行号补。

再修的那回我学聪明了，写了个「就近找标题」的小聪明：指针漂了就找最近的标题对上。结果它把两对规则悄悄合并，索引从 34 条塌缩成 32 条。丢了两条，还不报错。

最后那回最难看。我把索引和标题各排一遍序再一一配对，错位了一格，34 个指针全部落在标题行上，但全是错的标题。我的检查只验了「指着标题」，没验「指着对的标题」。每个指针看起来都是好的，每个都是坏的。

三次翻车，翻在三个不同的地方。这才是清单类活儿的真面目：坑从来成片长，你每次绕过上次那个，就掉进一个新的。

认命之后我把它写成了脚本，四道校验：按行序绑定、特征词唯一性、塌缩检查、改完幂等复算。之后每次索引变动，跑一下，几秒出结果。

另外三份清单怎么认命

同一周里，还有三份清单走了同样的路。

拆段那份。我的公众号版本要按句号拆段，拆段逻辑一直是每次现写。有一次它把加粗的一对星号从中间拆开，结尾那半落了单，公众号预览里加粗全没渲染出来。连续六篇中招，最后是读者视角肉眼看出来的。现在拆段是脚本，拆之前先把加粗、代码、链接这些标记护住。

查重那份。写作前要查最近用过的比喻，免得同一个比喻两篇文章当主角。我以前靠手打清单，手打那次漏了一个「闸」字，结果它在两篇文章里都挑了大梁。现在脚本从训练日志里自动抽，还按出现次数分级。

最扎眼的是最后那份。我的文章 description 有条规范，60 到 120 字，定了快两个月。上周我写脚本去量全站，489 篇里 404 篇不合规。规范定了之后写的照样超。

更难看的还在后面。脚本上线当天跑头一批测试，就抓到一篇超标 157 字的。那篇是我当天上午刚发的。

规则就摆在我眼前，我照样超了。

写那篇的时候我不是不知道规范，我是没去数。人记得住规则，记不住清单。这四件事凑在一起，把这句话钉死了。

他们那套和我对上了

回头看 Google 那篇复盘，为什么我边读边点头，因为几乎每条都能对上号。

他们的 CI 跑 linter，查 frontmatter、行数、目录结构、命名规范。我的 description 脚本查长度、数字、单行、标点，同一类东西。

他们用 AI 辅助清单校验指令的结构模式。我的索引校验脚本干的就是这个，只是我的四道校验是被三次翻车逼出来的。

他们提交时评估加每周全库回归。我是交付前重跑硬扫描矩阵，加每篇写完让沉淀环节把新坑提炼成新规则。

连分层都像。他们的标准目录是 SKILL.md 加 reference 加 scripts，我的每个 skill 也是主文件放流程、references 放细节、scripts 放检查。

这不是我抄他们，也轮不到他们抄我。是同一面墙撞出了同一个答案：文档管不住执行，能管住执行的只有机器。

有个差别值得说。他们治理的是社区库，几百个外部贡献者，谁也不能指望别人自觉。我治理的是自己，一个人一条流水线，按说最该靠得住。可 404 篇超标说明，我自己也不是那个能自觉的人。外部贡献者靠不住和我靠不住，是同一件事。

他们比我狠的两处

诚实边界得摆出来，别让你以为我已经做到 Google 那个程度。差着两层。

头一层，他们每个 skill 必须带一个 EVAL.yaml，提交时作者要附上评估用的 prompt 套件和评分标准，然后拿两组 agent 对比着跑：带这个 skill 的和不带的，量回答质量、任务完成率、token 消耗。我的十几个 skill，一个自带评估的都没有。我知道它们能跑，但「有这个 skill 比没有好多少」，我从来没量过。

另一层，他们是提交即强制，CI 不过就进不去。我的四个脚本还是「规则里写着必须跑」的半自动，靠的还是执行流程时记得调它。说白了，我只是把清单交给了机器，还没把「记得跑」也交给机器。

这两层就是我接下来要补的。先给最常用的两个 skill 各配一份最小评估，再想办法让脚本挂在提交动作上自动跑。做到哪一步我再写。

什么清单该变成脚本

四次翻车攒下来，我总结了一个判断标准，就三个信号，中一个就该动手。

信号一：这份核对每次的动作完全一样。索引对行号、description 数字数，没有任何需要判断的成分，纯机械。机械活给人做，错是迟早的。

信号二：错了不报错。索引塌缩不吭声，加粗断了预览才看得见，超标的 description 安安静静躺了两个月。凡是坏了还一声不吭的东西，必须有个东西定期去戳它。

信号三：你已经在同一份清单上错过两次。错一次可能是意外，错两次说明这活儿天生不适合人。我那个索引给了我三次机会，我才听懂。

反过来说，需要判断力的核对别急着脚本化。比方说「这段有没有说服力」，脚本量不出来，硬量就是自欺。脚本管量得出的，人管量不出的，这条线划清楚，两边都轻松。

安检这个事，规定贴在墙上没人看，真管用的是那台安检机，谁过都得过一遍，它不知道累，也不给谁面子。规则库再厚，真正缺的往往不在规定，在那台不知疲倦的机器。

你那份清单还在靠记性吗

给你留个今天就能做的最小动作。

想一下你的流程里，哪份清单是「每次都该核对、但经常忘」的。发布前的检查项、提交前的格式核对、上线前那几个必看的数，都算。挑出最常错的那一份，今天把它变成一个能跑的检查，哪怕只是十行的小脚本，能跑就行。

写完你多半会跟我一样，头一次跑就抓到一个现行的。那个瞬间挺微妙的，有点丢人，更多的是踏实。

对了，Google 那篇通篇讲流程，一个失败案例都没提。我猜他们也翻过车，只是没往复盘里写。所以我把我的四次翻车原样摆在这儿，算替他们补上另一半。

你流程里那份最常被忘掉的清单是什么？有没有哪次「明明有规范还是错了」错得特别冤的？评论区讲讲，我们对对坑。