AI 不是搜索引擎:让它把代码依据、推断和待核实分开

你正在修一个登录问题。

移动端用户登录以后，又被跳回登录页。你把错误日志、最近一次 PR diff、失败的测试输出，还有 README 里关于 auth 模块的说明，一起交给 AI Agent，让它帮你判断该从哪里查起。

AI 很快给出一个看起来像样的判断，问题大概率出在 token refresh 逻辑。它还建议把 refreshToken 的过期时间改长，并在请求失败时自动重试一次。

但真正动手之前，先停一下。

日志里确实出现了 401 和 token expired，这算依据。至于 refreshToken 过期时间太短，只是 AI 根据日志做的推断。“改长过期时间”和“失败后自动重试”，牵扯到项目配置、安全策略、测试覆盖和线上行为，不能因为 AI 说得完整，就直接写进代码。

上一篇我们讲过，不要把整个项目一股脑丢给 AI，要先把上下文材料分清楚。今天再往前走一步，材料分清以后，AI 给出来的回答也要再分清楚。

分成三类就够了，代码依据、模型推断、待核实项。

一段回答里，先分出依据和猜测

AI 的技术回答经常有一个毛病，它把不同可信度的信息写在同一段话里。

比如这一段：

日志中的 token expired 表明当前请求使用了过期 token。问题可能出在 refresh token 逻辑没有正确触发。建议把 refresh token 的有效期延长，并在接口返回 401 时自动重试一次。

第一句来自日志，能回头核对。第二句听起来合理，但只是推断。第三句已经是修改建议，而且涉及安全和业务策略。三句话连在一起，读起来像一个完整结论；真要写代码，却不能按同一个可信度处理。

很多人正是在这里被带偏。AI 不一定在胡说，它只是没有把“材料里明明写着的”“它根据材料猜出来的”“还需要人去确认的”分开说。读者如果不分，最后就会把推断当事实，把建议当结论。

这一步先不用追问哪个模型更可靠，也不用把话题拉到“AI 幻觉”的机制上。拿到 AI 的技术回答以后，先做一件小事，把它放进一张三栏表。

每句话归类，再决定动作

这张表够用。

AI 回答里的句子	类型	判断依据	下一步动作	采纳状态
日志里出现 `token expired`	代码依据	错误日志原文	回看日志上下文	可作为事实
可能是 refresh token 没有正确触发	模型推断	与 `401` 和 `token expired` 有关，但材料未证明	查刷新流程和测试	暂不采纳
建议接口 401 后自动重试一次	待核实项	涉及安全策略和业务行为	查现有重试策略、跑测试	核实后再定

第一栏“代码依据”，指能回到源材料核对的东西。它可以来自文件名、函数名、日志片段、测试输出、PR diff，也可以来自官方文档里的原句。判断标准很简单：如果把原材料打开，能不能找到这句话的出处。

第二栏“模型推断”，是 AI 根据材料做出的判断。推断不等于错。看到 401、token expired 和失败测试以后，怀疑 refresh 流程确实很自然；问题在于，这个怀疑还没有被代码路径、配置或测试结果证实。

第三栏“待核实项”，是需要你继续做动作的地方。比如查线上 token TTL，跑一遍 auth-refresh.spec.ts，看失败时刷新接口有没有发出去，确认项目是否允许 401 自动重试。这些事 AI 可以提醒，但不能替你完成。

表格看起来有点笨，好处倒很实在，它让 AI 的回答从“顺不顺”转向“有没有出处”。

提问时，先让 AI 标注依据

很多时候，AI 会分析；麻烦出在我们一上来就让它给结论。

“这个 bug 怎么修？”这句话太容易把模型推到方案模式。它会努力给一个完整答案，而完整答案里最容易混进没有验证过的假设。

更稳的问法，是先让它做标注：

请分析下面的技术材料，但不要直接给最终结论。

先把你的回答分成三类：

【代码依据】

只写材料里明确出现的信息。尽量引用原文、文件名、函数名、日志片段、测试名或文档段落。

【模型推断】

写你根据材料做出的判断。每条都说明它依赖哪些依据，并保留不确定性。

【待核实项】

写我需要继续检查的内容。每条都给一个具体动作，例如查看某个配置、运行某个测试、查官方文档、确认业务规则。

最后再给一个谨慎结论：哪些可以先采纳，哪些不能直接采纳。

技术材料如下：

<<<在这里粘贴日志、README、PR diff 或测试输出>>>

拿前面的登录问题举例，材料可以很短：

ERROR auth middleware: request failed with 401

message: token expired

path: /api/projects/42

test: auth-refresh.spec.ts failed at "retries once after refresh"

这几行能直接说明的事情很有限：请求失败，状态码是 401，日志里有 token expired，失败测试和 refresh 行为有关。至于是不是 token 有效期太短、是不是前端没有重试、是不是后端刷新接口没有调用，都是推断方向。

把这些方向列出来当然有用，但它们必须留在“推断”和“待核实项”里，不能换个说法混进“代码依据”。

文档、PR、测试，各有各的边界

错误日志只是入口。真正做项目时，AI 经常要同时读 README、API 文档、PR diff 和测试输出。它们的边界不一样。

看文档时，最容易出问题的是“合理脑补”。文档只写了：

Authentication:

Requests must include an Authorization header:

Authorization: Bearer <token>

AI 却可能接着写：你应该在 .env 中配置 API_KEY，并在服务启动时读取。

这句话不一定坏。把密钥放进环境变量，确实是常见做法。但它不是这段文档明确写出来的事实。这时只能把 Authorization: Bearer <token> 当作文档依据；环境变量是工程建议，变量名、注入方式、SDK 有没有别的认证写法，都要回到项目和官方文档里核实。

看 PR diff 时，能直接看到的是代码变化，不一定能看到业务意图。比如：

- if (user.role === "admin") {

+ if (user.hasPermission("delete_users")) {

await deleteUser(targetUserId);

}

AI 可以准确说出条件判断从角色检查变成了权限检查，这是依据。它也可以推断细粒度权限可能比单一角色更灵活。可如果它直接说“这个改动更安全”，就已经越过了材料。权限系统是否覆盖 super admin、普通管理员会不会被误拦、删除操作有没有审计记录、测试有没有覆盖边界情况，这些都不是 diff 本身能证明的。

看测试输出时也一样：

FAIL auth-refresh.spec.ts

Expected refreshToken to be called once

Received: 0

这段输出只证明一件事，测试期望 refreshToken 被调用一次，实际没有调用。它不能单独证明根因。可能是代码没有进入刷新分支，也可能是 mock 配错了，可能是测试根本没有触发 401，还可能是某个 feature flag 关掉了刷新逻辑。测试输出很硬，但硬的是“观察到的现象”，不是“最终原因”。

把这三类场景放在一起看，规则其实相同，能从材料里指认出来的，放依据；顺着材料推出来的，放推断；要动手查的，放待核实。

已有答案时，逐条追证据

如果 AI 已经给过一段完整回答，也不用重问一遍。可以让它复核自己，或者用另一个模型复核它：

请复核下面这段 AI 技术回答。

任务：

1. 把回答里的每个关键结论拆出来。

2. 标注它属于【代码依据】【模型推断】还是【待核实项】。

3. 对每个【代码依据】，指出它需要回到哪段材料核对。

4. 对每个【模型推断】，说明它还缺少什么证据。

5. 对每个【待核实项】，给出一个最小验证动作。

6. 如果有结论找不到任何材料支撑，请标为“不能直接采纳”。

原始材料：

<<<粘贴材料>>>

AI 回答：

<<<粘贴 AI 回答>>>

这里有个细节：不要只问“这个回答对不对”。“对不对”太大，模型很容易再给一段同样流畅的评价。把它要求成“逐条结论、逐条分类、逐条给验证动作”，输出才会变得可检查。

几份官方材料的侧重点不同，Anthropic 谈降低幻觉时强调让模型承认不知道、引用材料并撤回没有支撑的说法，OpenAI 的提示工程文档提到给模型可参考的材料，GitHub 和 Claude Code 文档又把代码任务落到能力边界、测试、构建和人工核验上。放回到前面的练习里，意思很朴素，别只看 AI 最后一两句结论，要看它能不能把依据摆出来。

不过，这些方法只能降低风险，不能取消验收。权限、支付、数据删除、线上配置、安全边界、依赖升级这些场景，错一次就可能改坏真实系统；碰到这类问题，AI 的建议最好先留在候选列表里，由人看过证据、跑过测试，再决定要不要入代码。低风险的小改动另说，也要让验证动作先跑起来。

最后抽查三条结论

找一段最近用 AI 问过的技术问题，不需要复杂。一个报错、一段 README、一个 PR diff，或者一段测试输出都可以。

把原始材料和 AI 回答放进上面的复核 prompt。然后只抽查三条：

一条“代码依据”：回到原材料里看，是否真的能找到对应文本。
一条“模型推断”：看它依赖的材料够不够，是否还有别的解释。
一条“待核实项”：做一个最小动作，打开文件、跑一个测试、查一段官方文档，或者确认一个配置。

做完以后，记录一句话：这次 AI 回答里，哪一条可以直接用，哪一条只是猜得合理，哪一条差点误导你。例如，日志里的 token expired 可以直接引用；token 有效期太短只是猜测；401 自动重试差点让我绕开安全策略。

这个练习不难，但能改变一个习惯。以后 AI 给出技术方案时，先别急着复制，也别只凭“看起来专业”判断它是否可靠。把回答分成依据、推断和待核实项，再决定下一步。

AI 可以帮人少走弯路，但在技术问题里，最后要落到一件事上，方向能不能被日志、代码、测试或文档重新验证。

资料来源

Anthropic: Reduce hallucinations

Claude Code: Best practices for Claude Code

GitHub Docs: Responsible use of GitHub Copilot Chat

OpenAI: Prompt engineering