从 Claude Code 的 Skills 设计中，我看到了 9 个值得借鉴的产品化思路

最近看到 Thariq 在 X 上发布的一篇长文《Lessons from Building Claude Code: How We Use Skills》，读完之后最大的感受不是“又多了一个 Agent 概念”，而是：Skills 正在从提示词技巧，进化成一种可复用、可组织、可分发的能力封装方式。

这篇文章并不只是介绍 Claude Code 怎么用 Skill，更重要的是，它把一个团队在真实生产环境里怎么沉淀经验、约束模型、复用流程、组织上下文，讲得很具体。

如果你在做 AI Agent、工作流自动化、企业知识库、内部开发平台，或者正在思考“如何把经验沉淀成 agent 能调用的能力”，这篇文章非常值得读。

为什么值得读这篇文章？

这篇文章有三个很高的价值：

• 它不是停留在“Skill 是什么”的概念层面，而是直接总结了团队里大量真实使用后的经验。
• 它把 Skills 从零散技巧整理成了较清晰的类别体系，方便团队内部建立共同语言。
• 它提醒我们：真正有价值的 Skill，不是重复常识，而是补上模型默认不知道的上下文、约束、脚本和坑点。

换句话说，这不是一篇“怎么写提示词”的文章，而更像一篇“怎么做 Agent 能力工程”的文章。

原文讲了什么？

作者先澄清了一个很常见的误解：很多人把 Skill 理解成“一个 markdown 文件”，但在 Claude Code 的语境里，Skill 更像是一个文件夹。

这个文件夹里不仅可以有说明文档，还可以包含：

• 脚本
• 资源文件
• 模板
• 数据
• references
• 配置项
• 动态 hooks

这意味着 Skill 的本质，不只是“告诉模型怎么做”，而是把完成某类任务所需的上下文和操作能力一起打包。

从这个角度看，Skill 更接近下面这几种东西的结合体：

1. 一份 SOP
2. 一组领域知识
3. 一套可调用的辅助脚本
4. 一种渐进式暴露上下文的方法

这也是为什么 Skills 会成为 Claude Code 中非常重要的扩展点。

一、作者总结的 9 类 Skills

文章里把团队内部常见的 Skills 大致分成了 9 类。这个分类很有启发性，因为它几乎覆盖了 Agent 在真实工作中最常见的几个方向。

1. Library & API Reference

这一类 Skill 的目标，是帮助模型正确使用某个库、CLI 或 SDK。

它特别适合用来处理下面这些问题：

• 某个内部 SDK 文档不完整
• 某个命令行工具参数很多，模型容易用错
• 某个前端设计系统有很多隐含约束
• 某个库有大量 footguns 和 edge cases

这类 Skill 的价值在于：把“会用”和“正确使用”之间的差距补齐。

2. Product Verification

这一类不是教模型写代码，而是教模型如何验证自己写出来的东西是否真的可用。

比如：

• 自动跑一遍注册流程
• 在结账链路里验证支付状态
• 借助 playwright、tmux 等工具进行交互式测试

这是非常重要的一类，因为很多 Agent 系统真正的短板，不是“不会生成”，而是“不会严谨验证”。

3. Data Fetching & Analysis

这一类 Skill 让 Agent 能够连接数据源、日志系统、监控面板和分析平台，完成更接近业务分析和运维排查的任务。

例如：

• 查询漏斗转化
• 对比 cohort 留存
• 根据问题快速定位 Grafana 看板

如果说前两类偏“工程执行”，这一类就开始进入“业务分析增强”。

4. Business Process & Team Automation

这一类非常像组织内部的自动化流程封装。

例如：

• 自动整理 standup
• 自动创建工单
• 生成 weekly recap

它的重点不在技术复杂度，而在于把团队重复做的事情，沉淀成标准化工作流。

5. Code Scaffolding & Templates

这类 Skill 用于生成样板代码、迁移模板、服务模板、项目初始化结构等。

它特别适合那些“并不复杂，但每次都很重复，而且要求风格统一”的工作。

本质上，这是把“脚手架”从传统代码模板，升级成“模板 + 说明 + 约束 + 上下文”的组合。

6. Code Quality & Review

这一类 Skill 用来提高代码质量，比如：

• 风格检查
• 测试规范约束
• 评审建议
• fresh-eyes 式的对抗性审查

它的意义不只是减少错误，更重要的是帮助团队把“隐性的代码标准”显性化。

7. CI/CD & Deployment

这一类关注的是交付流程，例如：

• 自动 babysit PR
• 部署后 smoke test
• 流量渐进发布
• 出问题自动回滚

这说明 Skill 不只是本地编码辅助，它也可以深入到工程交付链路。

8. Runbooks

这一类对 oncall、排障和 incident response 很有帮助。

它通常从一个症状出发，比如：

• 某类报警
• 某个错误签名
• 某个 Slack 讨论线程

然后引导 Agent 做结构化调查，最后生成报告。

这是典型的“把经验型排障流程封装成可以复用的能力”。

9. Infrastructure Operations

最后一类更接近基础设施和运维动作，比如：

• 找孤儿资源
• 做依赖治理
• 成本排查
• 带确认环节的清理操作

这一类 Skill 通常会涉及高风险动作，所以也特别需要 guardrails。

二、这篇文章最值得记住的 5 个判断

如果只能记住原文里的几条观点，我觉得下面 5 条最重要。

1. 不要写“显而易见的东西”

这是整篇文章里我最认同的一点。

模型本身已经知道很多通用知识。如果一个 Skill 只是把文档里最基础、最公开的内容又复述一遍，那它的边际价值会很低。

真正高信号的信息，通常来自下面这些内容：

• 团队内部默认约定
• 某个系统的特殊限制
• 某个库的常见坑
• 模型反复犯错的地方
• 某类任务里最容易忽略的细节

换句话说：Skill 的价值，不在“百科全书式覆盖”，而在“补模型的短板”。

2. Gotchas 往往是 Skill 里最值钱的部分

作者特别强调了 gotchas section。

这很合理，因为一个团队真正长期沉淀下来的经验，往往不是“应该怎么做”，而是：

• 哪些地方最容易踩坑
• 哪些做法看起来对，实际上会出错
• 哪些条件触发后必须换路径处理

如果你在构建内部 Skill，最有价值的维护方式之一，就是持续把模型和工程师踩过的坑写进去。

3. 要利用文件系统做“渐进披露”

这也是一个非常关键的设计思路。

Skill 不应该把所有信息一次性塞进一份大文档里，而应该利用目录结构，把不同信息放在不同层级：

• 主文档写原则和入口
• references 放详细 API 或签名
• assets 放模板
• scripts 放可调用脚本
• examples 放示例

这样模型可以在需要的时候按需读取，而不是一开始就被无差别信息淹没。

这其实是一种很典型的上下文工程思想。

4. 不要把模型“轨道化”得太死

原文提到，不要 railroading Claude。

也就是说，Skill 要提供足够的方向和边界，但不要把模型绑死在一种僵硬流程里。因为真实任务往往有上下文差异，如果写得过于死板，Skill 反而会降低适应性。

好的 Skill 更像：

• 给出判断原则
• 提供必要资料
• 提供常用脚本和模板
• 指出风险点

而不是：

• 要求每次都完全按固定路线机械执行

5. Description 字段不是简介，而是触发条件

这是很多人最容易忽视的一点。

作者提醒：模型会先扫描所有 Skill 的 description，再决定这次任务是否要触发某个 Skill。

所以 description 最重要的工作，不是“介绍这个 Skill 是什么”，而是清楚告诉模型：

• 什么情况下应该调用它
• 用户会怎么描述这类需求
• 哪些场景是它的适用边界

如果 description 写不好，再优秀的 Skill 也可能长期“躺在仓库里吃灰”。

三、为什么这篇文章对做 Agent 产品的人尤其重要？

因为它让我们看到，Agent 能力建设的重点，可能并不只是模型本身，而是：

• 如何组织上下文
• 如何把经验结构化
• 如何让模型按需读取信息
• 如何让工作流可复用
• 如何让验证与执行闭环起来

从这个角度看，Skill 并不是一个“Prompt 小技巧合集”，它更接近一种中间层：

把组织经验、工具能力、模板、验证方式、脚本和约束，封装成 agent 可以调用的能力单元。

这也是为什么很多团队在真正用 Agent 做事之后，最后拼的不是谁提示词更花哨，而是谁更早把知识和流程沉淀成可复用资产。

四、原文也隐含了几个更大的问题

虽然这篇文章已经很完整，但从评论区和实际应用角度看，还有几个问题会越来越重要。

1. Skill 的版本管理

如果多人在同一仓库中使用同名 Skill，但版本不同，结果可能会不一致。

这在团队协作和企业场景里会非常常见。

2. Skill 的去重与分类

当 Skill 越来越多时，重复、重叠、命名冲突会迅速增加。

例如：

• 一个团队有 design skill
• 另一个团队也有 design skill
• 还有外部社区版本的 design skill

这时候如何组织、推荐、治理，会成为核心问题。

3. Skill 的评估机制

我们怎么知道某个 Skill 更好？

是调用率更高？错误率更低？完成任务更快？用户满意度更高？

如果没有评估体系，团队就很难知道该继续维护什么、淘汰什么。

4. 面向社区的分发与商业化

原文更多是在讲内部使用视角，但如果 Skill 走向公共生态，就会出现新的问题：

• 如何发布
• 如何发现
• 如何安装更新
• 如何统计使用情况
• 如何沉淀贡献者生态

这会让 Skill 从“团队资产”进一步走向“平台能力”。

五、我自己的一个总结：Skill 的本质是什么？

读完整篇文章之后，我更愿意把 Skill 理解为下面这句话：

Skill 不是提示词包装，而是把组织经验产品化。

所谓“产品化”，不是说它一定要做成一个复杂平台，而是说它要具备几个特征：

1. 能被触发
2. 能被复用
3. 能被维护
4. 能被分发
5. 能随着真实问题不断迭代

当一个团队开始认真构建 Skills，它其实是在把原本散落在文档、聊天记录、资深员工脑子里、脚本角落里的经验，整理成 agent 时代可以真正被消费的能力层。

这件事的意义，比单纯“让 AI 更聪明一点”要大得多。

总结

如果你正在搭建自己的 Agent 工作流，我觉得这篇文章最值得带走的，不只是那 9 类 Skill，而是背后的方法论：

• 不要重复模型已经知道的内容
• 要优先沉淀 gotchas 和高信号经验
• 用文件系统做渐进披露
• 给模型边界，但不要把它写死
• 把 description 当成触发机制来设计

等你真正开始这样做，你会发现自己做的已经不只是“提示词工程”，而是更接近一套可演化的 agent 能力体系。

文章来源与出处

本文基于以下原文进行整理、翻译与延伸解读：

• Thariq, “Lessons from Building Claude Code: How We Use Skills”
• 原始链接：https://x.com/trq212/status/2033949937936085378
• 文中观点与结构整理自作者原文，中文表达、结构化梳理与延伸分析为本文作者补充

如果你更关心的是“这些经验能不能迁移到别的 Agent 平台”，答案大概率是：可以，而且非常值得。 因为它本质上讨论的不是某个单一产品功能，而是“如何把经验转化为 agent 可用能力”这件事本身。