途虎设计智能体：AI 驱动的设计生产力产品
角色：AI 产品经理 / 项目负责人。问题：重复性 UI 多、Figma 协作门槛高、放开生成后又不可信。策略：四阶段路线图——先验证拼装，再做可预览交付，再补质量闸门，最后把规范产品化进真实改稿。每阶段用 STAR 写清：用户与场景（S）→ 产品目标（T）→ 关键决策与方案（A）→ 结果与指标（R）。技术（知识库 / RAG / LLM / Skill）服务产品目标，不展开实现细节。
产品定位与路线图
| 项 | 内容 |
|---|---|
| 产品一句话 | 让业务/产品在途虎规范内更快出可讨论的设计方案，并逐步把「过检」与「改真实页」做成可规模化能力。 |
| 核心用户演进 | 设计师（拼装验证）→ 产品/业务/设计共创预览 → 业务/产品自助出稿（设计定规则抽检）→ 改真实业务页的人 + 设计规范 Owner |
| AI 产品关键命题 | 生成要「有依据」；放开后要「可控可检」；成本（Token）与幻觉要进产品机制，不能只靠模型自觉。 |
| 路线图逻辑 | 先证明场景（P1）→ 再换交付形态降门槛（P2）→ 再补质量与流程产品（P3）→ 再把规范沉淀为可复用能力进工程改稿（P4） |
阶段一验证：Figma 组件拼装提效
产品角色：需求与场景验证｜主用户：设计师｜成功标准：拼装路径成立、规范更统一
S背景 · 用户与问题
途虎移动端大量页面是重复结构：导航、列表、卡片、坑位本可由组件库拼装，却长期从零画，周期长、一致性差。若一上来做「从 PRD 直接生成代码」，风险高、难验真。产品决策是先在设计师工作流内验证「组件拼装 + Agent 辅助」是否真能提效。
T目标
- 验证「重复 UI → 组件拼装」是否是正确的自动化切入口。
- 形成可沉淀的页面结构与组件匹配经验（为知识库准备原材料）。
- 明确边界：本阶段不追求业务自助，不追求代码交付。
A关键决策与方案
- 场景收敛：只做 Figma 内拼装，不做跨工具大而全生成。
- 规则产品化：组件优先、按页匹配、模板提速；限制自由绘制以保证规范。
- 人机分工：Agent 出初稿，设计师保留取舍——AI PM 默认「人在回路」，避免把终稿权交给模型。
R结果与启示
| 结果 | 产品启示 |
|---|---|
| 拼装路径成立，规范更统一 | 自动化切入口选对了：重复 UI + 组件资产 |
| 交付仍在 Figma，业务难参与 | 下一阶段必须换交付形态，降低非设计角色门槛 |
| 沉淀结构与匹配经验 | 可进入「知识库化」与可预览交付 |
阶段二交付：设计知识库 → HTML 预览
产品角色：定义交付与体验｜协作用户：产品 / 业务 / 设计｜成功标准：能生成、能打开、能一起讨论
S背景 · 为什么做
拼装验证通过后，瓶颈变成协作与交付：方案锁在 Figma，业务/产品难随时打开。样本摸底显示自动化空间大（组件复用约 79.3%；150 条中约 119 条适合 Agent 出初稿；重复性需求约 75.3%）——用作立项依据，不是验收 KPI。
竞品（Figma Make 等）通用生成强，但对企业内组件/规范/历史资产调用弱。产品判断：差异化不在「更能画」，而在用得上内部资产 + 全员可预览。
T产品目标
- 主路径：自然语言/PRD → 命中内部规范与组件 → 输出 375×812 可预览 HTML。
- 体验目标：可解释（看得见用了什么依据）、可追问（多轮改）、可共创（多角色打开）。
- 刻意不做：独立质量检测与交付留证（留给阶段三）——先打通「看见」，再治理「可信」。
A关键决策与方案
产品机制（对应 AI 能力）
| 产品决策 | 解决的问题 | 能力落点 |
|---|---|---|
| 知识库优先于裸 Prompt | 规范与组件散落在人脑/文档 | 结构化设计知识库 |
| 先检索再生成 | 模型凭空编造组件/规范 | RAG + 展示命中依据（接地，≠质检） |
| 先结构清单再出预览 | 一句话直接画满屏难核对 | LLM 两段式：规划 → 渲染 HTML |
| RICH 协作体验 | 黑盒、难追问、难共创 | 角色/意图/会话/同屏预览 |
| 人在回路精修 | 生成不可当终稿 | 设计师保留判断；会话式再生成 |
用户路径（五步）：选场景 → 说需求 → 核对理解 → 确认依据 → 打开 HTML 预览并迭代。资料进上下文前做范围裁剪，控制 Token 与噪音。
AI PM 风控：RAG 命中 ≠ 合规通过；LLM 可能漏模块；多方案受成本/时延约束宜少量对照；无质检前「能不能交」仍靠人。
R结果与指标解读
- 交付升级：Figma → 全员可开的 HTML 预览，评审链路变短。
- 覆盖验证：重复性结构需求可稳定出可讨论初稿；立项数字说明市场空间，本阶段不宣称质量验收完成。
- 可复制：红虎/蓝虎复用「知识库 + 生成 + 预览」。
- 产品缺口暴露：「能生成仍不敢交」→ 明确下一阶段做质量与流程产品。
阶段三治理：自助出稿质量闸门
产品角色：质量与流程产品化｜主用户：业务/产品｜设计：规则 Owner + 抽检
S背景 · 放开生成之后
预览能力放开后，主用户切到业务/产品：他们要自助出稿推进评审，而不是排队等设计。AI 产品典型拐点出现——供给变容易之后，信任与成本成为主矛盾。
阶段三前没有设计质量检测产品：无难易分流、无 Plan 确认、无自检留证、无独立 Review。失败表现为跳步开工、理解跑偏、口头完工、上下文堆满导致慢且贵、该复用却从零生成。
业务 / 产品
要：快出稿、过程看得见、交得出、查得了。
设计师
要：从改稿苦力转为定规则、抽检、仲裁，经验可规模化。
T产品目标与指标
建设「说得清 → Plan 看得见 → 按计划生成 → 自检/Review 留证」的质量闸门产品。
A关键决策与机制设计
| 机制 | 产品意图 | 设计要点 |
|---|---|---|
| 意图难易分流 | 简单直出、复杂先问 | 复杂任务澄清 ≤3 问（背景/目标/策略），防审讯式体验 |
| Plan 先于生成 | 把黑盒变成可评审决策 | PRD 解构、指标、历史、策略；业务确认后再授权生成 |
| 取源优先级 | 少从零、少漂移 | 用户素材 → 历史 HTML → 知识库 → 从零兜底 |
| 交付自检 | 交稿可核验 | 流程完整性、视觉严重问题、交互死链；证据随交付流转 |
| Review Agent 解耦 | 出稿与评审不互相拖垮 | 独立查文案/硬约束/组件覆盖/用词一致；设计配规则抽检 |
| Token 治理 | 控成本与稳定性 | Plan/上下文限额，防「资料越多越漂」 |
R结果
- 业务可自助出初稿；复杂需求先澄清再 Plan，过程可追踪。
- 质量从「感觉」变成「哪条没过」；跳步/规则错误逼近 ↓60%。
- 同需求 Token 约 ↓40%；复杂完成率约 ↑20%。
- 设计师角色产品化：规则与抽检；口头规范开始拆成可执行约束，为阶段四铺路。
阶段四规模化：规范进真实改稿
产品角色：规范能力产品化 / 跨业务复用｜用户：改真实业务页的人｜设计：规范与检测 Owner
S背景
预览稿能交之后，价值下一跳是改真实业务页面。痛点变成：找不到改哪、易自造风格、规范无法自动判定、质检靠肉眼。产品目标从「出方案」扩展为「在规范内改线上相关页面，且可自动检查」。
T产品目标
- 把硬约束 / 专业指南 / Token 做成可执行、可检测的产品能力。
- Agent 改稿必须过闸门：澄清/Plan → 复用核查 → 合法数值 → 自检。
- 缩短定位—修改—预览；并在加油等业务线验证可复制（能力封装，而非单仓定制）。
A关键决策与能力打包
| 产品能力 | 用户价值 | 封装形态（点到为止） |
|---|---|---|
| 三层规范 | 什么必须过、什么是建议、什么数值合法，说得清 | 硬约束 Must · 专业指南 · Token 表 / tokens.css |
| 规范改稿助手 | 改真实页不跑偏、不跳步 | design-implement Skill（双源：项目写法 + 途虎规范） |
| 样式自动质检 | 改完即知有没有踩线，能修则修 | design-token-check + 改码后 Hook「改完即检」 |
| 定位与微调 | 少猜文件、少反复手改 | 元素点选定位、HTML 可视化编辑、本地预览手册 |
| 跨业务复用 | 不止一个业务线能用 | 加油等场景同构 Skill / Hook / 规范包 |
R结果
- 规范从文档变成可执行产品能力（可判定、可走查、可自动检）。
- AI 改稿全链路可控；常见样式违规可自动发现/修复。
- 人机协同路径缩短；跨业务验证可复制，具备平台化雏形。
AI 产品经理视角 · 总结
关键取舍：P2 先做「看得见」不做「过检」；P3 把信任做成产品机制；P4 把规范做成可复用能力而不是项目制人肉。
AI 特有功课：依据接地（RAG）、人在回路、Token/上下文治理、生成与评审解耦、指标区分立项空间与验收结果。
设计与 AI PM 的协作结果：设计师从主改稿者，转为规则与质量侧的规模化杠杆。