16-22 讲实战篇总复习版

一、整段实战篇到底在讲什么

16-22 讲合起来，不是在教几个零散技巧，而是在完整演示一套：

AI 原生开发工作流（AI-Native Development Workflow）

它覆盖了软件工程几乎完整的生命周期：

搭框架
→ 明确需求
→ 形成方案
→ 拆分任务
→ 编码测试
→ 协同审查
→ 构建交付
→ 维护重构

也就是：

16 讲：搭驾驶舱
17 讲：需求编译
18 讲：方案与任务编译
19 讲：编码与测试
20 讲：协同与审查
21 讲：构建与交付
22 讲：维护与重构

二、每一讲一句话总结

第 16 讲

先搭 AI 驾驶舱，给 AI 准备统一上下文、规则、命令和模板。

第 17 讲

把模糊想法编译成清晰、结构化、可审查的 spec.md。

第 18 讲

把 spec.md 继续编译成 plan.md 和 tasks.md，让需求变成可实施、可执行的工程语言。

第 19 讲

用 TDD 驱动 AI 按任务列表逐步写代码，把 AI 关进可验证轨道。

第 20 讲

把代码审查、commit、PR 描述标准化，让 AI 参与团队协作交付。

第 21 讲

让 AI 生成 Dockerfile、Makefile 和 CI，并把这些能力沉淀回驾驶舱。

第 22 讲

让 AI 从新项目执行者升级为遗留系统分析师，参与诊断、重构和知识同步。

三、整套实战篇的主线逻辑

第一阶段：先建“驾驶舱”

第 16 讲不是直接写代码，而是先建环境和规则。

因为 AI 如果没有统一上下文，后面会出现：

• 风格不一致
• 规则不一致
• 产出不稳定
• 无法复用经验

所以先准备：

• CLAUDE.md
• constitution.md
• .claude/commands/
• .claude/templates/

这是后面所有自动化和标准化的基础。

第二阶段：先想清楚，再动手

第 17-18 讲强调：

AI 时代更不能直接“开写”，而要先完成意图编译。

第 17 讲：spec.md

解决：

• 做什么
• 用户故事
• 边界条件
• 验收标准

第 18 讲：plan.md + tasks.md

解决：

• 怎么做
• 模块怎么分
• 数据结构怎么定义
• 接口如何组织
• 任务怎么拆
• 顺序怎么安排
• 哪些可并行

这三份文档对应三层抽象：

spec.md   = WHAT
plan.md   = HOW
tasks.md  = ACTIONS

第三阶段：按任务严格执行

第 19 讲进入编码。

这里的核心不是“让 AI 自动写完”，而是：

用 TDD 把 AI 的实现行为约束起来。

流程是：

RED → GREEN → REFACTOR

RED

先写失败测试，把需求变成代码化规范。

GREEN

只写最少代码让测试通过。

REFACTOR

在测试保护下优化结构。

这一步的核心思想是：

TDD 在 AI 时代不仅是测试方法，更是防止 AI 自洽幻觉的控制机制。

第四阶段：把代码变成团队可接收的交付物

第 20 讲开始进入协同。

代码写完了，不代表真正完成。还要经过：

• Review
• Commit
• PR

这一讲的核心是：

用 Slash Command 把协作流程标准化。

例如：

• /review-go-code
• /commit

这样能把：

• 审查标准
• 提交规范
• PR 写法

固化成团队资产，而不是靠个人发挥。

第五阶段：把项目变成真正可构建、可部署、可持续交付的系统

第 21 讲开始处理 DevOps。

核心产物：

• Dockerfile
• Makefile
• .github/workflows/ci.yml

但更关键的是：

不是只生成这些文件，而是把新能力继续沉淀回驾驶舱。

也就是说：

• 有了 make build
• 就封装 /build
• 有了 make docker-build
• 就封装 /docker-build

这样就形成能力闭环：

AI 生成能力
→ 人验证能力
→ 再把能力封装成命令
→ 团队以后持续复用

第六阶段：从 0 到 1 走向 1 到 N

第 22 讲进入最现实的维护与重构阶段。

因为真实工程里，大部分时间不在“新建项目”，而在：

• 查线上问题
• 偿还技术债
• 读遗留代码
• 同步文档
• 安全重构

所以 AI 的角色变成：

• 根因分析师
• 重构助手
• 文档工程师
• 遗留系统理解器

四、每一讲的核心关键词

第 16 讲关键词

• 驾驶舱
• CLAUDE.md
• constitution.md
• Slash Command
• 模板
• 团队标准资产

第 17 讲关键词

• spec.md
• 用户故事
• 功能边界
• 验收标准
• 需求编译

第 18 讲关键词

• plan.md
• tasks.md
• 技术方案
• 合宪性审查
• 原子任务
• TDD 顺序
• [P] 并行标记

第 19 讲关键词

• TDD
• Red-Green-Refactor
• 自洽幻觉
• Mock Server
• 可测试性
• 自我修正
• Git Worktree

第 20 讲关键词

• Code Review
• Slash Command
• 标准化审查
• Conventional Commits
• PR 描述
• 标准流程用指令

第 21 讲关键词

• Dockerfile
• Makefile
• CI/CD
• DevOps
• 能力沉淀
• /build
• /docker-build

第 22 讲关键词

• 维护
• 遗留系统
• Headless 模式
• Checkpointing
• /rewind
• 根因分析
• 文档同步

五、这 7 讲真正建立了什么能力

1. 建立统一上下文的能力

不是每次从零提示 AI，而是先搭驾驶舱。

2. 把模糊需求编译成工程文档的能力

从想法到：

• spec.md
• plan.md
• tasks.md

这一步是 AI 原生开发的核心分水岭。

3. 用 TDD 约束 AI 的能力

不是让 AI 同时写代码和测试，而是：

• 先写测试
• 人工审查测试
• 再让 AI 通过测试

防止“逻辑错了但测试也跟着错”的自洽幻觉。

4. 把协作动作标准化的能力

包括：

• review
• commit
• PR description

这些不是软技能发挥，而是可模板化、可指令化、可继承的流程。

5. 把 DevOps 能力纳入 AI 工作流的能力

不只是业务代码自动化，连：

• Docker
• Make
• CI
• 构建命令

也一起纳入。

6. 在遗留系统里安全使用 AI 的能力

包括：

• 日志分析
• 根因定位
• Checkpointing 重构
• 反向文档生成

这说明 AI 原生开发不是只适合“新项目”，也适合“脏项目”。

六、这 7 讲反复强调的几个大原则

原则 1：先想清楚，再让 AI 写

体现在：

• 17 讲 spec.md
• 18 讲 plan.md 和 tasks.md

意思是：

Prompt 不该只是临时指令，而应先被工程化为规范。

原则 2：规则要显式写出来

体现在：

• constitution.md
• 审查标准
• TDD 规则
• Conventional Commits
• Make targets

意思是：

不要相信 AI 会“自然懂你的团队习惯”，必须把原则显式编码。

原则 3：标准流程要资产化

体现在：

• Slash Commands
• 模板库
• /review
• /commit
• /build
• /docker-build
• /update-docs

意思是：

高频、可复用的动作，要从 Prompt 升级成团队共享能力。

原则 4：AI 生成，人工定夺

体现在：

• 审查 spec.md
• 审查 plan.md
• 审查 tasks.md
• 审查代码
• 审查 Review 结果
• 审查 PR 描述

意思是：

AI 提供高质量草稿，人类负责价值判断和最终决策。

原则 5：安全感来自可验证、可回退

体现在：

• TDD
• 测试护栏
• Mock
• Checkpointing
• /rewind

意思是：

AI 时代真正的效率，不是一次写对，而是快速试错又不怕出事。

七、最重要的 7 个文件，要整体记住

1. CLAUDE.md

定义 AI 的长期协作规则。

2. constitution.md

定义项目宪法：简单性、TDD、明确性等。

3. spec.md

需求规范，回答 WHAT。

4. plan.md

技术方案，回答 HOW。

5. tasks.md

原子任务与依赖，回答 ACTIONS。

6. Makefile

标准化工程任务入口。

7. Dockerfile / ci.yml

交付与持续集成基础设施。

八、最重要的 5 个动作链，要背住

动作链 1：需求编译链

模糊想法 → spec.md

动作链 2：方案编译链

spec.md → plan.md → tasks.md

动作链 3：实现执行链

tasks.md → 测试 → 实现 → 重构

动作链 4：协同交付链

代码 → review → commit → PR

动作链 5：运维演进链

build → docker → CI → diagnose → refactor → docs sync

九、整套工作流中“人”和“AI”的分工

AI 负责什么？

• 快速整理信息
• 起草规范
• 补全方案
• 拆任务
• 写测试
• 写实现
• 读错误日志
• 生成 Review 报告
• 生成 commit / PR 文本
• 生成 Dockerfile / Makefile / CI
• 反向整理文档

人负责什么？

• 决定方向
• 决定边界
• 审查规范
• 审查技术选型
• 审查依赖关系
• 审查关键实现
• 判断是改 spec 还是改代码
• 判断是否接受风险
• 最终批准与交付

所以整套方法的核心分工是：

AI 负责高强度整理与执行，人类负责高价值判断与拍板。

十、这一整套方法最怕什么误区

误区 1：跳过 spec / plan / tasks，直接让 AI 开写

结果：

• 容易漂
• 容易架构跑偏
• 难以审查
• 难以返工

误区 2：让 AI 同时写代码和测试

结果：

• 自洽幻觉
• 错逻辑 + 错测试一起绿

误区 3：只用临时 Prompt，不沉淀命令和模板

结果：

• 不可复用
• 不可传承
• 团队不一致

误区 4：把 AI 输出当真理，不做人工审查

结果：

• 规范错了还一路往下传染
• 返工成本极高

误区 5：只关注写代码，不关注 review / build / docs / CI

结果：

• 项目能写不能交付
• 团队协作成本高
• AI 价值发挥不完整

十一、16-22 讲总脑图

16 搭驾驶舱
├── CLAUDE.md
├── constitution.md
├── Slash Commands
└── 模板

17 需求编译
└── spec.md

18 方案与任务编译
├── plan.md
└── tasks.md

19 编码与测试
├── TDD
├── Red-Green-Refactor
├── Mock
└── 自我修正

20 协同与审查
├── /review
├── /commit
└── PR 描述

21 构建与交付
├── Dockerfile
├── Makefile
├── CI/CD
└── /build /docker-build

22 维护与重构
├── Headless 日志分析
├── Checkpointing
├── /rewind
└── /update-docs

十二、实战篇最终总公式

这 7 讲最终可以浓缩成一个总公式：

统一上下文
+ 明确规则
+ 编译意图
+ 原子任务
+ TDD 约束
+ 标准化协同
+ 自动化交付
+ 安全维护重构
= AI 原生开发工作流

十三、最适合背诵的总总结

16-22 讲完整演示了 AI 原生开发工作流从“搭框架”到“做项目”，再到“交付与维护”的全流程。

它的核心不是单纯让 AI 写代码，而是先通过 CLAUDE.md、constitution.md、Slash Commands 和模板，搭建起一个统一的 AI 驾驶舱；然后把模糊需求编译成 spec.md，再进一步编译成 plan.md 和 tasks.md，将意图逐层转化为可执行的工程文档；接着在编码阶段，用 TDD 把 AI 关进测试驱动的可验证轨道中，防止自洽幻觉；随后又通过 /review、/commit 和 PR 描述生成，让 AI 参与标准化协作；再通过 Dockerfile、Makefile、CI/CD 和新的 Slash Commands，把构建与交付能力纳入工作流；最后在维护阶段，借助 Headless 模式、Checkpointing 和文档同步能力，让 AI 参与遗留系统的诊断、重构与知识传承。

因此，这一整套实战真正建立的，不是“如何向 AI 提几个 Prompt”，而是：

如何把软件工程的全生命周期，改造成一个由人类指挥、AI 执行、规则显式、流程可复用、质量可验证的 AI 原生工程系统。

十四、一句话总记忆

16-22 讲的本质，是把软件开发从“人手工驱动的流程”，升级成“人类指挥、AI 执行、规则约束、全生命周期可复用”的 AI 原生工程系统。