DesignOS
构建产品设计智能体工作流

随着 AI Agent 在设计工作流中的应用逐渐深入，我希望 AI 真正参与完整产品设计流程。
尝试在产品设计流程的不同阶段结合岗位工作输出不同的 skill 辅助设计，但在不同 IDE（如 Cursor、Trae、Claude Code 等）中使用时，遇到了几个问题：

• 每个平台需要重复导入 Skill
• Skill 更新后需要手动同步
• 多设备环境无法保证版本一致
• 不确定当前 IDE 使用的是不是最新 Skill

最初尝试通过本地映射文件解决同步问题，但仍然存在：换电脑无法同步、配置维护成本高、多环境管理困难。

Skill 能力沉淀

将产品设计经验拆解为独立 Skill，我把不同的设计方向通过不同的技能来解决分析的问题。

为了让 AI 可以精准的调用，我在每个 Skill 通过 SKILL.md 进行规范描述：

• 使用场景
• 触发条件
• 执行流程
• 输出规范
• 专业知识约束

npx skills add chantezy/skills --skill prd-generator

npx skills add chantezy/skills --skill requirements-content-analysis

npx skills add chantezy/skills --skill b-design-diverge

npx skills add chantezy/skills --skill interaction-spec

npx skills add chantezy/skills --skill interaction-design-eval

Skill MCP 服务化

将 Skill 封装为 MCP Server。各个 IDE 产品对于 MCP 的兼容性比 SKILL 要好，我的目标是通过同一个服务，多端 IDE 可以调用，共享最新设计能力。内容更新上是：我 push 到 github 后，npm 自动同步最新的内容。

MCP 整体结构设计为：

mcp-product-design

├── src
│
│── index.ts
│     MCP 服务入口
│     注册 Tool
│
│── skill-loader.ts
│     SKILL.md 解析
│     Skill 加载管理
│
├── scripts
│     skill 同步脚本
│
├── package.json
│
├── tsconfig.json
│
└── README.md

将沉淀的产品设计 Skill 封装为基于 npm 发布的 MCP Server，通过 npm 包管理实现 Skill 能力的统一分发与自动更新。

npm（Node Package Manager）是一个用于管理和分发代码包的平台，类似于"应用商店"。在这个方案中，我将 MCP 服务打包成一个 npm 包并发布到 npm 仓库，AI IDE 通过 npm 自动下载安装并运行最新版本的 MCP 服务。后续 Skill 内容更新后，只需要重新发布 npm 包，使用方重新加载即可获取最新能力，无需手动替换文件。

MCP Server 负责解析和管理 Skill 内容，并通过标准化 Tool 接口向不同 AI IDE 提供设计能力。只需要维护一份 Skill 源文件，发布后 Cursor、Trae、Claude Code 等支持 MCP 的 IDE 均可直接调用最新版本，无需重复配置和手动同步，整体流程为：

MCP调用方式

npm i @chantezy/mcp-product-design

{
  "mcpServers": {
    "product-design": {
      "command": "npx",
      "args": ["-y", "@chantezy/mcp-product-design@latest"]
    }
  }
}

MCP 包括三个工具，会获取我 push 到 github 的 skill 列表，然后AI根据用户提问内容自动匹配适合的 skill 进行内容输出。

IDE 接入 Agent

到这一步已经实现了在不同的 IDE 中调用统一 SKILL 的能力，但是有个不够完美的地方是 MCP 本质上还是主动触发的工具，用户需要明确指定调用哪个技能来进行内容输出。

OpenAI 自己的数据也印证了AI 发展已经从「跟 AI 对话」转向「编排 Agent 执行任务」。

AI Agent 是指人工智能代理（Artificial Intelligence Agent），是一种能够感知环境进行自主理解，进行决策和执行动作的智能体。AI Agent 具备通过独立思考、调用工具逐步完成给定目标的能力。仅需要给定一个内容，就能够实现针对目标进行独立思考并完成目标任务。

一个基于大模型的 AI Agent 系统可以拆分 LLM（大模型）、记忆（Memory）、任务规划（Planning）以及工具使用（Tool） 的集合。在 LLM 为基础的 AI Agent 系统中，大模型为 AI Agent 系统的大脑负责计算，并需要其他组件进行辅助。

AI Agent 是基于大模型构建的智能执行系统，可以依据模型在意图识别完成复杂任务，具备真正的组合能力，这是与 SKILL 和 MCP 的主要区别。

Skill vs MCP vs Agent 对比

而相对于一般的对话模型，在流程上也有区别：

• 普通 LLM：用户输入 Prompt → 模型生成回答
• Agent：用户目标 → 理解任务 → 制定计划 → 调用工具 → 执行任务 → 输出结果

用户提问
   │
   ▼
┌─────────────────────────────────────┐
│         Agent 层（新增）              │
│  ┌─────────┐ ┌─────────┐ ┌───────┐ │
│  │ 意图识别 │ │ 对话历史 │ │任务规划│ │
│  └────┬────┘ └────┬────┘ └───┬───┘ │
│       └───────────┴──────────┘      │
│              │                       │
│              ▼                       │
│  "需要调用 design_diverge 和        │
│   generate_spec，分两步执行"        │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│         MCP Tool 层                 │
│  ┌─────────┐ ┌─────────┐ ┌───────┐ │
│  │analyze_ │ │ design_ │ │evalua │ │
│  │require  │ │ diverge │ │_inter │ │
│  └─────────┘ └─────────┘ └───────┘ │
│  ┌─────────┐ ┌─────────┐           │
│  │generate │ │ prd_    │           │
│  │_spec    │ │ generate│           │
│  └─────────┘ └─────────┘           │
└─────────────────────────────────────┘

举一个案例解释：
用户："帮我分析这个需求，然后做几个设计方案对比"
       │
       ▼
   Agent 理解意图
       │
       ├── 第一步：调用 analyze_requirements
       │         │
       │         ▼
       │     得到分析结果
       │
       ├── 第二步：调用 design_diverge
       │         │
       │         ▼
       │     得到设计方案
       │
       └── 第三步：整合结果，给出最终回复
               │
               ▼
           返回完整方案

在 TRAE 中配置智能体

通过 MCP 配置，让 IDE 中的 Agent 自动调用设计能力。

【提示词 + 调用场景 + MCP 工具】

自动调用逻辑

根据具体使用场景定义何时触发相应的 SKILL

技能组合路径

不需要手动选择技能，智能体会自动识别并组合调用。

示例：
用户："帮我分析直播首页需求，然后做设计方案"

智能体内部流程：

1. 调用 list_skills → 看到 5 个技能的触发条件
2. 判断："分析需求"匹配 requirements-content-analysis
3. 判断："设计方案"匹配 b-design-diverge
4. 判断顺序：先分析后设计
5. 调用 get_skill("requirements-content-analysis") → 执行分析
6. 调用 get_skill("b-design-diverge") → 执行设计
7. 整合两个结果返回

最后的实现效果如下：

Intent Router 的优化策略

虽然我相信 AI 对于自然语言的意图识别能力，但是我想在语义模糊的时候做一些规则来限制 token 的消耗浪费，我针对用户的模糊语境增加了两个兜底规则。

1、函数解析 SKILL.md 时提取 trigger

我在每个 SKILL 中都增加了 trigger，用一句自然语言描述 Skill 的典型适用场景。Intent Router 可以优先根据 trigger 进行快速匹配，而无需完整加载 Skill 内容。并且设置了已调用SKILL的记忆设置，重复调用无需重复加载。

mcp-server/src/index.ts 的 list_skills 工具里，把 trigger 展示给 AI：

const lines = skills.map(
  (s) => `- **${s.name}**  —  ${s.trigger || "查看描述了解适用场景"}`,
);

根据用户意图，选择最匹配的 skill 调用 get_skill：

• b-design-diverge — 当用户需要发散 B 端设计方案、对比多个设计思路、生成设计示意图时使用
• interaction-design-eval — 当用户需要评估/打分/评审交互设计方案、测评设计质量、或做设计师职级能力盘点时使用
• interaction-spec — 当用户需要撰写交互说明文档、组件行为描述、状态说明、动效规范时使用
• requirements-content-analysis — 当用户需要分析产品需求、梳理业务流程、识别用户痛点时使用
• prd-generator — 当用户需要撰写产品需求文档、PRD 时使用

2、当用户输入无法明确匹配时，使用兜底规则

如果用户输入模糊，比如：

• "帮我设计一下"
• "帮我优化一下"
• "帮我看看这个方案"

此时，我们根据上下文判断最可能的流程，如：

• 若包含"方案"、"设计"等关键词 → 优先匹配 b-design-diverge
• 若包含"评审"、"打分"、"评估"等关键词 → 优先匹配 interaction-design-eval
• 若包含"交互"、"说明"、"组件"等关键词 → 优先匹配 interaction-spec

DesignOS 设计流程总结

最后封装成 MCP 的价值也在于，在绝大多数真实使用场景中 更省 token。

我在这个过程中从工作流的不同阶段对内容进行组合，利用模型的分析和整理能力完成了一次设计工作方式升级。

• 文档输出：需求分析 → PRD 生成
• 快速验证：需求分析 → 设计发散
• 完整方案：需求分析 → 设计发散 → 交互评审 → 交互说明

从「使用 AI 工具」转变为：构建属于自己的 AI 产品设计工作流。让设计方法、经验和流程成为可复用、可组合、可持续进化的能力，最终实现：

• 一套设计能力，多 IDE 使用
• Skill 自动更新复用
• 设计知识资产化
• AI Agent 辅助完整设计流程