回字有多少种写法，本来是一个贬义词，但是被 Claude Code 活用成了用户体验的典范。
187 种"我正忙着呢"的说法
Claude Code 除了严谨工程之外还有一个有趣的设计小巧思，让我第一次接触时候很惊艳，感受到了大厂的精致，就是思考时蹦出来的动词 ------ 从 Accomplishing 到 Zigzagging 、Clauding 、Flibbertigibbeting 、Moonwalking 和 Prestidigitating ......。源码位置 src/constants/spinnerVerbs.ts 总共 187 个动词，Claude Code 在开始一个任务时候会从这 187 个动词里面随机选一个。也支持 settings.spinnerVerbs 自定义，自己加词。
另一类动词属于 turnCompletionVerbs 即代码写完了或一个轮次结束后的收尾词，源码在 src/constants/turnCompletionVerbs.ts，它只从 8 个词里挑一个：烤好了、煮好了、搅好了、想好了、出锅了、搞定了、炒好了、干完了，对应 Baked , Brewed , Churned , Cogitated , Cooked , Crunched , Sautéed , Worked.。
Caude Code 用 187 种说法描述它是如何进行编码旅程的，最终用 8 种说法宣告结果。
个人感受
一个好的产品真是处处都有小巧思。
过程本身是有价值的，哪怕用户只是在等待
第一个巧思是如何对用户表达 processing / loading，一般国内的产品大都同质化在"处理中"、"进行中"，而 Claude 从一个简简单单看似没有什么可以做的 "processing" 着手。为什么对它大费周章？我们需要了解背后的原因。
在得物的一篇文章《基于 Harness + SDD + 多仓管理模式的 AI 全栈开发实践｜得物技术 todo》中对比过 Cursor 和 Claude Code 代码生成速度。Cursor 极速，完成一次任务平均 1 分钟，而 Claude Code 中速，平均 3 - 30 min，5 min 以上是常态。当然这里面存在二者对代码库检索的哲学，一个是 Indexing 另一个是 No Indexing（仅使用 bash command）。Claude Code 好比人阅读代码的方式，自然造成在完成一个任务的时候需要一遍遍仔细"Grep/Glob... 我称之为咀嚼"代码。Claude Code 的长时间咀嚼以及多轮 IO / HTTP 调用迫使 PD 不得不想办法（当然能敏锐觉察到这是问题的 PD 已然是一个好 PD），如果不用这些"花里胡哨"的进行中动词，统一用 processing 或 loading，用户可能早就腻烦了等待。
上下文检索策略有两种。第一种推理前检索（传统 RAG），在推理前使用基于嵌入的检索来获取上下文，适用于在交互过程中不会改变的静态内容。这是 Cursor 采用的方案。
第二种即时上下文 ，维护轻量级标识符（文件路径、查询、链接），在运行时动态加载数据。它优势在于： 避免上下文污染、实现渐进式披露、模仿人类认知（我们不会记住所有东西）...... 。 缺点也显而易见，比预计算检索慢、耗费 token 多、需要适当的工具引导以避免走入死胡同，据此还可以产生混合策略，这就是 Claude Code / OpenCode 主流工具正在使用的。方法是预先检索部分数据，根据需要启用自主探索。Claude Code 预先加载 CLAUDE.md 文件，使用 glob/grep 进行即时检索。具体下一篇文章再细述。
而且 spinnerVerbs 的选择也是有讲究的，你会发现这些词都不简单，可以用佶屈聱牙形容。让你需要多看几眼，陷入短时思考，甚至去查一下字典才能知道含义。比如 Flibbertigibbeting 、Prestidigitating。这样的好处是什么？等待的时间可以被打发掉，过程似乎也没那么枯燥了。
Claude Code 永远不让你干等，总能用花式骚操作告诉你"我在忙"，让等待变成乐趣。
Claude Code 对 spinnerVerbs 的重视和精挑细选让用户感受到过程本身是有价值的，哪怕用户只是在等待。
结果的收敛也是一种美学
第二个巧思，为什么进行中 spinnerVerbs 数量比 turnCompletionVerbs 多两个数量级，前者 187+，后者 8+？"187 ways to describe the journey. 8 ways to describe the destination. Many paths, few outcomes."
这里面蕴藏着一种技术哲学。过程 极其丰富：Claude Code 在思考时 （做推理、查代码、生成方案）可以用 187 个不同的动词来描述，意味着它在"怎么干活"这件事上手段颇多、花样百出、路径多样。 但结果 极其收敛：任务完成后，用来描述"做完了"的动词只有寥寥 8 个。不管中间经历了多少曲折、用了什么酷炫的算法，最终呈现给用户的结果形式是单一的------任务完成了。
这就像：你为了做一道菜，可能经历了切、剁、拍、腌、炒、炸、炖、焖......（过程动词很多），但端上桌时，只需说一声"菜做好了"（结果动词极少）。
我们可管中窥豹感受到 Claude Code 工作模式：
- 路径多：它处理同一个问题时，内部可能尝试了多种思路、搜索了多个文件、打了多个补丁、回退重试了好几次。这些内部过程丰富多彩，用 187 个动词都不够形容。
- 结果少：但最终对外输出的结果往往只有几种：代码改好了、测试通过了、错误修复了、问题回答了...... 用户不关心它中间走了多少弯路，只看最后的"成色"。
一个简单的数字对比（187 : 8），体现了 Claude Code 的技术实现观：
AI 的复杂性隐藏在过程里，而交付给用户的简洁性是设计的结果。
编程不只是逻辑，也是手艺；解决问题不只是输出，也是创作
最后再谈谈那 8 个结果动词------它们清一色都是烹饪词汇。Claude Code 团队在告诉你：编程不只是逻辑，也是手艺；解决问题不只是输出，也是创作。
你能想象如果结果动词是"Executed"、"Terminated"、"Finalized"是什么感觉吗？那是机器的语言。而 "Cooked"、"Baked"、"Sautéed"是人的语言，带着温度。
JavaScript与编程艺术