产品原型不必从零画，OpenDesign 把设计系统递给了编码 Agent

产品经理说，帮我做个落地页，别像模板站。

这句话一进编码 Agent，通常会发生两件事。第一件是它很快吐出一页能打开的 HTML。第二件是团队看着那页东西沉默三秒，然后开始说，颜色不对，字不对，按钮也不对。

代码不是没写出来，难的是那一轮看起来还行的东西，常常只是一张会动的截图。视觉规则没留住，下一次改需求又从提示词里捞一遍。产品、设计和前端各自拿着一份心证，挺热闹，文件夹里却没有共同的交付物。

9 月 20 日发布 0.23.0 的 OpenDesign，盯的正是这段缝。它现在在 GitHub 上有约 9.7 万 Star，项目把自己叫作开源、本地优先的 Claude Design 替代品。不过我觉得最该看的不是平替二字，而是它试图把设计系统、功能 Skill 和编码 Agent 放回同一个本地工作区。

好家伙，AI 出第一版的速度早就不是瓶颈了。真正拖慢人的，是第一版之后每一次又要重新解释「我们家的页面到底长什么样」。

图：项目官方总览图。图中的数量会随版本变化，正文引用的是 9 月 22 日查询到的仓库数据。

先别急着把它当成又一个做图工具

OpenDesign 给出的思路很朴素。把品牌的颜色、字体、间距、组件习惯写进 DESIGN.md，需要时再带上 token、组件和资产。编码 Agent 不只收到一句「做一个高级一点的产品页」，还会拿到一个能读、能改、能进版本控制的设计契约。

这件事听起来没那么炫，落到日常却挺关键。

很多团队现在的流程是，需求在文档里，参考图在聊天记录里，Agent 在终端里，最后那张截图在某个临时文件夹里。中间每跨一次工具，设计信息就掉一点。OpenDesign 想把这几样东西捏回一个工作区，原型可以在本地预览，输出保留为 HTML、PDF、PPTX 或 MP4，后续还能交给 Codex、Claude Code、Cursor 继续改。

它公开列出了 151 套设计系统、100 多个功能 Skill 和 277 个官方插件。数字本身只是注意力，不是质量证明。但 DESIGN.md 这条线值得拿走，因为它把「这次看着顺眼」变成「下次也有地方可查」。

这里得把设计系统和换主题分开。换主题，通常是在 Agent 写完页面后再说，把蓝色改成紫色，圆角再大一点。设计系统更像一组先摆在桌面上的边界，哪些颜色能做主按钮，标题最多用几级，卡片在窄屏怎样折，错误状态该长什么样。前者是在修一张图，后者是在约束下一次生成。

这对做产品原型的人很实在。你不用在第一天补齐一整套组件库，也不必等设计师把所有状态画完。先把最容易反复争论的六七条写下来就行。产品的语气偏克制还是偏热闹，主操作有没有第二种颜色，表单报错要不要抢眼，数据为空时放一句什么话。能写进文件的判断，就别只留在群聊里。

下面是一个刻意写得很小的起点。它不是 OpenDesign 的固定格式，而是给编码 Agent 的品牌约束示例。先有这份约束，再让工具去生成页面，效果通常比在提示词里连用五个「高级」靠谱。

# DESIGN.md

产品目标，帮忙碌的运营同学快速看懂今天的异常
视觉语气，克制、留白、先让数字说话
主操作，只用一种强调色，不做渐变按钮
小屏规则，指标卡单列，表格必须有横向滚动或摘要
空状态，解释下一步能做什么，不能只写暂无数据

这份文件最大的好处不是让一次输出更漂亮，而是当第二个人接手时，还能知道前一版为什么这么写。团队以后想换模型、换 Agent，甚至换掉 OpenDesign，设计判断也不会跟着某段聊天记录一起消失。

图：官方插件目录。Skill 是可调用的工作说明，不等于自动通过设计验收。

适合拿来解哪一个老毛病

如果你要的是一份立刻拿给设计师定稿的视觉稿，它不是捷径。设计师仍然要判断信息层级、品牌情绪、无障碍和真实业务状态。让 Agent 直接决定这些，很多时候会收获一页很勤奋、也很陌生的页面。

但如果你的问题是「这周要把一个新功能讲清楚，先拿一版可评审的原型」，它的工作方式就有点意思了。

第一步，不再只给 Agent 一句需求。把已有页面、组件约束和文案边界收成一个 DESIGN.md。这文件不用写成审美论文，写清主色、字号层级、圆角、留白、按钮语气和禁止项就够了。

第二步，让 Agent 先产出一个真文件，而不是一张图。项目官方介绍里强调的就是 HTML、CSS、组件与本地预览。这样产品同学能评审信息结构，前端能看代码骨架，下一轮修改也能落在同一份东西上。

第三步，给这类原型加一道很土但很有用的验收。窄屏会不会挤，长标题会不会溢出，空状态有没有地方放，真实数据替换后卡片会不会塌。AI 最擅长把理想状态摆得很漂亮，最容易漏掉的也是这些。

图：官方主页截图。原型、工作目录与设计系统在同一个入口被选择。

十分钟可以怎样试

项目 README 给 Codex 的安装示例是下面这一条。先用 --print 看清它将要写入什么配置，比一上来把 MCP 配置塞进环境里稳妥得多。

od mcp install codex --print
od mcp install codex

这里有个小坑，macOS 自带一个也叫 od 的八进制转储工具。项目文档特别提醒，桌面应用安装后如果终端撞名，应该从应用的 MCP 设置页复制带绝对路径的配置，不要硬敲一个可能指错程序的 od。

接着别上来做完整 App。找一段已经写好的产品说明，只让它产一个登录页、定价页或数据看板。给出三样东西就行，目标用户、页面要完成的一个动作、不能碰的品牌规则。然后把输出放到真实仓库里，看看它能不能接着改，而不是只在预览里好看。

这才是我觉得它有点子牛逼的地方。AI 做设计的价值，不在于替你画完最后一个像素，而在于把模糊需求变成一份可以继续争论、继续修改、继续交接的文件。

OpenDesign 是 Apache-2.0 开源项目，支持自带密钥和多种本地编码 Agent。它也明确写了 Linux 暂无官方预编译桌面包，且项目列出的 Skill、插件和兼容数量来自它自己的 README。没独立实测之前，把它当作一个可验证的原型工作台，比把它当万能设计师靠谱得多。

还有两件事别被「本地优先」四个字带跑。自带密钥不等于没有成本，Agent 每轮生成、改图、预览，仍然会消耗你接入的模型额度。项目也不是把网络彻底关在门外，README 写了它会接不同的模型服务，并对代理入口做 SSRF 防护。涉及公司素材时，先弄清模型、日志和连接器各自会碰到什么数据，比装完再追着问要轻松得多。

第二件是，原型能进仓库，不代表它已经能上线。把 OpenDesign 产出的 HTML 接进真实项目之前，还是得过一遍组件复用、响应式、加载状态、权限边界和埋点。这里没有神秘配方，反而很像老老实实的工程活。可它至少把讨论从「这页感觉差一点」推进到「这条规则该写在哪里」。

对小团队而言，这已经够有用。先用它把需求和设计契约压成一个能运行的起点，再决定要不要投入设计师、前端和更完整的交付链。该花人工判断的地方照样花，别让人去重复翻译那些本来可以写进文件的规则。

如果你的团队已经让编码 Agent 写页面了，下一步最值得补的，可能不是再换一个模型，而是给它留一份能持续生长的设计契约。你们现在的原型，是一张截图，还是已经能进仓库的东西？