如果你一直在关注 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 编程 AgentClaude Code 是 Anthropic 推出的命令行 AI 编程工具。你可以把它理解成一个常驻在终端里的“结对程序员”你用自然语言描述需求它读取项目文件、搜索代码、执行命令、修改代码、运行测试然后告诉你发生了什么。和 ChatGPT 网页版最大的区别是Claude Code 拥有对本地环境的操作能力。它不是给你一段“建议运行以下命令”的代码而是真的去执行。它也不再是“围绕单次问答”的设计而是“围绕一个项目持续工作”的设计。Claude Code 的技术组成可以拆成四层组成作用类比模型层负责理解与生成代码大脑工具层读写文件、执行命令、调用 MCP 服务手脚上下文层决定模型每轮能看到哪些信息工作台交互层CLI、VS 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 CodeAI 可以直接读你的代码库、直接运行测试、直接提交修改你只需要描述意图。这大幅降低了 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.mdSKILL.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 环境。建议按以下条件准备项目建议操作系统Linux / macOS / WindowsWindows 建议使用 PowerShell 或 WSLNode.js建议 LTS 版本可以通过node -v确认npm随 Node.js 一起安装通过npm -v确认IDEVS Code 可选用于安装官方扩展这里不写死具体版本号因为工具迭代很快安装时以官方文档要求为准。最小可用原则是Node.js 环境没问题npm 能执行就能往下走。5.2 安装 Claude CodeClaude 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_URLhttps://your-api-endpoint.example.com export ANTHROPIC_AUTH_TOKENyour-token export ANTHROPIC_MODELdeepseek-v4-pro export ANTHROPIC_SMALL_FAST_MODELdeepseek-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 ## 关键约定 - 所有对外接口返回统一 ResultT 包装 - 错误码规则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.mdSKILL.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: command not foundnpm 全局 bin 目录不在 PATH 中执行npm prefix -g查看目录将 bin 目录加入 PATH或重新配置 Node.js 环境进程启动后立刻退出报error: claude code process exited with code 3Node.js 版本过低或依赖安装不完整查看完整错误栈执行node -v确认版本升级 Node.js 到 LTS 版本重新执行 npm install报错xxx model is not a model this version of claude code recognizesANTHROPIC_MODEL 配置的模型名不被当前版本识别检查环境变量和模型服务商文档改用官方支持的模型名或升级 Claude Code 版本提示your organization has disabled claude subscription access for claude code组织订阅权限未开通 Claude Code 访问检查组织管理后台的 Claude Code 权限策略联系组织管理员开启访问或切换为个人订阅提示claude code might not be available in your country当前账号地区不在官方支持范围内查看官方支持地区列表以官方支持范围和合规方式为准不要使用绕过手段模型不读取 CLAUDE.md 中的规则文件位置不对或内容过载确认 CLAUDE.md 在项目根目录检查文件长度精简 CLAUDE.md把细节拆分到 docs 目录Skill 没有被触发适用场景描述不清晰或模型不知道技能存在检查 SKILL.md 描述确认目录命名在 CLAUDE.md 中补充技能索引明确触发条件排查时有一个通用原则先看日志再改配置。不要一上来就怀疑模型能力。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 拿到更好的结果。选择权在你手里。 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 编程 AgentClaude Code 是 Anthropic 推出的命令行 AI 编程工具。你可以把它理解成一个常驻在终端里的“结对程序员”你用自然语言描述需求它读取项目文件、搜索代码、执行命令、修改代码、运行测试然后告诉你发生了什么。和 ChatGPT 网页版最大的区别是Claude Code 拥有对本地环境的操作能力。它不是给你一段“建议运行以下命令”的代码而是真的去执行。它也不再是“围绕单次问答”的设计而是“围绕一个项目持续工作”的设计。Claude Code 的技术组成可以拆成四层组成作用类比模型层负责理解与生成代码大脑工具层读写文件、执行命令、调用 MCP 服务手脚上下文层决定模型每轮能看到哪些信息工作台交互层CLI、VS 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 CodeAI 可以直接读你的代码库、直接运行测试、直接提交修改你只需要描述意图。这大幅降低了 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.mdSKILL.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 环境。建议按以下条件准备项目建议操作系统Linux / macOS / WindowsWindows 建议使用 PowerShell 或 WSLNode.js建议 LTS 版本可以通过node -v确认npm随 Node.js 一起安装通过npm -v确认IDEVS Code 可选用于安装官方扩展这里不写死具体版本号因为工具迭代很快安装时以官方文档要求为准。最小可用原则是Node.js 环境没问题npm 能执行就能往下走。5.2 安装 Claude CodeClaude 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_URLhttps://your-api-endpoint.example.com export ANTHROPIC_AUTH_TOKENyour-token export ANTHROPIC_MODELdeepseek-v4-pro export ANTHROPIC_SMALL_FAST_MODELdeepseek-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 ## 关键约定 - 所有对外接口返回统一 ResultT 包装 - 错误码规则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.mdSKILL.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: command not foundnpm 全局 bin 目录不在 PATH 中执行npm prefix -g查看目录将 bin 目录加入 PATH或重新配置 Node.js 环境进程启动后立刻退出报error: claude code process exited with code 3Node.js 版本过低或依赖安装不完整查看完整错误栈执行node -v确认版本升级 Node.js 到 LTS 版本重新执行 npm install报错xxx model is not a model this version of claude code recognizesANTHROPIC_MODEL 配置的模型名不被当前版本识别检查环境变量和模型服务商文档改用官方支持的模型名或升级 Claude Code 版本提示your organization has disabled claude subscription access for claude code组织订阅权限未开通 Claude Code 访问检查组织管理后台的 Claude Code 权限策略联系组织管理员开启访问或切换为个人订阅提示claude code might not be available in your country当前账号地区不在官方支持范围内查看官方支持地区列表以官方支持范围和合规方式为准不要使用绕过手段模型不读取 CLAUDE.md 中的规则文件位置不对或内容过载确认 CLAUDE.md 在项目根目录检查文件长度精简 CLAUDE.md把细节拆分到 docs 目录Skill 没有被触发适用场景描述不清晰或模型不知道技能存在检查 SKILL.md 描述确认目录命名在 CLAUDE.md 中补充技能索引明确触发条件排查时有一个通用原则先看日志再改配置。不要一上来就怀疑模型能力。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 拿到更好的结果。选择权在你手里。