AI 辅助开发的局限
- 历史对话里堆满了临时决策和反复调整的信息，感觉 AI 在变笨
- AI 完成了几个任务之后，忘记了最初的任务
- AI 一直猜整个系统的意图
- 同样的描述，不同的时间，生成的代码结构完全不同
- 代码的行为和测试一致，但是保证不了结构设计和系统一致
- 规格缺失，导致 AI 审查出错
- .......
解决这些问题，需要让 AI 更稳定的输出。
SDD 是什么？
用规范约束模型，把上下文喂给模型，用工作流复用经验，使用规范驱动开发。
Agent 和 SubAgent
每次和 Claude code 的对话，本身就是一个 Agent 会话，有完整的上下文、工具访问权限，当这个 Agent 遇到可以并行处理的任务时，可以派生出多个 SubAgent。每个 SubAgent 都会完成一个子任务，执行完成后把结果返回给主 Agent。
| 主 Agent | Subagent | |
|---|---|---|
| 上下文 | 完整对话历史 | 只知道被交代的那个任务 |
| 状态 | 有状态，负责协调 | 无状态，执行后结束 |
| 数量 | 单个 | 一次可以多个并发 |
| 职责 | 理解全局、分配任务、汇总结果 | 聚焦一个子任务，做到最好 |
配置 FastAPI Agent 来处理写后端
配置前端 Agent
SDD 工程流详解
阶段一：澄清需求
目的：定义规范，为后续的制定计划、任务分解和具体实现提供准确的依据
定义规范的核心作用：
-
确定功能边界与需求
- 将模糊的用户描述转化为具体的功能规格说明
- 确定功能的优先级层次
-
定义验收标准
- 制定验收场景
- 定义测试标准
- 准保每个功能都有可测试的输出标准
-
规范文档输出
- 核心功能的规格文档
- 功能的优先级矩阵
如果是自己的想法，比如：自己有一个模糊的想法需要落地。这时就需要先对这个想法深入讨论，参考同类竞品，讨论具体的难点 ......，在实际的企业项目中，这些步骤都是有人替你做的。office-houers 通过六问，输出一篇方向共识文件：这个产品在定义什么，核心假设是什么、最大的风险在哪里 ......
brainstorming 做的事：就是把需求的假设，澄清到开发之前
Claude code 把模糊的地方，拿出来和开发讨论，避免代码生成完了，才发现生成的方向错了
讨论结束之后可以得到计划文档
阶段二：计划实施
脑爆阶段的想法比较发散，当进入执行时，需要使用 openSpec 收敛并固化，固化的顺序是：proposal（做什么/为什么）--> design（怎么做）--> tasks（怎么落地）
设计稿来自figma，需要为 Claude code 连接 figma 的mcp
设计稿：Figma
"mcpServers": {
"figma": {
"type": "http",
"url": "https://mcp.figma.com/mcp"
}
},
接下来按照 tasks 写代码
阶段三：验证与回归
对照 spec 做验收，在这个过程中测试、验收、回归、修复，会产生修复代码，但不是首轮主产出
阶段四：归档
归档阶段就是把“做完”升级为“可维护、可追溯、可复用”，这个阶段做的事：
- 确保 tasks 对应的目标都完成，没有完成的项要转化为后续事项
- 关键的计划决策、接口约束都要固化
- 沉淀本次的有效实践和踩坑，提炼为下一轮可服用的模版
- 保存测试结果、回归结论
最终实现
可以看到已经按照 figma 设计稿还原页面，并且后端服务也可以正常使用
一些经验
-
不要让多个 agent 同时修改一个文件
-
配合 CLAUDE.md、 hooks、skills、agent、记忆 ...... 进行开发
-
合理的拆分任务
- 拆分的太细，不知道任务整体执行到哪一步了
- 拆分的太粗，AI 一次修改很多文件，完成一个任务之后，开发看不懂「AI 完成了什么」
- 注意任务之间的依赖关系，如果依赖的任务执行顺序靠后，计划阶段看不出错误，执行时就会报错
-
计划实施阶段，每个任务可以派出一个子代理完成任务，可以参考 superpower:subagent-driven-development
- 子代理完成之后，主代理做审查，确认没问题再启动下一个任务，这样单个子代理失败也不会影响其他子代理
- 不要让子代理自由发挥，可以在每个任务的task里做限制
-
计划写完不等于计划可用，需要人工自检
-
不要把模糊的任务留到执行阶段
-
把设计稿蒸馏出一个 skill，让设计稿直接吐出可以使用的组件，把设计稿蒸馏出 token 表加组件规范，把这些最终写入design.md
什么时候不需要使用 SDD
SDD 强调规格先行，在执行的过程中会消耗掉较多 token，所以也不是所有的场景都适合使用 SDD，有的场景只需要使用 Plan，改完之后，让 AI 更新一下 spec 文档就可以了，只有涉及模块多，传统开发耗时长...... ，才适合使用 SDD。
以下场景直接使用 Plan 就行了
- 已有系统的 bug 修复或小特性补充
- 改动量很小
