AI 类应用的交互形态差异大：对话式、表单式与创作流各有各的节奏，不能套同一个页面结构
项目概览
项目背景
这是一套 AI 应用的前端套件，共 3 个仓库，覆盖 2024 至 2026 年，全部为 Vue 技术栈，包括 Web 端、uni-app 跨端应用与 AI 创作类应用。三类应用对应三种交互形态：对话式、表单式与创作流。
客户当时的状态
AI 应用最容易停在「演示能跑」的阶段。演示时网络顺畅、输入规范、一次成功；上线后流式输出中途断掉、请求超时、用户等不及直接关页面，这些都是每天都发生的事。另一处差别在交互形态：对话式强调连续多轮与自由输入，表单式强调字段完整与结果可校验，创作类应用则要按步骤组织流程。把三种场景套进同一个页面结构，每种用法都会别扭。用户在这类应用里的等待时间也明显更长，等待期间没有反馈，可用性就崩了。这里的时间感也很不一样：普通页面加载慢一点可以忍，模型输出要几十秒，中间没有反馈，用户只会认为它卡住了。
我们的做法与取舍
第一个取舍是按场景区分交互形态，而不是做一套通用界面。代价是三套实现要分别维护，收益是每种场景的用户体验都成立。
第二个取舍是把异常处理当主功能做：流式分片渲染、超时重试、用户取消，全部在第一期落地。这些功能不写也能演示，但上线之后天天都要用。
第三个取舍是补齐结果留存与历史查看。AI 输出如果关掉页面就没了，用户就不会把它当工具用。留存看起来是附加功能，实际是产品与演示的分界线。
系统怎么承载这条链路
交互层按对话式、表单式与创作流区分形态；能力集成层负责模型调用、流式输出处理与超时重试；留存层保存输出结果并支持历史查看。跨端应用与 Web 端共用同一套调用与处理逻辑，只做展示差异。历史记录与结果留存同样由统一层承载，换一个形态打开时仍然可以继续查看。
交付状态与边界
代码处于维护状态，最近一次提交在 2026 年（具体月份未披露）。边界说明：模型能力与效果取决于贵方选定或提供的模型，我们负责前端与调用集成，不对模型效果做承诺；模型服务与算力资源以贵方或签约方案为准；生成内容的使用与合规审核由内容使用方承担，前端套件不承担审核责任。输出结果最终怎么使用由贵方决定，我们在前端只负责呈现与留存。三个仓库活跃度不一致，我们按实际情况说明。
项目信息
客户
某 AI 应用产品项目
项目周期
未披露
技术栈
Vue（Web 端、uni-app 跨端、AI 创作类应用）
服务类型
AI 应用前端套件
CHALLENGES
客户当时面对的现实
模型输出是流式的，中途中断、超时、返回不完整都要有处理方式
用户等待时间比普通页面长，等待期间的状态反馈直接影响可用性
把 AI 能力包成产品，需要补齐重试、取消与结果留存，这些在演示里往往都被省略
CAPABILITIES
我们交付的能力
Demo 和产品的差别，都在异常处理里
对话式交互
对话式应用的输入、流式输出与多轮上下文的前端处理。
表单式交互
表单式应用把 AI 能力放进固定字段结构，输出结果可预期、可校验。
创作流交互
创作类应用按步骤组织流程，过程可回溯、可中断、可继续。
流式与异常处理
流式输出的分片渲染、超时重试、中断取消，以及结果留存。
SCOPE
交付范围
以下范围按本项目实际交付内容与边界整理，不属于这次范围的部分一并列出。
已交付
- Web 端应用（Vue）
- uni-app 跨端应用
- AI 创作类应用前端
- 流式输出与重试机制的前端实现
不在本次范围
- 模型本身的能力与效果：模型由贵方选定或提供，我们负责前端与调用集成
- 模型服务与算力资源：以贵方或签约的服务方案为准
- 生成内容的合规审核责任：需按相应管理要求由内容使用方承担
ARCHITECTURE
分层技术架构
公开口径归纳为三层：交互层按对话式、表单式与创作流区分形态；能力层负责模型调用与流式输出的前端处理；留存层负责结果保存与历史查看。
FLOW 01
交互层
对话式界面
表单式界面
创作流界面
按场景选择合适的人机交互节奏
FLOW 02
能力集成层
模型调用集成
流式输出处理
超时重试与取消
把模型能力包成稳定可用的前端能力
FLOW 03
留存层
结果保存
历史查看
让输出结果可回看、可继续
DELIVERY
交付过程
分阶段推进，每个阶段都有可验收的产出，客户在早期就能看到实际效果。
阶段一
形态与场景确认
判断每个应用适合对话式、表单式还是创作流形态。
阶段二
交互与调用集成
前端交互落地，完成模型调用集成与参数组织。
阶段三
流式与异常处理
流式输出渲染、超时重试与取消机制实现。
阶段四
跨端与结果留存
跨端形态适配，补齐结果留存与历史查看。
FACTS
可核验的交付事实
以下内容来自本项目实际交付物；未经验证的指标不予展示。
3个仓库
全部为 Vue 技术栈
3类应用形态
Web 端 / 跨端 / AI 创作类
2024–2026年
仓库覆盖的年份跨度
TRANSFER
这套做法适不适合你
案例的用处不是证明"我们做过"，而是让你判断"在我们这种条件下能不能做成"。下面三句是我们对这一单的判断，写下来供你对照自己的情况。
适合什么情况
适合要把模型能力做成面向用户的产品、而非演示页面的场景。
什么情况下别照搬
若只是内部验证、使用者能接受失败率，不必投入完整的异常与留存机制；模型选型与算力不在开发范围内。
如果要试，第一步做什么
先确认场景适合哪种交互形态，再定流式与重试策略。
RELATED SERVICES
相关服务
从实际业务问题出发，查看对应服务的适用场景、交付物与不含项；具体范围仍需单独确认。
FAQ
常见问题
以下是同类项目沟通中出现频率最高的问题，答案就是我们实际的做法。
AI 应用前端最难的是什么？
不是把对话界面画出来，是异常。流式输出到一半断了、请求超时、用户中途取消——演示里这些都不出现，产品里这些每天都在发生。
为什么对话式和表单式不能共用一套界面？
因为节奏不同。对话式强调连续多轮、输入自由；表单式强调字段完整、结果可校验。硬套一套结构，两种用法都会别扭。
流式输出的前端要处理什么？
分片拼接与渲染、超时重试、用户取消，以及输出完之后的留存。这些都属于「不写也能演示、但上线就出问题」的部分。
现在还在维护吗？
代码处于维护状态，最近一次提交在 2026 年（具体月份未披露）。这三个仓库都是 Vue 技术栈，活跃度按实际情况说明。
做 AI 应用第一步做什么？
先确认这个场景适合哪种交互形态，再定异常处理策略。形态选错，后面的重试和留存都要重做。
本页最后更新：2026年9月24日
