Claude Code为何使用随机动词？从等待焦虑到可信状态反馈

同样等待二十秒，一块没有变化的空白界面，和一个持续回应你的界面，带来的感受可能不同。Claude Code 在处理任务时显示带有个性的动词，使等待成为产品体验的一部分。不过，“看起来还在工作”与“知道工作进展”仍然是两回事。

等待中的不安从哪里来

用户通常不是只关心时间长短，还在判断：请求是否已经收到、系统有没有卡住、现在该继续等还是重新提交。如果界面没有反馈，用户就要自己猜测，并可能反复按下发送按钮。

从产品设计角度看，活动提示能够为“请求已被接收”提供一个信号。短语变化则增加了一点可感知的动态。它们可能改善主观感受，但不能据此声称已经证明随机动词会降低焦虑，或让所有任务更容易等待。本文讨论设计推理，不把它写成 Anthropic 公布的心理实验结论。

随机动词可能发挥的三种作用

减少界面的僵硬感

长时间固定显示一个词，容易让人觉得没有变化。适度变化让产品保留活跃感，尤其适合没有准确百分比的生成任务。不过频率过高又会打断阅读，因此应把它当作低优先级信息。

建立产品语气

一个工具可以严谨，也可以在空闲细节上轻松一些。简短动词提供了表达风格的空间，不必占用正文或打断任务。面向不同组织和语言环境时，幽默也需要克制：开发者觉得有趣的文字，未必适合面向客户的正式工具。

把沉默变成可以理解的活动

用户更容易接受“当前尚无最终输出，但任务仍在运行”。前提是运行状态确实可靠。若后台已经失败，前台仍不断变换动词，原本用于安抚的设计就变成了误导。

为什么它不能替代真实进度

随机词库不了解任务实际步骤。看到“构思中”，并不代表模型进入了可被测量的某个思考阶段；看到“整理中”，也不能断定文件已经读取完毕。

对于会修改文件、运行命令的 Agent，真正有帮助的状态包括“已读取哪些文件”“正在执行哪个测试”“等待哪项输入”“发生了什么错误”。这些信息必须来源于执行事件，而不是为了好看临时编写。

如何把这种设计用于自己的产品

1. 先做准确状态：最少区分运行、等待输入、完成、失败与取消。
2. 再加辅助文案：让轻松短语处于次要视觉层级，避免覆盖错误信息。
3. 给用户控制权：支持取消、查看已完成步骤，以及在失败后重新尝试。
4. 照顾安静模式：减少动画、控制刷新频率，不让辅助词语反复打断屏幕阅读器。
5. 按场景验证：分别观察短问答、长代码修改和网络异常时的表现。

一组值得比较的实验

可以比较“静态提示”“轮换中性短语”“真实阶段信息加辅助短语”三种方案，在相似任务和响应时长下观察用户是否理解状态、是否重复提交，以及何时选择取消。不要只比较停留时长，那可能把困惑误判为参与度。

两个应避免的设计

• 没有后端证据，却显示“测试即将通过”或“马上完成”。这会制造不可靠的承诺。
• 等待已经超出预期，还只显示玩笑。此时应优先解释耗时原因或给出下一步。

Claude Code 允许用户定制 spinner 动词，为个人偏好留下空间。对产品团队而言，更值得借鉴的是分工：让真实状态负责可信，让辅助文案负责语气，让用户始终知道自己还能做什么。