feedback-states

反馈状态

每个耗时操作都有相同的几种状态，而大多数应用只设计了顺利完成时的状态。你的工作是选定一项功能，找出它可能处于的每种状态，并明确说明每种状态：用户会看到什么、状态如何变化、用户有什么感受，以及界面会显示什么文案。60fps 库提供了真实参考。

一次只处理一项功能或一个屏幕：保存、发送、购买、搜索，或某个屏幕如何加载数据。如果用户没有指定，请询问具体是哪一项。第 5 步之前不要更改代码。

1. 根据代码梳理触发方式和状态

阅读该功能的视图和执行操作的代码（视图模型、async 函数、网络调用），以及应用已有的任何共享加载、错误或数据新鲜度视图和修饰器。

先列出哪些操作会启动任务，以及每种操作从哪些位置启动（按钮和单元格都可能添加同一项，而两个入口正是竞态出现的原因）。用户操作（点击“保存”）是一种触发方式。屏幕加载通常有多种触发方式：打开屏幕、返回应用、计时器、切换筛选条件、下拉刷新、“刷新”或“重试”按钮。不同触发方式对应的反馈各不相同，所以要分别记录。

然后列出该功能实际可能达到的所有状态，而不只是它目前绘制出来的状态：

• 进行中，暂无内容可显示：首次加载，或用户操作正在进行。记录可能耗时多久：不到一秒、几秒，还是更久。
• 进行中，屏幕上已有已保存数据：在加载新数据时，显示之前已有的内容。对任何数据显示界面来说，这是最重要的状态。
• 成功：操作成功了。是否有下一步，还是用户留在当前页面？
• 部分成功：主要操作成功，但附带操作失败（已保存，但未能导出）。
• 空状态：操作成功，但没有内容可显示。
• 错误：操作失败。可能出现哪些错误（离线、服务器、验证、权限）？屏幕上是否仍显示已保存的数据？
• 重试：用户重试时会发生什么？再次失败时呢？
• 中断：操作进行时，用户离开、将应用切到后台、切换筛选条件或再次点击。

无法重新设计的系统屏幕（照片选择器、相机、分享表单）中的状态不在范围内：要设计它关闭后的后续表现。

如果操作会替换或删除内容，请检查代码，确认旧数据在操作失败时仍会保留（是否在新数据安全保存前就已删除？）。数据丢失比缺少任何状态都糟糕。

对于每种状态，记录对应的文件和行号，以及用户目前会看到什么。指出永远不会执行的反馈代码（例如，已经关闭的工作表中的覆盖层），以便将其移除。还要检查文案中的每个承诺是否都能在代码中兑现：“联网后我们会刷新”就需要有监控网络状态的机制。如果不运行应用就无法确定某个状态的表现，请写上“未验证”。

如果某个状态已经处理得很好，标记为 保留，然后继续。报告应聚焦于缺漏。

2. 决定每种状态

让整个流程保持平静、快捷。以下规则几乎适用于所有情况：

• 触觉反馈回应触摸操作。 只有当成功、错误和确认触觉反馈回应用户刚刚执行的操作（保存、刷新、重试）时才使用，即使处理花了几秒钟也一样。绝不用于自行开始的加载（打开屏幕、计时器、返回应用时），也绝不为同一个事件触发两次触觉反馈：搜索成功路径中会执行的所有触觉调用，跨文件检查，因为视图和单元格往往都会各添加一次。
• 处理中：约 400 ms 以内，不显示微调器（闪一下会像故障）；但对于用户主动请求的加载，仍需用小提示表明操作已执行。时间更长时，在原位置、针对正在处理的对象显示进度，不要用全屏遮罩阻挡操作。超过约 3 秒后，说明正在进行什么操作。
• 屏幕上已有保存的数据：加载新数据时，继续让已有数据保持可见且清晰易读，并以低调的提示表明正在更新。绝不要清空已有数据的屏幕。
• 成功：在用户触碰的控件上就地确认，然后不再打扰用户。
• 空状态：说明为空的原因以及接下来可以做什么。静态插图没问题；循环播放的插图通常只会造成干扰。
• 错误：保留用户输入或选择，并让已保存的数据继续显示。用通俗易懂的话说明出了什么问题以及该怎么做。如果错误是对点击操作的回应，错误触觉反馈加上该控件短暂轻微地抖动一下就够了（约 6 个点、摆动 3 次、持续 0.3 秒）。如果用户没有点击，则不要触发触觉反馈或抖动：平静地提示即可。
• 部分成功：先确认成功的部分，再低调地说明未成功的部分。对于大部分已成功的操作，绝不要显示标题为失败的警告。
• 重试：如果没有重试方式（例如提示“请重试”的警告），就添加一个，并将用户输入保存在内存中，这样重试时就不必从头开始。重试时，按钮应显示处理中状态。再次失败时，提示内容必须与第一次不同（“仍处于离线状态。已于 14:05 重试。”），否则会让人觉得点击没有效果。
• 中断：处理停止后，绝不要让微调器继续运行，也绝不要让较晚返回的结果覆盖更新的结果。

保持与应用语气一致，并优先复用应用已有的共享视图和修饰符，而不是提出新的实现方式。每种动效都需要提供 Reduce Motion 版本（交叉淡入淡出，或不使用动效）。

3. 查找参考

只搜索你要修改且需要动效的状态，通常是成功和重试，有时也包括处理中。跳过标记为 Keep 的状态以及不需要动效的状态。

调用 60fps_search_shots，用通俗的文字描述动效、时机和语气（“保存后平静地在原位置显示勾选标记”、“重试时按钮显示一个小微调器”）。不要以 widget 或 settings 之类的界面名称开头。请自行根据标题、摘要、intensity 和 mood 判断结果；这些分数几乎无法区分匹配度高低。该库擅长庆祝动效和按钮反馈，但缺少平静的错误提示、重试、离线通知和加载骨架屏：对于这些情况，最多搜索一次，并预期以“没有接近的匹配项”加上文字描述动效作为答案。

4. 报告

先用一到三句话列出问题，按严重程度从高到低排列（触觉反馈错误或承诺失效的问题比缺少动画更严重）。然后提供一张表，按用户遇到各状态的顺序排列：

状态	位置	当前情况	建议操作	触觉反馈	文案	参考动效

对于已经正确的状态，使用 Keep；对于不需要动效的状态，在“参考动效”列填写“无需”。如果应用已有将错误映射为文案的逻辑，则复用已有错误消息。在表格下方，先列出任何数据丢失风险，再列出应移除的无效反馈代码。接着用一行说明 Reduce Motion 版本，并询问是否要实现。

5. 按需构建

明确建模状态（使用包含你所列情况的枚举），而不是一组布尔值，以避免出现不可能的组合。仅针对用户选中的镜头获取 60fps_get_motion_breakdown 和 60fps_get_motion_code，并调整它们的时机，而不是外观。 沿用用户的设计系统。确保代码能够编译。

用词直白：句子要短，用常见词。绝不要使用 em dash 或 en dash。

不适用于

Android、Flutter、React Native 或 Web。对于应用整体上应该在哪里添加动画，请使用 find-animation-opportunities。