本期要点

有人说把 Skills 和规则全删掉之后，AI 反而变聪明了。我攒了 80+ 个、用了半年多，结论正相反：问题从来不是数量，是当前任务到底注入了哪几条、写得对不对。我拿自己的系统做了一次同任务对照实验，一共三个版本，本想证明「注入 Skills 的更强」，结果重规则那版被一句写错的系统提示坑到一次网都没搜，轻规则那版反而自己找对了该用的 Skill。这期讲清楚该删什么该留什么，判据只有一条：需要模型二次解释的规则，删掉或换成范例。

最近看到一个视频标题，大意是把所有 Skills 和规则都删掉之后，Claude 反而变聪明了。

这种说法很容易让人心动。在中文平台上也已经能看到同类话题。辛辛苦苦给 AI 写了一堆 system prompt、规则文件和自定义 Skills，用着用着发现系统不仅没变稳定，反而偶尔冒出死板的输出，或者漏掉关键步骤。这时候有人告诉你“全删了反而更好”，确实会让人琢磨：难道真是规则把模型搞笨了？干脆一把清空最省事？

我自己有 80+ Skills，用了半年多。在这个过程中，我也遇到过因为漏读私有规则而踩线、或者错误注入导致模型行为变形的具体问题。

但我很明确的体会是：问题从来不是 80+ 这个数量本身，而是当前任务到底注入了哪几条规则、这些规则本身写得对不对，以及系统能不能保证只在需要的时候用上对的那几条。

把退化归结为规则害了模型，就像把程序写出 bug 归咎于代码行数一样，把具体的工程问题简化了。

抛开标题，看视频到底测了什么

标题为了传播写得很有戏剧性。把视频作者 Nate Herk 的原片完整看一遍，会发现那句「删了 80% 反而更聪明」其实把三件不同的事压进了一句话：

第一件，Anthropic 自己把 Claude Code 内置的系统提示词删掉了 80% 以上。这是官方工程师在裁他们自己的内置指令，不是 Nate 删掉了自己 80% 的 Skills。

第二件，Claude Code 的创始工程师 Boris Cherny 在一段访谈里建议：每隔半年把 CLAUDE.md、Skills 和 hooks 删掉试试，看看新模型自己能做到什么程度。这是 Nate 剪进视频的片段，不是他的发现。

第三件，Nate 自己复制了一份仓库，去掉 CLAUDE.md 和全部 Skills，短暂用了一下，觉得还行（视频约 3:49 处）。他并没有在日常生产环境里把 Skills 删光。

而且，他只试了一个任务类型：生成一份 YouTube 资源指南。

在没有加载任何 Skills 的情况下，输出的排版确实变乱了，没有规范的标题头，格式也不工整（约 5:03–5:14）。但因为少了一些写得太死的格式束缚，模型对内容的组织方式更符合他当次的主观偏好。这本质上是一次单任务下的主观偏好变化，并不是严格的能力基准测试。

再看视频后半段（约 5:47 与 6:45），Nate 明确说明自己没有做全量扫荡删除。他真正的主张是把过于具体的旧指令精简掉，提高 prompt 的抽象层级，给模型留出验证手段；而在知识工作场景中，品牌、配色和链接格式这些私有上下文，依然需要保留。

所以，视频实际支持的是对过度具体的指令做简化与验证，而不是无差别清空。

私有约定无法靠通用推理恢复

如果规则写多了容易出问题，能不能索性把规则全删了直接裸跑？

答案是不能。模型能力再强，也无法仅凭当前任务推断出你的私有约定和硬性边界。

这在我的实际流程里发生过真实的事故。在 Newsletter 第 045 期起草时，有一轮执行漏掉了专用的 Newsletter 写作 Skill。

翻看当时的工作日志，成稿出现了几处结构问题，重点看其中两处的失误：

1. 栏目名用了早就淘汰的旧版命名；
2. 筛选出的三条行业动态通篇只有客观事实罗列，漏掉了“每条信号必须包含作者主观判断”的硬性要求。

在没有读取私有约定时，模型生成了一份完全符合通用习惯的新闻汇总。但它不可能凭空猜到：在我的 Newsletter 体系里，读者看重的是 Axton 的筛选视角与判断，而不是客观动态流水账；它也不可能自行知道哪个栏目最近改了名字。

模型可以推出一个合理的答案，但它推不出你过去为什么已经否决过这个答案。

在回查并读取对应的 Newsletter Skill 后，稿件里的这两处失误和结构缺失都得到了修正。

这一类规则 —— 专有命名、品牌栏目、链接规范、不可妥协的交付标准 —— 属于模型在通用语料里学不会的私有事实与机械约束。一旦丢掉它们，模型只能退回通用平均水平，最后依然需要人工逐行收拾。

一次对照实验：错误注入与路由错配

复杂规则确实可能干扰模型的执行，但背后的原因往往是错误的注入内容或路由错配。

我曾做过一次三轮的同任务的对照实验：在同一天、使用同一个模型，输入逐字节完全相同的任务描述。三组执行记录呈现出了明显的行为差异：

• ARM-v1（未显式注入 Skill 与信源块）：调用了 10 次联网检索；
• ARM-v2（显式注入了 5 个研究类 Skill 和本地信源块）：联网检索 0 次；
• ARM-v2b（保留了 Skill 注入，但去掉了该信源块）：联网检索 22 次。

为什么 ARM-v2 连一次检索都没做？

排查执行上下文后，一个最强的机制解释浮现了出来：ARM-v2 的本地信源块里夹带了一句错误声明：“当前处于无网络环境”。这一版随后 0 次联网检索，而且在输出里复述了当前无网络这个前提。

当然，这里不能把两者写成已经隔离的直接因果。ARM-v2 与 ARM-v2b 相差的是整块信源说明，不只是这一句话；三个版本也都只跑了一次。错误声明与零检索结果相互吻合，是目前最强的机制解释，但并不能说是唯一变量已经被证明的证据。

另一个现象发生在 Skill 路由上。系统给 ARM-v2 匹配注入了 5 个 Skills，但全是通用研究类工具，没有一个是本次任务需要的 Newsletter 写作规范。而在没有做显式注入的 ARM-v1 中，模型反而自己在上下文环境中找到了真正匹配的 Newsletter Skills 并完成了读取。

所以这次实验不能证明“规则越多表现越差”。它能支持的有限结论是：错误的能力声明可能压制必要检索，路由错配也可能让任务读到一组不相关的规则。这个结果是否稳定，还需要重复运行才能判断。

给 Skills 和规则做一次最小审计

如果你手头也积累了不少 Skills、规则文件或长篇 system prompts，开始感觉系统偶尔出现偏差，不需要盲目清空，也不用继续往上叠加规则。可以按以下步骤做一次最小审计：

1. 抓取当前激活层

不用去数规则库里总共有多少个文件。真正占用上下文并直接影响输出的，是当前任务实际激活了哪几条。如果系统有日志，直接调出本次运行的上下文记录；如果没有完整日志，就手动记录下当前任务显式加载的 prompt、引用文件与 Skill 清单。

2. 将生效规则按类型梳理

对激活层里的每条规则做一次归类，建立去留优先级：

• 私有事实与约定（优先保留）：专有命名、品牌栏目、固定模板、链接规范——这些属于模型无法靠通用推理获知的私有信息。
• 可机械核验的硬约束（优先保留）：必须包含的特定字段、字数边界、必须触发的工具——这些能通过肉眼或简单规则直接验证。
• 需要模型二次解释的泛化指令（重点审计）：诸如“分析要深刻”、“表达要生动”、“逻辑要严密”，或者为了修补某次偶发失误而写下的长篇抽象限制。

3. 处理泛化指令

• 删掉没有信息量的形容词套话，把推理空间留给模型；
• 如果确实有特定的风格倾向，将抽象描述改写为 1–2 个具体的正反范例（Few-shot Examples）；
• 属于低频特定场景的规则，从全局提示词中移出，改写为仅在特定任务加载的独立 Skill。

4. 冻结任务做轻重两版复跑

修改之后，不要凭单次阅读的主观感觉来判定效果。

挑选一个跑过的具体任务，固定住输入材料、使用的模型与可用工具：

• 运行一版包含修改前完整规则的版本；
• 运行一版去掉了冗余指令的轻量版本；
• 重点比对三个可观测指标：该调用的必要工具是否调用了？预设的硬规则是否命中了？过去出现过的已知错误是否复现了？

依据实际行为指标做出的保留、改写或删除决定，才经得起推敲。

四步记不住的话，记三个问题就够：这条规则是必要的吗，模型靠通用常识学不会的才值得写；它现在还正确吗，工具、接口和流程一变，几个月前的补丁可能已经成了错误指令；我能验证它真的生效了吗，既不能观察、出错也无法反证的规则，不算系统能力。

结语

在搭建 AI 工作流时，我们很容易在两个极端之间摇摆：要么试图把每个细节都写进规则，要么在系统出现摩擦时干脆一把清空。

真正让系统保持稳定的，不是规则库的绝对大小，而是让正确的上下文在需要的任务中被激活，并且让每一次调用的结果都可验证。这和 MAPS 关注的工作流方法论是同一个方向。

如果你现有的规则库也开始带来维护负担，不妨挑一个常用的具体任务，按这套流程做一次轻重版本的复跑对比，看看哪些规则真正需要留下。

📌 本期推荐

这封信写的是判断，不是教程。想看这些判断怎么落成能跑的东西，精英圈 PRO 里有每月一期的录播课，以及我自己在用的 Skills、Prompt 和 Make 蓝图。
→ 加入精英圈，获取独家深度分析

Axton 的 AI 实践工具箱
🎓 MAPS 课程 — 从方法论到可交付系统
👥 精英圈 PRO — 深度实践者社群
🆓 免费入门课 — 零门槛开始

MAPS 术语词典 & 原典索引：https://www.axtonliu.ai/maps