江湖小栈

Do Better

0%

大模型能力跃迁后：前端如何重新设计 AI 交互体验

发表于 分类于 Hot°C：
本文字数： 2.8k 阅读时长 ≈ 3 分钟
从大模型的基本原理出发，讨论模型能力变化后前端交互、状态管理和用户体验应该如何重新设计。

大模型真正改变的，不只是“能不能生成一段文字”，而是软件开始能够理解上下文、持续协作，并参与完成一项任务。前端也因此从展示结果，走向设计人与模型共同工作的过程。

大模型到底是什么

  大模型可以理解为一种在海量数据上训练出来的通用概率模型。它并不是把答案存进数据库，收到问题后再查出来，而是根据已经看到的上下文，预测接下来最可能出现的 Token。Token 可以是一个字、半个词，也可以是一段符号；模型通过大量参数把词语、代码、图片和上下文之间的关系编码下来。

  “大”通常体现在参数量、训练数据量和计算量上，但模型有用并不只因为参数多。预训练让模型获得通用语言能力，指令微调让它更愿意按照要求回答，人类反馈或偏好优化让回答更符合使用习惯，工具调用和检索增强则让它能够接触外部世界。

Transformer 的基本原理

1. 从文本到 Token

用户输入首先会被切分成 Token，再转换成向量。模型处理的不是汉字或英文单词本身，而是一串带有位置和语义信息的数字：

1
2
3
4
5
“请生成一个登录页”
        ↓ tokenizer
[请, 生成, 一个, 登录, 页]
        ↓ embedding + position
[向量1, 向量2, 向量3, 向量4, 向量5]

2. 注意力机制

Transformer 的核心是 Self-Attention。它会让每个 Token 计算自己应该关注上下文中的哪些 Token。例如“它”在一段话中究竟指用户、页面还是接口，需要结合前后文判断。

简化后的注意力公式是：

1
Attention(Q, K, V) = softmax(QKᵀ / √dₖ) V

其中 Q 表示当前查询，K 表示上下文索引，V 表示要聚合的信息。多头注意力让模型可以同时关注语法、指代、代码结构和更长距离的关系。

3. 预测与生成

模型会根据上下文计算下一个 Token 的概率分布，再按照采样策略选出结果。Temperature、Top-P 等参数影响结果的稳定性和创造性。前端不应该把这些参数简单暴露给所有用户，而应根据“代码生成、摘要、创意写作、结构化输出”等任务提供合适的预设。

为什么 2025 年前后的体验发生变化

模型从“回答问题”走向了更长上下文、视觉理解、工具使用和多步骤任务。用户不再满足于点击按钮后等待一段最终文本，而希望看到过程、能够中断、修改目标、补充上下文，并在结果出现后继续操作。

前端交互因此需要从一次请求升级为一个可恢复的任务状态机：

1
2
3
4
5
6
type AiTaskState =
  | { status: "idle" }
  | { status: "running"; taskId: string; text: string }
  | { status: "needs-confirmation"; taskId: string; action: string }
  | { status: "completed"; taskId: string; result: unknown }
  | { status: "failed"; taskId: string; error: string };

前端交互的五个变化

流式响应不是打字动画

流式输出应该具有真实的增量状态、取消能力和错误恢复，而不是把完整答案切成几段再播放：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
const controller = new AbortController();

async function startChat(prompt: string, onToken: (token: string) => void) {
  const response = await fetch("/api/ai/chat", {
    method: "POST",
    body: JSON.stringify({ prompt }),
    signal: controller.signal,
  });
  if (!response.body) throw new Error("当前服务不支持流式响应");

  const reader = response.body.getReader();
  const decoder = new TextDecoder();
  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    onToken(decoder.decode(value, { stream: true }));
  }
}

// 用户可以随时中断正在运行的任务
function cancelChat() {
  controller.abort();
}

上下文应该可见、可编辑

系统提示词、历史消息、检索资料和当前页面信息都会影响结果。界面应告诉用户“模型看到了什么”，允许删除过期上下文，避免用户把错误归因于模型的随机性。

工具调用必须有确认边界

读取天气和删除数据不是同一种操作。调用外部工具时，前端至少要展示工具名称、参数、执行状态和可撤销性：

1
2
3
4
5
const toolCall = {
  name: "create_ticket",
  arguments: { title: "登录页异常", priority: "high" },
  requiresConfirmation: true,
};

结果要结构化

表格、代码补丁、引用来源和待办事项不应全部塞进 Markdown。前后端可以约定 JSON Schema，让前端根据类型渲染不同组件，并保留复制、重试、回滚和反馈入口。

失败是正常状态

超时、限流、内容过滤、工具失败和网络中断都必须有明确的状态。AI 页面不能只准备一个 Loading 和一个 Error，而要支持重试、继续、缩小上下文和转人工。

从聊天框到 AI 工作台

好的 AI 前端不只是一个输入框，而是一套工作台：左侧是上下文和任务历史，中间是模型过程与结果，右侧是引用、工具调用和人工确认。对于企业系统，还要接入权限、审计、脱敏、租户隔离和成本统计。

这也是前端基础设施有价值的地方：统一的 Message、Modal、Drawer、路由、事件、权限和错误兜底，可以让 AI 功能遵循团队已有的用户体验，而不是每个业务页面重新发明一套交互。

小结

大模型让软件从“响应点击”走向“协作完成任务”。前端需要管理的也从组件状态扩展为上下文、流式过程、工具确认、结构化结果和可恢复错误。理解模型原理，不是为了让每位前端都去训练模型，而是为了设计出符合模型特性、也尊重用户判断的产品体验。

相关推荐
bulb