这篇文章从我的一个真实的困惑出发，经由与 AI 的多轮辩论打磨而成。过程中 AI 两次重构了我的框架，我也推翻了 AI 提出的一条“第一性原理”。我把这些博弈痕迹保留在文中——因为一个人和 AI 互相修正、把模糊直觉逼成清晰定义的过程，恰好演示了这篇文章自己的主张：有价值的从来不是答案，是判断力的显式化。
从一个不舒服的现状说起
打开任何一个 agent 系统，skill 都在野蛮生长：散落在不同平台、不同框架里，官方的统一管理姗姗来迟，本地管理更是各家自扫门前雪。这个现状让我一直有种模糊的不安：skill 这东西，到底有没有一套说得通的底层逻辑？
要回答它，得先回答一个更根本的问题：skill 到底是什么？
我最初的定义，和由它引出的两个死结
我最初的定义是：“将垂直领域人员的经验，用自然语言封装好的知识库。”
这个定义听起来没错，但它立刻引出两个无解的问题：
- 知识库是静态的，没法解决每个人具体处境里的细节问题；
- 知识库能封装的案例有限，遇到更复杂的情况，如果里面没有“元知识”（从 0 到 1 解决问题的思想和方法），用户最终只能回头去问作者本人。
这两个问题折磨了我很久。直到和 AI 辩论时才意识到：它们的根源不在 skill 本身，而在“知识库”这个定义上。
翻转：从 knowing-what 到 knowing-how
把 skill 当知识库，封装的就是专家的陈述性知识（knowing-what）——案例的集合、答案的集合。但陈述性知识恰恰是 AI 时代最不值钱的东西：检索工具做得比这好得多。
skill 真正的增量价值在于封装程序性知识（knowing-how）：
skill = 领域专家的决策流程、判断标准、启发式规则的显式化。
所谓“显式化”，就是把专家脑子里那些隐性的、凭直觉说不清楚的判断过程，用文字显性表达出来，变成可检查、可复用、可传给别人的东西。值得一提的是，这个理解和官方口径完全一致——Anthropic 在 Agent Skills 的发布文章里开篇就说，现实工作需要 procedural knowledge（程序性知识），skills 的用途正是 “capturing and sharing procedural knowledge”（捕捉并分享程序性知识）。
一个实例：同一个教学场景，两种 skill
抽象对比不如直接看东西。同样是“封装一位数学老师辅导应用题的经验”：
案例库型 skill 长这样：
- 遇到追及问题：路程差 ÷ 速度差 = 时间
- 遇到工程问题：设工作总量为 1
- 遇到浓度问题：抓住溶质不变
……（共 47 条题型-公式对照）
方法论型 skill 长这样：
辅导流程：
1. 先让学生用自己的话复述题目在问什么。
复述不清时，问："题目里哪些量是已知的？它们之间是什么关系？"
2. 让学生画图或列表，把文字翻译成结构。
画不出来时，示范第一行，让学生补第二行。
3. 学生列出至少两种思路后，才讨论取舍——
取舍标准：哪条路径的未知量更少、关系更直接？
4. 解完后追问："这道题和上次那道的共同点是什么？"
前者遇到没收录的题型就失效；后者能泛化，因为它教的是诊断和推进的流程，题型只是例证。两者的天花板也完全不同：一个受限于案例数量，一个受限于作者的真实水平。
一处必要的自我修正：这不是二元对立
和 AI 讨论时我一度把这个对比推得太绝。实际上两种形态是光谱，中间有大量混合态：品牌规范 skill、API 手册 skill，本质就是陈述性知识，照样很有价值。真正可操作的判断标准是这个：
领域的方差越大（情境越多样），方法论占比就该越高；领域越接近标准化流程（合规、协议、格式类），清单本身就是价值。
用这个标准回看开头那两个死结，性质就变了：“案例有限”直接消解——方法论天然覆盖没见过的案例，“元知识”不该是补丁，它就该是主体；“无法适配个性处境”部分消解——好的 skill 会教 agent 先诊断用户情境，再选择路径，跳过了“标准答案”这一步。之前觉得无解，是因为被“知识库”这个隐喻锁死了；换一个定义，问题自己就松动了。
为什么 skill 要这样设计：保护推理的信噪比
接下来是我和 AI 辩论中，我赢的那一段——也是本文最重要的一处修正。
AI 最初给出的设计公理是“上下文窗口是稀缺资源”。我反驳：现在模型都有上百万 token 的上下文了，稀缺从何谈起？更关键的限制明明是推理方式和回答质量。
辩论的结论是：我们各自对了一半，拼起来才是完整的图景——
名义容量 ≠ 有效容量。 “装得下”和“用得好”是两回事。经典论文 Lost in the Middle（Liu et al., TACL 2024）发现：相关信息处在上下文开头或结尾时模型表现最好，一旦埋在中部，性能显著塌陷——即使是专门为长上下文设计的模型也一样。Anthropic 自己的 context engineering 文章说得更直白：模型和人一样，信息量超过某个点后就会“失焦”（他们称之为 context rot：上下文里的 token 越多，模型准确调用其中信息的能力越差）。
而衰减的机制，恰恰就是我说的“推理架构”。 注意力机制下，每个 token 都在争夺注意权重，无关内容不是安静地占地方，而是主动稀释信号、诱导错误关联。所以稀缺从来不是“空间”，是信噪比预算。这解释了为什么窗口从 100K 涨到 1M，“少即是多”的设计不但没过时，反而更重要——窗口越大，人越容易乱塞，信噪比问题越严重。
于是公理升级为：
skill 设计的本质，是保护模型推理时的信噪比——在对的时刻，只给对的信息。
Anthropic 对 context engineering 的官方定义几乎是这句话的镜像：“finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome”（找到能最大化目标结果的、最小的高信号 token 集合）。
从这个公理出发，Anthropic Agent Skills 的三层设计可以被推导出来，而不只是被列举出来：
- 触发条件——SKILL.md 的 YAML frontmatter（name + description）常驻系统提示词。官方原话：元数据 “provides just enough information for Claude to know when each skill should be used”（只提供刚好够判断触发时机的信息）。推论：description 要写清“何时用我”，别只写“我是什么”，因为它的唯一职责是触发判断；
- 渐进式披露——判定相关后才加载 SKILL.md 正文，再按需读取打包的参考文件。官方称可打包的上下文总量因此“实际上无上限”；
- 按需查找——正文只放指针，细节拆进独立文件，用到才读。
还有一条容易被忽略：skill 可以打包可执行脚本。官方的 PDF skill 里放了一个提取表单字段的 Python 脚本，Claude 直接运行它，脚本和 PDF 都不进入上下文。代码既确定性又省 token——同样服从信噪比这条总原则。
边界：什么时候不该用 skill
第一性原理的文章，最有价值的部分往往是否定性判断。skill 有其明确的适用边界，三类情况它有更合适的替代品：
- 纯事实查错（“这个参数的默认值是多少”）→ 用 RAG 检索，陈述性知识是它的主场；
- 用户个人偏好和习惯 → 交给记忆机制，不值得写成 skill；
- 实时数据与操作（查库存、发请求）→ 用 MCP 等工具接口，skill 只管“怎么做”，不管“数据是什么”。
一句话：skill 封装判断，RAG 供给事实，记忆存偏好，工具给数据。 四者的分工对比值得单独成文，这里点到为止。
教学场景：封装“提问过程”，别封装“答案过程”
我最早对 skill 产生兴趣，正是因为它看起来是封装教师知识的绝佳机会。设想的实验：针对同一个问题，先让学生用裸 AI 学，再用封装了老师经验的 skill 版学，看两者的差异。
这个实验有意义——本质是把专家的认知路径显性化，是“认知学徒制”换了个新载体。但里面有个陷阱：
- 封装老师产出答案的过程 → 学生学到的仍然是答案；
- 封装老师提问和诊断的过程 → 学生学到的才是思考本身。
好的老师，价值不在给出答案，在于知道学生卡壳的每个节点该问什么问题（回看前面那个方法论型 skill 的例子，它封装的正是这个）。
实验设计还能升级一层：让学生用两个版本分别解决同一道新题，再与老师本人的真实解题路径做三层对比，观察指标也明确——学生脱离辅助后能否独立解出新题，而不只是当下的体验差异。
同时要诚实面对一个风险（我的推测，也是教学法里的老问题）：脚手架依赖。skill 帮学生度过了所有卡点，可一旦撤走 skill，他还会卡吗？好的教学型 skill 必须把“脚手架的逐步撤除”也设计进去——这本身又是一条 knowing-how。
一门生意的结构：漏斗、天花板与卖水人
skill 能卖钱吗？能，但要看清什么东西能卖钱，以及流量从哪来。
skill 是自然语言文本，天然无法防复制——看似致命缺陷，拆解之后却另有乾坤：
- 能被复制的部分（静态知识、方法论文本）本来就没法收费——干脆公开，换流量和口碑；
- 真正收费的部分（作者面对新颖、垂直、高难度问题时的现场判断力），恰恰是无法被文字封装、无法被复制的部分。
商业模式的护城河与 skill 的技术缺陷完美互补——这是整个模式最优雅的地方。
但“公开换流量”有个容易漏掉的环节：流量从来不来自 skill 生态内部。prompt 生态里也没有“prompt 商店流量”，流量在内容平台上。所以完整的漏斗是：
内容平台做入口（写作、分享、公开复盘）→ skill 做信任转换器（“不信你自己拿去用”的可验证作品）→ 私域做承接（高难度问题的付费咨询/陪跑）。
类比开源世界更清楚：GitHub 本身不分发，Red Hat 的流量也不是来自软件仓库，而是来自会议、博客和企业品牌。skill 是漏斗的中段，从来不是入口——指望“上架即流量”的人，会把技能包做成库存。
天花板也要诚实承认：私域咨询不规模化。这是一门专家生意（定价权 + 生活方式），不是风投生意。规模化的路径存在，但在后端：口碑攒够之后，把判断力产品化成课程、陪跑营或工具。
最后一个翻转：这个生态最大的风险——用户无法在使用前验证 skill 的质量——恰恰也是最大的机会。在评测基础设施出现之前，创作者的“可验证作品 + 公开写作”就是临时的信任基础设施；而谁先做出可信的 skill 评测体系，谁就是这个生态的卖水人（这是我的推测，欢迎证伪）。
生态：更近 prompt 生态，离 npm 生态尚远
回到开头的碎片化问题。官方并非没有动作：2025 年 12 月，Anthropic 已把 Agent Skills 正式发布为跨平台开放标准，社区注册表（如 skills.sh）也出现了。但碎片化有个更深的原因：
skill 的有效性耦合于宿主 agent 的循环机制。 同一个 skill，在上下文管理策略不同的 agent 里效果差异很大——这正是“信噪比”公理的直接推论：既然效果取决于推理时的上下文配置，而每个宿主配置上下文的方式不同，效果就天然无法跨平台保证。统一注册表能解决“分发”，解决不了“效果”。
所以我的判断是（推测成分，读者自辨）：短期内 skill 生态会更接近 prompt 生态的形态——松散、靠口碑传播、效果因环境而异；很难长成 npm 生态那种强标准、可组合、行为可预期的形态。对创作者的推论很直接：个人口碑和垂直社区里的地位，比上架哪个平台更重要。
结语：一张推导图
整篇文章其实只有两条公理，其余全是推论：
公理 A：skill = 专家决策流程与判断标准的显式化
公理 B：模型的注意力预算有限，信噪比决定推理质量
A → 痛点消解：泛化问题消失，情境适配靠"诊断前置"
A + B → 设计原则：在对的时刻只给对的信息
（触发条件 / 渐进式披露 / 按需查找 / 可执行脚本）
A + B → 边界判断：skill 管判断，RAG 管事实，记忆管偏好，工具管数据
A → 教学应用：封装"提问与诊断过程" > 封装"答案产出过程"
A → 商业模式：可复制的公开换流量，不可复制的判断力做私域；
流量来自内容平台，skill 是信任转换器
B → 生态判断：效果耦合宿主机制 → 近 prompt 生态，口碑 > 平台
一句话总结：别再想着把答案装进 skill，要装的是专家面对问题时的那套“怎么想”。 答案会被抄走、会过期、会失效；而判断力无法复制——这既是好 skill 的设计标准，也是它唯一能收费的底气。
附：本文的人机协作过程（留档）
- 我写下原始思考笔记（痛点、教学设想、商业模式直觉，以及三行没写完的设计原则）；
- AI 提出框架修正：把定义从“知识库”翻转为“决策流程显式化”，并指出我的前两个痛点是定义锁死的产物；
- 我质疑其“上下文窗口稀缺”的公理（百万 token 时代稀缺不成立），AI 接受挑战并查证文献，公理升级为“信噪比稀缺”——这一处升级来自我的质疑，文中已注明；
- 所有官方表述与论文引用，在发表前逐条对照原始来源核实（见下）。
参考来源（均已核实）
- Anthropic 工程博客：Equipping agents for the real world with Agent Skills（2025-10-16 发布，2025-12-18 更新为跨平台开放标准）——procedural knowledge 定位、三级渐进式披露、“容量实际上无上限”、description 用于触发判断、可打包执行脚本等表述的出处
- Anthropic 工程博客：Effective context engineering for AI agents（2025-09-29）——“context rot”、“finite attention budget”、“smallest possible set of high-signal tokens” 的出处
- Liu, N. F., et al. Lost in the Middle: How Language Models Use Long Contexts（TACL 2024）——长上下文中部信息利用塌陷的实验证据
（核对于 2026-08-28）