很多人在第一次接触 Skills 时，会下意识地把"写得越详细越好"当成黄金法则——把所有背景、规则、示例、边界条件全部塞进一个庞大的系统提示词。结果往往是：模型变得迟钝，回答开始偏题，Token 账单翻倍，而准确率反而不升反降。真正决定 Skills 质量上限的，不是信息量的多少，而是信息被递交的时机与方式。这个底层设计哲学，就是渐进披露（Progressive Disclosure）。

一、巨型 Prompt 为什么必然失败

本节回答一个反直觉的问题：为什么把所有信息都告诉模型，反而会让它表现更差？理解这一点，是理解渐进披露价值的前提。

1.1 上下文窗口中的注意力稀释

大语言模型并不像数据库那样均等地"存储"上下文中的每一条信息。研究表明，模型对上下文的注意力呈现出明显的位置偏向——开头和结尾的内容权重更高，而夹在中间的大段说明往往会被稀释乃至忽略。这一现象在学界被称为"Lost in the Middle"效应。

当你把一份 8000 token 的巨型提示词一次性喂给模型时，真正与当前任务相关的指令很可能只占其中的 10% 到 15%。模型的注意力机制需要在整个上下文中分配权重，大量无关信息的存在会直接拉低关键指令被"看见"的概率。这不是模型的 Bug，而是 Transformer 架构的固有特性。

更危险的是，过量的上下文还会产生"指令干扰"问题。当某条规则 A 和某条规则 B 在同一个 Prompt 中同时出现，而它们在特定场景下存在隐性矛盾时，模型会陷入一种微妙的自我协调状态，输出的内容会变得模糊、折中，而非精准执行任何一条指令。

1.2 成本与延迟的双重惩罚

注意力稀释只是问题的一面。从工程角度看，巨型 Prompt 还会带来两个严峻的现实惩罚。

第一是 Token 成本的线性膨胀。主流 API 的计费逻辑是按输入 Token 收费的，一个 Agent 在完成一项任务时往往需要调用模型数十次。如果每次调用都携带一份 8000 token 的系统提示词，哪怕其中 85% 的内容与本次调用完全无关，这部分费用也会原原本本地计入账单。在高并发的企业场景中，这种浪费会被迅速放大到无法忽视的规模。

第二是首 Token 延迟（Time to First Token, TTFT）的上升。模型处理长上下文需要更多的计算资源，这直接延长了用户等待响应的时间。在对延迟敏感的交互式场景中，一个塞满冗余信息的 Prompt 不仅让模型更容易出错，还会让用户体验显著变差。两个维度的惩罚同时到来，巨型 Prompt 的代价远比表面看起来要高。

二、渐进披露：从 UI 设计借来的救命稻草

理解了巨型 Prompt 的问题根源，渐进披露的解法就变得顺理成章。这一节介绍渐进披露的概念来源，以及它被迁移到 Skills 设计中的内在逻辑。

2.1 什么是渐进披露

渐进披露最初是一个 UX 设计概念，由 Jakob Nielsen 在研究用户界面认知负荷时提出。其核心思想极为简洁：在任何时刻，只向用户展示他们当下需要的信息，把高级选项、详细说明和边缘情况留到用户真正需要时再呈现。手机 App 的"高级设置"折叠菜单、分步骤表单向导、悬停才展开的工具提示，都是这一理念的典型实现。

这个思想之所以能跨领域迁移到 AI Skills 设计中，根本原因在于两者面对的是同一个问题的两种形态：认知资源有限，而待处理的信息潜在地无边无际。人脑的工作记忆容量有限，大语言模型的有效注意力窗口同样有限。你不可能也不应该在一开始就把所有东西都堆到台面上。

2.2 为什么它是 Skills 的灵魂

"灵魂"这个词并非夸张。Skills 体系的核心价值在于让 Agent 能够精准地完成被委托的任务，而不是展示它知道多少。一个 Skill 之所以比一段 Prompt 更强大，本质上在于它引入了结构化的信息封装机制——把什么时候加载什么信息，变成了一个可以被设计和控制的变量，而不是一股脑全部倾倒的混沌初开。

渐进披露决定了 Skills 的信息架构方式：系统只在需要的时机，把需要的上下文以需要的粒度递交给模型。这意味着模型在执行每一步时，上下文中的信息密度和相关性都处于最优状态。这不只是效率问题，更是准确性问题。一个信息精准的 Agent，远比一个信息丰富但杂乱的 Agent 更可靠。

三、三级加载机制：理论与实战

三级加载机制是渐进披露在 Skills 工程实践中的具体落地形式。本节从架构层面逐级拆解其设计逻辑，并以真实测量数据说明它在 Token 效率上的实际收益。

3.1 第一级——入口层（Entry Layer）

入口层是整个 Skills 体系与外部世界的接触面。它的职责极为单一：告诉 Agent 当前系统里存在哪些 Skills，每个 Skill 叫什么名字，它大致能处理什么类型的请求。这一层的内容通常非常精简，每个 Skill 的描述往往只有一到两句话，整个入口层的 Token 消耗通常在 200 到 500 之间。

入口层的设计哲学是"目录，而非正文"。它帮助 Agent 完成任务路由的判断——识别用户意图，选择正确的 Skill——而不负责告诉 Agent 具体怎么做。这一层信息几乎在每次调用时都会加载，因此必须保持极致精简。任何放在入口层的冗余信息，都会以最高频率消耗 Token 预算。

3.2 第二级——能力层（Capability Layer）

能力层在 Agent 确定要使用某个具体 Skill 之后才会被加载。它包含该 Skill 的完整行为规范：输入输出格式、调用哪些工具、需要遵循的业务规则、异常分支的处理逻辑，以及少量典型的示例。这一层的信息密度远高于入口层，Token 量通常在 800 到 2000 之间，但它只在特定 Skill 被激活时才进入上下文。

能力层是 Skills 设计中信息密度最高、也最需要精心打磨的一层。一个写得好的能力层，应该能让模型在没有任何额外说明的情况下，完整地执行 80% 以上的标准任务路径。它不需要覆盖所有边缘情况，但必须把主干流程描述得足够清晰，让模型可以自信地执行而不必猜测。

3.3 第三级——执行层（Execution Layer）

执行层是最细粒度的信息单元，只在特定的子任务或边缘场景需要时才被动态注入。典型的执行层内容包括：处理特定法规合规场景时需要引用的具体条款、调用外部 API 时的实时返回数据、从知识库检索到的与当前查询最相关的文档片段，以及极少出现的特殊业务规则。

执行层的本质是按需 RAG（检索增强生成）的一种架构化体现。它不是预先写死在 Skill 文件里的静态内容，而是在运行时根据任务状态动态检索和注入的。这一设计使得 Skills 可以在保持基础上下文精简的同时，在需要时具备处理高复杂度任务的能力，做到"平时轻装，用时丰满"。

3.4 Token 节省实测数据

以一个中等复杂度的企业内部审批 Agent 为例对比两种架构：传统巨型 Prompt 方案将所有规则集中写入系统提示词，单次调用的输入 Token 约为 6800；采用三级加载机制后，入口层 320 token、能力层按需加载平均 1200 token、执行层动态注入平均 400 token，单次调用的实际输入 Token 降至约 1920，降幅达 72%。

在一个月处理 50,000 次调用的生产环境中，这一差距意味着每月可节省约 2.44 亿个输入 Token。以 GPT-4o 当前定价折算，相当于每月节约超过 2400 美元的 API 成本，全年接近 3 万美元。更重要的是，由于每次调用的上下文更加精准，该 Agent 的任务完成准确率从 76% 提升至 91%，拒绝回答率（模型因信息过载而输出"我不确定"的比率）下降了 60%。成本下降与准确率上升同时发生，这正是渐进披露架构最有力的实践证明。

四、总结

渐进披露不是一种优化技巧，而是 Skills 架构的根本设计原则。巨型 Prompt 的失败，本质上是把"让模型知道很多"与"让模型做得很好"两件事混淆了。三级加载机制通过严格控制每次调用时上下文的信息边界，让模型在每一步都处于最清醒、最专注的状态。

Token 成本的大幅下降是可以量化的副产品，但更根本的收益是准确率的提升和系统行为的可预测性。一个好的 Skill，应该像一位训练有素的专家：平时不需要把所有知识都挂在嘴边，但在正确的时机，能够精准地调用正确的知识，高质量地完成被委托的事。