AI 设计工作流中间层
定义
AI 设计工作流中间层是连接用户设计意图与底层 编码 Agent、模型或 CLI 工具的软件层。它本身不必提供基础模型；其核心作用是把零散的自然语言要求、品牌规则、设计系统、任务步骤和交付要求，整理为底层 Agent 可执行、可追踪和可复用的设计任务。 与直接向模型输入一句提示词相比，中间层还要协调项目文件生成、设计系统选择、技能调度、预览、修改与多格式导出，使产出从一次性文本或代码回复转向可继续编辑和交付的界面项目。
本文档中的语境
在来源对 Open Design 的描述中，Open Design 被定位为“AI 设计工作流中间层”，而不是独立的 AI 模型。它不自带大语言模型，而是调用用户本地已安装的 Claude Code 等 CLI Agent，并将这些通用编码 Agent 组织为执行视觉设计任务的运行环境。 来源将这一模式概括为：用户提出设计需求，中间层补全和标准化需求，叠加技能与品牌规范，再通过本地 Agent 读取模板、编写 HTML/CSS、生成项目文件并完成预览和导出。这里的“设计能力”来自工作流编排、上下文约束与 Agent 执行的组合，而非中间层单独生成视觉结果。
关键组成与职责划分
需求结构化
用户可先输入自然语言需求；系统随后以标准化需求表单补充或锁定受众、调性、目标平台和品牌规则等信息。这样做的目标是把含糊的描述变成后续技能、设计系统和 Agent 都能消费的任务约束。 例如，来源所举流程中，用户先提出“做一款 AI 工具官网，简约科技风”，再选择网页原型技能、设计系统与视觉方向后，才由 Agent 开始生成和布局。
技能与品牌规范组合
中间层将 SKILL.md 技能库与 DESIGN.md 品牌规范组合进任务上下文。技能可定义网页原型、演示文稿、移动端或海报等任务的执行方法；品牌规范和 设计令牌与组件规则 则用于约束颜色、字体、间距、组件和整体风格。
这种机制是 设计规范驱动的 AI 界面生成 的工作流化延伸：规范不只作为静态文档存在，还会在任务启动时与所选技能、设计系统共同注入执行过程。
本地守护进程
来源将本地守护进程描述为 Node daemon 层，承担底层工具发现与本地状态管理职责：扫描计算机 PATH，识别已安装的 CLI 工具；持久化项目、会话和模板数据；并向其他组件提供 SSE 流式接口与标准 MCP 服务。 按来源说法，该守护进程可自动识别 Claude Code 等 25 种主流 CLI 工具。该“25 种”的范围、识别方式及兼容性均为来源主张，不能据此推断所有 CLI Agent 在所有环境中都可用。
运行时协调
运行时负责将技能、设计系统和具体任务组合后调度 Agent，并协调文件生成、多格式导出等步骤。底层 Agent 据此获得本地文件操作上下文，可读取模板、编写代码和生成布局；中间层则负责把执行状态、预览与后续操作串联起来。 来源还描述了 iframe 实时预览、局部微调、配色切换以及 HTML、PDF、PPTX、ZIP、Markdown、MP4 等导出能力。这些属于所述产品实现能力，不是所有 AI 设计工作流中间层的必要条件。
典型运行链路
- 用户提出自然语言设计需求，并在标准化表单中补充受众、调性、平台和品牌约束。
- 系统选择或组合适合任务的技能、设计系统和品牌规范。
- 守护进程发现并连接本地可用的 CLI Agent，维护项目、会话及模板等本地数据。
- 运行时通过本地调用机制向 Agent 下发任务，由 Agent 读取模板、生成 HTML/CSS 等项目文件并执行布局。
- 系统将生成结果实时呈现为可预览的界面，用户可进行局部修改或继续迭代。
- 运行时按交付需要导出代码包、文档、图像或视频等成品，并可经 MCP 将设计文件交给后续开发流程使用。
质量控制与约束
来源案例还将设计质量约束纳入中间层：一方面以品牌规范、设计系统和技能减少风格漂移；另一方面以五维自评审检查品牌贴合度、结构、工艺、可用性与创意，并对低分结果自动重做。 来源声称存在针对“AI 假设计”的限制，例如避免夸张紫色渐变、通用表情符号、虚构数据和不恰当字体滥用；在缺少真实数据时以破折号占位。此类规则可被理解为可执行的生成约束，但其实际效果和评审可靠性仍取决于具体实现、所用 Agent 与输入信息。
边界
AI 设计工作流中间层不等同于大语言模型：模型或 Agent 负责推理、生成和文件操作，中间层负责把任务、上下文、工具与交付流程连接起来。 它也不等同于单一设计系统。设计系统只是中间层在某个任务中可选择或加载的一组视觉与组件规则；中间层应能在不同项目、技能或规范之间进行协调。 它还不等同于独立的图形设计工具。图形工具通常强调手工画布编辑，而此处概念强调围绕 Agent 的需求结构化、代码与文件生成、规范注入、预览和导出编排；两者可以结合，但不能互相替代。 来源关于 Open Design 的开源协议、本地优先、支持的模型与 CLI 数量、内置设计系统和技能数量、导出格式、评审能力及部署限制，均应视为作者或项目方的具体主张，需结合项目版本、运行环境和独立资料核验。