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

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

核心理念¶

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

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

完整流程总览¶

项目启动
   │
   ├── 迭代零：基建准备
   │
   └── 迭代循环（1~N）
       ├── ① 需求澄清 ← 新增：在拆迭代之前先验证需求本身
       ├── ② 需求拆分与依赖分析
       ├── ③ 需求翻译 + 架构映射
       ├── ④ 大纲先行 + 审核
       ├── ⑤ AI 逐步实现
       ├── ⑥ 自动化质量门禁（含安全扫描 ← 新增）
       ├── ⑦ 人工审查 + 发布
       ├── ⑧ 发布后验证 ← 新增
       ├── ⑨ Mini Retro（迭代复盘）
       └── ⑩ 知识固化

贯穿全局（非迭代特异性）：
  │
  ├── 集成测试轮 ← 新增（每 3~5 个迭代或跨依赖节点触发）
  ├── 需求变更通道 ← 新增
  └── 回滚预案 ← 新增

人机分工速览¶

环节	谁做	说明
需求澄清	AI 主导 + 主人确认	AI 追问模糊点，主人拍板
迭代拆分	主人 + AI 出方案	主人把握方向，AI 出建议方案
需求翻译	AI 初稿 → 主人审核	AI 出技术翻译，主人纠偏
大纲审核	主人	关键质量门，必须主人亲自过
AI 实现	AI 全自动	AI 按清单执行
质量门禁	AI 全自动	不通过自动退回，不耗主人
人工审查	主人	核心代码必审
发布上线	AI 执行 + 主人确认	主人确认后触发部署
发布后验证	AI 全自动	监控 + 快照对比
需求变更	AI 评估 + 主人决策	AI 输出影响报告，主人决定是否改
集成测试	AI 执行 + 主人抽查	AI 跑跨迭代联调，主人抽样

🧩 全局环节（贯穿整个项目生命周期）¶

以下环节不属于某个特定迭代，而是项目运行中持续生效的全局流程。

0️⃣ 需求澄清 — 提想法先过这关¶

为什么需要： 人第一次描述需求时一定会有模糊、矛盾、边界不清的地方。如果直接拆迭代，后续做一半才发现想错了，返工成本极高。

流程：

主人提出需求"我想做XXX"
    ↓
AI 反向追问（自动，不需要主人主动触发）：
  □ 目标拆解：这个功能最终解决什么问题？
  □ 边界澄清：哪些场景是 "不算" 的？
  □ 矛盾检测：需求中有没有前后不一致的地方？
  □ 假设确认：有哪些隐含假设需要明确？（如"用户登录后才可用""只有管理员能操作"）
  □ 优先级：哪些是必须的，哪些是可延后的？
    ↓
AI 输出《需求澄清报告》：
  ✅ 已确认：N 条（主人明确说过的）
  ⚠️ 待确认：M 条（AI 追问出来的模糊点）
  ❌ 已排除：K 条（对话中排除掉的无关场景）
    ↓
主人确认或修正 → 进入迭代拆分

需求被驳回的标准： - 待确认项超过总量的 30% - 核心目标无法用一句话说清楚 - 存在无法协调的矛盾需求

🔄 需求变更通道 — 做到一半想改怎么办¶

为什么需要： 做项目一定会遇到需求变更。提前设计通道，比每次走"临时的口头沟通"更可控。

触发条件： 任何时候，主人主动提出修改。

流程：

主人："迭代3的功能A需要调整"
    ↓
AI 评估影响（自动出报告）：
  □ 影响范围：涉及哪些已完成的迭代？哪些进行中的迭代？
  □ 改造成本：需要回退的代码量  预计重写工时
  □ 依赖冲击：哪些下游迭代会受影响？
  □ 风险评级：🟢 低（局部修改）/ 🟡 中（影响1-2个迭代）/ 🔴 高（需要重新规划）
    ↓
AI 输出《变更影响报告》：
  "变更功能A → 影响已完成迭代2的模块B，需要回退重做；影响迭代4、5的依赖"
  ↓
主人决策：
  □ 接受变更 → AI 更新迭代规格 → 标记受影响迭代 → 重新安排优先级
  □ 打标记暂缓 → 记录到"后续优化"列表，当前迭代不停
  □ 拒绝变更 → 保持原计划

关键规则： 变更不阻塞当前进行中的迭代，先记下来，当前迭代完了再做评估。

🔙 回滚预案 — 上线出问题了怎么办¶

因为什么： 线上一定会出问题。没有预案的时候手忙脚乱。

触发条件： 发布会验证失败 / 监控告警 / 用户反馈问题。

分级响应：

级别	症状	响应时间	动作
🔴 P0	核心功能不可用、数据丢失、安全漏洞	15 分钟内	立即回滚到上一个稳定版本 → 切 hotfix 分支修 → 修完走快速审查 → 重新发布
🟡 P1	次要功能不可用、性能明显下降	2 小时内	评估是否回滚 → 如果影响面小可以在线修
🟢 P2	样式错乱、文案错误、非关键功能异常	下一个迭代修复	记录 bug → 纳入下一个迭代中

回滚操作（自动化）：

检测到 P0 级别故障
    ↓
自动触发回滚脚本：
  1. 记录当前版本号（存档，方便后续排查）
  2. git revert 合并的分支
  3. 将上一个稳定版本重新构建部署
  4. 发送通知："已自动回滚到 vX.X，原因：xxx"
    ↓
同时创建 hotfix 分支：hotfix-{故障描述}
    ↓
主人确认回滚结果后，进入 hotfix 修复流程

🔗 集成测试轮 — 迭代间联调¶

为什么需要： 每个迭代单独走单元测试，但迭代之间耦合的问题（字段对不上、API 参数不匹配）不会被单元测试发现。

触发时机：

条件	说明
每 3~5 个迭代	固定周期，不管有没有依赖关系
关键依赖节点	迭代 B 依赖于迭代 A 的模块，迭代 A 完成后
上线前	发布上线前必须跑一次完整集成测试

集成测试内容：

□ API 间调用链路通不通？（A 接口 → B 接口 → 数据落库 → 返回正确）
□ 数据库迁移是否兼容？（新字段不影响旧查询）
□ 前端调后端 API 是否正常？（参数格式、返回值格式）
□ 并行迭代代码合并后是否有冲突？
□ 端到端主流程是否跑通？（注册 → 登录 → 操作 → 登出）

不通过 → 自动生成冲突报告，标注具体哪两个迭代不兼容 → 分发修复任务。

一、迭代零：基建准备¶

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

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

二、迭代拆分原则¶

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

依赖图谱¶

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

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

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

三、单迭代工作流¶

每个迭代严格走以下十步。

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

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

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

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

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

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

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

注意： AI 出的翻译初稿需要主人审核，确认技术方向没有跑偏。

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

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

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

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

第四步：AI 逐步实现¶

利用AI按任务清单逐步执行：

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

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

第五步：自动化质量门禁（含安全扫描）¶

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

门禁	工具/方式	通过标准
Lint 检查	ESLint / Pylint 等	0 error, 0 warning
类型检查	TypeScript / mypy 等	无类型错误
单元测试	对应框架	通过率 100%
测试覆盖率	Istanbul / coverage 等	≥ 80%（核心模块 ≥ 90%）
🔒 依赖安全审计	`npm audit` / `pip audit` / `cargo audit`	0 critical, 0 high
🔒 密钥检测	正则扫描代码中的 token/password/secret	无硬编码密钥
🔒 API 暴露检查	检查路由定义确认未暴露内部端点	无未授权的内部接口

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

安全扫描说明： - 依赖审计：检查所有新增/更新的依赖是否存在已知 CVE 漏洞 - 密钥检测：扫描所有新增文件，检测 password=、api_key=、secret=、token= 后跟硬编码值的情况 - API 暴露检查：对比路由定义和用户权限表，确认新增接口不会意外暴露给未授权用户

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

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

发布审查清单：
□ 代码逻辑是否正确？
□ 是否处理了边界情况？
□ 命名是否符合规范？
□ 安全门禁是否已全部通过？（自动化检查不放过）
□ 测试覆盖是否充足？
□ 文档是否同步更新？
□ 分支代码是否最新（rebase 主分支）？
□ 回滚预案是否就绪？

安全漏洞的检查主要由自动化门禁负责，人工环节只需确认自动化扫描已通过即可。

不通过 → 记录问题，退回第四步修复。通过 → 主人确认，AI 执行合并 + 部署上线。

第七步：发布后验证¶

为什么需要： 上线不等于做完了。很多问题是在线上环境才暴露的——配置不对、数据量不同、用户行为出乎意料。

验证内容（自动化）：

□ 应用是否成功启动并响应？（HTTP 健康检查 200）
□ 核心接口是否返回正常数据？（自动请求核心 API，验证返回值结构）
□ 页面渲染是否正常？（骨架屏/白屏检测）
□ 日志是否有新增错误？
□ 关键指标是否在正常范围？（响应时间、错误率）

验证不通过（自动化检测到异常）：

情况	动作
应用无法启动	自动触发回滚预案
核心 API 异常	自动触发回滚预案
页面出现白屏	自动触发回滚预案
日志出现新增异常	通知主人，人工判断是否需要回滚
指标轻微波动	记录 + 通知主人，观察 15 分钟

通过 → 标记为"已上线"，进入下一环节。

第八步：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，直接套用在任何一个业务项目上。