一次误解的代价：模型的精度差距，最终算在谁头上

我有一个验证模型解释精不精确的固定动作：挑一个自己已经想清楚答案的技术问题去问，然后把它给出的解释压缩成一句我自己的陈述句，跟已知答案对一遍。这次拿去测的问题是 JavaScript 生成器里 yield 和 yield* 的区别，问了 Gemini 和 Claude 各一遍。

选这类问题做测试是有理由的：出错的时候我能立刻分辨，不用等到后面真吃了亏才发现。但这也提醒我该往前想一步——如果这次不是我特意挑来验证的问题，而是我真正陌生的领域，这套自检根本没有依据可以对照，错误会悄无声息地被我当成新知识收下。这句话本身值得停一下：只要理解停留在模糊的「哦懂了」状态，它就不会撞上「这句话对不对」这个问题；把理解压成一句陈述句，其实就是给自己做了一次断言（assertion）——跟写单元测试是同一件事，不判定，错误就潜伏着。

代价不是免费的

人脑的理解不是一张可以随便重写的纸，是神经元连接的物理状态。这类「错误理解一旦编码，纠正它比从没编码过它更贵」的现象，在学习科学里有名字，叫迷思概念的持续干扰（misconception persistence）——经典例子是学生学完牛顿力学之后，错误的「冲力」直觉在负荷升高时还会复发。我说不清具体是哪几个神经元、怎么重设，那是神经科学的实证问题，不是我能替自己打包票的细节。但现象本身是有据可查的：纠正一次错误理解，不是把旧内容删掉换新内容那么干净，旧的会残留、会在后续理解里冒出来添乱。

这次因为是我自己已经想清楚的问题，代价被我提前拦掉了。但换成一个我真正陌生的领域，情况会反过来：我会带着一个错误理解往前走好几步，直到某次撞上矛盾才发现要回头，而那时候要纠正的就不只是这一个知识点，是建立在它上面的所有后续判断。

两个模型，同一个问题

Claude 的回答，是从 JavaScript 语言规范本身讲起的：生成器函数才能暂停、恢复，yield* 是委托给另一个迭代器、把值原样转发、直到内层 return 才算完——然后用这套机制分别解释了 redux-saga 里的协程用法和 Python 风格的流式输出，说这是同一套底层机制上长出的两种不同解释。

Gemini 的回答，是从一个具体的库（Effect，一个 TypeScript 的函数式副作用库）讲起的，而且讲错了一个具体事实：

yield* 在原生的 Effect 3.x 早期版本中偶尔能看到，但在现代 Effect 中，官方已经全面推荐直接用 yield 来处理单个 Effect。

我去查了 Effect 的官方文档，“Using Generators” 这一节的原话是「Use yield* to handle effects」¹——推荐方向和 Gemini 说的正好相反。这不是「两种同样合理的写法之争」，是编出了一个关于版本演进的具体事实，而这个事实是假的。

真正的区别，不是知道得多不多

这两份回答的差距，第一眼看像是「Claude 更懂 JS」。但我觉得更准确的说法是：它们从两种不同稳定性的材料里取答案。Claude 锚定在 ECMAScript 生成器协议上——这是几十年没变过、被成千上万份文档反复印证的不变量，训练数据里几乎不存在互相矛盾的说法。Gemini 锚定在一个具体库的具体版本约定上——这是易变、低频、长尾的事实，新旧文档本来就可能打架，模型很容易把两份互相矛盾的印象揉成一个自信但错误的「版本演进叙事」。

真正值钱的能力，不是「分得清 yield 和 yield*」这么具体，是分得清「我正要说的这句话，是稳定的机制，还是易变的版本细节」，并且让语气跟着这个判断打折扣。Gemini 的问题不是不知道，是用了讲协议一样笃定的语气去讲一件它其实没有把握的事。语气不随材料的可靠性变化，是比事实错误本身更贵的毛病——因为读的人没有别的信号可以拿来提防。

评估在漏记什么

站内之前写过《评估不是打分会》，说语义正确、结果悄悄错掉是最不能接受的一类错误。这次的例子是它的一个具体样本：Gemini 的回答结构完整、语气自信、读起来像对的，这种「看起来对」的错误比「一眼假」的错误贵得多。

还有一层评估容易漏掉的：很多评估流程是「多轮之后答对了就算过」——如果我不是提前有答案、而是顺着 Gemini 的解释往下问，最后被它自己或者被我另外求证纠正过来，按这种记分方式，这轮对话最终是「正确」的。但从人这边的成本看，这不是同一件事：同一个「最终答对」的分数，背后可能是完全不同的人力成本，取决于模型是第一次就命中，还是先让人带着错误往前走了几步。评估要是只看终局，就把这笔债从账本上抹掉了。

两件能直接用的事

第一件是验证方法本身：挑自己已经有把握的问题去测模型，把它的解释压成一句陈述句去对答案——这比拿一堆随机问题去感受「好像挺懂」要可靠得多，而且成本极低。

第二件是给想测一个模型靠不靠谱的人：找一个有稳定不变量、也有易变版本细节的问题去问它——问题本身就带着两种材料，看它是不是把两者的语气分开处理，遇到易变的部分有没有主动降低确定性、甚至提示「这个建议先去核对当前版本」。这比拿一堆题去算分数更能看出问题。

一句坦白的结论

以我自己这段时间在这类需要精度的场景下的使用经验，Claude 和 GPT 的旗舰模型总体上更可靠——但我要把这句话的证据基础说清楚：这次的对比只有 Claude 和 Gemini 两家，不是一次系统测评，GPT 那部分是我更早、更零散的个人经验，不是这篇文章测出来的。

还有一件事必须摆在台面上：这篇文章是我和 Claude 一起写的，Claude 正是被拿来对比、被推荐的那一方。这个利益冲突我没法假装不存在——所以我把它写在这里，而不是悄悄藏起来；上面那条「挑已知问题去测」的方法，也是留给你不用信我这句话，自己验一遍的路。

Footnotes

1. Using Generators | Effect Documentation，“Key steps to follow when using Effect.gen” 一节。 ↩