跳到主要内容

AI 工作流

这页不是“工作流总表”，而是工作流分流器。目标只有一个：把你尽快送进正确的 runbook，而不是让你先在框架名和术语里打转。

现在先做什么​

先按任务选默认主线​

先把当前任务跑起来

如果你当前缺的是一条可执行主线，先选 runbook；不要一上来就看框架、方法论或术语总览。

如果主线已经跑通，再看家族分层​

三类工作流对象怎么分

不要一上来就看框架名。先判断你缺的是默认交付链、制度骨架，还是 daily execution 方法。

工作流家族先解决什么问题先读哪一页
工作流模式先固定任务的默认交付链，再决定具体用哪套框架或工具。Spec-First
官方/主线工作流框架这些方案本身就定义了角色、阶段、产物或提案链，适合作为团队制度骨架。BMAD
社区工作流框架这类框架不是单页 prompt 集，而是已经形成阶段、技能、worktree 和验证方法的社区方案。Superpowers

从这里直接进入具体工作流簇​

每个工作流簇都该回到可执行页

进入任一工作流簇后，优先读概览页和 runbook，再决定是否补治理、案例和工具组合。

工作流模式

Spec-First

先把目标、非目标、验收和任务拆解写清，再让 agent 执行，是新功能和跨模块改动的默认主线。

  • 触发信号：需求边界模糊，稍不注意就会在实现阶段扩边界。
  • 默认产物：spec 草稿
  • 默认入口：Spec Kit
工作流模式

Bugfix / Refactor / Test

把最高频的修 bug、局部重构和补测试固定成最小闭环，让 agent 先复现、再说明根因、最后给证据。

  • 触发信号：问题可复现，或者至少能通过日志、快照、断言定位。
  • 默认产物：repro note
  • 默认入口：Claude Code
工作流模式

Issue / Jira -> Draft PR

把已经进入 GitHub 或 Jira 的清晰任务交给 agent 异步推进，最后以 draft PR 形式回到人工 review。

  • 触发信号：任务目标、验收标准、允许修改的目录都能写进 issue。
  • 默认产物：ready issue
  • 默认入口：GitHub Copilot
工作流模式

Local -> Background -> Cloud

先在本地摸清问题和边界，再把可执行部分交给后台 agent，最后在云端或 PR 系统里收口，是复杂任务的稳妥分层。

  • 触发信号：本地探索和后台执行各有价值，单一入口承担全部工作会很笨重。
  • 默认产物：discovery brief
  • 默认入口：VS Code Agents
工作流模式

Terminal-First Repo Pairing

把 agent 当成仓库里的搭档，而不是网页聊天框：围绕规则文件、命令执行、diff 审阅和验证闭环工作。

  • 触发信号：仓库已有构建、测试、脚本或 codemod 回路。
  • 默认产物：task contract
  • 默认入口：Claude Code
工作流模式

Parallel Worktrees / Multi-Agent

把长任务拆成多个低耦合子任务，在独立 worktree 或独立 agent 会话中并行推进，再由 owner 收口 review。

  • 触发信号：任务可拆成多个互不踩脚的 lane，每条 lane 都有独立验证方式。
  • 默认产物：task map
  • 默认入口：OpenAI Codex
官方/主线工作流框架

BMAD

BMAD 更像团队级交付骨架：用多角色、多阶段和明确 handoff 组织完整的软件交付，而不是只给一个 spec 模板。

  • 默认进入方式：先在一个中等复杂度、至少跨两个阶段的任务里试跑，而不是拿最小 bug 或最大平台重构做第一次试点。
  • 更适合：单个任务经常跨多个阶段，且需要不同角色或职责面参与。
  • 补位方式：Spec-First
官方/主线工作流框架

Spec Kit

Spec Kit 更像规格与计划产物链：用 spec、plan、tasks 先把需求和实施拆开，再交给 agent 或工程师执行。

  • 默认进入方式：先挑一个本来就需要设计与实现分开的新功能，验证 spec -> plan -> tasks 是否能减少返工。
  • 更适合：需求经常在实现阶段漂移，导致 review 只剩“补需求”。
  • 补位方式：Spec-First
官方/主线工作流框架

OpenSpec

OpenSpec 更像轻量变更管理层：用 proposal、change 和 archive 管理 brownfield 项目的高频改动，不强行引入太重流程。

  • 默认进入方式：从高频的现有项目迭代开始，先验证 OpenSpec 是否比完整 spec 链更贴近真实成本。
  • 更适合：团队高频处理小功能、增量优化、兼容调整和迭代型改动。
  • 补位方式：Bugfix / Refactor / Test
社区工作流框架

Superpowers

Superpowers 是面向 coding agents 的社区工作流框架：把 brainstorming、worktree、plan、subagent、TDD 和 review 串成一条日常执行方法链。

  • 默认进入方式：在一个已有 repo 规则和固定验证命令的仓库里试跑，让 Superpowers 先叠加在现有工具之上，而不是替代全部治理。
  • 更适合：团队已经熟悉 coding agents，但产出波动仍然很大，缺少统一套路。
  • 补位方式：Terminal-First Repo Pairing

推荐阅读顺序​

推荐阅读顺序

第一次建设团队级 AI 工作流时，建议按这个顺序从可执行主线回到制度层。

先跑一条 runbook 主线

先让一个真实任务跑起来，再决定你缺的是模式、框架还是方法层。

再回到工作流概览

概览页负责做分流，不负责替代 runbook 和案例。

需要制度骨架时再看框架层

当 handoff、角色和产物总是乱，再引入更重的框架。

最后回到案例和 playbook

把模式和框架转成日常执行方法，避免只停留在概念层。