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。