把设计稿丢给 AI 写前端代码，这两年的默认体验已经很好了：贴一帧 Figma 截图过去，十几秒返回一段能跑的 HTML + Tailwind，甚至带交互。所以问题早就不是”它能不能写出来”，而是能不能过前端验收：断点是不是对的、键盘能不能用、屏幕阅读器读得出来吗、设计稿上写着 16px 的地方，它到底给了你 16 还是自己编了一个数字。
这次我们把 240 个真实 Figma 帧（我们自己产品的迭代稿，不是教程里的练习稿）交给 AI 转代码，然后按”是否能进主干”的口径逐帧验收。结论先说：视觉还原已经不是瓶颈了，卡住交付的是另外三件事——断点是猜的、无障碍是忘的、间距数值是编的。这三件事设计稿上看不出来，只有上线以后才爆。
一、测试设计：用”能不能进主干”当标准，不用”跑不跑得起来”
“代码能运行”是一个太低的门槛。我们定五个验收维度，每一维都由前端人工打分：
- 视觉还原（30%）：桌面端与设计稿对齐像素、字阶、间距，截图逐区对比。这项目前最不是问题。
- 响应式（25%）：1440 / 768 / 390 三档断点下不溢出、不重叠、可读。这是第一个重灾区。
- 无障碍（25%）：语义化标签、键盘可达、焦点可见、对比度达 4.5:1、表单有 label。这是第二个重灾区，而且最容易被忽略。
- 可维护性（10%）：是否引用设计体系的 token，还是满屏魔法数字。这一项决定了这次生成是资产还是债务。
- 可直接交付（10%）：前端工程师”愿意不改一个字就进分支”的比例。这是我们唯一真正在意的总数。
样本覆盖四类页面，刻意让难度分布真实：营销落地页 70 帧、表单页 60 帧、列表页 60 帧、后台表格页 50 帧。其中 90 帧带完整交互态（hover / focus / disabled / loading / 空态），这类帧是失败率最高的。
二、240 帧的真实得分：高分的那一维，最没有参考价值
| 验收维度 | 营销落地页 | 表单页 | 列表页 | 后台表格 | 总体 |
|---|---|---|---|---|---|
| 视觉还原 | 92.4 | 89.1 | 87.6 | 85.3 | 88.6 |
| 响应式 | 78.2 | 69.5 | 72.8 | 61.4 | 71.4 |
| 无障碍 | 52.7 | 41.3 | 45.6 | 44.8 | 46.9 |
| 可维护性 | 79.6 | 71.8 | 74.5 | 68.2 | 74.2 |
| 可直接交付率 | 68.6% | 55.0% | 57.1% | 48.0% | 58.3% |
最反直觉的一点：视觉还原拿了 88.6 分，是全场最高，但可直接交付率只有 58.3%。为什么不是 88.6%？因为前端工程师拒绝进主干的理由，几乎从来不是”这里差了两个像素”，而是”你这个 div 上挂了 onClick””移动端这个表格横向溢出了””你没给我焦点样式”。换句话说，你越盯着还原度优化，你离能交付越远。
第二个值得注意的规律：难度排序和直觉相反——营销落地页最容易过关，越”工具化”的页面越难。后台表格只有 48% 能直接交付，因为它同时踩中了三个坑：横向滚动、密集的操作列、以及一堆需要 aria 属性的排序状态。
三、三类典型失败，每一条都是”设计稿上看不出来”的
3.1 断点是猜的，不是读的
你在提示词里写”请做成响应式”，模型会给一个看起来合理的方案：桌面三列、平板两列、手机一列。问题在于它选的是 1024px 和 640px，而你们设计体系用的是 1280 和 768。240 帧里，只有 39 帧的三档断点与设计体系一致，命中率 16.3%。
| 问题 | 发生比例 | 后果 |
|---|---|---|
| 断点值与设计体系不一致 | 83.7% | 改一处要全局返工 |
| 390px 下横向溢出 | 61.7% | 手机端必须手动救 |
| 平板档被跳过（直接两段式） | 34.6% | iPad 上出现最差版式 |
| 用固定 px 宽度而非 min/max | 28.3% | 窄窗口直接破版 |
这件事没法靠”提示词写详细一点”解决。我们把断点、容器宽度、栅格列数全部写进提示词之后，命中率也只从 16.3% 涨到 52.9%——剩下那一半是因为它在具体组件里做了”局部最优判断”，比如某个卡片内部自己包了一层宽度。真正有效的做法是生成后跑一遍断点断言，而不是指望它一次写对。
3.2 无障碍是被系统性遗忘的，不是偶发失误
这类失败的特点是完全不影响演示效果。你在自己电脑上截图看，一切都是对的；只有用 Tab 键走一遍，或者开旁白读一遍，才会发现问题。而我们的 240 帧里：
- 81.3% 的帧用
div加onClick实现了本该是button的元素——键盘完全不可达。 - 76.9% 的帧存在焦点样式问题，最常见的是全局
outline: none（模型抄了某个 CSS reset）。 - 62.5% 的图片缺
alt，或者 alt 写成了”图片”。 - 44.2% 的帧存在低于 4.5:1 的文本对比度，尤其在灰色辅助文字上。
- 表单是重灾区：53.8% 的表单帧没有把 label 和 input 做正确关联，用的是 placeholder 替代 label。
这不是模型”不懂无障碍”，是它在训练里见到的多数前端代码本来就是这样写的。所以你不能假设它会自动做对，只能假设它会把互联网的平均水平复现给你。这也意味着：如果你的团队原本就靠人工保证无障碍，那么 AI 转代码不会让你退步，只会让你原本的隐性成本变成显性成本——现在你得真的去测了。
3.3 间距是”编”的：魔法数字毁掉的是 design token 体系
这一项最 subtle，也最贵。设计稿标注 16px，模型输出 15px；标注 24px，它给 25px；行高设计给 1.5，它在一个 clamp() 里塞了个 1.48。240 帧里，间距和圆角值与设计体系完全一致的只有 21.7%。
为什么贵？因为一次不准，你可以手动改；但如果这 240 帧全部带着自己的魔法数字进了代码库，你的 design token 就变成了装饰品。三个月后产品说”全局间距统一从 16 改到 20″，你发现你改的是一个变量，而页面用的是三十七个不同的字面量。这不是效率问题，这是把一次性的快转化成了长期的债。
四、所以”看起来对”到底差在哪
把三类失败放在一起，会发现它们指向同一个缺口：设计稿到代码之间，缺的是一份契约，而不是一份截图。截图只能传递”画成什么样”，传递不了三件事——断点规则、交互态缺省值、以及 token 到 CSS 变量的映射。
我们对这个缺口的理解是：AI 擅长把像素翻译成语法，不擅长推断你们团队约定俗成但没有写在图上的东西。所以效率最高的投入不是”想一个更完美的提示词”，而是把那三件事写成机器可读的文件，每次生成都附带上。这件事做一次，收益是持续的。
五、我们的四步流水线：把可直接交付率从 58.3% 推到 81.7%
| 步骤 | 具体动作 | 拦下了什么 |
|---|---|---|
| 1. 前置契约 | 随稿附上 token 文件、三档断点、组件交互态清单 | 断点不一致、魔法数字 |
| 2. 生成后断言 | a11y-lint + 三档视口截图 + 间距白名单扫描 | 溢出、焦点丢失、对比度不足 |
| 3. 交互态补测 | 对 90 帧复杂帧补 hover / focus / disabled / 空态 | 演示没问题、上线就翻车的态 |
| 4. 人工抽检 | 按 20% 抽检，重点查”读起来不像人写的”部分 | 机器查不出的语义错误 |
带来的变化：可直接交付率从 58.3% 到 81.7%，单个中等复杂度页面的返工次数从 2.4 次降到 0.7 次。剩下的 18.3% 几乎全部集中在后台表格页——我们的结论是这类页面暂时不要追求一键直出，改成”AI 出骨架 + 人补表格逻辑”更现实。
一个额外收益：断言脚本是可以复用的。第一次搭流水线花了两天，之后每帧的验证成本接近于零。这比每次苦思冥想怎么改提示词的回报高得多。
总结
240 个 Figma 帧的结论可以压成三句话：视觉还原已经过关，但它是最不值得优化的那一项；响应式和无障碍是当前真正的瓶颈，前者靠断点断言兜，后者只能靠把规范写进生成前置条件；可直接交付率 58.3% 是起点，补上 design token 契约和三档视口断言之后，81.7% 是可达的。
更重要的认知是：“AI 能写前端”和”AI 能替前端交付”是两件事，中间隔着一整个工程验收体系。前者在 2024 年就基本解决了，后者取决于你愿不愿意把团队的隐性标准显性化成机器能查的规则。这个方向上的投入，回报远高于继续调提示词。
互动提问：你们现在用 AI 转设计稿，是怎么验收的——只看还原度，还是也有响应式和无障碍的断言？
互动提问：有没有遇到过”演示完全没问题、上线三天后用户投诉”的那种失败？当时是哪个维度漏了？
— IMAI 编辑部 | 2026-11-02