从 Prompt 到 Skill：AI Agent 工作流的下一层抽象
在 把 AI 放进工作流 里，我写过一个判断：AI 不是靠一次漂亮的提示词用好的，而是要被放进一个有边界、有验证、有沉淀的工作流里。
这篇继续往下走，专门谈这个工作流里越来越重要的一层东西：Agent Skill。
如果一个同事还不知道什么是 Agent Skill，我不太想一上来就告诉他：它是一个包含 SKILL.md 的目录，里面有 YAML front matter、说明正文、references/、scripts/ 和 assets/。
这当然是事实，但这不是最重要的事实。
更重要的是：为什么我们已经会写 Prompt 了，还需要 Skill？
Prompt 适合表达这一次，Skill 适合沉淀下一次
我们平时和 AI 协作，最自然的方式是写 Prompt。
“帮我看一下这段代码。”
“按 TDD 的方式实现这个功能。”
“先不要动手，先读项目结构。”
“写完以后跑测试，不要只说完成。”
这些话都很有用。Prompt 的优势就在这里：它直接、灵活、贴近当前任务。你脑子里刚形成一个意图，就可以把它说出来，让 AI 立刻参与。
但问题也在这里。
很多要求并不是只对这一次有用。比如：
- 修 bug 前要先复现。
- 不熟悉代码时要先 zoom out，而不是盯着当前文件解释。
- 写文章前要先确定读者、目的、论点和材料。
- 改完代码后要用新鲜证据验证，不能靠语气宣布完成。
- 重要结论要写回项目文档或知识库，而不是散落在聊天记录里。
如果这些要求每次都靠临时 Prompt 提醒，它们就很容易失效。
人会忘记说。对话会变长。上下文会变脏。AI 会在后半段逐渐回到它熟悉的生成模式里。更麻烦的是，这些做法一旦只存在于聊天记录里，就很难被复用、修改、审查和传给团队里的其他人。
所以 Prompt 的问题不是“不够强”，而是它天然偏向一次性沟通。
Skill 要解决的是另一类问题：把反复出现的工作方式，沉淀成可复用、可触发、可维护的上下文。
Skill 不是更长的 Prompt
很容易把 Agent Skill 理解成“高级提示词”。
这个理解只对了一半。
Skill 里面确实有自然语言指令，Agent 也确实会读这些指令。但一个好的 Skill 不只是把一大段 Prompt 存起来。它至少多解决了三个问题。
第一，它解决“什么时候用”的问题。
Skill 的 description 不只是给人看的简介。对 Agent 来说，它是路由线索。一个好的 description 要说清楚：这个 skill 适用于什么任务，不适用于什么任务，和相邻 skill 的边界在哪里。
第二，它解决“触发后先判断什么”的问题。
SKILL.md 不应该像百科全书，也不应该复制工具教程。它更应该告诉 Agent：当前任务先确认什么，哪些边界不能越过，什么时候需要继续读 references/，什么结果才算完成。
第三，它解决“细节如何按需加载”的问题。
不常用的背景资料、长检查清单、示例、脚本、模板，不一定要全部塞进主文件。它们可以放进 references/、scripts/ 或 assets/。Agent 需要时再读，需要执行时再调用。
所以 Skill 和 Prompt 的差别，不只是“短”和“长”的差别。
Prompt 更像一次对话里的意图表达。Skill 更像某类任务的工作协议。
Skill、Prompt 和 Tool 各自解决不同问题
这三个概念很容易混在一起。
可以先粗略地区分一下：
| 概念 | 解决的问题 | 例子 |
|---|---|---|
| Prompt | 这一次要做什么 | “帮我写一篇解释 Agent Skill 的文章” |
| Tool | Agent 能执行什么动作 | 读写文件、运行测试、搜索网页、调用浏览器 |
| Skill | 某类任务应该怎么做 | 写文章前先确认读者、目的、论点、材料和声音 |
比如我说：“帮我写测试。”
这是一句 Prompt。
Agent 能调用测试命令、编辑器、文件系统，这些是 Tool。
如果我希望它按 TDD 的节奏推进，先写失败测试，再写最小实现，再重构，并且不要为了让测试通过反过来放松断言，那就是 Skill 要表达的工作方式。
Skill 不替代 Prompt，也不替代 Tool。
Prompt 提供当前目标。Tool 提供行动能力。Skill 提供可复用的判断和流程。
Skill 的核心是渐进式披露
Agent Skill 背后的关键设计，不是“把更多说明交给 AI”，而是“只在需要时加载正确说明”。
这叫渐进式披露。
Agent 不应该在每次任务里都读完所有规则。那样上下文会很快变成垃圾桶。真正可持续的方式是分层：
第一层，启动时只让 Agent 看到 skill 的名字、描述和位置。它知道“有这么一个能力”，但还没有把全文塞进上下文。
第二层，当任务匹配时，Agent 才读取对应的 SKILL.md。
第三层，如果 SKILL.md 指向更细的参考资料、脚本或模板，Agent 再按需要继续读取或执行。
OpenAI 的 Codex 文档把 skill 描述为可复用的工作流格式，并明确提到 Codex 先看到 skill 的名称、描述和路径，只有决定使用时才读取完整 SKILL.md。Anthropic 在介绍 Agent Skills 时也用了同样的思路：先加载 name 和 description，任务相关时再读正文，更细的文件继续按需展开。[1][2]
这件事很重要。
因为上下文窗口不是越满越好。把所有规范、示例、异常情况、脚本说明都塞进去，短期看像是“资料齐全”，长期看却会稀释真正关键的约束。Agent 可能读了很多字，却更难抓住当前任务最应该遵守的那几条规则。
好 Skill 不是让 Agent 多读字，而是让 Agent 少想错。
一个 Skill 通常长什么样
从格式上看，一个 Skill 通常是一个目录。
1 | my-skill/ |
SKILL.md 是入口。它通常包含 name 和 description，然后是一段给 Agent 的任务说明。
references/ 放更细的材料，比如写作检查清单、项目规范、领域背景、案例、边界说明。
scripts/ 放可以执行的脚本。能机械化的东西，尽量不要长期停留在自然语言里。脚本比口头规则更稳定，也更容易验证。
assets/ 放模板、图片、样例文件或其他资源。
但格式只是外壳。真正决定 Skill 质量的，是它有没有把边界和判断写清楚。
一个坏的 description 可能是：
1 | description: Help with project work. |
这句话几乎没用。它太宽了，什么都像能触发。
一个更好的写法会像这样：
1 | description: Use when drafting or revising public-facing technical articles. Identify reader, purpose, thesis, evidence, structure, and voice before drafting. Prefer project-docs-writing for durable internal project documentation. |
它说清楚了三件事：什么时候用，做什么，和相邻 skill 的边界在哪里。
这就是 Skill 和普通说明文档的差别。Skill 首先要能被正确触发，其次才是触发后写得多完整。
好 Skill 先教判断，再教步骤
很多人第一次写 Skill，容易把它写成操作手册。
第一步做什么，第二步做什么，第三步做什么。再加一大堆命令示例、注意事项、边界情况。最后 SKILL.md 越写越长，像一份很努力但很臃肿的说明书。
这不一定有效。
Agent 很多基础操作本来就会。它会读文件，会看 --help，会根据项目里的 package scripts 推断测试命令，会模仿现有代码风格。Skill 不应该把这些 baseline 能力重新讲一遍。
Skill 最值得写的是 Agent 默认不知道、但对这类任务很关键的东西：
- 这个团队的特殊约定。
- 这个任务的判断边界。
- 常见错误路径。
- 完成定义。
- 失败时应该回退到哪里。
- 哪些信息必须来自外部证据，而不是猜测。
比如一个写作 skill，不需要教 Agent “Markdown 用 # 表示标题”。它真正应该写的是：先确认读者是谁，文章要解决什么问题，中心论点是什么，材料哪些来自事实，哪些只是作者经验，哪些地方不能编造。
比如一个诊断 skill，不需要教 Agent “可以打印日志”。它真正应该写的是：先建立反馈循环，先复现，再提出可证伪假设，用观察结果更新判断，不要直接跳到最像答案的修复。
比如一个验证 skill，不需要教 Agent “测试命令怎么运行”。它真正应该写的是：不要在没有新鲜证据的情况下宣布完成；验证失败时要报告失败，而不是把语气改得更肯定。
好的 Skill 不是把 Agent 当新手，而是把 Agent 拉回正确的判断结构里。
坏 Skill 会把 Agent 推进噪声里
Skill 写坏了，会比没有 Skill 更糟。
最常见的坏法，是把 Skill 写成“万能入口”。
比如一个叫 engineering 的 Skill，里面同时包含代码审查、TDD、架构设计、文档同步、Git 提交、发布流程和故障诊断。它看起来很完整，但每次触发都把一大堆当前任务用不到的内容塞进上下文。最后 Agent 反而更容易抓错重点。
第二种坏法，是复制工具文档。
比如在 Skill 里长篇解释 git status、npm test、pytest、curl 怎么用。这些东西大多可以由 Agent 自己发现，或者应该交给脚本、README、package scripts、CI 配置处理。自然语言 Skill 应该保留给不能机械化的判断。
第三种坏法，是只有反模式，没有替代方案。
“不要乱改文件。”
“不要跳过测试。”
“不要写太长。”
这些话单独看都对，但只写“不要”很容易让 Agent 锚定在错误动作上，又不知道正确路径是什么。更好的写法是同时给出替代方案：
不要直接改实现。先复现问题，记录可观察现象，再提出假设。
不要把所有细节塞进 SKILL.md。主文件只保留路由和关键判断，长案例放到 references/。
不要只说完成。先运行和任务相关的验证命令，再用验证结果说明完成状态。
第四种坏法，是边界不清。
两个 Skill 如果都像能处理同一个任务，Agent 就会犹豫，或者选错。Skill 的边界应该写在 description 里，而不是藏在正文深处。
所以评估一个 Skill，不只要问它“能不能用”，还要问它有没有制造新的上下文噪声。
什么时候该把 Prompt 升级成 Skill
不是所有 Prompt 都值得变成 Skill。
一次性需求没有必要 Skill 化。还在探索中的偏好也不急着沉淀。只有当一段提示开始反复出现，并且忘记它会导致稳定的质量问题时，才值得考虑升级。
我会用这几个问题判断：
第一，它是不是高频出现？
如果每周都在重复同一类要求，比如写文章、诊断 bug、做代码审查、同步项目文档，那它有可能适合 Skill。
第二，它是不是代表稳定的团队约定？
比如“这个项目所有文档结论要区分事实、计划和猜测”，“修改支付逻辑必须补对账视角”，“发布前必须跑某几个验证命令”。这些不只是个人偏好，而是团队工作方式。
第三，它有没有明确触发边界？
如果你说不清什么时候该用、什么时候不该用，那它还不适合写成 Skill。边界模糊的 Skill 很容易误触发。
第四，它是不是包含判断规则，而不只是命令清单？
命令清单更适合脚本、Makefile、package scripts 或 CI。Skill 适合承载“什么时候该走哪条路”的判断。
第五，它是不是会从版本化中获益？
如果这个工作方式需要被审查、迭代、共享、回滚，那它就更像工程资产，而不是一次聊天里的提醒。
当这些问题的答案大多是“是”，Prompt 就可以升级成 Skill。
从最小 Skill 开始
写 Skill 不应该从设计一个完整体系开始。
更好的方式是从一个真实任务开始。
先选一个你最常重复的工作流，比如“写技术文章”“修 bug”“做 TDD”“同步项目文档”。然后只写最小入口：
1 |
|
正文也先保持短：
1 | # Article Writing |
然后用它做真实任务。
如果 Agent 误触发，就改 description。
如果 Agent 触发后仍然忘记关键边界，就把边界前置。
如果正文越来越长，就把细节拆进 references/。
如果某些步骤可以机械化，就写脚本。
如果某条规则只是你临时想到的，不要急着加进去。等它在真实任务里反复证明有用，再沉淀。
这和写代码有点像。不要一开始就抽象一个庞大的框架。先从一个代表性任务开始，让真实失败告诉你这个 Skill 缺什么。
Skill 让 AI 协作更像工程资产
Prompt 仍然重要。
我们不可能把所有意图都提前写成 Skill。每一次任务仍然需要人说明目标、提供上下文、判断结果。Skill 不是为了取代 Prompt，而是为了让那些稳定、重复、可复用的部分不再每次从零开始。
这也是我觉得“从 Prompt 到 Skill”重要的原因。
它不是提示词技巧的升级，而是工作流抽象的升级。
当我们只写 Prompt 时，AI 协作更像一场场临时对话。对话当然有价值，但它很难沉淀。
当我们开始写 Skill 时，一部分经验会变成可版本化的资产：团队怎么写文章，怎么修 bug，怎么做测试，怎么验证完成，怎么把结论写回文档。
这些东西过去可能藏在资深同事的脑子里，藏在 code review 的评论里，藏在一次次会议和聊天记录里。Skill 把它们转成 Agent 能按需读取的工作上下文。
所以，Agent Skill 不是为了让 AI 替我们判断。
恰恰相反，它是把人的判断边界写得更清楚，让 AI 在这些边界里更稳定地工作。
Prompt 表达这一次我要什么。
Skill 沉淀下一次仍然要遵守什么。
这就是从 Prompt 到 Skill 的那一层抽象。
参考与延伸阅读
- OpenAI Developers, Build skills
- OpenAI API Docs, Skills
- Anthropic, Equipping agents for the real world with Agent Skills
- Agent Skills, Agent Skills Overview
- 本博客：把 AI 放进工作流
OpenAI Developers, Build skills。这里引用的是 Codex Skills 对可复用工作流、渐进式披露、
SKILL.md、scripts/和references/的说明。 ↩︎Anthropic, Equipping agents for the real world with Agent Skills。这里引用的是 Agent Skills 的目录结构、
name/description路由、渐进式披露和按需加载参考文件的设计。 ↩︎