下一代设计工具,可能不是 Figma 插件,而是会写代码的 Agent

我最近看到一个挺有意思的开源项目，叫 Open Design。

它的 README 里写得很直接：「The open-source alternative to Claude Design.」

但我觉得，真正有意思的地方不是它要做一个开源版 Claude Design，而是它把 Coding Agent 当成了设计引擎。

也就是说，它没有把 AI 设计理解成「帮我画一张图」「帮我生成一个界面」。它更像是在说：设计这件事，可以交给一个会读文件、会写代码、会运行工具、会预览结果的 Agent 去做。

这个变化挺重要。

因为过去我们聊 AI 设计工具，很容易还停留在画布里。

Figma 插件更强一点，组件生成更快一点，自动补齐几个页面，或者把截图转成 UI。

这些都很有用。但它们解决的主要还是「画出来」的问题。

Open Design 这类东西指向的是另一个方向：从一个想法，到一个可以运行、可以点击、可以导出、可以继续改的原型，中间那一长段链条，正在被 Agent 重新接起来。

设计不再只发生在画布里

传统设计工具的中心是画布。

你在画布上摆元素，调间距，拉组件，做交互线。最后交给工程师，再进入代码世界。

这个流程大家很熟。

问题也很熟。

设计稿看起来很完整，但一到实现就会变形。组件状态没考虑全，空数据没画，加载状态没画，错误状态也没画。交互细节写在备注里，工程师看漏一点，效果就不一样。

所以很多产品团队后来会强调 Design System、组件库、设计规范。

这当然有用。

但它本质上还是在修补设计和工程之间的裂缝。

Agent 介入之后，工作方式会变得不太一样。

Open Design 的思路是，本地运行一个设计生成应用，然后调用你机器上的 Coding Agent CLI。Agent 会在真实项目目录里读写文件，生成 Web、移动端、桌面原型，也可以生成幻灯片、图片、视频等产物。

生成完之后，它不是只给你一段描述，而是把结果放进沙盒 iframe 里预览。你可以继续提要求，让它改。

这听起来更像一个「设计工作台」，但底层不是传统画布，而是 Agent 在操作一个项目。

差别就在这里。

画布工具擅长表达静态结果。Agent 工具更擅长把结果变成可运行的东西。

一个按钮不只是一个矩形。它背后可以有 hover、loading、disabled、error。一个表单也不只是几行输入框，它会牵涉校验、提交、反馈和数据状态。

这些东西放在画布里很麻烦。

放在代码里，反而自然。

下一代工具会更像创作链路

我觉得下一代设计工具的重点，不一定是画布能力继续增强。

更关键的是，它能不能把需求、交互、代码、预览、迭代串起来。

以前一个产品原型大概是这样来的：

产品经理写需求。

设计师画页面。

工程师实现。

大家在评论区、会议、飞书文档里来回对齐。

如果需求变了，就再走一遍。

这套流程最大的问题，不是慢，而是信息在每一步都会损耗。

产品经理说「这里要让用户更快完成创建」。设计师理解成少一个步骤。工程师实现时发现少了一个必要字段。上线后用户还是卡住，因为真正的问题是默认值没处理好。

这里面没有谁错。

只是文字、视觉稿、代码、运行状态，各自都只表达了一部分信息。

Agent 的优势在于，它可以在同一个上下文里处理这些东西。

你告诉它一个需求，它可以先问你目标用户和使用场景。接着生成界面，写出交互逻辑，跑起来给你看。你看完说「这个流程太绕了」，它再改代码，重新渲染。

这个闭环很短。

Open Design 里面也能看到类似思路。它有首轮 discovery 表单，有视觉方向选择，有实时 todo 和进度流。它还支持导出 HTML、PDF、PPTX、ZIP、Markdown、MP4。

这些功能放在一起看，就不像一个单点工具。

它更像是在搭一个产品创作链路。

这也是我觉得它值得关注的原因。

AI 设计如果只停留在「生成漂亮界面」，很快会变成模板竞争。谁的风格更好看，谁的组件更多，谁的截图还原更准。

但如果工具开始接管创作链路，竞争点就变了。

它要理解需求，要懂组件，要会写代码，要能跑起来，还要能接受反馈继续改。

这就不是单纯的设计工具了。

它更像一个产品原型引擎。

Agent 不会替代设计师，但会改变分工

我不太喜欢「AI 会替代设计师」这种说法。

太粗糙了。

真实世界里的设计师，不只是画 UI。

他们要理解用户，要判断信息层级，要处理品牌感，要和产品、研发、业务来回沟通。很多时候，设计师真正值钱的地方，是在一堆模糊输入里做判断。

Agent 现在还很难稳定做好这些判断。

但它会把很多低价值的中间步骤吃掉。

比如，把一个想法变成第一版可点击原型。

比如，把一个已有页面改成 3 种布局方向。

比如，把桌面端界面快速转成移动端。

比如，把设计规范转成可复用组件，再生成多个页面。

这些事情以前很耗时间。尤其是早期探索阶段，很多方案做出来只是为了被否掉。

Agent 适合干这个。

它不怕返工，也不怕你半夜突然改主意。你可以让它连续生成几版，再挑一个方向继续打磨。

设计师的工作重心会往前移，也会往后移。

往前，是更早参与需求判断和体验方向。

往后，是对 Agent 生成的东西做审美判断、体验校准和系统化沉淀。

中间那些重复搭页面、补状态、改细节的活，会越来越多交给 Agent。

这对独立开发者和产品经理尤其有用。

因为很多人最大的问题不是不会想，而是想法到原型之间太远。

你要懂设计工具，要懂一点前端，要知道怎么部署，还要把交互跑起来。任何一环卡住，想法就停在文档里。

如果 Agent 能把这个距离缩短，很多人会更愿意动手试。

先跑起来，再判断值不值得继续做。

这比在文档里反复讨论靠谱。

真正的门槛在上下文

当然，这类工具也不是万能的。

我觉得真正难的地方，不在生成一个页面，而在上下文。

一个 Agent 要做好设计，至少要知道几件事：

你的用户是谁。

这个产品现在长什么样。

已有组件怎么用。

品牌语气是什么。

哪些交互不能改。

哪些数据状态必须覆盖。

如果这些信息没有给清楚，Agent 很容易做出一个看起来还行、但完全不贴业务的东西。

这也是为什么 Open Design 里提到 skill bundles 和 design-system docs 这类东西，我会觉得很关键。

Agent 不是凭空创作。它需要被喂上下文。

一个 DESIGN.md，一套组件说明，一份交互规则，一个项目目录，都可能比一句「帮我做得高级一点」有用得多。

未来的设计工具，可能会越来越像一个上下文管理系统。

它知道你的组件库，知道你的产品结构，知道过去的设计决策。你每次让它改页面，它不是从零开始发挥，而是在已有系统里做变化。

这时候，设计师和产品经理要学的东西也会变。

以前你要学怎么画。

现在你更要学怎么描述约束，怎么定义标准，怎么判断生成结果能不能用。

这件事听起来没那么酷，但很实用。

我对 Open Design 这类项目的判断是：它现在可能还不是一个成熟产品，但方向值得看。

因为它提醒我们，AI 设计工具的终点，未必是一个更聪明的画布。

更可能是一个能把想法、界面、代码和运行状态串起来的 Agent 工作台。

对产品经理、设计师、独立开发者来说，这个变化会很实际。

以后你有一个想法，不一定先打开 Figma。

你可能会先打开一个 Agent，对它说：

「帮我做一个能跑起来的版本。」

然后再一起改。

这才是我觉得最有意思的地方。

相关来源：

• Open Design GitHub 仓库：https://github.com/nexu-io/open-design^[1]

引用链接