几位同事分别研究竞争产品，交来几十个链接和摘要。接手者要决定下一步，却不知道哪项功能实际试过，哪项只是宣传页的说法。资料数量增加了，确定哪些事实可以据此行动的工作却还没有开始。
一张共享研究表配合评审通常就能改善这件事。只有资料和查询工具散在不同环境、多个助手会反复使用时，才值得接出共同查询入口。连接来源不提高来源本身的可信程度。
研究团队可以维护证据条目：具体命题、观察日期、产品版本、核实方法及原始定位。查询函数按问题返回支持和反对材料，EasyNet 负责接入，Context 保留引用；条目模型、状态更新和审核责任需要由团队建设。
阅读官方文档、实际操作成功和二手转述应分别记录。某个输入在一个版本成功，不扩写成所有输入都支持；未测范围留在结论旁边。来源正文和实验材料仍按权限取得，接手者无权查看时应看见缺口。
可信度不应从网站域名或模型语气自动生成。由核实者对条目负责，冲突证据共同保留；来源改变之后重新检查。调用日志能帮忙定位取数动作，却不能替代研究者说明自己实际测了什么。
请另一位同事只拿这些条目继续一个决定，看看能否明确指出尚缺的那次验证。如果他不必把每个链接从头读完才能分辨事实和猜测，交接才保存了研究工作的进度，而不只是转移了一堆资料。
- 01
提出具体命题
某版是否支持指定输入
- 02
附核实过程
文档与操作证据不混同
- 03
交接下一次验证
保留冲突与未测项
分开已测试与只读到的说法
在合成研究条目中分类核实方法；该分类不自动判断产品事实。
本地示例 · python
entries = [
{"claim": "CSV import", "method": "hands-on", "scope": "3 rows"},
{"claim": "large file import", "method": "vendor-docs", "scope": "not tested"},
]
tested = [e for e in entries if e["method"] == "hands-on"]
assert len(tested) == 1 and tested[0]["scope"] == "3 rows"
print(tested)预期结果：仅3行CSV试验进入实测；大文件仍未测。
接入时的检查项
- 每项已核实结论是否有相应检查证据。
- 相互矛盾的来源是否都能被看到。
- 接手者是否能明确下一步要验证什么。