# Claude Code 系统提示词删掉 80%，编程评测零损失！你写的规则可能正在把模型变笨 - URL: https://davidyin.dev/writing/221-20260725-claude-context-engineering-rules/ - 作者: David Yin - 发布: 2026-07-25 - 标签: 上下文工程、提示词、Claude Code、CLAUDE.md、Skills、Agent - 摘要: Claude 官方把 Claude Code 系统提示词删掉 80%，编程评测零损失——「规则写满、反例列全、重要的事说三遍」那套手艺被官方产品当场证伪大半。文章讲清提示词与上下文的区别，逐条划掉六条过时做法（给规则→给判断、给例子→设计接口、全塞前面→渐进披露），并给出系统提示词、CLAUDE.md、Skills、参考文件的写法：保持轻、按需加载，规则文件要有定期删除机制。 7 月 24 日，Claude 官方博客更新了一篇讲上下文工程的文章。里面有一句话，凡是给 AI 写过工作流的人，看到都该心里一紧： 面向 Claude Opus 5 和 Claude Fable 5 这一代模型，他们把 **Claude Code 的系统提示词删掉了 80% 以上**，在自家的编程评测上没有测出可观察的损失。 不是重写，不是优化，是删。删掉八成，成绩单没动。 这句话的杀伤力在于，过去两年整个行业攒下来的那套手艺——把注意事项塞满、把反例列全、把每条规则重复三遍——被官方用自己的产品当场证伪了一大半。 ## 先说清楚：被删的到底是哪部分 很多人把「提示词」和「上下文」混着用，但这篇要说的，不是你在对话框里敲的那句话。 你敲的那句只是最小的一块。真正送进模型的是一整包东西：系统提示词、Skills、CLAUDE.md、记忆、@ 进来的参考文件……全部拼在一起，才是模型这一轮真正读到的内容。官方管这叫**上下文工程**。 区别在哪？提示词是一次性的，可以写得非常具体；上下文则要跨几百次请求反复使用，你根本不知道下一句用户会问什么，所以只能往「通用」上写。 而「通用」这件事，恰恰最容易写歪——因为你会忍不住把所有可能的情况都提前堵上。 ## 官方原话：我们把 Claude 管得太死了 文章里用了一个词叫 unhobbling，直译是「解开脚镣」。团队复盘自己内部用 Claude Code 的对话记录，发现同一次请求里经常出现互相打架的指令： 系统提示词说「文档该留就留」，某个 skill 说「不要写注释」，用户又说「你就照旧的那个改」。 三句话来自三个地方，谁都没错，但拼在一个上下文里就变成了一道阅读理解题。模型当然能猜出你真正想要什么，代价是它得先花一轮心思去调和这些矛盾，然后才能开始干活。 这里藏着一个容易被忽略的因果：**这些约束当初不是白加的**。老一代模型判断力不够，不写死就真会写出一屏胡说八道的注释、真会满仓库拉平文档，所以团队宁可接受「有时候管错」，也要先把最坏情况堵住。 变的是模型，不是道理。新一代模型自己能看情况办事之后，同一条规则的性质就从「保险」变成了「成本」。 ## 六条老经验，被官方逐条划掉 文章里最狠的，是这张对照表——六条曾经的最佳实践，现在全被划成了过时说法。 **第一条：从「给规则」到「给判断」。** 老版系统提示词里原话是这样的：代码里默认不写注释，绝不写多段式 docstring 或多行注释块，最多一行；除非用户要求，不要生成规划、决策、分析文档。 新版换成了一句话：**写出读起来像周围代码的代码——注释密度、命名、习惯，都跟着上下文走。** 前者是一条死线，后者是一个判断标准。前者在 90% 的场景里对，在剩下 10% 里错得很难看（比如某段复杂逻辑真就需要一大段说明）。后者把这 10% 交还给了模型。 **第二条：从「给例子」到「设计接口」。** 这条最反直觉。过去讲工具调用，第一铁律就是给示例。现在官方说，示例反而会把模型框死在你举的那几种用法里。 替代方案是去设计工具本身——参数取什么名、有哪几个取值、字段之间什么关系。 他们举了自家 Todo 工具的例子：状态字段就写成 pending / in_progress / completed 三个枚举值，模型自己就明白该怎么流转；再补一句「同一时间只留一项处于进行中」，行为约束就定死了。 不需要例子。接口本身就是最好的说明书。 **第三条：从「全塞在前面」到「渐进披露」。** Claude Code 早期什么都往系统提示词里塞，包括怎么做代码审查、怎么做验证——这些内容不是每次都用得上，但用得上的时候至关重要。 现在这些统统被拆成独立的 skill，需要时才加载。工具也一样：一部分工具改成了「延迟加载」，模型得先用 ToolSearch 去搜，才能拿到完整定义。好处是工具可以做得很多，不用的时候一个 token 都不占。 顺便，官方专门点名了一个流传很广的误区：很多人觉得 CLAUDE.md 和 skill 文件必须写成大而全的中央仓库，否则模型「找不到」。正确做法是拆成一棵可以按需加载的文件树。 **第四条：从「重要的说三遍」到「工具描述里说一遍」。** 老模型有个毛病，同一条指令放在上下文末尾比放开头更容易被听见，所以团队习惯在系统提示词和工具描述里各写一遍。现在这些重复可以直接删掉，指令归位到工具描述里就够了。 **第五条：从「手动记进 CLAUDE.md」到「自动记忆」。** 过去要用 `#` 快捷键手动往 CLAUDE.md 里写东西，现在模型会自己判断哪些东西值得记下来。 **第六条：从「简单规格书」到「富参考」。** 以前写 plan、写 spec，习惯落成一个 markdown 文件。现在官方说模型能吃下复杂得多的参考物：一份详尽的测试套件可以当规格书，另一个仓库里的某个函数可以当规格书，一个 HTML 原型可以当设计稿。 甚至评分标准也是一种参考——把「什么算好的 API 设计」写成 rubric，让模型开一个验证 agent 去照着打分。 ## 那到底该怎么写 文章末尾给了四个位置各自的定位，这部分其实比前面六条更实用。 **系统提示词**：它绑的是产品语境——告诉模型你在哪个产品里、在干什么。用 Claude Code 的人基本不用碰它；但如果你在自己搭 agent，这里值得花最多时间。 **CLAUDE.md**：保持轻。简单说清这个仓库是干什么的，然后**把大部分篇幅花在坑上**——比如「所有类型定义只在这一个文件里，别去别处找」。凡是模型翻一眼文件结构就能知道的事，一个字都别写。 **Skills**：把它当成「需要时能查到的轻量指南」，而不是必须遵守的军规。除非是特别要紧的领域，否则别把 skill 写得太死。写长了就拆文件。skill 最大的价值是承载**你自己、你团队、你产品特有的那点见识**——通用知识模型本来就有。 **参考文件**：@ 进来的东西优先给代码。官方原话是，一个 HTML 版的设计稿，效果通常好过一段文字描述，也好过一张截图。 官方还顺手上了个工具：在 Claude Code 里敲 `/doctor`，它会帮你把现有的 skill 和 CLAUDE.md 做一次「瘦身体检」。 ## 一个做工作流的人的实感 我自己维护着一套几十个 skill 的内容生产流水线，读到这篇的第一反应不是「学到了」，而是有点尴尬。 因为我那套东西里，被点名的每一种写法都能找到——生怕模型跑偏，每条规则后面都跟着「绝不许」「必须」「否则视为未完成」；生怕它找不到，一个 skill 塞了几百行；生怕它忘了，同一句话在三个文件里各写一遍。 这些不是懒，恰恰是过去两年被模型教出来的条件反射。每一条背后都对应着一次真实的翻车。 问题是，条件反射的更新速度赶不上模型。当年那些约束是为了兜住能力的窟窿，窟窿补上之后，约束不会自动消失——它会留在文件里，继续和模型现在的判断力对抗。上下文这东西又是加法结构，只进不出，一年下来就成了一层层压死的沉积岩。 所以这篇文章真正在说的，不是「少写点」这种懒人福音。它说的是**你的规则文件需要一个定期删除的机制**——每次模型换代，都该回去问一遍：这条当初是为了补哪个短板？那个短板还在吗？ 还有一句话值得单独拎出来：约束的作用是防最坏情况，不是提升平均表现。防最坏情况是有代价的，代价就是你顺手把最好的情况也一起摁死了。以前这笔账划算，现在不一定了。 至于删多少合适——官方自己删了 80%，你不必照抄这个数字。但如果你从来没删过，那大概率不是 0。 --- **数据来源** - Claude 官方博客：《The new rules of context engineering for Claude 5 generation models》（2026 年 7 月 24 日，作者 Thariq Shihipar） - Claude 官方博客：《A field guide to Claude Fable: finding your unknowns》 - Claude Code 官方文档（code.claude.com/docs） --- 你手里的 CLAUDE.md 或者规则文档，现在有多少行了？上一次删东西是什么时候？