想象你走进一家高级餐厅，点了一道“主厨现场料理”。你没有坐在大厅干等，而是被安排在开放式厨房的吧台前。你能看到大厨起锅烧油、食材依次下锅、香气一点点飘出来，他甚至会提前告诉你：“这块牛排还要煎两分钟，三分熟会更嫩。”等菜真正端到面前时，你不仅吃到了菜，更参与了它诞生的全过程——这就是流式输出的魅力。 传统软件的输出方式是“端菜”：你提交请求，系统闷头忙活，忙完了才把成品一次性端上来。而 AIGC 产品天生不同——模型生成一段文字、一段代码、一张图，需要几秒甚至几十秒。如果让用户盯着加载圈干等，焦虑会持续累积；如果把生成过程“直播”给用户，等待就变成了参与。这就是流式输出体验设计要解决的问题：如何让用户看着一道菜从无到有，既不焦虑，又有掌控感。 本文用“开放式厨房”这条主线贯穿始终，带你掌握流式输出的核心概念、三大设计模式、用户控制设计、不确定性传达、结果展示策略与反馈机制设计。你会理解：流式输出的本质不是技术炫技，而是把“等待”翻译成“参与”。

岗位关联

对 AI 产品设计师与体验从业者而言，流式输出是用户接触 AIGC 的第一道门：它决定了用户对 AI 的信任感与耐心值，是把“等待”变成“参与”的核心杠杆。

目录
  1. 可视化演示
  2. 流式输出概念
  3. 核心设计模式
  4. 用户控制设计
  5. 不确定性传达
  6. 结果展示策略
  7. 反馈机制设计
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示AIGC流式输出的打字机效果与阶段式进度提示设计，含首Token时间(TTFT)和生成速度体验指标。

本节配有交互动效（进入视口后自动加载，约 3KB）。

流式输出模式 Token逐个流式显示，模拟打字机效果 首Token时间(TTFT)影响用户感知响应速度 TTFT = t(first_token) - t(submit)

流式输出概念

在传统软件的世界里，用户和系统之间隔着一扇“后厨的门”：点击查询，系统在墙后默默忙活，期间只有一只转圈的加载图标，直到全部处理完毕，才把成品一次性端出来。如果这道“菜”30 秒就能上桌，你还能耐住性子；如果需要两三分钟，人就会开始怀疑：它是不是卡住了？会不会把我的需求忘了？

AIGC 产品面临的就是这种“慢菜”困境——主流大模型生成一段回答，往往需要数秒甚至数十秒。流式输出（Streaming Output）于是登场：模型每生成一个词元（token，即组成文本的最小单元），就立刻推送到前端展示。屏幕上的文字像打字机一样逐字生长，用户不再对着加载圈发呆，而是看着 AI 的回答一点一点成形。这就像后厨的墙被拆掉，客人能看到锅气升腾、听到油花作响。

衡量流式体验有两个关键指标：首 token 时间（TTFB）——从用户按下发送到第一个字符出现之间的耗时，它是用户感知中的“开锅信号”；平均生成速度——模型平均每秒能产出多少词元。二者共同决定了总耗时的构成。值得强调的是：流式并没有让总耗时变短，它的魔法在于把一段难熬的空白，拆成无数个微小的正反馈，让焦虑在持续刷新中被稀释。

所以，流式输出的第一课是认清本质——它不是性能优化，而是感知设计。后厨的门一旦打开，客人看到火候、闻到香气，哪怕菜熟的总时间一模一样，等待的体验也已经天差地别。这扇门，就是流式体验设计的起点。

T总=T首+Nvˉ\displaystyle T_{\text{总}} = T_{\text{首}} + \frac{N}{\bar{v}}
总生成时长 = 首 token 等待时间 + 剩余词元量 ÷ 平均生成速度。流式体验优化的重点在“首 token 时间”和中间过程的节奏，而不是压缩总时长。
  1. 总时长 T总从请求发出到完整回答渲染完毕的耗时。流式与非流式在这一项上数值几乎相同，但用户感受完全不同。
    T总\displaystyle T_{\text{总}}
  2. 首 token 时间 T首第一个字符上屏前的耗时，是用户感知中的“开锅信号”。它又可拆为请求传输、模型推理、前端渲染三段。
    T首=t请求+t推理+t渲染\displaystyle T_{\text{首}} = t_{\text{请求}} + t_{\text{推理}} + t_{\text{渲染}}
  3. 主体内容耗时剩余未生成的词元量除以平均速度，得到后半段“匀速上菜”的时长。这部分的体验由节奏设计决定。
    Nvˉ=T总−T首\displaystyle \frac{N}{\bar{v}} = T_{\text{总}} - T_{\text{首}}
  4. 设计启示流式体验的优化目标是尽量压缩 T首，并在主体阶段维持稳定、可预期的输出节奏。
    min⁡T首,节奏化Nvˉ\displaystyle \min T_{\text{首}},\quad \text{节奏化} \frac{N}{\bar{v}}

核心设计模式

开放式厨房不是拆了墙就万事大吉。真正讲究的大厨，节奏感是设计过的：猛火快炒时手起刀落，需要慢炖的菜，他会提前打招呼“这一步要等三分钟”，免得客人盯着锅干着急。流式输出同样需要“节奏设计”，否则只是一行文字以令人不安的速度在屏幕上跳动。

业界沉淀出三个核心设计模式。增量渲染（Incremental Rendering）：服务端把完整回答切成小块并按序推送，前端把新内容追加到已有文本之后，而不是每次重新渲染整个页面；占位提示（Placeholder）：在首个词元到达前，用“正在思考”“正在检索资料”等骨架提示占据空位，相当于大厨先报个时；渐进呈现（Progressive Disclosure）：先输出提纲或结论，再逐段补充细节，让用户头三秒就能抓住重点。

实现层面也有很多细节容易踩坑：增量渲染要使用固定容器，避免“整页重排”造成的闪烁；打字机光标的移动要平滑，太快会刷屏，太慢会被嫌弃；占位骨架的尺寸最好与真实内容接近，否则内容落地瞬间页面会“跳”一下。这些细节共同决定了“流动感”是否顺畅。

呈现量随时间的变化，大致符合一条“先快后慢”的曲线：早期快速出内容帮用户建立信心，后期放慢让用户来得及消化。大厨知道什么时候大火收汁、什么时候小火慢炖，好的流式设计，也是同样的火候艺术。

S(t)=Smax⁡(1−e−t/τ)\displaystyle S(t) = S_{\max}\left(1 - e^{-t/\tau}\right)
已呈现内容量随时间按指数规律增长：前期增速快、后期趋于饱和。这条曲线刻画了流式输出应有的“先快后稳”节奏。
  1. 最终内容量 Smax回答全部生成完毕时的总内容量，相当于一盘菜的完整份量。
    Smax⁡\displaystyle S_{\max}
  2. 时间常数 τ决定输出“提速”快慢的参数。τ 越小，前期输出越猛，像大厨开猛火快炒。
    τ\displaystyle \tau
  3. 指数项随着时间 t 增大，e 的负指数项迅速衰减，使 S(t) 先快速爬升、再逼近上限。
    e−t/τ\displaystyle e^{-t/\tau}
  4. 饱和趋势当 t 足够大时，S(t) 无限接近 Smax，意味着输出进入“稳火收尾”阶段。
    S(t)→Smax⁡ (t→∞)\displaystyle S(t) \to S_{\max} \ (t \to \infty)

用户控制设计

坐在开放式厨房吧台前的客人，绝不是只能干看的观众。他随时可以喊：“够了！不要香菜！”“这块肉再煎一分钟！”大厨会立刻回应。可很多 AIGC 产品里，用户面对一屏正在生长的文字，居然只有“等它写完”或“清空重来”两个选项——这是对用户极大的不信任。

用户控制设计的核心是三个“随时”：随时可打断、打断要利落、重来要无损。具体手段包括：停止生成（Stop）——用户发现方向不对，立即终止后续输出；重新生成（Regenerate）——让 AI 换一个思路重来，并提供多个候选结果切换；中途编辑（Inline Edit）——允许用户选中已生成的某一段直接修改，AI 只重写这一部分，而不是推翻整篇。

其中“停止生成”的工程实现最容易被低估：用户点下的瞬间，前端要立刻冻结已渲染内容、停止接收新词元，同时向后端发送中断信号，让模型停止推理并释放算力。如果只在前端断开连接，模型会在后台继续空转，既烧算力又让“半成品”无法恢复。重新生成时也切忌全盘推翻——用户辛苦修改过的几行字应当被保留，并作为上下文传给下一轮。

餐厅里最让人崩溃的场面，是客人已经喊停，厨师还在往锅里加料。把控制权真正交还给用户，用户才敢让 AI 参与更重要的任务——因为他们知道，任何时候都能把方向拉回来。这种安全感，是用户愿意深度使用 AI 的前提。

t停止=t请求+t中断+t冻结\displaystyle t_{\text{停止}} = t_{\text{请求}} + t_{\text{中断}} + t_{\text{冻结}}
用户从点击“停止”到画面真正停下，经历了三段延迟。总延迟越短，用户越觉得“AI 听话”。
  1. 请求传输耗时点击“停止”后，指令从前端传到后端需要的时间，通常很短但不可忽略。
    t请求\displaystyle t_{\text{请求}}
  2. 后端中断耗时模型收到信号后停止当前推理、释放显卡算力所需的时间。若后端未接中断接口，这一项会无限拉长。
    t中断\displaystyle t_{\text{中断}}
  3. 前端冻结耗时前端停止渲染新词元、光标归位需要的时间。冻结得快，用户才感觉“真停住了”。
    t冻结\displaystyle t_{\text{冻结}}
  4. 体验阈值三段延迟之和应控制在人的“即时反馈”感知范围内，超过则用户会反复点击或失去耐心。
    t停止<0.5 s\displaystyle t_{\text{停止}} < 0.5\ \text{s}

不确定性传达

老练的大厨从不吹嘘“我这道菜绝对完美”。鱼不够新鲜，他会提前打招呼：“今天的鱼一般，我打算用重一点的调味压一压。”这叫预期管理。AI 生成内容天然携带不确定性——它有概率一本正经地编造事实，业界称之为“幻觉”。如果产品从不提及这种可能，用户信任一旦崩塌便难以修复。

不确定性传达的手段主要有四类：进度可视化——在长生成任务里展示实时进度或“正在获取第 3 份参考资料”，让用户知道系统在推进而非死机；置信度表达——对模型把握较低的事实性内容，用“该信息可能存在误差，请核实”之类的弱化语气标注；风险预告——涉及数字、日期、合同等高风险语料时，直接建议用户二次确认；等待预期管理——明确告知“大约还需 10 秒”，比一句空洞的“请稍候”更能安抚情绪。

如何判断“此刻该不该提示”？信息论里有一把现成的尺子——信息熵。当模型在某个位置的候选词概率分布非常分散时，熵值高，意味着它自己也拿不准。产品可以在这些“高熵时刻”自动附上低置信度标记，而不是对所有内容一刀切地加免责声明。

客人若提前知道今天的鱼不够新鲜，吃到嘴里反而会给个公正的评价；AI 若能坦然说出“这里我可能不准”，用户对偶发的错误也会多一分宽容。诚实，是建立 AI 信任感成本最低的路径。

H=−∑i=1npilog⁡2pi\displaystyle H = -\sum_{i=1}^{n} p_i \log_2 p_i
信息熵衡量模型在某个输出位置上的“犹豫程度”：候选概率越分散，熵越高，置信度越低。高熵时刻正是需要风险提示的时刻。
  1. 候选概率 pi模型在当前位置认为第 i 个词元可能出现的概率。概率越均匀，说明它越拿不定主意。
    pi\displaystyle p_i
  2. 信息量对概率取以 2 为底的对数，概率越小，该候选出现带来的信息量越大。
    log⁡2pi\displaystyle \log_2 p_i
  3. 求和取负对所有候选的信息量按概率加权求和并取负，得到熵值 H。
    −∑i=1n\displaystyle -\sum_{i=1}^{n}
  4. UX 映射熵越高代表置信度越低，产品应在此处显示“低置信度”提示或引导用户核实。
    H↑⇒置信度↓\displaystyle H \uparrow \Rightarrow \text{置信度} \downarrow

结果展示策略

菜做完了，装盘同样见功力：主菜居中、酱汁拉花、配菜点缀，食客一眼就知道从哪里下筷。反观不少 AIGC 产品，生成结束就是一大段没有层次的文字堆在屏幕上——等于把食材乱七八糟地倒在盘子里端给客人。

结果展示策略的核心有四条：结构化组织——引导模型输出 Markdown 或 JSON 结构，前端渲染出标题层级、列表和表格，长文立刻变得可扫读；关键信息突出——把结论、数字、可执行动作提炼置顶，例如“该方案预计成本 3 万元”直接高亮在回答顶部；上下文锚定（Grounding）——涉及事实时附上参考来源，让用户能追根溯源；版本对比——在多次修改之间用 diff 视图标出增删内容，避免用户迷失在版本迷宫里。

衡量展示效率的直觉指标是信息密度：有效信息量除以输出总长度。结构化标题和关键信息高亮，本质上不是炫技，而是把“等用户自己找重点”变成“帮用户把重点端到面前”。同时，展示策略还包含“收尾”设计：生成结束时光标停稳、出现完成状态提示，并及时把编辑与反馈入口带到视线内，引导用户进入下一轮交互。

一盘赏心悦目的装盘，会让客人对厨师的用心多一分认可；一次结构清晰、重点突出的结果展示，也会让用户感叹“这个 AI 很懂我”。好的收尾，本身就是下一次对话的邀请函。

η=I有效L输出\displaystyle \eta = \frac{I_{\text{有效}}}{L_{\text{输出}}}
信息密度 = 有效信息量 ÷ 总输出长度。结构化组织与关键信息高亮，本质上是提高分子的策略。
  1. 有效信息量 I有效用户真正需要的关键结论、数字与可执行动作。分子越大，用户找重点越快。
    I有效\displaystyle I_{\text{有效}}
  2. 总输出长度 L输出模型生成的全部文字长度。啰嗦的铺垫与无效重复都会拉低体验。
    L输出\displaystyle L_{\text{输出}}
  3. 信息密度比值二者相除得到单位长度内的有效信息量，是衡量展示效率的直观指标。
    η=I有效L输出\displaystyle \eta = \frac{I_{\text{有效}}}{L_{\text{输出}}}
  4. 设计杠杆通过结构化提纲、醒目高亮、去冗余等手段提升 η，让用户体验“字字值钱”。
    η↑⇔结构化+高亮\displaystyle \eta \uparrow \Leftrightarrow \text{结构化} + \text{高亮}

反馈机制设计

想成为一家回头客不断的餐厅，光靠客人临走一句“还行”是不够的。真正用心的店会追问：“今天哪道菜不对味？盐多了还是火候老了？”AI 产品的能力进化同样依赖用户反馈，而反馈入口的设计，本身就属于流式体验的一部分。

设计要点有三：即时反馈入口——不要让用户等完整篇生成才评价，在生成过程中或刚结束时，对小段内容点赞/点踩，反馈颗粒度更细；操作确认与撤销——停止、重新生成这类操作带有破坏性，要提供轻量确认或撤销（Undo）兜底，防止误触造成不可逆损失；满意度收集——用星级、表情或“最不满意的一点”等结构化选项，把模糊的主观感受转成可入库的数据。

收集到的反馈要进入优化闭环：被点赞的风格要引导模型“多学”，被点踩的回答要作为负样本或调整提示词（Prompt）的依据。产品侧通常用移动平均来追踪体验分变化——让每次新反馈按权重小幅修正历史评分，比简单的算术平均更能反映“最近体验正在变好还是变差”。

大厨会根据客人的反馈微调调料比例，而当客人发现“我上次提的意见被采纳了”，他下次会更愿意开口。当用户意识到自己不是被服务者而是共同创作者，流式输出体验就到达了它的终极形态：一场用户与 AI 的合谋。

Rn+1=Rn+α (S−Rn)\displaystyle R_{n+1} = R_n + \alpha\,(S - R_n)
体验分滚动更新公式：新评分 S 与当前体验分 Rn 的差值，按学习率 α 部分并入。α 越大，近期反馈的影响越大。
  1. 单次满意度 S用户对某次生成的打分，来自点赞、点踩或星级评价。
    S\displaystyle S
  2. 当前体验分 Rn 与更新后 Rn+1产品对整体体验的滚动估计，每来一条反馈就修正一次。
    Rn, Rn+1\displaystyle R_n,\ R_{n+1}
  3. 学习率 α取值在 0 到 1 之间，控制新反馈的权重。α 接近 1 时反应激进，接近 0 时趋于保守。
    α∈(0,1]\displaystyle \alpha \in (0, 1]
  4. 加权变形展开后等价于新旧两部分的加权平均，既保留历史记忆，又对近期变化敏感。
    Rn+1=(1−α)Rn+αS\displaystyle R_{n+1} = (1-\alpha)R_n + \alpha S

AI 应用场景

AI 写作助手：边生成边改稿

阶段：交互体验设计阶段（流式输出 + 用户控制）

解决的问题：传统 AI 写作让用户输入主题后干等十几秒，拿到整篇草稿才发现开头方向就错了，只能整篇重来。流式输出配合停止与局部重写，让用户在第一段出现时就能纠偏，相当于在开放式厨房里看到切菜方式不对，立刻喊停调整。

具体案例：某笔记类 App 的“AI 帮我写”功能，正文逐句流出；用户在第 2 句处暂停，选中首句改为“更口语一点”，AI 只重写该句并继续。全程不到 3 次停顿就得到了一份可用的草稿，用户反馈“像在和大厨一起做菜，而不是等外卖”。

代码助手：逐字符补全与安全停止

阶段：功能可用性与反馈设计（增量渲染 + 置信度表达）

解决的问题：IDE 中 AI 补全一次生成数十行代码，若方向错误，用户浪费的不只是时间还有注意力。逐字符流式补全配合随时停止与置信度提示，把“赌博式补全”变成“可控的协作”。

具体案例：开发者在写数据清洗脚本时，AI 补全到第 3 行使用了可能不存在的 API 名，界面在该调用下方显示“该 API 置信度低，请确认”；开发者立即按 Esc 中断，只采纳前半段正确逻辑，手写修正后继续。评论区将这类设计称为“敢用 AI 写生产代码的底气”。

教育辅导 AI：分步讲解的节奏

阶段：不确定性传达 + 满意度收集（渐进呈现 + 即时反馈）

解决的问题：直接给答案的 AI 会让学生失去思考过程。流式分步讲解让学生看到“思路如何展开”，每步标注置信度，学生可点踩让 AI 换一种讲法——知识像一道道菜依次上桌，而不是一大盘堆在你面前。

具体案例：数学辅导 AI 先输出“先建立坐标系”这一骨架，再逐步填充解法；第 4 步学生点踩表示“看不懂”，AI 收到反馈后切换为图形化的讲解路径，并记录该知识点的易错标记，供后续教学内容优化。

Python 演示

python60 行
import time  class StreamGenerator:    """模拟大模型流式输出, 每次只吐出一个 token"""     def __init__(self, text):        self.tokens = list(text)        self._pos = 0        self._stopped = False     def generate(self):        while self._pos < len(self.tokens) and not self._stopped:            time.sleep(0.05)            yield self.tokens[self._pos]            self._pos += 1     def stop(self):        self._stopped = True  class StreamDisplay:    """负责流式内容的增量渲染与进度展示"""     def __init__(self, total):        self.buffer = []        self.total = total        self.step_count = 0     def feed(self, token):        self.buffer.append(token)        self.step_count += 1        self.render()     def render(self):        text = "".join(self.buffer)        bar_len = 20        filled = int(bar_len * self.step_count / self.total)        bar = "#" * filled + "-" * (bar_len - filled)        print("\r[%s] %s" % (bar, text), end="")     def stop_hint(self):        print("\n--- 用户主动停止, 保留已生成内容, 可后续续写 ---")  def main():    text = "好的, 我来为你写一段文章。流式输出让用户看到生成过程而非只拿到结果。"    generator = StreamGenerator(text)    display = StreamDisplay(len(generator.tokens))    for token in generator.generate():        display.feed(token)        if display.step_count == 18:            generator.stop()            display.stop_hint()            break    print()  if __name__ == "__main__":    main()
目的：用生成器模拟大模型流式输出，演示“增量渲染 + 进度可视化 + 用户停止”三段核心机制：词元逐字产出、前端逐字拼接展示、中途暂停保留半成品。
  1. while self._pos < len(self.tokens) and not self._stopped:生成循环的两个约束：内容未耗尽且用户未叫停，这是“停止”能力的基本盘。
  2. yield self.tokens[self._pos]生成器每次只吐出一个 token，正是流式推送在 Python 中的天然实现。
  3. def stop(self):用户点击停止时调用的方法，把停止信号写进状态，后端立刻停止后续推理。
  4. display.feed(token)前端“增量渲染”：每收到一个词元就拼接到缓冲区并重绘界面。
  5. bar = "#" * filled + "-" * (bar_len - filled)把进度可视化成长度条，对应文中“进度可视化管理等待预期”。
  6. if display.step_count == 18:模拟用户在第 18 个 token 时喊停，验证中断后半成品得以保留。
  7. generator.stop()真正触发后端中断，而不是简单丢弃前端数据，对应“停止需联动后端”。

常见误区

误区我以为流式体验的核心代码就是把后端返回的一段段文本用字符串拼起来再渲染，只要数据不丢就算做好了。

正解拼接只是最底层的数据搬运，真正的设计重心是节奏、占位、光标、防抖、进度反馈这一整套感知系统。就像开放式厨房不只是拆一堵墙，还得安排灯光、动线和上菜节奏。只做拼接，用户看到的是一堆文字毫无章法地跳动，体验依然糟糕。

为何常见：开发者视角天然关注数据流的正确性，容易忽略用户感知层面的设计，而“感知”恰恰是流式体验的胜负手。

误区我总觉得只要模型推理速度够快，流式体验自然就好，速度是唯一重要的指标。

正解速度不是唯一指标，稳定性与节奏感更重要。生成速度忽快忽慢，用户会怀疑系统卡顿；速度太快，文字刷屏反而来不及阅读。就像大厨颠勺再快，如果节奏乱，客人看着也心慌。固定的输出频率、合理的分段、平滑的光标，比单纯压榨速度更能带来好感。

为何常见：人们习惯用传统性能思维（更快 = 更好）去理解体验问题，忘了体验是主观感受而非客观速率。

误区用户点停止后，我只要把前端接收到的文字隐藏或停止追加，就算实现了“停止生成”。

正解前端停止显示只是表象，后端模型可能还在继续推理、烧着 GPU 算力。正确做法是向前端冻结渲染、向后端发送中断信号，双管齐下，并且保留已生成内容供用户后续续写。否则就像客人喊停后，后厨还在疯狂炒菜——不仅浪费，还想重新开火也难。

为何常见：前端与后端常常被看作两个世界，前端工程师容易认为“我看不到就等于没发生”，忽视了算力成本的可感知性。

误区流式输出本来就有文字在动，用户应该知道系统在干活，何必再加进度条和“正在检索”之类的提示？

正解有文字在动不等于有有效反馈。如果推流间隔不稳定、内容无规律，用户依然会焦虑，甚至会误以为卡死。进度可视化、阶段提示（“正在检索第 3 份资料”）和预期管理（“还需 10 秒”）把无序的流动变成可预期的节奏。就像大厨虽然一直在忙，客人依然需要他偶尔抬头说一句“马上就好”。

为何常见：把“有输出”误当作“有反馈”，忽略了反馈需要可理解、可预期的结构。

面试题

Q1. 流式输出最核心的体验价值是什么？

单选题 · easy

  • A.大幅降低服务器算力开销
  • B.把等待过程转化为参与感← 正确答案
  • C.显著提升模型输出的准确率
  • D.完全消除用户的等待焦虑

答案：B。流式不会让模型变快，也不改变总耗时（排除 A、C）；它真正做的是把一段空白等待切碎成持续反馈，让用户从“干等”变成“看着回答成形”，就像开放式厨房里看大厨炒菜，锅气本身就是安抚。D 说“完全消除”过于绝对，焦虑只能缓解，无法归零。

Q2. 首 token 时间（TTFB）指的是什么？

单选题 · easy

  • A.模型生成全部回答所需总时长
  • B.从请求发出到首个字符出现耗时← 正确答案
  • C.用户阅读完整答案花费的时间
  • D.网络传输整个页面的总耗时

答案：B。TTFB 是“开锅信号”——从请求发出到第一个字符上屏的耗时，对应公式中的 T首。它不等于总时长（排除 A）、不是阅读时间（排除 C）、也不是整页传输时间（排除 D）。TTFB 越短，用户越早从焦虑切换到参与状态。

Q3. 用户点击“停止生成”后，最佳实践是？

单选题 · mid

  • A.前端冻结显示且通知后端中断推理← 正确答案
  • B.只负责隐藏前端界面上的生成文字
  • C.无论前端后端都立刻清空全部内容
  • D.直接关闭当前页面让请求自动失效

答案：A。停止必须“链路级”生效：前端冻结已渲染内容、通知后端中断推理、保留半成品可续写（A）。只隐藏文字（B）会让模型继续烧算力；清空全部内容（C）丢掉半成品；关闭页面（D）则粗暴地断了上下文，无法恢复。

Q4. 实现增量渲染时，最需要避免的问题是？

单选题 · mid

  • A.每次追加内容时引起整页布局重排← 正确答案
  • B.使用固定位置容器持续追加文本
  • C.让后端按批次稳定推送文字片段
  • D.在前端使用防抖减少重绘频率

答案：A。增量渲染的大忌是每次追加都触发整页重排，导致光标乱跳、页面闪烁，就像每次上菜都重新摆一次桌（A 是要避免的问题）。B、C、D 都是正确做法：固定容器、分批推送、防抖合并，因此不选。

Q5. 为什么流式输出能显著缓解用户的等待焦虑？

单选题 · mid

  • A.因为它让模型生成速度变得更快了
  • B.因为持续反馈打断了焦虑的持续累积← 正确答案
  • C.因为用户看不到过程就不会着急
  • D.因为它减少了用户要等待的总时间

答案：B。焦虑来自“未知的空白等待”，流式用持续出现的新内容打断焦虑的累积（B）。它没有提高模型速度（A 错）、没有减少总字数（D 错）；C 与事实相反——用户正因为能看到过程才不着急。

Q6. 在不确定性传达中，置信度标注的正确做法是？

单选题 · hard

  • A.对所有内容都标注同等强度的风险提示
  • B.只在低确信关键信息处给出核实提示← 正确答案
  • C.隐藏所有不确定性避免打扰用户阅读
  • D.用系统错误弹窗代替文本内联提示

答案：B。正确做法是“按需标注”，只在模型把握较低的关键事实上提示核实（B）。对全部内容一刀切加风险提示（A）会形成“狼来了”效应；完全隐藏（C）违背诚实原则；用错误弹窗（D）打扰阅读流程，还会让用户误以为是系统 bug。

Q7. 用户希望修改已生成文本中的一小段，应该怎么做？

单选题 · easy

  • A.锁定全部内容不允许任何局部修改
  • B.支持选中片段并只重写该局部内容← 正确答案
  • C.让用户重新输入完整需求再生成
  • D.忽略修改直接维持最初的生成结果

答案：B。合理的交互是支持局部选中并重写（B），这就是正文中的“中途编辑”模式。A 锁死内容剥夺了用户控制权；C 要求重写全部需求，成本太高；D 忽略用户修改等于无视反馈。

Q8. 下列属于流式输出核心设计模式的有？

多选题 · mid

  • A.采用增量渲染逐块拼接内容← 正确答案
  • B.生成前展示占位提示与骨架← 正确答案
  • C.先出大纲再渐进填充细节← 正确答案
  • D.准备完整内容后再统一渲染

答案：ABC。增量渲染、占位提示、渐进呈现正是正文讲到的三大模式（A/B/C 全选）。D“先准备好再统一渲染”恰恰是流式的反面——相当于把开放式厨房重新关上门，因此不选。

Q9. 关于“重新生成”功能的设计，正确的做法包括？

多选题 · hard

  • A.提供多个候选结果支持用户切换← 正确答案
  • B.保留用户编辑过的内容作为参考← 正确答案
  • C.每次重新生成都重置全部上下文
  • D.允许用户调整风格与随机程度← 正确答案

答案：ABD。重新生成应提供候选切换（A）、保留用户已做的编辑作为新上下文（B）、允许调整风格与随机度（D），这些都是“重来要无损”的体现。C“重置全部上下文”会让用户之前的修改全部作废，是最常见的翻车设计。

Q10. AIGC 产品中反馈机制设计的要点包括？

多选题 · hard

  • A.在生成过程中提供即时点赞点踩← 正确答案
  • B.破坏性操作附带轻量撤销确认← 正确答案
  • C.收集满意度并回流优化生成策略← 正确答案
  • D.强制用户写长篇评价并打分

答案：ABC。即时点赞点踩（A）、破坏性操作可撤销（B）、满意度数据回流优化（C）三者构成完整反馈闭环，对应正文“即时反馈—操作确认—数据闭环”三段论。D 强制用户写长篇评价只会制造流失，不是合格设计。