渐进式披露不省 Token?AI 产品经理必须重新认识 Skill 的边界

一、开篇：一个让人误解的"省钱妙招"

打开 Claude.ai，界面干净、克制，功能入口收得很深。很多人第一次用都会觉得：这个产品设计得真好，不乱。

但如果你是 Claude Pro 用户，你可能会有另一种感受——额度消耗得比预期快得多。明明只是问了几个简单问题，没聊几轮，配额就去了一大半。

这不是错觉，也不是计费 Bug。

有人因此得出结论：Claude.ai 用了"渐进式披露"的设计，界面越来越简洁，但背后的系统却越来越复杂，所以 token 消耗大。言下之意，渐进式披露是"费 token"的罪魁祸首。

这个结论，对了一半，也错了一半。

错的那一半，恰恰是很多 AI 产品经理在做产品决策时最容易踩的坑。

本文想做一件事：把"渐进式披露"和"Skill"这两个概念，在 AI 产品的语境里，说清楚。不只是讲原理，更要给出一个可以落地的判断框架——什么时候值得用，什么时候别浪费精力。

二、渐进式披露的前世今生：一个概念的漂移史

渐进式披露（Progressive Disclosure）不是 AI 时代的产物。它的起源，要追溯到上个世纪九十年代。

这个演变史里有一个关键节点值得停下来看：2020 年代的语义漂移。

渐进式披露进入 AI 产品领域之后，它的含义悄悄扩展了。原本它只是一个界面设计原则，解决的是"怎么让用户不被功能淹没"的问题。但在 AI prompt 工程师和产品经理的讨论里，它开始被用来描述另一件事：怎么让 AI 模型"按需激活"指令，而不是一次性处理所有规则。

这个漂移本身没有对错之分。但问题在于：很多人没有意识到这个漂移的发生，在错误的层面使用了这个概念，做出了错误的产品决策。

他们以为优化了界面的渐进式披露，就优化了系统的 token 消耗。

事实上，这两件事之间，几乎没有关系。

三、为什么 Claude.ai 里的渐进式披露不省 Token

要搞清楚这件事，需要先理解一个概念：系统提示（System Prompt）。

你看到的只是冰山一角

在 Claude.ai 的对话界面里，你输入"你好"，看起来只发送了两个字。但实际上，模型收到的内容远不止这两个字。

在你的消息送达模型之前，Claude.ai 已经在前面悄悄附上了一大段系统提示。这段提示你看不到，但它真实存在，而且每一轮对话都会完整地重新发送一次。

【这里需要配{{一张老派的冰山剖面示意图，冰山水面以上标注"用户输入：你好（2字）"，冰山水面以下标注"系统提示：角色定义+工具描述+安全规则+格式指令+记忆模块（数千token）"，用传统黑白线条图风格，类似教科书插图}}】

这段系统提示里大概装了什么？

角色与行为规范：Claude 应该如何回答，语气风格，哪些能做哪些不能做
工具描述：联网搜索、代码执行、文件处理……每个工具的名称、功能、参数格式，全部以文字形式写在里面
安全与合规指令：各类边界规则，篇幅往往不小
格式与输出要求：什么时候用列表，什么时候用代码块，回答长度的控制逻辑
记忆与个性化模块：如果开启了记忆功能，相关内容也会注入

这些加在一起，仅系统提示本身就可能达到数千乃至上万 token。你那句"你好"，只是压在这座冰山顶上的两个字。

界面的简洁与底层的消耗是两件事

Claude.ai 的界面设计确实用了渐进式披露的思路：功能菜单不一次展开，高级设置藏在二级页面，工具能力按需展示给用户。这让产品看起来简洁、不压迫。

但这里有一个关键的层级错位：

界面的渐进式披露，优化的是用户的认知负担。 Token 的消耗，发生在模型的处理层。这两层之间，没有直接的连接关系。

你在界面上看不到联网搜索的工具描述，不代表这段描述没有进入模型的上下文。只要这个功能在后台是激活状态，它的完整描述就已经被写进系统提示，随着每一轮对话一起发送给模型。

用一个不严谨但直观的比喻：这就像一个员工，每次开会前都要把公司所有的规章制度背一遍，不管这次开会的议题是不是跟这些制度相关。

为什么不做"真正的"按需加载

这个问题的答案涉及工程上的取舍。理论上完全可以做到"用户触发联网时才加载联网工具描述"，但 Claude.ai 作为面向大众的通用产品，有几个现实约束：

意图预判有成本。要在用户发消息之前判断"这条消息需要哪些工具"，本身就需要一次额外的模型调用，这个开销不一定比全量加载小。

用户体验优先。动态加载可能导致工具触发不稳定，全量预加载能保证每次行为可预期。

工程复杂度。全量加载是最简单、最稳定的实现，动态管理带来的维护成本对通用产品来说往往得不偿失。

这些都是合理的工程决策。但作为产品经理，你需要清楚地知道：

Claude.ai 的系统提示成本，是为了换取稳定性和通用性而付出的固定开销。它不会因为你的任务简单而减少。

对用 Claude.ai 辅助日常工作的用户来说，这意味着 token 利用率天然偏低。就像买了一把瑞士军刀，不管今天只用了刀片，那些螺丝刀和开瓶器的重量你都得拿着。

对想通过 API 构建 AI 产品的产品经理来说，这个认知更关键：界面层的渐进式披露你无法干预，但架构层的上下文管理完全在你掌控之内。

四、Skill 是什么：被低估的 Prompt 工程单元

在进入"怎么做"之前，必须先把一个概念辨析清楚，否则后面的建议全部失效。

"Skill"这个词在 AI 语境里，至少有两种完全不同的含义，很多人混用了。

产品层 Skill，是 Claude.ai 这类产品里的内置能力——联网、代码执行、文件处理、记忆。这些功能对用户来说是"技能"，但对系统来说，它们以工具描述的形式预装在系统提示里，用不用都在消耗 token，用户无法控制。

工程层 Skill，是在自己构建 AI 产品时，把可复用的 prompt 指令封装成独立模块，按需注入上下文。这才是真正意义上能被产品经理"设计"和"优化"的 Skill。

Skill 的本质是：把隐性的专家经验，显式化、模块化。

类比一下：Skill 之于 Prompt，就像组件库之于前端开发。你不需要每次从头写一个按钮，而是调用封装好的 Button 组件。Skill 做的是同一件事——把"如何分析竞品""如何写用户故事""如何拆解需求"这些专业能力，封装成可以随时插入的 prompt 模块。

五、Prompt 工程层的渐进式披露：真正能降本增效的地方

讲到这里，核心问题来了：在自己构建 AI 产品或 Agent 时，怎么做才能真正降本？

先把最重要的原则说清楚：

信息不进入上下文，而不是"写了但希望模型忽略"。

这是工程层渐进式披露和界面层渐进式披露最本质的区别。界面上藏起来的功能，底层依然全量加载。工程层真正有效的渐进式披露，是让那段信息物理上就不出现在发给模型的内容里。

上下文窗口的分区管理

把上下文窗口想象成一个有限的工作台，而不是一个无限扩容的档案室：

【这里需要配{{一张三层分区示意图，采用传统表格样式，竖向分为三栏：第一栏"固定区（始终存在）"标注角色定义/当前任务目标，第二栏"动态区（按步骤替换）"标注当前工具集/相关记忆片段/上步摘要，第三栏"临时区（用完即清）"标注工具原始返回值/中间推理过程，三栏用不同深浅的灰色填充，风格类似传统架构设计图}}】

大多数人的 prompt 只有"固定区"，动态区和临时区完全没有设计。这是最常见的浪费来源。

三种真正有效的渐进式披露策略

策略一：Skill 动态注入

不把所有 Skill 模块堆在系统提示里，而是根据用户意图，在运行时插入对应模块：

关键在最后一步：任务完成后，主动从上下文中移除已用过的 Skill 模块，为下一步腾出空间。

策略二：工具按需检索

当工具数量超过 15-20 个，直接全量塞进系统提示会带来两个问题：token 爆炸，以及模型在太多选项里选择准确率明显下降。

解法是把工具描述向量化，存入向量数据库，每步只检索最相关的 3-5 个工具注入上下文：

两级工具描述的设计也很有价值：检索阶段用 20 token 的短描述，命中后才把 200 token 的完整 schema 注入。

策略三：观察结果压缩

工具调用的返回值往往很大——搜索结果、文件内容、API 响应。这些内容如果原样塞回上下文，会迅速吞噬窗口空间。

正确做法：

原始数据存外部，摘要进上下文，需要细节时按需检索。这是 Agent 架构里最容易被忽视、但收益最高的优化点之一。

结构化状态替代对话历史

单 Agent 长任务最容易崩在状态混乱上。很多人的做法是把完整对话历史一直带着走，导致上下文随轮数线性增长。

更好的做法是显式维护一个状态对象，每轮只注入这个结构化状态：

{"task_goal": "分析竞品定价策略","current_step": 3,"completed_steps": ["收集竞品列表", "获取公开定价数据"],"pending_steps": ["对比分析", "形成建议"],"key_findings": ["竞品A采用freemium模式", "竞品B按席位收费"],"constraints": ["只看国内市场", "目标客群为中小企业"]}

模型读结构化状态，比读对话历史准确得多，token 也少得多。历史对话不进主循环，全部转化为状态字段。

六、使用决策框架：什么时候该用，什么时候别用

理解了原理，最终还是要落到判断上。以下是一个可以直接拿来用的决策框架。

【这里需要配{{一张传统四象限矩阵图，横轴标注"工具/Skill数量"从少到多，纵轴标注"任务链长度"从短到长，四个象限分别标注：左下"简单任务：不值得引入动态管理"、右下"工具多但任务短：工具检索有价值"、左上"任务长但工具少：状态管理为主"、右上"复杂Agent：全套渐进式披露架构"，用传统黑色边框矩阵风格}}】

✅ 适合使用渐进式披露 + Skill 的场景

❌ 不适合 / 收益极低的场景

一个简单的判断原则：如果你的 AI 产品会被真实用户反复使用，且通过 API 计费，才值得认真设计渐进式披露架构。否则，把时间花在更重要的地方。

七、给 AI 产品经理的三个认知升级

做了这么多分析，最终想给出三个可以直接内化的认知。

认知一：分清你在哪一层工作

用 Claude.ai 做产品辅助，和通过 API 构建 AI 产品，是两件完全不同的事。前者你是消费者，后者你是构建者。同样是"用 AI"，决策框架、优化手段、成本结构都不一样。很多关于 AI 产品的讨论，混淆了这两个视角，导致建议在错误的层面被应用。

认知二：降本增效的真正战场在架构，不在界面

界面简洁不等于系统高效。Token 的消耗发生在模型处理层，界面层的任何优化都无法穿透到这里。真正的降本，发生在上下文窗口的设计里、工具描述的管理里、状态压缩的策略里。这些都是架构决策，不是交互决策。

认知三：Skill 的价值不只是省 token，而是让 AI 行为可预期、可维护、可迭代

这是 Skill 最容易被低估的地方。省 token 只是副产品，真正的价值在于：把隐性的专业经验显式化之后，AI 的行为变得可以被观察、被调试、被版本管理。一个产品经理写了一套竞品分析 Skill，下次换了新人，这套经验不会随人走，它沉淀在 Skill 库里。这才是团队层面 AI 产品化的核心资产。

八、结尾：渐进式披露的终极意义

渐进式披露从诞生起，就是为人服务的。

1990 年代，IBM 的研究员们发现，当界面展示的信息超过用户的处理能力，用户会感到焦虑、迷失、放弃。于是他们提出：在对的时机，给对的对象，披露对的信息。

三十年后，这个原则进入了 AI 时代，它的服务对象多了一个——模型本身。

研究表明，当模型的上下文里塞满了无关信息，它同样会"迷失"：注意力被稀释，选择准确率下降，推理质量退化。这和人类认知过载的表现，惊人地相似。

所以，工程层的渐进式披露，本质上是在替模型做认知管理。

但有一点始终没有变：核心不是"隐藏"，而是"适时"。不是把信息藏起来，而是在它被需要的那一刻，精准地送达。

这对界面设计是这样，对 prompt 工程是这样，对我们每天面对的信息过载，也是这样。