前提确定后再问下一轮问题

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

使用场景

通知系统需要决定保留期和清理方式。教学当前资料尚未明确允许保留多久，供应商限额则可从已有配置与文档查到。清理周期依赖保留决定，不应该在同一轮问题里默默假设其答案。

具体做法

列出决定与事实依赖，先自行查可发现事实。每轮只问前提已确定的必要决定，把互不依赖的问题合并，待实际回答后重算下一轮。一个资料探索未完成只阻碍其下游，不停止所有独立问题。前沿为空时核对整体范围，防止漏掉分支。

反例

同时让用户选保留 30 天、数据库和每天清理，实际保留规则尚未确认；用户没回答也按预选项实施。

改进写法

先查可发现的教学供应商限额与现有配置，再解决通知用途和必要保留政策；这轮不要求选择依赖保留期的清理频率。收到实际保留决定后再安排清理问题，记录依赖与答案。独立问题可先推进，未定下游留待后轮；不把 30 天或预选项当已确认政策。

为什么这样改

顺序不当的问题会携带隐藏前提，用户看似选了清理周期，实际还没决定保留条件。依赖就绪的轮次让每个问题都可在当前信息下回答，减少相互矛盾选择。

如何验证

示意第一轮解决用途/保留依据，后轮才选与其相符的清理方式；如果保留答案改变，相关下游重新核对。

检查可查限额没有被问成用户知识，尚未回答的决定没有标完成。前沿空须有完整范围核对，而非因问题表漏项。

适用边界

规则由实际产品与合规负责人提供，本例不建议具体法定期限。依赖树会变化，需要重算；必要答案待取得时不能靠推荐或沉默替代，也不必为已定事实重新开问答。