我用 Claude Opus 4.6 + Figma，2 小时跑通了一个落地页——但"设计稿转代码"差点让我崩溃

我在 Figma 里做好了一个设计稿，然后对 Claude 说"帮我把这个变成网页"——它真的做到了，但不是你想的那种方式。

不是一键生成，不是完美还原，而是一场反复拉锯的人机协作：有的地方流畅得让我惊喜，有的地方卡住让我想摔键盘，最后产出的结果……说实话，比我预期的好，也比那些"AI 一键出网站"的宣传稿诚实得多。

这篇文章就是那两个小时的完整复盘。

---

一、为什么要测这个组合？

最近"AI 设计开发一体化"的说法满天飞。各种产品发布会、公众号文章都在讲：AI 可以帮你从需求到上线，效率提升 10 倍。

但这些内容有一个共同问题：说的都是结果，没人说过程。用的什么工具？卡在哪里了？最终代码质量怎么样？能不能真的上线？

我决定自己测一遍。

测试边界设定如下：

目标产品：一个 SaaS 工具的落地页，包含 Hero 区、功能介绍、定价表、CTA 四个模块
工具分工：Claude Opus 4.6 负责需求拆解 + 代码生成，Figma 负责视觉设计 + 标注导出
时间限制：2 小时内跑通可以在浏览器里预览的原型
成功标准：视觉还原度 70% 以上，代码可以正常运行，响应式基本可用

为什么选 Claude Opus 4.6 而不是 GPT 系列？主要原因是它在长上下文理解和代码生成的一致性上口碑更稳，而落地页这个场景恰好需要在一次对话里维持大量上下文。

---

二、2 小时测试全流程复盘

阶段一：需求拆解（0–20 分钟）

实际耗时：18 分钟 | 预期：15 分钟

这一步出乎意料地顺。我把产品的核心卖点、目标用户、竞品参考用一段话描述给 Claude，让它帮我拆解落地页的信息架构。

Prompt 示例 #1（可直接复用）：

你是一个有 10 年经验的产品设计师，擅长 SaaS 落地页设计。

我的产品是一个 AI 会议记录工具，目标用户是中小型团队的项目经理。
核心卖点：
1. 自动转录会议内容，准确率 90% 以上
2. 自动生成待办事项和决策摘要
3. 与 Notion、飞书无缝同步

请帮我设计一个落地页的信息架构，包含：
每个模块的名称和核心目标
每个模块需要展示的关键信息
模块顺序的逻辑（为什么这样排列）

输出格式：Markdown 列表，每个模块单独一段说明。

Claude 给出了一个结构清晰的信息架构，Hero 区的文案建议也直接可用。这一步我基本没有返工。

---

阶段二：Figma 设计（20–65 分钟）

实际耗时：45 分钟 | 预期：40 分钟

按照 Claude 给出的信息架构，我在 Figma 里快速搭了一个中保真度的设计稿。这一步是纯手工的，AI 没有直接参与设计本身。

关键操作：

用 Figma 的 Auto Layout 做组件，方便后面描述给 Claude
每个组件用语义化命名（hero-section、feature-card、pricing-table）
导出时用 Figma 的"Inspect"面板记录精确的颜色值、字号、间距

⚠️ 提示：这一步的命名规范非常重要，直接影响后面 Claude 能否准确理解你的设计意图。

---

阶段三：设计稿转代码（65–100 分钟）

实际耗时：35 分钟 | 预期：20 分钟

这是整个流程里最容易翻车的环节，也是本文的重点。

我先把 Figma 的 Inspect 数据（CSS 属性）和设计稿的截图描述一起发给 Claude，让它生成 React 组件。

Prompt 示例 #2（失败版）：

帮我把这个 Hero 区变成 React 组件，背景是深色渐变，
左边是文案，右边是产品截图。

结果：Claude 生成了一个"大概对"的组件，但渐变方向反了，文字大小完全不对，图片位置也偏了。

第 47 分钟，我第一次感到有点烦。

不是 Claude 不行，是我的 Prompt 信息量不够。它没有办法凭空猜测你的 Figma 里到底是什么样子。

Prompt 示例 #2 改良版（成功）：

帮我生成一个 React 的 Hero Section 组件，要求如下：

布局：
容器最大宽度 1200px，水平居中
左右两栏，左侧占 55%，右侧占 45%
垂直方向居中对齐

左侧内容：
标签：背景色 #E8F4FD，文字 #2B7FD4，圆角 20px，内边距 6px 16px
主标题：字号 52px，字重 700，行高 1.2，颜色 #1A1A2E
副标题：字号 18px，字重 400，颜色 #666，行距 1.6
按钮：背景 #2B7FD4，白色文字，圆角 8px，内边距 14px 32px

右侧：
一个 img 标签，src 用 placeholder，宽度 100%，圆角 12px
添加轻微阴影：box-shadow: 0 20px 60px rgba(0,0,0,0.12)

背景：
线性渐变：从 #F8FBFF（左上）到 #EEF5FF（右下）

请用 styled-components 或 Tailwind CSS（我更倾向 Tailwind）实现。

这次生成的代码，95% 都是对的，只需要微调一下字体大小。

生成代码片段对比：

原始版（失败 Prompt 的输出）：

// 问题：渐变方向错误，字号硬编码不合理
const Hero = () => (


标题



)

改良版（精确 Prompt 的输出）：

// 结构清晰，Tailwind 类名语义化，响应式已内置
const HeroSection = () => (




AI 驱动


会议记录，从此不再是负担

{/ ... /}


className="w-full rounded-xl shadow-[0_20px_60px_rgba(0,0,0,0.12)]" />



)

---

阶段四：调试上线（100–120 分钟）

实际耗时：20 分钟 | 预期：25 分钟

这一步比预期顺。把四个模块的代码拼到一起，用 Vite 起一个本地服务，主要调整了两个地方：

1. 定价表的边框颜色在深色背景下对比度不够，让 Claude 帮我调整

2. 移动端的 Hero 区两栏改成单栏，追加了一条响应式 Prompt

整体 2 小时内跑通，最终可以在浏览器里正常预览。

---

各阶段耗时对比： | 阶段 | 预期耗时 | 实际耗时 | 偏差原因 | | 需求拆解 | 15 分钟 | 18 分钟 | 来回确认了一次模块顺序 | | Figma 设计 | 40 分钟 | 45 分钟 | 定价表组件重做了一次 | | 设计稿转代码 | 20 分钟 | 35 分钟 | Prompt 写得不精确，返工一次 | | 调试上线 | 25 分钟 | 20 分钟 | 代码质量比预期好 | | 合计 | 100 分钟 | 118 分钟 | 基本在 2 小时内完成 |

---

三、最容易卡住的 3 个环节

卡点 ①：Figma 导出信息不够精确

踩坑描述： Figma 的 Inspect 面板给出的是 CSS 属性，但它不会告诉 Claude 这些元素之间的空间关系——谁在谁的上面、谁是谁的子元素、哪些元素是一个组件。 解决方案： 在 Prompt 里手动描述布局层级，用缩进表示父子关系：

页面结构：
section.hero（全宽，padding 80px 0）
  - div.container（最大宽 1200px，居中）
- div.left-col（55% 宽）
- span.tag（标签）
- h1.title（主标题）
- p.subtitle（副标题）
- button.cta（按钮）
- div.right-col（45% 宽）
- img.screenshot（产品截图）

这个"手写层级树"的方式，比直接粘贴 Figma CSS 属性有效得多。

---

卡点 ②：多组件的代码一致性

踩坑描述： 我分四次让 Claude 生成四个模块的代码，结果发现：Hero 区的按钮圆角是 8px，CTA 区的按钮圆角变成了 6px；Hero 区的主色是 #2B7FD4，功能介绍区变成了 #2980D4。颜色和圆角漂移了。 解决方案： 在第一条 Prompt 里建立一个"设计系统声明"，然后每次生成新模块时都在开头引用它：

【设计系统，每次生成都要遵守】
主色：#2B7FD4
文字主色：#1A1A2E
文字辅色：#666666
圆角规范：按钮 8px，卡片 12px，标签 20px
间距单位：8px 的倍数
字体：系统默认，fallback 顺序：-apple-system, BlinkMacSystemFont, sans-serif

把这段话固定在每次对话的开头，一致性问题基本消失。

---

卡点 ③：响应式布局的描述方式

踩坑描述： 我说"帮我做响应式"，Claude 生成的移动端布局把所有元素都堆成了一列，但字号没有缩小，间距也没有调整，在手机上看起来像是放大版的桌面端。 解决方案： 把响应式需求拆成具体的断点行为：

响应式要求：
桌面端（>= 1024px）：两栏布局，左 55% 右 45%
平板（768px–1023px）：两栏布局，左右各 50%，字号缩小 10%
手机（< 768px）：
  - 改为单栏，图片在上，文案在下
- 主标题字号改为 32px
- 左右内边距改为 16px
- 按钮宽度 100%

描述得越具体，生成结果越接近预期。这是整个测试里最反直觉的发现：AI 不需要你"聪明"，它需要你"精确"。

---

四、Claude Opus 4.6 在这个场景里的真实能力边界

测试完之后，我对 Claude Opus 4.6 在"设计转代码"这个场景里的能力有了一个比较清晰的判断。

它真的擅长的：

长上下文维持：在一次对话里生成四个模块的代码，前后的变量命名、组件结构基本保持一致，没有出现"忘记前面说过什么"的情况
复杂逻辑理解：定价表里有"每月/每年切换"的交互逻辑，我用自然语言描述了一遍，它一次就生成了可用的 useState 切换逻辑
代码可维护性：生成的代码有注释，组件拆分合理，不是一坨屎山

它不擅长的：

像素级还原：如果你的设计稿有精细的视觉细节（比如特定的阴影层叠、复杂的渐变），Claude 很难还原，需要你手动调整
动效细节：我让它做了一个按钮的 hover 动效，结果过渡时间和缓动函数都不对，来回改了三次
从截图直接生成：我试过把 Figma 截图直接发给它让它还原，效果远不如文字描述精确

与上一代相比的感受（主观体验）：

相比我之前用 Claude 3 Opus 的经验，Opus 4.6 在多轮对话的稳定性上有明显提升——同样的设计描述，我体感上少追问了 2–3 轮才能得到可用的代码。上下文越长，这个差距越明显。

本文测试使用的是 Claude Opus 4.6 的 API 接口。如果你想自己跑一遍，国内直连访问 Claude API 可以通过 [api.884819.xyz](http://api.884819.xyz) 完成，支持 Opus 4.6 在内的全系列模型，按量计费，不用挂梯子，新用户注册即送体验 token。文末附的 Prompt 模板可以直接粘贴进去测试。

---

最终落地页质量评分： | 维度 | 评分（1–10）| 说明 | | 视觉还原度 | 7/10 | 整体布局对，细节有偏差 | | 代码可维护性 | 8/10 | 结构清晰，组件化合理 | | 响应式适配 | 7/10 | 主要断点正常，极端尺寸有问题 |

---

五、适合谁用？怎么用才划算？

独立开发者

重点用代码生成这一步。你的 Figma 设计稿可以做得粗糙一些，但 Prompt 要写得精确。建议用"设计系统声明 + 模块层级树 + 具体断点行为"的三段式结构，每次生成一个模块，不要一次让它生成整个页面。

产品经理

重点用需求拆解 + 原型验证。你不需要真的把代码部署上线，用 Claude 生成的 HTML 文件在浏览器里打开就可以当原型给团队演示。这套流程可以帮你把"脑子里的想法"变成"可以点击的东西"，沟通效率提升明显。

设计师

重点用设计稿描述转组件。把你的 Figma 组件用文字精确描述出来，让 Claude 生成对应的代码组件，然后交给开发同学。这样可以减少"设计师说一套，开发实现另一套"的沟通损耗。

---

可复用的最小 Prompt 模板：

【角色】你是一个专业的前端开发工程师，擅长 React + Tailwind CSS。

【设计系统】
主色：[填入你的颜色]
文字色：[填入你的颜色]
圆角规范：[填入你的规范]

【任务】帮我生成 [模块名称] 的 React 组件。

【布局结构】
[用缩进描述父子关系]

【响应式要求】
桌面端（>= 1024px）：[描述]
手机端（< 768px）：[描述]

【注意事项】
颜色值必须与设计系统保持一致
组件要有 TypeScript 类型声明
添加必要的注释

---

务实的结论：

这套组合能帮你省掉大约 60% 的重复劳动——主要是"把设计意图翻译成代码"这件事。但剩下 40%——像素级调整、动效细节、边界情况处理——还是得你自己上。

AI 不是替代你的，它是帮你跳过"把脑子里的东西变成屏幕上的东西"这个最枯燥的环节。

---

这次测试里有一个问题一直困扰着我："设计稿→代码"这一步是整个链路里最脆弱的环节，而我用的工具（Claude）并不是专门为这个场景设计的。

那如果换成专门的代码生成工具呢？

下一篇我打算做一个横向测评：同一份 Figma 设计稿，分别交给 Claude Opus 4.6、v0.dev 和 Cursor，看谁的还原度更高、谁的代码更好维护、谁在"多轮对话调整"上更稳定。 这三个工具的设计哲学完全不同，对比结果可能会出乎你的意料。

如果你有想看的对比维度，评论区告诉我——比如"我最想知道哪个工具生成的代码最容易改"，这种具体的问题会直接影响我的测试设计。

---

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#AI设计 #Claude #Figma #前端开发 #AI工具评测 #落地页 #8848AI #Prompt技巧