信息转译重复
策划文档信息密集。UX 需要反复整理目标、规则、状态和边界，才能开始设计。
UBISOFT · JDM · INTERNAL PRACTICE
AI Assisted
UX Workflow
搭建从游戏设计文档（GDD）到 UX、从 Figma 到 Unity 的两段工作流， 将流程封装为可复用工具，配合使用指引与人工评审，支持同事独立使用。
JDM / DESIGN WORKFLOW
从设计依据，
从设计依据，
到可验证的交付。
- 01GDD游戏设计文档
- 02UX分析 · 线框 · 评审
- 03Figma组件 · 页面
- 04Unity引擎验证
HUMAN REVIEW关键阶段，由人判断与批准。
GDDUX ANALYSISWIREFRAMES
HUMAN REVIEW
FIGMAUNITY
01 / CONTEXT
AI 的价值不在于跳过设计过程，
而在于让过程更容易被检查。
设计依据容易丢失
需求范围、研究、设计检查清单和信息架构逐步转成页面时，早期判断的依据容易丢失。
生产衔接依赖人工理解
Figma 到 Unity 涉及重复搭建，也容易在组件复用、状态和交互语义上产生偏差。
设计命题
怎样让 AI 承担结构化与跨工具执行，同时保留 UX 对目标、取舍和质量的控制？
02 / OPERATING MODEL
AI 参与执行链，
人负责判断和批准。
在早期实践中，我按任务环境拆分工具职责：Goose 负责阶段产物， Codex 负责 Figma 与 Unity 执行，关键阶段由设计师评审和批准。 随后，我将共用规则与模板抽离到知识库，封装为团队可调用的 Skill（工作流执行工具）。
- Goose早期流程：阶段化运行、模板与 Gate
- Codex早期执行：写入 Figma、映射 Unity 资产
- Human确认设计目标，处理歧义，批准关键阶段
03 / WORKFLOW A
GDD to UX
从需求分析到 UX 稿，把设计推导拆成能够独立检查的阶段产物。00Preflight
01Scope
02Research
03Checklist
04IA
GHuman Gate
05AWireframes
05BReview Board
RECIPE RUN / 04:30
从导入 Recipe 到 Preflight 与人工 Gate
录屏展示一次实际运行如何集中填写输入、完成 Preflight 校验， 并在进入后续生成前停在人工确认节点。
STAGE 1
先确认设计问题
从 GDD、产品背景和目标用户中提取产品目标与 UX 目标，并明确范围、假设、风险与待确认项。
RUN RECORD
让每次运行留下可恢复的记录
阶段目录保存输入、分析、Checklist、IA、Wireframes 与 Review Board，不依赖聊天记录恢复上下文。
HUMAN REVIEW GATE
Stage 4 后必须明确批准
Agent 汇总阶段输出、关键假设、未解决问题和风险。 UX 可以要求修改前序阶段、批准 Wireframes、批准完整输出，或停止运行。
04 / WORKFLOW B
Figma to Unity
以明确的 Figma 设计范围为输入，完成语义解析、资产映射、人工评审与批准后生成。DESIGN PREPARATION · FIGMA
先准备可评审的 Figma 设计稿
进入 Workflow B 前，先准备设计输入：Codex 读取前序 Checklist、页面状态与项目规则， 在 Figma 中生成完整 Screen，并根据评审反馈同步修改多屏、保留依据和交互说明。
01输出低保真 Screens
02根据 Checklist 补齐状态
03按反馈同步修改多屏
04同步设计依据与交互说明
FROM DESIGN OUTPUT TO PRODUCTION
生成低保真之后，下一步是让设计稿能够被工程准确理解。
01Feature Section明确 Screen、State 与 Flow 的导出边界
02Semantic Naming让图层名表达组件类型、业务语义与状态
03Explicit Spec写明 Target、Trigger、Condition、Action 与 Result
04Asset Mapping扫描已有组件与 Prefab，优先复用真实项目资产
05Review First生成前先输出方案，无法判断时停止并报告
EXPLICIT INTERACTION SPEC
交互规则不能只靠图层位置推断
固定字段把按钮目标、触发条件、运行状态、成功结果和失败反馈写进交付物， 减少 Agent 仅凭视觉关系猜测业务逻辑。
05 / VALIDATION
真实价值来自发现误判，
并把纠偏写回流程。
WHAT FAILED
Agent 找到了资产，仍然没有做到最小新增。
- 把实例差异误判为类型差异，创建了多余 Variant。
- 复用已有 Item 后又包了一层不必要的新 Prefab。
- 把业务行为简化成文案与 Flow，交互语义仍然不完整。
01区分实例参数与结构差异
02新建前证明已有资产不能复用
03把交互规则写成固定字段
04先评审生成方案，再写入工程
IN PRACTICE
本轮实践确认的能力
- 阶段产物可以单独评审，并支持暂停与恢复。
- Wireframes 能追溯到 Scope、Checklist 与 IA。
- Figma 语义能够映射到真实 Unity 组件与 Prefab。
- 人工 Gate 能在生成前暴露错误假设与复用问题。
APPLICATION SCOPE
适用范围
- 主要生成 UI 与交互骨架。
- 复杂业务逻辑、数据与异常处理仍由程序接手。
- 同事已完成对应流程；扩展到新功能时，仍需检查设计规则与工程适配。
06 / TEAM ADOPTION
从个人实践，
到团队可使用的工作流。
我将工作流、使用指引与评审规则交给同事，支持他们独立完成从设计输入到阶段交付的流程。
01 可维护的封装
SKILL两条流程的执行入口
KNOWLEDGE设计规则与工程适配
TEMPLATES产物、评审与验证记录
把个人经验变成共用资产
封装两套 Skill，将共用知识、评审规则和交付模板纳入项目 AI Knowledge 库，并提交版本管理。
两套工作流与共用模板已纳入版本管理02 可执行的指引
ONBOARDING
- 选择流程GDD → UX / Figma → Unity
- 准备输入设计范围、上下文与工程配置
- 人工审核先看方案，再批准生成
让同事知道怎么开始、何时停下
在 Confluence 编写使用指引，说明输入要求、阶段产物与评审节点，帮助同事判断何时可以继续、何时需要补充信息。
图中概括了使用指引的三个关键步骤03 实际使用
WORKFLOW A
GDD UX 稿
同事已完成WORKFLOW B
Figma Unity
同事已完成同事独立完成两段流程
同事分别使用 GDD to UX 完成 UX 设计稿，使用 Figma to Unity 完成 Unity 界面搭建。
两段流程可分别使用，按各自节点评审
关键判断仍由人负责
同事可按任务选择相应流程，在关键节点评审设计方案并批准工程写入。两段流程均已用于团队实践，尚未进行系统性的效率量化。
内部分享与交流Ubisoft U Share Time #103
我也将两条工作流、真实案例、误判和后续方向整理为内部分享，让同事能够讨论方法与适用边界。
REFLECTION