Skills 编排工作流：一个 Skill 串起「查 issue → 跑测试 → 提 PR」

你已经会写一个简单的 Skill 了——教 Agent「按某个格式写提交信息」「照某套规范回客诉」。但你心里大概有个疑问：那些要跑好几步的活——查 issue、定位代码、改、跑测试、提 PR——也能写成一个 Skill 吗？还是只能我一步步盯着指挥？

能。这正是 Skill 被低估的地方：一个 SKILL.md 不只能教单步方法，它能在正文里把整条多步流程编排清楚，你一句话触发，它自己从头跑到尾。 这一节我们把「工作流型 Skill」彻底讲透，给你一个能直接抄的模板，再用一个真实的 bug 修复流程走一遍。

这篇适合谁：写过最简单的 SKILL.md、知道它能教方法，但还没把「多步流程」固化成技能的人。读完你能把团队里那些「每次都这么几步」的重复活，变成一句话触发的 skill。

---

先看一个场景：同样的五步，你已经重复二十遍了

想想你修一个线上 bug 的标准动作，是不是每次都这几步：

1. 打开 issue，读清楚现象和复现步骤；
2. 在代码里定位到可能出问题的地方；
3. 改掉它；
4. 跑一遍相关测试，确认没改坏别的；
5. 提一个 PR，标题写清修了啥、关联上那个 issue。

这五步，顺序是固定的，判断标准也是固定的（测试不过就别提 PR、定位不到就先别瞎改）。你已经重复二十遍了，每次还得在对话里一句一句指挥 Agent 走。这种「步骤稳定、判断稳定」的活，就是工作流型 Skill 的主场——把这套流程写进 SKILL.md 正文一次，以后一句「修一下 #123」就全跑完。

---

关键认知：SKILL.md 正文里能写「编排」，不只是「方法」

很多人对 Skill 的印象停在「教一个动作怎么做」。但 SKILL.md 的正文就是一段普通 markdown，你能在里面写有序步骤、写分支判断、写「什么情况下停下来问我」。 Agent 命中这个技能、把正文读进上下文后，会照着这段流程一步步执行——这跟你写一份给新人的 SOP 没区别，只不过读者是 Agent。

所以工作流型 Skill 和单步 Skill 的差别，全在正文怎么写：

• 单步型：正文讲清「这一类活的方法/格式/规范」。
• 工作流型：正文讲清「先做啥、再做啥、每步做到什么算过、什么情况停下来」。

把这点想通，你就明白为什么不需要什么「编排引擎」「流程框架」——编排逻辑就是用自然语言写在正文里的，朴素得很。它属于 Skills 这条「教方法」的路，而不是 MCP 那条「给连接」的路（两条路的根本区别见 给 Agent 加能力的两条路）。

---

最小可用：一个工作流型 SKILL.md 的骨架

先看一个能跑的最小例子，结构看清了再往里填血肉。注意 frontmatter 字段（name / description）以官方文档为准，这里给的是通用写法。

---
name: fix-issue
description: 当用户要求修复某个 issue（如"修一下 #123"）时使用。从读 issue 到提 PR 的完整流程。
---

# 修复 issue 的标准流程

你的任务是修复指定的 issue，并走完到提 PR 为止的全流程。**严格按下面的步骤顺序执行，每一步做完先确认达标再进下一步。**

## 步骤 1：读懂 issue
- 用 `gh issue view <编号>` 读取 issue 正文和评论。
- 提炼出：问题现象、复现步骤、期望行为。
- 如果 issue 信息不足以复现，**停下来**，把缺的信息列给用户，不要猜。

## 步骤 2：定位代码
- 根据现象在代码库里搜索相关函数/文件。
- 锁定最可能出问题的 1-3 处，简短说明你的判断依据。
- 如果完全定位不到，**停下来**说明，别在没把握的地方乱改。

## 步骤 3：修改
- 只改定位到的那几处，改动尽量小、聚焦。
- 每改一处，用一句话说明改了什么、为什么。

## 步骤 4：跑测试（硬门槛）
- 运行相关测试（本项目用 `pnpm test`）。
- **测试不通过就不许进下一步**：要么继续修，要么把失败原因报给用户。
- 测试全绿，才算这步过了。

## 步骤 5：提 PR
- 用 `gh pr create` 提 PR。
- 标题：`fix: <一句话说明>`；正文写清改了什么、怎么验证、`Closes #<编号>`。
- 把 PR 链接发给用户，流程结束。

这就是一个完整、能直接抄的工作流型 Skill。它的精髓不在哪个命令，而在三样东西：有序步骤、每步的达标标准、明确的「何时停」。

---

逐步预期：触发后它该怎么跑

你装好上面这个 skill，在对话里说一句「帮我修一下 #123」，正常情况下 Agent 会这样走（你能逐步看到它的动作）：

1. 命中技能：description 里「修一下 #编号」对上了你的话，Agent 把这段正文读进上下文。
2. 步骤 1 执行：它跑 gh issue view 123，回你一句「现象是导出 CSV 时中文乱码，复现步骤是……期望是 UTF-8 正常显示」。
3. 步骤 2 执行：它搜代码，回「定位到 export.py 的 write_csv，这里没指定编码，默认走了 GBK，应该是它」。
4. 步骤 3 执行：它改 write_csv，加上 encoding="utf-8-sig"，并说明「加 BOM 是为了 Excel 打开不乱码」。
5. 步骤 4 执行：它跑 pnpm test，假设全绿，回「测试 12 个全过」。如果有红的，它会卡在这步——这正是你要的。
6. 步骤 5 执行：它 gh pr create，把 PR 链接发你，标题 fix: 导出 CSV 中文乱码，正文带 Closes #123。

一次触发，五步跑完，你只在它「停下来问」的时候才需要插手。 这就是工作流型 Skill 的价值。

---

增量一：可直接抄的「工作流型 SKILL.md」模板

把上面的例子抽象成一个万能模板，你改改步骤就能用到任何固定流程（周报、数据清洗、发版检查都行）：

---
name: <动词-名词，如 weekly-report>
description: 当用户要求<触发场景，给一两个真实说法>时使用。<一句话说明这条流程干啥>。
---

# <流程名>

你的任务是<最终交付物>。严格按步骤顺序执行，每步达标再进下一步。

## 步骤 1：<拿输入 / 准备>
- <具体动作，能给命令就给命令>
- 达标标准：<什么算这步做完>
- 停止条件：<什么情况下停下来问用户，而不是硬往下走>

## 步骤 2：<处理 / 加工>
- <具体动作>
- 达标标准：…
- 停止条件：…

## 步骤 N：<产出 / 提交>
- <具体动作，写清交付格式>
- 完成后<把结果发给用户 / 留链接>，流程结束。

## 通用约束
- 不确定就停下来问，绝不猜测关键信息。
- 每步做完用一句话汇报，让用户能跟上你走到哪了。

换个场景填一下你就懂了——比如「写周报」：步骤 1 拉本周任务数据（数据从哪来由 MCP 或临时喂入解决），步骤 2 按「已完成/进行中/阻塞」分类汇总，步骤 3 套模板排版，步骤 4 发到指定群。同一套骨架，换血肉而已。

---

增量二：什么活值得固化成工作流 Skill

不是所有多步活都该写成 skill。拿这三条筛一遍，三条都中再动手：

1. 步骤稳定：每次都是这几步、这个顺序，不会今天五步明天八步。
2. 判断稳定：每步「算不算过」有客观标准（测试绿、字数达标、字段齐全），不是每次靠你临场拍脑袋。
3. 重复够多：你已经手动指挥过好几遍，未来还会反复做。一次性的活不值得固化。

反过来，探索型、每次路径都不一样的活（比如「研究一下这个技术方案可不可行」）就别硬塞进固定流程——那种活的价值恰恰在随机应变，写死步骤反而碍事。

---

避坑表

坑	后果	怎么破
步骤之间没说清「何时停」	它定位不到也硬改、测试红了也提 PR	每个关键步骤写明确的「停止条件」
把判断标准写得含糊（如"测得差不多"）	每次执行松紧不一，质量飘	给客观达标标准：测试全绿、字数≤500
一个 skill 塞进两条不相干的流程	description 命中混乱，触发错流程	一条流程一个 skill，名字对应清晰
步骤里写死某工具特有命令	换工具/换项目就跑不通	命令可参数化或在正文标明「本项目用 X」
探索型活也硬编成固定流程	该随机应变时被步骤捆死	只固化「步骤稳定+判断稳定」的活
不让它每步汇报	中途出错你发现不了、没法及时拦	正文要求「每步用一句话汇报进度」

---

动手挑战

1. 挑一件你最近手动指挥 Agent 走过三遍以上的多步活（修 bug、发周报、整理数据都行），用上面的模板把它写成一个工作流型 SKILL.md，重点写清每步的「达标标准」和「停止条件」。
2. 故意制造一个「中间步骤失败」的情况（比如让测试挂掉），看你的 skill 是不是真的会卡在那一步停下来，而不是硬往下跑。这一步最能检验你的「何时停」写得够不够硬。
3. 把同一个 skill 的某一步「判断标准」从含糊（"看着差不多"）改成客观（"必须测试全绿"），对比前后两次执行的稳定性差别。

---

小结 · 你现在掌握了什么

• 你看清了 Skill 不只能教单步方法，正文里能写有序步骤、分支判断、何时停，一次触发跑完整条多步流程——编排逻辑就是自然语言，不需要额外框架。
• 你手上有一个可直接抄的工作流型 SKILL.md 模板，换血肉就能套到周报、数据清洗、发版检查等任何固定流程。
• 你会用「步骤稳定 + 判断稳定 + 重复够多」三条筛子，判断一个活该不该固化成 skill。
• 你知道工作流 Skill 的命脉是每步的达标标准和明确的停止条件，写糊了它就会跳步、卡死或乱跑。

下一步：流程能跑了，再看怎么让它跨工具、跨团队复用——这正是下一节「Skills 可移植与团队共享」要讲的。想看整条路的位置就对照 三支柱路线图，或回到 AI Agent 智能体阶梯 看本级其他节。

👉 看看 AI 数字员工落地指南，或了解 数字员工搭建实战课。需要为企业落地方案，欢迎找我们聊 企业服务。