本页目录5
这个考点是什么
「多轮与多实例审查」考的是：当审查（无论是审代码、审 prompt、还是审模型输出质量）本身开始失真时，该用怎样的架构去修——而不是简单加大资源投入。它包含两条主线。
第一条是「拆分」，针对单遍审查跨度过大导致的注意力稀释：一次性把几十个文件、多个审查维度塞进同一遍推理，会出现深度不均（有的文件被认真看、有的敷衍带过）、遗漏明显 bug，甚至对同一段代码在不同文件里给出矛盾结论。解法是把审查拆成职责单一的多遍——比如先逐文件做本地审查，再单独跑一遍聚焦跨文件数据流的整合审查，让每一遍只承担它擅长的那部分认知负担。
第二条是「独立」，针对审查实例与被审对象共享上下文导致的偏见：同一个 session 里先生成代码再回头自查，审查实例天然带着生成时的推理惯性，容易对自己的判断高抬贵手，这就是 self-review bias。修法是换一个没有生成上下文的独立实例（或 subagent）来复查，而不是靠更清晰的验收标准去弥补。
这个考点还延伸到两类相关的系统性排查/评测方法：
-
用 ablation testing（逐段移除/替换 prompt 内容、对比输出变化）定位是 system prompt 哪一段导致了异常行为；
-
以及面对成百上千条测试用例时，用自动化单元测试（判客观/结构化输出）+ LLM-as-judge（配合 rubric，判主观质量）组合做可扩展评测，而不是逐条人工看或让模型自评。
为什么考
出题角度通常是给一个「审查失真」的症状描述（深度不均、自相矛盾、漏掉 bug、self-review 打了 looks good 却漏了逻辑错误），让考生判断根因和对应的架构修复，而不是停留在表面症状描述。
常见的干扰项思路是用「扩大 context window / 提高输出预算」「调高 temperature 加多数投票」「整段重写 prompt」「模型自评」这类看起来合理、实际不解决结构性问题的手段来诱导误选——考的是能否分清「资源不够」和「架构不对」这两类完全不同的失败模式，并选出真正改变审查流程本身的方案。
核心辨析
- 1
症状是深度不均、遗漏 bug、同一 PR 内对相同代码给出矛盾结论；根因不是 diff 装不下（context 足够），而是一次推理要同时兼顾局部细节和跨文件一致性。正确做法是拆成「逐文件本地审查」+ 单独的「跨文件整合审查」，而不是加大 context window / 输出预算，那不解决注意力分配问题。
- 2
同一 session 审查自己刚写的代码，审查实例带着生成时的推理上下文，容易固守先前判断（looks good），漏掉真实 logic error。正确架构是换一个没有生成上下文的独立 Claude 实例（或 subagent）来复查——这与「多实例」字面意义直接对应，区别于「更清晰的验收标准」这类只能部分缓解、不解决同 session 偏见的措施。
- 3
怀疑某段 system prompt 导致异常行为时，逐段移除/修改并观察输出变化，才能把「哪段文字」和「什么行为」建立因果对应。整段重写可能碰巧压掉症状但丢失定位信息；调高 temperature 只会引入采样噪声，让根因更难辨认。
- 4
面对几百条测试用例，人工全量审查是 ground truth 但不可扩展，真人 A/B 测的是线上效果而非离线评测质量，模型自评又有自我一致性偏见。可扩展组合是：结构化/客观输出用自动化单元测试判定，主观质量用 LLM-as-judge（独立评分模型 + 明确 rubric）打分。
- 5
别把「多次采样 + 多数投票」当成多实例独立审查
靠调高 temperature 制造分歧、设 2-of-3 一致性规则，既不解决单遍审查内部深度不足的问题，又会把只在一次运行中出现的真实 bug 当噪声滤掉，还多花两三倍成本。多实例独立审查要解决的是「共享上下文带来的偏见」，不是「输出的随机性」。
反模式对照
用扩大 context window 或提高输出长度来解决单遍审查深度不均、遗漏 bug 的问题。
把审查拆成逐文件本地审查 + 单独的跨文件整合审查两遍。
14 个文件的 diff 本来就装得下，问题出在一次推理要同时兼顾的维度太多、注意力分配不均，不是空间不够。
让刚写完代码的同一个 session 顺手自查一遍。
换一个没有生成上下文的独立实例或 subagent 来复查。
同 session 复查带着自己生成时的判断惯性，容易对自己的决定高抬贵手，漏掉真实逻辑错误。
怀疑某段 system prompt 有问题时，靠整段重写或调高 temperature 来排查。
做 ablation testing：逐段移除/替换 prompt 内容并对比输出变化。
整段重写可能碰巧压掉症状但丢失定位信息，调温只会引入采样噪声，两者都无法把问题精确定位到具体段落。
用同一模型给自己的输出打分（self-scoring）作为大规模评测手段。
客观/结构化输出用自动化单元测试判定，主观质量用独立的 LLM-as-judge 配合明确 rubric 打分。
模型自评有自我一致性偏见，规模化评测需要独立评分者和可复现的判分标准，而不是被评对象自己兼任裁判。