Skill 是方法论，工作流是流程

市场上对 Skill 有几种不同的认知。前几天腾讯开发者论坛发了一篇文章，说 Skill 是"带文档的脚本"。

但根据我的经验，这个定义太窄了。

今年年初 Gemini CLI 的 GitHub 上有一个 issue #15895，对 Skill 给出了一个非常好的定义：Skill 是方法论，不是脚本加文档。 这句话非常好地总结了我之前的经验。

我在 Dify 和扣子上都开发过工作流，也深度使用过各种 Skill。从实际使用的角度来说，它们之间有许多使用上不能忽视的区别：

维度	工作流（Workflow）	Skill
本质	流程	方法论
AI 视角	黑盒（只看到单节点）	白盒（全貌可见）
灵活性	固化，不可逃逸	可裁剪、可干预
维护	节点多时困难	按需加载，轻量
AI 角色	语义工具（局部调用）	全局编排者

工作流：有向无环的黑盒

工作流是一个带有明确流程限制的有向无环图（DAG），它意味着：不能从一个节点在没有路径或连接线的情况下直接跳到另一个节点，必须沿着预设的流程走。

flowchart TD Start([开始]) --> CondA{条件判断 A} Start --> CondB{条件判断 B} CondA --> ExecA1[执行节点 A1] CondB --> ExecB1[执行节点 B1] ExecA1 --> Merge[合并结果] ExecB1 --> Merge Merge -.->|禁止回边| CondA

对绝大多数用户来说，工作流是一个黑盒。你感觉不到它到底是 10 个节点、20 个节点还是上百个节点——只有开发者才需要关心这些。用户只管用，但很难了解内部到底有哪些流程、哪些异常分支、哪些地方需要人工介入。

优点是流程固化。 用户不会从流程中逃逸出去，可以得到确定性的结论，不会出现完全异常、无法控制的结果。

缺点也很明显。

当工作流超过几十个甚至上百个节点时，维护起来会非常困难。
工作流天然需要脚本作为粘合剂，把节点的输入输出对接起来——上一个节点的输出就是下一个节点的输入，中间有大量的胶水代码。
AI 在工作流中的作用，只是其中某几个需要智能判断的关键节点，没有承担整个流程的规划，也没有总揽全局，仅仅作为一个语义工具被调用。

Skill：白盒的方法论

Skill 会被加载到 AI 的提示词中。AI 先阅读 Skill，然后按照 Skill 来执行相应的步骤。它知道整个 Skill 从开始到结束会经过哪些流程、有哪些步骤，知道哪些地方需要用户确认、哪些地方允许用户选择，甚至知道怎么让用户退出，以及如何把步骤交接给下一个 Skill。

对 AI 来说，工作流是黑盒的，它只能看到一个节点；但 Skill 是完全的白盒。

flowchart TD AI2["AI · 加载、编排、调度"] subgraph Skill["Skill 方法论 · 全部可见"] direction LR S1["步骤1 读取需求"] --> S2["步骤2 分析数据"] --> S3["步骤3 生成方案"] --> S4["步骤4 交付结果"] --> S5["步骤5 沉淀复盘"] end AI2 -.->|"加载"| Skill

因为 AI 看到的是完整的方法论，而不是单个节点，所以它可以灵活地选择执行方式：

完整执行：按步骤 1→2→3→4 走完
部分提取：只取其中一两个步骤，跳过不需要的环节
用户裁剪：按用户指令修改某一步骤，调整后再继续

flowchart TD Start["AI 阅读 Skill 方法论"] Start --> Mode1["完整执行"] Start --> Mode2["部分提取"] Start --> Mode3["用户裁剪"] Mode1 --> M1["1 → 2 → 3 → 4 全部执行"] Mode2 --> M2["跳过 1、4 只取步骤 2 和 3"] Mode3 --> M3["步骤 3 被修改为 3' 按用户指令调整"]

这种灵活性就是方法论的本质：它是一套经验性的指导原则，让你学习并可选择性地使用它。

什么时候选哪个

当你作为一个开发者或者专业用户，需要写 Skill 或流程的时候，你要先判断：这是一个方法论，还是一个流程？

这个问题的核心区分是控制权归谁：

需要确定性、自上而下管控的场景（公司审批链路、数据处理管道、固定业务流程）——工作流更合适。流程固化的价值在于，不需要使用者做选择，也不会有人从流程中逃逸。
面向个人或团队效率提升的场景——Skill 更合适。因为很多时候我们不能强迫别人，方法论的意义在于让专业用户理解后自愿遵循，而不是被流程绑住。

对专业使用者：先用后改

Skill 的使用者通常是或者说“需要是”专业用户。这和工作流的使用者有本质区别——工作流不需要你理解，你只要照着走就行；但 Skill 的使用者需要理解方法论，才能用好它、改好它。

如果你拿到了别人写的 Skill，首先当然可以用它来完成工作。但更重要的是：

你可以选择忽略或修改 Skill 中的某些步骤，干预它，让它按照你的想法执行。
你可以裁剪 Skill，把它改成你想要的版本。 市场上大部分 Skill 都代表了作者个人的见解和经验。如果你想让它完美符合你个性化的工作流，你需要对原来的 Skill 进行修改，发明自己的 Skill。这是方法论的终局——不是照搬，而是内化后重造。

还有一个隐含的因素：你需要让 Skill 反过来教会你这套方法论。 Skill 的使用者需要了解这个 Skill 是怎么用的，才能真正驾驭它。

一个值得注意的趋势：让 AI 参与全流程

之前我聊到过 Compound Engineering 这个插件，它做了一件非常激进的事：把子智能体（sub-agent）的调用完全改成了纯粹的 Skill markdown。

其中有一个重要的理由：调用子智能体时，某些上下文、工具调用结果或 harness 的结果无法传递到子智能体，而且各家平台对智能体的实现方式也不统一。子智能体本质上是把 AI 关进了一个个黑盒，彼此看不到对方的上下文。

与其费力解决跨智能体的信息传递，不如让所有智能体都变成 Skill 的模式——这样可以直接复用完整的上下文和 harness 结果，模型在整个流程中的表现会更加优异。

这背后其实就是白盒的红利：打开可见度，AI 看到的信息越完整，表现就越好。 子智能体的调用模式相当于把流程重新切成黑盒节点，而 Skill 模式把整个方法论和全部上下文都暴露给 AI，让它在完整可见的基础上做判断和调度。这个过程中，Skill 是一本经验性的手册，初期可以发挥作用，在更加长程的任务中，让它自己判断，比经验更重要。