AI 原生开发实践指南 — 基于 spec-kit 的规格驱动开发

1.What：这是什么？

1.1 AI 原生开发（AI-Native Development）

AI 原生开发是一种以智能体编码工具（如 Claude Code）为主要执行者的开发范式：人负责定义「做什么、为什么、做到什么程度算好」，AI 智能体负责「怎么做」——生成计划、编写代码、运行测试、修复问题。人的角色从「写代码的人」转变为「写规格、做评审、把关口的人」。

1.2 规格驱动开发（SDD, Spec-Driven Development）

SDD 是 AI 原生开发的核心方法论：规格说明（Spec）是项目的唯一真相源，代码是规格的「可执行表达」。开发流程不再是「边想边写」，而是：

章程Constitution→ 规格Specify→ 计划Plan→ 任务Tasks→ 分析Analyze→ 实现Implement→ 收敛Converge

每一阶段都产出可评审的文档，下一阶段以上一阶段的文档为输入。文档先行，代码最后。

1.3 spec-kit 是什么

spec-kit 是 GitHub 开源的 SDD 工具包。它不做代码生成，而是向你的智能体编码工具（Claude Code、Copilot、Cursor 等）注入一组斜杠命令（技能）和文档模板，把上述 SDD 流程固化下来：

/speckit-constitution — 制定项目章程（不可妥协的开发原则）
/speckit-specify — 把一句话需求变成结构化功能规格
/speckit-plan — 生成技术实现计划与设计产物
/speckit-tasks — 把计划分解为可执行的任务清单
/speckit-analyze — 跨文档一致性分析（规格/计划/任务是否互相矛盾）
/speckit-implement — 按任务清单执行实现
/speckit-converge — 实现后收敛核查（代码 vs 规格的差距闭环）

1.4 本指南的实战案例

本指南全部内容来自一个真实完成的项目：适老友好计算器（macOS 原生应用，Swift 6 + SwiftUI）。从「给老人开发一款计算器 macOS 原生应用」这一句话开始，全程通过 spec-kit + Claude Code 完成，共产出 1 份章程、1 份规格、5 份设计文档、29 个任务、全部单元测试与可运行应用。文中所有提示词、产物、提交记录均为该项目的真实历史。

2.Why：为什么需要 SDD？

2.1 直接让 AI「凭感觉写代码」（Vibe Coding）的四大问题

① 需求漂移

没有书面规格，AI 会自行脑补需求。聊得越久，上下文越长，最初的目标越容易被稀释、遗忘或曲解。

② 质量无标准

「做到什么程度算好」没有定义，AI 交付的代码是否合格无从判断，评审只能凭感觉。

③ 复杂度失控

AI 倾向于「多做」——加功能、加抽象、加依赖。没有约束，一个计算器也能长出用户系统和云同步。

④ 无法交接与复现

对话记录不是工程资产。换一个人（或换一个会话）继续开发，无法知道当初为什么这样决策。

2.2 SDD 如何解决这些问题

机制	作用	本项目实例
章程（Constitution）	把不可妥协的原则写成「法律」，后续所有产物必须过章程门禁检查	「适老性优先（字号≥24、对比度4.5:1）」「测试先行（TDD）」等 5 条原则，每条都标注理由
规格（Spec）	用用户故事 + 验收场景 + 可度量成功标准锁定「做什么」，不含技术细节	3 个用户故事（P1 四则运算 / P2 防错 / P3 语音播报）、15 条功能需求、6 条成功标准
计划（Plan）	锁定「怎么做」：技术栈、架构、目录结构，并做章程合规检查	Swift 6 + SwiftUI、纯逻辑状态机引擎、零第三方依赖；章程门禁 5 项全 PASS
任务（Tasks）	把计划切成可独立验证的小任务，标注依赖与并行性，测试任务强制先行	29 个任务（T001–T029），按 Setup → 基础 → US1 → US2 → US3 → 打磨 → 收敛分 7 个阶段
分析 + 收敛	实现前查文档间矛盾，实现后查代码与规格的差距，形成闭环	收敛阶段发现并修复 3 个遗留差距（T027–T029：窗口缩放、上限提示、魔法数字）
Git 版本化	每个阶段产物单独提交，历史即审计轨迹，可随时回滚与追溯	9 次提交，从 `specify init` 到收敛任务完成，每一步可查

核心理念在 AI 原生开发中，写得最好的代码是规格。你的工程能力不再体现在打字速度上，而体现在：能否写出无歧义的需求、能否制定有效的约束、能否评审 AI 的产出。

3.全流程总览

整个实战项目从初始化到收尾共 8 个操作步骤，对应 9 次 Git 提交。记住这张地图，后面每一章展开讲一步：

步骤	命令	核心产物	对应提交
0. 初始化	`specify init --here --integration claude`	`.specify/` 模板、`.claude/skills/` 技能	`2d8e96d`
1. 章程	`/speckit-constitution`	`.specify/memory/constitution.md`	`bc7534f`
2. 规格	`/speckit-specify`	`specs/001-.../spec.md` + 质量清单	`c57afe0`
3. 计划	`/speckit-plan`	`plan/research/data-model/contracts/quickstart`	`028c24a`
4. 任务	`/speckit-tasks`	`tasks.md`（26 个任务）	`e17138a`
5. 分析	`/speckit-analyze`	一致性报告（对话内）	—
6. 实现	`/speckit-implement`	全部源码 + 测试（TDD）	`1e64725`
7. 收敛	`/speckit-converge` + `/speckit-implement`	追加任务 T027–T029 并完成	`7794f32` `5603619`

关键纪律每个阶段完成后立即 git commit。这让「文档先行」可追溯：任何一行代码都能回溯到产生它的任务、计划、规格和章程。

4.环境准备（一次性）

4.1 你需要什么

智能体编码工具：Claude Code（本指南使用，模型 Kimi-K3）。spec-kit 也支持 Copilot / Cursor / Gemini CLI 等，命令完全兼容。
spec-kit CLI：specify，用于初始化项目脚手架。
Git：版本化是流程的一部分，不是可选项。
目标平台工具链：本项目为 Xcode 15+（Swift 6），换成你自己的技术栈即可。

4.2 初始化项目

在你的（可以是全新的）Git 仓库根目录执行：

# 在已有仓库中初始化（--here）；指定集成 Claude Code
specify init --here --integration claude

初始化后项目多出两块内容：

.specify/ — 模板（spec/plan/tasks/checklist 模板）、章程存放处（memory/）、集成配置
.claude/skills/speckit-*/ — 9 个技能（斜杠命令），Claude Code 启动后自动可用

验证在 Claude Code 中输入 /speckit，能看到自动补全列表即说明安装成功。

5.第 0 步：制定项目章程建议必做

5.1 这一步在做什么（What & Why）

章程是项目的「宪法」：5–8 条不可妥协的原则，每条附带「为什么」。它回答的问题是：当 AI（或人）面临取舍时，应该牺牲什么、保住什么？后续的计划命令会对章程做门禁检查（Constitution Check），不合规的设计必须返工或书面声明偏离。

5.2 怎么操作（How）

在 Claude Code 中输入
/speckit-constitution

可以不带参数直接运行（本项目即如此），智能体会基于项目背景交互式地引导你确认原则；也可以在参数中直接给出你的原则草案。

5.3 本项目的真实产物（节选）

产物位于 .specify/memory/constitution.md（v1.0.0），共五条核心原则：

原则	要点	是否 NON-NEGOTIABLE
I. 适老性优先	字号 ≥24px、对比度 ≥4.5:1、点击目标 ≥44×44、防误触间距	✅ 是
II. 简洁至上	只做四则运算；单屏完成；YAGNI；新增复杂度须书面理由	否
III. 测试先行	严格 TDD 红-绿-重构；测试先于实现并观察到失败	✅ 是
IV. 防错设计与清晰反馈	除零等非法操作给通俗中文提示；禁止技术性错误码	否
V. 可访问性合规	WCAG 2.1 AA；屏幕阅读器标签；全键盘可达	否

注意章程中每条原则都有「理由」段落——理由是给 AI 看的，让它在边界情况下能推理出符合原则的决策，而不是机械执行字面规则。

5.4 完成标志与提交

章程文件无占位符，版本号、批准日期齐全
原则数量控制在 5 条左右，每条可执行、可检查
提交：docs: 制定项目章程 v1.0.0

6.第 1 步：编写功能规格（Specify）

6.1 这一步在做什么

把「一句话需求」变成一份结构化、可测试、不含技术细节的功能规格。规格只描述「用户是谁、要达成什么、怎样算成功」，禁止出现语言、框架、API 等实现细节——那是下一步计划的事。

6.2 怎么操作

本项目的真实输入
/speckit-specify 给老人开发一款计算器 macOS 原生应用。

就这一句话。智能体会自动创建特性分支目录 specs/001-elder-friendly-calculator/ 并生成完整规格。

6.3 产物的骨架（照此评审）

生成的 spec.md 必须包含以下部分，评审时逐项核对：

用户故事（User Stories）：按优先级 P1/P2/P3 排序，每个故事都要写「Why this priority」和「Independent Test」（如何独立验证）。本项目的 P1 故事仅「大字号四则运算」一条——仅此一条即可构成 MVP。
验收场景（Acceptance Scenarios）：Given/When/Then 格式，每个故事 3–4 条。
边界情况（Edge Cases）：超长输入、溢出、无限循环小数、窗口失焦……本项目列了 5 条，全部在后续转化为防错需求。
功能需求（FR-xxx）：可测试的 MUST 语句，本项目 15 条。
成功标准（SC-xxx）：可度量、技术无关的结果指标，如「90% 老年用户 1 分钟内完成一次两位数加法」。
假设（Assumptions）：把未言明的默认决策写下来（如「语音默认关闭」「界面语言为中文」）。

6.4 质量门禁

spec-kit 会同时生成 checklists/requirements.md 质量清单，逐条自查。本项目的清单 16 项一次通过。重点关注：

无 [NEEDS CLARIFICATION] 标记残留（有歧义时要么用 /speckit-clarify 澄清，要么依据章程取合理默认值并记入 Assumptions）
成功标准可度量且技术无关
无实现细节泄露（本项目允许 24pt/44×44/4.5:1 出现在规格中，因为它们是用户可感知的验收约束，直接来自章程）

经验规格阶段「忍住不谈技术」是最难也最重要的一条。技术约束（如「必须用 Swift」）留给下一步 /speckit-plan 的输入参数。规格越纯粹，它作为真相源的寿命越长。

提交：docs: 新增 001 适老友好计算器功能规格说明

7.第 2 步：制定实现计划（Plan）

7.1 这一步在做什么

在规格的约束下做技术决策：选什么技术栈、什么架构、目录怎么组织、关键技术风险怎么解决。这一步是你向 AI 施加技术意图的最佳时机——通过命令参数显式给出。

7.2 怎么操作

本项目的真实输入
/speckit-plan 使用 Swift 6 + SwiftUI 开发 macOS 原生应用，最低支持 macOS 13，不引入任何第三方依赖。语音播报使用系统 AVSpeechSynthesizer 中文语音。遵循 TDD：计算引擎作为独立的纯逻辑模块先行开发并用 XCTest 覆盖，UI 层尽量薄。

这段参数包含四类信息，写你自己的项目时照此组织：①技术栈 ②版本/平台底线 ③硬约束（零依赖）④架构意图（引擎纯逻辑、UI 极薄、TDD）。

7.3 产出的五份设计文档

文件	内容	本项目要点
`plan.md`	技术上下文 + 章程门禁检查表 + 目录结构	5 条章程原则逐项 PASS；单 target 约 10 个源文件
`research.md`	关键技术决策：Decision / Rationale / Alternatives	7 项决策（R1–R7），如「用 Decimal 而非 Double，避免 0.1+0.2 浮点误差伤害老年用户信任」
`data-model.md`	实体、字段、验证规则、状态机转移表	计算会话状态机 5 个状态，每个转移标注对应的需求编号（FR-007 等）
`contracts/`	模块间契约	引擎 API 契约 + UI 契约（字号/对比度等硬线写成可验收条款 U1–U15）
`quickstart.md`	端到端验证场景，直接映射 spec 验收场景	V1–V4 四组场景，覆盖构建、四则运算、防错、语音、边界与度量

评审重点计划阶段你必须亲自评审 plan.md 的「Constitution Check」表和 research.md 的每个 Alternatives——AI 否决某个方案的理由是否成立，是体现你工程判断力的地方。

提交：docs: 新增 001 实现计划与设计产物（plan/research/data-model/contracts/quickstart）

8.第 3 步：分解任务清单（Tasks）

8.1 这一步在做什么

把计划切成编号任务，每个任务粒度为「一个文件的一次改动」，并标注：所属用户故事、是否可并行 [P]、依赖关系。这是 AI 执行实现时的「施工图纸」。

8.2 怎么操作

在 Claude Code 中输入
/speckit-tasks

无需参数，智能体读取 specs 目录下全部设计文档自动生成本项目 26 个任务（T001–T026）。

8.3 产物结构（tasks.md）

Phase 1 Setup：工程初始化（T001–T003）
Phase 2 Foundational：全部故事共享的基础类型、文案资源、设计常量——完成前阻断所有用户故事（T004–T007）
Phase 3–5 用户故事：每个故事内部测试任务先行（如 T008 写失败测试 → T009 实现使其通过），严格 TDD
Phase 6 Polish：性能验证、UI 冒烟测试、代码清理（T022–T026）

任务格式：[ID] [P?] [Story] 描述 + 确切文件路径。示例：

- [ ] T008 [P] [US1] 编写失败测试 ElderCalculatorTests/CalculatorEngineTests.swift（US1 部分）：
      C1 初始显示 "0"；C2 四则运算各至少 2 例（12+7=19 …）…

经验好的任务清单有三个特征：① 每个任务写明确切文件路径；② 测试任务明确要求「先确认失败（Red）再实现（Green）」；③ 明确标注「本项目故事间共享引擎文件，不可并行，严格 P1→P2→P3」——不盲目套用模板的并行建议。

提交：docs: 新增 001 任务分解清单 tasks.md（26 个任务，TDD 测试先行）

9.第 4 步：跨文档一致性分析（Analyze）实现前必跑一次

9.1 这一步在做什么

在写任何代码之前，让智能体交叉审阅 spec / plan / tasks 三份文档，找出：矛盾（A 文档说要、B 文档说不要）、遗漏（需求没有对应任务）、含糊（任务描述无法执行）。这是成本最低的缺陷修复点——文档阶段改一句话，胜过实现后改一堆代码。

9.2 怎么操作

在 Claude Code 中输入
/speckit-analyze

分析报告在对话中输出（不写文件）。发现的问题分严重级列出，你可以让智能体当场修订对应文档，修订后再跑一遍直到没有高危项。

注意 Analyze 是只读的——它只报告问题，不擅自改文档。修不修、怎么修，由你决定。这正是「人把关口」原则的体现。

10.第 5 步：执行实现（Implement）

10.1 这一步在做什么

智能体按 tasks.md 的顺序逐任务执行：勾选任务 → 写代码 → 跑测试 → 勾选完成。你在这个过程中要做的不是写代码，而是监督节奏、审查关键产出、验证检查点。

10.2 怎么操作

在 Claude Code 中输入
/speckit-implement

全量执行所有任务；也可以传参数只执行指定阶段，如 /speckit-implement 完成 Phase 7 收敛任务 T027、T028、T029（本项目收敛阶段即如此使用）。

10.3 执行中的监督要点

TDD 纪律：测试任务（T008/T015/T018）必须先写并观察到失败，再实现。若 AI 跳过了 Red 环节，要求它回退演示失败。
阶段检查点（Checkpoint）：tasks.md 每个阶段末尾有检查点（如「US1 完整可用——运行 quickstart V1 全部通过，可作为 MVP 演示」）。到达检查点时亲自运行验证，不要只看 AI 的自述。
测试通过是硬门槛：本项目通过 xcodebuild test 运行引擎全分支测试 + 设计常量合规断言 + 播报文案测试，全部通过才算完成。
运行真实应用：本项目执行中用户多次提供应用截图反馈界面问题——把截图直接发给智能体是非常高效的视觉反馈方式。

10.4 本项目的执行结果

维度	结果
源码结构	`Engine/`（纯 Swift 状态机，零 UI 依赖）、`Views/`（4 个薄视图 + 设计常量）、`Speech/`（协议隔离的语音服务）
测试	CalculatorEngineTests（含 ≥1000 组随机按键序列的属性式测试）、SpeechServiceTests（mock 合成器）、AccessibilityMetricsTests（字号/对比度自动断言）
提交	`feat: 实现适老友好计算器 macOS 原生应用（T001–T024、T026）`

注意提交信息里诚实标注了未含 T025（人工验证任务）——人工验证本就该由人完成，这是人机职责边界的正确示范。

11.第 6 步：收敛收尾（Converge）

11.1 这一步在做什么

实现完成后，代码与文档之间往往存在「静默差距」：规格里写了但实现漏了的、契约里承诺了但代码没兑现的。收敛步骤系统性地核查这些差距，把它们变成追加任务并闭环。这是 SDD 区别于「一锤子生成」的关键机制。

11.2 怎么操作

分两步
/speckit-converge

产出差距清单，追加为 Phase 7 任务（本项目追加 T027–T029）：

T027 窗口放大时按钮与字号按比例缩放（契约 U5 只实现了部分）
T028 输入达 12 位上限时的轻微视觉提示（spec 边界情况只做到静默忽略）
T029 残留魔法数字迁移至 AccessibilityMetrics（T026 的「无魔法数字」声明未真正成立）

/speckit-implement 完成 Phase 7 收敛任务 T027、T028、T029

两次提交收尾：docs: 追加 001 收敛任务 Phase 7 → feat: 完成收敛任务 T027–T029 + 窗口可见性保障。

为什么收敛如此重要 T029 暴露了一个典型问题：AI 在 T026 中「声明」完成了魔法数字清理，但实际残留了硬编码。收敛核查就是对 AI 自我声明的独立审计——没有这一步，这类差距会永远藏在代码里。

12.Git 版本化策略

本项目的完整提交历史就是一部 SDD 流程史，照此节奏提交即可：

5603619 feat: 完成收敛任务 T027–T029（窗口缩放/输入上限提示/魔法数字清理）
7794f32 docs: 追加 001 收敛任务 Phase 7（T027–T029）
1e64725 feat: 实现适老友好计算器 macOS 原生应用（T001–T024、T026）
e17138a docs: 新增 001 任务分解清单 tasks.md（26 个任务，TDD 测试先行）
028c24a docs: 新增 001 实现计划与设计产物（plan/research/data-model/contracts/quickstart）
c57afe0 docs: 新增 001 适老友好计算器功能规格说明
bc7534f docs: 制定项目章程 v1.0.0（适老性优先等五条核心原则 + 治理规则）
2d8e96d specify init --here --integration claude
d9f4de5 Initial commit

文档产物用 docs:，代码产物用 feat:，一眼区分阶段性质。
一个阶段一次提交，提交信息里带上任务编号范围，可追溯。
每个阶段完成后，在 Claude Code 里直接说「git commit」即可，智能体会按惯例生成规范信息。

13.最佳实践总结（来自实战的十条经验）

章程先行，且写出理由。理由段落让 AI 能在边界情况下推理，而不是机械执行。章程会在计划阶段被自动门禁检查，写得越具体约束力越强。
规格里忍住不谈技术。技术约束通过 /speckit-plan 的参数传入。规格只写用户价值、验收场景与可度量标准。
一句话也能启动。本项目的规格输入只有「给老人开发一款计算器 macOS 原生应用」——模板和章程会引导 AI 补全结构，但你要评审它补的 Assumptions。
用优先级用户故事换取 MVP。P1 故事必须能独立验证、独立交付（本项目的 P1 = 大字号四则运算，做完即可演示）。
TDD 不可协商。把「测试先行」写进章程并标记 NON-NEGOTIABLE；任务清单强制测试任务在前；执行时要求演示测试先失败。
实现前跑 Analyze，实现后跑 Converge。前者查文档间矛盾，后者查代码对文档的欠账——两次审计兜住大部分 AI 偏差。
每阶段立即提交。Git 历史即审计轨迹；文档与代码分开提交，任务编号写进提交信息。
核心逻辑做成纯模块。计算引擎不 import 任何 UI 框架，因此可以脱离界面全分支测试——这既是好架构，也是 AI 时代「可验证性」的前提。
把质量底线变成可执行的测试。本项目的「字号 ≥24pt、对比度 ≥4.5:1」不靠自觉，靠 AccessibilityMetricsTests 自动断言防回归。
人在三个位置把关：评审章程与规格（意图层）、评审计划与分析报告（决策层）、运行检查点与人工验收（结果层）。其余交给 AI。

14.常见问题 FAQ

Q1：需求很简单，也要走完整流程吗？

流程粒度可伸缩，但章程 → 规格 → 任务 → 实现 → 提交这条主干不建议省。小需求下每份文档可能只有半页，但「写下来再实现」的纪律不变。计算器就是个小需求，完整流程依然带来了 T027–T029 三个真实改进。

Q2：规格写到一半发现需求有歧义怎么办？

两条路：歧义影响方向性决策时用 /speckit-clarify 做交互式澄清；有合理默认值时依据章程取默认并记入 spec 的 Assumptions（本项目未用 clarify，全部走了默认值路线）。

Q3：AI 实现时偏离了任务清单怎么办？

任务编号就是你的缰绳：要求它「只做 T0xx，完成后停下汇报」。大阶段之间用 quickstart 场景亲自验证，验证不过不让进入下一阶段。

Q4：规格写错了，已经进入实现了怎么办？

改规格 → 同步改计划与任务 → 提交说明 → 再让智能体按新任务实现。永远不要只改代码不改文档——规格是唯一真相源，文档与代码分叉后 SDD 就失效了。

Q5：这套流程换其他技术栈/其他 AI 工具能用吗？

能。spec-kit 与语言无关（文档全是 Markdown），初始化时用 --integration 换成你的工具即可（copilot / cursor / gemini 等）。命令名与流程完全一致。

Q6：多个特性怎么组织？

每个特性一个编号目录（specs/001-...、specs/002-...），章程全项目共享一份。特性之间通过 Git 分支或顺序开发隔离。

15.附录：速查表

15.1 命令速查

命令	何时用	产物
`specify init --here --integration claude`	项目开始，一次性	.specify/ 模板 + 技能
`/speckit-constitution`	项目开始，一次性（可修订）	.specify/memory/constitution.md
`/speckit-specify <需求描述>`	每个新特性	specs/NNN-*/spec.md + checklists/
`/speckit-clarify`	规格有重大歧义时（可选）	更新后的 spec.md
`/speckit-plan <技术约束>`	规格通过后	plan/research/data-model/contracts/quickstart
`/speckit-tasks`	计划评审通过后	tasks.md
`/speckit-analyze`	实现之前	对话内一致性报告
`/speckit-implement [范围]`	分析通过后，可分阶段调用	源码 + 测试
`/speckit-converge`	实现完成后	追加任务（差距闭环）

15.2 项目目录结构（最终形态）

elder-friendly-calculator_spec-kit/
├── .specify/
│   ├── memory/constitution.md        # 项目章程（全项目共享一份）
│   └── templates/                    # spec/plan/tasks/checklist 模板
├── .claude/skills/speckit-*/         # 9 个 spec-kit 技能
├── specs/
│   └── 001-elder-friendly-calculator/
│       ├── spec.md                   # 功能规格（唯一真相源）
│       ├── checklists/requirements.md# 规格质量清单
│       ├── plan.md                   # 实现计划 + 章程门禁
│       ├── research.md               # 技术决策（R1–R7）
│       ├── data-model.md             # 状态机与数据模型
│       ├── contracts/                # 引擎 API / UI 契约
│       ├── quickstart.md             # 端到端验证场景 V1–V4
│       └── tasks.md                  # 任务清单 T001–T029
├── ElderCalculator/                  # Xcode 工程（源码 + 测试）
└── docs/                             # 本指南

15.3 参考资料

spec-kit 官方仓库：github.com/github/spec-kit（含 spec-driven.md 方法论原文）
本实战项目仓库：elder-friendly-calculator_spec-kit（全部文档与提交历史可供对照学习）
WCAG 2.1：w3.org/TR/WCAG21（章程原则 V 的依据）

1.What：这是什么？

1.1 AI 原生开发（AI-Native Development）

1.2 规格驱动开发（SDD, Spec-Driven Development）

1.3 spec-kit 是什么

1.4 本指南的实战案例

2.Why：为什么需要 SDD？

2.1 直接让 AI「凭感觉写代码」（Vibe Coding）的四大问题

① 需求漂移

② 质量无标准

③ 复杂度失控

④ 无法交接与复现

2.2 SDD 如何解决这些问题

3.全流程总览

4.环境准备（一次性）

4.1 你需要什么

4.2 初始化项目

5.第 0 步：制定项目章程 建议必做

5.1 这一步在做什么（What & Why）

5.2 怎么操作（How）

5.3 本项目的真实产物（节选）

5.4 完成标志与提交

6.第 1 步：编写功能规格（Specify）

6.1 这一步在做什么

6.2 怎么操作

6.3 产物的骨架（照此评审）

6.4 质量门禁

7.第 2 步：制定实现计划（Plan）

7.1 这一步在做什么

7.2 怎么操作

7.3 产出的五份设计文档

8.第 3 步：分解任务清单（Tasks）

8.1 这一步在做什么

8.2 怎么操作

8.3 产物结构（tasks.md）

9.第 4 步：跨文档一致性分析（Analyze）实现前必跑一次

9.1 这一步在做什么

9.2 怎么操作

10.第 5 步：执行实现（Implement）

10.1 这一步在做什么

10.2 怎么操作

10.3 执行中的监督要点

10.4 本项目的执行结果

11.第 6 步：收敛收尾（Converge）

11.1 这一步在做什么

11.2 怎么操作

12.Git 版本化策略

13.最佳实践总结（来自实战的十条经验）

14.常见问题 FAQ

Q1：需求很简单，也要走完整流程吗？

Q2：规格写到一半发现需求有歧义怎么办？

Q3：AI 实现时偏离了任务清单怎么办？

Q4：规格写错了，已经进入实现了怎么办？

Q5：这套流程换其他技术栈/其他 AI 工具能用吗？

Q6：多个特性怎么组织？

15.附录：速查表

15.1 命令速查

15.2 项目目录结构（最终形态）

15.3 参考资料

5.第 0 步：制定项目章程建议必做