跳转到内容
NTLx's Blog

Anthropic 这篇 skills 文章，真正写的是组织接口

Anthropic 这篇 Lessons from building Claude Code: How we use skills 表面上是在教人怎么写 skill。九类分类、gotchas、hooks、memory、marketplace，一路看下来，很容易把它读成一份“Claude Code 最佳实践清单”。

但我读完以后更强烈的感觉是：它真正写的不是 skill，而是组织终于开始给 Agent 造接口。

以前我们说 prompt engineering，本质上还是一个人对模型讲话。你知道什么，就把什么写进提示词。Anthropic 这篇文章往前走了一步。它现在盯着另一件事：哪些知识值得沉淀成文件，哪些验证值得脚本化，哪些风险值得 hook 化，哪些历史值得让 Agent 下次还能读到。

那张九宫格，分的不是技能，是组织职责

Section titled “那张九宫格，分的不是技能，是组织职责”

原文那张九类 skill 的图，我觉得最值钱的地方，在于它把一个组织里原本散落的职责第一次摆到了同一张图上。library/API reference、verification、data analysis、business automation、deployment、runbook、infra operations，这些看起来像“skill 类型”，其实更像“组织里哪些知识和动作值得变成可调用单元”。

这里最醒目的是第二类：verification。Anthropic 明说，verification skills 在内部对输出质量的改善最可测，甚至值得工程师花一整周把它打磨好。这个判断非常重。它几乎是在告诉你：Agent 时代最值得产品化的，是验收环节。

这也和 Anthropic 后来那篇 How Anthropic enables self-service data analytics with Claude 接上了。那篇给出的数字很夸张：没有 skills 时，Claude 回答分析问题的准确率不超过 21%；加入 skills 后，整体稳定超过 95%。差距主要出在流程知识和验证套路被外化了，模型本身并没有突然换了脑子。

所以我现在更愿意把 skill 理解成一种职责压缩格式。它把 senior engineer 脑子里的坑、分析师手里的查询顺序、运维的回滚纪律、产品流程里的验收动作，压成 Agent 能反复调用的东西。

Skill 不是 prompt，它是上下文的路由器

Section titled “Skill 不是 prompt，它是上下文的路由器”

我之前在 《从提示词到工具箱——Claude Code 技能系统的设计哲学》 里写过，skills 的意义在于把“一段提示词”升级成“一个文件夹工具箱”。这次再看官方材料，我觉得还可以再往前推一步：skill 不只是工具箱，它还是上下文的路由器。

官方在 skills explained 和 技能文档 里都反复强调同一个机制：先扫描 metadata，再按需加载正文，再在需要时读取引用文件和脚本。skill 的核心价值，就在于它能在对的时候，只放进对的那一点东西。

这很像把 prompt 从一大段连续文字，拆成了一套分层文件系统。你不用把所有制度都写进主提示词里常驻；你只需要让 Agent 知道，这里有哪几个入口，碰到什么问题时该读哪份规则、哪份 gotchas、哪段脚本。

这件事看起来朴素，实际上是在改 Agent 工程的重心。难点落到另一处了：怎么把组织经验切成能按需装载的块。

description 写给模型看，所以它更像函数签名

Section titled “description 写给模型看，所以它更像函数签名”

原文里最容易被忽略的细节，是作者反复提醒：description 不是给人看的摘要，而是给模型看的触发条件。官方文档甚至把这件事说得很直白：description 是最推荐填写的 frontmatter 字段，因为 Claude 就靠它判断什么时候自动加载这个 skill。

这一下，skill 的味道就变了。

如果 description 只是宣传文案，skill 还是内容资产。可一旦 description 决定触发，它就更像一个接口声明，甚至像函数签名。它在回答的是：什么时候该把我接进来。

这也让我想起我在 《Claude Code 的七种控制方式：从’告诉 AI 做什么’到’让 AI 无法不做’》 里写的那个区分：prompt 是叙述，skill 是路由，hook 才是强制执行。三者不在一个层级上。真正成熟的 Agent 环境，会把触发、装载、执行、拦截拆开管理。

所以当 Anthropic 说“description 要为模型而不是人为写”时，它其实是在承认一个事实：组织知识如果要给 Agent 用，就不能只追求可读性，还要追求可匹配、可调度、可组合。

日志、配置、记忆，说明组织开始给 Agent 造工作面

Section titled “日志、配置、记忆，说明组织开始给 Agent 造工作面”

原文后半段那些例子，我觉得比九类分类更重要。config.json、standups.log、动态 hooks、脚本目录，这些东西放在一起看，已经像一块新的工作面。

配置文件解决的是首次接入。日志解决的是跨任务记忆。脚本解决的是把高重复、高确定性的动作从 token 里拿出来。hooks 解决的是“绝对不能错”的边界。几样东西拼起来，skill 开始像一个小型工作接口，而不是一篇说明书。

这也是为什么我不太认同“skill 只是 lazy-loaded prompt”这种轻描淡写的说法。它当然带着 prompt engineering 的成分，但更接近一种团队可维护的制度载体。prompt、目录、脚本、记忆、配置和触发规则，全都被绑在了一起。

当然，这里也有文章没展开的另一半。Hacker News 上很多人质疑：如果团队连文档都维护不好，skills 只会把过时制度更大规模地传播。我觉得这不是抬杠，而是真问题。一个没有 owner、没有持续更新 gotchas、没有验证回路的 skill，最后只会变成一条自信但过期的组织谣言。

所以我读到最后，脑子里留下的不是“赶快多写几个 skill”。我想到的是另一句更硬的话：Agent 时代真正的竞争力，落在谁能持续把组织里的判断、验证和记忆维护成可调用接口。

如果你也在给团队上 Agent，你最想先接口化的是什么：坑点、验收、配置，还是历史记忆？

延伸阅读

Section titled “延伸阅读”

参考资料

Section titled “参考资料”