## 任务目标
请为业务操作补齐完整的反馈与恢复设计。覆盖从操作触发到最终结果的真实过程。
交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。
## 输入信息（选填）
两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。
反馈设计范围：
页面与状态资料：
## 信息不完整时
先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。
### 优先确认
- 追踪按钮触发、请求发送、任务受理、查询或回调到最终结果的实际路径。
- 核对 loading、提示、弹窗及错误处理的现有逻辑，检查页面切换、账号失效与部分失败。
- 查取消、重试、幂等键、请求标识和结果查询接口是否真实存在，区分能力说明与未实现建议。
### 可采用的默认处理
- 有明确结果才显示成功，超时或回调缺失默认保留结果待确认，不自动重发非幂等写操作。
- 按影响范围选择行内或页面反馈，只有确需用户决定时使用对话框，不为每次成功重复打断操作。
- 无真实进度时使用处理中的状态描述；错误保留有用上下文与安全的恢复入口，不用自动跑满的百分比。
### 必须有依据的事项
- 服务端是否已经生效、是否可重试或取消无法确定时，不能替系统承诺撤销、重新提交或完成；继续设计结果待确认及查询路径。
- 错误码缺少业务含义或同码含义冲突时，不能臆造具体原因，需确认影响数据及可恢复动作。
只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。
### 资料仍不足时的交付
- 无接口实现时交付操作状态矩阵、逐条中文反馈及恢复流程，明确结果查询和幂等能力的接入要求。
- 只有错误记录时交付可确认错误的文案与恢复建议，并将无法判断的状态单列，不声称故障已修复。
## 执行要求
反馈应及时、适度，过程与结果分别表达；异常分类和恢复动作必须匹配系统实际能力。
1. 逐个记录操作的触发位置、影响对象、耗时依据、成功判据和数据刷新方式。没有服务端最终结果时区分已接收、处理中与已完成，禁止点击后立即伪装成功。
2. 列出空闲、提交中、处理中、成功、失败、部分成功、中断、结果未知或待核实等适用状态，指定每种状态的可信来源和退出条件。不存在的后端状态不能直接当作现有能力。
3. 结合影响范围与用户必须采取的行动选择行内提示、页面提示、轻提示、结果页或对话框。成功后内容已明显变化时减少重复提醒，重要失败应保留可找回的信息。
4. 为每种错误写清楚发生了什么、对已填写或已处理数据有什么影响、现在可以做什么。网络异常、权限不足、规则冲突、记录不存在和服务异常分别处理。
5. 设计重试、刷新、取消、继续编辑和查看详情入口，注明可用条件、操作后果和上下文保留。重复请求可能产生重复业务记录时必须列出幂等条件。
6. 检查多任务同时执行、页面切换、刷新、账号失效和部分项目失败的表现。进度只显示真实可得的进度，不能使用自动跑满的百分比造成办理完成错觉。
## 交付与验收
输出：操作状态矩阵、反馈组件选择表、逐条中文文案、恢复流程、接口或任务能力缺口、验收场景。文案以业务信息和下一步动作为中心，避免责备用户。
验收：已知终态有可信依据；结果未知时保留原请求标识，通过查询、回调或对账确认，确认前不自动重发非幂等操作；重要错误不丢失；重试不会默认制造重复记录；部分成功能定位失败对象；不存在无依据进度和频繁无用弹窗。
信息边界：仅有错误码而无业务含义时保留待映射项；不猜测故障根因，不声称错误已经修复，不在用户文案中泄露内部日志、凭据或敏感数据。
### 本条完成检查
- 每种终态有可信来源，结果未知保留请求标识并有确认办法。
- 反馈能够说明数据影响与下一步，重试和取消条件真实，部分失败可定位到对象。
- 关键异常、多任务和页面切换均有处理规则，不丢失重要错误或生成假进度。
按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。
## 参考资料与适用边界
参考来源（核验于 2026-09-08）：
- [Ant Design 反馈](https://ant.design/docs/spec/feedback-cn/)
