90% token被浪费：AI编程的「渐进式加载」藏了3年

一个语法校验器有20个关联文件，开发者习惯一次性全塞进上下文窗口。结果？token瞬间爆满，AI在噪音里迷路，连简单的DECLARE验证都答错。

这不是AI变笨了，是你喂饭的方式太粗暴。

渐进式披露（Progressive Disclosure）在界面设计里是老朋友——先给用户看核心，需要时再展开细节。把它搬到AI编程技能架构上，token消耗能砍掉90%，响应速度却纹丝不动。

一次性加载的灾难现场

想象你走进一家图书馆，管理员不问你要查什么，直接把20个书架全推倒你面前。DECLARE规则、数组语法、嵌套数组、函数调用、循环结构……全混在一起。

你只想问「DECLARE 123合法吗」，AI却不得不先读完15000token的庞然大物。上下文窗口被无关规则塞满，留给对话的空间归零。 hallucination（幻觉）开始冒头，追问？没门，窗口早爆了。

更隐蔽的损耗藏在响应模板里。一个完整的技能文件往往包含「何时用」「怎么用」「输出格式」三块，但单次请求通常只触发其中一块。剩下的变成沉默成本，像买了全票却只坐了一站地铁。

关键词触发：让AI自己点菜

渐进式披露的核心机制是关键词映射。你在主技能文件里埋入触发器，AI识别到特定词汇才加载对应子模块。

输入「DECLARE 123」，系统捕捉到DECLARE关键词，只拉取declaration.md。数组相关规则？函数调用细节？循环语法？全留在硬盘里睡觉。

这种「按需索取」把token消耗从15000压到1500，精度反而提升——AI的视野里只有当下需要的规则，没有干扰项。

实现层面需要三件套：用「What/When/How」模式写描述，让AI快速判断技能相关性；在主文件里建条件规则，定义关键词与文件的映射关系；准备响应模板，确保输出格式一致。AI通过关键词主动请求资源，开发者不用猜它会用到哪部分。

三层加载：从名片到手术刀

完整的渐进式披露分三个阶段运作，像递名片、聊需求、动手术，层层递进。

Discovery（发现阶段）：启动时只加载技能的元数据——名字和描述。AI知道「有个语法校验器存在」，但不知道它具体能干嘛。这个阶段零token开销，纯索引。

Activation（激活阶段）：任务描述匹配上技能标签，SKILL.md完整指令才进上下文。AI现在明白「要校验语法」，但还没碰具体规则文件。

Execution（执行阶段）：解析用户输入时检测到DECLARE关键词，对应子模块动态加载。AI终于拿起手术刀，但只切需要的那一刀。

每个阶段都由真实需求触发，而非预加载的保险策略。复杂技能可以无限膨胀——加100个子模块也不影响启动速度，因为没人会一次性唤醒它们。

模块化拆分的工程细节

把单体文件拆成模块不是简单切块，得按「独立触发单元」重组。语法校验器的正确姿势是：declaration.md管DECLARE规则，array.md管数组，nested-array.md管嵌套，function-call.md管调用，loop.md管循环。

每个子模块内部保持自洽，包含自己的规则、示例、边界情况。主文件只负责路由——「看到DECLARE就去declaration.md，看到[就去array.md」。

这种结构让调试变得透明。AI输出异常时，你一眼就能定位是哪个子模块在作妖，不用在15000token里大海捞针。

响应模板也要分层。发现阶段返回技能列表，激活阶段返回能力说明，执行阶段返回具体校验结果。同一技能在不同阶段呈现不同面貌，用户不会收到超纲信息。

渐进式披露本质上是把「开发者预设」翻转成「AI自选」。传统做法是你猜AI需要什么，提前备好；新做法是AI自己判断需要什么，实时索取。后者在信息过载场景下几乎是唯一解——当技能复杂度超过上下文窗口的10%，预加载必然崩盘。

有个细节值得玩味：关键词触发机制让AI获得了某种「元认知」能力。它不再被动接受全部指令，而是主动发起资源请求。这种架构下的AI更像调用API的程序员，而非执行脚本的解释器。

当你的技能文件突破5000token时，渐进式披露就从优化选项变成生存必需。现在检查你的技能架构：有多少token正在沉默燃烧？