我以前对这类“AI 做设计”的项目比较警惕。原因很简单：很多工具只是把 prompt 包了一层漂亮 UI，最后产物看起来像模板站，改两轮就塌。但最近 Hacker News 上的 Open Design 让我多看了几眼。它不是另一个单点生成器，而是把 Claude Code、Codex、Cursor Agent、Gemini CLI、Qwen、Copilot CLI 等命令行编码 Agent 当成“设计引擎”，再叠一层本地优先的技能、设计系统、沙盒预览和导出链路。项目 README 直接把自己定位成 Claude Design 的开源替代。

这句话听起来很大，但工程上真正有意思的不是“替代 Claude Design”，而是它暴露了一个更具体的搜索问题：设计工作流到底应该由专门的设计模型驱动，还是由已经会读文件、改代码、跑命令的 Coding Agent 驱动？

我的判断是：Open Design 不一定会马上成为生产级设计平台，但它代表了一条很值得关注的路线——把设计从“生成一张图”拉回到“生成一个可运行、可审查、可导出的工程项目”。

它不是文生图工具，而是把设计任务工程化

Open Design 的 README 里有几个关键词很关键：local-first、BYOK、agent CLI auto-detect、Skills、Design Systems、sandboxed preview、HTML/PDF/PPTX/MP4 export。翻成人话就是：它不试图自己训练一个万能设计模型，而是把你机器上已有的 Agent CLI 调起来，让 Agent 在一个受控项目里生成和修改设计资产。

这和很多 AI 设计产品的差别很大。后者通常是“输入一句话，得到一个不可解释的视觉结果”；Open Design 更像是“给 Agent 一个设计系统、任务说明和预览环境，让它持续修改文件，直到产物可运行”。

说白了，它把设计任务变成了一种软件工程任务。

这件事的价值在于可迭代性。一个登录页、一份销售 deck、一个移动端交互原型，本质上不只是图片，而是一组结构、样式、文案、资源和导出规则。Coding Agent 已经擅长处理这些东西：读项目、改组件、运行构建、根据错误日志修复。Open Design 做的是把这些能力迁移到设计场景。

这里我会联想到之前写过的 Claude Code Routines：真正稳定的 Agent 工作流，很少靠一次神奇 prompt，而是靠可复用步骤、上下文约束和反馈循环。Open Design 的 Skills 和 Design Systems，本质上也是在给 Agent 建立可复用的“套路”。

为什么“本地优先”比看起来重要

Open Design 强调 local-first 和 BYOK。这个卖点有点老生常谈，但放在设计工作流里反而很实际。

设计原型里经常包含还没发布的产品信息、客户名单、商业计划、品牌资产。把这些内容直接丢到一个黑盒 SaaS 里，很多团队嘴上说能接受，法务和安全团队未必接受。Open Design 的思路是：前端、预览、导出尽量在本地或自托管环境完成，模型调用用你自己的 key，Agent CLI 也优先复用本机环境。

当然，这不等于“绝对安全”。只要调用外部模型，prompt 和上下文仍然可能离开本机；只要让 Agent 执行命令，就要考虑权限边界。项目的沙盒预览能降低一部分风险，但不能替代企业里的密钥隔离、网络出站控制和审计。

换句话说，本地优先不是免死金牌，只是把控制权从平台手里拿回来一部分。

如果你关心 Agent 安全边界，可以顺手看我之前写的 AgentArmor 八层安全框架。Open Design 这种“让 Agent 生成并运行设计项目”的模式，和代码 Agent 一样，需要最小权限、文件系统边界、命令执行白名单，以及对外部资源的审查。设计资产看起来不像生产代码危险，但它一样可能带上外链、脚本、埋点和泄露信息。

它的核心工程假设：设计系统可以被 Agent 消费

Open Design 最激进的地方，不是支持多少个 Agent CLI，而是它把设计系统作为一等公民。README 里提到多套 brand-grade Design Systems 和 composable Skills。这个方向我比较认可，因为“好看”这个目标太抽象，Agent 如果没有约束，很容易生成一堆平均化的 Tailwind 卡片。

设计系统的作用，是把审美问题的一部分转成约束问题：颜色、间距、字体、组件层级、动效节奏、品牌语气。Agent 不一定真的懂设计，但它能遵守规则。

人话翻译一下：不要让模型凭空发挥，要让它在护栏里发挥。

这也是为什么我觉得 Open Design 比单纯的文生图工具更有工程价值。图片生成模型可以给你灵感，但很难稳定接住“把这个 hero section 改成更企业级，同时保持品牌色、导出 PPT、再生成一个移动端版本”这种连续任务。Coding Agent 虽然审美上不一定更强，但它有文件级记忆和可执行反馈，适合做多轮修改。

不过这里也有一个坑：设计系统本身要足够清晰。很多团队的“设计系统”其实只是一份 Figma 文件和几句口头约定。如果把这种松散规范交给 Agent，最后还是会失控。Open Design 能不能落地，很大程度取决于团队是否愿意把品牌规则、组件规则、导出规则文档化。

生产环境最大的风险不是生成失败，而是审查成本

我不太担心 Open Design 生成一次失败。失败了再跑、再改就行。真正的问题是：它生成出来的东西谁来审？怎么审？审哪些层面？

设计产物至少有三层需要检查。

第一层是视觉和品牌一致性。这个还可以靠人工设计师或产品经理看。

第二层是工程质量。HTML 是否可维护？组件是否乱堆？导出的 PDF/PPT 是否在不同环境下稳定？如果里面有脚本，是否引入未知第三方资源？这已经不是传统设计评审能完全覆盖的范围。

第三层是版权和合规。Agent 生成的图片、图标、文案和模板风格，是否借鉴了不该借鉴的东西？Open Design 是开源工具，不代表它生成的一切天然可商用。尤其是团队把外部模型接进来后，模型服务商的条款也要算进来。

所以我的建议是：Open Design 更适合作为“设计工程加速器”，而不是无人值守的设计外包。

比较稳妥的用法，是让它处理中间态产物：早期原型、内部评审材料、销售 demo、文档配图、概念验证页面。等到要进入正式品牌投放或客户交付，再由设计师和工程师做一次收口。

和 Claude Design 的差异：开源不是唯一重点

Open Design 把自己称为 Claude Design 的开源替代，这个定位很容易让人只盯着“免费”和“可自托管”。但我觉得更关键的差异是工作流所有权。

封闭产品的优势是体验完整：打开即用、模型和界面高度整合、少折腾。缺点也明显：你很难控制底层 prompt、很难插入自己的 Agent、很难把内部设计系统变成可执行约束，也很难把产物链路嵌进现有 CI、文档或营销系统。

Open Design 的路线更工程师友好。它假设你愿意折腾，也愿意把设计流程当成代码流程来管理。比如用 Git 管理设计资产，用 PR 审查 Agent 修改，用脚本批量导出多种格式，用不同模型后端做成本和质量权衡。

这和 Chrome Prompt API 那篇里讨论的浏览器内置 AI 有点相似：真正影响落地的，往往不是模型能力单点，而是运行位置、权限模型、成本结构和可集成性。Open Design 也是这样。它的卖点不只是“能生成设计”，而是“能嵌进工程师已经熟悉的工具链”。

我会怎么选型

如果你是个人开发者、独立产品团队，或者需要频繁做 landing page、demo、deck，Open Design 值得试。项目在 GitHub 上已经有较高关注度，最近提交也很活跃；从 GitHub API 看，仓库 stars 超过 1.9 万，最后更新时间在 2026 年 5 月，至少不是一个只有 README 的概念仓库。

如果你是中大型企业，我会更保守：先用它做内部原型，不要直接接生产品牌资产；先把模型 key、文件系统权限、导出目录、外链策略管住；再考虑把它接入正式流程。

如果你是专业设计团队，也别急着把它当威胁。短期内它更像一个会写代码的设计助理，而不是能替代资深设计师的创意总监。它能把“从想法到可运行原型”的距离缩短，但对品牌判断、叙事节奏、用户研究和商业取舍仍然很粗糙。

我真正看好的，是“设计工程师”这个角色会被放大。未来很多团队可能不再区分那么清楚：这个人只写前端，那个人只做 Figma。会用 Agent 组织设计系统、生成原型、审查代码、导出交付物的人，会非常吃香。

Open Design 还不完美，我也不确定它的长期维护质量能不能跟上热度。但它提出的方向是清楚的：AI 设计工具不应该只追求一次性惊艳截图，而应该追求可复用、可审查、可集成的工程链路。

这才是它值得写的原因。

参考资料

• Open Design GitHub 仓库
• Open Design 在 Hacker News 的讨论
• Open Design README 原文
• GitHub API：nexu-io/open-design 仓库元数据
• Claude Code 官方文档