Design-Driven Development 是什么？Figma 设计稿也是 AI 时代的 spec
把 Figma 设计稿当 spec 用，AI 写页面才有收敛条件——这套做法可以叫 DDD（Design-Driven Development）。
- spec 分两层：文字管行为 ，设计稿管视觉，markdown 写不出间距是 32 还是 40。
- 给 AI 一个停止条件：截图对比设计稿，视觉差异就是可判定的验收标准。
- 协作契约：按 frame 分工，人和 agent 的接口都是设计稿，不是口头描述。
- 省 token：反复 prompt 试布局，比在 Figma 里拖两下贵一个量级。
- 改得动：需求变更直接改设计稿，不用重写一遍 prompt 再全量重生成。
- 例外：单人开发、无协作、token 预算充足，直接 coding 也没问题。
- 短板：Figma 画布里那个 AI 现在还偏弱，内置模型有待优化。
设计稿是 spec 的视觉那一半
Spec-driven development 这两年被讲透了：先写 spec，再让 agent 照着 spec 实现，spec 是唯一事实来源。但落到页面开发上，纯文字 spec 有个绕不过去的洞——它描述不了视觉。
你可以在 markdown 里写「卡片列表，三列，卡片带阴影」，agent 也能照做。然后你会发现间距不对、圆角大了 2px、阴影虚了一圈、字重差一级。这些不是 agent 不听话，是 spec 本身没有这个信息量。继续往文字 spec 里塞 gap: 24px 这种细节，写到第三个组件你就会放弃——那不是在写 spec，是在用自然语言手写 CSS。
设计稿天生就是这一层的载体。Frame 尺寸、auto layout 的 padding、color variable、text style、组件实例，全都是结构化的、有确定数值的。通过 Figma MCP 读出来的不是一张图，是一棵带完整样式数据的节点树。
所以更准确的说法是：文字 spec 和设计稿是同一份 spec 的两个投影面，前者定义行为与边界，后者定义效果。DDD 不是要取代 SDD，是把 SDD 缺的那一半补上。
真正的价值：AI 终于有了停止条件
这是我觉得最被低估的一点。
AI 写页面最难的不是写不出来，是不知道什么时候算写完了。模型的自我判断只能到「看起来差不多是个卡片列表」，它没有 ground truth，于是要么早停，要么在你反复说「再调一下」的过程中来回抖动，越改越乱。
有设计稿之后，这个环节变成一个可闭合的循环：
设计稿在这里的角色是视觉断言。跟单元测试之于逻辑正确性是一回事：测试给出行为的判定标准，设计稿给出效果的判定标准。有了判定标准，agent 才能自己跑循环、自己判断收敛，而不是靠你当人肉 assert。
光有设计稿不够，还得让 agent 能看到自己写出来的东西。Figma MCP 负责读设计侧（get_design_context / get_screenshot），Chrome DevTools MCP 之类的负责截实现侧，两张图能对比，循环才真正闭上。
协作场景：设计稿是唯一契约
多人开发时，设计稿的价值从「给 AI 看」变成「给所有人看」。
按 frame 切分工是最自然的划分方式：谁领哪个页面、哪个组件，边界在设计稿上一目了然，不需要开会对齐「你说的那个弹窗是哪个弹窗」。设计系统里的 color variable 和 component 又天然保证了各人产出的一致性——大家引用的是同一套 token，不会 A 写 #3b82f6、B 写 #3d80f0。
多 agent 并行也一样，甚至更需要。人能靠聊天弥补契约缺失，agent 不能：三个 agent 各写一个页面，没有共享设计稿的话，产出的风格必然漂移。设计稿就是它们之间那份不用解释的接口定义。
为什么不直接 AI coding？
「反正 agent 能写，让它直接写不就完了。」我一开始也这么想，后来有三个原因让我改主意。
| 维度 | 直接 AI coding | 先做设计稿（DDD） |
|---|---|---|
| token 消耗 | 视觉靠猜，多轮试错反复重写 | 一次读稿，差异定向修 |
| 设计质量 | 模型的默认审美，同质化 | 专业设计产出，可 1:1 复刻 |
| 改需求 | 重描述 + 重生成，容易连带改坏 | Figma editor 拖两下，重跑对齐 |
| 多人协作 | 无共享契约 | 设计稿即契约 |
token 那条最实在。视觉调整的每一轮都是「生成 → 你看 → 你描述哪里不对 → 重写」，一个页面来回五六轮很常见，每轮模型都要重读一遍上下文。设计稿把这些轮次前置成了一次结构化输入。
设计质量那条更容易被忽略。让模型自由发挥，出来的大概率是那套熟悉的味道：紫渐变、圆角过大、层次全靠阴影。有设计稿之后，agent 的任务从「设计 + 实现」降级成「实现」——这是它更擅长的那半。
什么时候可以跳过设计稿
不必教条。同时满足下面几条时，直接 coding 完全没问题：
- 单人开发，没有协作和交接
- token 预算充足，多试几轮不心疼
- 页面是探索性质的，视觉本身还没定，正在拿代码当草稿
- 内部工具、admin 页面这类视觉要求本来就不高的场景
DDD 的成本是要先有一份设计稿。这份成本在协作和高保真场景下立刻回本，在一个人写 admin 后台的时候就是纯负担。
Figma 自己的 AI 还不够用
一个诚实的补充：现在 Figma 画布里已经能用 AI 直接生成和修改设计了——不是 Figma Make 那条 prompt 直出 app 的路线，而是在 Design 编辑器里生成可编辑的图层。这条路走通之后，DDD 里「先得有设计稿」这个前提门槛会低很多，不会设计的人也能起个稿。
但目前它偏弱。内置模型的产出质量和外面那些专门做 AI 设计的工具还有差距，复杂布局和设计系统一致性上尤其明显。不过 Figma AI 也在不断进步。这样高效产出的设计稿在 AI 时代最大的身份变化，不是「给开发看的图」，而是一份机器可读、人可编辑、团队共享的视觉 spec。