什么是从设计到代码？
从设计到代码指的是把在 Figma 等工具里做出的决定变成可运行的前端代码。真正耐用的做法是传递设计 Token，而不是从画布生成标记：界面改变时 Token 依然有效，生成的标记则不然。
两种被混为一谈的做法
从画布生成代码。 把工具对准一个 Figma 画框，拿回 JSX 或 HTML。这在演示里极其好看，在生产里让人失望：产出跟你的组件库毫无关系，嵌套结构反映的是设计师怎么给图层分的组，而设计一改你就重新生成，之前的改动全丢。
把决定搬过去。 改为搬运 Token——颜色、间距、字体、圆角——让工程师去写引用这些 Token 的组件。演示里没那么亮眼。但这是能活下来的那条路，因为布局变了 Token 依然成立，也因为代码始终是人写的、人能维护的代码。
几乎每个试过第一条路的团队，最后都落到第二条上。
交接为什么一直失败
失败不在交接的那一刻，而在之后的一切。
设计师在 Figma 里改了一个颜色。这个改动得走到样式表里。没有自动通路，于是它经由某个频道里的一条消息传达，有人看到，或者没看到。把这件事乘以一年里的每一次改动。
两边都在正确地工作。连接两边的是一个记得这件事的人。
Figma API 的限制
在评估这个领域的任何工具之前值得知道：Figma REST API 中用于读取变量的端点，只在 Enterprise 套餐里提供。
也就是说，一个通过 REST API 同步 Figma 变量的工具，在 Enterprise 账号的演示里能跑，在大多数团队实际使用的 Professional 套餐上什么也不做。插件不受此限制，因为它们通过插件 API 从文件内部读取变量。如果你在比较同步类工具，就问清楚各自用的是哪一种。
一个跑得通的闭环长什么样
- 设计决定以 Token 的形式存在，放在两边都引用的同一个地方。
- 设计侧的改动以 diff 的形式到达，而不是覆盖。
- 有编辑权限的人评审并应用它。
- 仓库上打开一个 pull request，走正常的代码评审。
- AI 智能体实时读取同一套 Token，于是生成的代码落在系统之内，而不是系统旁边。
中间那个评审环节不是应该被优化掉的摩擦。一个悄悄改写团队 Token 的工具，损失的信任比自动化带来的收益更多。
这与 Flash DSM 的关系
Flash DSM 用 Figma 插件作为传输方式，因此在任何 Figma 套餐上都能工作。一次发布会变成可评审的 Token diff，通过的 diff 可以作为 pull request 打开。