AI 回复前的三个点，应该告诉你它在忙什么

AI 回复前的三个点，应该告诉你它在忙什么

你在 AI 聊天框里等回复时，最怕的不是慢，而是不知道它有没有在处理。thinking-orbs 把等待拆成六种状态、两种尺寸和低动效，让转圈变成能读的反馈。

先看它有没有把转圈、状态和可访问性连成一条链路，再判断值不值得继续看。

样本里最值得看的点

这里看的不是图形多花，而是状态有没有按真实场景拆开。能把等待、暂停、隐藏页和低动效一起说清，才算有组件味道。

这也是 AI 产品越来越常见的小问题：模型能力在前进，界面反馈如果跟不上，用户还是会觉得卡。

它像一个界面体验样本

公开资料能确认它面向 AI 和 agent UI：dotted thought-orb loading indicators，包含六种状态、两种尺寸、深浅色、低动效、2D canvas、DPR 2、role="img" 和 aria-label。

这里最值得看的不是“好不好看”，而是它把等待、暂停和可访问性放在了一起。2D canvas、DPR 和低动效一起出现，说明它想把实现做轻，也想把状态说清楚。

我为什么先看 2D canvas

这个实现不碰 SVG filters，也不走 WebGL，说明它想把实现方式做轻。这个信号比单看动图更有观察价值，因为界面体验最后拼的不是动画炫不炫，而是状态能不能稳定出现。

先怎么试

先用临时页面验证一个状态，记录隐藏页暂停和主题表现；记录完整再进入下一步。样本越小，越容易看清它是不是解决了“等待没说清”的问题。

我会怎么取舍

这次只记为样本。等出现真实页面任务，再看它能不能接住。能让客服、运营或测试少问一句“现在到底卡没卡住”，才算有价值。

下一轮看真实页面

这次先记为界面体验样本；等出现实际任务，再看它能不能接住。

现在只给观察结论。能让等待、暂停和低动效都讲清，才算真正有价值。

如果它只是把页面装饰得更忙，那就不必抢占开发排期。

使用边界

公开资料能说明组件方向；没有本地安装实测，不能替代真实页面运行记录。

后续要看的不是再数一次参数，而是状态是否能在真实页面里稳定出现。

2026-07-23 · 公开资料观察，按 AI 界面状态链路、可访问性和低动效边界记录；后续需本地页面复核。 项目仓库：https://github.com/Jakubantalik/thinking-orbs。

技术信号放在哪里

thinking-orbs 的技术信号不在复杂特效，而在它选择了 plain 2D canvas arcs。这个选择说明它更像一个轻量状态组件，而不是靠重特效堆出来的演示动画。

等待状态已经不是 AI 产品的小装饰。模型生成、工具调用、agent 排队都会让用户停在屏幕前，反馈设计如果缺位，功能再强也容易被误解成卡顿。

后续如果要继续观察，我会只看真实链路：同一套反馈能否覆盖生成中、暂停中和失败后的提示，样式能否被现有设计系统接住，升级后会不会牵动多个页面。