规格驱动开发（Spec-driven development）配合 AI 助手
方法目标
把自然语言需求先转写为 proposal、spec、design、tasks 等结构化文档，再让 AI 助手按这些文档推进开发，在保留自然语言开发速度的同时提高复杂项目的可控性与可审查性。
它与 wiki 现有方法形成互补关系：
文档分层
- proposal：回答"为什么做、范围是什么"。一份变更对应一份 proposal，便于追溯。
- spec：回答"做什么、怎么算完成"。包含用户场景、行为描述和验收条件；用场景和验收条件消除需求歧义。
- design：回答"怎么做"。对复杂架构选择补充关键技术决策、依赖、权衡。
- tasks：回答"先做什么、再做什么"。把实现拆为可逐项推进的清单，每项任务可单独由 Agent 执行并验证。
- archive：完成后保留决策与实施历史，让 Agent 在不同会话回到同一份约束。
操作流程
- 用 proposal 描述这次变更的原因与范围。
- 把用户场景、行为与验收条件写入 spec。
- 对复杂架构选择补充 design，记录关键技术决策。
- 将实现拆为 tasks，让 Agent 一项一项执行。
- 每项任务完成后运行测试并对照 spec 验收。
- 完成变更后归档文档，保留决策与实施历史。
角色分工
- AI 协助：起草规格、发现遗漏、拆分任务、生成实现。
- 人工确认：业务目标、技术边界、完成标准。
- 验收环节：运行测试并对照 spec 验收，不能仅依赖 Agent 自报"已完成"。
适用情况
- 跨文件功能、需多文件协调的实现。
- 多人协作、需长期维护的项目。
- 容易被 Agent 误解或上下文较复杂的任务。
- 需要保留决策历史供后续会话回看的项目。
不适用情况
- 一次性脚本或极小改动（前期文档成本不划算）。
- 没有清晰业务目标或验收标准的"先做着看"型任务——spec 写不出来，方法也走不通。
关联任务
风险与边界