工作流：把多步任务串成一条流水线
提示词解决「一次问对」，工作流解决「每次都对」。当你发现自己在反复粘贴同一段要求、每次都手动检查同样的几件事，这段流程就该被固定下来。本章讲清三件事：什么算「可重复的多步流程」、怎样用自然语言把步骤讲明白、以及什么阶段该把它固化成 Skill 或脚本。
什么算可重复的多步流程
不是所有任务都值得做成工作流。判据是「发生频率」和「步骤稳定性」，两个都高才值得固化。
| 特征 | 值得做工作流 | 不值得做 |
|---|---|---|
| 频率 | 每周至少两次 | 一年一次 |
| 步骤 | 顺序基本固定，可写成清单 | 每次做法都不一样 |
| 输入 | 输入类型固定（一个 diff、一张表、一份需求） | 输入形态飘忽 |
| 输出 | 有明确产物与验收标准 | 只要个感觉 |
工作流的三段式：步骤 → 检查点 → 输出物
写工作流的本质，是把「你想让它怎么干」翻译成一张有三列的清单。
| 组成 | 作用 | 写法要求 |
|---|---|---|
| 步骤 | 说明先做什么后做什么 | 用动词开头，一步只做一件事 |
| 检查点 | 明确哪里必须停下来等确认 | 写清「停下来时要给我什么」 |
| 输出物 | 明确最后交付什么 | 写明格式、文件名、字段名 |
【任务】把本周的需求文档整理成一份可评审的研发交底清单。
【输入】docs/requirements/ 下本周新增的 Markdown 文件。
【步骤】
1. 逐个读完输入文件，提取：需求点、验收标准、依赖项、未决问题；
2. 输出一张表：需求点 | 验收标准 | 依赖 | 未决问题 | 我判断的风险等级；
3. 把「未决问题」单独汇总成一段清单，每条附上原文出处（文件名 + 小节名）。
【检查点】
- 第 1 步结束后先停：把提取到的需求点列表发我确认，我确认后再进入第 2 步；
- 遇到无法判断的内容，写「需人工确认」，不要自己编一个答案填上。
【输出物】
- 表格以 Markdown 输出，直接回复在对话里；
- 同时写一份文件 docs/review/交底清单.md，内容与表格一致。
【禁止】
- 不要修改 docs/requirements/ 下的任何原文件。
人机分工：AI 做草稿，你做决策
分工不清是工作流失败的头号原因：要么人累成保姆，要么把决定权交了出去。
| 环节 | AI 负责 | 你负责 |
|---|---|---|
| 收集与整理 | 读文件、抽取字段、去重、归类 | 确认范围与取舍 |
| 分析与草稿 | 生成初稿、列选项、给风险等级 | 判断哪些结论成立 |
| 决策 | 提供依据与备选方案 | 拍板，并对结果负责 |
| 执行 | 生成脚本、跑只读命令 | 批准写入、删除、上线 |
| 验收 | 自查清单、指出不确定项 | 最终验收与留档 |
一句话标准：凡是产生不可逆后果的动作，都必须有人点头。
检查点怎么设
检查点不是「每步都停」，那样人比自己做还累。只在这三类位置停：
| 检查点类型 | 什么时候停 | 停下时要什么 |
|---|---|---|
| 范围确认点 | 分析完成、动手之前 | 影响面清单：会改哪些文件、哪些库、哪些接口 |
| 不可逆点 | 删除、覆盖、写入生产、提交推送之前 | 变更清单 + 回滚办法 |
| 质量门槛点 | 草稿完成、提交评审之前 | 自查清单 + 不确定项列表 |
一段可以直接抄进任何工作流的收尾要求：
收尾时统一给出三样东西：
1) 你做了什么：按步骤列出，每步一句话，并标明用了哪些输入文件；
2) 你不确定什么：列出你拿不准的判断，说明为什么拿不准，不要用模糊语气掩盖；
3) 你需要我做什么：列出需要我确认或补信息的具体事项，最多 5 条，按重要性排序。
从提示词到 Skill，再到脚本
按「重复程度」升级，不要一上来就写代码。
| 阶段 | 形态 | 适合 | 优点 | 缺点 |
|---|---|---|---|---|
| 第一次 | 聊天里手写提示词 | 探索做法 | 灵活 | 每次都要重写 |
| 稳定后 | 存成提示词模板或 Skill | 每周复用 | 一句调用，规则统一 | 仍需人盯检查点 |
| 完全确定 | 固化成脚本/命令 | 步骤机械、输入规范 | 可定时、可无人值守 | 变更成本高 |
Skill 的最小写法就是「什么时候用 + 要什么输入 + 分几步 + 检查点 + 输出什么」，把上面那段结构化提示词原样存下来即可：
名称：需求转交底清单
适用：需要把需求文档整理成研发可评审清单时
输入：需求文档目录路径
步骤：提取 → 列表确认 → 生成表格 → 汇总未决问题
检查点：提取后先确认需求点列表；不确定项写「需人工确认」
输出：对话里的表格 + docs/review/交底清单.md
同一套规则要反复跑十几次、输入输出都固定时，再改写成脚本：
#!/usr/bin/env bash
set -euo pipefail
IN_DIR="${1:?用法: run.sh <需求目录>}"
OUT="docs/review/交底清单.md"
mkdir -p "$(dirname "$OUT")"
{
echo "# 需求交底清单（自动生成）"
echo
echo "生成时间: $(date '+%Y-%m-%d %H:%M:%S')"
echo
echo "输入文件:"
find "$IN_DIR" -name '*.md' -type f | sort
} > "$OUT"
echo "已生成骨架: $OUT"
失败重试与人工兜底
工作流一定会失败，区别只在「失败后你知不知道」。
| 失败类型 | 表现 | 处理 |
|---|---|---|
| 输入不合格 | 文件缺失、格式不对 | 前置校验，缺少就停下并报出缺什么 |
| 输出不达标 | 字段缺、格式乱 | 重试一次并明确说出上次哪里不合规，仍不行转人工 |
| 工具报错 | 超时、连接失败、权限拒绝 | 有限重试（建议 2 次）+ 退避，仍失败则告警 |
| 模型判断错 | 结论看起来合理但不对 | 关键结论必须有第二来源或人工复核 |
如果任何一步失败，最多重试 2 次；每次重试前先说明失败原因和你这次换了什么做法。
两次都失败就停下，输出：失败的步骤、原始错误信息全文、你已经排除的可能原因、
你建议的下一步。不要为了「完成任务」而跳步或伪造结果。
常见坑
| 坑 | 后果 | 规避 |
|---|---|---|
| 步骤写成一句「帮我整理一下」 | 每次结果都不一样 | 拆成动词开头的编号步骤 |
| 检查点设得太密 | 人比自己做还累 | 只在范围、不可逆、质量门槛处停 |
| 没写输出物格式 | 结果无法验收 | 写明字段、文件名、存放路径 |
| 失败就默默跳过 | 交付物缺内容还看不出来 | 失败必须显式报告 |
小结：工作流的价值在于把「每次都要重新交代」变成「每次都一样」，做法是用步骤、检查点、输出物三段式把流程写清，人只在范围确认、不可逆动作、质量门槛三处介入；稳定后再固化成 Skill，机械到不用判断时再写成脚本。