我用 Claude Opus 4.6 + Figma 建了一个网站，2小时跑通了——但有一个环节卡了40分钟

2小时能跑通，但有一个环节我卡了40分钟，而且几乎所有人都会卡在同一个地方。

先把结论放在最前面：这套流程是真实可行的，不是"AI一键建站"那种标题党。但"可行"和"顺畅"之间，隔着三个非常具体的坑。这篇文章不是成功案例秀，是一份带时间戳的操作日志——包括那些让我骂出声的时刻。

---

为什么选这个组合？为什么卡死2小时？

Figma 是国内设计师最熟悉的工具，几乎没有之一。Claude Opus 4.6 在代码生成和上下文理解上有明显升级，尤其是对设计描述的"意图理解"能力，比之前的版本更稳。两者组合，代表了当下"非程序员独立建站"的最高水位线。

测试边界我设得很具体：目标是一个落地页级别的静态网站，包含导航、Hero区、功能介绍、FAQ、页脚，不含后端，不含支付，不含用户系统。时间卡死2小时，超时就是超时，不补时。

为什么是2小时？因为这是一个"有意义的门槛"——能在2小时内跑通，意味着这个流程对普通设计师或产品经理有实际价值；跑不通，就说明它还是一个需要开发者参与的流程。

---

完整流程拆解：每一步实际花了多少时间

时间轴总览

| 环节 | 预期耗时 | 实际耗时 | 偏差 | | ① Figma 设计稿准备 | 15 min | 18 min | +3 min | | ② 导出资产 / 标注 | 10 min | 12 min | +2 min | | ③ 向 Claude 描述需求，生成 HTML/CSS | 20 min | 25 min | +5 min | | ④ 组件细化与迭代对话 | 25 min | 40 min | +15 min | | ⑤ 响应式适配调试 | 20 min | 25 min | +5 min | | ⑥ 部署上线 | 10 min | 15 min | +5 min | | 合计 | 100 min | 135 min | +35 min |

总时长 135 分钟，压线通过。但那 40 分钟的环节④，差点让整个测试崩掉。

---

环节①：Figma 设计稿准备（实际 18 分钟）

我用的是 Figma Community 里的一套 SaaS 落地页模板，改了配色和文案。这步比预期快，主要是因为有现成模板可以改，从零设计会慢很多。

给小白的提示：不要从空白画布开始。Figma Community 里有大量免费的落地页模板，选一个结构接近你需求的，改内容就好。这一步的目标不是"设计出完美的稿子"，而是"给 Claude 一个可以描述的参照物"。

---

环节②：导出资产 / 标注（实际 12 分钟）

这里有个细节很多人会跳过：光截图给 Claude 是不够的。你需要把关键参数手动整理出来：

  • 主色 / 辅色的 HEX 值
  • 标题字号（H1/H2/H3）和行高
  • 卡片的内边距、间距
  • 按钮的圆角半径

我用了一个笨方法：在 Figma 里直接截图，然后把上面这些参数打成一段文字，一起粘给 Claude。后来发现 Figma 的 Dev Mode 可以直接复制 CSS 属性，但 Dev Mode 是付费功能，所以手动整理是更通用的方案。

---

环节③：向 Claude 描述需求，生成 HTML/CSS（实际 25 分钟）

第一轮 prompt 我给了大概 400 字的描述，包括页面结构、色彩规范、字体参数，以及"这是一个 SaaS 产品的落地页，目标用户是中小企业主"这样的语境信息。

Claude Opus 4.6 第一轮的输出质量让我有点意外——结构基本对，Hero 区的布局和我描述的一致，颜色也用上了。问题主要出在两个地方：

1. 它自作主张加了一个渐变背景动画，我完全没要求，删了 5 分钟（这里我骂了一声）

2. FAQ 部分它用了

标签做折叠，交互逻辑没问题，但样式需要重写

这一轮的核心产出：约 350 行 HTML + CSS，可以在浏览器直接打开，视觉还原度大概 70%。

---

环节④：组件细化与迭代对话（实际 40 分钟）⚠️ 卡点在这里

这是整个流程最耗时的环节，也是最容易出问题的地方。详细拆解放在下一章。

---

环节⑤：响应式适配调试（实际 25 分钟）

Claude 默认给的断点是 768px 和 1024px，这是标准的 Bootstrap 逻辑，但不符合国内主流设备的实际情况。国内用户的手机屏幕主要集中在 375px（iPhone SE/标准版）和 390px（iPhone 14/15 系列），平板场景少，直接跳到 1440px 的宽屏。

我告诉 Claude 把断点改成 375px / 750px / 1440px，它很快就改好了，但改完之后导航栏的汉堡菜单逻辑出了 bug——点击不响应。这个 bug 花了 10 分钟定位，原因是它在修改断点时把 JavaScript 事件监听的选择器写错了。

---

环节⑥：部署上线（实际 15 分钟）

用 Vercel 部署静态文件，拖拽上传，3分钟搞定。剩下的时间花在配置自定义域名上。如果你没有域名，直接用 Vercel 给的子域名，6分钟内可以上线。

---

三个最容易卡住的环节

卡点一：Figma 标注信息不够，Claude "猜"出来的代码偏差大

问题描述：我第一次给 Claude 的信息里，只说了"卡片之间有间距"，没有给具体数值。Claude 猜了一个 gap: 24px，但 Figma 里实际是 32px。这种偏差单独看不明显，但当页面有 6 个卡片、3 行排列时，整体视觉密度就明显不对。 烂 prompt vs 好 prompt 对比： 
❌ 烂 prompt：

"功能介绍区域有三个卡片，横向排列，卡片之间有间距，卡片内有图标、标题和描述文字。"



✅ 好 prompt：


"功能介绍区域有三个卡片，横向排列，卡片间距 gap: 32px，卡片内边距 padding: 24px，


卡片圆角 border-radius: 12px，图标尺寸 48x48px，标题字号 18px/font-weight: 600，


描述文字 14px/line-height: 1.6/color: #666666。"
解决方案：在给 Claude 描述之前，先在 Figma 里把所有关键数值标注出来。用 Dev Mode 最方便，没有 Dev Mode 就手动量。这一步多花 5 分钟，能省后面 15 分钟的反复调整。

---

卡点二：多轮对话后 Claude 的上下文"漂移"

这是那个让我卡了 40 分钟的环节。

问题的本质是：Claude 的上下文窗口虽然很长，但在多轮修改中，它对"当前代码状态"的理解会逐渐模糊。大概从第 5 轮对话开始，我发现它在修改 A 组件时，会悄悄改动 B 组件的样式——而且它自己不知道它改了。

具体表现：第 1 轮生成的 Hero 区背景色是 #1A1A2E，到第 8 轮我让它调整按钮样式时，它把 Hero 区的背景色改成了 #0D0D0D。我没要求改，它就改了。 烂 prompt vs 好 prompt 对比： 
❌ 烂 prompt（第 7 轮）：

"把主按钮的 hover 效果改成有一点阴影感，其他不变。"



✅ 好 prompt（第 7 轮）：


"以下是当前完整的 CSS 代码：[粘贴完整代码]


只修改 .btn-primary:hover 的样式，添加 box-shadow: 0 4px 12px rgba(99, 102, 241, 0.4)。


其他所有样式保持不变，请只返回修改后的完整 CSS。"
解决方案：每隔 3-4 轮对话，重新把完整的当前代码投喂给 Claude，让它基于最新状态操作，而不是基于它"记忆"中的状态。麻烦，但有效。

---

卡点三：响应式断点不符合国内主流设备

问题描述：Claude 默认的断点逻辑来自国际标准，但国内用户的设备分布和欧美有明显差异。 烂 prompt vs 好 prompt 对比： 
❌ 烂 prompt：

"帮我做响应式适配，移动端要好看。"



✅ 好 prompt：


"请按以下断点做响应式适配：


  • 移动端：max-width: 750px（主要针对 375px 的 iPhone，使用 2x 设计稿逻辑）
    • 

  • 平板/中屏：751px - 1199px（这个断点国内用户少，做基础适配即可）
    • 

  • 桌面端：min-width: 1200px（按 1440px 宽度设计，内容区最大宽度 1200px）
    • 

移动端优先，导航栏在 750px 以下折叠为汉堡菜单。"

---

Claude Opus 4.6 在这个场景下的真实能力边界

说几个客观的判断：

它做得好的地方：
  • 代码生成质量高，HTML 语义化做得不错，CSS 命名规范
  • 能理解设计意图，不只是机械翻译参数
  • 多轮修改有耐心，不会因为改了很多次就开始"摆烂"
  • 对 CSS 动画、Flexbox/Grid 布局的理解很准确
它做不到的地方：
  • 它不是 Figma 插件，无法直接读取设计文件，所有信息需要人工"翻译"
  • 上下文漂移问题在复杂项目里会更严重
  • 对"国内用户习惯"的默认值经常需要手动纠正
横向对比：同样的任务我用 GPT-5.1 测过，在 CSS 细节还原度上 Claude Opus 4.6 体感上略优，尤其是对复杂布局的处理更稳定。但差距不是决定性的——真正的差距在于你的 prompt 质量。换句话说，工具的上限，是你 prompt 能力的上限。 适合用这套流程的项目类型：
  • ✅ 落地页、活动页、产品介绍页
  • ✅ 个人作品集网站
  • ✅ 企业官网（静态部分）
  • ✅ 邮件模板
  • ❌ 需要用户登录 / 数据库的应用
  • ❌ 复杂交互（拖拽、实时协作等）
  • ❌ 需要精确像素级还原的设计稿（误差 > 5px 会让你抓狂）

---

给不同类型读者的行动建议

小白读者

别从零开始设计。去 Figma Community 找一个你喜欢的落地页模板，改成自己的内容，然后把改好的稿子描述给 Claude。先跑通流程，再谈优化。第一次建站，能上线就是胜利。

进阶用户

把第三章的三个卡点做成你自己的 SOP checklist：

1. 给 Claude 的设计描述里，所有数值必须精确到 px

2. 每 3-4 轮对话重新投喂完整代码

3. 响应式断点明确写 375/750/1440，不要让 Claude 自己猜

按这个 checklist 操作，整个流程可以压到 90 分钟以内。

有 API 需求的用户

如果你想把这套流程做成团队工具，或者需要稳定调用 Claude Opus 4.6 而不被官网的访问限制卡住，可以直接用 [api.884819.xyz](https://api.884819.xyz)——接口格式和官方完全兼容，适合批量调用或集成到自己的工作流里。我们这篇文章的测试本身也用了这个接口跑了部分对话。没有月租，按量付费，国产模型（Deepseek / 千问等）完全免费，新用户注册即送体验 token。

---

最后说一句真实的话

这套流程真正节省的，不是"技术门槛"——一个完全不懂代码的人，面对 Claude 生成的 350 行 HTML，遇到 bug 还是会手足无措。

它真正节省的，是设计师和开发者之间反复沟通的时间成本。一个设计师能把自己的稿子直接转化成可以跑的代码，哪怕质量只有 80 分，也比"把设计稿交给开发，等两天，改三轮，再等两天"这个流程快得多。这才是 AI 辅助建站的核心价值：它不是替代开发者，而是让设计师在需要验证想法的时候，不再依赖开发者。

务实地说：这套流程现在值得学，但它还不够成熟，卡点依然存在，需要你有耐心调教。

---

这次测试只覆盖了"静态落地页"这个最简单的场景。下一个问题更有意思：如果目标是一个有表单、有数据库、需要后端的完整 Web 应用，Claude + 哪个工具的组合才是真正的天花板？ Cursor？v0？还是直接上 Claude 的 Artifacts？我已经在测了，结论比你想象的更出乎意料。

---

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

#AI建站 #Claude #Figma #前端开发 #AI工具 #8848AI #无代码开发 #设计转代码