产品经理问要不要保留一个功能，两个助手分别给出删除和保留的建议，而且都很有道理。继续找第三个投票，并不能解释它们究竟看了不同用户、不同时间段，还是在同一事实下作了不同取舍。
先做论点与证据对照表往往最快，不必为了两份意见引入系统。需要多个助手持续研究时，可以连接同一组获准资料，减少资料入口的差异；EasyNet 不会因为组织了调用就成为事实裁判。
资料查询函数应接受明确问题范围，返回原始来源定位、数据时间和定义。分析助手再分别给出结论、假设和不确定项。Context 可保留入口，但证据结构、对照工具以及缺失来源检查需要另外建设。
先比较“留存”到底指什么，再比较参与计算的人群和窗口，最后才看价值判断。相同数据下仍有不同选择时，可以把分歧留给负责人；不应把一个助手无法访问的数据默默替换为空，从而制造假冲突。
每个调用者只能读取获准材料，查询结果应包含足够核对的引用而非整份客户数据。调用记录只能说明请求经过哪里，不能证明模型真的正确使用了所有来源；重要推论需要返回原文和计算继续检查。
选一项可核实的争议，把两边统一到同一数据版本，再看结论是否还相反。能指出最早分叉的定义或假设，已经比新增一份流畅意见更有帮助；找不到证据时，保留未确认比编出共识更诚实。
- 01
两份建议
保留与删除同一功能
- 02
对齐依据
定义、人群、时间与数据版
- 03
保留真实分歧
证据相同仍不同，由负责人判断
找到最先不一致的依据
比较两份合成分析的条件，不判断哪位助手更正确。
本地示例 · python
a = {"metric": "day-7 retention", "cohort": "all signups", "version": "2026-08"}
b = {"metric": "day-30 retention", "cohort": "all signups", "version": "2026-08"}
differences = [key for key in a if a[key] != b[key]]
assert differences == ["metric"]
print(differences)预期结果：输出 ['metric']；先统一7日和30日留存的定义再比较建议。
接入时的检查项
- 每个关键结论是否有能打开的证据定位。
- 换成同一数据和定义后，原分歧是否仍然存在。
- 无法核实的判断是否仍被清楚标注。