Claude Code Skills 实战经验：Anthropic 内部到底怎么用
这篇文章最值得记下来的，不是又补了一份 SKILL.md 写作规范，而是把一个更实际的问题说透了：Skill 真正的价值，不在“能不能触发”，而在“能不能把团队里反复出现的经验、检查和流程，稳定地交给 agent”。
如果只把 Skill 理解成一段提示词，最后通常会写成一份越来越长的说明书。Anthropic 内部的做法明显不是这样。他们把 Skill 当成一个可以持续演进的能力单元，里面可以放说明、脚本、引用资料、模板、配置和 hooks。这样一来，Skill 管的就不只是“怎么说”，还包括“怎么查、怎么验、怎么落地”。
我读完后留下来的判断很简单：Skill 不是 prompt 的别名，它更像是给 agent 准备的运行时工作包。
原文里把内部常用 Skill 分成了九类。我觉得这个分类很有用，因为它逼着你先想清楚自己到底在解决哪一类失控问题。
Library & API Reference：给特定库、CLI、SDK 或内部平台补齐用法、坑点和参考代码。Product Verification：告诉 agent 应该怎样验证功能是否真的可用，而不是只看代码长得像不像对。Data Fetching & Analysis：接查询、监控和指标系统，负责拉数、比对和分析。Business Process & Team Automation：把 standup、周报、建单、流转这类重复流程压成一个入口。Code Scaffolding & Templates：生成脚手架、迁移文件或团队约定的模板代码。Code Quality & Review：做审查、风格约束和测试规范收口。CI/CD & Deployment：覆盖发布、回滚、重试和流水线看护。Runbooks：围绕告警、错误签名或故障症状做排查手册。Infrastructure Operations：处理孤儿资源、成本巡检、依赖治理这类运维动作。
原文有个判断我很认同：最好的 Skill 往往只属于其中一类，最难维护的 Skill 通常是职责混在一起的那种。你一旦既想塞知识库，又想塞脚手架，还想顺手做验证和发布，最后多半会变成一个谁都不敢改的大 prompt。
作者明确提到，不要在 Skill 里重复 Claude 本来就知道的常识。高价值内容应该是那些默认模型最容易踩坑、但你团队又已经有共识的东西。
这也是为什么 Gotchas 会被单独拿出来强调。很多 Skill 看起来写得很完整，但真正最有信号的往往只有几行：哪些命令不能乱用，哪些参数容易填错，哪些边界条件会让结果直接失真。把这些失败模式持续沉淀下来，Skill 才会越来越值钱。
原文反复强调，Skill 是文件夹，不只是 Markdown 文件。这一点看上去像实现细节，其实是设计核心。
你可以把详细 API 签名放进 references/，把模板放进 assets/，把确定性校验做成脚本，再让主 SKILL.md 只负责描述入口和路径。这样做的好处很直接：默认上下文更轻，信息也更容易按需展开，不需要每次都把全部细节塞进主说明。
这类设计跟普通软件工程其实很像。不是所有知识都要常驻内存，很多时候更重要的是把索引和分层设计好。
作者用了一个很好的词，叫 railroading。意思是你把 agent 写成只能沿一条轨道硬走，遇到新情况也没有回旋空间。
这类 Skill 短期看起来很稳，长期通常很脆。输入稍微变一下，或者任务约束和你预设的不一样，它就开始卡住。更好的做法是给出必要的判断依据、检查门槛和信息来源，但不要替 agent 把所有分支都硬编码死。
同样的思路也体现在 setup 上。像发 Slack、跑特定环境、操作内部系统这类 Skill，往往需要用户先补一层上下文。原文建议把这类配置显式存成 config.json 一类的文件，而不是默认 agent 自己猜。这个建议很朴素，但很重要，因为很多“智能体失误”本质上不是推理错，而是前提就没拿到。
文章后半段我觉得最有现实意义的，不是“怎么写第一版”，而是“怎么让 Skill 长期活着”。
一是分发。小团队可以直接把 Skill 放进 repo，大团队则更适合做内部 marketplace，让真正有价值的 Skill 自然扩散，而不是靠一个中心团队统一拍板。
二是测量。原文提到，他们会记录 Skill 使用情况，观察哪些 Skill 真正常用，哪些其实 undertrigger，哪些又只是名字好听但没人依赖。这个动作很关键，因为 Skill 一旦多起来，问题通常不再是“有没有”，而是“什么时候该触发、触发后有没有真的帮上忙”。
三是演进。好的 Skill 往往不是一开始就很完整，而是先有一个最小版本，然后随着踩坑不断把 gotchas、脚本、模板和配置补进去。换句话说，Skill 也应该像产品一样维护，而不是像一次性的 prompt 一样写完就算。
如果你想在团队里把 Skill 真正用起来，我更建议先做三件事。
第一，先盘点你们最常见的失败类型，再决定做哪类 Skill，不要一上来就从空白页编指令。是库经常被调错，还是验收经常走过场，还是发布流程老忘步骤，这三类问题的 Skill 长得完全不同。
第二，优先投资那些能直接减少返工的 Skill。比如验证类、排障类、数据分析类，或者带明确门禁的业务流程类。它们的回报通常比“再做一个会生成模板的 Skill”高得多。
第三，把 Skill 当成长寿资产来维护。把踩过的坑写进 Gotchas，把重复执行的检查下沉成脚本，把需要用户确认的前置条件显式配置化。真正让 Skill 变强的，通常不是语言更漂亮，而是约束和证据越来越完整。