大模型不是「一次性写完」才把答案交给你的。输出以 SSE 分块方式一段段抵达浏览器：某个数据包可能在几毫秒内塞进数百个字符，下一个分块却要等数十毫秒。这种不均匀的到达节奏，是几乎所有流式界面体验问题的总源头。dsh-smooth-stream 是 DeepSeek Harness（dsh）Web UI 的原生插件，它把「内容到达」与「画面呈现」拆开，交给两级独立的物理状态机分别接管。本文不写安装，只讲机制，以及那些看似很玄的参数——8px、0.55 倍速、32ms——究竟在挡什么。
分块到达为什么会同时制造两个麻烦
把 DOM 渲染和视口滚动直接绑在离散的到达事件上，会同时引出两类问题。
第一类是视觉跳跃与撕裂：段落、代码块、表格整段「砸」在屏幕上，而不是铺上来；视线刚锁定一行，新内容已把它挤走，只能反复重新寻焦。
第二类是滚动抖动与重排风暴：常见写法是 scrollTop = scrollHeight 做瞬时硬跳；就算换成 CSS scroll-behavior: smooth，高频写入也会不断重置缓动曲线，动画永远无法收敛，高速流下伴随剧烈的主线程重排。
两类问题需要两套解法：前者关乎字符以什么节奏出屏，后者关乎视口以什么运动追上内容。插件把两者拆成独立的物理状态机，在每帧动画回调（rAF）中连续积分。
揭示节奏引擎（Reveal Engine）：把字符排放变成分数积分
揭示引擎决定每一帧露出多少字符。它不做「来一段就渲染一段」的搬运，而是维护字符积压队列并做分数级字符积分，速度随积压队列深度自适应：
v = 90 + backlog^1.25 × P
低负载时从容，高积压时平稳追赶，绝不倾泻整段文本；因为不要求每帧恰好露出整数个字符，速度曲线连续，不会因取整而顿挫。
折行限幅：8px 在挡什么
长文本与代码块换行时，内容高度会在一帧内突增。放任渲染的话，单帧视觉位移会达到 24~28px，看起来就是文字被「踢」了一下。揭示引擎对换行做折行限幅，把单帧视觉位移压到 8px 以内，原本一次完成的跳跃被摊到数帧。视觉上，换行是「流过去」而不是「跳过去」。
尾部平稳收束
回合结束标记到达后，队列里可能还有残余字符没露出。这部分缓冲会以恒定速率释放，而不是立刻全显。因此正文、思考链与工具调用之间的衔接自然，回合末尾不会出现一次「清仓式」突现。
弹簧跟随引擎（Follow Engine）：让视口用物理移动而不是赋值移动
第二件事是视口如何追上不断增长的内容。做法是二阶阻尼弹簧：k=130, c=24, m=1 的亚步进物理系统，把内容高度变化转化为平滑连续的速度与位移轨迹，而不是一次性赋值。你看到的推移是「被弹簧拉着走」的结果，天然带阻尼，不会急停急起。
零重排：把视觉滞后交给合成层吸收
若每次跟随都改滚动容器的高度或位置，读写布局属性就会触发 Reflow，「重排风暴」正源于此。零重排（Zero-Reflow）位移补偿做了职责分离：真实滚动容器锚定底部，剩余视觉滞后完全由外层 DOM 的 transform: translate3d 吸收；跟随过程不读写任何触发 Layout 的属性，补偿走纯合成层（GPU），因此不引发重排。
闭环背压：最低为什么是 0.55 倍速
跟随滞后是有限度的。当弹簧滞后接近预留空间时，插件反向向揭示引擎施加阻尼——这就是闭环背压控制，最低把揭示速度降到 0.55 倍速。也就是说，跟随引擎并非被动追逐，它还会回头压住呈现节奏，防止文本增长超出视口弹簧能处理的范围。这条从跟随指向揭示的反向通道，是系统稳定收敛的关键。
掉帧自愈与跨刷新率一致
主线程卡顿时，弹簧物理时间会被自动钳位在 32ms 以内，避免画面恢复后一次「突进瞬移」。同时这套物理在 60Hz 与 120Hz（ProMotion）屏下拥有近乎一致的收敛时间——高刷屏不会因帧更密就把动画做快，手感保持一致。
会话生命周期自动折叠（Turn Auto-Collapse）
插件也管会话生命周期：对话进行时思考链与工具调用实时展开，让你看见过程；回合结算稳定后，执行过程自动收敛为一行极简的「已处理 X 秒」摘要，保持工作区专注，需要时点击即可无缝展开。这是「过程可见」与「结果干净」之间的一次折中。
这套机制扛得住吗：三道基准闸门
README 随包提供三个自动化闸门，用来约束这些机制真的在起作用：
| 验证闸门 | 测试项目 | 指标要求 |
| --- | --- | --- |
| 流式渲染审计 | node scripts/run-render-audit.mjs | 5 种典型场景 10/10 Clean，零位移回退 |
| 视口溢出闸门 | node scripts/verify-overflow.mjs | 极限输出下零过滚、零反弹 |
| 尾行晃动抑制 | pnpm test | 单帧跳变 ≤30px，7 帧振幅峰值 ≤32px |
这些是作者随仓库提供的台架基准，衡量「机制是否按设计收敛」，而非对阅读感受的背书。另一个细节是体积——核心 ESM 产物 Gzip 后仅约 4.7 kB，用几 KB 装下一整套物理状态机，是它能无负担挂进 Web UI 的原因之一。
装上它之前，先确认这几件事
环境前提。 安装命令 dsh plugin --profile web add dsh-smooth-stream 依赖 dsh CLI 引擎；若得到 command not found: dsh，先 npm install -g @deepseek-ai/dsh 或用 npx @deepseek-ai/dsh web。package.json 声明 ^22.19.0 || >=24.0.0，低于 22.19 会在安装阶段报 engines 不满足。
本地验证需要额外环境。 执行 pnpm build:repro 后以 file:// 打开 repro/index.html 会空白或 404，需在仓库根目录执行 python3 -m http.server 8765 --bind 127.0.0.1 再访问；node scripts/verify-logarithmic-fade.mjs 则需要 Chrome 与 ffmpeg，Chrome 不在默认路径可用 CHROME_BIN 指定，缺 ffmpeg 时用 pnpm exec playwright-core install ffmpeg 补齐。
这些都是环境前提，与插件物理机制无关，但会让第一次上手的人多绕几步。
总结
dsh-smooth-stream 的价值不在视觉特效，而在于把「字符到达」与「画面呈现」彻底解耦：揭示引擎用分数积分与折行限幅控制出屏节奏，跟随引擎用二阶阻尼弹簧与零重排补偿控制视口运动，两者再由背压闭环互相牵制。如果你也在用 dsh 处理长篇生成，想一次看清同类插件的分布，可以先翻一遍 DeepSeek Harness Hub 插件清单 再决定装哪个；理解了这两级状态机，你也就理解了它的默认手感为什么是现在这样。
适合与不适合
适合：长期用 dsh Web UI 读数百行长篇推演与思考链、需要稳定阅读手感的用户；高频盯代码块生成、被换行踢移干扰的开发者；对高刷屏上动画速度不一致敏感的 ProMotion 设备用户；想开调试面板观察 FPS 与字符积压、并微调物理参数的技术型用户。
不适合：主要在 TUI 或桌面客户端工作的人——插件只覆盖 Web UI，对终端界面无效；宿主内核停在 0.1.2-alpha 系列之前又不愿升级的人，需要内核 ≥0.4.3 才能在这类宿主上加载；习惯依据社区口碑决策的人——该插件用户评分为 0、无人投票，没有现成反馈可参考，只能自己实装试手感。
标签：流式渲染引擎、DeepSeek Harness、流式渲染原理、物理动效、Web UI 插件
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。