1. 项目概述：一个被忽视的细节，如何定义一流体验

最近在折腾Claude Code的时候，我注意到一个特别有意思的细节。这玩意儿不是个代码编辑器插件嘛，但让我印象最深的，不是它写代码有多快，也不是它理解上下文有多准，而是它“等待”时显示的那行字。对，就是那个在你提交请求后，它思考时显示的“正在处理”的提示语。

你可能觉得这有啥好说的，不就是个加载动画配个文案吗？但如果你像我一样，一天要和它交互几十上百次，你就会发现，这个小小的文案，几乎每次都不一样。有时候是“正在思考”，有时候是“正在分析”，有时候是“正在生成”，甚至还有“正在润色”、“正在重构”。我一开始以为是随机的，后来一琢磨，不对，这背后肯定有门道。于是，我花了点时间，把Claude Code里所有可能的“正在处理”的动词都给扒了出来，不数不知道，一数吓一跳，竟然有187种不同的说法。

这个发现让我这个干了十几年产品设计和开发的老兵，一下子来了精神。我们整天挂在嘴边的“用户体验”，到底体现在哪里？是酷炫的界面，还是流畅的动效？这些当然重要，但Claude Code用这187个动词告诉我，真正的顶级体验，藏在那些最细微、最容易被忽略的交互瞬间里。它解决的，是用户在等待时最核心的焦虑：“我的请求被接收了吗？”“它在干嘛？”“还要等多久？”通过一个精准、动态变化的动词，它把后台这个“黑箱”过程，撕开了一个小口子，让用户得以窥见一丝光亮，从而获得确定感和掌控感。

这不仅仅是一个文案游戏。它适合所有正在打造数字产品的产品经理、设计师和开发者来思考。无论你做的是To B的复杂系统，还是To C的轻量应用，只要你的产品需要用户等待，这个“等待体验”的设计，就是你与平庸产品拉开差距的关键战场。今天，我就带你一起，从Claude Code这187个动词出发，拆解一下一流公司是如何在细节上“死磕”，把等待变成一种甚至有点“愉悦”的体验的。

2. 核心思路拆解：为什么是动词，以及为什么需要187个？

2.1 从“状态指示”到“过程沟通”的范式转变

传统的加载设计，我们称之为“状态指示器”。它的核心逻辑是二元且静态的：任务要么“进行中”，要么“已完成/失败”。表现形式通常是一个旋转的圆圈（Spinner）、一个进度条，或者一句万年不变的“加载中...”、“请稍候...”。这种设计传递的信息极其有限，它只告诉用户“我在忙”，但忙什么、忙到哪一步了，用户一无所知。在等待一个未知时长的任务时，这种不确定性是用户焦虑的主要来源。

Claude Code的做法，实现了一次从“状态指示”到“过程沟通”的范式跃迁。它不再满足于告诉用户“我在工作”，而是致力于告诉用户“我正在如何为你工作”。这187个动词，就是它用来与用户沟通工作过程的“词汇表”。每一个动词，都对应着后台AI模型在处理用户请求时，可能正在执行的一个微观任务或一种思维状态。

举个例子，当你让它“写一个快速排序函数”时，它可能依次显示：

1. 正在理解你的请求... （解析指令，明确意图）
2. 正在构思算法结构... （构建回答框架）
3. 正在编写Python代码... （生成核心代码内容）
4. 正在添加注释... （增强代码可读性）
5. 正在进行最终检查... （逻辑与语法校验）

这个过程模拟了一个人类专家的思考和工作流，让冰冷的AI处理过程有了温度和节奏。用户不再是面对一个沉默的黑箱，而是在“观看”一场思维表演。这种透明化极大地提升了用户的耐心和信任感。

2.2 “187”这个数字背后的产品哲学

你可能会问，需要这么多吗？10个、20个不够用吗？这里就体现了一流公司的产品哲学： 极致的场景颗粒度与情感共鸣 。

首先， 场景的极致细分 。Claude Code能处理的任务类型极其多样：写代码、解释代码、调试、重构、写文档、写测试、翻译、甚至聊天。每一类任务，其内部的处理子步骤是不同的。写文档时的“正在组织大纲”和调试时的“正在定位异常”所传达的专业感和准确性是天差地别的。187个动词确保了在任何一种任务、任何一个处理阶段，都能找到最贴切的那个词，避免“张冠李戴”带来的违和感。

其次， 对抗单调与疲劳 。即使对于同一类任务，如果用户每次看到的都是相同的几个动词循环，新鲜感会迅速消失，文案就会重新沦为背景噪音，失去沟通价值。187个动词构成了一个庞大的词库，通过合理的随机或上下文匹配算法，使得每次等待的体验都有细微的不同，这种不可预测的“小惊喜”能有效缓解重复操作带来的枯燥感。

最后， 建立品牌人格 。这些动词的选取绝非随意。它们大多积极、主动、富有建设性，如“构思”、“雕琢”、“编织”、“赋能”。这潜移默化地在塑造Claude Code的人格形象：它不是一个被动的工具，而是一个积极的、有创造力的、致力于为你提供价值的合作伙伴。这种人格化设计，是提升用户情感认同和忠诚度的关键。

2.3 技术实现窥探： spinnerVerbs 与 turnCompletionVerbs

从技术角度看，实现这套系统主要涉及两个关键概念，这也是我们从网络热词中看到的： spinnerVerbs （加载动词）和 turnCompletionVerbs （回合完成动词）。

• spinnerVerbs ：这就是我们上面讨论的，在流式输出内容（即AI一个字一个字生成）之前，在加载动画旁边显示的那个动词数组。它负责“过程沟通”。这个数组很可能非常庞大，包含了那187个动词，并根据当前会话的上下文（如用户最后一条消息的意图、正在编辑的文件类型）进行筛选和轮播。
• turnCompletionVerbs ：这个则是在AI完整输出完一段内容后，可能用于替换或补充的动词。例如，当回答生成完毕，加载动画停止，可能会短暂显示“已完成分析”或“建议已生成”，然后才消失。它负责给一个处理“回合”画上明确的句号，提供完整的反馈闭环。

在Claude Code的配置文件或内部设置（如 settings.spinnerVerbs ）中，产品团队可以精心管理和维护这些动词列表，并可能为其配置权重、关联任务类型等元数据。实现时，前端会监听AI模型的状态。当状态变为“思考中”时，便从这个动词池中，根据算法选取一个动词显示出来。这个算法可能是简单的随机，也可能是更复杂的基于上下文的匹配。

实操心得 ：在我们自己的项目中，初期不必追求187这个数量级。可以从10-20个高度贴合核心场景的动词开始，关键是建立“状态-动词”的映射逻辑。例如，对于上传任务，可以准备“正在校验”、“正在压缩”、“正在传输”、“正在入库”等；对于数据分析任务，可以是“正在查询”、“正在计算”、“正在可视化”。核心是让动词和后台真实的任务阶段尽可能对应。

3. 设计解析与实操要点：如何打造你自己的“动词引擎”

3.1 动词池的构建原则：精准、多样、有温度

构建一个有效的动词池，不能靠拍脑袋，需要遵循几个核心原则：

1. 精准性优先 ：动词必须准确反映后台进程。如果你在计算，就显示“正在计算”，而不是“正在思考”。不准确的描述比模糊的描述更伤害信任。这需要产品、设计和开发紧密协作，明确每一个可能让用户等待的后台任务，并将其分解为可描述的阶段。
2. 多样性控制 ：多样性不等于随意。动词之间应有清晰的语义边界。避免使用“正在处理”、“正在操作”这种万金油词汇，它们和“加载中”没有本质区别。相反，应使用“正在编译”、“正在渲染”、“正在同步”这样具体的词汇。多样性应体现在对不同任务类型的覆盖上，而不是对同一任务堆砌近义词。
3. 注入人格与温度 ：在精准的基础上，可以选择一些更具象、更拟人化的词汇来提升体验。例如，用“正在雕琢语句”代替“正在优化文本”，用“正在绘制蓝图”代替“正在生成架构”。这一点需要克制，必须符合产品的整体调性。一个严谨的B端数据库工具用“正在编织数据”可能就不太合适，而“正在聚合结果”则更佳。
4. 时态与语态 ：中文通常使用“正在+动词+...”的进行时态，清晰表明状态。确保所有动词都能自然融入这个句式。避免使用名词或形容词。

一个简单的启动清单 ：

• 分析类任务 ：正在解析、正在拆解、正在评估、正在对比、正在溯源。
• 生成类任务 ：正在起草、正在编写、正在创作、正在构建、正在合成。
• 优化类任务 ：正在精简、正在重构、正在调整、正在润色、正在提速。
• 检查类任务 ：正在验证、正在测试、正在扫描、正在校对、正在复核。
• 系统类任务 ：正在连接、正在上传、正在下载、正在安装、正在配置。

3.2 上下文匹配逻辑：让提示“智能”起来

有了动词池，下一步是决定在某个特定时刻显示哪一个。这里有几个层次的匹配逻辑可以考虑，由简入繁：

• 层级一：随机轮播 。最简单的方式，从动词池中随机选取一个显示。优点是实现简单，能提供基础的变化性。缺点是可能文不对题，比如用户在上传文件，却显示“正在思考”。
• 层级二：按任务类型分组 。将动词池预先分为几个大类，如“代码相关”、“文本相关”、“文件操作”、“系统操作”等。当触发一个任务时，根据任务类型从其对应的分组中随机选取动词。这能保证基本的相关性。
• 层级三：基于用户输入内容的简单推断 。这是Claude Code很可能采用的策略。通过分析用户最新的消息或操作，提取关键词。例如，消息中包含“写一段代码”，则从“生成类”和“代码类”动词中选取；消息中包含“为什么报错”，则从“分析类”和“检查类”动词中选取。这需要一定的自然语言处理（NLP）基础，但初期可以用关键词匹配来实现。
• 层级四：结合处理阶段动态切换 。对于耗时长、阶段明确的任务，可以在任务执行的不同节点，动态更新动词。例如，一个视频导出任务，可以依次显示：“正在编码视频流”、“正在混合音频轨”、“正在封装文件”、“正在计算校验和”。这需要后台能提供明确的进度事件给前端。

注意事项 ：上下文匹配的复杂度越高，开发和维护成本也越高。对于大多数团队，我建议从 层级二 开始，结合 层级一 的随机性。即为核心的3-5个任务类型定义专属的动词子集（每个子集10-15个动词），执行时从对应子集中随机选取。这能在保证相关性的前提下，以较低成本获得不错的效果。

3.3 前端实现与动画配合

光有文案还不够，需要与加载动画（Spinner）有机结合，形成一个统一的等待状态组件。

1. 组件结构 ：创建一个独立的 LoadingIndicator 组件。它接收一个 verb （动词）属性，用于显示动态文案。动词可以来自父组件根据上下文传入，也可以由该组件内部从一个列表中随机选取（取决于你的匹配逻辑放在哪里）。
2. 状态管理 ：在全局状态（如Vuex、Pinia、Redux）或组件内状态中，管理一个 isLoading 和 loadingVerb 变量。当发起异步请求时，将其设为 true 并设置对应的动词；请求完成时，设为 false 。
3. 动画与文案的节奏 ：Spinner动画应该平滑、稳定。文案的出现和消失最好有淡入淡出效果，避免生硬切换。如果动词会根据任务阶段更新，确保更新时有一个平滑的过渡动画。
4. 超时与降级处理 ：必须设置超时机制。如果等待时间异常长（如超过30秒），除了显示动词，应考虑提供更详细的进度信息、取消操作的按钮，或将动词替换为“正在处理，这可能需要比平时更长的时间...”等安抚性文案。这是体验的底线保障。

一个简单的Vue 3组件示例 ：

<template>
  <div v-if="isLoading" class="loading-overlay">
    <div class="spinner"></div> <!-- 一个CSS旋转动画 -->
    <p class="loading-text">正在{{ currentVerb }}...</p>
  </div>
</template>

<script setup>
import { ref, computed } from 'vue';
import { useLoadingStore } from '@/stores/loading'; // 假设使用Pinia管理状态

const loadingStore = useLoadingStore();
const isLoading = computed(() => loadingStore.isLoading);
const currentVerb = computed(() => loadingStore.currentVerb || '处理'); // 提供默认值
</script>

<style scoped>
.loading-overlay {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  /* 定位样式 */
}
.spinner { /* CSS动画 */ }
.loading-text {
  margin-top: 10px;
  color: #666;
  transition: opacity 0.3s ease;
}
</style>

4. 深入实操：从零搭建一个动态加载提示系统

4.1 第一步：定义动词词库与分类

我们先抛开复杂的AI推断，为一个假设的“智能文档助手”应用构建一个基础系统。这个应用主要功能是：分析文档、总结内容、翻译、校对语法。

我们在项目的 /src/config/ 目录下创建一个 loadingVerbs.js 文件：

// /src/config/loadingVerbs.js

/**
 * 按任务类型分类的加载动词库
 */
export const LOADING_VERBS = {
  // 文档分析相关
  ANALYSIS: [
    '解析文档结构',
    '提取关键信息',
    '识别核心主题',
    '梳理逻辑脉络',
    '评估内容质量',
    '解构段落大意',
    '定位重点句段'
  ],

  // 摘要总结相关
  SUMMARIZATION: [
    '凝练核心观点',
    '组织摘要大纲',
    '精简内容要点',
    '合成概括语句',
    '压缩文本信息',
    '提炼主旨思想'
  ],

  // 翻译任务相关
  TRANSLATION: [
    '解析源语语义',
    '匹配目标语汇',
    '转换语言结构',
    '调整文化表达',
    '润色译文措辞',
    '进行双语对齐'
  ],

  // 语法校对相关
  PROOFREADING: [
    '扫描语法错误',
    '检查拼写问题',
    '评估标点使用',
    '调整句式流畅度',
    '优化词语搭配',
    '进行最终复核'
  ],

  // 通用/未知任务（保底）
  GENERAL: [
    '处理你的请求',
    '进行中',
    '加载内容',
    '准备就绪'
  ]
};

/**
 * 根据任务类型获取一个随机动词
 * @param {string} taskType - 任务类型，对应 LOADING_VERBS 的 key
 * @returns {string} 随机选中的动词（不带“正在”前缀）
 */
export function getRandomVerb(taskType = 'GENERAL') {
  const verbList = LOADING_VERBS[taskType] || LOADING_VERBS.GENERAL;
  const randomIndex = Math.floor(Math.random() * verbList.length);
  return verbList[randomIndex];
}

4.2 第二步：集成状态管理与任务派发

接下来，我们需要在状态管理中关联任务与动词。这里使用 Pinia（Vue 3）作为示例，Redux或Context API思路类似。

创建加载状态Store： /src/stores/loading.js

// /src/stores/loading.js
import { defineStore } from 'pinia';
import { getRandomVerb } from '@/config/loadingVerbs';

export const useLoadingStore = defineStore('loading', {
  state: () => ({
    isLoading: false,
    currentVerb: '处理',
    currentTaskType: null,
  }),

  actions: {
    /**
     * 开始加载，并指定任务类型以匹配动词
     * @param {string} taskType - 任务类型
     */
    startLoading(taskType = 'GENERAL') {
      this.currentTaskType = taskType;
      this.currentVerb = getRandomVerb(taskType);
      this.isLoading = true;
    },

    /**
     * 停止加载
     */
    stopLoading() {
      this.isLoading = false;
      // 可选：清空任务类型
      this.currentTaskType = null;
    },

    /**
     * 在长任务中更新动词（用于多阶段任务）
     * @param {string} newVerb - 新的动词
     */
    updateLoadingVerb(newVerb) {
      if (this.isLoading) {
        this.currentVerb = newVerb;
      }
    }
  }
});

在具体的业务组件中，比如一个文档总结按钮：

<template>
  <button @click="handleSummarize" :disabled="loadingStore.isLoading">
    总结文档
  </button>
  <LoadingIndicator />
</template>

<script setup>
import { useLoadingStore } from '@/stores/loading';
import { summarizeDocument } from '@/api/documentApi'; // 假设的API

const loadingStore = useLoadingStore();

const handleSummarize = async () => {
  // 1. 开始加载，并指明是“总结”任务
  loadingStore.startLoading('SUMMARIZATION');

  try {
    // 2. 执行异步任务
    const result = await summarizeDocument();
    // 处理结果...
  } catch (error) {
    // 处理错误...
  } finally {
    // 3. 无论成功失败，都停止加载
    loadingStore.stopLoading();
  }
};
</script>

4.3 第三步：实现动态提示组件与高级效果

现在，创建我们的 LoadingIndicator 组件，并添加一些提升体验的细节。

/src/components/LoadingIndicator.vue :

<template>
  <Transition name="fade">
    <div v-if="isLoading" class="loading-indicator">
      <div class="spinner-container">
        <!-- 使用SVG实现一个更精致的Spinner -->
        <svg class="spinner" width="40" height="40" viewBox="0 0 50 50">
          <circle class="path" cx="25" cy="25" r="20" fill="none" stroke-width="5"></circle>
        </svg>
      </div>
      <div class="text-container">
        <Transition name="verb-fade" mode="out-in">
          <span :key="currentVerb" class="verb-text">正在{{ currentVerb }}...</span>
        </Transition>
        <!-- 长任务超时提示 -->
        <div v-if="showLongTaskHint" class="long-task-hint">
          内容较多，可能需要更多时间，请稍候。
        </div>
      </div>
    </div>
  </Transition>
</template>

<script setup>
import { computed, ref, watch } from 'vue';
import { useLoadingStore } from '@/stores/loading';

const loadingStore = useLoadingStore();
const isLoading = computed(() => loadingStore.isLoading);
const currentVerb = computed(() => loadingStore.currentVerb);

// 长任务超时提示逻辑
const showLongTaskHint = ref(false);
let timeoutId = null;

watch(isLoading, (newVal) => {
  if (newVal) {
    // 开始加载，5秒后显示长任务提示
    timeoutId = setTimeout(() => {
      showLongTaskHint.value = true;
    }, 5000);
  } else {
    // 停止加载，清除定时器，隐藏提示
    clearTimeout(timeoutId);
    showLongTaskHint.value = false;
  }
});
</script>

<style scoped>
.loading-indicator {
  position: fixed;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  background: rgba(255, 255, 255, 0.95);
  padding: 30px 40px;
  border-radius: 12px;
  box-shadow: 0 10px 30px rgba(0, 0, 0, 0.15);
  display: flex;
  flex-direction: column;
  align-items: center;
  z-index: 9999;
  min-width: 200px;
}

.spinner-container {
  margin-bottom: 20px;
}

.spinner {
  animation: rotate 1.5s linear infinite;
}

.spinner .path {
  stroke: #4f46e5; /* 品牌色 */
  stroke-linecap: round;
  animation: dash 1.5s ease-in-out infinite;
}

.text-container {
  text-align: center;
  min-height: 30px; /* 为动词切换预留高度，避免抖动 */
}

.verb-text {
  font-size: 16px;
  color: #374151;
  font-weight: 500;
}

.long-task-hint {
  margin-top: 8px;
  font-size: 13px;
  color: #6b7280;
  font-style: italic;
}

/* 淡入淡出过渡 */
.fade-enter-active,
.fade-leave-active {
  transition: opacity 0.3s ease;
}
.fade-enter-from,
.fade-leave-to {
  opacity: 0;
}

/* 动词切换过渡 */
.verb-fade-enter-active,
.verb-fade-leave-active {
  transition: opacity 0.2s ease;
}
.verb-fade-enter-from,
.verb-fade-leave-to {
  opacity: 0;
}

/* Spinner动画 */
@keyframes rotate {
  100% {
    transform: rotate(360deg);
  }
}

@keyframes dash {
  0% {
    stroke-dasharray: 1, 150;
    stroke-dashoffset: 0;
  }
  50% {
    stroke-dasharray: 90, 150;
    stroke-dashoffset: -35;
  }
  100% {
    stroke-dasharray: 90, 150;
    stroke-dashoffset: -124;
  }
}
</style>

4.4 第四步：模拟多阶段任务与动词更新

对于导出、复杂分析等长任务，我们可以在任务执行的关键节点更新动词，让进度感更强。

假设我们有一个“深度分析文档”的API，它分阶段进行：

// 在业务逻辑中模拟多阶段处理
const handleDeepAnalyze = async () => {
  loadingStore.startLoading('ANALYSIS'); // 初始动词

  try {
    // 阶段1: 初步解析
    await api.phase1Parse();
    loadingStore.updateLoadingVerb('提取关键实体'); // 更新动词

    // 阶段2: 情感分析
    await api.phase2Sentiment();
    loadingStore.updateLoadingVerb('分析情感倾向');

    // 阶段3: 生成报告
    const report = await api.phase3GenerateReport();
    loadingStore.updateLoadingVerb('生成可视化报告');

    // 完成
    console.log('分析完成', report);
  } catch (error) {
    console.error('分析失败', error);
  } finally {
    loadingStore.stopLoading();
  }
};

通过这种方式，用户看到的提示可能是：“正在解析文档结构...” -> “正在提取关键实体...” -> “正在分析情感倾向...” -> “正在生成可视化报告...”。这种阶段性的反馈，即使没有精确的百分比进度条，也能极大缓解用户在长等待中的焦虑。

5. 避坑指南与进阶思考

5.1 常见问题与排查技巧

在实际落地过程中，你可能会遇到以下问题：

问题1：动词切换过于频繁或生硬，导致干扰而非安抚。

• 排查 ：检查动词更新的触发频率。是否在每次异步请求的微状态更新都触发了动词变化？
• 解决 ：确保动词更新只发生在有明确语义变化的“阶段”，而不是随机的或基于技术性的状态（如HTTP请求状态）。为动词切换设置最小时间间隔（如至少持续1.5秒）。

问题2：动词与后台实际任务严重不符，产生误导。

• 排查 ：检查任务类型（ taskType ）的映射逻辑。是否在调用 startLoading('SUMMARIZATION') 时，后台实际执行的是翻译任务？
• 解决 ：建立严格的任务类型枚举，并在业务代码和API调用处保持一致性。进行代码审查，确保映射正确。

问题3：在极快任务中，提示组件“闪烁”，用户体验不佳。

• 排查 ：任务完成太快（如小于200ms），导致加载组件刚出现就消失。
• 解决 ：为加载状态设置一个最小显示时间（如300ms）。可以使用一个延迟显示的技巧：

  // 在 loading store 或组件中
  let minDisplayTimer = null;
  actions: {
    async startLoading(taskType) {
      this._trueLoading = true; // 一个内部状态
      this.currentVerb = getRandomVerb(taskType);
      // 设置一个最短显示时间的延迟
      minDisplayTimer = setTimeout(() => {
        if (this._trueLoading) {
          this.isLoading = true; // 对外显示的状态
        }
      }, 300);
    },
    stopLoading() {
      this._trueLoading = false;
      clearTimeout(minDisplayTimer);
      this.isLoading = false;
    }
  }
  

问题4：动词库维护成本高，难以扩展。

• 排查 ：动词是否硬编码在多个地方？新增任务类型是否需要修改多处代码？
• 解决 ：如我们之前所做，将动词库集中化、配置化。考虑将动词列表存储在数据库或配置文件中，甚至设计一个管理后台，让产品运营人员可以方便地增删改动词，而无需开发介入。

5.2 进阶优化方向

当你已经熟练掌握了基础动态提示后，可以考虑以下进阶优化，向Claude Code的体验看齐：

1. 基于AI预测的动态动词 ：对于包含用户输入的任务，可以先用一个轻量级的本地NLP模型（或调用一个快速的意图识别API）对输入内容进行实时分析，预测任务类型，从而选择更精准的动词组。例如，用户输入“解释一下这段代码”，即使你调用的是同一个“分析”API，前端也可以显示“正在解读代码逻辑”而非通用的“正在分析”。
2. 情感化与个性化动词 ：根据用户的使用习惯或当前时间，微调动词的“情绪”。例如，在深夜时段，使用“正在挑灯夜战，为你分析...”；对于高频用户，偶尔使用一些更活泼的词汇，如“正在马力全开地生成...”。这需要建立用户画像和上下文感知系统。
3. 进度感增强 ：对于耗时非常确定的任务（如上传、下载、视频转码），将动态动词与进度条结合。动词描述当前阶段，进度条显示总体进度。例如：“正在编码视频（65%）...”。
4. 失败状态的情感化设计 ：当任务失败时，不要只显示冰冷的“错误”或“失败”。可以根据失败原因，显示更具安抚性的文案，如“网络似乎开了小差，正在重试...”、“处理遇到一点困难，请稍后再试”。并提供明确、可操作的恢复建议。

5.3 衡量效果：如何评估“等待体验”的优化？

做了这么多，如何知道体验真的变好了？除了主观感受，可以关注以下数据指标：

• 用户取消率/中途放弃率 ：在长任务等待过程中，用户点击取消或直接离开页面的比例是否下降？
• 用户满意度调研（CSAT） ：在问卷中增加关于“系统反馈清晰度”、“等待过程焦虑感”的问题。
• 会话分析 ：观察用户在等待提示出现时的行为，是安静等待，还是频繁切换标签页或进行其他操作？后者可能意味着提示未能有效安抚。
• A/B测试 ：最科学的方式。将用户随机分为两组，一组看到传统的“加载中”，另一组看到动态动词提示。对比两组在相同任务上的完成率、任务时长感知（事后调研）、以及整体的任务成功率。

从Claude Code的187个动词这个细微之处，我们看到的是一种对用户体验极致追求的工匠精神。它告诉我们，伟大的产品体验，是由无数个这样经过深思熟虑的细节构成的。它不需要高昂的成本，但需要敏锐的洞察、细腻的共情和持续的打磨。作为构建产品的人，我们的任务就是去发现这些“等待”的时刻，然后用智慧和创意，将它们从用户体验的“减分项”，转变为建立信任和好感的“加分项”。下次当你在设计一个按钮、一个表单、一个加载状态时，不妨多问自己一句：除了功能，我还能通过这个瞬间，向用户传递什么？