首先，官方是有硬性边界的。 Anthropic 把 Skills 内容分成了三个 Level：Level 1 是 Metadata（name 和 description），系统启动时永远加载，大概 100 token；Level 2 是 SKILL.md 的正文，触发时加载，官方建议上限是 Under 5K tokens；Level 3 是引用文件和脚本，按需 bash 读取，容量实际无限。写 2000 行肯定超标了，换算下来起码 12K token，超了官方上限两三倍。
其次，为什么要卡在 5K 以内？本质是为了保护模型的注意力。 官方有个核心概念叫 Progressive Disclosure，也就是渐进式披露。大模型的上下文注意力是稀缺资源，如果一次性把所有细节塞进去，反而会稀释它对当前任务的专注度。所以，SKILL.md 不是大杂烩式的文档，也不是 prompt 的延伸，它其实是一个分层引用网络的根节点。
所以在具体写法上，主文件只放三样东西：触发条件、决策树（也就是工作流骨架）、以及引用索引。 其他所有细节------比如长篇的示例、具体的规则、模板、脚本------全部下沉到 Level 3 的子文件里。模型走到某一步，需要细节了，再通过 bash 按需去读。
关于拆分，我的优先级是：先拆示例和模板（最长且低频），再拆详细规则，最后把长流程封装成脚本。 但有个底线：决策树绝对不能拆，否则模型读完主文件连下一步该干嘛都不知道。另外，写引用的时候不能光甩一个文件名，要带上"指路标签"，告诉模型什么情况下去读、重点读哪几条；而且子文件之间绝对不能循环引用，必须由主文件统一索引。
最后，我拿我自己的实战数据举个例子。 我之前维护过一个写作 SKILL，早期把规则、案例、脚本全塞在一个文件里，大概 1900 行，14K token。每次触发，模型先吃进 14K，不仅慢，还经常把不同场景的规则搞混。后来我按渐进式披露重构，主文件砍到 612 行，大概 4.5K token，其他下沉成 7 个子文件。重构后，单次工作流端到端的 token 占用从 28K 直接降到了 12K，不仅成本降了，触发准确率反而上升了，因为主文件不再被无关细节稀释，决策树更清晰了。不同性质的 Skill 之间，我也只用 Handoff 协议交接，绝不混在一个文件里。
我对 SKILL 工程化的理解，它本质上跟传统软件的模块化架构是一回事，只不过我们管理的是 token 预算和模型注意力。