Skills: 多步骤工作流技能
最后更新:2026-08-31
复杂任务不是一步能完成的——多步骤 Skill 就是把"怎么拆、怎么串、出错怎么办"写进流程。
1. 工作流设计原则
(1) 任务拆解
TEXT
📖 仅展示
任务拆解原则
├── 每步有明确的输入和输出
├── 每步可独立验证
├── 步骤间依赖关系清晰
├── 关键步骤有检查点
└── 异常时有回退方案
(2) 步骤类型
| 类型 | 说明 | 示例 |
|---|---|---|
| 顺序步骤 | 必须按序执行 | 先安装依赖再构建 |
| 条件步骤 | 满足条件才执行 | 测试失败时才进入调试 |
| 可选步骤 | 可跳过 | 文档生成 |
| 循环步骤 | 重复执行 | 批量处理文件 |
| 检查点 | 状态确认和快照 | 构建完成后的验证 |
2. 工作流编排
(1) 线性工作流
最简单的顺序执行:
TEXT
📖 仅展示
新功能开发工作流
1. 需求分析 → 输出:需求文档
2. 技术方案 → 输出:设计文档
3. 编码实现 → 输出:源代码
4. 单元测试 → 输出:测试报告
5. 代码审查 → 输出:审查意见
6. 合并部署 → 输出:上线状态
(2) 条件分支工作流
TEXT
📖 仅展示
部署工作流
1. 前置检查
2. 运行测试
3. 条件判断:
- 测试通过 → 继续部署
- 测试失败 → 调试修复 → 回到步骤 2
4. 部署到 staging
5. 健康检查:
- 通过 → 询问是否部署生产
- 失败 → 回滚 + 通知
(3) 并行工作流
TEXT
📖 仅展示
并行任务示例
┌→ 单元测试 ─┐
前置检查 ──┤→ 代码审查 ─┤→ 汇总结果 → 部署
└→ 安全扫描 ─┘
3. 异常处理与恢复
(1) 错误分级
| 级别 | 处理策略 | 示例 |
|---|---|---|
| 🟢 可忽略 | 记录日志,继续执行 | 非关键警告 |
| 🟡 可重试 | 重试 N 次后升级 | 网络超时 |
| 🔴 必须停止 | 回滚到检查点,通知人工 | 数据丢失 |
(2) 检查点机制
MARKDOWN
## 检查点设置
1. 关键步骤前:git commit 保存状态
2. 危险操作前:确认用户意图
3. 不可逆操作前:创建备份
4. 每完成一个阶段:输出进度报告
(3) 中断恢复
MARKDOWN
## 中断恢复流程
1. 读取上次进度记录
2. 确认已完成步骤
3. 从未完成的步骤继续
4. 验证已完成步骤的状态
4. 工作流 Skill 实战
▶ 示例:版本发布工作流
Alice 创建了标准化的版本发布 Skill:
YAML
---
name: release-workflow
description: "版本发布工作流"
triggers:
- keyword: "release|发布版本"
tools:
- Read
- Write
- Edit
- Bash
- Grep
---
MARKDOWN
## 发布流程
1. Bash: git status(确认工作树干净)
2. Bash: npm test(全量测试)
3. Edit: 更新版本号
4. Bash: git tag + git push
5. Write: 生成 CHANGELOG
6. Bash: npm run build
7. Bash: 部署到 staging + 健康检查
8. 确认后部署到 production
Bob 说:"发布最怕漏步——Skill 把流程写死,不可能忘了跑测试就直接上线。"
❓ 常见问题
Q 步骤太多会不会影响性能?
A 会。建议核心步骤不超过 8 个,检查点不超过 3 个。更多步骤建议拆分为多个 Skill 串联。
Q 中断后如何恢复?
A 每个关键步骤输出状态记录(文件或日志),中断后读取记录确定恢复点。
Q 条件分支会不会让流程太复杂?
A 会。建议分支不超过 3 条,嵌套不超过 2 层。更复杂的逻辑考虑拆分为独立 Skill。
📖 小节
- 设计原则:每步有明确 I/O、可验证、有回退方案
- 三种编排:线性、条件分支、并行
- 异常处理:错误分级、检查点机制、中断恢复
- 实践建议:步骤 <8、分支 <3、嵌套 <2
📝 作业
- 基础题(难度⭐):创建一个线性工作流 Skill,实现"测试 → 构建 → 部署"三步流程。
- 进阶题(难度⭐⭐):创建一个条件分支工作流 Skill,测试失败时自动进入调试流程。
- 挑战题(难度⭐⭐⭐):创建一个完整版本发布 Skill,含检查点、异常恢复和回滚机制。