智能体上下文经济学：GPT-6 时代 AI 编程助手「省 Token、稳输出」的配置与工作流全解

本文由 辛梓煜@词元二号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

先说结论：新一代高推理能力模型（社区里常说的 GPT-6 Astra 一族）变"聪明"的同时，也变成了上下文的重度消耗者。真正决定你用起来舒不舒服的，不是模型本身，而是两件事——你给的推理档位，以及你塞给它的上下文质量。把档位按任务分级、把上下文从"压缩总结"换成"跨窗口笔记"、把 AGENTS.md 和 Skill 从"菜谱"改成"路由器"，我自己的实测里，同一批任务的实际 Token 开销能压到原来的一半上下，输出质量不降反升。 这套调整不需要你换工具，也不需要什么特殊网络条件，改的只是几份文本文件和你提问的习惯。

如果你只想要一个能马上抄走的清单，那就是下面六条：

• 档位分级：抽取、分类、短改写、小脚本这类活，一律用低档；常规编码和多步工具调用用中档；仓库级改动和复杂规划才上高档；架构级规划再往上。高档不是"更保险"，很多时候只是更慢、更耗。
• 上下文建档：开启跨窗口的笔记式上下文管理，别再依赖一次性压缩总结，细节丢得更少。
• 前缀稳定：把不常变的内容（角色、规则、项目约定）放在提示词最前面，把每次都变的内容放在最后，缓存才命中得上。
• 规则瘦身：AGENTS.md 只写"这个项目真实且长期有效的事实"，不写"怕模型犯傻所以叮嘱一句"。
• 技能分层：Skill 主文件做导航，详细流程拆成配套文档，用到才读。
• 少喂少吐：工具输出先过滤再看，别让几百行日志白占上下文。

想看完整拆解，往下翻。

写在前面：为什么一篇讲"配置"的文章值得你花二十分钟

我自己是这半年才把 AI 编程助手真正接进日常工作的。最开始的感觉和很多人一样：哇，这次是真的能干活了，一个需求丢进去，它自己建文件、自己跑测试、自己改回来。爽了大概两三天，然后我看到后台的额度曲线，人瞬间清醒。

不是它不好用，是我不会用。

同一个任务，我前后跑了两遍。第一遍用默认设置，把它当成一个"什么都能问"的万能助手，随手丢进去一整段文档、几份配置文件、半屏报错日志，然后等它慢慢想。第二遍我把任务拆开，档位调低，只给它真正相关的那几段，工具输出先过滤。结果是：第二遍不仅更快，给出的改动还更干净，因为它没有被一堆无关信息带着跑偏。

这中间隔的不是什么玄学，而是一个很朴素的事实：高推理能力模型的开销，主要不是花在"回答"上，而是花在"读"上。 你喂进去的每一个字，它都要过一遍注意力；你想得越久，它在每个中间步骤上停留的次数越多。写代码这件事本来就需要多轮工具调用、多轮自我验证，于是每一次"多轮"，都是乘数关系。

所以这篇文章不聊"哪个模型最强"这种问题，那没意义，每一代都会翻篇。我想聊的是更耐用的东西：当智能体越来越聪明，人应该怎么配合它，才能既拿到高质量结果，又不把上下文预算烧穿。 这里面有四块内容——档位、上下文、规则文件、技能文件——它们互相咬合，单独改哪一块效果都有限。

辛梓煜@词元二号站

下面我按"原理 → 配置 → 实操 → 自检"的顺序来写。你不需要装什么特别的东西，跟着改几个文件，跑两三个任务，就能感觉出差别。

一、先搞懂 Token 从哪来：一次请求的「三段式」开销结构

1.1 用大白话讲清楚 Token 是什么

Token 可以理解成"模型眼里的最小计数单位"，不是字，也不是词，而是介于两者之间的一个碎片。中文里大概一个汉字对应一到两个 Token，英文里一个常见词可能是一个 Token，长单词会被切成两三块。你跟模型说的每一句话、它回的每一句话、它调用的每一个工具返回的一大坨内容，最后都要被换算成 Token 计一遍数。

关键点在于：计数的对象不是你"感觉"发了多少，而是整段上下文里所有的 Token 都要被重新过一遍。 这就是为什么很多人会觉得"我只是多贴了一个文件，怎么涨这么猛"。

1.2 预填充与解码：开销到底花在哪两段上

模型处理一次请求，可以粗暴拆成两个阶段。这两个词听起来很专业，其实一句话就能说清：

• 预填充（prefill）：把你发过去的整段输入，从头到尾读一遍，建立起"理解状态"。这一步计算量大，而且是跟你的输入长度成正比的，你给两万字和给两千字，差的就是这一段的倍数。
• 解码（decode）：在已经理解的基础上，一个字一个字往外蹦。它每蹦一个 Token，都要把前面所有内容重新参照一遍，所以越长越吃力。

智能体干活的时候，这两个阶段会反复循环：它读一次你的需求（预填充）→ 输出一段思考（解码）→ 调一个工具（预填充）→ 看工具结果（预填充）→ 再输出（解码）……所以你会看到一个反直觉的现象——一个任务的消耗，往往不是被最后一次回答拉高的，而是被中间那些"看一眼再想一下"的小回合慢慢堆高的。

1.3 三段式开销表：你以为的和你实际付的

下面这张表是我自己对着用量统计一点点对出来的，左边是很多人下意识的认知，右边是实际发生的事。

1.4 一次典型请求长什么样

把上面的东西画成结构图，大概是这样：

┌──────────────────────────────────────┐
│ 1. 系统提示词 / 角色设定              │  ← 几乎不变，最该被缓存
├──────────────────────────────────────┤
│ 2. 工具定义（文件读写、命令执行等）    │  ← 偶尔变
├──────────────────────────────────────┤
│ 3. 项目规则（AGENTS.md 等）           │  ← 半稳定
├──────────────────────────────────────┤
│ 4. 历史对话 + 工具返回结果            │  ← 逐轮增长，最大的黑洞
├──────────────────────────────────────┤
│ 5. 你这一次的最新输入                 │  ← 每次都不同
└──────────────────────────────────────┘

规律很清楚：越靠上的部分越稳定、越值得复用；越靠下的部分越动态、越需要控制体量。 而很多人恰恰反过来——规则文件写得又长又啰嗦，项目上下文随手一贴，历史记录从不清理。这就等于每次都让模型从头读一遍百科全书，然后回答一个"这个函数为什么报错"的小问题。

1.5 一张流程图看清智能体一轮的成本是怎么复利的

flowchart TD
    A[你的任务描述] --> B[读取系统提示词与规则文件]
    B --> C[判断需要哪些工具与资料]
    C --> D[调用工具/读文件]
    D --> E[工具结果进入上下文]
    E --> F[继续思考或再调工具]
    F -->|未完成| D
    F -->|完成| G[输出结论与改动]
    style E fill:#ffe6cc
    style B fill:#dae8fc

被标出来的两块就是节流的主战场：规则文件的固定开销，以及工具结果的无控膨胀。把这两块管住，你已经拿到了一大半收益。

小结一句：Token 的消耗不取决于你"发了多少字"，取决于"循环了多少轮、每轮背了多重的包袱"。 后面三章讲的档位、上下文管理、规则瘦身，本质上都是在给这个循环减负。

二、推理强度档位：把「聪明」用在刀刃上

2.1 档位到底在调什么

现在的编程智能体基本都带一个"推理强度"（reasoning effort）滑杆，名字各家略有不同，但思路是一致的：同一个模型，在回答问题前愿意"想多久"。

• 低档（low）：快速判断，几乎不展开推理，适合不需要动脑的活儿。
• 中档（medium）：日常主力档，平衡速度和深度，很多工程师把它当默认值。
• 高档（high）：会认真拆解、中途自我检查，适合真正复杂的改动。
• 超高（xhigh / extra high）：为架构级、跨模块的规划准备，想得久也慢。
• 顶格（超高之上还有一档）：理论上的最强档，实际上我至今没敢在正经项目上全程用，收益递减太明显。

需要提醒一句：档位不是一个"保险丝"。很多人潜意识里觉得"档位高一点更稳"，于是所有任务都往高档堆。这在过去也许问题不大，但在高推理能力模型上，代价会成倍放大——因为它高档时是真的会想很久，而中间每一段思考都会留在上下文里，成为后续每一轮的负担。

2.2 一个反直觉的事实：低档的新模型，常常赢过高档的老模型

社区里流传过一张对照表，讨论热度很高。它的核心结论其实就两条：

1. 新一代模型开低档，在不少任务上已经超过上一代开高档。
2. 从高档再往上加一档，往往只换来百分之一到百分之三的准确率提升，消耗却几乎翻倍。

这两条如果成立，就意味着你的档位策略应该整体下移一格。上一代模型你可能习惯直接开高档，这一代从档位切换成中档开始试，大概率不会变差。

我得说清楚，这不是一个可以无脑套用的定律。它在"边界清晰、答案可验证"的任务上最成立——比如改一个报错、补一个测试、按规范重构一个函数。到了"需求本身还模糊、要你自己拿主意"的任务上，高档带来的规划质量确实能省掉后面几轮返工，反而是值得的。

2.3 我的档位分配表

下面这张表是我自己用了两周之后稳定下来的分配习惯，你可以直接拿去改。

有个很好用的小技巧：档位不必全程统一。 一个任务可以在"规划阶段"用高档，确定方案后切到中档去执行，最后校验阶段再临时上调一次。规划想清楚一次就够，执行阶段没必要每步都重新推演一遍。

2.4 用一段伪代码把决策固化下来

如果你经常在同一个工具里来回切，不妨把自己的判断写成一个决策片段，贴在备忘里或者做成自己的小技能文档：

输入：任务描述 T

if  T 只是抽取/格式化/单文件小改 and 结果很容易验证:
    档位 = 低

elif T 涉及多文件协作 or 需要多轮工具调用:
    档位 = 中

elif T 涉及跨模块重构 or 需要先出可行方案:
    档位 = 高

else:
    档位 = 超高（仅规划阶段）

执行中如果连续两轮没有实质进展:
    升一档，但升档前先把当前上下文里明显无关的内容清掉

执行中如果连续两轮都在原地打转、答案很浅:
    先怀疑上下文质量问题，再怀疑档位

最后那两行是我自己的经验教训。很多时候不是模型想得不够，是你给的东西让它没得想。升档之前先看看上下文里是不是塞了一堆用不上的东西，这一步经常能省掉一次升档。

2.5 关于档位的两个常见误区

误区一：开低档 = 质量差。 这个等式在旧模型上大致成立，在新模型上已经不太成立。低档的意义是"不做多余的推理"，不是"少干活"。真正影响质量的是上下文是否干净、需求是否说清楚。

误区二：一直挂着高档最省心。 恰恰相反，一直挂高档会让你对消耗失去感知，等发现额度见底的时候，你的习惯已经养成了。我的做法是默认中档，需要的时候手动往上调，调完记住手动往下调回来。听起来麻烦，但比事后肉疼强。

辛梓煜@词元二号站：档位管理的本质是"分级授权"——不是所有任务都配得上满功率思考，也不是所有任务都值得省。把档位和任务复杂度对齐，比调参本身重要。

三、上下文管理：从「压缩总结」到「跨窗口笔记」

3.1 传统做法的软肋：每次压缩都在丢细节

先说老办法。过去我们用聊天型工具配合编码助手，处理长任务的套路基本是"能塞多少塞多少，塞不下就压缩"。所谓压缩（compaction），就是当上下文快满的时候，让模型把前面发生的事总结成一小段，替换掉原始记录，腾出空间继续干。

这个办法在短任务上没问题，但长任务上有个致命软肋：总结是有损的。 每一次压缩，模型都会丢掉一部分"看起来不重要"的细节。问题是很多细节恰恰在后来才变得重要——比如某个方案为什么被否掉、某个函数的边界行为是什么、上一轮测试失败的具体原因是什么。

我踩过这个坑。当时是在调一个并发下偶发的报错，来回改了七八轮，中间触发了一次自动压缩。压缩之后智能体明显"变傻"了：它开始重复我两轮前已经否掉的思路，因为那条"为什么否掉"的记录被压没了。我又得把背景重新讲一遍，讲完它再重复一遍压缩。那一轮下来，我才意识到——压缩省下的是当前这一轮的空间，付出的是后面几轮返工的代价。

3.2 新机制：笔记 + 可检索的窗口

新一代模型配合编码助手，思路换了个方向。它不再把旧内容揉成一段总结，而是尽量保留一份跨窗口的"工作笔记"，同时让更早的消息和工具结果保持可检索。等你后面需要某个细节时，它可以回去把原文捞出来，而不是靠一段模糊的摘要回忆。

差别在哪？我做一个对照表：

3.3 怎么开：改一行配置

这类功能在编码助手里通常是实验开关，位置在用户级配置文件里。以配置目录下的 config.toml 为例，加一个开关段落即可：

# ~/.codex/config.toml

[features.context_management]
experimental_mode = true

保存之后新建一个任务再试（旧会话不一定生效）。如果你不确定路径，可以在助手界面里让它自己帮你定位并修改这个文件，把上面那段贴给它就行。

几点需要提前知道的事：

• 这类开关通常默认关闭，而且是实验功能，官方一般会在随后的版本里把它做成默认行为或者换掉写法。
• 有些版本对登录方式和账号类型有限制，具体以你当前版本的官方说明为准。
• 打开之后，旧版本里习惯用的"上下文窗口大小""自动压缩阈值"这类手动参数，优先级可能会变，建议不要再硬调，容易互相打架。

我的实测体感是：在长任务上，这一项的效果比调档位还明显，因为它是全局性的，管的是"包袱有多重"，不是"这一步想多久"。

3.4 开完之后的工作流变化

开了跨窗口笔记之后，我的用法有几个调整：

• 不再怕长会话。以前我会刻意把任务切成小段，开新会话重讲背景，现在可以在一个会话里把事情聊透。
• 主动给"锚点"。我习惯在关键节点手动写一句"到这一步的结论是 X，已排除 Y"，等于帮它把笔记写得更结实。
• 不再依赖自动压缩兜底。该清理的时候我会主动让它把已经落地的方案归档成一段短文，而不是等系统塞爆了才压。

流程上大概是这样：

sequenceDiagram
    participant U as 我
    participant A as 智能体
    participant N as 跨窗口笔记
    U->>A: 描述任务与约束
    A->>N: 记录目标、约束、已排除方案
    A->>U: 执行第一步并汇报
    U->>A: 确认或纠正
    A->>N: 更新笔记（含失败原因）
    Note over A,N: 上下文接近上限
    A->>N: 保留笔记，旧消息转为可检索
    A->>U: 继续后续步骤，必要时回查旧结果

注意那个 Note 的位置——上下文满了之后，动作不是"压缩掉一切"，而是"保住笔记，其余可查"。这就是它比传统压缩更耐用的地方。

3.5 一个容易忽略的配套习惯：主动归档

跨窗口笔记只是把包袱变轻，不是让你永远不清理。我的习惯是每完成一个里程碑就做一次归档，把阶段性成果写成一小段结论，明确告诉它"以下内容已确定，除非我明确说要改，否则不用再展开"。这句话看着朴素，实际能省掉大量重复推理，因为它等于给智能体划了一条"不必再想"的线。

辛梓煜@词元二号站的经验是：上下文管理最有效的动作不是技术手段，而是"什么时候该收口"这个判断。 工具能帮你保住细节，但只有你能告诉它哪些细节已经定型了。

四、让提示词前缀稳定：缓存友好的上下文布局

4.1 缓存这件事，为什么值得单独拿一章讲

前缀缓存（prompt caching）的原理，一句话就能说明白：模型读你输入的过程，可以把中间状态存下来；下次你再发一段内容，只要开头部分和之前一模一样，这段就不用重算。

为什么能省？因为前面说过，读入阶段的算力开销是跟长度成正比的，而且占整次请求的大头。如果能复用，等于把最贵的那一段白拿了。官方文档里通常写得很直白：想吃到缓存红利，就得把静态内容放前面、动态内容放后面。

这里有一个很多人不知道的细节：缓存是从开头逐块比对的。也就是说，只要开头有一点点不同，后面的全部作废。这解释了为什么有的团队发现"缓存几乎不命中"——他们在系统提示词里插了一句"今天是 2026 年 X 月 X 日"，或者把时间戳、随机 ID 塞在了最前面，结果每天都换一次前缀，缓存永远命中不上。

4.2 把提示词分区：一张布局表

这张表的用法很简单：每次你要写点东西进提示词的时候，先问一句"它多久会变一次"，然后扔到对应位置去。 极少变的扔前面，每次变的扔后面，不要把两者混在一起写。

4.3 一个反例，一个正例

反例长这样，很多人无意识就是这么写的：

今天是 2026-03-11 14:22，我是辛梓煜，现在时间是下午。
你是一个资深工程师。规则：先给结论，少用列表，禁用套话。
我们要改的文件是 src/api/user.ts。
提示词缓存要求前缀稳定。

问题出在哪儿？第一行就是动态内容，等于每次请求的开头都不一样，后面所有稳定内容全部白费。而且"缓存要求"这种说明，放在最前面反而会稀释角色设定。

正例把顺序倒过来：

【角色】
你是一个资深工程师，负责在既有代码库中做小步、可验证的改动。

【输出规范】
先给结论，短段落，少用列表，不用套话。

【项目约定】
技术栈：TypeScript + Node；提交信息遵循约定式提交。
说明：以上三块内容长期不变。

--- 以下为本次任务 ---

【背景】
目标文件：src/api/user.ts
问题：并发场景下偶发超时返回。
【要求】
只改这个文件，改完给出改动说明与验证方式。

上半部分几乎一字不动，可以长期复用；下半部分每次重写。这就是"稳定在前、动态在后"的落地写法。

4.4 几个让缓存更容易命中的小习惯

• 别在开头放时间戳、会话 ID、随机字符串。真要记时间，放到最后的任务描述里。
• 同一类任务用同一套开头。哪怕换个项目，前半段结构保持一致，命中率也会高不少。
• 措辞别频繁微调。把"请务必认真思考"改成"请仔细思考"这种改动，看着无所谓，实际上会让整段前缀失效。
• 工具描述尽量稳固。有些工具定义是自动生成的，顺序或措辞变了，缓存就跟着丢。这一块你能控制的不多，但知道原理之后，至少不会自己往里添乱。
• 长任务别频繁开新会话。会话一换，前缀全部重建，等于每次都从零预热一次。

4.5 怎么判断自己有没有吃到缓存的收益

多数平台在用量统计里会给一个"缓存命中"相关的指标。你可以用一个很土但有效的对照法：同一个任务，连续跑两遍，第二遍的输入侧开销应该明显低于第一遍。 如果两遍几乎一样，基本可以断定前缀不稳定，或者内容根本没被当成可缓存块。

自检三步：
1. 同一任务连跑两次 → 比对输入侧用量，应显著下降
2. 在提示词开头插一句会变的话 → 再跑 → 命中应大幅下降
    （这一步是故意制造失败，确认你真的在吃缓存）
3. 把变化内容移到末尾 → 再跑 → 命中应恢复

这三步做完，你对这套机制的直觉就有了。后面再看到别人说"缓存能省一大截"，你会知道那到底省在哪儿。

五、AGENTS.md 重写：把「给弱模型打的补丁」换成「给强模型的契约」

5.1 这份文件是什么，为什么现在成了焦点

AGENTS.md 是一份放在项目根目录的纯文本规则文件（Markdown 格式），用来告诉 AI 编程助手这个项目"怎么建、怎么测、怎么改"。它不是给人类看的 README，而是给机器看的操作说明。到 2026 年，它已经被三十多种工具原生支持，采用它的开源仓库超过六万个，格式本身也交给了公开的基金会维护——也就是说，这是一份跨工具通用的约定，不是某一家平台的私有格式。

它的价值很好理解：没有 AGENTS.md 的时候，智能体每进一个项目都要先"摸索"——看目录结构、猜构建方式、试测试命令，这些都是实打实的上下文消耗。有了它，这些信息一次性给到，探索阶段直接省掉。

但真正的麻烦出在另一头：过去一年，我们为了"管住"能力较弱的模型，往这些文件里塞了大量叮嘱。新一代模型读了这些叮嘱，反而被拖住了。

5.2 为什么旧规则会变成负担

高推理能力模型的性格有几个明显特点：更爱提问、更爱输出长列表、有时候会停在计划上不动、对规则文件本身格外敏感。最后一点最关键——如果它自己的判断和文件里的规定冲突，它更倾向于服从文件，而不是服从你当次说的话。极端情况下，它会因此卡在计划阶段，或者直接给出一个"严格遵守了规则但没解决问题"的结果。

于是逻辑就变成了：文件里每一条没必要的约束，都在给一个本来能自己拿主意的模型上枷锁。

我把常见的过时约束整理成六类，你可以拿这六条去照自己的项目：

5.3 抄一个我自己的精简模板

我现在项目根目录的 AGENTS.md 大概只有一屏半，结构是固定的七段。这个结构的好处是：每一条都是"可执行的判定条件"，不是"态度上的要求"。 判断标准也很好用——一条规则如果删掉之后你无法说出"会导致什么具体后果"，那它大概率就是多余的。

# AGENTS.md

## 一、完成定义（什么算做完）
- 交付物：可运行代码 + 一句话说明改了什么、怎么验证。
- 未通过项目现有测试时，不得声称完成。

## 二、自主边界（什么时候自己决定，什么时候问我）
- 常规缺口自行假设，并在结论里标注"此处为假设"。
- 只有会实质改变结果的缺失信息才提问。
- 提问的同时，先推进不依赖该答案的部分。

## 三、优先级（冲突时听谁的）
1. 我本次的显式指令
2. 本次对话中的补充说明
3. 本文件与相关技能文档的一般指导
冲突时，指出冲突所在文件与原文。

## 四、输出形态
- 先结论，短段落，少列表，不用客套话。
- 不确定的地方直接说不确定，不要编。

## 五、审批边界（哪些必须先问）
- 只读操作、可撤销的本地改动：直接做。
- 不可逆的外部动作：先给出可审阅的结果，再确认最后一步。

## 六、验证力度（验到什么程度）
- 验证力度与改动规模相称，必要检查通过即停。
- 不为微小改动额外补测试。

## 七、子任务并行
- 相互独立的子任务可以并行，最终由你整合与裁决。

有几处细节是我特意这么写的，值得说一下：

• "优先级"这一段放第三位，而且必须编号。这是整份文件里最重要的一段。多项研究都指向同一个现象：当规则之间互相矛盾又没有明确优先级时，智能体倾向于"默默继续干"而不是回来问你，任务成功率会明显下降，解决率甚至能从将近一半掉到三成上下。把优先级写成有序列表，问题基本消失。
• "完成定义"写在最前面。它需要知道的是"什么叫完成"，不是"你希望我努力"。写成"哪条命令全绿、哪个接口返回什么结构"，比写十句鼓励有用。
• 不用模糊措辞。"小心一点""尽量优雅""注意性能"这类话对智能体等于没写，它需要的是"改完必须跑 pnpm test 且全绿"这种能判定的条件。
• "审批边界"按可逆性分层。这是唯一能同时解决"打断太频繁"和"乱改一通"的写法：可撤销的本地改动直接做，不可逆的外部动作才停下来确认。
• 给"提问"配一条出口。它更爱提问不是缺点，但你得告诉它提问时别把整条流水线停住——"把不依赖答案的部分先推进"这一句，能省掉很多无谓的等待。

5.4 用一段指令做一次全面体检

如果你手上已经有一堆历史文件，别急着一条条手改。可以让智能体先"只审查、不动手"，输出一份报告，你确认之后再让它改。我用的提纲大概是这样：

请审查本项目内的规则文件与技能文档，本轮只输出报告，不修改任何文件。

对每条指令判断三件事：
1) 它描述的是这个项目真实长期有效的事实（技术栈、目录约定、安全边界），
   还是仅仅为了弥补旧模型能力不足而加的叮嘱？
2) 它是否是不必要的强制步骤，抹掉了按实际情况调整的空间？
3) 它是否要求了与当前任务无关的大范围阅读？

按下面格式输出：
【建议调整】类别 / 原文与位置 / 原本想解决什么问题 / 现在为什么多余 / 处理方向（删除、精简、拆分、改写）
【建议保留】原文与位置 / 保留理由（对应哪条真实约束）

最后给一行比例：建议调整与建议保留各占多少。
不要仅仅因为一条指令写得具体，就把它标成问题。

这套流程走一遍，一般能砍掉三成左右的条目。砍完之后最直观的感受是：它在同样任务上说的废话变少了，动的第一刀也更准了。

辛梓煜@词元二号站的体会是：AGENTS.md 的演化方向很清楚——从"防错清单"变成"项目契约"。前者假设模型不可靠，后者假设模型可靠但需要知道边界。你现在写下的每一条，都在向模型表达你相信它是哪一种。

六、Skill 的渐进式披露：把技能做成「路由器」而不是「菜谱」

6.1 技能是什么，它怎么被加载

技能（Skill）可以理解成"打包好的专项能力"：一个目录，里面有一个说明文件（通常叫 SKILL.md），再加上一些可选的脚本和参考资料。你写一次，以后每次遇到匹配的任务，助手就自动按这套流程干活。

它省上下文的关键机制叫渐进式披露（progressive disclosure），分两个阶段：

• 阶段一（启动时）：只加载每个技能的名称、一句描述和文件路径，组成一份初始清单。
• 阶段二（命中时）：只有当助手决定用某个技能了，才把那份完整的 SKILL.md 读进来。

这个设计非常聪明：意味着你可以放心往技能正文里写详细的检查清单、长表格、参考资料，因为在被用到之前，它几乎不占成本。 就像自助餐厅里每道菜前面只立一块小牌子，牌子上就"菜名 + 一句话"，你不可能站在那儿把后厨所有菜谱都读一遍；只有你决定夹这道菜，后厨才开始按那份详细做法操作。

flowchart LR
    A[启动] --> B[加载全部技能的名称+描述+路径]
    B --> C{任务是否匹配某技能?}
    C -->|否| D[直接执行任务, 不读正文]
    C -->|是| E[读取该技能完整 SKILL.md]
    E --> F[按技能流程执行]
    style B fill:#dae8fc
    style E fill:#ffe6cc

6.2 有一件事很多人不知道：那份初始清单也是有预算的

渐进式披露不等于免费。官方给初始清单设了字符预算，大概相当于上下文窗口的百分之二上下（窗口未知时按几千字符算）。如果你装的技能太多、描述又写得又长又啰嗦，系统会做两件事：

1. 先压缩描述文字；
2. 压完还不够，部分技能会被从初始清单里省略，只给一条警告。

第一件事的直接后果是：你写在描述末尾的触发关键词，可能在某次启动时被削掉了，于是这个技能再也匹配不上了。 所以规则只有一条——把最核心的用途和触发关键词放在描述的最前面。 这一条和"AGENTS.md 里最重要的规矩别埋在第 140 行"是同一个道理，重要信息要前置。

6.3 菜谱式 vs 路由式：一次结构性升级

真正需要在 2026 年重写的，是技能正文的组织方式。过去我们习惯把技能写成"详尽的操作脚本"：第一步做什么、第二步做什么、每一步都有明确指令。这种写法是为能力较弱的模型准备的，因为那时不写清楚它就会乱来。

问题是，新模型在理解细微差别和处理模糊情况上已经好得多。过度具体的指引现在反而会约束它，让结果变得僵化、不完整。 我把两种写法做个对照：