跳到主要内容

主流 AI Coding 工作流

这篇里的“主流”是什么意思​

这里的“主流”不是市场份额榜，而是截至 2026 年 3 月 7 日，官方文档和高频仓库信号里反复出现的交付主线。

它分成两层：

  • 工作流模式：回答任务怎么从问题走到 PR。
  • 工作流框架：回答团队要不要用一套明确方法论把这条链路固定下来。

一张表先看完​

层级名称更适合什么
模式Spec-First新功能、跨模块、需要清晰验收
模式Bugfix / Refactor / Test高频维护任务
模式Issue / Jira -> Draft PRGitHub / Jira 工作系统中的清晰任务
模式Local -> Background -> Cloud先本地探索再异步推进的复杂任务
模式Terminal-First Repo Pairing仓库内强控制协作
模式Parallel Worktrees / Multi-Agent多 lane 长任务
官方框架BMAD多角色、多阶段、完整治理
官方框架Spec Kitspec、plan、tasks 产物链
官方框架OpenSpecbrownfield 与轻量 proposal 管理
社区框架Superpowers面向 coding agents 的日常方法链

先固定哪一条​

如果你当前最痛的是需求跑偏，先固定 Spec-First。

如果你最痛的是高频维护任务波动大，先固定 Bugfix / Refactor / Test。

如果你的团队默认在 GitHub / Jira 里协作，先固定 Issue / Jira -> Draft PR。

如果你已经高频使用 coding agents，但日常节奏仍然很散，再看 Superpowers 这类社区框架。

不要同时做错的三件事​

  • 不要一边没有默认 workflow，一边同时试三个主入口工具。
  • 不要把框架当成规则文件和质量门禁的替代品。
  • 不要一上来选最重方案，再指望团队自然适应。

应该先固定哪一条​

真正更稳的顺序通常是：

  1. 先选默认任务链。
  2. 再选主入口工具。
  3. 最后判断是否要引入框架层。

如果只给一个建议：

  • 个人工程师先固定 bugfix / refactor / test 或 terminal-first
  • 小团队先固定 spec-first
  • GitHub-first 团队优先试 issue -> draft PR
  • 长任务团队再升级到 parallel worktrees / multi-agent

Sources​