feat(quick-start): 统一后续创作流程的视觉语言与对话体验

[huyanxius]

Why

新版 /quick-start 已形成明确的产品气质：暖灰开放画布、中心化提问、克制绿色强调、低密度内容和稳定的底部输入器。用户进入的是一个直接、轻松的角色创作入口。

提交描述后，后续界面却突然切换为后台任务控制台：左右分栏、嵌套面板、重复状态栏和大量 Run / 节点 / 阶段信息压过角色产物。用户从“正在创作角色”变成“正在操作工作流”。

这不只是文案或按钮问题，而是页面空间、排版密度、表面层级、动效和交互责任全部断裂。仅替换文案、调整颜色或删除几个按钮无法解决，需要统一 Quick Start 后续流程的视觉与交互连续性。

Experience Positioning

Quick Start 的后续体验是一张持续展开的创作画布，而不是聊天软件，也不是工作流控制台。

它采用 Claude Code / Codex 式的单会话模型：从输入描述、等待生成、选择候选、补充修改、确认产物到最终预览，所有可见交互都发生在同一个 Quick Start 界面。runId 只用于刷新恢复，不代表一次可见的页面跳转。

“对话感”来自创作上下文持续存在、系统响应按时间自然展开、用户始终可以补充要求、产物始终是视觉焦点，以及系统只在需要审美或资产决策时邀请用户参与。

视觉基准以当前新版 Quick Start 入口为主：暖灰单画布、轻边界、克制绿、低密度和持续输入器。参考成熟 AI 产品的内容优先与连续生成结构，但不照搬通用消息气泡界面。

Current Problems

• 入口使用开放单画布，后续切换为左右面板、嵌套卡片和重复底栏，像进入另一个产品。
• Run、节点、阶段编号和制作进度比角色候选、首帧和动作结果更醒目。
• 多层圆角、边框、阴影和状态块增加密度，却没有形成清晰信息关系。
• 正常路径要求用户反复点击“继续下一步”“重新导入”“中断制作”等系统操作。
• 提交后输入器消失，用户无法自然补充“眼睛再亮一点”“动作更笨重”等要求。
• 失败时直接暴露供应商原始错误，缺少自然语言说明、原地重试和继续修改入口。

Visual Direction

单一创作画布

• 延续入口的暖灰背景、克制绿和低密度留白。
• 后续状态在同一主内容列中自然展开，不切换成后台工作台外壳。
• 移除常驻右侧进度栏和重复底部状态栏。

产物成为主视觉

• 角色候选、动作首帧和最终动画占据主要面积。
• 当前系统说明紧邻对应产物，进度和技术信息降为次级内容。
• 调试信息收进可展开详情，不直接暴露给普通用户。

减少界面表面

• 只有候选选择、产物预览等具有独立语义的内容才使用表面。
• 避免卡片嵌套卡片，主要使用留白、排版和轻边界建立层级。
• 不引入高饱和状态色、厚重阴影或控制台式标签。

保持输入器连续

• 底部输入器从入口持续存在到最终完成。
• placeholder 可以随阶段变化，但位置和基本形态保持稳定。
• 补充要求、重新生成和失败恢复优先通过自然语言完成。

连续动效

• 提交后，入口提示自然退场，生成状态在原位置接续出现。
• 候选、首帧和最终产物按创作顺序进入同一内容流。
• 阶段变化不触发整页框架跳变，并支持 prefers-reduced-motion。

Target Interaction Flow

状态	页面主要内容	用户决定	系统责任
描述角色	中心提问与输入器	输入创作意图	理解需求并启动制作
生成中	连续反馈、轻量进度、产物占位	可继续补充要求	自动推进内部任务
角色候选	大尺寸候选预览	选择候选或输入修改意见	选择后自动进入下一阶段
动作首帧	首帧预览与必要说明	确认首帧或描述修改方向	确认后自动生成完整动作
动作生成	动画生成反馈与预览更新	无常规操作要求	自动完成生成与恢复
最终审核	完整角色和动作预览	明确确认入库或继续修改	确认后保存，仍留在当前界面
失败恢复	自然语言错误说明和已有上下文	原地重试或补充要求	保留进度并恢复可继续状态

正常路径只保留三个有意义的人工判断：选择角色候选、确认动作首帧、最终审核并确认入库。候选点击本身即完成选择，不再追加“确认选择，继续下一步”。工作流推进、任务恢复和预览导入由系统自动处理。

Scope

• /quick-start 提交后的过渡。
• /quick-start/:runId 的生成中、候选、首帧、动作生成、最终审核、完成与失败状态。
• 完成后的角色与动作预览继续留在 Quick Start，不跳转到 Playtest 或 Workflow Editor。
• Quick Start 发起的 WorkflowRun 在后续制作过程中的用户侧呈现。
• 页面布局、排版、表面、状态层级、文案、操作组织和阶段动效。
• 前端自动推进现有工作流所需的交互调整。
• 桌面端与移动端的连续体验。

Out of Scope

• 不修改模型能力、生成质量或提示词策略。
• 不新增后端 Agent、长期会话系统或数据结构。
• 不重构 Quick Start 之外的完整 Workflow Editor。
• 不修改公开宣传页。
• 不取消用户确认后才写入角色资产库的规则。
• 不改变 Project、Character、Action 等领域关系。
• 不建立另一套页面私有设计令牌。

Acceptance Criteria

• 从入口提交到最终完成始终保持同一画布、排版、配色、表面和动效语言。
• 从描述到完成的所有可见交互都发生在一个 Quick Start 界面；流程中不跳转到 Playtest、Workflow Editor 或其他业务页面。
• 提交后不再切换成左右分栏的后台任务看板。
• 页面不存在常驻右侧制作进度面板和重复底部状态栏。
• 角色候选、首帧和最终动画在对应阶段均为第一视觉焦点。
• 底部输入器贯穿生成、确认、修改、失败恢复和完成前流程。
• 普通用户界面不展示 Run、节点、阶段编号及英文系统标签。
• 正常路径只要求用户完成候选选择、首帧确认和最终入库确认。
• 候选选择后自动推进，不再要求额外点击“继续下一步”。
• 内部工作流推进、任务恢复和预览导入不要求用户手动操作。
• 用户可以通过输入器提出修改或重新生成要求。
• 失败状态不直接展示供应商原始错误，并能保留上下文原地重试。
• 最终产物仍须用户明确确认后才进入角色资产库，符合 「产物需用户确认后入库」已确认为设计——缺的是契约明写与专用确认接口（现只有整树 PATCH） #123。
• 所有动效支持减少动态效果。
• 桌面端与移动端不存在明显视觉或交互断层。
• 入口、生成中、候选、首帧、最终审核、完成和失败状态均通过真实浏览器视觉验收。

Related Issues

• feat: 引入懒人智能体（Agent）与会话管理 #84：更广泛的 Agent 与会话能力；本 Issue 不实现新的 Agent，只重构现有 WorkflowRun 的用户体验。
• 「产物需用户确认后入库」已确认为设计——缺的是契约明写与专用确认接口（现只有整树 PATCH） #123：规定产物必须经过用户确认后入库；本 Issue 保留该确认边界。
• feat(ui): 建立四个产品页面的统一设计系统 #274：已建立产品页共享设计基础，但明确排除了信息架构和业务交互；本 Issue 处理尚未覆盖的 Quick Start 后续连续性。