最近有一个说法在开发者社区里传得比较广：造 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，而是重新分配了系统提示词、项目记忆文件和任务描述之间的权责。
对我们普通开发者来说，这套变化最实际的影响是：从今天开始，不要再去追求“写一份完美无缺的系统提示词”。更好的做法是把稳定规则分散到项目文件里，把临时目标写进任务描述里，让工具按需加载，让上下文保持小步更新。
先跑通一个最小任务，再建立一条项目记忆规则，最后再把权限和日志补上。这条路比一开始就背着一个庞大的上下文要稳得多。
