在合适的节点征求反馈

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

用户搜索已知方法却没有结果，你已修正查询规则，想确认是否解决了这次失败。教学信息是查询词 retry、预期方法 P15、原结果空。反馈需要围绕这个问题，不在每次搜索后打断用户做满意度调查。

具体做法

先完成可自行检查的修复，再在反馈能影响下一动作的节点呈现具体结果与简短问题。提供查询、预期和实际结果，方便用户指出仍有的偏差。本例同一会话最多征求一次；反馈自愿，未回答不推断满意，也不停止独立技术检查。

反例

每次用户搜索后立即要求填写满意度调查。无回答就反复追问，并把沉默记为满意。

改进写法

修复上述 retry 搜索后先展示实际结果与技术检查。若需要用户确认，提供简短反馈入口：查询 retry，原为空，预期 P15，当前显示结果；请指出仍不符合的地方。本会话最多询问一次，只记录用户自愿提供的反馈，不把沉默当满意或反复打断。反馈含义与修复验证分开记录。

为什么这样改

具体失败信息让用户可以评估变化，而不是回答宽泛满意度。等待合适节点减少打断，技术检查与主观反馈分开则不会把一次回答变成所有行为的质量证明。

如何验证

教学检查应看到修复结果先呈现、一次具体反馈请求和没有重复催问。用户说“仍找不到 P15”时保留这个问题并继续核对；未回答保持反馈未知。

技术测试通过不等于用户认可，用户认可也不替代技术检查。这里没有自动发送错误报告。

适用边界

一次上限是本例安排，频率由任务和渠道决定。必要的需求澄清不属于满意度调查；不要为了少问把阻塞下一动作的信息省掉。原文未确认，反馈记录遵守授权与隐私范围。