你写的 Skill，可能正在把模型变笨

——从 Claude Opus 5 删掉 80% 系统提示说起

前段时间，我写过一篇关于新一代大模型提示词的文章，核心观点是“少即是多” [1]。

但最近读完几份官方文档，又围观了开发者社区里几场激烈的争论，我发现“少即是多”这句话还不够狠。它很容易让人误解成：以后提示词越短越好，工作流最好全部删掉，让模型自己去猜。

真正的变化不是字数变少了，而是我们给模型塞信息的方式，已经彻底过时了。

想象一下，你花高薪请来一位顶级工程师。开工前，你先递给他三百行公司守则：这里写“适当添加注释”，几十行后又写“绝对不要添加注释”；一处要求他主动验证，另一处要求他不要擅自扩大工作范围；最后还附上十几个工具的完整使用教程。

他站在那里读了很久，做事也开始犹豫。你觉得他不够聪明，于是又补了两百行。

这大概就是不少团队今天还在用的 AI 工作流。

当旧地图遇上新天地

Claude Opus 5 发布后，有开发者分享了一个很有意思的“开荒”实测。他们把现有的复杂工作流和插件直接套到新模型上，结果模型开始和指令“吵架”，偶尔提前停下，怎么都不顺手。后来团队一怒之下删掉所有旧规则，从空白环境重新跑，表现反而明显改善 [2]。

紧接着，另一位资深开发者给出了一个非常尖锐的解释：每轮都让模型扫描大量技能（Skill）描述，就像要求一位天才每次回答问题前，都把整本书的目录重读一遍。他把这些堆砌的规则称为“自伤武器”，认为它们纯粹是在干扰模型的注意力 [3]。

这个比喻很毒舌，但真正把底牌亮出来的，是官方团队的下场。

Anthropic 的工程师发文证实，他们为最新的 Opus 5 和 Fable 5 模型，删掉了内部系统提示中超过 80% 的内容。结果呢？在内部编码评测中，没有观察到可测量的性能损失 [4] [5]。

“我们为 Claude Opus 5 和 Fable 5 删除了超过 80% 的系统提示词，在编码评估中没有观察到任何可测量的性能损失。”

——Anthropic 官方博客 [5]

注意，这不是在鼓励所有人“无脑删掉 80%”。它真正揭示的是一个残酷的事实：随着模型判断能力跃升，过去为了防止它犯蠢而写下的那些防御性规则、保姆级教程，现在已经变成了互相冲突的噪音，甚至在限制它找到更好的解法。

问题不是“提示词太长”，而是你的上下文里，塞了太多不该常驻的垃圾。

提示词的“重生”

强大的模型仍然需要提示词。但我们需要淘汰的，是那些没有业务意义的过程微管理。

过去常见的写法是这样的：

1
2
3
4
5
6

先完整阅读所有文件。
然后列出详细计划。
接着逐步分析每一种可能性。
必须调用子代理复查。
完成后再检查三遍，确认绝对没有遗漏。
最后输出答案。

这段话看起来很专业，实际上全是在替模型规定思考姿势。它既没有告诉模型真正的任务风险，也没有定义怎样才算干完活。

更适合现代模型的写法，应该是这样的：

1
2
3
4
5
6
7
8

修复结账流程中偶发的重复扣款。

背景：问题只在支付重试后出现，用户会看到两笔已完成交易。
范围：只修改 payments 模块；保持现有 API 和数据库结构不变。
完成标准：新增一个能稳定复现问题的测试；修复后该测试及现有支付测试全部通过。
权限：可以修改本地代码并运行非破坏性测试；不要发布、部署或修改线上配置。
交付：完成代码修改，并简要说明根因、改动文件和验证结果。
参考：payments/retry.ts、现有幂等性测试、支付服务接口定义。

第二段并不一定更短，但明显更“轻”。它把模型需要知道的事情说清楚了，同时把怎么干活的自由还给了模型。

我现在更愿意把提示词当成回答五个问题：

当然，这不意味着你每次都要像填表一样写满五段。一句话能说清的简单任务，就写一句话；复杂任务才需要逐层补齐。核心的判断标准只有一个：不要让模型去猜那些一旦猜错，就会彻底改变结果的事情。

信息的“五层汉堡”

很多臃肿的提示词，根源在于把不同层级的信息混在了一起。仓库约定被复制进每个任务，工具教程被塞进系统提示，模型行为补丁又混进业务规则。久而久之，一条规则有四个版本，谁也不知道哪一个才算数。

现代 Agent 系统的上下文，其实是一个“五层汉堡”：

现代的上下文工程（Context Engineering）要做的，就是把信息放回它该在的位置。

技能（Skill）的正确姿势

技能不是“更长的提示词”，也不是工具本身。它更像一张按需调阅的作业手册。

工具解决“能不能做”。例如文件工具可以读取代码，浏览器可以打开网页。技能解决的则是“什么时候该用、应该参考什么、做到什么程度才算合格”。

一个好的技能会先用很短的描述完成路由，让模型知道“什么情况下需要我”。它的正文保存那些无法直接从现场推断、但团队会反复使用的知识；更长的规范、示例和模板则放进引用文件，等任务真的需要时再展开。

所以，前文提到的那种“把技能当成干扰”的批评，其实是在提醒我们：把所有技能的详细内容每轮都常驻加载，才是反模式。 目录负责发现，正文按需加载，执行者只拿当前工作需要的材料，这才是正解。

真正有意思的玩法：管理代理与最小上下文

理解了技能的正确定位之后，一个真正有意义的架构模式就浮现了：拥有一个管理代理（它不执行实际的“工作”），它读取公司 Wiki 或技能目录（技能意识）来构建所需的最小上下文，以便它能够生成一个子代理来执行工作，并带有精心构建的上下文。

这个模式的关键在于两层分工。管理代理的职责不是写代码、不是改配置、不是跑测试——它只做一件事：搞清楚“这次任务需要哪些知识”。它会扫描技能目录，找到与当前任务相关的条目，按需加载对应的规范、示例和约束条件，然后把这些材料精简打包，连同明确的任务边界一起交给执行者。

执行者拿到的不是三百行的系统提示，而是一份干净、聚焦的委托书：做什么、为什么做、边界在哪、怎样算完成。至于怎么想、先做哪一步、用什么工具，执行者自己决定。

这和我们之前讨论的“让正确的信息，在正确的时机，以正确的粒度进入上下文”是一脉相承的。只不过在这个模式里，“谁来决定时机和粒度”这件事，也交给了模型自己。

拥抱变化，而不是拥抱混乱

这是开发团队最头疼的问题：Opus 5 出来了，Fable 5 也来了，我难道要为每个模型维护一套独立的工作流和技能库吗？

短期来看，我们可以采用 Profile 或 Adapter 做适配。

你们团队的代码审查口径、品牌语言、财务核算方法，并不会因为底层模型换了名字就改变。短期内最务实的做法是共享业务的知识核心，把模型行为差异放进很薄的配置文件（Profile）里。

1
2
3
4
5
6
7
8
9
10
11

skills/code-review/
├── SKILL.md                 # 共享：触发条件、目标、审查口径、交付物
├── references/
│   ├── severity-rubric.md   # 共享：严重度标准
│   └── repo-gotchas.md      # 共享：仓库特有问题
├── profiles/
│   ├── opus-5.md            # 适配：限制重复验证、控制委派深度
│   └── fable-5.md           # 适配：长运行进度汇报、异步协作策略
└── evals/
    ├── routine-fix.md
    └── long-run-review.md

比如，Opus 5 本身就会主动检查并修正自己的工作。官方建议移除遗留提示词中“必须调用子代理复查”之类的硬性要求，否则会叠加成过度验证；它也更容易主动生成子代理，所以小任务需要限制委派 [6]。

而 Fable 5 面对的常常是持续数小时的任务。在这类运行中，官方建议让进度声明对应真实的工具证据，并在长周期提示词中显式安排定期自验证 [7]。

两者的“代码审查”业务规则仍然是同一份。不同的只是验证如何编排、要不要生成代理、运行多久汇报一次。这些属于模型的执行偏好，而不是业务核心。

但长期的话，我们需要一套更动态的组织方式。

为不同模型准备不同的 Skill 和上下文空间——类似于我们上面谈到的那个模式：管理代理读取技能目录，按需构建最小上下文，再生成带有精心上下文的子代理去执行。不同模型有不同的能力边界和行为偏好，那么它所需要的上下文空间本身就不一样。与其用一层薄薄的 Profile 去修补一个共享的上下文，不如让系统根据当前使用的模型，动态地为它准备一套“刚好够用”的知识和技能组合。

这意味着我们的技能库和组织结构，最终会走向一种模型感知的动态装配。业务核心仍然是共享的，但进入模型视野的内容，会因模型而异。

这里还有一个很好的提醒。前面提到的那位开发者发现，新模型在较低的思考投入（effort）下体验反而更好 [2]；但官方指南同时建议，复杂任务可以从最高 effort 开始测 [6]。两者并不矛盾，它们说明了一件更重要的事：不要把别人的模型体验，直接写成自己的永久规则。

结语

现代 AI 并没有让提示词变得不重要。恰恰相反，它要求我们写得更诚实：说清楚自己要什么，为什么要，边界在哪里，什么证据能够证明任务已经完成。

至于模型怎么思考、先读哪个文件、需不需要列一份十步计划，如果这不是业务流程本身，就给它一点判断空间。

与其说现代提示词的原则是“少写”，不如说是：

让正确的信息，在正确的时机，以正确的粒度进入上下文。

这句话听起来不像什么神奇的“念咒”技巧。

但也许这正是重点。我们终于可以少研究一点怎么和 AI 斗智斗勇，多花一点时间，把工作本身想清楚。

参考资料

[1] iDEVLab. (2026). 当提示词遇上 GPT-5.6：少即是多. https://blogs.idevlab.dev/gallery/gpt5-6-prompt-optimizer/

[2] Dan Shipper. (2026). Breaking: Claude Opus 5 is OUT NOW! X. https://x.com/danshipper/status/2080700057892815114

[3] @quanta. (2026). 关于 Skill 与上下文工程的讨论. X. https://x.com/_quanta_/status/2080704229875065080

[4] @trq212. (2026). Claude Code 工程师关于系统提示精简的分享. X. https://x.com/trq212/status/2080710971228918066

[5] Anthropic. (2026). The new rules of context engineering for Claude 5 generation models. Claude Blog. https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models

[6] Anthropic. (2026). Prompting Claude Opus 5. Claude Platform Docs. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5

[7] Anthropic. (2026). Prompting Claude Fable 5. Claude Platform Docs. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5