语义滚动条

三千行日志，滚动条滑块只有几像素高。用户想找「刚才那个报错在哪」时， 唯一的办法是盲拖——这是所有长列表共同的困境。

把内容的结构画出来，就能直接跳过去。

微应用尚未挂载。

试试

右侧每个色块是一个执行阶段，红色是含错误的段。点色块跳到该段， 悬停看标题与行数；滚动列表时当前段会跟着高亮。

不需要模型

「语义滚动条」听起来像是要让模型去读一遍内容，但对结构化的长列表来说完全不必： 段落边界本来就在数据里。

Agent 执行流的例子里，规则只有三条：

• 一条「思考」开启新的一段，它的文本就是段落标题；
• 太短的段并入上一段，否则连续的思考行会切出一堆一行段，导航条变成噪声；
• 段的颜色取段内最严重的事件（错误 > 工具调用 > 输出）。

纯函数、无网络、无模型，几千行的分段计算不到一毫秒。会话列表可以换成别的规则—— 按话题切换、按时间间隔（超过十分钟没说话就是新一段）、按发言人变化。 真正需要模型的只有「给这一段起个人类能读的标题」，而那件事可以离线做、结果存起来。

导航条怎么画

一段一个色块，高度按段内行数分配。用 flex 布局的话不需要自己算像素：

容器：display: flex; flex-direction: column
色块：flex-grow = 段内行数

于是每个色块的高度天然等于这一段在整个列表里的占比， 数据变了重新渲染一次就行，没有任何几何计算。

三件让它真正好用的事

一、当前段要高亮。 用 update 事件里的 inViewBegin 反查落在第几段—— 用户滚动时导航条上的位置跟着走，才建立起「我在哪」的空间感。

二、点击跳转用 scrollToIndex，而不是按比例设偏移量。 不定高列表里「第 30% 的像素」和「第 30% 的项」是两回事， 而用户点的是「那一段」，要的是段首那一项。

三、悬停给出标题与行数。 色块本身只能表达位置和严重程度， 「这一段在干什么」得靠 title 或自定义浮层补上。

与滚动条的关系

这个导航条不替代滚动条，两者信息不同：滚动条表达「视口在整个内容里的位置与比例」， 导航条表达「内容的结构」。让它们并列摆放、各司其职，比把语义信息塞进滚动条滑块要清楚。