上一篇讲了 Claude Code 的 workflow。但几乎所有人第一反应都是：这不就是 skill 吗？ 不是。这俩是 Claude Code 里最容易搞混的两个概念，混了的后果是------该用 skill 的你写成了 workflow（重得要命），该用 workflow 的你硬塞进一个 skill（流程全靠运气）。这一篇把这条线彻底划清。
一、一句话区分：skill 是「招式」，workflow 是「套路」
先用个比喻：
- skill 像武功里的单个招式------「这一招出拳要怎么发力、脚步怎么站」，把一个动作的标准做法写清楚。
- workflow 像套路 ------「第一招接第二招、什么时候攻什么时候守」，把一串招式的编排顺序定下来。
落到 Claude Code：
- skill 回答的是「这件事怎么做才对」 ------它是一个
SKILL.md，里面写清楚触发词、正确做法、有哪些坑、红线是什么。模型遇到这类事，照着做。 - workflow 回答的是「这几件事按什么顺序、由谁接力做」------它是一个编排脚本，定义了阶段、阶段里起几个 agent、agent 之间怎么传结果。
核心区别一句话：skill 管「单点怎么做」，workflow 管「多点怎么流转」。
二、从 5 个维度把区别钉死
光一句话不够，用一张表把区别钉死：
| 维度 | skill | workflow |
|---|---|---|
| 本质 | 一份「做事指南」（SKILL.md + 脚本/参考） | 一个「编排脚本」（流程 + agent 分工） |
| 解决问题 | 这件事的正确做法、坑、红线 | 多步骤/多 agent 的顺序与协作 |
| 谁来跑 | 模型读了指南后自己判断执行 | 脚本按固定流程驱动 agent 执行 |
| 确定性 | 弱------模型理解后自由发挥 | 强------流程写死，乱不了 |
| 典型粒度 | 一件事（写 PRD、配图、加标注） | 一套流程（审核→发布→归档） |
最关键的一行是「谁来跑」：skill 是「模型理解了去做」，workflow 是「脚本控制着去做」。 这决定了它们的确定性完全不同。
三、为什么这层区别很重要（混用的代价）
搞混了会怎么样？两个方向的坑我都见过：
坑 1：把流程硬塞进 skill。 有人想让 skill「既管怎么做、又管流程顺序」，于是在 SKILL.md 里写「第一步做 A、第二步做 B、做完 B 再做 C」。结果呢？skill 靠模型自觉执行，模型哪天理解偏了，顺序就乱了------它没有强制力。你想保证顺序，就该用 workflow，别指望模型「每次都记得」。
坑 2：用 workflow 做一件小事。 反过来，有人听说 workflow 很强大，给「写一篇文章」这种单点任务也写个编排脚本。这就像为了「出个拳」专门编一套套路------杀鸡用牛刀，维护成本远超收益。
一句话：单点的事用 skill，要保序的多步流程才用 workflow。
四、判断该用谁：三问法
遇到一个需求，按这三问判断：
第 1 问：这是「一件事」还是「一串事」？ → 一件事（写完就完）→ skill；一串要接力的 → 往下问。
第 2 问：这串事的「顺序」重要吗、需要强制吗？ → 顺序可灵活、靠模型判断就行 → 还是 skill（在 SKILL.md 里写「先做 A 再做 B」的软指引）； → 顺序必须严格、不能乱、要并行/验证 → workflow。
第 3 问：重复频率高吗？ → 高频重复 → 值得固化（skill 或 workflow 都行）；偶尔一次 → 两个都别做，直接对话干。
把这三问画成决策树：
scss
需求来了
├─ 偶尔做一次? ──是──→ 直接对话,别固化
└─ 高频重复
├─ 单件事 ──────→ skill
└─ 多步流程
├─ 顺序可靠模型自觉 → skill(SKILL.md 写软指引)
└─ 顺序必须强制/要并行 → workflow
五、它们不是二选一，是配合关系
最容易被忽略的一点：skill 和 workflow 不是互斥的，经常是配合的。
workflow 负责「流转」，但每个环节里「具体怎么做」，往往还是调 skill。比如一套「内容发布 workflow」：
workflow 内容发布:
阶段1 审核 → 调「审核 skill」的做法
阶段2 配图 → 调「配图 skill」的做法
阶段3 发布 → 调「发布 skill」的做法workflow 定「先审核、再配图、再发布」这个骨架 ；每个环节点进去，具体怎么审、怎么配图、怎么发，是各自 skill 里写的血肉。
workflow 是骨架，skill 是血肉。 一个健康的自动化体系，往往是「少量 workflow 定流转 + 一批 skill 管单点」。
六、写在最后
把这条线记住：
- skill = 单件事的正确做法（管「怎么做」，模型自觉执行）
- workflow = 多步流程的编排（管「怎么流转」，脚本强制驱动）
判断用谁，就问自己：这是一件事还是一串事？顺序需要强制吗？ 一件事用 skill，要强制保序的多步流程才上 workflow。
而且它们不打架------workflow 搭骨架，skill 填血肉，配合着用才是完整形态。
那问题来了：我自己的内容发布，流程也是「审核→配图→发布」多步接力，按理该用 workflow------但我偏偏没用，而是用「skill + 状态机」实现的。 为什么？这里面有一个很实际的取舍。下一篇《我们的案例为什么没选择 workflow 而是 skill+状态机》讲我的真实考量。
这篇帮你分清了 workflow 和 skill 吗？欢迎关注 看系列下一篇；你在实际里有没有把这两者用混过的经历，评论 聊聊；觉得有用就收藏备用。