用 Spec-Driven Development 让 AI 先写规格再写代码（Conductor 实战）

在支持 Conductor 的 CLI（Gemini CLI 或 Antigravity CLI）里，先初始化一个 spec 工作区：

# 进入你的项目目录
cd my-project

# 启动 Conductor，进入规格驱动模式
/conductor init

# 它会创建约定目录（示意）
#   specs/   存放 spec.md
#   plans/   存放 plan.md
#   artifacts/ 其它中间产物

别急着要代码，先用自然语言把需求聊透。Conductor 会把它沉淀成 spec.md：

你：我想做一个「团队请假审批」的小功能，
    能提交申请、主管审批、记录历史。

/conductor spec
# AI 反问澄清关键细节（示例）：
#  - 审批是单人还是多级？
#  - 数据存哪里（本地文件 / 数据库）？
#  - 要不要通知？

你：单人审批即可，存 SQLite，审批通过发站内通知。
# AI 生成 specs/leave-approval.md

规格定了，下一步让 AI 把实现拆成有序步骤，写进 plan.md：

/conductor plan

# 生成的 plans/leave-approval.md 类似：
# 1. 设计 SQLite 表结构（applications / approvals）
# 2. 实现提交申请接口
# 3. 实现主管审批接口（含状态机）
# 4. 实现站内通知
# 5. 补单元测试与迁移脚本
# 每步标注：依赖、预计改动文件、验收点

计划你点头了，再让 AI 按步骤实现。每完成一步，对照 plan 的验收点：

/conductor implement --step 1
# AI 只做「设计表结构」这一步，并汇报改动

# 你 review 后继续
/conductor implement --step 2
/conductor implement --step 3

# 随时回到规格：需求变了就改 spec.md，
# plan 会自动提示哪些步骤受影响

spec.md / plan.md 是纯文本，直接进 Git，等于白捡一份永远和代码同步的设计文档：

git add specs/ plans/
git commit -m "feat: 请假审批 规格与计划"

# 新人接手：读 specs/ 就知道为什么这么设计
# Code Review：先审 plan 再审代码，方向错一眼看出
# 复盘：需求为什么变，spec 的 diff 就是证据

官方建议拿一个中等复杂度功能试跑，重点看规格文件是否真的减少了返工：

验收清单（跑完一个功能后填）：
□ 代码写完前，需求细节是否已在 spec 对齐？
□ 有没有出现「AI 自作主张加了不需要的功能」？
□ 需求变更时，是否只改了少数几步 plan？
□ Review 是否先审 plan 再审代码、更高效？
□ 总体返工次数 vs 直接写代码是否明显下降？