nexu-io__open-design/specs/current/studio-chat-visual-discovery.md

Studio Chat 提问体验升级

1. 现在的问题

问题总结

当前 Studio Chat 的意图确认流程更接近一张固定配置表，而不是由 Agent 基于上下文发起的轻量对话。用户进入 Studio 后，常常需要重新回答系统已经知道的信息，再通过抽象文字判断视觉风格，并在 Chat 与 Questions 面板之间切换。整个过程提问偏早、问题偏多、缺少推荐和提交反馈，导致用户在看到任何结果前就承担较高决策成本。

核心问题可以归纳为四类：

1. 提问成本高：问题出现太早、数量多、专业术语多；即使多数题目可以跳过，用户仍要先处理整张表单才能进入生成。
2. 问题不够准确：没有充分利用 Home、模板、项目创建信息、Design System 和历史上下文，不同产物还共用相似的提问与风格体系。
3. 决策不够直观：抽象文字难以表达最终视觉效果，用户只能生成后判断方向是否正确。
4. 流程反馈与控制感不足：问题与 Chat 分离，用户不知道为什么问、还要问多久、答案是否生效，也不方便修改或交给 Agent 推荐。

因此，本次升级不只是把文字选项替换成图片，而是要同时解决三件事：减少不必要的提问、按产物提供可视化决策、让确认和反馈完整发生在 Chat 中。

现状数据支撑

现有样本显示，提问已经是一个高频且会显著改变用户路径的环节：

• 24.3% 的新项目首轮被提问（24,407 / 100,348），约每 4 个新项目就有 1 个先进入问答。
• Questions 表单累计曝光 127,016 次；其中 discovery 约 60k、task_type 约 36k，两类通用表单贡献约 76% 的曝光。
• discovery 主动提交率为 68.9%，task_type 仅约 57.9%，对应 skip 比例分别约为 31% 和 42.1%。用于补充产物类型的 task_type 是摩擦更明显的环节。
• 每张表单平均回答 3.48 题、跳过 0.93 题，约五分之一的题目没有获得有效答案，说明当前表单仍然偏长。
• 已记录的 skip 中，30,264 次来自 10 分钟倒计时自动继续，5,449 次来自用户主动点击；约 85% 的 skip 是被动超时，不能解读为用户主动选择“无需回答”。
• 首轮直接产出 artifact 的比例为 13.8%；回答问题后的下一轮产出比例为 25.8%，提高约 12 个百分点、约为前者的 1.9 倍。这说明有效澄清可能帮助产出，但回答后仍只有约四分之一立即得到 artifact，优化不能只停留在表单展示。
• 首轮提问率在 other（28.9%）、slide_deck（27.9%）、prototype（24.5%）和 mobile/wireframe（约 25%）中较高，而 image 为 6.9%、design_system 为 2.0%。不同产物明显需要不同的提问策略，不适合共用固定 discovery。

数据口径说明：以上结论来自现有分析截图；正式评审前还需补充统计周期、去重口径以及“曝光、run、项目”之间的定义。首轮提问 run 的 99.3% success 仅表示问答回合正常结束，不代表已经生成产物；13.8% 与 25.8% 也属于不同路径的相关性对比，不能直接解释为因果提升。

1.1 提问以文字表单为主，用户难以直观判断视觉方向

当前默认 discovery 最多包含约 7 个问题，其中“视觉调性”提供 7 个纯文字选项。用户需要根据 “Modern minimal”“Editorial”“Playful”等抽象词判断风格，只能在生成后验证理解是否一致。

现有 direction-cards 仅展示色板、字体、情绪描述和参考品牌，没有真实作品预览图，仍不足以表达最终视觉效果。

1.2 所有产物共用相似的风格问题，但不同产物需要不同的选择体系

PPT、Prototype、Document、Image、Video 的“风格”不是同一个概念：

• PPT 的风格体现为整套叙事、页面版式、图表和信息密度。
• Prototype 的风格体现为组件语言、界面密度、导航方式和多屏一致性。
• Document 的风格更多体现为阅读层级和编辑排版。
• Image、Video、Audio 各自有完全不同的媒介表达方式。

如果所有产物都使用同一组 “minimal / playful / luxury” 选项，视觉选择与最终结果之间缺少稳定映射。

1.3 Home 已经收集的信息没有被完整继承，进入 Studio 后会重复提问

用户可能已经在 Home 完成以下选择：

• 产物分类，例如 Deck、Prototype、Wireframe、Mobile、Image。
• 二级场景，例如 Dashboard、Pitch、Report。
• 示例或模板。
• Design System。
• 平台、保真度、页数、比例、时长等创建参数。

但当前不同入口传递信息的完整度不一致：

• 一级产物分类通常会写入 project kind。
• 部分二级分类只用于筛选示例，没有作为明确的 artifactSubtype 传入 Studio。
• Home 会主动移除部分 fidelity、slideCount、ratio、duration 等字段，留给 Agent 再次询问。
• 默认设计路由会固定输出 task-type 或 discovery 表单，即使用户的 prompt 已经明确写出答案。

结果是用户刚刚选完产物或参数，进入 Studio 又被问一次。

1.4 问题与 Chat 物理分离，打断对话连续性

当前问题表单主要展示在右侧 Questions Tab，Chat 中只显示一个 Questions Banner。用户需要从 Chat 切换到右侧面板回答，再回到 Chat 查看 Agent 后续进展。

这一模式带来几个问题：

• 用户不一定知道应该去哪里回答。
• 在窄屏或移动端，左右区域切换更加困难。
• 提交后答案会作为 [form answers — ...] 用户消息显示在 Chat，原问题也会标记为已回答；但展示偏技术化，缺少人类可读的 brief 摘要。
• 用户能看到答案已提交，但无法快速确认 Agent 最终采用了哪些选择、补了哪些默认值。

1.5 当前是“入口触发表单”，而不是“缺什么问什么”

系统根据用户入口选择两套模式：

• task_type：用于默认路由，固定询问产物类型、目标用户、品牌、规模和约束，共 5 项，不能根据 brief 删减。
• discovery：用于已明确场景的新设计任务，默认询问产物、平台、目标用户、视觉调性、品牌、规模和约束，共 7 项；可以删除已知字段，但仍必须在首轮出现。

两套模式都遵循“先问后做”：首轮输出表单并停止，用户回答后才进入下一次 run。仅局部修改、用户明确要求直接生成等少数情况可以跳过。

核心问题是提问由入口决定，而不是由信息缺口决定。 因此会同时出现三类情况：已知信息被重复询问、非关键问题占用用户注意力，以及用户必须多等待一轮才能看到产物。

1.6 提问时机过早、一次过多，用户尚未看到价值就要先填表

用户刚描述需求，Agent 还没有展示对任务的理解，也没有给出任何可见结果，就先抛出一组问题。这会让用户产生“还没开始就要填表”的阻力。

当产物、受众、风格、页数、品牌和限制同时出现时，用户需要一次完成大量决策。用户可能只认真回答前几个，后续随意选择或直接跳过，答案数量增加了，但信息质量未必提高。

问题还缺少稳定的进度预期。用户不知道一共有几个问题、回答后是否还有下一轮，以及什么时候才会开始生成。

1.7 问题不够贴合任务，且缺少回答理由

固定的通用问题无法体现不同任务的真实决策重点。例如：

• Live Artifact 更应该优先确认功能、数据源和核心交互。
• Wireframe 更应该确认页面、流程和信息层级。
• 局部视觉修改通常不需要重新确认受众和产物类型。

部分选项还包含 Fidelity、Editorial、Brutalist 等专业术语。即使完成翻译，非设计用户也不一定能形成准确理解。

同时，问题没有解释答案会如何影响结果。用户无法判断哪些决定值得认真选择，哪些可以交给 Agent 使用默认值。

1.8 缺少推荐和“让 Agent 决定”的低成本路径

当前流程倾向于把所有决策交还给用户，但很多用户并不具备专业设计判断，也不希望逐项配置。

更合理的方式是由 Agent 基于 brief 给出推荐及理由，例如：

推荐 Editorial Utility，因为当前产物是面向投资人的数据型 Deck。你也可以选择其他方向。

当前表单中只有产物类型等少数字段必填，页数、比例、讲者备注、Media 配置和其他约束本身都可以跳过。问题不在于这些字段“必填”，而在于它们仍作为首轮表单的一部分展示，用户需要逐项判断是否回答。

系统应直接继承线上已有配置，并对未填写的非关键项采用产品默认值；只有会显著改变结果、且无法从上下文推断的决策才需要用户确认。

系统还需要提供明确的“帮我选择”入口，让希望快速获得结果的用户把专业判断交给 Agent，而不是被迫理解全部设计选项。

1.9 提交后的反馈、摘要和答案采用情况不透明

用户提交答案后，当前体验没有清晰说明：

• Agent 最终如何理解这次任务。
• 哪些答案被采用。
• 哪些参数使用了默认值。
• 是否已经开始规划或生成。

如果后续产物没有明显体现用户的选择，用户也无法判断是选项没有生效，还是 Agent 对风格的理解发生了偏差。这会产生“问了但没用”的不信任感。

缺少人类可读的 brief 摘要，也让用户无法在生成前快速发现理解错误。

1.10 用户控制感与异常恢复不足

用户选择错误或中途改变想法后，不容易回到原问题修改答案，往往只能再发送一条自然语言消息纠正。

必填项、可选项和安全默认项之间的区别也不明确。“Skip all”虽然可以快速继续，但用户会担心跳过后影响结果质量。

在网络中断、刷新页面、切换会话或表单尚未完整生成时，还需要保证：

• 已选答案不会丢失。
• 同一份答案不会重复提交。
• 用户能够继续未完成的问题。
• 历史选择能够正确恢复并再次修改。

上述问题可以归纳为四类体验缺口：

1. 提问成本过高：太早、太多、太专业。
2. 问题质量不足：过于通用、缺少上下文、缺少推荐。
3. 流程反馈不足：不知道为什么问、还要问多久、答案是否生效。
4. 用户控制感不足：难修改、难放心跳过、难把判断交给 Agent。

2. 目标

2.1 用“看图选择”替代抽象的文字风格选择

对真正需要视觉判断的选项提供精选预览图，让用户在生成前就能感知方向差异。

图片不是装饰，而是稳定设计方向的入口。每个选项都需要绑定：

• 稳定的 style ID。
• 适用的产物类型。
• 面向用户的预览图和简短说明。
• Agent 可执行的设计语义与 prompt tokens。

2.2 根据产物类型加载专属风格目录

系统先确认或推断产物类型，再加载对应目录：

• Deck/PPT：投资路演、产品发布、编辑叙事、数据报告、课程培训等。
• Prototype：SaaS 工具、消费级 App、内容网站、电商、实验性界面等。
• Document：编辑排版、报告、Brief、长文阅读等。
• Image、Video、Audio：分别使用各自媒介的风格目录。

不同目录可以共享底层视觉属性，但不能向用户展示一套不区分产物的通用风格列表。

2.3 已知信息不重复询问

每次提问前，系统统一汇总：

1. 当前用户消息与附件。
2. Home 选择的产物分类、二级场景、示例和模板。
3. 项目创建信息（project metadata），例如产物类型、平台、保真度和模板。
4. Plugin inputs。
5. Active Design System。
6. 当前会话已经确认的答案。

任何已经明确的信息都不再询问。信息足够时允许 0 个问题直接开始。

2.4 把完整决策流程留在 Chat

用户在同一个 Chat 流中完成：

描述需求 → 看图选择 → 确认 brief → 开始生成

Agent 提出的问题直接展示在 Chat 对话流中，用户无需切换到右侧 Questions 面板即可选择并提交。提交后，问题卡原位折叠成人类可读的 brief 摘要，历史消息仍能看到当时选择的方向。

2.5 减少不必要的问题

只询问会显著改变结果、且无法可靠推断的决策。可以跳过的非关键参数不再集中展示给用户，而是继承已有配置或使用产品默认值，并允许后续修改。

期望问题数量：

• 0 个：信息完整，直接生成。
• 1 个：产物已知，只需要选择视觉方向。
• 2–3 个：补充关键结构信息和视觉方向。
• 不再固定输出一张通用的多问题表单。

3. 方案

方案优先级（由现状数据推导）

1. 优先优化 task_type：task_type 主动提交率约 57.9%、skip 约 42.1%，应先使用 Home 选择、用户描述和项目创建信息推断产物，只在低置信度时询问类型。
2. 第一阶段聚焦 Deck 与 Prototype：两类首轮提问率分别为 27.9% 和 24.5%，同时最需要产物专属的视觉风格目录。
3. 缩短而不是只美化固定问卷：每张表单平均跳过 0.93 题；图片选择只能解决“不直观”，还需要减少非关键问题并允许直接开始。
4. 优化回答后的执行衔接：回答后下一轮产出 artifact 的比例为 25.8%，仍只有约四分之一；提交后应立即展示 brief 摘要并进入生成。
5. 按产物制定策略：image 和 design_system 的首轮提问率仅为 6.9% 和 2.0%，应保留专用流程，避免为了统一视觉卡片反而增加问题。

3.1 建立“已知信息 → 缺失决策”的动态提问机制

将 discovery 从固定问卷改为动态决策：

1. 汇总所有已知上下文。
2. 判断当前任务是否属于新产物、局部修改或专用流程。
3. 推断产物类型和子类型。
4. 计算仍然缺失、且会显著影响结果的决策。
5. 没有关键缺失项时直接开始；有缺失项时只生成最短问题集。

现有问题不需要整体废弃。产物类型、平台、受众、视觉方向、规模和约束在对应场景下仍然有价值，方案只改变它们的展示规则：从“每次展示整套固定问卷”改为“根据当前缺失信息选择其中必要的问题”。文字问题继续用于受众、范围和约束；只有需要视觉判断的选项改为图片卡片。

信息冲突时，以当前用户消息和显式选择为最高优先级，不应静默采用旧值。

3.2 按入口决定是否提问

Home 已选择产物分类

不再询问产物类型，只补该产物仍缺少的信息。

• Deck：按需补 deck 子类型、受众；没有 Design System 或参考时展示 Deck 风格图。
• Prototype：按需补平台、关键页面或流程；没有视觉来源时展示 Prototype 风格图。
• Wireframe：只关心页面、流程和信息层级，默认不问装饰性视觉风格。
• Mobile：平台已知，只补关键流程和 Mobile 专属视觉方向。
• Media：媒体类型已知，只补主题与真正影响结果的媒介参数。

Home 已选择具体示例或模板

示例或模板已经确定产物、子类型、结构和视觉方向，默认直接生成。

只有用户修改后的描述与模板明显冲突时，才提出一个确认问题。

Home 自由输入

先从用户描述推断产物：

• 高置信度：直接进入对应产物的风格选择或开始生成。
• 低置信度：先询问一次产物类型，再加载对应风格目录。

New Project Modal

完整继承用户在创建阶段已经选择的 platform、fidelity、slide count、speaker notes、ratio、duration 等值，只补未填写的关键决策。

已有项目续聊

局部修改沿用项目类型、Design System、历史 brief 和风格选择，不重新 discovery。只有用户明确开启新产物时，才重新路由。

Design System 或参考素材已存在

• Active Design System 已经定义视觉语言，不再问通用风格。
• 上传参考图、品牌规范或参考网站后，不再展示通用风格目录。
• 如有必要，只确认“严格匹配”或“参考其方向”。

导入与迁移

Figma、Claude Design 或现有文件本身就是结构与视觉参考。只询问迁移范围、目标技术栈、保真程度等迁移决策。

专用流程

Plugin、Skill、Brand Kit 和 Design System 创建使用各自输入契约，不进入通用 discovery；Ask 模式保持普通对话。

3.3 建立按产物分类的视觉风格目录

第一版不需要为每个子场景单独制作一套风格，避免出现“产物 × 场景 × 风格”的组合爆炸。建议采用：

产物类型拥有风格目录 → 子类型负责筛选和推荐

例如 Deck 先维护 6–8 个稳定方向，Pitch、Report、Training 等子类型从中推荐最匹配的 3–5 个；Prototype 使用另一套独立目录，Dashboard、Mobile App、Landing Page 再从中筛选。

第一步：确定首批目录

• Deck：投资路演、产品发布、编辑叙事、数据报告、课程培训等。
• Prototype：SaaS 工具、消费级 App、内容网站、电商、开发者工具等。

每个方向必须在视觉上有明显差异，并能对应一组可执行的设计规则，不能只是给同一个模板更换颜色。

第二步：制作可比较的预览图

• Deck 使用同一份示例内容制作 3–4 页拼图，覆盖封面、内容页和数据页。
• Prototype 使用同一组示例页面制作多屏拼图，覆盖首页、列表和详情等典型界面。
• 同一产物的预览保持内容和画幅一致，让用户比较的是风格，而不是被不同题材干扰。

第三步：将预览图绑定到可执行规则

每个风格条目包含：

• id：稳定机器标识。
• artifactType 与适用的子类型。
• title 与 description：面向用户的简短文案。
• preview 与 alt：精选预览素材。
• styleSpec：颜色策略、字体角色、版式密度、圆角、图像语言、组件和动效规则。
• promptGuidance：Agent 如何把该方向落实到对应产物。

用户选择后保存 style_id + version，系统将对应的 styleSpec 注入 Agent 上下文。图片只负责帮助用户判断，真正约束生成结果的是结构化规则。

第四步：运行时筛选

1. 根据 Home 入口、用户描述和项目创建信息确定产物及子类型。
2. 从对应目录筛选 3–5 个最匹配方向，并给出一个 Agent 推荐项。
3. 用户选择后进入生成；选择“帮我决定”时使用推荐项。
4. 已有 Design System 时优先遵守其品牌 token，只使用兼容的结构/版式方向；已有参考图时不再展示通用目录。

第一版使用内置精选素材，不在用户等待期间临时生成风格图。

3.4 建立云端视觉风格目录服务

长期需要建设的不是一个单纯的图片库，而是一套可运营的“视觉风格目录服务”。图片只是其中的预览素材，目录还需要保证用户选择能够稳定映射到 Agent 可执行的设计规则。

服务由以下部分组成：

• 对象存储与 CDN：保存 Deck 多页拼图、Prototype 多屏拼图等预览素材，并提供稳定、可缓存的访问地址。
• 风格元数据目录：维护 style ID、适用产物、分类标签、标题、说明、预览图、design tokens 和 prompt guidance。
• 查询 API：客户端可以根据 artifactType、artifactSubtype、locale 和版本获取对应的可用风格。
• 运营管理能力：支持上传或替换预览图、编辑文案、调整排序、灰度发布以及上下线风格。
• 版本管理：每次用户选择都记录 style ID 和目录版本，保证历史项目可以还原当时的视觉方向；更新目录不能静默改变已有项目。
• 客户端缓存与降级：网络不可用或服务异常时，使用最近一次缓存或应用内置的基础目录，不阻断 Studio 主流程。
• 效果数据：记录风格曝光、选择、改选和生成后再次修改方向等信号，用于判断目录质量，而不是只统计图片点击率。

云端返回的数据必须经过固定 schema 校验。客户端不直接执行目录中的任意代码，也不允许未经审核的外部图片地址或 prompt 内容进入生成流程。

建设节奏分为两步：

1. 第一阶段在代码仓库内维护 Deck、Prototype 的静态目录和内置预览图，先验证视觉选择是否提高决策效率、降低生成后改风格的比例。
2. 指标验证有效后，再迁移到云端目录、CDN 和管理后台，使产品与设计团队可以在不发版的情况下更新风格内容。

3.5 将视觉问题完整迁入 Chat

扩展现有 <question-form>，增加通用 visual-cards 类型，同时兼容历史 direction-cards。

交互规则：

• Agent 最新提出的问题直接展示在 Chat 中，用户可以原地操作。
• 支持单选、多选、其他输入、键盘操作和图片加载失败状态。
• 流式接收表单时先展示稳定骨架，避免问题逐个出现造成长时间等待。
• 回答后原位折叠为“Brief 已确认”摘要。
• 历史表单保持只读，可查看当时的选择。
• 不再依赖右侧 Questions Tab 完成主流程。

3.6 回答提交后，清晰展示用户的选择

当前回答会以 [form answers — ...] 的技术文本显示在 Chat。方案仍在底层保留这些稳定机器值供 Agent 使用，但用户看到的是一段容易检查的需求摘要，明确说明最终选择和系统采用的默认值。

示例：

已确认：SaaS Dashboard · Desktop · High fidelity · Editorial utility 关键页面：Overview、Orders、Order detail 使用现有 Design System

默认参数也显示在摘要中，并提供后续修改入口，但不阻断第一次生成。

3.7 补齐 Home 到 Studio 的上下文传递

需要统一传递并持久化：

• artifactType
• artifactSubtype
• 示例或模板 ID
• 用户明确修改过的 plugin inputs
• Design System
• 创建参数和附件

Home 二级分类不能只用于过滤示例，应作为真实任务上下文进入 Studio。

提交时可以省略用户从未操作过、且已有产品默认值的字段；用户明确选择过的值不得为了让 Agent 再问而删除。

3.8 数据验证与埋点

数据验证需要与功能方案一起评审，并在视觉提问上线前或同版本补齐。否则只能看到“用户有没有点击图片”，无法判断是否减少重复提问、缩短产出时间或降低风格返工。

已有数据

目前已经可以统计：首轮是否提问、不同表单的曝光和提交/跳过、平均回答题数、主动或倒计时 Skip，以及回答后下一轮是否产出 artifact。这些数据足以提供当前基线，后续重点是补齐完整漏斗和视觉选择效果。

需要补充的数据

第一阶段上线前需要补齐：

• 表单链路串联：现有表单事件只有 project_id，需要补充 conversation_id、关联的 run_id 和唯一 form_instance_id，才能把同一张表单的曝光、回答和后续产出可靠串联。
• 入口信息：普通首轮 run 的 entry_from 经常为空，需要补充 Home 分类、模板、自由输入、New Project 等入口来源。
• 表单耗时与逐题行为：补充曝光到首次操作、曝光到提交的耗时，以及 question_id、题型、操作顺序和退出位置；当前只能看到最终回答/跳过数量，不知道用户卡在哪一题。
• 提问策略判断：记录 Agent 当时已知的字段、实际询问的字段及信息来源，用于判断是否发生重复提问。
• 视觉卡片行为：补充 artifact_type、style_id、style_catalog_version、推荐是否被接受、改选次数和选择耗时；当前 direction-cards 没有选择埋点。
• 生成后的视觉质量：记录生成后 1–2 轮内是否修改风格或重新生成，验证图片选择是否真正降低风格返工。
• 运行模式完整性：当前 daemon run 链路已有数据，BYOK 路径仍需补齐相同的 run 事件和字段，避免漏斗只覆盖部分用户。

指标使用

• 主指标：提问后第 2 轮产物率、首次产物耗时；“可用产物”还需要结合生成后是否立即返工定义。
• 体验指标：有效提交率、平均问题数、提交耗时、主动 Skip 和逐题流失。
• 质量指标：生成后风格改选率、重新生成率、Agent 推荐风格接受率。
• 护栏指标：run 成功率、artifact 失败率和总体生成时长。

discovery 提交率和首轮提问率仅作为诊断指标，不单独作为优化目标。正式实现埋点前需对照现行埋点规范复用已有事件和参数，新增字段同步进入 analytics contracts 与埋点文档。

3.9 分阶段交付

第一阶段聚焦最核心链路：

1. 先补齐基线漏斗、串联 ID、表单耗时与逐题行为，确保上线前后可以对比。
2. Home 上下文完整传递与去重提问。
3. Deck 与 Prototype 两套视觉风格目录。
4. Question Form 完整内联到 Chat。
5. 自然语言 brief 摘要与历史恢复。

第二阶段扩展：

1. Document、Image、Video、Audio、Live Artifact 风格目录。
2. Studio 空状态与生成后快捷操作。
3. 将静态风格目录迁移到云端目录服务、CDN 和管理后台。
4. 建立风格曝光、选择、改选和生成后返工的数据闭环。

3.10 验收标准

• 从 Home 的 Deck 分类进入 Studio，不再询问产物类型。
• 从 Prototype、Wireframe、Mobile 进入时，不重复询问已锁定的平台或保真度。
• 选择具体示例或模板后，可以 0 问题直接开始。
• Active Design System 或参考图存在时，不再展示通用风格选择。
• Home 自由输入可以在高置信度时自动判断产物，只有低置信度才询问类型。
• 用户可以完全在 Chat 内完成视觉选择与提交。
• 提交后显示人类可读的 brief 摘要，刷新和切换会话后仍能恢复。
• 已有项目的局部修改不会重新触发 discovery。
• Deck 与 Prototype 展示不同的风格目录和不同形态的预览图。