我用设计图 Penpot-MCP + Playwright + Claude Code，手动跑通了一次 AI 还原页面闭环

说明：这篇文章已经按 Markdown 写好，适合直接复制到掘金。
文中图片目前使用仓库相对路径，适合本地仓库或 GitHub Pages 预览；如果你要发掘金，把对应图片拖到相应位置替换即可。
仓库路径：github.com/dongge12345…

最近我在系统学习 Claude Code，想验证一件事：

如果把设计图 MCP、浏览器自动化、Claude Code 和大模型能力串起来，能不能真正跑通一条从“设计稿输入”到“页面产出”的闭环？

这次我做了一次比较完整的手动实践。虽然最终页面还不是像素级还原，局部细节也还有优化空间，但这次最大的收获不是“复刻得多像”，而是我已经把一条 AI 工程化链路亲手跑通了。

这次用到的能力组合是：

设计图 MCP
Playwright
Claude Code
阿里云百炼免费模式

我更关注的不是某个底层 API，而是这套 AI 协作流程到底能不能落地。

一、我这次到底在验证什么

这次实践的目标，不是单纯让 AI “写一个页面”，而是验证下面这条链路：

设计图输入 -> Claude Code 生成页面 -> 浏览器截图验证 -> 继续反馈问题 -> 再次调整 -> 最终结果沉淀

如果这条链路能稳定跑通，那它的意义就不只是“做出一个页面”，而是说明：

AI 可以真正参与前端还原工作
AI 不只是一次性生成代码，还可以进入“生成 -> 验证 -> 修正”的循环
这套方式后面可以继续复用到更多项目里

二、AI 调用流程是怎么串起来的

我这次的实际流程大概是这样的：

先用设计图 MCP 获取设计稿里的页面结构、布局和视觉信息。
再把这些信息交给 Claude Code，让它先生成第一版页面代码。
用 Playwright 打开页面并截图，观察真实效果。
把截图中看到的问题继续反馈给 Claude Code，让它迭代调整。
最后保留设计图、效果图、页面代码和 README，形成一次完整实践记录。

这一套下来，我最大的感受是：

AI 真正有价值的地方，不是“一次写对”，而是它能够进入一个可验证、可反馈、可继续优化的流程。

三、最终效果怎么样

1. 设计图总览

2. 登录页效果

3. 选题页效果

4. 选标签页效果

从最终效果看，页面结构、层级和交互流程已经基本跑通了：

登录页做出来了
选题页做出来了
选标签页也做出来了
整个流程可以从页面切换、截图验证一路走通

当然，问题也很明显：

还原度不是百分之百
一些细节间距、素材选择、局部比例还有偏差
设计稿的视觉精度和 AI 最终产出之间，还是存在差距

但这并不影响这次实践的价值，因为我这次验证的重点，本来就不是“像素级还原”，而是“AI 协作闭环是否可行”。

四、核心代码是怎么实现的

这次我保留的最终页面代码在 day5_figma/index.html。

整体实现并不复杂，重点是先让页面结构、交互和验证流程跑通。比如页面切换部分，就是直接用最简单的类名切换去做：

<button class="btn btn-primary" onclick="showTopics()">REGISTER</button>

function showTopics() {
  document.getElementById('registerPage').classList.remove('active');
  document.getElementById('topicsPage').classList.add('active');
}

function showTags() {
  document.getElementById('topicsPage').classList.remove('active');
  document.getElementById('tagsPage').classList.add('active');
}

主题卡片的选择状态，也用了一个很直观的切换逻辑：

function toggleTopic(card) {
  const plusIcon = card.querySelector('.plus-icon');
  const circle = plusIcon.querySelector('circle:first-child');
  const lines = plusIcon.querySelectorAll('line');

  if (plusIcon.classList.contains('selected')) {
    plusIcon.classList.remove('selected');
    circle.setAttribute('fill', '#fff');
    lines.forEach(line => line.setAttribute('stroke', '#000'));
  } else {
    plusIcon.classList.add('selected');
    circle.setAttribute('fill', '#000');
    lines.forEach(line => line.setAttribute('stroke', '#fff'));
  }
}

这类代码本身不算复杂，但它说明了一件很重要的事：

在 AI 实践里，很多时候第一目标不是“架构有多高级”，而是先把流程跑通，把可验证结果拿到手。

五、这次实践我最真实的收获

这次让我感受最深的，不是“Claude Code 能不能写页面”，而是：

当我开始把它和设计图 MCP、Playwright、真实截图验证结合起来时，AI 就不再只是一个聊天工具，而开始像一个真正能参与工作流的搭子。

我觉得这次最值得记录的收获有 3 个：

AI 最有价值的不是一次生成，而是进入多轮反馈闭环。
浏览器截图验证这一步非常关键，它让“感觉差不多”变成“我能看见问题”。
设计稿 MCP + Claude Code + 验证工具的组合，已经具备继续工程化的基础。

六、这次实践的不足

如果实话实说，这次离“非常惊艳的还原效果”还有距离。

主要问题包括：

视觉细节还不够准
局部布局和留白还不够精细
设计素材和页面结果之间还有一定误差

但我现在的判断是：

这类问题更多是“模型理解和调优问题”，不是“这条路走不通”。

也就是说，方向是成立的，只是细节还有优化空间。

七、为什么我觉得这件事值得写出来

因为很多人提到 AI 编程，还是停留在“帮我写个组件”“帮我改个 bug”这个层面。

但我这次真正感兴趣的是：

能不能把 AI 放进一个更完整的研发流程里，让它参与：

输入理解
页面生成
效果验证
问题修正
结果沉淀

而这次实践至少证明了一件事：

这条链路是能跑通的。

哪怕现在还不是满分结果，它也已经足够说明，AI 在前端还原、页面验证和流程协作这件事上，已经不是“玩具级别”的存在了。

八、结尾

这次实践之后，我对 AI 工程化的理解更具体了。

以前我更容易把 AI 当成“一个会回答问题的工具”，但现在我更愿意把它看成：

一个可以接入设计图、接入浏览器验证、接入代码仓库，并在真实工作流里持续协作的能力节点。

这也是我接下来想继续深挖的方向：

不是只问 AI 一个问题，而是让它进入完整流程，和我一起把事情做成。

如果你也在学 Claude Code、MCP、Playwright 这类东西，我很建议你也做一次类似的闭环实践。
哪怕结果不完美，只要你真的把链路跑通一次，理解就会和只看视频完全不一样。