我怕被封号才想做的那张清单，大厂上周把它做成标准了

Hello，我是飞飞。

七月三十号写 Anthropic 封号那篇的结尾，我给自己派了个活。原话是这样的：

我这周要做的是上面这件事的一半。把那 13 个 skill 里真正跟 Claude Code 机制绑死的部分标出来，分清哪些是可移植的规则、哪些是特化的胶水。这个清单我一直没做，因为以前它没有到期日。

先说结论：五天过去了，那张清单我一行没写。

然后这周有两条消息同时落地，一条论文一条标准，讲的都是同一件事。我读完的心情有点复杂：我因为怕号没了才想干的活，大厂正在把它做成人人都能用的规范。

先撇清一下。八月三号我写过 Google 给 skill 库上 CI，讲的是怎么让规则真被执行；七月一号写过怎么把单个 skill 写得不飘，讲的是工艺；七月十号写过 skill 的版本管理。这篇是新的一层：写好了、管住了、也执行了，可它跟不跟得走。

那张清单我一行没写

得先交代我手里到底有什么，不然后面全是空话。

13 个 skill，一个编排 8 个阶段的 director。一本写作规则库 57 万字节、150 条。一份 38 行的选题范式索引。还有这一周刚做的 5 个检查脚本，分别管索引指针、公众号拆段、比喻查重、描述长度、笔记元信息。

这些东西堆了两年多，全是照着 Claude Code 的脾气一点点磨出来的。

那句「这个清单我一直没做，因为以前它没有到期日」，写的时候我以为自己是在立个 flag。现在看更像一句自嘲。到期日已经摆在那儿了，我还是没动。

一份 md 搬过去反超

先说论文这条。

微软和上海交大、同济、复旦合作的 SkillOpt，arXiv 编号 2605.23904。它干的事一句话说清：不动模型权重，只训练一份自然语言的技能文档。

产物我特意去核了形态，因为这决定了我那堆东西能不能对号入座。答案是一个纯文本的 md 文件，379 到 1995 个 token，由 1 到 4 次被采纳的编辑拼起来。论文原话说这是「领域从业者几分钟能读完的文本文件」。

那就跟我那本规则库是同一类东西。

它最抓眼球的一个数是这样的。在 SpreadsheetBench 上用 GPT-5.5，把在 Codex 上训出来的那份技能文档直接搬到 Claude Code：

• Claude Code 什么技能都不带，22.1 分
• Claude Code 自己训一份技能，80.4 分
• 从 Codex 搬过来那份，81.8 分

搬过来的比自己训的还高一点。收益保留率 102%。

十一组迁移实验，跨模型的、跨工具链的、跨基准的，没有一行掉到目标端的无技能基线以下。

我第一反应是有点兴奋。这不就是在说，我那本规则库真能跟着我走吗。

论文自己说了更要紧的话

然后我读到了论文自己写的限定，比那个 headline 重要得多。

原话是：迁移强度跟任务类型走，程序性的表格技能搬得很好，数学推理类的技能搬得很差。

它给了两个弱例，都不好看。GPT-5.4-nano 那行只保留了 16% 的收益，LiveMath 从 Codex 搬到 Claude Code 只保留 10%。

作者还写了一句我很服气的话：证据只覆盖了一个 GPT 家族、每个维度两个基准，所以可移植性是被演示了，还没被泛化。跨模型家族的迁移，比如 GPT 搬到 Qwen，压根没测。

那条 aihot 摘要给我的只有「81.8 超过 80.4」这半句。要是照着那半句写，这篇文章就成了替它喊口号。

我摸出的那条线

有意思的地方在这儿。论文那句「程序性搬得动，要推理的搬不动」，跟我这一周的体感撞上了。

这周我把四份原本靠脑子记的清单做成了脚本。做完之后，一件我一直说不清的事反而清楚了。

我那本规则库里的东西，其实是两种。

一种是纯文字的规矩。单句超过二十个汉字就拆开、二级标题不超过十二个字、结尾必须带一个好接话的具体问题、别写「值得深思」这种正确的废话。这些规矩跟哪个模型都没关系，换谁来写都成立。

另一种是贴着 Claude Code 长出来的东西。扫某个句式的正则，是照着它爱犯的口癖写的；skill 描述怎么写才不会误触发，是照着它读 frontmatter 的方式调的；hook 在哪个时机插进去，是照着它的执行顺序试出来的。

这一类换个工具就作废，甚至换个模型版本都可能要重调。

真正跟得走的那部分，不在你写了多少条规则，在那些规则是不是照着某一家的脾气长出来的。

拿论文那把尺子再量一遍，我这条线还能画得更准。写死的格式规矩是程序性的，搬得动；而「这段有没有说服力」「观点够不够聚焦」这种需要判断的，恰恰是论文说搬得最差的那一类。

租房子久了会有这个体感。家具能装车拉走，墙上的柜子和地板拆下来就废了。我这两年往这套房子里砸的钱，一部分变成了行李，一部分变成了墙。

好消息是结构不用改

再说标准这条，Agent Plugins 1.0.0。

它做的事是给 skill 和 MCP 服务定一个统一的打包格式，让你不用为每个 agent 和 IDE 各维护一套封装。

我最关心的是要不要改结构，所以专门去核了目录约定。结果是好消息：

reports-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
└── mcp.json

规范原文写得很明白，skills/ 里那些子目录用的就是 Agent Skills 规范已经定好的格式。

而我那 13 个 skill 现在长的就是这个样子，主文件放流程、references 放细节、scripts 放检查。等于我不用动结构，外面套一层 plugin.json 就完事，而那个清单只要求两个字段。

规范原话形容它是「两行实质内容」。

谁不在那张桌子上

有个细节我读了两遍。

核心维护者名单是这么写的：亚马逊、Cursor、微软、OpenAI、Vercel 组成的技术指导委员会，Google 这次作为核心维护者加入。

名单里没有 Anthropic。全文也没提 Anthropic，只在兼容客户端里列了 Claude Code 的名字。

可 skills/ 那个格式，是 Anthropic 定的 Agent Skills 规范。

一群人围坐着给一个东西定打包标准，那个东西的原作者不在桌上。这话我点到为止，因为我不知道内情，也许是没受邀，也许是没兴趣。但这个位置很值得盯，它多少能说明这套东西将来往哪个方向长。

它没回答我那个问题

再说个我没被说服的地方。

六月我踩过一个坑。当时在 Claude Code 里一口气挂了七八个 MCP，结果它老在不该调的时候瞎调，排查半天才发现是工具定义把上下文撑爆了，删到只剩三个才顺手。

所以看到「把 skill 和 MCP 打包成单一单元」，我头一个问题是：打包了，还能挑着装吗。

规范给的答案是失败隔离。某个 MCP 服务起不来，不会把这个插件里的 skill 一起拖垮，客户端跳过它继续加载并报告失败。

这是好设计，但它答的不是我问的。它保证「挂了不连累别人」，没保证「用不上的可以不装」。

我又去翻了一遍，整份公告里没有一个字提到装太多插件会撑爆上下文，也没给对策。

这不是说这套规范不好，它解决的是分发和封装，本来就不负责替你做取舍。我只是提醒你，如果你也踩过我那个坑，别指望打包能顺手把它治了。取舍这件事，还是你自己的活。

我这周真要做的

诚实边界摆在这儿。SkillOpt 我没跑过，Agent Plugins 我没试过打包。上面全是读论文、读规范，再拿我自己那 13 个 skill 去对照。那条分界线是我的判断，不是我做出来的成果。

那张清单我还是欠着，但这次它有了更明确的做法。

我打算把那 150 条规则和 5 个脚本过一遍，只做一件事：给每一条打个标记，是纯文字的规矩，还是照着某一家的脾气写的。不改内容，只标记。做完就知道真要换家的时候，我能带走几成。

给你留个今天能做的动作。挑你最依赖的那个 AI 工具，把你为它写过的东西分成两摞，一摞是纯文字的规矩，一摞是贴着它的脾气调出来的。先别急着搬，就数一数两摞各有多少。

我猜大多数人会跟我一样，以为自己攒的都是财产，数完发现有一部分其实是装修。

最后想问问你：你为某个 AI 工具攒的那堆东西，真要换一家，你估计能带走几成？评论区说个数，我想知道大家的比例差多少。