定义开发者试用路径
把“下载模型、运行模型、选择能力、输入样本、查看输出、判断是否接入”梳理成稳定工作流。
Nexa Studio：让开发者在手机上高效验证端侧 AI 模型
PROJECT POSITIONING
项目定位
Nexa Studio 是一款面向开发者的移动端 App，用来在真实手机设备上下载、运行、切换和试用端侧 AI 模型。它服务的不是普通聊天用户，而是需要快速判断模型能力、性能和接入价值的开发者。
这个项目的 UX 难点在于：端侧模型有下载、运行、加载、推理、失败等技术状态，也有 LLM、ASR、Embedding Search、多模态输入等不同能力。设计不能只做“好看的聊天界面”，而要把复杂模型能力转译成开发者能快速理解、快速测试、快速判断的移动端工作流。
MY UX WORK
我承担的 UX 工作
搭建模型信息架构
把模型管理、能力测试、结果反馈、历史记录和多端状态组织成可扩展的移动端结构。
设计多模态测试容器
统一文字、语音、相机、图片、文件和模型切换，让不同模型能力在同一套测试逻辑下被验证。
建立状态与 QA 规范
定义模型生命周期、AI Ball 反馈、暗色模式和设计走查，让方案能被准确实现。
UX Foundation / Problem Framing
问题定义：开发者真正需要验证的不是“能不能聊天”
端侧 AI 模型体验工具的核心问题，不是给开发者一个聊天框，而是帮助他们回答一组判断题：这个模型能不能在我的设备上跑起来？支持什么输入？输出质量如何？速度和稳定性是否可接受？是否值得进一步接入我的产品？
用最短路径判断模型是否可用
开发者不想在移动端反复找入口，他们需要快速进入模型、输入测试样本、看到结果并形成判断。
把端侧模型能力可视化
端侧 AI 的价值很抽象，设计需要把下载、运行、推理、多模态输入和结果质量变成可感知的体验。
技术状态不清会阻断试用
如果开发者不知道模型是否下载、是否运行、是否加载失败，就会把技术等待误解为产品不可用。
手机端承载开发者工具
小屏幕既要放输入、输出、模型切换和媒体预览，又要保留开发者关心的状态信息和结果反馈。
我设定的 UX 成功标准
- 路径短：开发者从打开 App 到开始试用模型，不需要理解复杂导航。
- 状态清楚：模型是否下载、运行、加载、生成、失败，都有可见反馈。
- 能力可测：不同模型能力有明确测试入口、输入方式和输出展示。
- 结果可判断：开发者能基于输出、上下文和运行状态判断模型是否值得进一步接入。
UX Foundation / Developer Journey
开发者旅程：从发现模型到判断接入价值
我没有把 Nexa Studio 当成普通 App 设计，而是按开发者评估模型的决策过程拆解旅程。每一步都要回答“现在能不能测、该怎么测、测出来怎么看”。
阶段
用户行为
浏览模型列表，查看模型能力、大小和状态。
下载模型，等待资源准备，点击 Run Model。
进入 LLM、ASR、Embedding 或多模态模式。
输入 prompt，上传图片/音频/文件，切换模型。
阅读回复，展开统计，查看媒体上下文。
对比结果，判断是否值得集成到产品。
关键触点
Model Page / Download CTA / Capability Tag
Run Model / Loading / Ready State
Mode Switch / New Chat / Model Dropdown
Input Bar / Media Picker / Preview
Output Container / Show More / AI Ball
History / Context / Design QA
痛点风险
模型信息过技术化，不知道该试哪个。
下载、加载、运行状态混淆，误以为产品卡住。
能力入口分散，不知道这个模型该怎么测。
素材是否进入模型上下文不够确定。
长输出和元信息混在一起，小屏可读性下降。
结果难以复盘，无法支撑接入判断。
设计回应
用模型卡承载能力类型、状态和主操作。
拆分生命周期状态，让主按钮始终指向下一步。
按能力自动进入对应工作区，降低模式选择成本。
提供媒体预览、播放、放大和上下文反馈。
区分输入、输出、统计和补充信息层级。
保留历史测试、上下文和 QA 规则，便于继续评估。
UX Foundation / IA & Capability Taxonomy
信息架构：把模型管理和能力测试拆开
Nexa Studio 的信息架构不是按页面堆功能，而是围绕开发者试用模型的过程组织：先管理模型，再进入对应能力的测试工作区，最后通过状态和结果帮助判断。
Nexa Studio App
Model Management
Model Library
Model Detail
Download / Run State
Capability Tags
Testing Workspace
Model Context Header
Input Container
Output Container
History / New Chat
Capability Modes
LLM Chat
ASR
Embedding Search
Omni Multimodal
System Layer
AI Ball State
Error Recovery
Dark Mode
Design QA
横向规则层
模型生命周期
输入格式规则
状态反馈规范
跨端一致性
LLM Chat
核心是长文本输入输出、上下文连续性、模型切换和回复可读性。
ASR
核心是录音、播放、识别结果、失败重试和语音输入反馈。
Embedding Search
核心是上传/输入样本、触发检索、展示相似结果和判断搜索质量。
Omni Multimodal
核心是图片、相机、文件与文本共存，并让开发者确认素材已进入模型上下文。
UX Artifact 01 / Model Lifecycle
模型生命周期：把技术状态翻译成用户可理解的操作
对开发者来说，“模型不可用”背后可能是未下载、下载中、加载中、运行失败或设备不支持。我的设计重点是把这些技术状态拆开，让主操作按钮和界面反馈始终告诉用户下一步能做什么。
未下载
下载中
已下载
加载中
可试用
生成中
完成
失败恢复
状态
触发条件
界面反馈
用户动作
Not Downloaded
模型在列表中可见，但本机尚未准备资源
展示模型能力、大小、下载入口和不可运行状态
下载模型、查看详情、切换模型
Downloading
用户开始获取模型资源
进度反馈、下载中禁用运行入口、允许取消
取消下载、等待、返回模型页
Ready to Run
模型已下载但尚未进入运行状态
主按钮切换为 Run Model，提示可开始试用
运行模型、查看支持能力
Running
模型加载完成，测试容器可用
输入框、媒体入口、模型选择和 AI Ball 激活
输入样本、切换能力、New Chat
Generating
模型正在本地推理或处理输入
AI Ball 动效、生成中状态、必要时禁用重复提交
等待、停止、查看已有输出
Recoverable Error
资源不足、权限缺失、输入格式错误或运行失败
说明失败原因，并给出重试、换模型或修改输入
重试、换模型、清空输入
UX Artifact 02 / Testing Workspace
测试工作区：统一不同模型能力的输入与输出
如果每种模型能力都单独做一套界面，产品很快会失控。所以我把试用区设计成可扩展容器：顶部承接模型与模式，主体承接输入/输出，底部承接文本、媒体和运行操作。
模型上下文
- 当前模型
- 能力类型
- 运行状态
- 切换入口
输入容器
- 文本输入
- 语音录入
- 图片上传
- 相机拍摄
素材确认
- 图片预览
- 音频播放
- 文件状态
- 多图上下文
推理反馈
- AI Ball
- 生成状态
- 等待反馈
- 错误提示
结果判断
- 模型输出
- 上下文记录
- Show more
- 继续测试
关键控制点
Run Model
New Chat
Switch Model
Upload Media
Show More
DESIGN SOLUTION
设计解法：从工具复杂度到开发者效率
1. 用“模型管理 + 试用工作区”建立主路径
- 模型管理负责下载、选择、运行模型；试用工作区负责输入、生成、结果查看与历史记录。
- Welcome、No Model Selected、Models downloaded 等空状态让开发者知道为什么当前不能测试，以及下一步该做什么。
2. 建立可扩展能力框架，而不是为每个模型单独造页面
- LLM、ASR、Embedding Search 等能力被纳入同一套试用逻辑，降低后续新增模型类型的设计成本。
- 开发者从模型页进入能力页后，系统自动切到对应测试模式，减少“这个模型应该在哪里试”的疑问。
3. 用统一容器承载多模态输入
- 测试容器同时支持文字输入、长文回复、模型下拉、统计信息、上下文操作和键盘输入。
- 媒体入口覆盖音频、相机和图片上传，并提供播放、预览、放大查看、多图对话等反馈，让开发者知道素材已经进入模型上下文。
4. 用 AI Ball 承载端侧运行状态反馈
- AI Ball 被设计成可复用状态组件，覆盖默认、语音输入、思考、动效关键帧等状态。
- 它让端侧 AI 的“正在录入、正在处理、可继续操作”变成可感知的微交互，而不是只有静态按钮。
5. 用暗色主题和设计走查完成落地闭环
- 暗色版本复用同一套 ASR、Model Page、Embedding Search 结构，验证了框架在不同主题下的延展性。
- 设计走查用 Present / Design 对照表记录实现偏差，把样式、交互、文案和状态问题转化为开发可修复的任务。
UX Artifact 03 / High Fidelity Interface Analysis
高保真界面分析：不是把功能画出来，而是把开发者试用模型的判断过程画清楚
Nexa Studio 的高保真设计重点不是“聊天页好不好看”，而是让开发者在手机上完成一套连续判断：模型是否可用、当前在测什么能力、输入是否进入上下文、输出是否可信、下一步该切模型还是继续追问。
把开发者行为拆成模型准备、能力选择、输入、运行、查看结果、切换模型。
顶部承接模型上下文，中部承接输入与输出，底部承接运行和媒体入口。
下载、加载、推理、失败、等待和录入都需要明确反馈，避免端侧运行像卡死。
高保真不是终点，最后还要把主题适配和实现偏差转成可修复问题。
01 / Core Workspace Anatomy
主工作区为什么采用“模型上下文 + 对话输出 + 底部输入”的稳定结构？
开发者不是来“聊天”的，而是在验证某个端侧模型能否完成任务。所以界面第一优先级是持续暴露模型上下文，同时让输入、输出、状态和切换路径保持稳定，降低反复测试时的认知成本。
- 模型上下文固定在顶部让用户始终知道当前测试的是哪个模型、什么模式，避免多模型切换后误判结果。
- 输出区服务长内容阅读长回复、统计信息和二级操作被收纳，保证小屏仍能比较模型结果。
- 输入区固定在底部测试动作始终可达，同时兼容键盘、媒体上传和再次追问。
1
2
3
4
5
未进入模型时用 Welcome / No Model Selected 说明原因和下一步。
Loading 与 Thinking 分开，避免用户把模型推理误以为页面卡顿。
下拉切换与结果区保留在同一工作区，支持横向比较。
Audio、Camera、Photos 统一从输入区展开，符合“补充上下文”的心智。
图片可预览、放大、继续对话，让输出进入下一轮测试。
02 / A/B Thinking
Before
每个能力单独生长
After
统一容器承载能力差异
从“按能力堆页面”到“统一能力框架”：为什么这是更好的扩展方式？
早期如果把 LLM、ASR、Embedding Search 分别做成独立页面，短期看起来直观，但每新增一种端侧模型能力都要重新定义入口、状态、输入和输出。最终方案把差异放在能力参数里，把稳定结构沉淀为同一套测试容器。
LLM Page
ASR Page
Embedding Page
入口、状态、输入规则分散，后续新增能力会不断增加学习成本。
Model Context
Input Container
Output Container
开发者理解一次结构，就能迁移到语音、搜索、多模态等不同能力。
1
2
3
4
先确认模型已准备，再进入能力测试，减少“在哪里开始”的疑问。
录音、停止、转写仍进入同一输出容器，不重造阅读和历史逻辑。
文件导入、数据库为空、索引设置被当作能力参数，而不是新产品。
空库、设置、确认弹窗都复用统一状态反馈，降低实现分裂。
03 / Multimodal Detail
多模态界面怎么保证用户知道“素材已经被模型接收”？
多模态测试最容易出问题的地方不是上传入口，而是用户无法判断素材是否真的进入模型上下文。因此我把媒体入口、素材预览、发送后状态、结果引用和放大查看串成闭环。
- 入口收敛Audio、Camera、Photos 统一从输入区展开，符合“给当前模型补充材料”的动作语义。
- 素材可见上传后以缩略图和气泡进入对话流，让用户确认上下文已经被记录。
- 结果可验证图片可放大查看，多图可并列进入对话，方便开发者判断模型是否真的理解内容。
1
2
3
4
5
6
用户输入不离开当前模型页，减少“新建任务”的割裂感。
Copy、Try Text、Regenerate 放到长按菜单，避免主界面过载。
模型列表从顶部展开，让用户知道正在换的是模型而不是任务。
上传不是独立模块，而是当前提问的上下文补充。
拍摄和确认分开，防止误把临时画面发送给模型。
开发者能检查细节，而不是只能看到聊天流里的小缩略图。
04 / AI State System
Default可输入
Listening接收中
Thinking推理中
Error需恢复
AI Ball 为什么不是装饰？它解决的是端侧 AI 的等待与可信反馈
端侧模型运行时，用户经常面对几秒到几十秒的等待。AI Ball 被定义成状态组件，而不是视觉点缀：它用形态、层级和动效关键帧表达“可输入、正在听、正在思考、已完成或失败”。
低强度发光，提示工具可被唤起。
增强动效，反馈语音或媒体输入正在进入系统。
循环旋转与渐变变化，让等待变成可感知处理。
状态弱化并配合文案，引导用户重新运行或检查模型。
1
2
3
4
以静态底层、微弱内核和动态渐变分层，让用户先知道工具可被唤起，再判断它是否正在处理任务。
两个 Gradient 层按 0°、90°、180°、270° 的不同节奏转动，形成持续推理感，而不是一个含义模糊的 loading 图标。
当组件进入更小的界面容器时，保留核心形态与动效层级，避免小尺寸下只剩一颗无法解释的发光圆点。
关键帧在 360° 回归初始状态，使循环连续无跳变；用户能稳定感知模型仍在本地运行，并保有继续等待或改用其他操作的判断依据。
UX Foundation / Error & QA
异常与 QA：开发者工具必须把“不稳定”设计进去
端侧 AI 模型试用会遇到资源不足、模型加载失败、权限缺失、输入格式不支持、暗色模式偏差和跨端实现偏差。我的工作不是只交付理想页面，而是把这些不稳定因素变成可检查、可恢复、可交付的设计规则。
让主按钮告诉用户下一步
未下载时显示 Download，已下载时显示 Run Model，运行后进入测试工作区，避免状态和操作割裂。
提前限制并给出原因
媒体入口需要展示可上传类型、失败原因和替代路径，减少开发者以为模型本身不可用。
把等待转换成状态反馈
用 AI Ball 和生成态告诉用户模型正在本地处理，而不是让界面看起来卡死。
区分主要输出和补充信息
长回复、统计信息和上下文记录通过展开入口组织，避免小屏输出区失控。
验证同一框架在暗色主题下仍成立
暗色版不是简单换色，而是检查层级、状态、输入容器和结果区的可读性。
用 QA 表把问题转成任务
设计走查通过 Present / Design 对照，把界面偏差、间距、状态和文案问题具体标出。
UX Foundation / Validation & Handoff
验证与交付：我如何证明这是可落地的开发者工具设计
Nexa Studio 的设计价值，不只是界面看起来完整，而是它能不能让开发者更快完成模型评估，并让研发团队按一致规则实现多端体验。
原型验证问题
- 开发者能否快速判断当前模型是否可运行？
- 开发者能否理解不同模型能力应该在哪里测试？
- 媒体输入后，开发者是否知道素材已经进入模型上下文？
- 生成失败时，开发者是否知道下一步该怎么恢复？
可用性检查维度
- 任务效率：从选择模型到开始测试的步骤是否足够短。
- 状态透明：下载、运行、生成、失败是否都有反馈。
- 信息层级：输入、输出、统计和历史是否不会互相干扰。
- 跨端一致：不同端与暗色主题是否遵循同一套规则。
交付给团队的设计规则
- 模型生命周期状态：未下载、下载中、可运行、运行中、生成中、失败。
- 测试工作区结构：模型上下文、输入容器、素材确认、推理反馈、结果判断。
- 多模态输入规范：文本、音频、图片、相机、文件的入口和反馈方式。
- Design QA 对照：Present / Design 差异记录和修复优先级。
CORE DESIGN OUTPUT
核心设计产出
- 从模型能力到开发者任务：把端侧 AI 的技术能力翻译成开发者可以快速完成的试用流程。
- 从功能页面到可扩展框架：建立模型管理、能力模式、测试工作区和状态反馈，支撑后续更多模型类型。
- 从多模态复杂度到统一容器：把文本、音频、相机、图片上传和模型切换组织进稳定的小屏工作流。
- 从视觉稿到交付闭环：通过暗色主题和设计走查，推动方案在多端准确落地。