AI 搜索核验是写技术教程前很值得做的一步。回答后面附了几个链接，看起来可信，却可能引用旧版文档、转述文章，甚至只支持结论的一部分。本文提供“问题拆解、来源检索、逐条核对、记录缺口”的流程，适合工具安装、功能比较和教程选题，不依赖某一家搜索产品。
一、把大问题拆成可核实的小问题
不要直接问“哪个 AI 最好”。先写具体场景，例如“Windows 本地运行，资料不上传云端，能处理中文短文本”。再拆成系统支持、模型运行位置、功能要求、资源需求和许可条款几个问题。
每个问题都应有可以检查的对象。“支持 Windows”可以查系统文档；“速度很快”则需要特定硬件和任务数据，不能仅凭产品介绍判断。
请帮我寻找关于[工具与具体功能]的资料。
优先官网、项目仓库和正式文档。
按事实点列出：主张、来源链接、来源日期或版本、适用条件、尚未确认内容。
区分产品官方说明与独立实测；没有实测不要写性能结论。
不要只给搜索摘要，请指出需要我打开核对的原文位置。
二、先找一手资料，再补使用经验
下载地址优先官网和官方仓库，安装参数优先当前文档，故障可补充项目 issue 中与版本相符的记录。社区经验能帮助排错，但一条评论不等于普遍结论。
搜索词可以由“项目名＋功能名＋官方域名”构成。不要为了得到满意答案不断改问法，直到 AI 给出想听的结论；应当保留找不到证据的状态。
三、逐个打开来源核对
| 检查点 | 需要问自己的问题 |
|---|---|
| 来源身份 | 真的是官方域名或项目所有者吗？ |
| 日期与版本 | 讲的是当前版本还是历史版本？ |
| 适用范围 | 系统、地区、账号与套餐一致吗？ |
| 支持程度 | 原文支持整句结论，还是只支持其中一部分？ |
| 可复现性 | 有明确步骤、配置或测试条件吗？ |
尤其要看“可能”“仅在”“默认”“不支持”这些限定词。模型把“支持通过额外工具完成”简化成“原生支持”，会直接误导后续教程。
四、建立一份来源台账
事实编号：F01
待确认主张：工具可以在Windows本地处理文本
来源：官方系统说明页面
核对日期：填写实际日期
原文位置：系统要求/运行方式小节
适用条件：具体系统与版本
结论：已支持 / 部分支持 / 未确认
备注：下载模型需联网，与推理是否联网分开说明
这个例子强调两件事：安装时联网与运行时联网不同；网页界面在本机与模型运行在本机也不同。把事实拆细之后，就不容易被一句“全本地”带偏。
五、遇到冲突怎么处理
先比较时间、版本和适用条件，再考虑来源权威性。官方文档更新后，旧教程可能仍在搜索排名前面；新发布的文章也可能只是转载旧信息，不能只按日期排序。
两份来源仍冲突时，在稿件里写清已确认的部分，未确认的参数暂不写成操作前提。必要时自己做最小测试，记录环境和结果，而不是把 AI 的解释当成实测。
六、把搜索结果转成自己的教程
先跑通步骤，再按自己的操作顺序写。保留必要官方链接，说明每个链接用于下载、配置还是排错。不要把搜索摘要逐段改写凑成文章，也不要把参考资料中的性能数字写成自己的电脑测得。
发布前抽查所有外链：是否打开正确页面，有没有跳到登录、404 或旧版本；模型生成的 URL 可能看起来合理却实际不存在。
七、常见问题与排错
引用很多是不是更可信？
不一定。多个网站可能转引同一份旧材料。优先看来源是否独立、是否直接支持事实。
官方没写免费额度怎么办？
不要猜。写“以账号当前显示为准”，并把额度与功能可用性分开描述；不把短期活动当长期条件。
搜索不到答案，AI 却很肯定怎么办？
要求它指出原文依据；无法给出时将该项降为未确认，再设计实际测试或删去不必要的结论。
资料阅读可以结合PDF 引用整理，写作前则看事实约束改写。怎样检验回答可参考 OpenAI 评测实践。
Pingback: AI 改写文章：保留事实和个人风格，别把润色变成编造