猫拽智库
结论先行：代码生成质量的上限，由设计器对约束的表达能力决定，而不是由生成算法决定。同一套拖拽操作，出口不同，结果差一个量级：截图式产出的是像素坐标，改一次文案要重画；组件树与源码出口产出的是可维护结构，改文案只改一个属性。选设计器时，先问它交付什么，再问它生成得多快。
一、四种出口
1. 截图式（Screenshot-to-Code）
输入是一张图或一次画布渲染结果，输出是绝对定位的样式代码。优点是任何设计稿都能转，缺点是结构信息丢失：一个按钮被拆成背景块加文字层，后续无法按组件语义修改。
2. DSL（Domain-Specific Language）
输出是一份描述页面的领域语言文档：节点类型、属性、样式、绑定关系。DSL 本身不是代码，需要渲染器解释执行。优点是跨端一致、可做版本对比；缺点是可读性依赖工具支持。
3. 组件树（Component Tree）
输出是带语义的组件层级，例如"页面 → 卡片 → 标题 + 按钮"。优点是结构清晰、可直接映射到前端框架；缺点是要求设计器内置组件语义，自由绘制能力受限。
4. 源码（Source Code）
输出是可直接运行的前端代码。优点是脱离平台也能维护；缺点是生成质量高度依赖模板，二次修改后难以再次回到设计器。
二、四种出口对比
| 出口 | 产物形态 | 可维护性 | 能否回流设计器 | 适用场景 |
|---|---|---|---|---|
| 截图式 | 绝对定位样式 | 低，改文案常需重画 | 否 | 一次性原型、视觉参考 |
| DSL | 结构化描述文档 | 中高，可版本对比 | 是 | 多端渲染、低代码平台 |
| 组件树 | 语义组件层级 | 高，贴合前端工程 | 是 | 与设计系统配套的项目 |
| 源码 | 框架代码 | 高，但会逐渐脱离设计器 | 部分 | 需要自主托管的交付 |
读表方法：第三列决定"改一次要多久"，第四列决定"设计与代码会不会分叉"。分叉一旦发生，后续每次调整都要改两处。
三、代码生成质量取决于约束
同一个设计器，两个人拖出来的代码质量可能差 3 倍，差别不在操作熟练度，而在是否受约束。
设计规范约束。 间距是否只能取 4 的倍数、颜色是否只能取设计令牌（Design Token）、字号是否有层级。没有约束时，画布上会出现 13px、17px、22px 这类随手数值，生成代码里就是一堆魔法数字。
布局约束。 元素是"距左 120px"还是"左边距占 1 栅格"。前者生成绝对定位，后者生成弹性布局。响应式能力在拖拽那一刻就决定了。
语义约束。 拖出来的是"一个带圆角的蓝色矩形加文字"，还是"一个主要按钮"。前者只能生成样式，后者能生成组件与交互属性。
因此，设计器的价值不只是"画得快"，而是"把规范变成不可绕过的选项"。约束越强，生成结果越稳定；约束越弱，越依赖人工修。
响应式具体怎么落地，见拖拽出来的页面怎么做响应式布局。
四、设计器与设计系统的关系
一套能稳定产出代码的设计器，背后通常有三样东西：
- 组件库：组件的属性与状态被完整建模，而不是只建模外观。
- 令牌体系：颜色、字号、圆角、阴影统一命名，换主题只改令牌。
- 布局规则：栅格与约束模式明确，哪些容器可自由定位、哪些必须流式排列。
三者缺一，生成代码就会退化为"样式堆叠"。这也是为什么很多设计器演示效果很好，交付给开发后仍需重写。
五、评估设计器的 5 个动作
- 拖一个卡片列表，改数据条数，看布局是否自适应。
- 把主色改一个令牌，看整页是否同步更新。
- 生成代码后，手工改一处文案，看能否回流设计器。
- 检查生成代码里是否存在大量固定像素与重复样式。
- 换一个端预览，看结构是否保持一致。
第 3 步最关键：能回流，说明设计器与代码共享同一份结构；不能回流，说明代码是"一次性快照"。这类工具适合做原型，不适合做长期迭代的产品。
AI 生成的结果同样要落到这些约束里，见AI + 拖拽：下一代页面构建方式。
FAQs
Q1：代码生成会不会取代前端开发？
A：在标准页面范围内会替代大量重复劳动，在复杂交互上不会。列表、表单、详情这类结构固定的页面，生成质量已可用于生产；手势交互、动画编排、性能调优仍需人工。现实的分工是"生成打底、人工收口"。
Q2：DSL 和源码，哪个更适合长期项目？
A：看团队要不要脱离平台。DSL 的优点是跨端一致、结构可版本管理，缺点是依赖渲染器；源码优点是自主可控，缺点是容易与设计器分叉。多数团队的做法是 DSL 为主、关键模块导出源码，两者并存。
Q3：设计规范不统一，能靠设计器补救吗？
A：不能。设计器只能执行约束，不能发明约束。规范缺位时，设计器会把混乱放大：同一页面出现 5 种间距、4 种圆角，生成代码同样混乱。先统一令牌与组件命名，再谈代码生成效率。
