26个CLI智能体组合成设计引擎：从零搭建AI设计工作流

把设计流程搬到命令行里跑这个想法听起来有点反直觉但最近一个 89.7k 星的开源项目方向让“CLI 智能体 设计引擎”成了开发者圈子里讨论度很高的话题。过去我们提到设计第一反应是 Figma、Sketch、Photoshop 这类图形界面工具但现在随着 Claude Code CLI 这类智能体开发工具的普及设计工作正在被拆解成一条可以被代码驱动、被 AI 编排的流水线。这篇文章不是要鼓吹“命令行取代设计软件”而是想从工程视角拆解为什么有人把 26 个 CLI 智能体组合成设计引擎这种玩法适合谁如果你想在自己的项目里搭一套类似的“AI 设计工作流”应该怎么下手我会给出完整的环境准备、Agent 角色拆分思路、可运行的实战示例和常见坑点尽量做到照着能跑、跑完能改。1. 背景与核心概念1.1 什么是 CLI 智能体CLI 是 Command-Line Interface 的缩写也就是命令行界面。智能体Agent可以简单理解为一个能自主拆解任务、调用工具、根据结果继续执行下一步的 AI 程序。CLI 智能体就是把这两者结合你不需要打开网页端或 IDE 插件而是在终端里输入命令智能体就会读取你的项目文件、执行命令、生成代码、甚至调用外部工具。一个典型的 CLI 智能体工作流程是这样的用户输入目标例如“把这段 HTML 转成 React 组件”。智能体读取当前目录下的文件理解项目上下文。智能体拆解任务决定需要调用哪些命令或工具。执行生成、替换或格式化操作。输出结果并给出说明。Claude Code CLI 是 Anthropic 推出的命令行智能体工具它可以让 Claude 直接在你的终端环境中工作。由于它天然就是一个 CLI 工具所以非常容易被脚本化、批量化也容易和其他命令行工具组合。1.2 为什么有人用 CLI 做“设计引擎”“设计引擎”这个词听起来很大但本质上是把设计工作拆成了很多可重复的标准化动作。比如根据产品描述生成设计规范。把设计稿导出成前端代码。对现有页面做可用性审查。生成设计 Token 和主题变量。批量生成图标或插画草稿。把文字描述转换成 HTML/CSS 原型。这些动作有一个共同点它们都涉及“输入信息 - 处理 - 输出产物”非常契合智能体的工作模式。而 CLI 的好处在于可编程。设计流程可以被 shell 脚本编排实现批量处理。可版本管理。Prompt、配置文件、生成结果都可以放进 Git。可集成。CLI 智能体可以直接调用 git、node、python、sharp 等生态工具。可复用。不同项目可以复用同一套 Agent 配置。所以这个方向的本质不是用 AI 替代设计师而是把重复的、规则明确的设计任务自动化让设计产出的“初稿效率”大幅提升。1.3 26 个 CLI 智能体的拆分思路“26 个 CLI 智能体”听起来很多但拆开看就是按设计流程的环节来做角色分工。你可以类比成一个虚拟设计团队品牌组负责命名、色彩、字体、LOGO 方向。产品组负责原型、页面结构、交互说明。视觉组负责布局、组件样式、设计系统。前端组负责把设计转成 HTML/CSS/React 代码。审查组负责可访问性、性能、设计一致性检查。每个智能体本质上是同一套 CLI 工具配了不同的 System Prompt 和工具权限。也就是说你不需要部署 26 个服务而是准备好 26 个配置按需调用。这个思路非常重要后面实战部分我会演示具体怎么做。2. 环境准备与版本说明2.1 基础运行环境在开始之前建议准备好以下基础环境。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。依赖项说明操作系统macOS 或 LinuxWindows 可通过 WSL 运行Node.js18.0 以上建议使用 LTS 版本Git用于版本管理和智能体初始化CLI 智能体工具以 Claude Code CLI 为例具体安装方式见下文模型 API Key需要配置可用的 API 访问凭证为什么要强调 Node.js因为很多 CLI 智能体的安装和插件机制都基于 Node.js 生态npm 是核心分发渠道。如果你的机器还没有 Node.js建议先到官网下载 LTS 版本。2.2 安装 CLI 智能体工具以 Claude Code CLI 为例安装命令如下npm install -g anthropic-ai/claude-code安装完成后可以验证版本claude --version如果你终端里执行claude后提示找不到命令需要检查 npm 全局安装路径是否已经加入系统的 PATH 环境变量。不同系统的 PATH 配置方式不一样macOS/Linux 通常是在~/.zshrc或~/.bashrc中追加export PATH$PATH:$(npm prefix -g)/bin然后在当前终端执行source ~/.zshrc或者重新打开终端窗口。接下来需要配置 API 访问凭证。CLI 智能体本质上还是会调用大模型接口所以你需要让终端会话能访问到模型服务。通常做法是设置环境变量export ANTHROPIC_API_KEY你的密钥如果你不想每次开终端都输入一次可以把这行写入~/.zshrc或~/.bashrc。但要注意密钥属于敏感信息不要把带有真实密钥的文件提交到 Git 仓库。生产环境中更推荐使用云平台的密钥托管服务本地开发时也要保证文件权限正确。2.3 验证智能体是否可用环境配置完成后先运行一个最简单的测试确认 CLI 智能体已经可以正常工作claude -p 请用一句话介绍你自己这里的-p参数表示 print 模式也就是让智能体执行一次任务后直接输出结果并退出非常适合脚本调用。如果你看到一段正常的文本回复说明环境已经就绪。如果你的使用场景不是 Claude Code CLI比如你用的是其他开源 CLI 智能体工具原理完全一样先确认命令可用再确认模型访问凭证正确最后再进入复杂配置。3. 核心原理26 个 CLI 智能体如何变身设计引擎3.1 从“单次对话”到“角色分工”直接让一个通用的 CLI 智能体做设计效果往往很随机。原因在于通用智能体没有固定的专业视角它可能在“品牌策略”和“CSS 代码”之间反复横跳。智能体配置文件的核心就是一个 System Prompt也就是系统级提示词。通过编写不同的 System Prompt你可以让同一个底层模型扮演不同角色claude -p 你是一名资深UI设计师请根据以下需求输出页面布局建议...但这样每次都在命令行里写长 Prompt既难维护也无法复用。更工程化的做法是把每个智能体的 Prompt 和参数固化成一个配置脚本存放在项目的agents/目录。这样就有了“26 个 CLI 智能体”的雏形。3.2 设计引擎的基本架构一个完整的设计引擎至少需要四层入口层、角色层、工具层、产物层。入口层是用户与引擎交互的界面可以是一个 shell 脚本、一个 Node.js CLI 命令甚至是一条 npm script。用户只需要输入需求不需要关心具体调用哪个智能体。角色层是智能体池。每个角色有明确的职责边界例如brand-strategist品牌定位、命名、关键词提取。color-system生成色彩体系包含主色、辅助色、中性色。typography字体选择、字号等级、行高建议。layout-engine页面结构、栅格、间距。html-coder把设计描述转成 HTML/CSS。react-coder把设计描述转成 React 组件。accessibility-auditor检查可访问性。seo-auditor检查 SEO 基础。copywriter界面文案生成与润色。工具层是智能体可以调用的外部程序。Claude Code CLI 天然支持执行终端命令比如node、python、git、ls、cat等。你可以在 Prompt 中引导智能体组合使用这些工具。例如让 HTML 生成智能体先创建目录再写入文件然后执行npx prettier格式化代码。产物层是最终输出的设计文档、代码、图片或设计 Token。为了让产物可追溯建议每个智能体都输出到独立目录并在文件头部追加生成说明。3.3 为什么是 26 个而不是 1 个你可能会想一个智能体把所有事做完不是更方便吗理论上可以但实际操作中会碰到几个问题上下文过长。一个智能体在处理大量设计任务时上下文会被各种中间过程占满后面的生成质量明显下降。职责混乱。如果没有角色边界智能体容易在应该写代码的时候纠结文案或者在应该做视觉审查的时候跑去做 SEO。难以复现。当流程被拆成多个独立智能体每个智能体的输入和输出都是明确的出了问题可以单独重跑。便于迭代。如果你发现某一步效果不好只需要调整这个角色的 Prompt不需要改动整个流水线。26 个智能体是把设计过程切得足够细让每个环节保持单一职责。这也是很多开源设计引擎项目受欢迎的原因它们提供了一套完整的 Agent 配置模板你拿来改一改就能用。4. 完整实战搭建一个可运行的设计引擎下面我们动手搭建一个简化版的设计引擎。为了便于理解我们先实现一个最小闭环用户输入一句话需求引擎自动调用多个智能体角色最终输出一个可预览的 HTML 页面。4.1 创建项目结构首先初始化项目目录mkdir cli-design-engine cd cli-design-engine npm init -y然后创建以下目录结构cli-design-engine/ ├── agents/ │ ├── system/ │ │ └── design-context.md │ ├── brand-strategist.md │ ├── color-designer.md │ ├── layout-planner.md │ ├── html-builder.md │ └── ui-reviewer.md ├── output/ ├── scripts/ │ ├── run-design.sh │ └── generate-page.js ├── package.json └── README.md使用agents/存放每个智能体的 Prompt 配置文件。使用output/存放生成结果。使用scripts/存放编排脚本。4.2 定义设计上下文所有智能体需要共享同一个项目背景。这里定义一个设计上下文文件内容如下# 设计上下文 项目名称智能家居控制台 目标用户有一定技术背景的年轻家庭用户 设备桌面端优先移动端适配 风格偏好简洁、清爽、科技感但不要太冷 品牌关键词智能、可靠、温暖、高效 ## 通用设计原则 1. 优先使用语义化 HTML 标签 2. 颜色对比度至少满足 WCAG AA 标准 3. 字体采用系统中文字体栈避免外部字体依赖 4. 所有交互元素必须包含键盘可访问性 5. 页面总大小不超过 300KB不包含图片这个文件会被后续所有智能体读取保证不同角色拿到一致的背景信息。4.3 编写智能体配置每个智能体就是一个 Markdown 文件核心内容就是 System Prompt。下面给出几个关键角色的配置示例。brand-strategist.md# 角色 你是一位品牌策略师擅长根据产品需求提炼品牌关键词和视觉方向。 ## 任务 根据用户输入的产品描述输出以下内容 1. 品牌关键词5-8个 2. 一句话品牌定位 3. 推荐的视觉风格 4. 建议的主色调方向 ## 输出格式 使用 JSON 格式输出字段如下 { brand_keywords: [...], brand_positioning: ..., visual_style: ..., color_direction: [...] } ## 注意 - 不要直接给出完整设计稿 - 不要使用高大上国际化等空泛词汇 - 每个关键词都要有具体解释color-designer.md# 角色 你是一位色彩系统设计师专注于构建可访问、可扩展的设计 Token。 ## 任务 根据品牌策略和设计上下文输出一套完整的色彩系统。 ## 输出格式 使用 CSS 变量格式输出 :root { --color-primary: #值; --color-primary-hover: #值; --color-bg: #值; --color-text: #值; ... } ## 输出内容 1. 主色含 hover、active 状态 2. 背景色页面背景、卡片背景 3. 文本色主文本、次文本、禁用文本 4. 功能色成功、警告、错误、信息 5. 每个颜色都要标明对比度等级 ## 注意 - 必须保证文本和背景的对比度不低于 4.5:1 - 颜色数量控制在 12 个以内 - 输出前需要检查颜色命名是否语义化layout-planner.md# 角色 你是一位信息架构与布局规划师擅长把需求转化为清晰的功能分区。 ## 任务 根据品牌策略和设计上下文输出页面的布局方案。 ## 输出格式 使用 ASCII 线框图描述桌面端布局然后补充移动端简化布局。 ## 输出内容 1. 页面功能分区列表 2. 桌面端布局线框图 3. 移动端布局说明 4. 栅格系统建议 5. 交互行为说明 ## 注意 - 优先考虑用户核心任务路径 - 每个功能分区都要有明确的职责 - 不要与开发实现脱节html-builder.md# 角色 你是一名资深前端开发工程师擅长将设计说明转化为语义化、可访问的 HTML/CSS 代码。 ## 任务 根据前面的设计上下文、品牌策略、色彩系统和布局方案输出一个完整的 HTML 文件。 ## 输出要求 1. 文件路径output/index.html 2. 使用语义化标签header、nav、main、section、article、footer 3. 使用内联 CSS 或单个 style 标签 4. 必须包含响应式布局使用 CSS Grid 或 Flexbox 5. 必须包含以下基础样式 - 色彩系统 CSS 变量 - 字体排版规范 - 间距系统 - 基础组件样式按钮、卡片、导航 ## 输出前检查 - 页面有完整的主标题和次级标题 - 所有链接都有可访问的名称 - 表单控件有关联的 label - 没有内联事件处理器 - 代码格式化清晰 ## 注意 - 不要引入外部 CSS 框架 - 不要使用图片占位服务 - 确保纯 HTML 文件可以直接在浏览器中打开预览ui-reviewer.md# 角色 你是一位用户体验评审专家负责审查页面的可用性、可访问性和视觉质量。 ## 任务 读取 output/index.html从以下几个维度输出审查报告 1. 信息架构合理性 2. 视觉层次 3. 可访问性问题 4. 响应式表现 5. 性能隐患 ## 输出格式 使用 Markdown 表格包含问题级别、问题描述、修改建议、优先级。 ## 要求 - 问题级别分为严重、一般、建议 - 每个问题都要有具体的修改建议 - 不要只写稍显不足这类模糊表述4.4 编写编排脚本有了智能体配置还需要一个编排脚本来串联整个流程。下面用 shell 脚本实现。scripts/run-design.sh#!/bin/bash # 设计引擎编排脚本 # 用法./scripts/run-design.sh 你的产品需求描述 set -e DESCRIPTION$1 CONTEXT_FILEagents/system/design-context.md OUTPUT_DIRoutput if [ -z $DESCRIPTION ]; then echo 请提供产品需求描述例如 echo ./scripts/run-design.sh \一个帮助用户管理家庭能耗的仪表盘\ exit 1 fi if [ ! -d $OUTPUT_DIR ]; then mkdir -p $OUTPUT_DIR fi echo 第一步品牌策略分析 claude -p 请阅读 $CONTEXT_FILE 中的上下文然后根据以下需求执行品牌策略师任务$DESCRIPTION \ --append-system-prompt $(cat agents/brand-strategist.md) \ output/brand.json echo 第二步色彩系统设计 claude -p 请阅读 output/brand.json 中的品牌结果执行色彩系统设计师任务 \ --append-system-prompt $(cat agents/color-designer.md) \ output/colors.css echo 第三步布局规划 claude -p 请阅读 output/brand.json 中的品牌结果执行布局规划师任务 \ --append-system-prompt $(cat agents/layout-planner.md) \ output/layout.md echo 第四步HTML 页面生成 claude -p 请综合 output/brand.json、output/colors.css、output/layout.md 的信息执行 HTML 构建任务 \ --append-system-prompt $(cat agents/html-builder.md) \ output/index.html echo 第五步UI 审查 claude -p 请审查 output/index.html 文件执行 UI 评审专家任务 \ --append-system-prompt $(cat agents/ui-reviewer.md) \ output/review.md echo 全部完成产物已输出到 output/ 目录为脚本添加执行权限chmod x scripts/run-design.sh4.5 运行与验证运行编排脚本./scripts/run-design.sh 一个帮助用户管理家庭能耗的仪表盘要求能展示用电趋势、设备状态和节能建议脚本会依次执行五个智能体任务。每个任务跑完都会在终端输出当前步骤最终产物包括output/brand.json品牌策略结果。output/colors.css色彩系统 Token。output/layout.md布局方案。output/index.html可预览的页面。output/review.md审查报告。用浏览器打开output/index.html你应该可以看到一个基于设计上下文生成的静态页面。如果页面没有生成成功通常是中间某个智能体输出格式不符合预期导致的可以单独重新执行对应步骤。claude -p 请阅读 output/brand.json 中的品牌结果执行色彩系统设计师任务 \ --append-system-prompt $(cat agents/color-designer.md) \ output/colors.css4.6 把流程升级成可组合的 CLI目前编排脚本里只能按固定顺序执行如果你希望支持选择不同的智能体组合可以改进为一个 Node.js 命令行入口。下面是一段示意代码。scripts/generate-page.js#!/usr/bin/env node const { execSync } require(child_process); const fs require(fs); const path require(path); const agentsDir path.join(__dirname, .., agents); const outputDir path.join(__dirname, .., output); function readPrompt(name) { const filePath path.join(agentsDir, ${name}.md); return fs.readFileSync(filePath, utf-8); } function runAgent(task, promptFile, outputFile) { const prompt readPrompt(promptFile); const command claude -p ${task} --append-system-prompt ${prompt.replace(//g, \\)}; const result execSync(command, { encoding: utf-8, maxBuffer: 10 * 1024 * 1024 }); fs.writeFileSync(path.join(outputDir, outputFile), result); console.log(已生成 ${outputFile}); } const description process.argv[2]; if (!description) { console.error(用法node scripts/generate-page.js \需求描述\); process.exit(1); } if (!fs.existsSync(outputDir)) { fs.mkdirSync(outputDir); } runAgent( 请根据以下需求执行品牌策略师任务${description}, brand-strategist, brand.json ); runAgent( 请根据品牌结果执行色彩设计师任务, color-designer, colors.css ); runAgent( 请根据品牌和色彩结果执行布局规划师任务, layout-planner, layout.md ); runAgent( 请综合所有中间产物执行HTML构建任务, html-builder, index.html ); runAgent( 请审查生成的HTML文件, ui-reviewer, review.md );这个版本把每个智能体的调用封装成了函数理论上可以扩展到更多智能体组合。5. 常见问题与排查思路在实际运行 CLI 智能体设计引擎的过程中你会遇到一些高频问题。下面整理了一份排查表。问题现象常见原因解决思路claude: command not foundnpm 全局路径未加入 PATH将$(npm prefix -g)/bin添加到 PATH提示无法定位 CLI 二进制CLI 工具安装不完整或版本不兼容重新执行npm install -g检查 Node.js 版本输出内容为空API Key 未配置或额度不足检查环境变量和账户状态生成的 JSON 格式无法解析智能体输出了额外文字在 Prompt 中强调“只输出 JSON”或用脚本提取代码块HTML 页面风格不符合预期上下文信息不足或 Prompt 约束不够补充设计上下文文件增加示例某个中间步骤失败Prompt 中要求执行了不存在的文件检查前面的脚本是否真的生成了文件多次运行结果差异很大大模型生成存在随机性固定 System Prompt增加输出格式约束上下文过长导致生成质量下降输入给智能体的文件内容太多拆分任务或先用脚本提取关键摘要5.1 排查清单当你遇到问题时建议按下面的顺序排查先确认 CLI 工具本身能不能单独工作。运行claude -p test看是否有正常输出。检查环境变量。确认 API Key 已正确设置且没有拼写错误。单独运行某一个智能体确认是流程问题还是单个 Prompt 问题。查看中间产物文件。如果output/layout.md是空的那问题一定出在第三步而不是第四步。确认文件路径。脚本里的相对路径依赖当前工作目录建议在项目根目录执行。检查特殊字符。需求描述中的引号、中文标点可能导致命令解析失败必要时用文件传递输入。5.2 关于“unable to locate the codex cli binary”类报错网上经常看到“unable to locate the codex cli binary”这类报错它本质上也是 CLI 工具路径找不到或版本不匹配的问题。无论你用的是 Claude Code CLI 还是 Codex CLI解决思路是一致的确认全局安装完整。确认 PATH 路径正确。确认当前终端会话已经重新加载过配置。如果是通过 IDE 插件调用 CLI需要确认插件设置的 CLI 路径指向真实安装位置。安装类问题不需要慌九成是环境变量问题。6. 最佳实践与工程建议6.1 Prompt 配置要进版本管理智能体配置不是临时写在命令行里的草稿而是工程资产。每个智能体的 Prompt 文件都应该纳入 Git 管理这样你可以追踪“为什么某个版本生成的页面风格变了”。建议每次修改 Prompt 后提交信息写清楚改动目的feat(agent): 调整色彩设计师的对比度要求新增 WCAG AAA 限制 fix(agent): 修复 html-builder 未输出完整页面结构的问题6.2 为智能体设置明确的输出契约如果智能体输出的格式不稳定后续步骤就很难消费。最稳的做法是为每个智能体定义输出契约。比如色彩设计师的输出可以严格要求只输出 CSS 变量块不要输出解释文字。在 Prompt 中加一句你的输出必须是可以直接复制到 CSS 文件的合法内容不要包含 Markdown 代码块标记不要包含任何解释性文字。这样脚本就可以把输出直接重定向到.css文件不需要再清洗。6.3 控制 Token 消耗CLI 智能体在长任务中会消耗大量 Token尤其是当它反复读取大型文件时。控制成本的几个技巧不要让每个智能体都读取所有文件只读取它需要的那部分。中间产物尽量精炼。品牌策略输出几行 JSON不要让它生成一篇长文。使用-p非交互模式跑自动化任务避免长时间挂在会话里。为每个任务设置超时时间防止异常情况导致无限调用。6.4 设计上下文要独立维护设计上下文是影响所有角色的关键文件。推荐把项目品牌色、目标用户、设计原则统一放在agents/system/下其他角色的 Prompt 里都引用这个上下文。这样可以实现“改一处全局生效”。例如如果项目风格从“科技感”调整为“温暖居家感”只需要修改设计上下文里的风格偏好所有智能体都会收到新的约束不需要逐个修改。6.5 安全边界与权限意识CLI 智能体可以执行终端命令这在带来便利的同时也引入了安全风险。使用时要遵守几条基本原则不要让智能体执行带有破坏性的命令比如rm -rf。在 Prompt 中明确禁止危险操作例如“不要执行任何删除文件、安装全局依赖、修改 git 历史的命令”。在 CI/CD 或生产环境使用 CLI 智能体时使用最小权限账户。API Key 只通过环境变量注入不要写入任何 Prompt 或普通文件。对生成的外部资源下载类命令保持警惕。涉及重要代码库变更时让智能体先在分支上生成人工审查后再合并。6.6 从 5 个智能体扩展到 26 个当我们讨论“26 个 CLI 智能体”时指的是设计流程可以被切得更细。在实际项目中你可以边用边扩展。建议起步阶段先搭一个 5 个角色的最小闭环跑通之后再逐步增加品牌策略色彩系统布局规划HTML 构建UI 审查跑通之后再增加 UI 文案、Design Token 生成、Storybook 代码生成、SEO 审查、性能审查、无障碍审查、React 组件生成、Figma 变量格式化等角色。每次增加一个角色都可以独立验证它对最终产物是否有正向影响不要盲目堆数量。6.7 产物沉淀与知识复用设计引擎每次运行的产物都应该被沉淀下来。建议在output/目录里按日期创建子目录output/ └── 2025-01-20-home-dashboard/ ├── brand.json ├── colors.css ├── layout.md ├── index.html └── review.md这样积累一段时间后你就拥有了一批“AI 生成 人工修正”的设计样本。这些样本既可以用作后续智能体的 few-shot 示例也可以用来分析哪类 Prompt 效果更好。7. 后续可以怎么玩设计引擎做完之后你可以继续往几个方向扩展。一是接入组件库。让 HTML 构建智能体不仅生成页面还能输出符合你团队组件库规范的代码例如基于 Ant Design 或 Element Plus 的 React/Vue 组件。二是增加图片生成能力。CLI 智能体可以调用图片生成接口把色彩方案和布局描述转成视觉稿草图让设计评审更直观。三是做成团队内部 CLI 工具。把设计引擎发布为 npm 包团队成员安装后在任意项目里执行一条命令就能生成规范化的设计初稿。四是接入 CI/CD。在项目提交 PR 时自动运行 UI 审查智能体针对改动的页面输出报告辅助人工 Code Review。这个方向最吸引人的地方在于它把“设计能力”从一个依赖图形界面的黑盒变成了可以被组合、被测试、被复用、被版本管理的工程能力。设计引擎的价值不在于第一次生成结果有多完美而在于它让流程里的每个环节都有了可优化的抓手——今天改进色彩 Prompt明天增加一个审查智能体后天把某个步骤替换成更专业的模型。迭代下去这套引擎会越来越贴合你自己的项目风格。如果这篇文章对你有帮助可以收藏备用。接下来建议你自己动手创建一个agents/目录选一个真实的小项目从 5 个智能体开始跑通流程再逐步扩成 26 个。只有亲手跑过一遍你才能真正理解 CLI 智能体在设计流程中的边界和潜力。