你是不是一直好奇为什么你做出来的产品，无论怎么调整都没法做得很好，都会是如下图所示的样子？

图里其实是调用了专门的前端 skill，还利用 image2 进行了生图，理论上会比一般的效果还要好上不少 图里其实是调用了专门的前端 skill，还利用 image2 进行了生图，理论上会比一般的效果还要好上不少

而别人做的效果却是这样的，美观，高度个性化，就像下图这样。

如果你对 Scatter 感兴趣，可以查看官网： https://scatter-website.pages.dev/ 如果你对 Scatter 感兴趣，可以查看官网： https://scatter-website.pages.dev/

我们之前推荐过使用 21st、react bits 这些提示词组件库，让自己的网站更加好看，但是依然是有区别的。因为我们的产品不仅仅是 web 网页，可能是客户端应用、可能是一个插件拓展等等，这些难道就没有办法吗？

当然是有的，无论是用 figma 来设计，还是你直接 vibe design，都是可以的，经过几次落地实践，我总结了一套工作流程来帮助你！

先产出可走通的 MVP

永远先跑通都是第一步。

我之前做过一个叫做 Scatter（https://scatter-website.pages.dev/） 的工具，它可以帮助我来梳理想法，把技术栈、产品功能这些都梳理清楚，然后无缝交付 Codex 和 CC。

然后就是 debug 时间，这个阶段可能会让你暴跳如雷，也很漫长枯燥。但是确实必须的，只有这样才能把流程走通，为后续的设计还原和以后的功能实现打好基础。

开始设计

功能跑通之后，再认真进入设计阶段。当然，设计师普遍对 Figma 都很熟悉精通，所以我个人还是习惯使用 Figma 来做设计稿，你当然也可以直接 Vibe design。

但无论在 Figma 还是 vibe design，这一步我都建议把基础的规范做得尽可能完整一点，因为这会直接影响后面 AI 还原的质量。AI 不是不能看图写代码，但如果设计文件里变量、样式、组件和说明都比较乱，它还原的时候就会猜，猜多了就会开始跑偏。

我自己实际的实践中，我基本都会有这些内容：

  • 颜色变量，比如背景、文本、边框、强调色、状态色

  • 字体样式，比如标题、正文、说明文字、按钮文字

  • 间距和圆角规则

  • 基础组件，比如按钮、输入框、标签、弹窗、导航、卡片

  • 组件的不同状态，比如 hover、disabled、selected、loading

  • 主要页面和关键交互说明

不过，其实也没必要追求像 ADS、Carbon 这种大型组件库的那种完整度，我们就是自己的产品，够用即可。如果你想快速创建一套规范在 Figma，你也可以使用我的 Figma 插件 Magic foundations：https://www.figma.com/community/plugin/1635127742021494315/magic-foundations

还原顺序

这一步也很枯燥，很漫长，但是我的实践下来，这是必须要做的。如果跳过这一步，直接让 AI 还原整个页面，它很容易在每个页面里写一套局部样式。短期看好像快，长期会越来越难维护。

正式还原 UI 之前，我会先做一层基础还原。顺序通常是：

  1. 先把 Figma 里的变量和样式还原到代码里，你可以利用 Figma mcp 来做到，例如这样写提示词：

这是我的设计稿链接，请提炼 design.md 文件，链接：Figma 设计文件链接

  1. 再把基础组件一个个还原出来，这里你可以考虑使用 shadcnUI 来进行二开；

  2. 最好做一个简单的 HTML 或组件预览页，能直接看到组件效果。这个预览页不一定要复杂，能看到按钮、输入框、卡片、导航、弹窗这些基础东西就够了。它的作用是让你在进入完整页面之前，先检查“零件”有没有做对。

用 Figma MCP 还原界面，再做微调

组件基础有了之后，再开始用 Figma MCP 还原具体界面。我一般会在 AGENTS.md 和 design.md 里写清楚：项目里已经有一套变量、样式和组件，后续实现页面时要优先使用现有资产，不要随手新建一套。

不要一口气把所有页面都丢给 AI。页面越多，偏差越容易累积。一个一个做，虽然看起来慢一点，但整体更可控。

交互也是一样。先把静态 UI 和主要流程做好，再补动画、过渡和一些手感细节。动画这种东西很容易变成“看起来有做，但实际很怪”，所以最好在界面稳定之后再加。

每做一个都要测试，但可以自己测

每完成一个页面、一个组件或者一个流程，都要测试。

不过我不一定会让 AI 每次都完整测试。因为很多前端项目每次测试都要重新编译、跑浏览器、截图、对比，AI 做起来会很耗时间。尤其是在你自己就在电脑前，可以快速点几下的时候，自己测反而更高效。

我的习惯是：

  • AI 负责实现和修问题

  • 我负责快速看效果、点流程、发现不对劲的地方

  • 确认是具体问题之后，再把问题描述给 AI 修改

比如“这个按钮 hover 状态不对”“这个弹窗在窄屏溢出了”“列表空状态没处理”“这里动画太突兀”，这些都很适合自己先看出来，再让 AI 精确修。

AI 不是不能测试，只是测试也要讲成本。需要自动化、需要重复验证、需要防回归的时候，就让 AI 写测试。只是普通视觉和流程检查，自己来往往更快。

一些很重要的小习惯

做好 Git 版本管理

每次比较明确的改动都要做好 Git 版本管理。不要等到一大坨功能都做完才提交。越是和 AI 一起写代码，越要勤提交。因为 AI 有时会一次改很多地方，前面不留检查点，后面发现方向错了就很难回滚

比较舒服的节奏是：

  • 功能跑通，提交一次

  • 样式变量还原，提交一次

  • 一个组件完成，提交一次

  • 一个页面还原完成，提交一次

  • 一段交互调好，提交一次

探索使用工作树

必要的时候用 fork 或者独立工作树探索方案。有些改动你一开始也不知道好不好，比如换一套布局、重构组件结构、试一个动画方案。这种就不要直接在主工作区里硬改。开一个 fork 或工作树，让 AI 放开手去试。试出来好，再合回来；试得不好，就丢掉。

巧用其他设计工具

这也不是什么注意事项，就是要说明一下 Figma 这个流程，其实这里是因为我是设计师，很熟练可以使用 Figma，如果你并不是设计师，或者使用的工具也很难和 AI 联动，那么可以考虑其他设计工具，例如 Claude design这些，也是一样的，不需要非要局限于某一种工具。