最近有一个说法在开发者社区里传得比较广造 Claude Code 的人亲手把它 80% 的系统提示词删掉了。这个百分比我没法考证也不想争论数字准不准。真正让我感兴趣的是它背后那条信息——2026 年上下文工程这套规矩可能真的要变了。我见过太多人第一次接触 Claude Code 时搜索关键词排在前面的是“怎么安装”“VS Code 怎么配置”“怎么卸载”。装好之后呢打开工具把整个仓库丢进去等它输出一段看起来还不错的代码。结果它要么读得太慢要么改错了模块要么把不该动的地方也动了。很多人这时候会抱怨一句“模型不行。”但作为一个长期折腾各类 AI 编程工具的人我的判断是很多时候不是模型不行而是上下文没有被治理。Claude Code 真正解决的不是“帮你写代码”这个表面需求而是把一个原本靠人反复粘贴的抽象东西——“上下文”变成了一份可以维护、可以复用、可以按需加载的工程资产。系统提示词变短不是说明规则变得不重要了而是规则的存放位置和加载方式发生了根本变化。这篇文章我想从这件事出发聊聊上下文工程在 2026 年可能带来的改变以及我们普通开发者要怎么落地。1. Claude Code 不是又一个人工智能玩具它把“上下文”变成了工程对象1.1 它真正替代的是反复粘贴“项目背景”这件事在 Claude Code 出现之前我们用 AI 编程工具最烦的一件事不是模型回答得不好而是每次对话都要重新交代背景。这个项目是 Python 后端还是前端工程代码在哪几个目录里依赖是 npm 还是 poetry 管理哪些文件不能动测试命令是什么代码风格是 4 空格还是 2 空格单人开发时你还能忍受这种重复劳动。但一旦项目规模上来这段“前情提要”本身就是巨大的时间成本。更麻烦的是你写少了模型就靠猜你写多了对话窗口里一半内容被背景信息占掉真正能用于任务的空间反而变小。Claude Code 这类型工具带来的变化是让模型自己读取文件树、读取项目配置、读取仓库里已有的记录然后把其中一部分稳定信息保存成项目记忆文件。你不再需要每次解释“这是一个什么项目”只需要告诉它“这次要改哪里”。这才是它真正替代的东西不是写代码而是重复描述代码背景。1.2 用命令行只是表象核心是工作流很多人一看到“命令行工具”就觉得是给极客用的是另一种形式的聊天窗口。但 Claude Code 真正特殊的地方不是终端交互而是它允许你把这套能力嵌入到工作流里。你可以用脚本调用它可以在 CI 流程里跑它可以把一次任务拆成多个小步骤每一步只关注一个文件或一个函数。它不是逼你在对话框里一次性描述完所有需求而是允许你像写程序一样把任务拆开、组合、重试、记录。这就带来了一个关键差异它不再是一个“问你一句答一句”的工具而是一个可能持续运行、反复读取和修改项目文件的执行者。这时候上下文就不再是一段对话记录而是这个执行者在很长一段时间内理解项目的基础。如果上下文不治理后果不是“回答差一点”那么简单而是它可能在一个错误的前提上继续往下执行越改越偏。1.3 和 Codex 放在一起看才能理解“上下文工程”的差异社区里很多人会搜“Claude Code 和 Codex 的区别”。从定位上看两者不完全一样。Codex 更强调和编辑器、IDE 场景的深度协同更像是坐在你旁边帮你改代码的协作者Claude Code 则更偏向终端、批处理、自动化适合把任务写进脚本和流水线里。但更值得关注的不是谁替代谁而是它们都开始把“上下文”从一次对话里抽离出来变成环境的一部分。过去上下文是聊天窗口里不断滚动的历史消息现在上下文是文件、目录结构、项目记忆、工具权限和任务描述的组合。你给模型的项目记忆文件写得好不好几乎决定了它在实际项目里的表现上限。这也是我为什么觉得“系统提示词被删掉 80%”这个信息值得讨论它不是一次简单的优化而是一个信号说明工具的设计者正在把上下文从“写进系统提示词”迁移到“由运行环境动态提供”。2. 系统提示词删掉 80%不是省 token是决策权重新分配2.1 系统提示词、项目记忆文件、任务描述各管一段先说结论如果“删掉 80% 系统提示词”这个说法属实我看到的不是“偷懒”或“倒退”而是上下文管理的思路变了。要理解这个变化先要分清三层内容系统提示词模型每次开始工作前固定看到的一段指令通常由工具内置。项目记忆文件存在于项目目录里的记录工具会按需读取和更新。任务描述开发者真正发出的一条指令比如“修复 payment 模块的时区问题”。以前的思路是为了让模型稳定遵守某些规则就把规则尽可能多地塞进系统提示词里让它在任何情况下都“记得”。但这样做的代价也很明显上下文预算被系统提示词占掉真正留给用户任务和项目信息的位置就变少了而且规则一旦过多模型对某些次要规则的遵循度反而会下降。如果 Claude Code 真的把系统提示词删掉了 80%那它真正删掉的是“每次都必须背在身上的静态规则”而不是把规则彻底丢弃而是把这些规则移到了外部文件、运行时状态和工具调用流程里。2.2 为什么过去系统提示词越写越长过去很长一段时间我和很多搞提示词工程的人一样倾向于把系统提示词写得很长原因很简单模型不记事儿。模型不会主动去读你的项目目录也不会记得上周你说过“这个模块不要用同步请求”。所以你要么在系统提示词里写清楚要么在任务描述里反复强调。系统提示词因此变成了一个“项目背景技术栈代码规范输出格式禁止事项”的大杂烩。这种写法在小项目里有效因为规则少模型很容易遵循。但到了真实项目里问题就暴露了。一个仓库可能有几十条规范有命名约束、依赖约束、路径约束、权限约束。如果你把这些全部塞进系统提示词模型处理每个请求时都要背着这一大包规则它既消耗上下文也增加了规则之间互相冲突的概率。更麻烦的是你在写系统提示词的时候很容易把只对某个模块有效的规则写成了对全项目都生效的全局规则。长并不等于好。越长越容易稀释模型对关键信息的注意力。2.3 删掉 80% 背后真正发生的是“静态规则变薄动态上下文变厚”我理解的核心转变是静态规则正在变薄动态上下文正在变厚。什么叫静态规则就是那些“无论什么时候都应该成立”的全局约束。比如“不要修改锁文件”“不要删除迁移文件”“输出格式必须是 JSON”。这些规则当然要保留但它们更适合放在项目记忆文件里由工具按需读取而不是写进系统提示词里。什么叫动态上下文就是当前任务真正需要的信息。比如“这次任务涉及的是订单模块依赖了外部的结算服务在测试环境里可能要 mock 掉”。这类信息应该放在任务描述里让模型只在需要时感知其他时候不占用注意力。如果系统提示词被砍掉 80%那被砍掉的大概率是那些“看起来很重要但大多数任务根本用不到”的静态规则。它们没有消失而是被转移到了更合适的位置。这才是上下文工程的真正方向不是把所有规则背在身上而是让规则靠近它所属的任务按需加载、用完就走。2.4 一个更容易理解的类比旧思路像一个旅行者把所有行李都背在身上。好处是无论到哪一站想拿什么都能马上拿出来。坏处是走几步就累翻行李还要花时间行李之间还会互相压挤。新思路是分门别类装进不同的箱子根据目的地只带上要用的那几箱。系统提示词是随身携带的急救包只在关键时候打开项目记忆文件是托运行李到了特定场景才去取任务描述则是你本次出门的目的地决定了你会打开哪个箱子。这个类比放到 Claude Code 里就是系统提示词不再负责“教会模型理解所有项目”它只负责划定最底层的边界真正理解项目这件事交给了持续读取文件、持续更新记忆的运行机制。3. 2026 年上下文工程的四条新规矩3.1 规矩一信息密度比上下文长度更重要过去很多人追求“上下文越长越好”觉得窗口够大模型就能记住更多信息。但在实际操作中你会发现上下文窗口变大不等于模型就有效利用了这些信息。信息多了噪声也多了。新规矩是先看信息密度再看上下文长度。所谓信息密度就是“每句话里有多少能直接影响输出结果的内容”。比如下面两种写法低密度写法我们的项目是一个互联网公司内部使用的后台管理系统技术栈是 Vue 3组件库是 Element Plus后端使用 Go 编写数据库是 MySQL部署在 K8s 集群上。这次的业务背景比较复杂……高密度写法项目后台管理系统 前端Vue 3 Element Plus 后端Go 数据库MySQL 本次改动订单列表导出功能导出格式与现有 CSV 导出保持一致后者不一定更短但密度更高模型不需要从一段背景介绍里提取关键信息直接就能理解当前任务。在 Claude Code 里这个原则同样适用。项目记忆文件里不要写大段描述性文字而是尽量写可检索、可判断、能直接约束输出的规则。3.2 规矩二稳定信息进记忆文件临时信息进任务描述这是我现在处理所有 AI 编程工具项目时都遵循的一个拆分方式。稳定信息是指那些“这个项目只要存在就应该一直成立”的信息。例如项目语言和框架目录结构约定测试命令禁止修改的文件命名规范这类信息应该进入项目记忆文件由工具自动读取不需要每次重复。临时信息是指“只对当前这次任务成立”的信息。例如这次要改哪个模块这次允许动哪些文件这次不需要处理边界情况上线窗口是本周五这类信息应该写进任务描述里任务结束就作废不需要进入全局记忆。很多人容易颠倒过来把“这次任务不要碰用户鉴权模块”写进了全局记忆文件结果之后所有任务都会受影响又把“项目使用 pnpm”这种稳定信息写进每条任务描述白白消耗上下文。3.3 规矩三权限和工具列表要做减法Claude Code 这类工具往往允许你配置它可以执行哪些命令、读写哪些目录、调用哪些工具。新规矩是权限越小出错越少。这听起来像是在约束模型实际上是在保护项目。如果你让它放开手脚它可能为了完成一个任务顺手改了版本锁定文件、执行了没有必要的格式化命令、甚至删掉了看起来无关的目录。一旦发生这种事你很难在事后逐行找回。更合理的做法是任务需要什么权限就开什么权限允许它访问哪些目录就先限定到哪些目录不需要它执行 shell 命令时就把命令权限关掉。从上下文工程的角度看这也是在减少噪声。权限列表越短模型越不可能在错误的操作路径上跑偏。3.4 规矩四把按需加载当作默认设计系统提示词被删掉 80%在我看来就是把“按需加载”变成了默认设计。具体到实际使用中这个规矩可以翻译成几个可执行动作全局配置只保留最底层的硬性约束。项目记忆文件按项目单独维护不搞一份全局万能文档。遇到只对某个子目录有效的规则就放在子目录附近不要放到根目录。任务描述里只写本次相关的背景不复制粘贴项目介绍。按需加载的好处是模型在大多数任务里不需要背着一堆无关规则只有在真正进入某个模块时才读取该模块相关的上下文。3.5 一条 CLAUDE.md 该长什么样如果你刚接触 Claude Code最值得先落地的就是项目记忆文件。下面是一个很克制的示例结构# 项目记忆 ## 项目类型 Python 异步服务提供 REST API。 ## 目录约定 - src/ 主代码 - tests/ 测试 - docs/ 文档 ## 常用命令 - make test - make lint ## 禁止操作 - 不要修改 database/migrations/ 下的文件 - 不要修改 poetry.lock这个文件不是一次性写出来的而是随着任务推进慢慢补充的。每当你发现模型反复混淆某个规则就把它写进去每当你发现某条规则只对单个模块有用就不要放在根目录。4. 从安装到跑通先建立一套最小上下文工作流4.1 环境准备先确认 Node.js 和安装方式很多人最早搜的是“Claude Code 安装”“Claude Code 下载”。实际落地时常见的安装方式是通过 npm 全局安装命令结构类似下面这样npm install -g anthropic-ai/claude-code不同版本的安装方式可能有变化所以安装前先确认自己的 Node.js 版本是否满足要求npm 源是否正常。如果你用的是桌面版或 VS Code 扩展也可以先通过扩展市场找到对应入口。这里有一个容易踩的坑只装完核心包还不够还要看它能不能正常读写当前项目目录。权限不足会导致很多奇怪问题后面排查的时候会一直绕圈。4.2 第一次运行任务越小越好装好之后不要急着丢一个“帮我重构整个项目”的宏大任务进去。你第一次使用它的目标不是证明它有多强而是验证一条最小链路能不能跑通。我建议第一次只做这样一件事让它读取一个文件给出问题判断。claude 读取 src/payment.py列出这个文件中所有可能抛异常但没有被捕获的地方这个任务足够小不涉及太多上下文也没有写入操作即使出错也不会对项目造成影响。跑通之后再尝试让它修改文件、运行测试、批量处理。如果连这种最小任务都会报错问题通常出在环境、模型标识或权限配置上而不是模型能力本身。4.3 建立项目记忆文件从三条规则开始很多人一上来就想写一份非常完整的项目记忆文件把技术栈、目录、命名规范、部署方式全部放进去。我建议反着来从三条规则开始。先写项目类型是什么。哪些目录是最核心的。哪件事是绝对禁止的。三条就够。然后开始真实任务让它在实际运行中暴露问题。每当它犯了一个和“项目背景”有关的错误再去补充对应的规则。这个做法的好处是你不会把时间浪费在写“模型本来就不会犯错”的规则上。你写的每一条都是经过实际任务验证过的、确实会影响输出的规则。4.4 关键配置模型、权限模式、工具白名单Claude Code 在不同版本里提供的配置项不太一样但大致会涉及几个维度配置维度常见问题建议模型标识自定义模型标识与当前版本不匹配先确认当前版本支持的模型名再填配置权限模式给了过高权限模型误改文件从最小权限开始按需逐步放开工具白名单允许执行任意命令先限定到测试、lint、格式化等固定命令项目记忆文件文件缺失或内容过时每次任务后检查是否需要更新像我前面说的权限模式一开始一定要保守。哪怕多花一点时间在配置上也好过跑完任务后去 git diff 里找它多改的那些行。4.5 单任务跑通之后再谈批量和自动化单任务跑通只说明流程没有断。真正麻烦的是批量任务、异常重试和长期维护。批量处理一批文件时你最需要考虑的不是“模型能不能一次性处理一百个文件”而是“如果中间某个文件处理失败整个流程会不会一起崩掉”。更稳妥的方式是先处理一个文件确认结果再处理三五个文件观察稳定性最后才考虑把整个目录都交给它。每往前一步都要有明确的日志输出和结果检查手段。注意不要一上来就把批量数和并发数拉满。先用一条样例确认输入、输出和日志都正常。5. 真正考验人的是报错和恢复一份可复用的排查链路5.1 先看现象不要只盯着最后一行我在社区里看到很多人遇到类似process exited with code 3的报错时第一反应是去搜报错码。但这条报错本身能提供的信息非常少。排查第一步不是搜报错码而是先复现现象。问自己几个问题是安装后第一次启动就报错还是运行到某个任务才报错是每次都会报错还是偶发是模型输出中断还是工具进程退出是只有当前项目目录报错还是任意目录都报错现象描述得越准确越不容易被表面报错带偏。5.2 按输入、环境、参数、工具边界的顺序逐层排查我自己的排查顺序通常是固定的从最底层的输入开始输入检查任务描述是否完整文件路径是否存在文件名是否有大小写或编码问题目录结构是否符合预期。环境检查Node.js 版本、npm 包版本、VS Code 扩展版本、当前目录是否有读写权限。参数检查模型标识是否正确权限模式是否过严或过宽工具白名单是否覆盖了任务所需命令。工具边界当前版本是否支持你用的功能是否在某些区域不可用是否有已知限制。这个顺序的关键在于先排除最简单、最确定的问题再进入不确定的部分。不要一上来就怀疑模型能力。5.3 两个常见报错的判断思路第一个是类似is not a model this version of claude code recognizes的报错。它一般不是网络问题也不是密钥问题而是你配置的模型标识和当前版本支持的模型名不一致。解决办法是把模型标识和当前版本支持列表对齐而不是反复重启或重装。第二个是process exited with code 3。这类错误更像是一个兜底报错常见原因包括入口文件缺失、依赖版本不一致、权限不足、某些区域限制。排查时不要只看最后一行要往前翻日志找到真正断掉的那一步。注意如果工具提示“可能在你所在地区不可用”第一件事是去确认官方支持范围遵守官方规则不要通过非正规途径绕过。5.4 日志和输出目录早期就要定下来很多人用这类工具都是跑一次就完不看日志不保留中间输出。单次任务还能忍但一旦你要把它接入工作流日志就变成刚需。建议从第一次使用开始就固定一个输出目录任务请求记录写一份。模型输出写一份。报错信息单独保留。最终改动文件通过 git diff 检查。这样做的目的不是增加负担而是让你在出问题时能够快速定位是哪一环出了问题。6. 适用边界上下文工程不是万能钥匙6.1 哪些项目适合先引入上下文工程我的判断是上下文工程最适用的不是那些复杂到极致的大型系统而是“规则多且重复”的中型项目。典型特征包括仓库结构清晰但新人需要花不少时间理解约定。开发过程中经常要重复交代项目背景。代码规范、目录约定、禁止操作这类信息长期稳定。团队或者个人会频繁切换不同项目每次切换都需要重新建立上下文。如果你符合这几个特征花一点时间维护项目记忆文件是很值得的。6.2 哪些项目现在不必折腾反过来有几类项目现在不必急着做上下文工程。一次性脚本写完就跑上下文再乱也不会长期影响。纯探索性需求你还不清楚要什么上下文工程会拖慢节奏。没有文档习惯的项目连项目自身都缺结构再好的记忆文件也救不回来。团队协作很松散、成员对项目规则没有共识的项目很难维护一份大家都认的规则文件。上下文工程解决的是“模型如何稳定理解项目”的问题不是“项目本身一片混沌”的问题。如果代码库没有基本结构任何记忆文件都只是在一堆乱麻上再缠一圈。6.3 团队引入时真正要补的是文档和审计如果只是个人使用维护一份 CLAUDE.md 就够了。但一旦要带进团队事情就变得不一样。团队场景下你需要的是一套“关于上下文的工程规范”项目记忆文件由谁来更新任务描述里哪些信息必须写工具权限由谁来审批模型的每一次改动如何做代码审查记忆文件变更时有没有历史记录这些不是模型能力问题而是工程管理问题。工具本身不会帮你建立规范它只会放大你已有的工作方式。6.4 我的一点长期判断回到文章开头那个说法。系统提示词被删掉 80%大概率不是终点而是上下文工程开始成熟的标志。删掉那 80%不是为了省 token而是重新分配了系统提示词、项目记忆文件和任务描述之间的权责。对我们普通开发者来说这套变化最实际的影响是从今天开始不要再去追求“写一份完美无缺的系统提示词”。更好的做法是把稳定规则分散到项目文件里把临时目标写进任务描述里让工具按需加载让上下文保持小步更新。先跑通一个最小任务再建立一条项目记忆规则最后再把权限和日志补上。这条路比一开始就背着一个庞大的上下文要稳得多。