[research@ai4se] : ~ $ ▌
cd ../
[process] | | 18 min

# AI Development Workflows 全景：从五步骨架到企业交付闭环

主流 AI 开发工作流收敛于 Research→Plan→Execute→Review→Ship——成熟实践是规格有来源、执行有纪律、评审有独立性、发布有门禁。

[workflow-design][process]

Claude Code、Codex CLI、Gemini CLI 三个 best-practice 生态在 Development Workflows 上出现高度收敛：主流 AI 开发工作流都在向同一骨架靠拢：

Research → Plan → Execute → Review → Ship

意义不是机械执行五步，而是把 AI 开发从「单次 prompt 写代码」升级为可追踪、可验证、可审计的交付闭环。

三层循环组合

层级核心问题关键实践
Middle LoopAI 该做什么、看什么、遵守什么边界？OpenSpec/Spec Kit、Context Pack、Plan Mode、权限与 hooks
Inner LoopAI 如何小步、可靠地改代码？TDD、worktree、subagent、systematic debugging
Outer LoopAI 代码如何进入组织交付系统？PR、CI/CD、SAST、E2E、DORA 度量

参见 Inner / Middle / Outer Loop 与 Loop Engineering。

五步骨架详解

阶段本质问题常见产物
Research系统是什么？需求与约束？代码库调查、Context Pack、风险扫描
Plan怎么做？怎样证明做完？计划、验收标准、测试策略
Execute如何小步实现并控制漂移？小 PR、TDD、worktree、phase handoff
Review结果是否正确、安全、可维护？code review、QA 报告、独立 evaluator
Ship如何进入交付系统并回流经验？PR、CI/CD、changelog、retro、metrics

Workflow 最小单位正从 prompt 模板升级为流程资产 — 有入口、状态、产物、检查点、退出条件。Superpowers 封装 TDD/review skills；OpenSpec/Spec Kit 版本化 spec artifacts；gstack 显式化专家 gears；GSD 用 fresh-context subagents 抗 context rot。

企业参考模型：0+6 阶段

0. Policy & Routing     → 工具 tier、数据边界、human gate
1. Research & Spec      → 意图、约束、验收标准
2. Plan & Contract      → 任务拆分、done、风险、rollback
3. Execute in Batches   → TDD、worktree、小 PR
4. Independent Review   → CR、运行时测试、QA、安全
5. Ship                 → PR、CI/CD、监控、回滚
6. Archive & Improve    → sync specs、更新 skills、度量

本体分类：先问「它是什么」

直接按五步阶段分类会混淆 OpenSpec、GSD、gstack 等横跨多阶段的项目。应按 primary ontology 归类：

本体类别判定代表项目
Workflow Method Framework定义完整方法、阶段、产物、门禁Spec Kit, OpenSpec, BMAD, GSD, Superpowers, gstack, HumanLayer
Workflow Capability / Skill Collection可复用 building blocks，不强制唯一 E2E 方法Matt Pocock Skills, agent-skills
Runtime Harness Pack增强特定 runtime 的配置与编排ECC, oh-my-claudecode, oh-my-codex

边界： Claude Code、Codex、Cursor 是 Agent Runtime，不是 workflow 方法；MCP、GitHub Actions、Playwright 是 基础设施，支撑但不规定完整方法。

主流 Workflow 项目速览

项目Workflow 概要本体
Superpowersbrainstorming → plans → TDD → review → verification工程纪律型框架
Spec Kitconstitution → specify → plan → tasks → implementSDD 标准型
OpenSpecpropose → apply → verify → archiveBrownfield 变更型
GSDdiscuss → plan → execute → verify → ship执行编排 + context 工程
gstackplan reviews → qa → ship → retro专家角色型
BMADPM/Architect/Dev/UX/QA 多角色敏捷角色分工型

完整 SDD 对比见 SDD 工具横向对比。

选型五问

问题若答案是「是」优先考虑
需求/验收边界不清？先结构化意图Spec Kit / OpenSpec / BMAD
Agent 经常跑偏、跳测试？强化执行纪律Superpowers / GSD
缺少产品/设计/QA 视角挑战？显式专家审查gstack / BMAD
已选定 runtime？适配原生命令/hooksECC / AGENTS.md / CLAUDE.md
必须进入企业发布链？接入 CI/CD 与度量Actions / Playwright / DORA

常见场景组合

场景推荐组合
低风险小修Runtime plan + targeted verification
Brownfield featureOpenSpec/Spec Kit + Superpowers TDD + CI gate
UI / full-stackSpec + design review + Playwright evidence
长时程迁移GSD phase graph + worktree + batched PRs
高风险变更Spec + human gate + security review + rollback plan

工具链分层实践见 OpenSpec + Superpowers + gstack 与 GStack + GSD + Superpowers。

子循环才是难点

AI 开发风险通常不在 happy path，而在子循环：

  • 测试失败 → 系统化调试还是猜修？
  • Review 发现问题 → 回 plan 还是堆 patch？
  • CI 失败 → 能否定位、修复、保留证据？

流程设计必须定义：哪些步骤可重复、停止条件是什么、何时升级给人。

Runtime 原语决定上限

Runtime编排能力含义
Claude CodeCommand → Agent → Skill 较完整复杂 playbook、专家审查
Codex CLIAgent → Skill + slash controls实现 worker；用 AGENTS.md/CI 补编排
Gemini CLICommand → Agent → Skill；大 context大上下文研究、TOML commands

方法论不应绑定单一工具，但落地时必须知道每个 runtime 能原生承载什么。

关键原则

  1. Spec as Source of Truth — 需求与行为变化必须可版本化，不能只在聊天记录里
  2. Context Pack — 可引用、可增量加载，而非一次性灌入全库
  3. Planner / Generator / Evaluator 分离 — Generator 自评过度乐观；独立 Evaluator 更可靠
  4. 不绕过 Outer Loop — AI 代码仍走 PR、CI/CD、度量

参考