主题
认识 SDD：为什么 AI 编码需要"规矩"
5 分钟读完本页，你会理解 HCodeFlow 的核心理念，以及它为什么这样设计。
你可能遇到过的场景
用 AI 写代码时，这些情况是不是很熟悉？
- 让 AI 改个功能，结果改了不该改的地方 — 你说"改登录页"，它连注册页也一起动了
- AI 写的代码能跑，但和团队规范不兼容 — 你用 Pinia，它给你写了 Vuex；你用 RESTful，它给你设计了 RPC
- 需求说不清，AI 理解错方向，来回返工 — 你说"加个搜索"，它做了全文检索，你其实只要个下拉筛选
这些问题的根源不是 AI 能力不够，而是缺乏明确的约束和流程。
SDD 是什么？
SDD = Spec-Driven Development（规范驱动开发）
核心只有一句话：先写清楚要做什么（Spec），再让 AI 去做。
打个比方：
- 没有 SDD = 让装修工人"看着来"，装完发现风格不对
- 有了 SDD = 给工人施工图纸，按图施工、按图验收
SDD 不是 HCodeFlow 发明的概念。在传统软件工程中，先写需求文档再编码是基本常识。HCodeFlow 做的是：把这套常识结构化地教给 AI。
HCodeFlow 的三条铁律
| 铁律 | 含义 | 为什么需要 |
|---|---|---|
| No Spec, No Code | 没文档不动手 | 防止 AI 凭感觉写代码，先想清楚再动手 |
| Spec is Truth | 文档是唯一真相 | 有分歧时以 Spec 为准，而不是"我记得当时说的是..." |
| No Approval, No Execute | 没批准不执行 | 人掌握关键决策权，AI 不能擅自行动 |
这三条铁律确保了：人是决策者，AI 是执行者。
SDD 工作流长什么样？
HCodeFlow 把 AI 编码过程拆成了 6 个步骤：
需求 ──→ Intake(三问定位) ──→ Spec(写文档) ──→ Approval(人审批)
│
Merge(合并) ←── Review(代码审查) ←── Execute(AI实现) ←─┘每一步做什么：
| 步骤 | 做什么 | 谁来做 | 人的参与 |
|---|---|---|---|
| Intake | 澄清需求：目标/边界/验收标准 | 你 + AI | 你回答三问 |
| Spec | 写需求文档 + 技术设计 | AI（PM + Architect 角色） | 你审批 |
| Approval | 人确认方案 | 你 | 你拍板 |
| Execute | 写代码 + 写测试 | AI（Dev/FE 角色） | 不需要 |
| Review | 审查代码质量 | AI（QA 角色） | 你确认结果 |
| Merge | 合并代码 | 你 | 你决定 |
你的工作从"写代码"变成了"审批和决策"。
什么时候不需要完整流程？
不是所有改动都需要走上面 6 步。对于小改动（改个文案、修个 bug、调个配置），HCodeFlow 提供 Q0 轻量模式：
需求 ──→ 简要确认 ──→ AI 直接改 ──→ 你确认AI 会自动判断用完整流程还是轻量模式，你不需要操心。
HCodeFlow 在 Claude Code 中的位置
┌──────────────────────────────────────┐
│ Claude Code（AI 编码助手） │
│ │
│ ┌────────────────────────────────┐ │
│ │ HCodeFlow（工作流框架） │ │
│ │ 定义"怎么用 AI 写代码"的规矩 │ │
│ └────────────────────────────────┘ │
│ │
│ 你的业务项目 ← AI 在这里写代码 │
└──────────────────────────────────────┘HCodeFlow 不替代 Claude Code，也不替代你的项目。它是一套"规矩"——告诉 Claude Code 在你的项目中应该如何协作。