大模型很擅长把零散信息整理成流畅的答案，也正因为表达过于自然，我们容易把“说得像真的”误认为“已经证实”。我现在使用这类工具时，会把生成结果当成一份待审阅的草稿：它可以帮我打开思路、列出线索，却不能替我完成最后的事实判断。
先分清事实与判断
核查之前，我会先把回答拆成两类。第一类是可以验证的事实，例如发布日期、产品参数、政策条文、论文结论和某个命令的具体行为；第二类是判断，例如“这个框架更适合小团队”或“某项技术未来会流行”。
事实应该能够落到明确证据上，判断则需要说明依据和适用条件。混在一起时，模型常会把经验推测写成确定结论。一个简单办法是追问：“请把这段回答中的可核查事实逐条列出，并把观点单独标注。”这不能保证结果正确，但能让后续检查更有目标。
要求来源，但不要只看链接
遇到数字、时间和引用，我通常要求模型给出资料名称、发布机构、发布日期和对应段落，而不只是丢出几个链接。链接本身也可能失效、指向二手转载，甚至根本不存在，所以仍要亲自打开确认。
如果回答声称“某报告显示效率提升了 40%”，我会继续检查样本规模、测试条件、统计口径和报告是谁资助的。离开这些上下文，一个看似精确的数字可能没有实际参考价值。对于无法提供可定位出处的说法，我会暂时标为“未证实”，而不是顺手写进文章。
回到一手资料
事实核查最有效的一步，是尽量回到信息最初出现的地方。产品能力看官方文档和更新日志，法律政策看政府网站的正式文件，学术观点看论文原文，开源项目则看仓库、版本说明和问题记录。
搜索摘要、媒体报道和社区讨论适合发现线索，却不适合作为所有结论的终点。二手内容在转述时常会省略限制条件。例如“支持某功能”可能只是测试版支持，“免费使用”也可能附带额度或地区限制。找到原文后，还要核对版本和日期，避免用旧资料解释已经变化的产品。
用独立来源交叉验证
重要信息最好由两个或更多相互独立的来源支持。这里的“独立”很关键：十篇文章都引用同一条未经验证的消息，并不等于得到了十次确认。我会优先组合不同类型的证据，例如官方公告加实际测试、论文原文加同行评议、政策文件加主管部门解读。
如果来源之间存在冲突，不必急着选择更顺眼的一方。先检查发布时间、适用地区、软件版本和统计口径，很多矛盾其实来自条件不同。仍然无法解释时，就在文章中保留分歧，并明确写出目前能确认到哪一步。
代码和命令必须实际运行
技术问题尤其不能只凭文字判断。模型生成的代码可能调用不存在的接口，也可能语法正确却在边界条件下失败。我会在隔离环境中安装指定版本，准备最小输入，实际运行代码，并记录错误信息和输出结果。涉及性能时，还要重复测试，避免把一次偶然结果当成结论。
对于会删除文件、修改数据库或请求线上服务的命令，先阅读参数说明，再换成测试目录、测试数据或只读模式。能运行不代表适合生产环境，真正可靠的答案还应考虑权限、异常处理、安全风险和版本差异。
给结论标注不确定性
最后，我习惯给信息做一个简单分级：“已确认”表示有一手资料或可重复实验支持；“较可信”表示多个独立来源一致，但仍缺少直接证据；“待验证”表示只有单一来源或模型推断；“未知”则是当前资料不足。
这种标记看起来保守，却能防止草稿中的猜测在多次复制后变成所谓事实。大模型可以大幅提高收集线索和整理材料的速度，但它无法保证每句话都正确。把来源、验证步骤和不确定性留下来，才是让回答真正可用的关键。