删掉80%的Skill，Agent反而更强了——2026年，别再往Prompt里塞规则了

2026年7月，数字生命卡兹克记了一笔账。

他让一个Agent跑了个长程任务，目标定义得模糊了点。Agent没偷懒，它认认真真跑了整整一夜。等他早上打开电脑，20亿Token烧没了，Agent在错误的方向上一路狂奔了8小时。Agent越勤奋，浪费越彻底——而罪魁祸首不光是目标模糊，更大的坑是规则写得太多太满。

<!-- 配图：膨胀的Skill文件示意，红线圈出重复段落 -->

2026年的Agent开发者陷入了一个集体幻觉：只要把规则写够细、禁令叠够多，Agent就会听话。

现实反手就是一巴掌。

1500行的Skill，每条规则重复8遍

腾讯云开发者郑姝雅维护着一个数据质量检测Agent的Skill。上线之后，模型开始"犯病"：挑错工具、输出被禁字段、"四个维度必须覆盖"的规则下，某个维度因为常年正常就被悄悄跳过了。

她的对策很工程师——接了个自动修复工具。每次Badcase喂进去，工具自动分析、生成修复规则、更新文档、发布。她只看修复结果，不审文档。效率很高。

40次迭代后，她终于打开文档从头读了一遍。

Skill从400行膨胀到了1500行。同一条规则被塞进了8个不同位置，以一种完全不同的措辞。"严禁"、"铁律"层层加码——同一句话通过排列组合繁衍出一个家族。而模型犯错的频率，反而更高了。

越强调，文档越长；越长，注意力越分散；越分散，违反越多；违反越多，再追加一遍。

她把1500行砍到300行，按分层架构重写后，核心规则的遵循率明显回升。不是AI不听话，是它被噪声淹没了。

Anthropic也发现了——删80%，评测不降

如果你觉得这只是个例，看看Anthropic。

团队成员Thariq Shihipar透露，他们把Claude Code的系统提示词砍了超过80%，内部编程评测没有任何下滑。Qoder工程师陈成抓取了实际请求做对比：Opus 4.7时系统提示词15225字符，到Opus 4.8直接砍到4467字符，降了71%。

注意一个细节：砍完之后，团队又加了点东西回去——Opus 5回升到7694字符。加的是什么？"Delivering work + Corrections"——专门用来治新模型的"坏脾气"。核心动作只有一个：只写不得不写的那部分，其余全扔。

扔掉的六类内容是：让模型自判断、少给示例改设计接口、按需加载不一次性加载、说一次就好、交给自动记忆、只给简单规格。

每一条的潜台词都是同一件事：别把模型当白痴，也别把自己当保姆。

这跟代码工程是一个道理——你见过哪个优秀的代码库是堆try-catch堆出来的？每个错误都加一个catch，catch套catch套catch，最后没人能读懂执行流。

注意力是物理定律，不是鸡汤

为什么加规则反而更差？

Stanford那篇经典论文"Lost in the Middle"把话说得很清楚：LLM的注意力分布是U形的。开头和末尾最强，中间掉30%到50%。你往Skill里塞1500行，关键规则在前面没动——问题是后面多了1400行"中间内容"，注意力被稀释得干干净净。

这跟"强调"是两个完全不同的概念。你重复5遍，注意力不会增强5倍——它只会把其他规则的注意力配额抢走。

另一个更坑的问题是隐性冲突。研究显示，顶级模型在指令冲突场景下，23%到47%的情况会出问题。郑姝雅的Skill里有个经典bug：

• 规则A："分析必须覆盖四个质量维度"
• 规则B："正常维度不展开"

当某个维度稳定在99.9%时，模型静默选择B，丢掉A——因为B给了它一个"合理的"跳过理由。模型不会报错，它只是用你的逻辑打败了你的逻辑。

还有否定指令。多项研究证实，"不要做X"的遵循率远低于"只做Y"。token生成是正向选择——你越说"别想粉红大象"，模型越要先把"粉红大象"这个token激活一遍。这不叫听话，这叫条件反射失败。

<!-- 配图：注意力U形曲线示意图 -->

自动修复才是膨胀的加速器

郑姝雅回溯Git历史时发现了一个值得警惕的模式：

每次Badcase，自动修复工具的处理逻辑一模一样——生成一段新规则，追加。它不会去读已有规则找重复，不会分析位置是不是放中间被淹没了，不会判断这条规则跟现有的有没有冲突。它只做一件事：把问题描述转成新规则，找个近似的段落插进去。

40次修复，累计追加1100行，平均每次27行。其中真正的新知识大概300行，剩下800行全是同义反复。

因为"追加"是LLM做长文档修改时最安全的策略——不碰已有内容（怕改坏），不分析位置（要理解注意力机制），不做全局审视（上下文不够扫1000多行）。自动化移除了手工维护的天然刹车——以前人的懒惰是膨胀的天敌，现在机器太勤快了。

任何基于"提取经验→自动追加"的反馈系统，不给它加刹车，都会重蹈覆辙。

三明治法则：别再到处写了

那正确的做法是什么？

先说结论：**把Skill当"工作手册"，别当"免责条款"。**你觉得写得越厚越保险，实际上是在用字数稀释每一条规则的执行力。

具体怎么做，有几个从实战里踩出来的习惯：

核心禁令只写在开头20到50行，中间和结尾都不重复。郑姝雅从1500行减到300行，80%的工作就是消除重复。

无法避免的冲突规则，直接标注各自的适用范围。把优先级写死——"只对有异常的维度展开"改成"总览表格固定包含四性全部行，无论是否正常"。

禁止项改成正向指令。把"严禁在报告结尾给建议"改成"报告结尾以数据表格结束，最后一个元素必须是表格或数值"。这跟训狗一个逻辑——你让它"别坐"，它得先想"坐"是什么。你让它"站着"，它只需要理解"站"。

最关键的限制用三明治结构：开头写一遍（首因效应），末尾再写一遍（近因效应），中间留给执行流。但只对2到3条真正致命的规则这么干——多了就是新一轮膨胀。

参考类内容外置。表结构、SQL模板、报告格式、下钻规则——这些不需要常驻Skill，需要时调用就行。但外置完要审计一遍：你的模板里是不是有被Skill禁止的字段？示例是不是只覆盖了部分维度？参考文件是模型的课本，课本里的例题违反了你定的规矩，模型就会在"听老师的"和"照课本"之间精神分裂。

<!-- 配图：三明治法则示意图，首尾高亮 -->

写到最后，我发现这件事真正反直觉的地方在于——

我们以为Agent不听话是因为"说得不够清楚"，其实是"说得太多，每条都听不见了"。

Prompt Engineering在2026年正在从"写好一句话"进化成"设计一个注意力分配系统"。指令位置、语义负载、隐性冲突、正向表述——这些东西比"再强调一遍"有效100倍。因为Attention is all you need，但Attention的带宽是有限的。你在上面堆的每一行字，都在从别处偷走注意力。

"少即是多"不是设计哲学。是物理定律。