什么是 AI 编程工程工作流？
AI 能写出代码，但写不出工程纪律。AI 编程工程工作流把「能写代码的 AI」改造成「可交付的工程师」——用结构化流程约束每个环节，用质量门禁守住每一道关口，让 AI 生成的不再是一次性代码，而是可维护、可追溯、可发布的软件。
问题：AI 编码缺少工程纪律
直接让 AI 写代码，效率很高，但稳定性堪忧。典型的「裸奔式 AI 编程」长这样：
- 从想法直接跳到代码，跳过需求澄清，改到一半才发现方向错了。
- 没有计划就动手，改动面越滚越大，收不了口。
- 只写实现不写测试，「能跑」被当成「完成」。
- 不审查、不验证就宣称交付，把风险推给下游。
- 在 main 上直接提交，不关联 Issue，不留任何审计痕迹。
结果：代码看起来能跑，但不可维护、不可追溯、不可交付。短期省下的时间，会在长期的返工与事故里加倍还回去。
解法：一个公式，三条腿
工程纪律不是对 AI 的约束，而是对 AI 的增强。把「能写代码的 AI」放进工程化的容器里：
AI 助手
承担高强度执行——编写、重构、审查、跑命令，把人的精力留给关键决策。
结构化流程
需求澄清 → 计划制定 → 执行 → 交付检查，把工程循环固化成不可跳过的步骤。
质量门禁
build → test → fmt → clippy → pre-commit，全绿才算完成，杜绝「看着能跑」就交付。
四阶段模型：一个命令，跑完整个工程循环
工程循环被固化为四个连续阶段，每个阶段都有明确的产出与闸门，阶段间不可跳步：
- 01
需求澄清
从 open issues 提炼需求，产出结构化 Issue 与可机械验证的验收标准。
- 02
计划制定
生成可执行实现计划：改动面盘点、TDD 顺序与质量门禁承诺。
- 03
执行
TDD 红绿循环 + 子代理隔离开发，自动创建 PR 并附质量报告。
- 04
交付检查
流水线分析、Issue 分流、代码审查与闸门复核，全绿才合。
想深入了解每个阶段的执行细节与闸门证据？前往 gf-workflow 完整指南 →
两种技能来源，两种驾驶方式
工作流骨架恒定，执行引擎可切换。启动时自动检测技能来源并写入契约，跨会话沿用：
| 维度 | Superpowers（全自动流水线） | mattpocock（人工驾驶流水线） |
|---|---|---|
| 触发模型 | 模型全自动触发 | user-invoked 硬约束，✋ 暂停语义 |
| Phase 1 澄清 | brainstorming | grilling → /to-spec（只写本地） |
| Phase 2 计划 | writing-plans | /to-tickets（票据图 + blocking edges） |
| Phase 3 执行 | SDD / executing-plans / 后台代理 | /implement 逐票据（内部 /tdd） |
| 人的触点 | 2 个（Gate 2→3、Branch Finish） | 5 个（✋×3 + 审批 + 确认） |
| 主线 token 开销 | ≈14k + subagent 扇出 | ≈4.8k，不触发零消耗 |
两者皆未安装时，gf skills install
会硬阻断并给出安装引导，确保工作流始终有可用的执行引擎。
为什么需要工程纪律
工程纪律不是流程负担，而是把 AI 的生产力沉淀成组织资产：
可追溯
每次改动都关联 Issue、PR 与 CI 结果，审计链条完整。
可维护
TDD 与代码审查保证测试覆盖与可读性，长期可演进。
可交付
质量门禁保证每次合并都是全绿，发布可重复、可回滚。
可扩展
统一命令面覆盖 GitHub / GitLab / GitCode，多 Agent 平台一键接入。