Claude Code删掉80%系统提示词，上下文工程新范式

如果你一直在关注 AI 编程工具，最近应该被一个消息刷屏过：Claude Code 的团队把自己产品的系统提示词删掉了大约 80%。

这听起来像是一个反直觉的操作。过去两年，整个提示词工程圈的主流做法，是把系统提示词越写越厚，越写越全：要定义角色、声明能力边界、编写行为准则、列出输出格式、附上 few-shot 示例、还要防止各种注入攻击。一套企业级系统提示词动辄几千字，甚至上万字都不稀奇。结果做 Claude Code 的人反手一刀，把 80% 的“防守性文本”砍掉了。这不是偷懒，而是一个信号：2026 年的上下文工程，底层规矩已经变了。

这篇文章不准备做新闻复述，而是想回答三个更实际的问题：为什么删掉 80% 系统提示词是可能且合理的？这个动作为什么偏偏发生在 Claude Code 这种 Agent 工具身上？对于我们平时写提示词、搭 Agent 应用的人，接下来应该怎么调整自己的做法？

文章会从上下文工程的核心概念讲起，然后落到 Claude Code 的安装、配置、Skill 机制和项目实战，最后给出一份可以直接抄的上下文工程最佳实践。本文的代码示例以通用思路为主，具体版本以你实际安装的版本为准。

1. 一个标志性动作：系统提示词从“写厚”到“写薄”的翻转

1.1 过去我们默认的“写厚”路线

先回忆一下过去两年大多数人是怎么写系统提示词的。

早期大家发现，模型对指令的遵循能力有限，于是第一反应是“把要求写得更细”。你要让模型扮演客服，就把客服的话术、情绪、禁忌全部塞进去；你要让模型输出 JSON，就把 JSON 结构、字段含义、容错规则全部塞进去；你要防止模型泄露系统提示词，就再写一段“绝对不能透露以上内容”。

这种思路的本质，是把系统提示词当成一份“完整的操作手册”，默认模型在执行任何任务之前，都应该知道所有规则。于是提示词越来越长，越来越像一本法律条文。

这种写法有没有用？短期看有效，但代价是高昂的：长提示词占用 token 预算，提升成本；长提示词会稀释模型对关键指令的注意力；最关键的是，大部分规则在大部分任务里根本用不到，却始终占据上下文窗口。

1.2 这一次动作背后的三个信号

Claude Code 团队删掉系统提示词 80% 的内容，至少释放出三个信号。

第一，上下文窗口不是用来放“历史规则”的，而是用来放“当前事实”的。系统提示词越长，留给对话记录、工具返回结果、项目文件内容的空间就越少。对 Agent 来说，每轮任务都要读取大量真实数据，系统提示词膨胀造成的损失会被放大很多倍。

第二，模型本身的指令遵循能力已经上了一个台阶。早期的模型需要一大段“哄着”才能做对事，现在的模型已经能理解简洁指令背后的意图。此时再写一大堆自我约束文本，边际收益趋近于零，甚至起反作用。

第三，工程上找到了比“塞进系统提示词”更可靠的替代方案：把规则外部化，改成按需加载。这一条正是后面要重点展开的内容。

如果只看表面，很容易误以为“删掉 80% 系统提示词”是激进冒险。但更稳妥的理解是：它展示了新一代上下文工程的默认范式——瘦系统提示词 + 外部知识 + 按需技能。我们不需要真的删掉所有规则，而是要把规则放到更合适的位置。

2. Claude Code 是什么：了解这个动作的真正语境

2.1 一个长在终端里的 AI 编程 Agent

Claude Code 是 Anthropic 推出的命令行 AI 编程工具。你可以把它理解成一个常驻在终端里的“结对程序员”：你用自然语言描述需求，它读取项目文件、搜索代码、执行命令、修改代码、运行测试，然后告诉你发生了什么。

和 ChatGPT 网页版最大的区别是，Claude Code 拥有对本地环境的操作能力。它不是给你一段“建议运行以下命令”的代码，而是真的去执行。它也不再是“围绕单次问答”的设计，而是“围绕一个项目持续工作”的设计。

Claude Code 的技术组成可以拆成四层：

理解了这四层，你就会明白，系统提示词在 Claude Code 里的作用并不是“教会模型写代码”，而是“告诉模型如何组织和调动自己的工作台”。真正决定工作台上放什么东西的，是 CLAUDE.md、Skills、工具定义和每轮用户输入。

2.2 它和 Codex、Cursor 的差异

很多人在搜索时都会问“claude code 和 codex 的区别”。这里给一个简明的判断。

Cursor 是叠加在 IDE 上的 AI 编辑器，核心是“辅助人类逐行写代码”，交互方式偏图形化。Codex 和 Claude Code 则更接近“自主 Agent”，它们面向的是任务而非行号，更适合做批量重构、跨文件修改、跑测试、修 bug 这类工作。

Claude Code 和 Codex 的主要差异集中在三点：一是模型路线不同，Claude Code 默认使用 Claude 系列模型，Codex 默认使用 OpenAI 系列模型，二者对长上下文、工具调用的处理风格有明显差异；二是工具生态不同，Claude Code 早期的 MCP 支持和 Skills 机制做得比较早，Codex 后来也在补同样的能力；三是交互习惯不同，Claude Code 的权限审批、快捷键互动、CLI 输出风格，更适合熟悉终端的技术人员。

这里不评价谁更强，因为真实答案取决于你使用的模型版本、项目类型和个人习惯。但从社区讨论看，两派工具的差距正在缩小，真正拉开距离的是上下文工程和工具链整合能力。

2.3 为什么它对中文开发者这么重要

Claude Code 对中文开发者的意义在于，它把“让 AI 干活”这件事低成本地搬进了本地仓库。

过去，AI 编程能力的门槛是：你要把代码复制到网页对话框，再手动把 AI 给的结果粘贴回编辑器。有了 Claude Code，AI 可以直接读你的代码库、直接运行测试、直接提交修改，你只需要描述意图。这大幅降低了 AI 辅助开发的摩擦。

当然，Claude Code 的使用有一些现实约束：官方服务的可用地区、账号订阅策略、企业组织限制等都可能影响使用。许多搜索词也印证了这一点，比如区域的可用性提示、组织禁用提示、第三方模型接入等。这些内容会在第七节详细排查。

3. 上下文工程的核心概念：系统提示词、窗口与预算

3.1 三个术语，一次讲清

要理解“删掉 80% 系统提示词”为什么成立，先要把三个术语彻底分清。

系统提示词，是模型开始处理任务前注入的一段指令，用于设定角色、行为规则、输出约束。它每轮对话都会消耗上下文空间，且用户无法在对话里直接绕过。

上下文窗口，是模型单次能处理的文本总量，通常以 token 为单位。模型每处理一个字，窗口里就会被占用一份空间；窗口满了，最旧的内容就可能被截断或压缩。

上下文预算，是我认为真正值得关注的概念。它不是指窗口大小，而是指“窗口里这些位置到底被谁占了”。一个窗口内同时住着系统提示词、工具定义、对话历史、工具返回结果、用户输入，它们是竞争关系。

三者的关系可以这样理解：系统提示词是固定居住的“长期住户”，工具定义是“常驻职员”，对话历史和工具结果是“每日访客”。窗口就是办公室面积，预算就是每个住户实际占用的工位数量。如果长期住户占了太多工位，每天真正到访的重要访客就只能站在门外。

3.2 为什么系统提示词不是越长越好

很多人有一个直觉误区：系统提示词越长，模型越不容易犯错。实际上，当系统提示词超出一定长度后，模型反而会犯更多错误。

原因有几层。第一层是注意力稀释，模型在处理后续文本时，对开头长指令的关注度会下降，尤其是中间位置的内容最容易被忽略，这种现象在论文里有个形象的说法叫“丢在中间”。第二层是约束冲突，系统提示词越长，内部规则之间互相打架的概率越大，模型需要在矛盾指令之间做隐性权衡，结果往往不可预测。第三层是工具调用干扰，Agent 场景下系统提示词里大量关于“如何调用工具”的说明，可能和真实工具定义产生重叠甚至冲突，导致模型调用工具的格式变得混乱。

从工程经验看，系统提示词更合理的定位是“给出不可妥协的边界”，而不是“穷举所有情况”。边界之外的信息，交给外部文档和按需技能去补充。

3.3 一个重要的判断：上下文工程的核心是预算管理

所以我把 2026 年的上下文工程定义为：在有限的上下文预算里，让每一轮任务只加载最低必要的信息，并让信息加载过程尽量自动化。质量的关键不是“模型一次能看多少”，而是“模型需要时能不能准确找到该看的部分”。

这意味着，写提示词的功夫要从“怎么写得全”，转移到“怎么设计加载机制”。比如定义一个 CLAUDE.md 作为项目的“导航页”，只写关键词、索引和最重要的约定；把详细规范拆成独立文件，让模型在执行具体任务时再读取；用 Skills 把某个功能的完整流程封装成一个技能包，模型用到时按需解压。

Claude Code 团队删掉系统提示词的 80%，本质上就是把那些“长期住户”赶了出去，改成了“有事再叫”的临时工。这是预算管理思维在产品层面的体现。

4. “删掉 80%”是怎么做到的：瘦系统提示词 + 按需加载

4.1 信息不是消失了，而是换了个位置

要特别强调一点：删掉 80% 的系统提示词，不代表那 80% 的信息被丢弃了，而是换了一种组织方式。从各种公开讨论和项目结构看，这个动作背后至少有三类信息迁移。

一类是“项目级规则”迁到了 CLAUDE.md 这类项目记忆文件里。Claude Code 在工作时会把 CLAUDE.md 作为项目上下文读取，里面的内容可以动态补充，而不是像系统提示词那样固定写死在产品代码里。

一类是“任务级操作说明”迁到了 Skill 机制里。一套 Skill 通常包含一个 SKILL.md 作为导读，以及若干参考文件。模型只有在判断当前任务确实需要某个技能时，才会把对应文件读入上下文。没有相关任务时，它连文件名都不会看到。

还有一类是“工具能力定义”迁到了 MCP 工具服务里。工具返回的实际结果是结构化的数据，模型只在调用该工具时获取这些数据，而不是在每一轮对话开始前就把所有工具的说明书背一遍。

这三类迁移有一个共同点：把“全量常驻”改成了“按需加载”。从上下文预算的角度看，这是巨大的节省。想象一个大型仓库项目里既有前端规则、又有后端规范、还有部署流程，如果全部写进系统提示词，模型每轮都要白白消耗大量 token；而按需加载后，只有涉及部署的那一轮任务才需要读取部署文档。

4.2 Skill 机制：从“塞进提示词”到“任务时再读”

Skill 是 Claude Code 里一个很容易被低估的设计。很多人把它理解成“插件”或“预设 prompt”，其实它更像一个“任务触发式的知识包”。

一个 Skill 的典型结构大致是：

.skills/ └── review/ ├── SKILL.md └── checklist.md

SKILL.md 写清楚这个技能解决什么问题、适合在什么场景调用、大体如何执行。checklist.yml 等文件存放详细的操作清单。实际使用时，把技能包放进项目的 skills 目录，并让模型知道“存在这个技能”；当模型判断当前任务属于该技能的适用范围时，它才会读取完整内容。

这个机制的工程价值在于：模型不用再把几十条操作规范背在脑子里，它只需要知道“有这本书，遇到相关问题时翻到对应的章节”。这对长指令遵循能力的提升是决定性的。因为“知道有规则”和“把规则一字不差地放进上下文”是两种完全不同的成本。

4.3 指令层级的实际作用

还有一个不能忽略的概念：指令层级。现代模型在训练和微调阶段就已经对大模型内部行为有了一套优先级安排，通常情况下，系统级指令的优先级高于用户输入，用户输入高于工具返回内容。

瘦身后的系统提示词，反而能更有效地利用这个层级。因为它内容少、边界清晰，模型更容易把系统提示词当作“最高优先级约束”来遵守。反过来，如果系统提示词里写了 50 条要求，模型很难判断哪一条才是真正的底线。

所以在设计自己的 Agent 应用时，我的建议是：把系统提示词收敛成“宪法”，只写最高原则和不可触碰的红线；把具体流程放进外部文档；把可复用的操作封装成 Skill；剩下的一切，交给模型在运行时实时决策。

5. Claude Code 实战：安装、配置与基础用法

讲了这么多原理，现在进入可操作环节。这一节先完成 Claude Code 的安装和基础配置，演示如何把它接入你的项目。如果你的搜索关键词里有“claude code 安装”“vscode 配置 claude code”，这一节就是你要看的。

5.1 环境准备

Claude Code 官方主打的是命令行工具，依赖 Node.js 环境。建议按以下条件准备：

这里不写死具体版本号，因为工具迭代很快，安装时以官方文档要求为准。最小可用原则是：Node.js 环境没问题，npm 能执行，就能往下走。

5.2 安装 Claude Code

Claude Code 最常用的安装方式是 npm 全局安装。打开终端，执行：

npm install -g @anthropic-ai/claude-code

安装完成后，确认命令是否可用：

claude --version

如果终端提示找不到 claude 命令，通常说明 npm 全局 bin 目录没有加入 PATH。可以在终端里执行npm prefix -g查看全局目录，然后把对应的 bin 目录加入 PATH。这一步在不同操作系统上略有差异，但排查路径是一致的。

另一种常见安装方式是通过 VS Code 扩展。在 VS Code 扩展市场搜索“Claude Code”，安装官方扩展后，可以直接在编辑器侧边栏或通过终端面板打开 Claude Code 界面。这种方式对不习惯纯命令行操作的人更友好。

5.3 配置模型端点与第三方模型接入

Claude Code 默认使用 Anthropic 官方服务，需要你有官方账号或订阅权限。如果你使用的是企业环境或第三方兼容端点，可以通过环境变量来指定模型服务地址和认证信息。

以下是接入一个兼容 Anthropic 协议的模型端点的基础配置，用claude-code启动时生效：

export ANTHROPIC_BASE_URL="https://your-api-endpoint.example.com" export ANTHROPIC_AUTH_TOKEN="your-token" export ANTHROPIC_MODEL="deepseek-v4-pro" export ANTHROPIC_SMALL_FAST_MODEL="deepseek-v4-pro" claude

需要注意，这种接入方式属于社区实践，是否可用取决于你的模型服务商是否实现了 Anthropic 兼容接口。如果你在配置后看到类似"deepseek-v4-pro" is not a model this version of claude code recognizes的报错，第一步先检查ANTHROPIC_MODEL是否被当前版本识别，再看服务商的模型名称是否准确。

更稳妥的做法是：先使用官方支持的模型跑通全流程，再切换第三方端点。否则你很难分清问题是出在 Claude Code 安装，还是出在模型服务商。

5.4 基础交互与审批模式

启动 Claude Code 后，你可以直接输入自然语言任务，例如：

claude

然后输入：

请阅读这个项目的 README，并解释项目的整体架构。

Claude Code 会调用工具读取文件，然后给出解释。日常开发中你会高频接触它的审批机制：默认情况下，部分敏感操作会要求你确认。终端里经常出现1、2、3、Tab等快捷键提示，分别代表不同响应方式。实际使用中，建议先保持默认审批级别，等熟悉了工具行为再放宽，避免 Agent 在你不注意时执行危险命令。

6. 用上下文工程思维改造你的项目配置

现在进入本文最有价值的部分：如何把“瘦系统提示词 + 按需加载”的思路，落地到自己的项目里。这一节我们会写完三个文件，然后跑通一次完整验证。

6.1 最小示例：一个普通的 CLAUDE.md

先在项目根目录创建CLAUDE.md。这个文件是 Claude Code 对项目最重要的记忆入口。你要把它当成“项目导航页”，而不是规则大全。

# 项目：order-service ## 项目概览 - 技术栈：Java 17 + Spring Boot 3.x + MySQL - 目录结构：controller/service/repository/domain 四层 - 构建命令：mvn clean package ## 关键约定 - 所有对外接口返回统一 Result<T> 包装 - 错误码规则：A 开头表示参数错误，B 开头表示业务错误 - 禁止在 controller 中写业务逻辑 ## 需要时才读取 - 数据库表结构：docs/database.md - 部署与发布流程：docs/deploy.md - 代码规范细则：docs/style-guide.md

注意看，CLAUDE.md 里没有把数据库表结构、部署流程全部粘贴进来，只写了“需要时读取哪个文件”。这就让模型在每一轮任务里都能快速掌握项目骨架，只有在真的涉及数据库或部署时，才会去加载对应文档。

这个写法，是“删掉 80% 系统提示词”思路在项目层面的翻版：常驻信息只保留导航和最重要的红线，其余进入按需加载。

6.2 瘦身后的系统提示词模板

如果你不是在使用 Claude Code，而是在自己开发 Agent 应用，也可以把系统提示词收敛成下面这种风格：

# 文件路径：prompts/system.md 你是本项目的数据分析 Agent。 不可违背的边界： 1. 不要臆造数据，所有数据必须来自工具返回结果。 2. 对不确定的判断，明确说明置信度低。 3. 回答必须使用中文，除非用户要求其他语言。 工作方式： - 当用户询问数据时，先调用 list_datasets 工具确认可用数据集，再调用 query_data 获取结果。 - 当工具返回空值时，输出“无数据”，不要编造原因。 - 当用户请求超出你的能力范围时，直接说明，不要尝试用无关工具蒙混。

这份系统提示词不到 200 字，但已经把边界、工作方式、异常处理都讲清楚了。剩下的行业术语、指标口径、报告模板，全部放进外部文档，由 Agent 在执行任务时按需读取。你会发现，瘦身后的系统提示词不仅更省 token，模型遵循度反而更高，因为已经没有多余内容来分散注意力。

6.3 Skills 目录示例

在 Claude Code 项目里，下一步是建立 skills 目录。以“代码审查”技能为例，创建如下目录结构：

.skills/ └── code-review/ ├── SKILL.md └── reference.md

SKILL.md 内容如下：

# 技能：代码审查 ## 适用场景 - 用户要求对某个文件或某次提交进行代码审查 - 代码合并前需要自动化检查 ## 执行流程 1. 确认审查范围：git diff 或指定文件路径 2. 阅读变更代码，重点检查： - 是否有越权或未授权行为 - 异常处理是否完整 - 是否引入性能隐患 3. 输出审查意见，按严重程度分为 blocker / major / minor ## 注意事项 - 如果变更涉及数据库，必须先阅读 docs/database.md - 不要给出空泛的建议，每条意见必须对应具体代码位置

然后创建reference.md，存放详细的审查检查清单。当用户说“帮我 review 一下这个提交”时，Claude Code 会先读取 SKILL.md，确认执行流程；如果变更涉及数据库，还会按 SKILL.md 的要求去读 docs/database.md。

这种“技能包”结构，让项目里的知识不再是散落的系统提示词，而是变成了一块块可以按需调用的模块。新成员接手项目时，不需要把几十页规范全部背诵，只需要知道“这些技能存在，用的时候会加载”。

6.4 运行验证

完成上述文件创建后，启动验证：

claude

输入：

请审查当前工作区最近一次提交的代码。

观察 Claude Code 的行为：它应该先读取 CLAUDE.md 了解项目结构，然后调用 git 工具查看提交，接着判断需要加载 code-review 技能，并输出结构化审查意见。

如何判断运行成功？有三个标准。第一，模型在回答前确实调用了工具，而不是凭记忆编造代码；第二，模型读取了对应 Skill，且没有把 reference.md 的全文一股脑输出；第三，最终意见能落到具体代码位置，而不是泛泛而谈。

如果模型没有触发 Skill，优先检查.skills目录路径是否正确，以及 SKILL.md 里的“适用场景”描述是否清晰。模型无法触发技能，大多是因为它不知道这个技能的存在，或者描述里缺少明确的触发信号。

7. 常见问题与排查思路

Claude Code 使用过程中，社区里出现频率最高的问题集中在安装、认证、模型识别和进程异常。下面给出一份可直接对照的排查表。

排查时有一个通用原则：先看日志，再改配置。不要一上来就怀疑模型能力。Claude Code 在报错时通常会给出错误代码和上下文信息，先确认报错发生在启动阶段、认证阶段还是运行阶段，对应排查效率会高很多。

8. 最佳实践与工程建议

8.1 系统提示词瘦身原则

现在可以把“删掉 80% 系统提示词”的思路提炼成一套可操作原则。

第一，保留红线，删掉流程。系统提示词只写不可违背的边界，比如禁止编造数据、禁止越权操作、必须返回特定格式。具体流程放到外部文档，让模型按需读取。

第二，保留索引，删掉正文。如果你要在系统提示词里提外部规范，就只写一行“遇到 XX 场景时读取 docs/xx.md”，而不是把文档正文复制进来。

第三，保留判断信号，删掉穷举。不要试图把模型可能遇到的所有情况都写进去，而是教模型“什么时候该停下来查文档”。这比穷举规则更可靠。

第四，定期审计上下文预算。每一个固定写进系统提示词的词都要问一句：它是否在每一轮任务中都真正必要？答案是否定的，就干掉它。

8.2 上下文预算管理

在真实项目中，上下文预算管理应该像性能优化一样纳入日常巡检。

第一层是常量审计：查看你的系统提示词、工具定义、全局记忆文件占了多少 token。如果超过上下文窗口的三分之一，基本可以判断设计过重了。

第二层是动态行为观察：观察模型在工作中是否频繁读取同一份大文件。如果每次都读，说明这个信息应该升级为常驻；如果读了一次就永远存在于上下文中，说明工具返回的内容可能过载，需要裁剪。

第三层是输出控制：工具结果的返回字段也应该精简。一个查询接口如果返回 100 个字段，但任务只需要 5 个，就在工具调用参数里限制返回字段。少加载，就是少消耗。

8.3 安全与权限边界

当 Agent 拥有执行命令和修改文件的能力时，安全边界必须前移。

最小权限是第一条原则。Claude Code 的审批机制，本质就是为了给 Agent 的执行能力装上闸门。建议在非交互式场景里默认禁止执行危险命令，把需要人工确认的操作列一个白名单。

第二条是审计。所有 Agent 执行的关键操作都应该留下可检索的日志，包括调用了什么工具、读取了什么文件、执行了什么命令。一旦出现问题，能顺着日志回溯。

第三条是避免把敏感信息写进常驻上下文。API Key、数据库密码、内部系统地址，永远不要放进 CLAUDE.md 或系统提示词。正确做法是通过环境变量注入，或者使用密钥管理服务，让模型在需要时通过安全接口获取。

8.4 团队协作

上下文工程在团队里落地，需要的不是一两个人写提示词，而是建立一套可持续维护的约定。

建议把 CLAUDE.md 当成项目代码的一部分来管理。它应该进 Git，应该有版本记录，应该由所有主要维护者共同 review。不要把 CLAUDE.md 当成个人笔记，否则换个人接手项目时，整个上下文资产就归零了。

Skills 目录也一样。新技能先小范围试用，确认确实能稳定触发、稳定产出后，再合入主干。技能包的“适用场景”写清楚，不然模型要么不触发，要么误触发。

另外要统一模型版本意识。同一个项目，不同模型版本对同样提示词的表现可能差别很大。团队里应该明确一个基线版本，写上下文工程的人以这个版本为准去做调优，避免“在我机器上能触发，在他机器上不行”的混乱。

9. 总结：2026年，上下文工程的规矩确实变了

回到开头的问题：造 Claude Code 的人为什么敢删掉 80% 的系统提示词？

因为这个动作的本质，是上下文工程的重心从“让模型知道所有规则”变成了“让模型知道去哪里找到规则”。删掉的不是能力，而是无效的常驻占用；补进来的不是更长的提示词，而是更聪明的按需加载机制。

对我们普通开发者的直接启发是：写提示词的手感要换了。不要再把系统提示词当成一本越写越厚的百科全书，而是把它当成一份边界清晰的地图。具体知识放到外部文档，可复用流程封装成 Skill，常驻上下文只保留导航和红线。这样模型更省钱、更可控，也更容易维护。

如果你正在用 Claude Code，下一步建议做两件事。第一，把你项目的 CLAUDE.md 拿出来做一次“瘦身”，删掉所有不是每条任务都需要的细节。第二，试着把最常用的一个工作流封装成 Skill，比如代码审查、数据库变更分析或接口文档生成，然后观察模型的触发率和任务完成质量。做完这两步，你对上下文工程的理解会明显上一个台阶。

2026 年，AI 工具的上下文规矩已经变了。那些还在用“堆提示词”解决问题的团队，会很快发现成本越来越高、效果越来越难调；而转向“瘦身 + 按需加载”的团队，正在用更少的 token 拿到更好的结果。选择权在你手里。