[AI经验] AI助手越用越笨？可能是Skill文件太胖了

上周哥们问我：你那个Hermes咋样了，最近没见你提了？

我苦笑：别说了，帮我发条消息能格式报错，做个封面能尺寸搞混，我都怀疑它阿尔茨海默了。

表弟说：你是不是该换个更强的模型？

我说：不应该啊，之前一直好好的。别急，我先看看它脑子里在想什么。

结果这一看，发现一个大秘密。

操作手册800多行，搁谁谁能记住？

我把这些"操作手册"打印出来看——好家伙，一个Skill 800多行！

里面都写了啥？

• 100多行是"当年为什么会这样设计"

• 200多行是代码示例

• 150行是各种编码规范

• 真正要执行的步骤？不到200行。

你让一个AI模型读800多行废话，它能记住关键内容才见鬼了。

问题就出在这里：信息密度超标

我用的MiniMax-M2.5，虽然不是顶级模型，但处理日常任务完全够用。可为什么它频频出错？

经过排查，我发现了一个关键概念：Token数≠信息密度

一个Skill占多少Token，跟它有多少行直接相关。 但信息密度是：每一行里有多少是必须执行的指令，有多少是可以忽略的废话。

就像你给员工一份50页手册让他照着做，大概率会漏掉几页关键内容。

AI模型也一样。

信息密度对比

而且问题会越来越严重。因为每次有新需求，我们习惯性地在现有Skill里加几行。飞书表格不能用？加一条。小红书封面要竖版？加一段。某个平台有特殊限制？再补一个分支。

几个月下来，Skill就像滚雪球一样越来越胖。

笨模型出错的真实表现

Skill没优化之前，MiniMax-M2.5出错很有规律：

○ 跳过检查点

Skill里写了"执行到第3步必须停下来确认"，它直接一路跑到第7步。用户还没看到封面，它已经把六个平台的封面全生成完了。

○ 混淆相似信息

知乎封面尺寸是1478×600，什么值得买是1550×655。两个数字就差一点点，小模型经常搞反。

○ 输出错误格式

飞书不支持Markdown表格，Skill里明明写了"禁止用表格"，它照样输出带|的表格，然后飞书报230001错误。

飞书报错

○ 该停不停

有些步骤需要等用户回复再继续，它自己就往下走了。

这些错误有一个共同特征：不是不会做，是没看清楚该怎么做。

我是怎么解决的

花了3天，把8个Skills全改了一遍。

第一步：把代码扔出去

200多行代码示例从Skill正文中移除，只保留一句"详细代码见references/xxx.md"。模型不需要内联完整脚本，只需要知道调什么。

第二步：把"废话"改成序号

原来一大段"我们建议用户先做A，然后考虑B的情况..."，改成：

Step 1: [动词] [目标] Step 2: IF [条件] THEN [动作] Step 3: [动词] [目标]

第三步：给它画重点

我加了"反例黑名单"——告诉它什么不能做。 比如"飞书禁止用表格"，"已发表文件不能改"。

这类显式禁止项加上之后，出错率明显下降。

第四步：隔几步让它歇口气

每做两三步就加个检查点，强制它停下来确认。

这对我模型来说是"路标"——走到这里必须看一眼再继续。

改完效果怎么样？

直接看数据：

大Skill（>300行）→ 精简为主，代码移references/ design-shi-wiki: 837 → 274 行（-67%） ima-skill: 286 → 155 行（-46%） batch-embedding: 224 → 160 行（-29%） 中Skill（200-300行）→ 精简 + 结构增强 scrapling-fetch: 142 → 97 行（-32%） 小Skill（<200行）→ 结构增强为主（行数可能增加） ocr-and-documents: 194 → 238 行（+23%） local-mem0-setup: 188 → 211 行（+12%）

有意思的是，有3个小Skills反而变长了——因为之前缺检查点，我给补上了。行数多了，但AI执行更准了。

总量从2138行减到1418行（-34%），但更重要的不是减了多少行，而是信息密度的变化。

优化结果

5条可复用的拆分方法论

从这次优化中提炼出5条方法论：

方法论

1. 一个Skill只做一件事

路由Skill纯调度，不含执行逻辑。就像设计虱写作系统的v3.0，核心就是一个路由表：用户说了什么→做什么→加载哪个Skill。没有执行逻辑，只有调度指令。

2. 信息密度控制在200行以内

超过200行就开始拆：代码移到references/，历史文档移到references/，详细平台规则移到references/。SKILL.md只保留核心步骤和检查点。

3. 编号步骤替代散文描述

Step 1 → Step 2 → Step 3比"首先...然后...最后"清晰得多。小模型处理编号步骤的成功率远高于处理自然语言描述。

4. 反例黑名单比正面规则更有效

列出"不要做什么"比列出"要做什么"更容易被模型记住。尤其是飞书格式限制、文件保护这类硬性规则。

5. 检查点前置

关键确认步骤放在Skill开头而非中间。小模型的注意力在Skill开头最集中，越往后越容易漏。

什么情况下该拆

不是所有Skill都需要拆。判断标准很简单：

• 超过300行 → 必须拆

• 200-300行 → 看是否有重复内容或隐式分支

• 小于200行 → 补结构（CHECKPOINT、Anti-patterns），不一定要拆

拆的时候按优先级来：先把代码移出去，再删理念性内容，最后合并重复部分。改一个验证一个，别一口气全改。

坚持创作有深度、高质量的作品、致力于分享干货、抵制标题党和网络垃圾，是我的座右铭。 关注我，蹲后续。您的支持对我真的很重要O(∩_∩)O）。让我们共同打造互联网内容创作和知识分享的一股清流！ヾ(◍°∇°◍)ﾉﾞ