让每条 AI 反馈都有证据状态和责任所有者
AI 反馈需要避免过度确定，因为一句流畅的话可能混合三种不同状态：当前输入直接支持的内容、只有条件成立时才成立的推断、产品暂时无法解决的未知。它也应避免无法兑现的承诺，因为“我会处理好”没有说明谁拥有动作、哪个外部服务必须回应、承诺何时失效，以及失败后界面显示什么。这是产品反馈措辞和交互设计问题，不是教用户如何核验一条回答。可用七字段契约约束反馈：证据状态、推断条件、未知项、用户或系统可控动作、外部依赖、承诺所有者与时限及失败终态、过期时间。确定语气只能跟随可观察状态，不能反过来制造状态。
先分开证据、条件推断、未知与动作状态
先标状态，再写顺畅文案。“当前支持”表示主张能对应某个已命名的当前输入、系统记录或完成事件；“条件推断”必须写出仍需成立的前提；“未知”指出缺少的输入、不可用来源或未解决冲突，不擅自补空；“动作状态”只能在系统观察到转换时写请求、排队、发出、收到回执、完成或失败。NIST 生成式 AI Profile 指出，错误内容也可能被自信地呈现，因此语气不能替代状态信号。还要拆开原子主张：日历记录可能已经创建，但外部邀请仍未收到回应，不能合并成“一切已安排好”。每张反馈卡都应暴露支持来源类别和最近检查时间。
把承诺拆成所有者、依赖和终态
承诺只有在所有者能够执行动作并观察完成时才成立。明确下一步归谁：本产品、用户、具名外部服务，还是系统之外的人。随后写前置条件、真实期限或估计、再次检查的节点，以及完成、拒绝、过期、失败、仍在等待等终态。“我会让对方明天回复”没有可控所有者；“本应用已发出邀请，对方回复不受本应用控制，周二后可再次查看”则把控制和依赖分开。Microsoft HAX 建议清楚说明能力与表现边界。不能让第一人称助手文案悄悄把外部人的义务转给模型。没有任何主体能拥有结果时，应把它写成选项或可能状态，而不是承诺。
让条件与过期时间紧贴反馈
通用免责声明不能修复一个无条件的“完成”标签。把决定性条件放在句子旁，例如“依据当前已连接日历”“如果场馆时间未改变”或“尚未收到外部回执”。时间包含三个不同字段：证据时间表示何时观察到支持；承诺节点表示所有者何时行动或复查；过期时间表示这句话何时不得继续作为当前状态复用。外部数据、权限、应用版本与用户编辑会各自变化；依赖断开或过期时，状态应降级，而不是保留昨天的确定措辞。OECD 透明度指南支持按情境说明输入与限制。历史文案可以留在日志中，但必须有清楚日期，不能继续冒充当前事实。
给出可控下一步，不暗示结果
有用的不确定反馈仍能提供边界明确的动作。Google PAIR 建议说明缺少什么并给出前进路径：到检查点后重试、重新连接来源、编辑输入、切换手动路径、取消请求，或继续保持未知。按钮名称描述动作本身，而非许诺后果：“发送申请”而不是“获得批准”，“检查空位”而不是“预订成功”，“请求澄清”而不是“立即解决”。反馈控件也要说明真实影响。如果纠正只改变本次显示，就不要说系统已经学会；如果它进入稍后审查队列，就写清范围和时间。仅显示“谢谢反馈”也不能暗示底层模型已即时更新。
用五个依赖断裂情境检查自信文案
使用无害测试数据观察界面。先在正向反馈后断开外部来源；再撤销必要权限；让外部回执超过检查节点仍不返回；提供与首个输入冲突的第二输入；最后在输出过期后重新打开。每轮都检查标题、徽章、通知、摘要和后续生成文案是否一起降级。失败状态不能继续保留“已完成”“确定”“始终”或产品已不再拥有的将来时。可用动作也必须匹配状态：重新连接、编辑、重试、取消、手动路径或保持未知。不要探测隐藏防护或使用危险内容。记录输入、依赖、时间戳、预期终态、实际措辞和版本，使失败可以复现。
用七字段契约作为发布门槛
逐个审查重要反馈组件：证据状态、条件、未知、可控动作、外部依赖、所有者/时限/失败、过期。每句话只对应一个状态，每项承诺都有真正能执行的所有者，依赖可见，过期触发降级，五个负向情境都进入诚实终态，才可通过。若视觉自信超过证据、把“已发出”推成“已完成”、把估计写成期限、把用户反馈说成模型即时更新，或让陈旧输出继续有效，就不能通过。文案审查还要与事件状态一起做；后端若只有成功布尔值，换形容词无法补出等待、失败与过期。此门槛评估产品反馈，核验某条具体回答仍由 170 的独立用户流程承接。
常见问题
确定语气都不合适吗？
不是。范围、来源和时间明确的可观察完成状态，可以使用确定表述。
可以显示预计时间吗？
可以，但必须标为预计，说明依据和复查节点，并定义依赖未回应时显示什么。
所有未知都应显示为错误吗？
不应。有些事项只是尚未解决，应保持未知，并只提供真正能缩小缺口的动作。