AI Experience Design Case Study

VoC用户之声体验平台AI设计工作流探索

在 TikTok VoC 体验管理平台中，将 Figma 规范、Semi 主题包与 AI Skill 串联为一套可执行设计系统。帮助设计师用 AI 完成轻量需求修改、预览、提交 MR，并进入合码上线协作，成为设计+开发的双重角色。

My Role

业务支持者 / AI 工作流搭建者 负责 VoC 设计规范沉淀、Semi 主题包落地、AI Skill 结构设计、组件 Prompt 编写与设计侧 AI Coding 流程验证。

120+VoC 组件覆盖 3天→2小时C 级需求交付周期 >90%前端 Review 通过率 7位组内设计师共用工作流

查看我的角色查看真实案例

VoC 产品首页与关键指标总览 — VoC 首页与关键指标总览：让读者第一眼看到真实平台、业务线结构和核心分析能力。

What is VoC

VoC 是 TikTok 的体验反馈分析与 Issue 闭环平台

Voice of Customer 将 App 内反馈、客服工单、内部反馈和业务监控里的用户声音组织成趋势监控、原声明细、多维下钻与 Issue 管理。它帮助 PM、运营、研发和设计判断问题规模、影响范围、优先级和处理进度，是一个高密度、多角色协作的 B 端体验中台。

反馈收集趋势分析 Issue 闭环

业务复杂度 跨业务线、国家、渠道和设备版本筛选。

核心任务 发现异常、下钻原因、创建并跟进 Issue。

设计挑战 高密度数据、多角色协作和状态表达一致。

Product

复杂 B 端产品理解

从反馈趋势、多维下钻到 Issue 闭环，拆解真实体验管理平台的业务复杂度。

System

设计系统产品化

把 Figma 规则沉淀为 Semi 主题包、Token 和可复用业务组件。

AI Skill

机器可读的设计系统

把布局、组件 Preview 和 AI Prompt 封装为 AI 可读取的设计系统资产。

Workflow

可控交付闭环

人负责判断与边界，AI 负责局部执行，工程流程负责最终安全上线。

01 / Project Overview

这是一个 AI DesignOps 项目：把规范变成可交付工具

我不是只设计了一套界面规范，而是把规范转化为 AI 可以理解、工程可以调用、设计师可以用来交付需求的生产工具。

项目名称 VoC AI DesignOps System｜可执行设计系统与交付工作流

所属产品 TikTok VoC 体验管理平台

项目周期 2025.12 - 2026.Q2

我的角色 业务支持者 / AI 工作流搭建者

核心成果 设计团队独立完成 C 级需求上线，交付周期从 3 天缩短至 2 小时

Case Thesis

AI Experience Design 不只设计界面，也设计人机协作方式

传统设计系统主要帮助人理解规范；这个项目进一步把规范转换为工程主题包和 AI Skill，让开发环境可以读取设计规则，也让设计师在明确边界内参与修改、预览、MR 和上线协作。

02 / Product Context

VoC 是复杂的体验管理平台，覆盖从反馈分析到 Issue 管理的完整业务链路

平台包含趋势监控、多维下钻、原声明细、内部反馈、Issue 管理等核心场景。这决定了设计系统不能只解决视觉一致性，还必须沉淀复杂 B 端信息结构、筛选模式、图表布局和业务状态表达。

VoC Insight Dashboard — 趋势监控与多维下钻：高密度筛选、指标卡、图表和多维分析是 VoC 的核心体验。

VoC Issue Management — **设计思考** 把 Issue 列表从“任务集合”转成“风险分拣台”：优先级、状态、反馈量和趋势先被看见，再进入分派与解决。 *识别 → 聚合 → 分级 → 分派*

03 / Challenge

原有链路的问题，不是设计师不会表达，而是规范没有进入执行环境

规范停留在 Figma

设计规则对人可读，但无法被代码和 AI 稳定引用，落地质量依赖前端逐条理解与还原。

轻量需求也进入完整排期

文案、状态、间距、Tooltip 等 C 级调整需要等待前端开发，交付链路被不必要地拉长。

走查返工消耗协作成本

设计出图、前端还原、设计走查、反复修正，最终拖慢真实产品体验迭代。

Core Insight

AI 时代的设计系统，终点不是一致性，而是可执行性

如果 AI 要参与界面生产，设计系统就不能只是一份“让人遵守”的说明书。它需要成为开发环境中的上下文，能约束组件选择、布局方式、业务模式和代码生成边界。

04 / System Architecture

三层设计系统：从设计源文件到 AI 可执行规范

Figma 单源真值 Semi DSM 主题包 VoC Skill Trae / Aime MR / 合码上线

Layer 1

设计规范层

把复杂 B 端体验拆解为可复用的视觉变量、布局规则、响应式栅格和业务组件。

产出物：VoC 设计规范 2026-Q2
作用：建立所有下游资产的单源真值

Layer 2

主题包层

将设计规范发布为 Semi DSM 主题包，并通过 npm 包进入工程依赖体系。

产出物：Semi 官方 VoC 主题包
作用：让设计规范从人可读变成机器可读

Layer 3

可执行 Skill 层

把组件规则、布局约束、业务最佳实践和反模式写入 AI 可理解、可调用的 Skill。

产出物：VoC Skill 组件沙盒站点
作用：让 AI 知道什么是正确的 VoC 界面

Layer 1 Evidence

设计规范层：把复杂 B 端体验拆成可复用规则

Figma 规范不只沉淀组件外观，还包含颜色变量、间距标尺、响应式栅格和业务状态组件。它定义了 VoC 后续主题包、Skill 和代码生成的基础边界。

Figma color variables — 用颜色变量建立视觉单源真值，并在真实页面上标注 token 应用关系。

Figma spacing usage guideline — 把页面级、容器级、模块级、组件级间距拆成明确的使用规则。

Layer 2 Evidence

主题包层：把设计规范从人可读变成工程可消费

Semi DSM 主题包将 VoC 规范发布为可复用的代码资产。工程侧可以通过主题市场预览、切换亮暗模式，也可以通过 npm 安装，让规范进入真实代码依赖。

Semi DSM VoC light theme — VoC 主题包发布到 Semi 主题市场，覆盖组件样式与品牌色。

Semi VoC theme npm package — 主题包成为工程可安装的 npm 资产，设计规范进入代码依赖体系。

Design Thinking

主题包不是换色，而是把品牌、暗色与可访问性一起工程化

通过色阶、语义 Token 和对比度校验，让同一套组件在亮暗模式下保持一致的业务含义与可读性。

Layer 3 Highlight

可执行 Skill 层：让 AI 知道什么是“正确的 VoC 界面”

VoC Skill 不是静态文档，而是可以被 AI 开发环境安装和读取的设计系统资产。每个页面布局、业务组件和代码生成规则都包含 Preview、约束说明和 AI Prompt。

可安装

Skill 包结构

包含 SKILL.md、references/ 和 scripts/，可以在 Trae 中作为本地 Skill 加载。

可执行

组件级 AI Prompt

明确组件导入、业务复用、I18N、不要硬编码、不要修改内部源码等约束。

可验证

Preview + Applied Example

让设计师和 AI 都能对齐最终界面效果，而不是只依赖抽象规则。

Interactive Playground

把组件调用台嵌进 Skill，研发和产品可以直接拉取可复用组件

面对新增输入框、替换组件、调整筛选项这类 C 级需求，研发和产品可以在 Playground 中直接找到对应组件、查看 Preview、复制 AI Prompt，并由 VoC Token 约束颜色、间距和状态，减少凭经验实现带来的偏差。

VoC Skill download page — Skill 包可下载、可安装，说明它是开发环境资产，而不是传统设计文档。

VoC Skill List Card prompt — 业务组件同时提供 Preview 和 AI Prompt，指导 AI 按正确方式复用现有代码。

Semi AI Agent MCP Skills document — 与 Semi MCP / Skills 生态对齐

06 / AI Coding Workflow

AI Coding 工作流：把 AI 放进可控、可验证的交付流程

这套流程不是把需求直接交给 AI，而是把 AI 放在明确边界内：人负责体验判断与风险边界，AI 负责局部执行，工程流程负责 Review、合码与上线。

Core Principle

边界优先，让 AI 成为局部执行器

所有步骤、规则和限制，都是为了让模型只做它可靠的事：不让 AI 做端到端决策，不让它独自判断影响面，也不让它自己确认正确性。

人先拆任务 AI 只做局部执行人类增量 Review 正式流程上线

Allowed

AI 可以可靠完成的工作

确定性翻译：把明确输入输出要求转成对应代码。
模式匹配：复用代码库中已有结构完成相似功能。
机械修改：格式调整、参数修改、样板代码生成。
用例生成：根据功能描述补充常规测试场景。

Forbidden

AI 必须被禁止的工作

架构决策：方案取舍、边界判断、系统性拆分。
影响面评估：判断修改是否影响其他功能。
隐式逻辑推理：处理代码里没有写出的历史约束。
错误自检：让模型独自确认自己输出的正确性。

阶段责任人核心动作设计目标缺陷拦截率

1. 需求前置分解 RD

静态拆分任务边界、文件范围、修改点。

从源头消除大模型最不擅长的系统理解、架构决策和影响面评估。

~70%

2. 单任务翻译 AI

自然语言到代码的确定性翻译。

只允许局部代码生成，禁止任何范围外修改。

~15%

3. 增量 Code Review RD

单次变更控制在 ≤5 文件 / ≤200 行。

利用人类模式识别优势，在认知负荷阈值内发现逻辑错误。

~10%

4. 用例驱动测试 AI + QA

生成测试用例，并对照用例完成边界检查。

拦截明显的功能正确性问题。

~4%

5. 灰度发布流程 SRE

分批次上车、可回滚。

作为生产环境前的最后一道安全网。

~1%

前置拆分

RD 先把需求拆成独立小任务，明确修改文件、范围和验收点。

AI 执行

产运按任务逐个给 AI 发指令，用 /adk:specify 生成规范后实现代码。

增量评审

每完成一个小功能就提 MR，单次变更控制在可被人类可靠审查的粒度内。

测试验证

AI 生成测试用例，自测后交给 QA 确认关键边界和主流程。

合码上线

逐个合并通过评审的分支，跟随班车节奏发布上线。

Production Handoff

设计侧 Vibe Coding 不是绕开流程，而是更早进入流程

从实际交付实践来看，AI 完成局部实现后，真正的交付才刚开始：先在代理环境与 PPE 预览确认效果，再进入 Meego、合规评估、Pipeline、Code Review 和班车上线。

代理预览 PPE 确认 Meego 节点合规评估 Pipeline RD CR MR 合入班车上线

01 先处理开发阶段卡点

运行、代理、页面效果和明显样式问题先在本地闭环，再进入正式评审。

02 再解决测试阶段卡点

对照用例和 QA 反馈修正边界问题，避免把 AI 产物直接推给下游兜底。

03 最后进入 MR 与班车

Pipeline 报错交给 RD 定位，CR 通过后再合码，并跟随 Meego FE 上线节点。

Meego workflow for UX optimization — UX 优化进入正式需求流程，包含技术方案、安全评审、QA、FE 上线等节点。

Legal compliance review — 设计侧自主开发仍然进入产品合规与风险评估流程。

Bits pipeline detail for VoC deployment — 设计修改进入真实流水线，包含代码提交、检查和部署节点。

Bits integration task list for VoC release — 合码前进入真实集成检查，开发任务、MR 状态和准入结果都有明确记录。

Bits release pipeline after VoC deployment — 发布阶段进入班车流水线，证明设计修改最终走到检查通过和上线链路。

05 / Real Production Case

真实案例：一个线上 Tooltip 问题如何穿过 AI Coding 流水线

这条案例证明工作流不是概念 Demo。你在线上发现 Issue Detail 页 Tooltip 使用问题后，开启系统代理模式，提取相关代码块，在 Trae 中完成局部修改，并把规范沉淀、Meego、合规和 MR 串成完整闭环。

Layer 1

定位局部问题

在真实 Issue Detail 页中发现 Tooltip 热区、按钮状态和标签展示存在体验优化空间。

Layer 2

锁定代码边界

通过系统代理与浏览器 DevTools 定位目标 DOM、class、spacing 和 disabled 状态。

Layer 3

AI 局部执行

在 Trae 中让 AI Agent 结合页面代码、设计意图和 VoC 规则完成小范围实现调整。

Layer 4

预览确认效果

在代理环境中确认视觉间距、状态标签与交互热区达到预期，避免凭想象提交。

Layer 5

进入正式协作

创建 Meego、完成合规评估并提交 MR，让设计修改进入真实工程守门流程。

Tooltip Case

从一次线上问题，沉淀成可复用开发约定

这个案例真正有价值的不是“AI 改了一段代码”，而是你把一次线上走查变成了新的团队规则：先识别 trigger，再确认布局约束，最后才处理 spacing 与 offset。

6.1-6.2Vibe coding 6.3跟车上线 8px标准间距 4px局部 offset

01 线上异常

Tooltip 与触发器间距不统一，icon 尖角与 hover 热区出现偏差。

02 工程定位

确认根因不是规范缺失，而是 wrapper、盒模型和代码包位置造成视觉差异。

03 规则沉淀

产出 tooltip-guidelines.md，形成可被研发复用和 Review 的检查清单。

Why it matters

这次修改的价值不在于 AI 完成了一段代码

更重要的是验证了设计侧可以在明确边界内，用 AI 参与轻量体验问题修复；发现问题、限定范围、预览验证和规则沉淀都由设计侧主动完成，最后再进入正式工程协作。

Issue Detail before optimization — 发现线上 Issue Detail 页存在 Tooltip 与按钮状态体验问题。

Issue Detail after optimization — 调整后状态表达更完整，字段展示和视觉节奏更接近规范预期。

优化前局部放大 — Tooltip 与 Join group 按钮热区贴近图表，状态标签信息不完整。

07 / Collaboration Model

协作关系重构：设计更早验证体验，工程更专注质量与发布

设计师通过 AI 工作流更快验证体验细节，前端更多投入到组件基建、工程质量和发布安全；双方不是互相替代，而是在同一条交付链路里重新分配判断、执行和验证责任。

同一件 C 级体验修改，旧流程是“交付后再走查”，新流程是“设计侧先验证，再进入工程发布”。

Before

线性交付：设计在下游验收

设计出图用静态稿表达意图 前端还原逐条理解组件与状态 设计走查在下游发现体验偏差 前端返工轻量问题也拉长周期

设计主要在下游验收效果，轻量调整也容易进入完整排期。

核心变化 体验跑通后工程再发布

人负责判断，AI 负责局部执行，工程负责安全上线。

After

分层协作：人在上游做判断

设计师定义体验目标明确边界与验收标准 AI 执行局部修改只处理可控的小范围代码 设计师预览验证先确认体验是否达标 RD / QA Review 与发布进入正式工程安全门

设计侧先完成可控的小范围验证，工程侧负责 Review、合码和上线安全。

读法：这不是让设计绕过工程，而是把一次交付拆成判断、执行、验证和发布四类责任，让 AI 只承担可控的局部执行。

Before

设计出图，前端还原

设计交付静态稿，前端负责还原，设计走查后再修正，平均周期约 3 天。

After

设计直接修改，前端安全 Review

设计师通过 AI 工作流验证轻量体验修改，前端聚焦组件基建、Review 与发布安全。

Designer

体验判断与最终形态

负责发现问题、定义体验目标、确认最终效果，并对界面质量负责。

AI Agent

局部代码执行器

负责按明确约束生成代码、复用模式、补充测试用例，不做自主决策。

架构与代码守门

负责任务拆分、影响面判断、Code Review 和最终合码安全。

QA / SRE

验证与发布安全网

负责用例确认、灰度发布、回滚机制和生产风险兜底。

08 / Impact

项目成果与影响

100%

设计团队可独立完成 C 级需求、样式调整、文案修改。

120+

完整覆盖 VoC 平台全部组件。

>90%

前端 Code Review 通过率。

7位

组内设计师共用该工作流，并完成线上需求交付。

阶段量化影响

7 个 设计侧 C 级需求已进入线上交付
约 18 人天 前端重复还原成本被释放
3 天 → 2 小时 单需求平均交付周期缩短
100% 样式、文案和状态调整可由设计侧独立完成
>90% 前端 Code Review 一次通过率

09 / My Role

我的角色：设计系统负责人，也是 AI 生产方式的搭建者

定义系统

梳理 VoC 平台组件、Token、响应式、深色模式和业务状态规范。

搭建链路

推动 Figma、Semi DSM、Skill、Trae / Aime 形成可执行链路。

沉淀流程

制定 10 步标准开发流程、FAQ、操作指南与答疑机制。

推动协作

重构设计与前端协作边界，让设计团队获得更高交付自主权。

Closing Thought

我不是只做界面的设计师，而是能驾驭设计、产品与开发的 AI 时代多面体。

这个项目证明，设计系统可以从规范资产升级为生产基础设施：它连接设计源文件、工程主题包、AI Skill 和真实上线流程，最终让设计师拥有更高质量、更短链路的产品交付能力。