上下文工程：官方为何删掉80%提示词

这期讲了什么

• 事件：7 月 24 日一家头部 AI 公司官方博客发文，面向最新一代模型把自家 AI 编程工具的系统提示词删掉 80% 以上，在自家编程评测上没有测出可观察的损失——不是重写不是优化，是删
• 先分清两个词：提示词是一次性的、越具体越好；上下文是系统提示词、技能文件、项目说明、记忆、外挂资料拼成的一整包，要跨几百次请求复用，只能往通用写，而通用最容易写歪
• 为什么当年必须写：老模型判断力不够，不写死它真会乱来，约束当时是划算的保险；新一代模型能看情况办事后，同一条规则从保险变成了成本——规矩不更新，昨天的保险就成了今天的绊子
• 六条被划掉的老经验：给规则→给判断；给例子→设计接口；全塞前面→渐进披露；重要的说三遍→说一遍就够；手动记笔记→自动记忆；简单规格书→富参考（测试用例、函数、网页原型都能当规格）
• 四个位置怎么写：系统提示词绑产品语境、项目说明保持轻量多写坑、技能文件当轻量指南承载特有见识、参考文件优先给代码；外加一个定期删除机制——每次模型换代问一遍这条规则补的短板还在不在

文字稿

官方删掉八成提示词，删的到底是什么

你有没有干过这种事：怕 AI 乱来，规则越写越多。项目说明文件几百行，每条规则后面都跟着「绝不许」「必须」，同一句话怕它忘了，三个文件里各写一遍。我先交代，这些我全干过。

7 月 24 号，有家头部 AI 公司的官方博客发了一篇讲上下文工程的文章，里面有一句话，凡是给 AI 写过规则的人看到都该心里一紧：面向最新一代模型，他们把自家那款 AI 编程工具的系统提示词删掉了 80% 以上，然后在自家的编程评测上，没有测出可观察的损失。注意，不是重写，不是优化，是删。删掉八成，成绩单没动。过去两年整个行业攒下来的那套手艺——注意事项塞满、反例列全、重要的话说三遍——被官方用自己的产品当场证伪了一大半。

先分清两个词。很多人把提示词和上下文混着用，但你在对话框里敲的那句话只是最小的一块。真正送进模型的是一整包东西：系统提示词、技能文件、项目说明、记忆、你外挂进来的参考资料，全部拼在一起，才是模型这一轮真正读到的内容。怎么设计、组织这一整包东西，官方管它叫上下文工程。

提示词和上下文有个本质区别。提示词是一次性的，这一次要干嘛，写得越具体越好。上下文不一样，它要跨几百次请求反复使用，你根本不知道下一句用户会问什么，所以只能往通用上写。而通用这件事恰恰最容易写歪——因为你会忍不住把所有可能出的岔子全都提前堵上。

官方在文里用了一个词，直译过来叫解开脚镣。他们复盘内部使用记录，发现同一次请求里经常有几句互相打架的指令：系统提示词说文档该留就留，某个技能文件说不要写注释，用户又说你就照旧的那个改。三句话来自三个地方，谁都没错，可拼在同一个上下文里就成了一道阅读理解题。模型多数时候能猜出你真正想要什么，但代价是它得先花一轮心思调和这些矛盾，然后才能开始干活。

这里有个特别容易被忽略的因果：这些约束当初不是白加的。老一代模型判断力不够，不写死，它真会满屏写没用的注释、真会到处乱建文档。所以团队宁可接受偶尔管错，也要先把最坏情况堵住。这在当时是笔划算的账。变的是模型，不是道理。新一代模型自己能看情况办事之后，同一条规则的性质就从保险变成了成本。

我给你打个比方。老师傅带新徒弟，头一年在墙上贴满规矩：这台机器不许碰，焊接之前必须喊我。徒弟毛手毛脚，这面墙救过好几次命。三年过去，徒弟出师了，手艺比师傅还稳，可那面墙没人撕。他每干一步还得先扭头看一眼墙——不是规矩错了，是人变了。规矩不更新，昨天的保险就成了今天的绊子。

六条被证伪的老经验

这部分是全文最狠的地方：六条曾经的最佳实践，被官方逐条标成了过时说法。

第一条，从给规则到给判断。老版系统提示词里有这么几句原话：代码默认不写注释；绝不写多段的说明块，最多一行；除非用户要求，不要生成规划、分析文档。新版全删了，换成一句话：写出读起来像周围代码的代码——注释密度、命名、习惯，都跟着上下文走。前者是一条死线，后者是一个判断标准。死线在九成场景里对，但剩下一成里错得很难看，比如某段复杂逻辑真就需要一大段说明。判断标准把这一成交还给了模型。

第二条最反直觉：从给例子到设计接口。过去讲工具调用，第一铁律就是多给示例。现在官方说，对最新的模型，例子反而会把它框死在你举的那几种用法里。那不给例子给什么？去设计工具本身——参数叫什么名字、有哪几个取值、字段之间什么关系。他们举了自家待办工具的例子：状态字段就三个取值，待办、进行中、已完成，模型一看这三个词自己就明白该怎么流转；再补一句同一时间只留一项进行中，行为就定死了。一个例子都没给。接口本身，就是最好的说明书。

第三条，从全塞在前面到渐进披露。这款工具早期什么都往系统提示词里塞，包括怎么做代码审查、怎么做验证——这些不是每次都用得上，但用得上的时候很关键。现在统统被拆成独立的技能文件，需要的时候才加载。工具也一样，一部分改成了延迟加载，模型得先去搜才能拿到完整定义。好处是工具可以做得很多，不用的时候一个字都不占地方。官方还顺手点名了一个流传很广的误区：很多人觉得项目说明文件必须写成大而全的中央仓库，不然模型找不到。错了。正确的做法是拆成一棵文件树，需要哪片叶子取哪片。

第四条，从重要的说三遍到说一遍就够。老模型有个毛病，同一条指令放在上下文末尾比放在开头更容易被听见，所以大家习惯在系统提示词和工具描述里各写一遍。现在这些重复可以直接删掉——工具怎么用，写在工具描述里，一遍，够了。

第五条，从手动记笔记到自动记忆。过去要靠快捷键手动往项目说明文件里记东西；现在模型自己会判断哪些事值得记下来。

第六条，从简单规格书到富参考。以前写方案、写规格习惯落成一个文档。现在官方说，模型能吃下复杂得多的参考物：一套详尽的测试用例可以直接当规格书；另一个仓库里的某个函数可以当规格书；一个网页原型可以当设计稿。甚至什么算好这种品味问题，也能写成评分表，让模型开一个验证代理照着表打分。

六条看下来，它们指向同一个方向。过去我们把 AI 当一个不放心的新人，恨不得把每个动作都写进员工手册；现在官方的意思是把它当一个有判断力的老手——你要做的不是替它决定每一步，而是把标准、接口、参考资料备好，让它自己看着办。

四个位置怎么写和定期删除机制

官方在文章末尾给了四个位置各自的定位。第一个位置，系统提示词。它绑的是产品语境——告诉模型你在哪个产品里、在干什么。直接用现成工具的人基本碰不到它；但如果你在自己搭智能体，这里值得花你最多的时间。

第二个位置，项目说明文件。四个字：保持轻量。简单说清这个仓库是干什么的，然后把大部分篇幅花在坑上——比如，所有类型定义只在这一个文件里，别去别处找。凡是模型翻一眼目录结构就能明白的事，一个字都别写。

第三个位置，技能文件。把它当成需要时能查到的轻量指南，而不是必须遵守的军规。除非是特别要紧的领域，否则别写死；写长了就拆文件。技能文件最值钱的地方，是承载你自己、你团队、你产品特有的那点见识——通用知识模型本来就有，用不着你教。

第四个位置，参考文件。外挂进来的东西优先给代码。官方原话说，一个网页版的设计稿，效果通常好过一段文字描述，也好过一张截图。代码对模型来说是母语，说母语，误会最少。官方还上了个现成工具：在那款工具里敲一个体检命令，它会帮你把现有的技能文件和项目说明做一次瘦身检查。

方法讲完了，说点我自己的实感。我维护着一套几十个技能文件的内容流水线，读这篇文章的第一反应不是学到了，是有点尴尬。因为被点名的每一种写法，我那套东西里都能找到：生怕模型跑偏，每条规则后面跟着绝不许；生怕它找不到，一个文件塞几百行；生怕它忘了，同一句话三个文件各写一遍。这些不是懒，恰恰是过去两年被老模型教出来的条件反射，每一条背后都对应一次真实的翻车。

问题是，条件反射的更新速度赶不上模型换代的速度。当年的约束是为了兜住能力的窟窿，窟窿补上之后，约束不会自动消失——它会留在文件里，继续跟模型现在的判断力对着干。上下文这东西又是只进不出的加法结构，一年攒下来，就是一层压一层的沉积岩。

所以这篇文章真正在说的，不是少写点这种懒人福音。它在说：你的规则文件需要一个定期删除的机制。每次模型换代，都回去问一遍：这条规则当初是为了补哪个短板？那个短板现在还在吗？

最后泼两盆必要的冷水。第一，这不是让你回去把规则一键清空。约束防的是最坏情况，你的场景里最坏情况值多少钱，这笔账只有你自己能算——官方敢删，是因为他们有整套评测兜底，删完能立刻测出有没有掉分。第二，官方删了 80%，你不必照抄这个数字。但如果你从来没删过，那正确答案大概率不是 0。

常见问题

为什么提示词规则越多 AI 反而越笨？

因为同一次请求里来自系统提示词、技能文件、用户的指令可能互相打架，模型得先花一轮心思调和矛盾才能开始干活。这些约束当年是给判断力不够的老模型兜底用的保险；新一代模型能自己看情况办事后，死规则就从保险变成了成本。

上下文工程和提示词有什么区别？

提示词是一次性的，这一次要干嘛写得越具体越好。上下文是系统提示词、技能文件、项目说明、记忆、外挂资料拼成的一整包，要跨几百次请求反复使用，只能往通用写——而通用最容易写歪，因为你会忍不住把所有岔子提前堵上。设计组织这一整包东西就叫上下文工程。

AI 规则文件该怎么瘦身？

四个位置各有定位：系统提示词绑产品语境；项目说明保持轻量、篇幅花在「坑」上；技能文件当轻量指南、写团队特有的见识；参考文件优先给代码。更关键的是建立定期删除机制：每次模型换代都问一遍，这条规则当初补的短板现在还在吗？