Vercel 这套 AI 设计流，把设计师和前端都卷进去了

设计稿不再永远是上游

以前做产品，顺序很清楚。

设计师先在 Figma 里画页面，开发再照着还原。

设计稿是上游，代码是下游。

但 Vercel 产品设计团队最近那篇工具分享，把这个顺序讲得有点不一样了。

Hannah Hearth 在 4 月 28 日写了一篇文章，标题是 Tools the Vercel Product Design Team Actually Uses。

真实产品开始反哺设计

她讲的不是一份普通工具清单。

最有意思的地方，是生产环境开始反过来喂给设计。

原文里有一句很直接。

以前设计文件跑在生产前面，团队努力让两边同步。

现在实现成本和时间大幅下降，设计文件反而很容易过期，生产环境里已经有很多功能根本没从画布开始。

这句话挺狠。

因为它说的不是某个工具好不好用。

它说的是设计和代码的上下游关系变了。

AI 进入真实工作流

原文提到 Paper 浏览器插件，可以把页面结构和样式带回 Paper 的设计画布。

设计师不一定非要从一张空白画布开始。

真实页面已经跑起来了。

你可以从真实页面里把结构、样式、组件状态抓回来，再做二次创作。

浏览器开始变成画布的一部分。

这对设计师很关键。

静态设计稿里看起来顺的东西，放到真实数据、真实状态、真实交互里，未必还成立。

按钮文案一长会不会挤。

列表内容一多会不会乱。

加载状态、空状态、错误状态是不是还好看。

这些东西在浏览器里跑一遍，比在画布里想象更直接。

原文还提到一个叫 UI Fork 的本地开发工具。

它可以在本地开发环境里给组件做多个版本，评审的人直接在浏览器里切换方案。选中某一版后，再把那一版差异合回原文件。

这就像把 Figma 里多方案探索那套，搬到真实运行环境里。

以前是在画布里看方案。

现在可以在产品里看方案。

还有一个细节也挺有代表性。

Timo 用 Codex 做主要 coding agent，又做了一个 Claude review skill，让 Codex 把计划交给 Claude 审。

Claude 会问方案是不是太复杂，有没有重复，API 设计是不是合理。

Codex 不能盲目服从，它要坚持自己的判断。只有两个模型都同意，才更新计划。

这个流程不像“让 AI 给我一个答案”。

更像一场小型评审会。

一个模型写方案，一个模型挑毛病，最后人来拍板。

我觉得这才是 AI 进入真实工作流之后最有意思的地方。

它不是替设计师按一个按钮生成页面。

它是在把设计、代码、评审、修改这些环节重新串起来。

人负责方向、审美、取舍和边界。

AI 负责快速落成多个版本，让东西真实跑起来。

然后人再挑。

这篇文章最值得看的地方，不在 Paper、UI Fork、Codex 或 Claude 这些名字上。

工具会变。

工作流的方向更重要。

当实现成本足够低，产品可以先在真实环境里长出来，再反过来沉淀成设计资产。

以后设计师的分水岭，可能不只是会不会画图。

而是能不能把真实产品、真实用户、真实代码和 AI 工具串成一条工作流。

写在最后

设计不会因为 AI 消失，但设计的边界一定会变。

以后真正值钱的，可能不是单独交一张漂亮稿，而是把需求、页面、代码、反馈和迭代全都串起来。

当实现成本足够低，产品可以先在真实环境里长出来，再反过来沉淀成设计资产。

我是麦总玩 AI，长期实测 AI 工具、Agent 工作流和普通人能直接用起来的提效方法。

如果你也想少踩坑，点个关注，后面继续拆。