你以为把 AI 调教好，靠的是给它写更多规矩。
上周日，我让 Claude 数了一下我写给它的那份写作技能文件。23899 个汉字，1726 行。「禁止」「绝不」「严禁」「禁用」「禁区」这几个词加起来，一共出现了 84 次。
我盯着那个 84 看了挺久。
这份文件是我从今年 4 月开始一点点不断调整优化做出来的。100 问访谈拆出来的声音档案，7 个反 AI 检测的武器，4 道发布前自检，15 条永远要做，15 条永远别做。每一条都是我踩过坑之后加上去的。我一直觉得这是我比较重要的一块数字资产。
然后 Claude 顺手报了另外几个数字。说实话，看完不太好受。
这份文件的硬规则第 20 条写着「禁止破折号」。而它自己，用了 93 次破折号。
「不是 A 而是 B」这个句式该出现几次，同一份文件里给了两个不同答案。第三部分写「超过 1 次就要删」，第四道自检写「超过 2 次要精简」。
专有名词的密度，全文标准是每 500 到 800 字至少 1 个，首段标准是每 50 字至少 1 个。差了十几倍，但整份文件里没有一句话解释为什么首段要高这么多。
坦白讲，这些矛盾不是 AI 造成的，是我自己一层一层加上去的。我每次改稿不满意，就往文件里再补一条规则。补到第 84 条的时候，我已经忘了第 12 条说过什么。
上周五，Anthropic 官方博客发了一篇文章《The new rules of context engineering for Claude 5 generation models》。作者是他们自己的技术人员 Thariq Shihipar。
这是一篇写给开发者的英文技术文档，我替你读完了，你不用再去花时间。
文章开头就一句话：他们把 Claude Code 的系统提示词删掉了 80% 以上，在编码评测里没有出现明显的性能下降。
不是删掉冗余的废话，是删掉了他们过去几年精心积累的、被验证有效的约束。
原因很简单，他们在内部使用记录里发现，同一个请求中同时存在互相冲突的指令。一条说「酌情保留文档」，另一条说「不要添加注释」。模型收到这两条，得先花算力去调解它们，才能开始干活。
这跟我那份 23899 字的文件是同一个病症。
我的理解是，Opus 5 这一代模型的判断力，已经越过了某个门槛。过去你必须把手把手的规则写死，因为它不会看语境，而现在它会了。如果你还在写死规则，等于把一个能自己判断的资深顾问，当成了实习生使唤。
原文给了六组对照，讲从旧做法转到新做法。这六组本来是给写代码的人看的。我花了一晚上，把它逐条翻译成了独立顾问的场景。在此分享给大家。
1. 别再给 AI 写死流程
原文的旧做法：默认不写注释。永远不写多段落文档字符串或多行注释块，最多一行短注释。
原文的新做法：写与周围代码相匹配的代码，匹配它的注释密度、命名和习惯用法。
看出区别了吗。旧做法在规定动作，新做法在描述环境。
翻译到我们这行：你给 AI 写「第一步做背景分析，第二步列三个假设，第三步给建议」，这是规定动作。你写「这份东西是给一家 800 人制造业公司的 CEO 看的，他上一份类似材料退回过一次，嫌太学术，他要的是能在周一早会上直接讲的东西」，这是在描述环境。
后者的产出质量，我自己的感受是高一个数量级。
我见过太多顾问，在客户那儿做的是一模一样的事。给客户团队写 SOP，写到「第一步打开系统，第二步点击左上角」这个颗粒度，写完还挺自豪，觉得这叫交付扎实。
结果是什么。团队照着做，做对了不知道为什么对，做错了不知道错在哪儿。SOP 覆盖不到的场景一出现，全部卡死，然后打电话给你。
（写到这儿我得承认一件不太光彩的事。我早年在美菜做企业大学的时候，写过一份 40 多页的内部带教手册，细到每个环节的话术模板。当时觉得这是我的心血。现在回头看，那份手册的真正作用，是让新主管们停止了思考。）
本质上，规则的密度和判断力的空间，是一个跷跷板。你按下去一头，另一头必然翘起来。对 AI 是这样，对客户团队也是这样。
今天可以做的事：打开你的 AI 项目指令，把所有「第一步、第二步」的流程描述，改写成「这件事发生在什么场景里、给谁看、上一版被否掉在哪儿」。
2. 范文不如模板结构
原文的旧做法：给工具的使用方式提供示例。
原文的新做法：把精力放在工具、脚本和文件本身的设计上，让参数更有表达力。
原文举了一个例子。一个待办事项工具，它的状态枚举只有三个值：待处理、进行中、已完成。光是这三个值本身，就已经告诉模型该怎么用它了，不需要额外写一段说明。
我第一次读到这里，脑子里蹦出来的是艾伦·韦斯的三选项报价。
你给客户的提案，如果是「诊断服务 / 项目工作坊 / 战略陪跑」这三档，客户不用你解释，他自己就知道该怎么选，因为这三个词本身携带了信息：深度不同，投入不同，解决的问题不同。
反过来，如果你的提案是「咨询服务，报价 30 万」，然后附上五页说明来解释这 30 万包含什么，那你就是在「提供示例」，而不是在「设计接口」。
这条翻译到 AI 协作上，就是：别再往项目指令里塞范文了，去改你的模板结构。
我举个我自己的例子。我以前给 AI 写组织诊断报告，会附三份历史报告让它模仿。产出的东西永远像那三份的平均值，平庸得很。后来我不给范文了，我把诊断报告的字段结构改了：「现象层 / 机制层 / 根因层 / 干预点」，每个字段下面写一句这个字段该回答什么问题。
产出立刻不一样了。因为字段名本身在传递我的方法论，而范文只在传递我的句式。
就像我在前面的文章《如何重新设置Claude Cowork，之前我错了｜Consult With AI》里提到的，我已经把之前建的文件夹和文章范例都删掉了。
今天可以做的事：找出你最常用的那个交付模板，看它的一级标题。如果标题是「背景」「现状」「建议」这种空壳，你就还在靠范文说话。把标题改成携带判断的词。
3. 分层加载
这一条是全篇最重要的，也是我这周真正想说的那件事。
原文的旧做法：系统提示里包含了代码审查和验证的全部细节，哪怕并不总是需要。
原文的新做法：把验证和代码审查移到独立的技能里，模型需要的时候自己去调用。原文管这个叫「渐进式披露」。
它甚至提到，工具的定义也可以延迟加载，代理必须在使用之前先去搜索它的完整定义。CLAUDE.md 和技能文件应该用文件树的方式组织，在合适的时刻才加载相关信息。
我这才意识到，我那份 23899 字的 SKILL.md 文件，是把所有东西一次性塞给模型的。即使只是写一篇朋友圈改写，它也得先读完 7 个武器和 4 道自检。
这就好比你去问一个人「今天几号」，他先把日历的编制原理给你讲一遍。
回到独立顾问的工作场景中，也是如此。
你想想一场标准的方法论导入。你准备了 120 页 PPT，把整套框架从底层逻辑到落地工具一次性讲完。客户团队全程点头，会后合影。
三个月后你回访，发现什么都没落地。
不是他们不认真。是你一次性给了他们 120 页，他们的工作记忆装不下。等到真正需要用某个工具的那一刻，他们想不起来它在第几页，于是放弃，回到原来的做法。
突然想到，老麦前几天给我的留言，也让我在复盘第一期「外贸创始人AI²研习社」课程中有了非常好的反馈与客户视角。
所以，新的做法是需要分层加载。你手上那套东西，不该是一个大而全的文件包，该是一棵逻辑树。
树干是一页纸的索引，说清楚三件事：这套东西是干什么的、边界在哪儿、什么情况下走哪条分支。
树枝是一件事一个文件。做访谈编码的时候只调访谈编码那一份，做汇报的时候只调汇报那一份。
树叶是真实样本。不是描述，是能直接看的成品。
我从 5 月开始把自己的知识库按这个结构重做，现在已见初效，5 个仓库联动分别行使不同职能。已经拆完的那部分，AI 的产出稳定性明显上来了，因为它不用在 23899 字里找那 800 字。
（顺便说一句，Claude Code 里有个 /doctor 命令，是他们专门做来帮你简化技能和 CLAUDE.md 文件的。我已经把自己的系统提示词与全局 CLAUDE.md 文件进行了优化与升级）