随着模型能力跃升，Claude Code 删除80%系统提示词，GPT-6 Astra 对指令更敏感，Prompt 与 Skill 的旧规则正从帮助变为负担。本文结合实测数据与专家观点，拆解哪些指令该留、哪些该删，教你为 AI 工作流科学瘦身。

2026 年，Claude Code 的创造者 Boris Cherny 在 Y Combinator 的一次公开对谈里提到：为了适配新一代模型 Opus 5，他们删掉了 Claude Code 超过 80% 的系统提示词。

这80% 主要来自旧模型的能力补丁。很多提示词原本用于纠正模型不会做或做不好的动作。模型升级后，它已经能自然完成这些动作，原来的纠正规则却还留在系统里。团队做消融测试时甚至发现，去掉这些提示后，模型有时会显得更聪明一些。

剩下的提示词仍然重要。它们主要负责安全、权限、静态检查和产品交互等明确约束。变化发生在分工上：过去需要人一步步教模型如何做，现在更需要人说清楚做什么、为什么做、哪些边界不能越过，以及做到什么程度才算完成。

这也带来了一个值得重新讨论的问题：当模型能力持续增强，我们过去写进Prompt、Skill 和 AGENTS.md 的内容，会不会已经从“帮助”变成了“负担”？

图1：Boris Cherny 介绍 Claude Code 在适配 Opus 5 时删除了 80% 的系统提示词

一、我们为什么曾经需要那么长的Prompt？

早期的大模型经常需要非常具体的引导。一个看起来专业的Prompt，通常包含角色设定、任务背景、执行步骤、输出格式、禁止事项和参考示例。有时还会加入“请认真思考”“先分析再回答”“检查三遍”等提醒。

这些内容可以分成两层。

第一层是任务定义。比如写给谁看、解决什么问题、有哪些可用材料、结果要以什么格式交付。这些信息来自用户和真实业务，模型无法凭空获得。

第二层是能力补丁。比如要求模型先列计划、必须按固定顺序执行、每一步都要自检、遇到某种情况必须套用某个模板。这些规则往往来自过去的失败经验：模型容易漏步骤，我们就把步骤写得更细；模型容易跑偏，我们就增加边界；模型输出不稳定，我们就放入更多示例。

当同一批补丁需要反复使用，Skill 就变得合理。稳定的规则、专业资料、模板和脚本可以被打包起来，不必每次都塞进对话。Anthropic 对 Agent Skills 的设计也强调“渐进式加载”：模型先看到 Skill 的名称和说明，确认任务相关后再读取完整指令，需要时才继续调用附加资料或脚本。

图2：Agent Skills 将元数据、完整指令和附加文件分层加载

Skill 由此把一段反复使用的 Prompt 变成了可复用的工作包：模型临时缺少的知识、流程和确定性工具，可以在合适的时机交给它。

问题在于，这些内容通常只增不减。一次失败增加一条规则，一次事故增加一个禁止项，一次效果波动再增加几个示例。时间久了，我们很难分辨哪些内容仍是业务要求，哪些只是旧模型留下的补丁。

二、模型越听话，旧规则的代价越高

旧规则不会一直安静地待在上下文里。模型会读取它们、解释它们，并尝试把它们落实为行动。

OpenAI 在 GPT-6 Astra 的官方使用指南中专门提醒：新模型能够遵循更长、更复杂的指令，同时也会对 Skill、AGENTS.md 等可访问的指令文件更加敏感。含糊或相互冲突的规则，可能让模型过早停下来确认；过宽的测试要求，也可能让一个小修改触发远超必要范围的检查。

图3：GPT-6 Astra 能够遵循更长的指令，也会对上下文中的冲突规则更加敏感

这是一种很容易忽视的变化。模型能力较弱时，一条多余规则可能只是一段没有发挥作用的文字。模型执行能力增强后，它更可能认真完成这条规则，于是多读文件、多做测试、多走流程，甚至因为两个边界互相冲突而停止推进。

ETH Zurich 与 LogicStar.ai 的研究者专门评估了 AGENTS.md 的实际效果。他们在 300 个 SWE-bench Lite 任务和 138 个 CTXbench 任务上测试多种编码 Agent。结果显示，自动生成的仓库级上下文文件没有带来显著的成功率提升，却让两组实验的成本分别增加约 20% 和 23%。开发者亲自编写的文件带来约 2.4% 的平均提升，但统计上同样不显著，同时也增加了成本。

图4：上下文文件对四种编码模型任务成功率的影响。左图比较无文件与自动生成文件，右图加入开发者编写的文件

这个实验只覆盖特定的Python 仓库、编码 Agent 和评测任务，不能推导出“上下文文件都没有价值”。它揭示了一个更实际的机制：Agent 的确会遵守文件里的要求，而额外的探索、测试和执行步骤都需要付出成本。实验结果与文件长度没有明显关系，成本增加更可能来自每条指令所触发的行为。

图5：加入上下文文件后，各编码 Agent 的平均执行步骤和推理成本变化

Eric Provencher 在 OpenAI 负责 Codex 开发者体验。他在讨论 Astra 的 Prompt 与 Skill 设计时也给出了相似建议：Skill 的入口应当尽量像一个简洁的路由器，把详细资料留到真正需要时再加载；为旧模型写下的固定路线和繁复配方，则应该重新检查。模型已经能够处理的判断，继续被步骤锁死，反而会压缩它寻找更短路径的空间。

由此看，长度只是表象。需要减少的是失效、重复、冲突，以及会诱发无效行动的指令。十行准确的业务背景可能比一句话更有价值；一句“每次都运行全部测试”，也可能比十页参考资料更昂贵。

三、给Prompt 和 Skill 瘦身，应该留下什么？

判断一条指令是否值得保留，可以看它属于下面哪一类。

1. 模型自己无从知道的信息

包括组织内部事实、项目历史、用户偏好、数据口径、已有资产和当前环境。模型能力再强，也无法猜出团队内部的命名规范，无法知道这次修改背后的历史原因，更无法自动获得尚未提供的材料。

这部分内容要写得具体，并根据任务按需加载。稳定且通用的信息可以进入Skill；只与当前任务相关的背景留在当次 Prompt；体量较大的资料则通过索引和渐进式加载提供。

2. 必须由人做出的选择

包括目标、受众、优先级、取舍、验收标准和停止条件。模型可以分析方案，却无法替用户决定速度和质量谁更重要，也无法自行判断一次产品修改可以承受多大风险。

与其规定“先做第一步，再做第二步，最后做第三步”，更有效的写法通常是：交代目标，给出可用资源，明确不可越过的边界，再说明什么结果可以被接受。路径可以交给模型根据现场情况选择。

3. 不应允许模型临场发挥的部分

安全、权限、合规、不可逆操作、固定数据格式和关键验证规则，都值得明确保留。只要一次偏差可能造成真实损失，就不能把结果完全交给概率判断。

其中能够用代码确定完成的工作，最好交给脚本、校验器和权限系统。例如检查JSON 结构、验证字段、运行固定测试、阻止高风险命令。自然语言负责表达意图，确定性工具负责守住硬边界，两者的职责越清楚，系统越稳定。

与这三类内容相比，最值得优先清理的通常是泛泛的角色设定、情绪化鼓励、僵硬的固定步骤、重复表达的禁止项、为旧模型准备的大量示例，以及“每次都读完所有资料”“无论改动大小都跑全部测试”之类的全局要求。

有效的瘦身从最小版本和真实验证开始。先用一组有代表性的任务测试，观察模型在哪些地方反复失败，再把必要信息逐条加回来。Boris 分享的 Claude Code 方法就是：每次适配新模型，先移除原有系统提示，再逐条恢复并观察每一条的实际影响。

Skill 也应该接受同样的周期性检查。模型升级后，删除旧规则，运行真实任务，记录重复出现的问题，只为稳定复现的缺口增加指令。某条规则如果长期没有改善结果，或者只会带来额外步骤，就应该被改写、下沉到按需资料，或者直接移除。

结语

随着模型能力增强，Prompt 和 Skill 的价值正在迁移：过去，我们花很多精力补足模型“不会做”的部分；以后，更重要的是补充模型“无从知道”的背景，明确“必须由人决定”的取舍，并守住“不能临场发挥”的边界。

模型越聪明，人越需要说清目标、背景和边界，也越需要克制自己规定每一个步骤的冲动。好的Prompt 不以长度取胜，好的 Skill 也不以规则数量取胜。它们最终要做的，是把人的意图和责任讲清楚，同时给模型留下足够的执行空间。