模型升级后，给 Skills 做一次瘦身

蔡坨坨2026-09-052026-09-05

转载请注明出处❤️

作者：测试蔡坨坨

原文链接：caituotuo.top/ab08ab1a.html

你好，我是蔡坨坨。

每次模型升级，我觉得都值得回头看一眼自己的 Skills：有些内容，可以瘦身了。

模型已经能处理的事情，旧文件里可能还在逐步教；过去为了防止它犯错加上的限制，也可能变成今天做事时的阻碍。模型换了，工作说明却一直沿用旧版，这件事容易被忽略。

最近看到逸尘在 X 上分享一个做法：让 Agent 审阅 AGENTS.md 和 Skills，找出让它反复确认、停下等待，或者任务做一半就结束的指令。我觉得这个方向值得借鉴。原帖在这里。

每次升级模型，也给旧规则一次重新证明自己有用的机会。

旧规则为什么值得重看

给 Agent 写规则时，很容易顺着一次错误补一句话。少做了一步，就要求每次列计划；改动不符合预期，就要求修改前先确认。

单独看，每条都有理由。放到一起，却未必能顺畅执行。

假设一份文件要求“把任务完成后再回复”，另一份却要求“每一步都等我确认”，Agent 到底该继续，还是停下？这样的冲突，靠换模型未必能解决，得把适用范围写清楚。

还有一类内容没冲突，只是重复。几处都在提醒检查结果、解释原因，维护时又各改一点，时间一长，同一件事就有了几种说法。

我的判断是：当新模型能够在常用任务里稳定完成某个步骤，就可以尝试删掉对应的重复叮嘱，再看结果。至于通用能力是否足够，得靠任务验证，不能只看版本号。

留下模型猜不到的内容

拿这次整理的写作 Skill 来说，我要求开头固定为“你好，我是蔡坨坨。”，文章保存到博客目录，还要求不要把我没做过的事情写成亲身经历。

这些内容有保留的理由。模型再聪明，也不能凭空知道我的固定开场、项目目录，更不能推断我到底做过什么。

“写得专业一些”就不同了。这句话缺少判断标准，堆上几遍也没有多少帮助。把要求写成“技术结论给出处，没有实践素材就不要写我亲测”，才方便检查稿子有没有达标。

Skill 最值得留下的，是个人偏好、项目约定，以及能检查的交付要求。

工具脚本和必要的参考资料也要按用途判断。一个负责转换文章格式的脚本，有确定的输入和输出，不能因为说明文件要变短，就连同它一起删掉。

让 Agent 先审一遍

沿着原帖的思路，可以新开一个对话，把下面这段提示词交给 Agent。这是结合 Skill 瘦身整理的版本：

请检查当前项目的 AGENTS.md 和 .agents/skills 中的规则，
帮我判断哪些内容值得精简。现在先审阅，不修改文件。

请按实际影响排序，每个问题都列出文件路径、原文、
可能造成的行为，以及建议替换成的文字。

重点检查：
- 同一件事是否在多处重复规定，或者要求互相矛盾。
- 是否把普通任务也写成必须逐步等待确认。
- 是否存在只有计划、没有完成标准的工作流程。
- 哪些通用步骤可以尝试删除，并用任务验证是否仍然需要。

保留个人偏好、项目约定、必要脚本和明确的批准要求。
涉及权限扩大时单独说明，不要把取消授权边界当成精简。
对不能确定的规则，列出验证方法，不要直接判定它已经过时。