途虎设计智能体

角色：AI 产品经理（主导方案设计与跨团队落地，编写需求理解类核心 Skill）。 问题：小需求与复杂项目挤同一套重流程，交付慢、落地成本高；外部工具原型「看起来像」，却缺真实业务逻辑与规范，难以交付。 策略：三阶段路线图——先验证拼装，再做可预览交付，最后按需求复杂度分流、在真实页面按规范改稿。每阶段用 STAR 写清：用户与场景（S）→ 产品目标（T）→ 关键决策与方案（A）→ 结果与指标（R）。技术（知识库 / RAG / LLM / Skill）服务产品目标，只点到能力名称，不展开实现细节。

项目背景

2026 上半年「闪电需求」平台合计交付 337 条高频小颗粒度设计变更（基础组 174 条、轮保组 163 条），暴露出两个问题：

痛点	现状
需求交付慢，产品落地成本高	小需求与复杂项目挤同一套重流程，占排期、挤占高价值事项
外部工具原型「看起来像」，难交付	外部工具画示意图，缺真实业务逻辑、代码与设计规范，无法直接进产研流程

产品定位与目标用户

产品定位：让产品和业务同学自己就能在真实页面上改设计，改出来的东西符合途虎规范，可以直接上线。

目标用户演进：

• 阶段一 · 验证：先让设计师在 Figma 里试用，验证组件拼装是否真能提效。
• 阶段二 · 交付：产品、业务、设计一起打开 HTML 预览讨论。
• 阶段三 · 落地：简单需求产品自己改完上线；中等需求产品和设计一起定；复杂需求仍由设计师做。

验证：Figma 组件拼装提效

产品角色：需求与场景验证｜主用户：设计师｜成功标准：拼装路径成立、规范更统一

S背景 · 用户与问题

项目背景里的两个痛点，根源都是重复 UI 在消耗人力。第一步不急着解决交付，而是先验证「组件拼装」这个切入口是否成立。

途虎移动端大量页面是重复结构：导航、列表、卡片、坑位本可由组件库拼装，却长期从零画，周期长、一致性差。若一上来做「从 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 预览，评审链路变短。
• 覆盖验证：重复性结构需求可稳定出可讨论初稿；立项数字说明市场空间，本阶段不宣称质量验收完成。
• 可复制：红虎/蓝虎复用「知识库 + 生成 + 预览」。
• 产品缺口暴露：「能生成仍不敢交」→ 下一阶段转向在真实页面按规范改稿。

难点与反思

阶段二打通了「看得见」之后，落地中仍暴露两类硬伤，直接决定了后续必须从生成原型转向改真实源码：

• 缺真实业务逻辑的历史设计稿：知识库与样本里缺少带真实业务逻辑的历史稿，生成结果往往「看起来像途虎」，但不符合真实需求路径与业务约束，可用性不高，难当评审依据。
• 使用场景与意愿错位：当时主要落在 PRD 配套设计原型上——产品更愿意找人类设计师出稿与拍板，对 Agent 出的预览意愿偏低；「能打开共创」不等于「愿意日常使用」。

回头看，我们自己的 HTML 预览也遇到了和项目背景里外部工具同样的问题：「看起来像」，却难以交付。这两点说明：仅有组件/规范检索与 HTML 预览不够，需要让 Agent 直接基于真实业务代码工作，并把使用场景从「替代设计师出 PRD 原型」推进到「在真实页面按规范直接改、产出即可交付」——这也成为阶段三按复杂度分流、源码内落地的直接动因。

落地：首期简单需求由业务及产品侧直接生成

产品角色：分流策略与能力产品化｜主用户：产品 / 业务（简单需求）、产品 + 设计（中等需求）、设计师（复杂需求）｜成功标准：可覆盖率、设计侧时间成本、业务侧交付时长

S背景 · 从「能生成」到「能交付」

回到项目背景里的两个痛点：阶段二解决了「看得见」，但生成稿缺真实业务逻辑、产品更愿意找设计师，依然没有解决「交付慢」和「难交付」。阶段三的判断是：与其生成「看起来像」的原型，不如让 Agent 直接在真实业务源码里按规范改，产出即可交付。

T产品目标 · 按复杂度分流

• 简单需求 · 产品主导：不进设计研发流程，直接修改上线。
• 中等需求 · 产品 / 设计主导：Agent 出初版方案，产品与设计协同确认。
• 复杂需求 · 设计主导：交回设计师，Agent 只承担规范检测与还原。

对应项目背景的两个痛点：简单需求由产品 / 业务侧自己快迭代，不进设计研发排期；产出物从「可预览的原型」升级为在真实页面上按规范直接改、直接看效果的源码改动，产出即可交付。成功标准看三件事：能覆盖多少需求、设计侧还要投入多少、业务侧多快能交付。

A关键决策与能力打包

工程上以 Claude Code 插件 tuhu-design-toolkit 交付，愿景能力与实现一一对应：

愿景能力	用户价值	对应实现
需求理解	把 PRD / 需求文档 / IM 消息拆成结构化设计字段并标出信息缺口；动手前对齐业务目标、用户、设计策略与边界，产出设计简报交给下游	scope · brief（本人编写）
PRD → 设计生成	UI 需求直接在源码内落地，先复用已有组件与 token；命中保养列表可自动匹配 115 个已研发组件	design-implement
规范检测 loop	圆角 / 间距 / 描边 / 阴影 / 字号 / 颜色六类合规检测，改完代码自动跑一遍并修正违规	design-token-check
一致性检测	同类组件一致性实测，全局或两两对比几何差异；容器空白占比真实渲染测量	design-sibling-check · design-layout-check
手动编辑模式	浏览器点选元素，直接定位源码文件与行号并写回改动，Vue2 / RN-web 双栈通用	dev-element-picker
一句话拉起项目	一句话本地拉起 wash / blackgold / enterprise / rn-to-web，成功后自动装好检测与定位能力	project-init
AI 友好 PRD 生成	让需求输入本身更适合 Agent 理解	待补充，仍是空白

关键取舍：可覆盖的必备条件是设计组件已覆盖 + 代码仓库已开放——不满足的需求不硬上，直接归入「暂不支持」，保证交付质量。

R结果 · 试点证据

业务线	是否上线	设计时间成本	业务时间成本
加油	是	0	0 ~ 1.5–2 天*
洗美	否	0	约 5 分钟
大客户	试点中	0	待计算

* 加油试点内不同复杂度需求耗时不同，原文未拆分口径，如实保留区间。保养油液业务线另有 4 个真实案例（改文案 / 改颜色 / 复用已有标签组件），均分钟级完成。

覆盖率与建设优先级

分类	基础平台设计组	轮保综合设计组
Agent 可覆盖（±3%）	26%	26%
未来 Agent 可覆盖	11%	28%
暂不支持	约 57%	约 42%

两组「Agent 可覆盖」都在 26% 左右，但轮保综合设计组「未来可覆盖」（28%）明显领先基础平台设计组（11%），基建更成熟，应优先扩量。下一步补哪个组件，按 48 条需求、51 次组件提及排序：

组件类型	提及次数	占比
标签组件	18 次	35%
icon / 图标库	7 次	15%
优惠券组件	6 次	13%
其余（弹窗 / 素材 / 仓库等）	20 次	37%

正式接入进度与路线图

• 正式接入（规模化推广）：保养、轮胎推进中（预计 2 周）；蓄电池、加油、贴膜、洗美、订单列表待排期。加油、洗美、大客户为前期试点，正式接入还需补齐组件与仓库条件。
• Q3 中下旬轮保宣讲 → Q4 初期正式使用：简单需求为主，可复用组件的局部样式与文案调整。
• Q4 中期：组件 / 仓库 / mock 数据完善，覆盖简单交互链路。
• 远期：长链路交互、中等难度需求。

难点与反思

三线试点已验证方向：设计侧时间成本降为 0，简单需求的业务侧耗时从天级压缩到分钟级。规模化的卡点不在工具本身，而在组件库与代码仓库的开放进度——可覆盖率停在 26%，要继续提升，靠的是按需求频率补组件（标签 > icon > 优惠券）和推动更多仓库开放。另外，价值量化口径与风险边界仍待产品与设计先对齐方法，这是下一步要补的功课。

AI 产品经理视角 · 总结