先把这笔账搁这：整件事里最贵的不是幻觉，是它扫完仓库，漏掉那个后来才要你命的 bug，然后你问它“这地方有问题吗”，它回你一句“看起来正确”。那个 webhook 处理器就是现成的账单。这篇我就从它入手，把账摊开。
Info Inlet 在 dev.to 那篇你大概看过。他把整个仓库——路由、数据库迁移、配置、一个多年没动的 utils.ts——全塞进一个上下文窗口够大的模型里，让它 review。模型还真把系统架构梳理得比给新员工写的入职文档还清楚。这活儿干得漂亮，我不抬杠。它说认证走单个中间件、两个服务不该共享同一张表、支付 webhook 和注册写了 users 表不同位置——都对。省了多少时间？不好说，但肯定不少。这笔账是正的。
紧接着它丢出带编号的问题清单。到这里一切还都挺美。然后毛病来了：清单里混着一些根本不存在的东西。第 7 项说某个函数有 SQL 注入——那个函数压根不存在。第 9 项说某个端点缺认证检查，但检查就在旁边文件里，写得明明白白。最要命的是，它说真话跟说假话的时候，排版、语气、修复建议都一个样。你看到的是一条条看着靠谱的发现，实际真假掺一起，你自己分不出来。这就是 finder 的天然属性——它只给候选，不给判断。
你以为幻觉是什么？不是一句“它骗了你”就完了。幻觉有价格，价格就是你被迫逐条去验。十条发现里混两条假的，你验十条。二十条里混四条假的，你验二十条。更别提你喂给它的上下文越足，它越会用你真实的函数名、文件名来包装虚构故事。这成本不是恒定的，是指数往上爬。你给它一个文件，它顶多编个假函数名，你一眼看穿。你给它整个仓库，它就用你真实函数名编一个发生在你函数上的假漏洞，你得打开那个文件、读那个函数、琢磨它说的对不对，才敢下结论。这才是幻觉的标签价。说句扫兴的，上下文窗口越大，它编得越像，你验得越久——这买卖越往后越不划算。
但注意，幻觉还是小事。真正的灾难出在另一个地方。
那个 webhook 处理器。它先向支付提供商确认“收到事件，没问题”，然后才开始尝试写数据库。看出问题没有？如果这两个动作之间进程挂了——或者数据库这会儿正好抽风抛个异常——支付那头就认为这事处理完了，不会重试。钱呢？钱没了。日志里连个 error 都没有，你根本不知道有付款丢了。最讽刺的是，当作者直接去问模型“这个 webhook 处理器有没有问题”，模型说看起来没问题，还夸了 try/catch 写得好，建议加个注释。加个注释！你听到没有？它把一个会静默丢款的 bug 说成“看起来正确”。这不是幻觉——幻觉至少你还能说你被骗了。这是它当了一个它根本当不起的角色：witness。
这就说到 finder 和 witness 的区分了。这个提法我认为是这个月最值钱的一个词。Finder 给候选，漏了没事，错了也没事，因为后面总有人去验。Witness 不一样，witness 是拿信誉背书“这东西能上线”。你把一个 finder 硬放在 witness 的位置上，它不是能力不行，是职责错位。出事儿了，你找谁说理去？找不到，你只能自己把账吞了。这在商业上叫什么？叫你把一个只会报线索的实习生，提拔成了签字的合伙人。然后他签字说“看起来正确”，你把产品上了线，三个月后你发现有一笔款永远没到账。这个账算谁的？算你自己的。
插一句不相干的，回正题。评论区那个 xiangc 有句话我特别认：大模型只能分析静态文本，生产故障发生在分布式状态转换中间，靠读代码是读不出来的。他提的是故障注入和集成测试。作者的回复更清楚一步：先用模型枚举可能在哪些异步步骤之间注入故障，然后让混沌测试来裁决。这就是把 finder 放回它该在的位置——它枚举，测试来断案。Finder 提名，行为测试来判决。这个分工是对的。
为什么这个分工这么重要？因为模型能看见的，只有你代码里写下来的东西。它看不见支付提供商那头的行为。它不知道那家支付服务在收到确认之后就不再重试。这不是它不够聪明，是这些信息根本不在你的仓库里。作者说得很直白：整仓上下文能提高发现问题的数量，但对判断力没帮助。这句话我直接抄下来，因为太对了。判断一个 webhook 有没有问题，你得先知道外面那头是怎么干的，这不在任何上下文窗口里能解决。得给系统装一个外部视角，一根行为测试的探针。
那怎么办？我看下来就三条，多了没有。
头一条，模型只当 finder。它给线索，你去验证。它说“第 7 项有 SQL 注入”，你去打开那个函数看一圈，发现根本没这个函数——好，这条划掉。它说“这个 webhook 处理器看起来正确”，你不能信，你去查它到底有没有先确认后写库。验证不是可选项，是你用它之前就得认的规矩。
再一条，认证变更必须独立。能让代码上线的那个人或那条测试路径，不能跟提候选问题的模型共用同一个脑子。作者说不同模型家族、对抗性提示、实际运行测试，这些都是手段，核心是独立先验——你得有一个不受模型影响的东西来判断模型说得对不对。像 Nan Nan 在评论区说的，拿 Search Console 和 PageSpeed 当外部探针，揪出一个 177KB 的第三方脚本拖慢首页，那些外部探针就是独立先验，它们量的是真实世界里的行为，不是代码里写的字。
最后一条，接缝缺陷只能靠行为测试。什么是接缝缺陷？就是你的系统和外部系统交界的地方，支付 webhook、注册与支付的竞态、任何跨越进程边界的异步步骤。这些地方光读代码没用，因为你要知道的是系统实际运行中会发生什么，不是你代码里写的意图是什么。测试办法也直接：在确认和持久化之间把进程打挂，然后看支付提供商到底会不会重试。这测的是真实世界，不是测代码。
把这笔账再算一回：你把模型当 finder，它给你十条候选，你花半小时抓出两条真的——这个 ROI 是正的。你把模型当 witness，它说“看起来正确”，你省了验证的时间——你省下的每一分钟，都是在给你的静默丢款存保险金。哪个划算？你自己算。
这笔账我一开始算反了。我以前觉得 AI review 最大的问题是幻觉，是它编的那些假漏洞。后来才发现漏了一项：被它放过的那个真漏洞，比它编出来的十个假漏洞都贵。假漏洞消耗你的时间，真漏洞消耗你的钱。时间没了你还知道去哪了，钱没了你连个 error 都看不到。这是最狠的地方。
所以结账：AI 代码 review 这玩意儿，用要用，但只能放在 finder 的位置上。谁把它当 witness，谁就是在自掏腰包替它交认知税——而且这笔税不是明着收的，是藏在那句“看起来正确”里的。那个 webhook 处理器要是上了生产，静默丢三个月款，你能拍着胸脯说这不是我的问题吗？不能。因为是你让一个 finder 当了 witness。账本上记得住。这笔账，你自己算。咱下篇见。