一句话定位#
workflow 负责回答：如何把一次需求，从“对话”变成“可交付”，并且可控、可复查、可复用？
ClaudeCode workflow 可以理解为一种 可组合、可复用、带流程控制的提示编排机制：
- 不是单条 prompt 的“一锤子”调用
- 而是把任务拆成阶段、固化阶段产物、设置门禁点（gates）、并把状态落到文件里
为什么“单条 Prompt”不够#
当你把一次工程任务压缩成一段 prompt，常见会发生：
- 需求/约束缺失：模型会补全细节，容易“自由发挥”，结果不可预期。
- 修改不可控：一次性改太多文件，缺乏边界与回滚路径。
- 缺少验收标准：没有明确的 Done 定义，输出很难被验证。
- 缺少验证：没跑测试、没自检、没评审，容易把 bug 带进主分支。
- 上下文会爆：长对话里状态漂移，关键约束被遗忘。
工作流的价值，就是把这些失败模式系统性“堵住”。
Workflow 的基本构件#
| 构件 | 目的 | 典型形式 |
|---|---|---|
| Stages / Phases（阶段） | 把任务拆成可管理的步骤，降低一次性决策压力 | Research / Plan / Execute / Review |
| Artifacts（阶段产物） | 让每阶段都有“可验收输出”，减少空谈 | 计划、变更清单、测试证据、风险点 |
| Gates（门禁点） | 在关键节点强制停下来检查/确认，避免一路跑偏 | 人工确认、测试必须通过、独立审查 |
| State（状态） | 让状态可跨会话、可追溯、可并行，避免全靠对话记忆 | 文件化状态：issues/plan/spec 等 |
这四个元素组合起来，才是“编排”，而不仅是“提示”。
与 rules / skills / commands 的分工#
workflow 不是要取代 rules/skills/commands，而是把它们编排成闭环：
| 组件 | 解决的问题 | 作用方式 | 入口 |
|---|---|---|---|
rules | 底线与边界：安全、变更控制、工程验证 | 永远生效的约束 | 平台/仓库级 |
skills | 某类任务 SOP：怎么做、做到什么程度算完成 | 按需加载的流程说明 | 模型自动/用户触发 |
commands | 显式入口：你希望“这次就是按这个流程走” | 用户触发、确定性启动 | /command |
workflow | 端到端交付闭环：把阶段、产物、门禁、状态串起来 | 编排与流程控制 | 方法论/体系 |
一个实用的默认原则是：
- Rules 保持短、硬、可执行
- Skills 负责细流程与成功标准（SOP）
- Commands 负责启动入口（手感）
- Workflow 负责闭环与控制面（让输出变成可交付）
最小可用闭环（Minimal Viable Workflow）#
把复杂度压到最低，一个可落地的最小闭环是：
1) Research（研究）#
- 输入：目标、现状、约束、失败代价。
- 产物：入口点/关键文件定位、风险清单、未知项列表。
- 门禁：当存在关键未知项（需求/边界/验收）时必须停下来问你。
2) Plan（计划）#
- 输入：研究结论与约束。
- 产物：可执行的改动清单（文件/函数/逻辑概要）、验证步骤、回滚方案。
- 门禁：计划必须得到你确认后才能进入执行（避免“先干了再解释”）。
3) Execute（执行）#
- 输入：已确认的计划。
- 产物：小步、可审查的变更（patch/diff），必要时拆成多次提交。
- 门禁：遇到超出计划范围的改动，必须回到 Plan 更新并再确认。
4) Review（评审）#
- 输入：变更与验证结果。
- 产物：自检报告（变更点、风险、测试证据）、待办/后续建议。
- 门禁：未满足验收标准不应收尾；必要时回到 Execute 迭代修复。
“可控”的关键：把状态落到文件里#
工作流一旦变长，只靠对话记忆会退化。
更稳妥的方式是：把关键状态写入仓库文件，让它成为“第二记忆”，支持：
- 跨会话继续
- 多人协作可追溯
- 多 Agent/多模型并行时通过文件交接
你可以采用非常轻量的约定：
./issues/<task>.md：记录目标、约束、计划、验证、结论
升级路径：从单人闭环到多 Agent/多模型#
当任务足够复杂时，workflow 通常会从“线性闭环”升级为“角色分工 + 文件交接”的编排：
- Planner：只产出计划与验收，不写代码
- Implementer：严格按计划改动，小步提交
- Reviewer/Tester：独立审查与验证，提出修复项
更进一步的多模型协作与工程化实践，可以参考站内汇总：
一页检查清单（建议每次收尾前过一遍）#
- 目标是否可验证：是否有明确验收标准（功能/性能/行为）
- 阶段产物是否齐全：是否有计划、变更清单、测试证据
- 门禁是否执行：关键节点是否停下来确认，而不是一路“自动驾驶”
- 变更是否可控：是否小步、可审查、可回滚
- 风险是否显式：是否列出潜在破坏面与回滚方案