从 Prompt 到 Skill：读 Claude Code Skills 这篇文章的一点理解

最近读到 Thariq 在 X 上的一篇文章：《Lessons from Building Claude Code: How We Use Skills》。

原文链接：\ Lessons from Building Claude Code: How We Use Skills

先说一下作者。Thariq Shihipar 可以算是 Claude Code / Agent 工程实践的重要推动者之一。截至 2026 年 3 月 18 日，他的 X 账号显示有 13.36 万关注者，也署名写过 Anthropic 官方博客 Building agents with the Claude Agent SDK。他写这篇关于 Claude Code Skills 的文章，不太像产品介绍，更像是在整理一套已经在团队里反复验证过的经验。

我读完最大的感受是，AI 工具的发展，正在把我们从“优化单次提示”，推向“设计可复用能力”。

这件事值得展开说。

一、Skill 解决的，不是回答质量，而是复用问题

很多人第一次接触 Skill，会把它理解成“高级一点的 Prompt”。

这当然不算错，但不够准确。

Prompt 的单位是“一次请求”。\ Skill 的单位是“一类任务”。

前者关注的是：这一轮怎么让模型答得更好。\ 后者关注的是：同类问题以后如何稳定地做。

这是两种完全不同的工程对象。

如果我们把 AI 只当成一个对话界面，那么优化 prompt 就够了。但一旦你开始把 AI 用在写代码、验证产品、生成报告、执行流程这些高频任务里，你很快会发现，真正麻烦的不是“说什么”，而是：

• 需要哪些上下文
• 哪些规则每次都要重复
• 哪些步骤必须验证
• 哪些地方最容易出错
• 哪些动作应该交给脚本而不是语言生成
• 哪些结果要被保存，供下次继续使用

换句话说，问题已经从“怎么提问”变成了“怎么封装能力”。

Skill 的意义，就在这里。

二、文章里最重要的一个判断：Skill 不是文件，而是工作单元

这篇文章反复强调一个点：Skill 不是“一个 markdown 文件”，而是“一个目录”。

这个判断非常关键。

因为当你把 Skill 理解为目录，它就不再只是说明文字，而是一个完整的工作单元。这个目录里可以有：

• 主说明文件
• 参考文档
• 模板
• 脚本
• 配置文件
• 样例数据
• hooks
• 持久化数据的入口

这意味着，Skill 本质上是在做一件很像软件工程的事：把知识、工具、边界和执行路径，一起打包。

从这个角度看，Skill 更接近一个“面向模型的微型工具包”，而不是一段更长的提示词。

这也是为什么 Thariq 在文中提到，好的 Skill 往往会使用文件系统做 progressive disclosure，也就是渐进式披露。模型先读最小必要信息，需要时再进入 references/、assets/、scripts/ 等目录继续取材，而不是把所有内容一次性塞进上下文。

这背后其实是一种很典型的上下文工程思路：不是让模型一次看到所有东西，而是让它在正确的时候读到正确的信息。

三、他们总结的 9 类 Skill，本质上是一张“组织经验地图”

文章里把内部常见的 Skills 分成了 9 类，比如：

• Library & API Reference
• Product Verification
• Data Fetching & Analysis
• Business Process & Team Automation
• Code Scaffolding & Templates
• Code Quality & Review
• CI/CD & Deployment
• Runbooks
• Infrastructure Operations

这份分类最有意思的地方，不在于名字，而在于它揭示了一个事实：

Skill 不是围绕“模型会什么”来设计的，而是围绕“组织里哪些经验值得复用”来设计的。

也就是说，Skill 的对象不是能力清单，而是经验清单。

比如 API skill，沉淀的是内部库的边界和 footguns；\ 比如验证 skill，沉淀的是“怎样证明它真的工作了”；\ 比如 runbook，沉淀的是面对告警和异常时的排查路径；\ 比如团队流程 skill，沉淀的是那些重复但容易出错的协作动作。

如果从知识管理的角度看，这其实是在把原本散落于文档、脚本、口头经验和工程习惯里的隐性知识，逐步转成模型可调用的结构化资产。

这比“让 AI 更聪明”更重要。因为真正稀缺的，从来不是通用推理能力，而是组织内部那些不写下来就会反复丢失的经验。

四、文章最有价值的建议，不是“多写说明”，而是“多写 gotchas”

如果只让我选文中最重要的一条建议，我会选这一条：Build a Gotchas Section。

原因很简单。

大多数 Skill 写作者天然倾向于描述“正确路径”。\ 但模型在真实环境里最缺的，往往不是正确路径，而是错误边界。

真正高价值的信息通常长这样：

• 哪些参数组合不能用
• 哪些页面状态不能只靠肉眼判断
• 哪些命令在生产环境下有破坏性
• 哪些系统返回值看起来成功，其实并没有完成业务动作
• 哪些默认做法在这个团队里是不被接受的

这些不是教科书知识，而是实战知识。

从信息密度上看，gotchas 往往比普通说明高得多。因为模型对于“常规写法”通常已经知道不少，但对“这家公司、这套系统、这条流程里的特殊坑”并不了解。

所以好的 Skill 不是把常识重复一遍，而是补齐模型最可能犯错的那一段认知缺口。

这也是为什么我越来越觉得，Skill 设计的核心不是“写得全”，而是“写得准”。

五、文中给出了一套很清晰的 Skill 设计原则

把全文收束一下，大概能提炼出这样几条方法论：

1. 不要陈述模型本来就知道的东西。\ 重点写那些能改变默认行为的信息。

2. 把高频错误显式化。\ 也就是用 gotchas 去沉淀失败经验。

3. 把大块信息拆开，按需暴露。\ 用文件系统而不是一大段提示词管理复杂度。

4. 不要把模型写死。\ Skill 应该提供边界和资源，而不是把每一步都固定成脚本化动作。

5. 能用代码解决的，不要只靠文字。\ 脚本、模板、helper library 的价值，通常高于描述性说明。

6. 需要状态的 Skill，要考虑持久化。\ 而且存储位置要稳定，不能和 Skill 升级过程强绑定。

7. 危险限制适合做按需 hooks。\ 不是所有 guardrail 都应该全局生效。

这几条放在一起看，会发现它们其实共同指向一个原则：

Skill 设计，本质上是在做“最小但足够”的能力封装。

既不能只有文字，没有执行力；也不能全部刚性规定，没有适应性。

六、我自己的一个结论：AI 使用正在从“提问技术”转向“资产建设”

读完这篇文章，我最大的感受是，下一阶段真正拉开差距的，未必是谁更会写 prompt，而是谁更会把反复出现的任务沉淀成资产。

Prompt 是即时技巧。\ Skill 是长期资产。

Prompt 更多服务于当前对话。\ Skill 服务于未来重复发生的问题。

Prompt 的上限来自表达能力。\ Skill 的上限来自你是否理解自己的工作流，是否知道什么值得固化。

这对团队成立，对个人也成立。

一个人如果长期使用 AI 做写作、编程、分析、信息整理、发布流程，迟早会遇到同一个问题：哪些东西不应该每次从头再说？

一旦这个问题出现，Skill 就不是可选项，而是自然演进方向。