项目快照：nexu-io/open-design，约 87,436 个 Star，10,149 个 Fork；最新推送时间 2026-08-16T17:45:23Z。本文基于仓库公开资料撰写。

项目地址：https://github.com/nexu-io/open-design · https://open-design.ai

open-design 从代码、运行环境到实践流程的项目封面
open-design 的项目能力与实践流程示意。

项目速览（TL;DR）

open-design 是一个采用 TypeScript 编写的本地优先桌面应用，目标是把编码代理接入设计生产流程。根据仓库描述，它可以围绕原型、落地页、仪表盘、幻灯片、图像和视频生成真实文件，并支持 HTML、PDF、PPTX 与 MP4 导出。

项目默认分支为 main，许可证为 Apache-2.0。所给 GitHub 元信息显示项目有 87,436 个 Star 和 10,149 个 Fork；这些数字属于资料提供时的仓库快照，未提供统计时间，不能据此推导当前实时数据。

  • 定位：面向编码代理的设计工作台，以及面向代理时代的 Figma 替代方案。
  • 运行形态：面向 macOS 和 Windows 的本地优先原生桌面应用。
  • 核心机制：检测本机已安装的代码代理命令行工具，运行设计技能与设计系统，并将生成物流式送入沙箱预览。
  • 代理接入：README 列出 DeepSeek Harness（dsh）、Claude Code、OpenClaw、Codex、Cursor、OpenCode、Qwen、Copilot、Amp、Hermes、Kimi、Antigravity 等，以及 26 个不同的本地 CLI 可执行文件。
  • 模型接入：支持通过 BYOK（Bring Your Own Key，自带密钥）使用 OpenAI 兼容端点；README 还介绍了官方 Open Design Cloud 模型服务。

定位与目标用户

Open Design 的主要价值不在于提供一个传统的像素级画布，而在于把设计说明、代理会话、文件系统、渲染预览和导出流程放进同一个项目工作区。读者可以据此判断，它更适合以文本 brief、代码和文件为主要工作材料的团队，而不是只需要手工绘图的场景。

README 将其描述为“开放源代码的 Claude Design 替代方案”，并强调设计代理循环包括发现需求、确定方向、流式生成制品、批评和交付。这里的“替代方案”是项目自身的定位表述，不代表两个产品在功能、兼容性或商业条件上完全等价。

典型使用对象

  • 需要由编码代理生成可运行网页原型的前端或全栈开发团队。
  • 需要把品牌规范固化为 DESIGN.md，并在多个项目中复用的设计系统维护者。
  • 需要同时处理原型、演示文稿、文档、图像或动效制品的产品团队。
  • 希望继续使用本机 Claude Code、Codex、Cursor、DeepSeek Harness 或其他 CLI，而不切换到单一代理入口的用户。

核心功能

核心功能围绕“项目—代理会话—生成文件—实时预览—交付导出”组织。每类制品的具体模型、模板和插件组合可能不同，仓库资料未提供所有内部接口签名，因此以下说明只覆盖 README 明确描述的工作机制。

代理驱动的设计制品生成

用户在 Home 页面选择制品类型，填写 brief，并设置设计系统、工作目录和模型，然后启动一次工作流。代理读取工作区中的技能、设计系统和相关文件，生成真实文件；文件进入项目 Studio 后，用户可以继续通过对话要求修改，再在同一处查看渲染结果。

输入主要是 brief、工作目录、设计系统和代理配置，输出是项目文件及其预览。README 未给出每类制品的固定文件命名规则，也未提供统一的 API 请求格式，因此不能把上述流程扩展为未被资料证明的接口承诺。

设计技能与插件

Plugins 页面提供官方技能目录，用户可以按类别浏览、搜索，并使用 Try it 启动工作流。技能可以理解为可组合的设计操作单元，其触发点是用户从目录启动，或由工作流在代理执行期间读取相应技能文件。

技能的输入、输出格式和扩展 API 在给定资料中没有完整说明。仓库只明确指出，Open Design 将“文件系统中的功能技能、渲染设计模板、设计系统和插件”提供给编码代理读取、写入和重新组合。

品牌设计系统与 DESIGN.md

Design System 页面用于从品牌参考中提取和细化视觉语言，并在同一工作区内预览和创建。README 将 DESIGN.md 称为品牌契约，说明该文件承担跨项目传递品牌规则的作用。

在实际工作流中，设计系统作为生成阶段的约束输入，影响字体、颜色、组件和版式等视觉结果；生成文件则作为可预览、可导出的输出。资料没有给出 DESIGN.md 的正式字段表、优先级规则或校验命令，团队应以仓库最新文档和实际文件定义为准。

六类 Studio 制品

README 的 Product tour 展示了 Prototype、Deck、Mobile app、Image、Document 和 HyperFrames 等制品类型。每种制品都在 Studio 中保留对话、生成文件和实时预览，用户可以在生成后继续迭代，而不是把设计过程拆成独立工具之间的复制粘贴。

  • Prototype：生成或重建网页体验，在渲染页面中检查结果，并在原位置继续与代理迭代。
  • Deck：创建多页演示文稿，检查缩略图和演讲者备注，并在完成后导出。
  • Mobile app：在设备预览中生成和打磨移动界面，同时查看对话、输出文件和后续操作。
  • Image：从项目对话生成视觉资产，查看完整尺寸预览，然后下载或打开文件。
  • Document：生成多页指南和编辑类文档，检查渲染布局，并在完成后导出或共享。
  • HyperFrames：README 将其描述为动效图形能力，但给定资料没有提供其输入格式、时间轴模型或渲染参数。

实时预览与导出

生成文件会流入沙箱化 iframe（sandboxed iframe）预览，用户可在文件生成过程中或生成后检查渲染结果。导出目标包括 HTML、PDF、PPTX 和 MP4；这些是 README 明确列出的交付格式，不代表所有制品类型都同时支持所有格式。

导出所依赖的具体工具链、系统组件、字体处理方式和失败重试策略，官方仓库资料未提供该信息，建议以最新 README 为准。对生产交付而言，应在目标操作系统上验证字体、媒体编解码和版式一致性。

系统架构与关键模块

从公开资料可确认的架构是“本地桌面应用加本地守护进程，再连接外部或本地代理 CLI”。package.json 显示仓库包含 @open-design/daemon 工作区包，并将 od 命令映射到 ./apps/daemon/bin/od.mjs，这为守护进程入口提供了直接证据。

桌面工作区与项目 Studio

桌面应用承载 Home、Plugins、Design System 和 Studio 等页面。Home 负责收集任务上下文，Plugins 负责技能发现，Design System 负责品牌规则，Studio 负责会话、文件和预览的联合管理。

给定资料没有列出桌面端使用的具体 UI 框架、Electron 主进程结构或 IPC 接口。虽然 package.json 的依赖构建白名单出现了 electron，但这只能证明依赖安装流程允许构建 Electron，不能单独证明所有桌面运行细节。

守护进程与命令行入口

od 是 package.json 中声明的二进制入口，实际脚本位于 apps/daemon/bin/od.mjs。仓库描述还指出，产品会检测已安装的代码代理 CLI，并通过这些 CLI 运行设计技能和设计系统。

DeepSeek Harness 的 README 描述包括结构化思考、工具调用、模型发现、取消和会话恢复。生成文件会留在 Open Design 工作流中，以便实时预览和交付；其余代理的能力差异、检测优先级和兼容版本，官方仓库未提供完整矩阵。

工作区包与开发工具

根 package.json 的开发依赖包括 @open-design/components、@open-design/daemon、@open-design/tools-dev、@open-design/tools-pack、@open-design/tools-release 和 @open-design/tools-serve，均通过 workspace:* 引用。该信息说明仓库使用多包工作区组织代码。

根脚本还包含类型检查、国际化检查、设计引用检查、社区资源同步和测试项目播种等任务。具体包之间的数据协议、构建产物路径以及发布流水线配置没有在给定资料中展开，因此不应根据包名推断其全部职责。

依赖与运行环境

运行环境约束来自 package.json：项目使用 pnpm 管理依赖，Node.js 版本范围为 ~24，pnpm 版本范围为 >=10.33.2 <11。package.json 的版本为 0.19.2，项目标记为 private: true，这表示当前仓库包配置并非直接按公共 npm 包发布模型声明。

项目 资料中的值 含义 注意事项
Node.js ~24 运行引擎版本范围 应使用与该范围匹配的 Node.js 版本
pnpm >=10.33.2 <11 包管理器版本范围 packageManager 字段指定为 pnpm@10.33.2
模块类型 module 使用 ECMAScript 模块语义 由 package.json 的 type 字段声明
TypeScript 5.9.3 开发依赖中的 TypeScript 版本 来自根 package.json 的 devDependencies
tsx 4.22.3 执行 TypeScript 脚本的开发依赖 用于多个仓库维护脚本
项目版本 0.19.2 package.json 中的版本字段 不等同于 GitHub 当前最新 Release

package.json 还声明了若干依赖覆盖项，包括 better-sqlite3、sharp、esbuild、protobufjs、electron 等允许执行构建的依赖。给定资料没有列出操作系统级依赖、显卡要求、内存要求、网络要求或完整的生产部署矩阵。

快速开始

官方资料提供了仓库的包管理器和可执行脚本，但没有在给定 README 片段中提供完整的桌面安装命令、发行包文件名或端口。下面的闭环只使用 package.json 中真实存在的命令，适合在本地检出目录中确认依赖安装和类型检查链路。

安装

Bash
git clone https://github.com/nexu-io/open-design.git
cd open-design
pnpm install

pnpm install 会触发 package.json 中声明的 postinstall 脚本，即执行 node ./scripts/postinstall.mjs。资料没有说明该脚本的全部副作用，因此建议在隔离的本地开发目录执行，不要把未知生成物直接纳入生产发布流程。

运行仓库定义的开发工具

Bash
pnpm tools-dev

该命令对应 package.json 的 tools-dev 脚本：pnpm exec tools-dev。给定资料未说明它是否会启动完整桌面应用、是否需要额外参数或是否绑定端口，因此不能把它表述为确定的 GUI 启动命令；如果目标是运行发行版桌面应用，应使用官方 Download 页面或最新 QUICKSTART 文档。

验证

Bash
pnpm typecheck

该脚本会执行工作区类型检查，并对 scripts/tsconfig.json 执行 tsc --noEmit。这一步验证的是 TypeScript 类型链路，不等同于验证桌面渲染、代理登录、模型调用或所有导出器。

如果本机没有匹配的 Node.js 或 pnpm 版本，应先按照 package.json 的 engines 和 packageManager 字段调整环境。官方仓库未提供 Windows 与 macOS 的逐步安装差异、发行包校验方式和首次启动故障表，建议以最新 README、QUICKSTART.md 和发布页面为准。

配置说明

公开资料没有提供独立的 .env.example、配置文件样例、端口表或模型端点字段表。因此，下面的表格只列出 package.json 中能够核查的项目级配置字段，不把它们误称为运行时环境变量。

字段名 类型 默认值 作用
name 字符串 open-design 项目包名称
version 字符串 0.19.2 项目包版本
private 布尔值 true 标记包为私有项目包
packageManager 字符串 pnpm@10.33.2 声明包管理器及其版本
type 字符串 module 启用 ECMAScript 模块语义
license 字符串 Apache-2.0 声明项目许可证标识
engines.node 版本范围字符串 ~24 声明 Node.js 运行环境范围
engines.pnpm 版本范围字符串 >=10.33.2 <11 声明 pnpm 运行环境范围

模型密钥属于敏感配置。README 明确提到 BYOK 和 Open Design Cloud，但给定资料没有提供环境变量名、配置文件路径、密钥存储位置或代理端点格式；因此不要依据本文自行创建未经文档确认的变量名，具体配置应以最新官方文档为准。

进阶用法

进阶使用的重点是把设计规则、代理能力和交付格式组合起来，而不是单独调用某一个模型。项目资料明确支持技能、设计系统、本地 CLI 和多种制品类型，但没有给出完整的插件开发协议，扩展时应先确认仓库当前约定。

把设计系统作为团队约束

团队可以将品牌参考整理为设计系统，并通过 DESIGN.md 作为代理生成时的上下文。适合把颜色、字体、组件风格、版式原则和交付要求集中维护，再由不同项目在 Home 或 Studio 中选择同一设计系统。

根据本文作者的经验判断，设计系统文件应纳入代码审查和版本控制，避免品牌规则只存在于个人桌面应用状态中。但仓库资料没有规定文件存储位置、合并策略或审查工具，具体落地方式应由团队自行制定。

选择代理运行时

README 将 DeepSeek Harness、Claude Code、Codex、Cursor、OpenCode 及其他 CLI 视为可接入运行时。触发方式是应用检测本机可用的代理可执行文件，用户在工作流中选择相应运行时，生成结果再返回 Open Design 的文件和预览链路。

DeepSeek Harness 的资料还明确列出模型发现、工具调用、取消和会话恢复等原生运行能力。不同 CLI 是否支持同样的会话恢复、取消语义和文件权限边界，仓库未提供逐项对照表，不能把 DeepSeek Harness 的特性外推到其他运行时。

组合不同制品

同一 Studio 可以围绕一个项目处理原型、演示文稿、移动界面、图像、文档和 HyperFrames。实际流程可以先用设计系统约束原型，再从项目上下文生成 Deck 或 Document；这种跨制品复用是 README 所描述的“对话、生成文件和实时预览保持在一起”的直接结果。

输出格式选择应根据交付对象决定：网页交付可关注 HTML，打印或阅读场景可验证 PDF，演示场景可检查 PPTX，动效交付可检查 MP4。README 没有承诺导出文件的兼容性范围、无障碍等级、媒体编码参数或跨平台视觉一致性。

可观测性与运维

可确认的运行反馈主要来自 Studio 中的代理对话、生成文件和实时预览，以及 DeepSeek Harness 的取消和会话恢复能力。它们有助于观察一次设计任务的输入、过程和产物，但不等于完整的生产监控系统。

  • 任务层：保留 brief、使用的设计系统、代理运行时和生成文件，便于复盘。
  • 预览层：在沙箱化 iframe 中检查渲染结果，重点验证资源加载、字体、布局和交互。
  • 会话层：使用 README 明确提到的会话恢复和取消能力管理中断任务，但具体持久化位置未提供。
  • 导出层：对 HTML、PDF、PPTX、MP4 分别进行打开和版式检查，不能仅以生成成功作为交付依据。
  • 开发层：使用 pnpm typecheck 验证类型链路，并根据仓库脚本选择 pnpm i18n:check、pnpm lint:craft 等检查任务。

官方仓库未提供日志格式、指标名称、追踪系统、健康检查端点、端口、告警规则、备份策略或 SLA。部署到团队环境前，应自行建立任务日志、导出物留存、密钥审计和失败重试记录，并以最新文档确认应用支持的运维接口。

安全与合规边界

Open Design 会处理本地工作目录、代理会话、生成文件和模型请求，安全重点是文件权限、密钥保护、外部模型传输和预览隔离。资料明确提到沙箱化 iframe 预览，但没有给出完整威胁模型、权限清单或安全审计报告。

授权与数据边界

  • 只在用户有权访问的本地目录中运行代理和生成流程，不应把他人或组织的未授权文件交给代理处理。
  • 使用 BYOK 或官方云服务前，应确认 brief、源文件、品牌资料和生成内容是否会离开本机，以及服务条款和数据保留政策。
  • API 密钥不得写入公开仓库、设计系统文件、截图、导出文档或提交记录；本文不提供未经资料证明的密钥配置字段。
  • 对来自代理的文件修改、脚本执行和外部资源引用进行人工审查，特别是准备发布到公开站点或交付给客户时。
  • 沙箱预览降低了预览内容与宿主环境直接交互的风险，但不能替代操作系统权限控制、网络隔离和依赖供应链审查。

项目资料没有涉及渗透测试、账号自动化、模型越狱或绕过检测等用途。本文只讨论在授权的本地开发和设计交付环境中使用；对涉及个人信息、商业机密、受监管数据或跨境传输的场景，应由组织的隐私、法务和安全流程先行评估。

许可证与商用条款

仓库 LICENSE 文件明确采用 Apache License 2.0。该许可证授予使用者永久、全球、非排他、免版税且不可撤销的版权许可，并在许可证条件下允许复制、制作衍生作品、公开展示、公开执行、再许可和分发。

Apache-2.0 通常允许商业使用，但具体权利和限制必须以仓库 LICENSE 为准。分发原始作品或衍生作品时，LICENSE 第 4 节要求向接收者提供许可证副本、对修改过的文件添加显著修改说明，并保留源文件中的版权、专利、商标和归属声明；如果发行包包含 NOTICE 文件，还需要按许可证要求保留其中的归属信息。

  • 可以在符合许可证条件的前提下进行商业使用。
  • 分发时需要附带 Apache License 2.0 文本。
  • 修改文件需要标明已经发生修改。
  • 不能把 Apache-2.0 理解为自动获得项目名称、商标或服务标识的使用许可；LICENSE 第 6 节明确不授予商标许可。
  • 如果项目或依赖另有独立许可证、服务条款或模型条款，应分别审查，不能只依据仓库许可证覆盖全部服务。

局限性与已知限制

资料足以说明产品方向和主要工作流，但不足以建立完整的兼容性、性能和生产部署承诺。以下限制均来自资料缺口或 README 的明确边界，不把缺失信息包装成产品能力。

  • 未提供桌面发行包的具体版本、校验值、安装步骤和系统最低版本。
  • 未提供公开端口、后台服务地址、环境变量、配置文件路径或 API 接口签名。
  • 未提供 26 个本地 CLI 的逐项可用版本、检测规则和功能兼容矩阵。
  • 项目描述提到“20+ CLIs”，README 则写明“26 distinct local CLI executables”；资料存在表述口径差异，不能把两者合并为新的统计结论。
  • 未提供性能基准、并发上限、导出耗时、资源消耗、稳定性数据或 SLA。
  • 未提供所有插件的开发规范、技能文件格式、DESIGN.md 完整 schema 或版本兼容策略。
  • 模型服务、BYOK 端点和本地 CLI 的费用、数据留存和服务可用性不由 Apache-2.0 自动保证。

根据本文作者的经验判断，若团队需要可审计的设计生成流水线，应在引入前补充版本锁定、依赖扫描、文件变更审查、导出回归样例和敏感数据分级策略。官方仓库未提供这些企业治理材料，建议以最新 README 和组织内部控制要求为准。

适合谁

当团队已经使用编码代理，并希望把设计制品直接落到真实文件和可交付格式时，Open Design 的工作流更容易与现有开发流程衔接。下面的判断信号用于评估匹配度，而不是对项目能力作额外承诺。

  • 团队已有 Claude Code、Codex、Cursor、DeepSeek Harness 或 README 列出的其他 CLI，并希望继续使用现有代理运行时。
  • 交付物包含 HTML、PDF、PPTX 或 MP4，而不是只需要保存设计稿画布。
  • 团队愿意用 DESIGN.md 或设计系统文件维护品牌规则，并接受代码和文件审查。
  • 用户需要在 macOS 或 Windows 本地优先运行，并能够自行管理工作目录、模型密钥和代理安装。
  • 产品、设计和开发人员需要在同一项目中查看对话、生成文件和实时预览。

不适合谁

如果组织的主要需求是成熟的协作画布、已验证的企业级治理或固定供应商服务等级，当前资料不足以证明 Open Design 能直接满足这些要求。下面列出的信号意味着应先做小范围验证，或保留现有替代方案。

  • 团队必须使用资料未列出的操作系统、运行时版本或桌面部署方式，且无法接受自行验证兼容性。
  • 项目要求明确的并发上限、SLA、审计日志、集中式权限管理或官方运维接口，而仓库资料未提供这些信息。
  • 组织禁止设计 brief、源文件或生成内容发送到任何外部模型服务，且没有可用的本地代理或合规 BYOK 方案。
  • 工作流依赖资料未列出的设计工具格式、插件生态或专业出版功能，不能接受通过 HTML、PDF、PPTX 或 MP4 重新核验交付。
  • 团队需要对插件、技能和导出链路进行严格的正式 schema 管理，但当前仓库文档尚未提供完整规范。

在场景 A，即“本地代理驱动的文件型设计交付”，可以优先评估 Open Design；在场景 B，即“已有成熟画布协作体系且需要该体系的专有格式和治理能力”，应继续评估现有替代方案。README 明确提到其为 Figma alternative，但没有提供迁移工具或格式兼容承诺。

常见问题与排查（FAQ / Troubleshooting）

排查应先区分环境问题、代理发现问题、模型配置问题和导出问题。资料中可核查的命令主要是安装、开发工具和类型检查，超出这些范围的诊断步骤需要结合最新仓库文档。

安装时提示 Node.js 或 pnpm 版本不匹配怎么办

检查 package.json 中的 engines.node 和 engines.pnpm：Node.js 为 ~24，pnpm 为 >=10.33.2 <11；packageManager 指定 pnpm@10.33.2。调整后重新执行 pnpm install，不要通过修改 engines 字段来掩盖环境不匹配。

为什么无法确认桌面应用是否已经启动

package.json 中存在 pnpm tools-dev 和 od 二进制入口，但给定资料没有明确完整桌面启动命令、端口或窗口行为。先执行 pnpm typecheck 验证代码链路，再查阅仓库 QUICKSTART.md、最新 README 和发布页面确认运行方式。

代理 CLI 没有出现在可选列表中怎么办

README 说明应用会检测本机已安装的代码代理 CLI，但未提供检测路径、环境变量或失败日志格式。应先确认目标 CLI 已按其官方方式安装并能在本地 shell 中运行，再检查 Open Design 当前版本支持的代理列表；不要根据 CLI 名称自行猜测集成参数。

导出文件无法满足交付要求怎么办

先在 Studio 的实时预览中检查原始制品，再分别验证 HTML、PDF、PPTX 或 MP4 导出结果。由于资料没有提供导出器版本、字体嵌入规则和媒体编码参数，具体兼容性问题应以最新文档、仓库 issue 和目标平台复现结果为准。

如何确认类型检查通过

在仓库根目录执行 pnpm typecheck。根据 package.json，该脚本会递归执行工作区中存在的 typecheck 脚本，并对 scripts/tsconfig.json 执行只检查不输出文件的 TypeScript 编译；它不能替代端到端测试。

找不到模型 API 配置项怎么办

给定资料只确认了 BYOK 和 Open Design Cloud 的存在，没有给出密钥字段、环境变量或配置文件路径。官方仓库未提供该信息，建议以最新 README 和官方文档为准，并避免把真实密钥写入代码、设计系统或 Git 提交。

项目地址与资源

以下链接均来自项目资料，可用于查看源代码、官方说明、下载入口、云服务信息或社区渠道。使用前应以目标页面当前内容为准，尤其是版本、价格、支持的模型和安装方式。

结论与评估建议

Open Design 把编码代理、设计技能、品牌设计系统、文件生成、沙箱预览和多格式导出放进本地优先桌面工作流，适合希望直接获得可运行或可交付制品的开发与产品团队。它的关键差异在于以文件和代理会话为中心，而不是以独立画布为中心。

评估时应优先验证四项内容：目标操作系统上的安装与启动、现有 CLI 的发现和会话行为、团队 DESIGN.md 的可维护性，以及最终 HTML、PDF、PPTX、MP4 文件的交付质量。对于密钥、敏感资料、企业审计和服务可用性要求，则必须在许可证之外单独核对官方条款与组织合规要求。