AI 驱动业务系统自动化构建流水线¶

把业务能力变成可执行的生产系统，从需求分析到部署上线全程 AI 自动化。

核心理念¶

不是让 AI 单次生成代码，而是建立一套可重复执行的开发流水线：

主人只需要描述"我想要什么"
自动拆解成小迭代，业务翻译成技术任务
每个迭代走标准工作流，有质量门禁有复盘
知识持续沉淀，越用越聪明

完整流程总览¶

项目启动
   │
   ├── 迭代零：基建准备
   │
   └── 迭代循环（1~N）
       ├── ① 需求拆分与依赖分析
       ├── ② 需求翻译 + 架构映射
       ├── ③ 大纲先行 + 审核
       ├── ④ AI 逐步实现
       ├── ⑤ 自动化质量门禁
       ├── ⑥ 人工审查 + 发布
       ├── ⑦ Mini Retro（迭代复盘）
       └── ⑧ 知识固化

一、迭代零：基建准备¶

每个新项目必须先过这一关，否则后续迭代没有根基。

任务	输出	说明
技术选型	技术栈决策文档	后端语言/框架、前端框架、数据库、部署方式
脚手架搭建	可运行的空项目	初始化框架、配置好构建、本地可启动
全局宪法制定	CONSTITUTION.md	技术栈规范、命名规则、目录结构、架构约定
CI/CD 建立	自动化流水线	代码检查、构建、部署的自动化链路

二、迭代拆分原则¶

原则	说明
粒度够小	每个迭代 1-3 次 AI 会话内可完成，避免上下文溢出
用户可见	每个迭代产出可见可测试的用户价值，不是纯技术层重构
依赖前置	迭代开始前标注依赖关系，形成依赖图谱
并行推进	无依赖的迭代可同时推进，提高效率

依赖图谱¶

每个迭代开始前必须标注：

迭代 A ──依赖──→ 迭代 B ──依赖──→ 迭代 C
                  │
                  └──→ 迭代 D (无依赖，可并行)

阻塞处理策略：若上游迭代卡住，被依赖的迭代先走 mock/stub，向下推进不等待。

三、单迭代八步工作流¶

每个迭代严格走以下八步循环。

第一步：迭代需求规格说明书¶

用业务语言写清楚，包含：

要素	说明
迭代目标	这个迭代要解决什么问题
用户故事	谁做什么带来了什么价值
验收标准	怎么才算"做完了"
依赖标注	前置依赖和后续依赖
风险点	可能卡住的地方

第二步：需求翻译 + 架构映射¶

将业务需求翻译成技术任务。 这一步很关键——业务语言直接丢给 AI 会跑偏。

输出： - 涉及的文件目录范围 - API 设计（方法、路径、参数、返回值） - 数据库模型变更 - 新增的公共组件类型

同时标注依赖关系：当前迭代依赖迭代 X 的 Y 模块，以及被哪些后续迭代依赖。

第三步：大纲先行 + 审核¶

不允许直接写代码。 先出任务清单，逐项审核：

审核清单：
□ 任务是否有遗漏？（对照验收标准逐条核对）
□ 是否使用了禁止的库/技术？（对照全局宪法）
□ 是否符合现有架构？（目录结构、设计模式是否一致）
□ 是否引用了未定义的模块？
□ 是否有对应的测试计划？

审核不通过 → 退回修改大纲，审核通过 → 进入第四步。 不跳过。

第四步：AI 逐步实现¶

调用 codex-cli / cursor-cli 等终端工具，按任务清单逐步执行：

1. 创建文件框架
2. 实现核心逻辑
3. 补充边界处理和错误处理
4. 编写自动化测试（单元测试 + 集成测试）
5. 生成测试报告

每完成一个任务关闭一个，便于追踪进度。

第五步：自动化质量门禁¶

AI 实现完成后，必须先过自动化检查，不进人工环节：

门禁	工具/方式	通过标准
Lint 检查	ESLint / Pylint 等	0 error, 0 warning
类型检查	TypeScript / mypy 等	无类型错误
单元测试	对应框架	通过率 100%
测试覆盖率	Istanbul / coverage 等	≥ 80%（核心模块 ≥ 90%）

未通过 → 自动退回第四步，AI 修复。 不消耗主人时间。

第六步：人工审查 + 发布¶

对照审查清单逐项核对，不是自由发挥：

发布审查清单：
□ 代码逻辑是否正确？
□ 是否处理了边界情况？
□ 命名是否符合规范？
□ 有无安全漏洞（SQL注入、XSS、敏感信息泄露）？
□ 测试覆盖是否充足？
□ 文档是否同步更新？
□ 分支代码是否最新（rebase 主分支）？

不通过 → 记录问题，退回第四步修复。通过 → 合并到主分支，发布上线。

第七步：Mini Retro（迭代复盘）¶

不要等到项目结束才复盘，每个迭代做一次小型回顾：

复盘问题：
① 这个迭代 AI 生成质量如何？（好/中/差）
② 审核发现了什么问题？（归类记录）
③ 有什么可以优化的流程？
④ 有什么值得沉淀的知识？
⑤ 下一个迭代需要注意什么？

复盘产出 → 更新到下一个迭代的上下文中。

第八步：知识固化¶

不是所有变更都需要固化。 按门槛标准分级：

级别	范围	举例	操作
🔴 必须固化	公共组件、API 端点、新引入的依赖、架构模式	新增了文件上传组件	更新到领域知识文档
🟡 选择性固化	优化技巧、踩过的坑、代码风格偏好	发现某个 Ant Design 组件有坑	视重要性决定是否记录
⚪ 不固化	纯业务逻辑、临时调试代码、单次工具函数	某个报表的 SQL 查询	不记录

固化方式： - 更新到分层上下文文档（全局宪法/领域知识/迭代规格） - 同时推送到 Git 仓库，确保各环境同步

四、分层上下文管理¶

三层结构¶

层级	内容	读取策略	维护时机
全局宪法	技术栈、命名规则、架构约定、部署规范	每次必读	迭代零制定，后续仅重大变更时更新
领域知识	主要业务实体、API 路径、核心模型、公共组件	按需引用	每次知识固化时更新
迭代规格	当前迭代任务清单、验收条件、依赖、风险	本次迭代使用	每次迭代开始时创建，结束后归档

文档自动维护¶

每次迭代完成后，AI 自动生成： - 迭代总结报告（做了什么、有什么产出、有什么遗留） - 更新领域知识文档（如果有必须固化的内容） - 存档迭代规格文档（历史可回溯）

五、代码隔离策略¶

main 分支 ← 稳定可发布版本
  │
  ├── iter-01-feature-A      ← 迭代1：实现功能A
  ├── iter-02-feature-B      ← 迭代2：实现功能B（可并行）
  ├── iter-03-dependency-X   ← 迭代3：依赖性工作
  └── iter-04-fix-Y          ← 迭代4：修复/优化

每个迭代一个独立分支，互不干扰
分支命名：iter-{序号}-{简短描述}
合并规则：谁审查谁合并，合并后删除远程分支
主分支保护：不允许直接 push，只能通过 PR/MR 合并

这套流程可以作为通用方法论，后续做成可复用的 Skill，直接套用在任何一个业务项目上。