---
title: Skill 是方法论，工作流是流程
canonical: "https://xiaofeng.dev/writing/skill-methodology-workflow-process/"
pubDate: 2026-08-29
author: 唐小锋 Xiaofeng TANG
description: "市场上对 Skill 有几种不同的认知。前几天腾讯开发者论坛发了一篇文章，说 Skill 是\"带文档的脚本\"。"
tags: [Agent Skills, Workflow, AI Coding, Methodology]
---

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

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

今年年初 Gemini CLI 的 GitHub 上有一个 issue [#15895](https://github.com/google-gemini/gemini-cli/issues/15895)，对 Skill 给出了一个非常好的定义：**Skill 是方法论，不是脚本加文档。** 这句话非常好地总结了我之前的经验。

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

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

## 工作流：有向无环的黑盒

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

```mermaid
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 是完全的白盒。

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

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

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

```mermaid
flowchart TD
  Start["AI 阅读 Skill 方法论"]
  Start --> Mode1["完整执行"]
  Start --> Mode2["部分提取"]
  Start --> Mode3["用户裁剪"]

  Mode1 --> M1["1 → 2 → 3 → 4<br/>全部执行"]
  Mode2 --> M2["跳过 1、4<br/>只取步骤 2 和 3"]
  Mode3 --> M3["步骤 3 被修改为 3'<br/>按用户指令调整"]
```

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

## 什么时候选哪个

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

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

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

## 对专业使用者：先用后改

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

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

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

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

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

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

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

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

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