跨模型评审Cross-model peer review是让编码代理coding agent生成的代码接受另一个不同模型独立评审的质量控制方式。它的出发点很直接生成代码的模型和检查代码的模型如果是同一个那么模型的训练偏好、上下文窗口取舍和推理盲区会同时影响生成与检查两个环节最终得到一个“自说自话”的通过结论。换成另一个模型来做评审等于在生成链路外面引入一个独立视角用不同训练分布和不同推理习惯去校验同一个产出物。这个思路在真实工程里解决的具体问题包括AI 生成的代码存在边界条件遗漏、错误地使用某个 API、假设了不存在的函数、忽略了异常分支而生成模型在自我回顾时往往维持原来的判断。跨模型评审不是简单地把同一个 prompt 发给两个模型而是要让两个模型承担不同角色、使用不同上下文、产出不同类型的结论。这也是接下来要重点拆解的地方角色如何拆分协议如何定义结果如何仲裁以及整个链路如何在成本可控的前提下落地。1. 为什么需要跨模型评审单模型自审为什么靠不住1.1 编码代理的输出需要独立质检真实场景中编码代理已经能完成从需求理解到代码生成的完整链路接到任务、读取相关文件、调用工具、生成补丁、运行测试。但“能完成任务”不等于“产出可信”。一个编码代理最典型的失败模式不是写不出代码而是写出的代码看起来结构完整却在边界条件、异常处理、依赖假设或并发语义上存在问题。这些问题的共同特点是它们在正常路径下不引发报错只有在特定输入、特定环境或特定组合条件下才会暴露。如果这个产出物直接进到代码仓库问题就会转嫁到下游人工 Code Review 的人、持续集成流水线、以及生产运行时。因此生成之后的质检环节不是可选项。传统工程里质检靠人肉 Code Review 和自动化测试当生成代码的单元从“函数”变成“整个 Pull Request”质检也需要有对应的自动化手段。跨模型评审就是一种把人工评审的“独立视角”复制到自动化链路中的方案。1.2 同模型自审的三个盲区让同一个模型先生成代码、再检查代码表面上省事实际有三个结构性盲区。第一个盲区是偏好一致性。同一个模型对“什么样的代码算好”有一套固定偏好。生成时会按这套偏好组织代码审查时也会按同一套偏好判断等于用一把尺子量自己写的东西很容易忽略这套偏好之外的缺陷。第二个盲区是知识边界一致。如果模型对某个 API 的记忆是错误的生成阶段会错误地调用它审查阶段同样会认为这个调用是合理的。知识错在源头自审无法纠正源头。第三个盲区是上下文惯性。生成过程中模型已经看过自己写出的代码再让它去审查它的注意力会被生成时的推理路径引导倾向于在原有思路上补充而不是提出相反的判断。这一点在长上下文中更明显。这三个盲区决定了自审只能发现“水平线内的笔误”很难发现“思考方式本身的问题”。而跨模型评审恰恰针对这个问题设计。1.3 跨模型评审的适用边界跨模型评审并不是万能的它有自己的适用边界。适用场景包括编码代理产出关键模块、需要快速但高质量地把 AI 生成代码纳入人工评审之前、需要评估多个候选方案、以及需要在自动化流水线里给代码质量打一个可追踪的评分。不太适用的场景包括代码量非常小且明确、评审本身带来的延迟和成本已经超过代码本身的开发成本、以及模型差异带来的评审噪声大于信号。后一种情况在跨模型评审初期很容易出现评审模型给出的意见本身不够稳定反而让人无法判断代码到底有没有问题。所以落地跨模型评审之前先要回答三个问题评审的是代码还是方案评审结果要不要阻塞合入以及评审失败之后是重新生成还是人工介入。这三个问题的答案决定了整个编排逻辑。2. 跨模型评审链路怎么搭从任务拆解到评审协议2.1 链路总览一条完整的跨模型评审链路可以拆成六个环节。任务接收接收用户的编码需求并把需求整理成结构化任务描述。上下文准备收集相关文件、依赖信息、代码风格规范和已有测试。代码生成生成模型根据任务描述和上下文输出代码或补丁。测试执行如果项目里有自动化测试先跑测试把结果作为评审输入。跨模型评审另一个模型基于任务描述、生成代码、测试结果和评审维度输出结构化意见。结果仲裁根据评审意见决定通过、重新生成还是人工介入。这里的核心设计原则是“评审模型拿到的信息要完整但职责要单一”。完整指的是任务描述、生成代码、测试报错、相关文件都要给它单一指的是它只负责输出问题清单、严重级别和建议不负责修改代码。职责分开的好处是评审结果容易解析、容易统计也避免模型在“我是评审者”和“我是修改者”之间切换时模糊边界。2.2 评审协议字段设计跨模型评审要落地先把协议定下来。评审协议指的是评审模型输入和输出的格式约定。输入侧至少要包含以下字段task_description原始任务描述尽量与生成模型收到的描述一致或更详细。generated_code待评审的代码最好包含文件路径。context相关文件内容、依赖版本、编译或测试日志。review_dimensions评审维度列表控制评审模型的注意力范围。output_schema要求评审模型按指定 JSON 结构输出方便下游解析。输出侧建议统一为结构化 JSON避免让评审模型输出自由文本。结构化输出便于做阈值判断、统计失败率、留档审计。一个最小输出结构可以参考{ review_id: review_20250601_001, verdict: pass, score: 82, issues: [ { severity: high, category: boundary_condition, file: src/order.py, line: 45, title: 折扣计算未处理负数金额, detail: 当 amount 为负数时discount_rate 会被错误地应用到负数上。, suggestion: 在进入折扣逻辑前增加金额合法性校验。 } ], summary: 整体逻辑清晰存在一个高优先级边界条件缺陷修复后可通过评审。 }这里的关键点有两个。第一个是 verdict 和 score 同时存在verdict 用于自动化决策score 用于比较不同候选方案。第二个是 issues 数组里每条意见必须包含 severity 和 category否则后续统计和筛选无法自动化。2.3 评审结果怎么被消费评审结果需要被下游消费才有价值。按照消费方式不同可以把评审结果分成三类。第一类是阻塞类。verdict 为 fail 时阻塞代码合入或阻塞后续流程触发一次重新生成或通知人工评审。第二类是提示类。verdict 为 pass_with_warning 时不阻塞合入但把 issues 记录到评审报告里人工可以在合入前决定是否处理。第三类是统计类。无论 verdict 是什么所有 issues 都应该进入数据库或日志用于后续分析哪个模型作为评审者时发现的问题最多、哪类缺陷最常出现、生成模型的修复成功率是多少。很多团队只实现了阻塞判断忽略了统计类消费。这会导致跨模型评审始终停留在“跑了一遍”的状态无法沉淀成团队自己的质量基线。3. 最小可运行实现用 Python 编排生成与评审3.1 环境准备与依赖为了让方案可复现下面给出一组最小实现。它不依赖任何特定厂商 SDK而是通过统一接入层调用不同模型后端这样可以把“生成模型”和“评审模型”随意替换成不同的模型。前置环境假设Python 3.10 或更高版本。两个可调用的模型后端分别记为 model_generator 和 model_reviewer。一个支持补全的 HTTP 接口或者可以使用各厂商的 Python SDK。如果原始项目还没有确定模型供应商建议先把模型接入层抽象出来不要在生成逻辑里直接写死某个 SDK。最小实现只需要 requests 库pip install requests真实项目中可能还需要各家模型服务商的 SDK但最小实现里用 requests 统一发 HTTP 请求就足够说明编排逻辑。3.2 定义统一模型接入层统一接入层的职责是把“调用哪个模型”和“如何解析响应”封装起来让上层代码只关心 model_name 和 messages。import requests import json import os from typing import List, Dict def call_model(model_name: str, messages: List[Dict], temperature: float 0.2) - str: 统一调用不同模型后端返回文本内容。 实际项目中根据 model_name 路由到不同供应商的 API。 endpoint os.getenv(LLM_ENDPOINT, https://api.example.com/v1/chat/completions) api_key os.getenv(LLM_API_KEY, ) # 不同后端的鉴权字段不同这里用最常见的 Authorization 示例 headers { Authorization: fBearer {api_key}, Content-Type: application/json, } payload { model: model_name, messages: messages, temperature: temperature, } resp requests.post(endpoint, headersheaders, jsonpayload, timeout120) resp.raise_for_status() data resp.json() # 不同供应商的返回结构不同这里假设统一取 choices[0].message.content return data[choices][0][message][content]这个接入层的关键是 model_name 作为第一路由维度temperature 作为可调参数。评审任务建议 temperature 调低让输出更稳定生成任务可以适当调高给模型更多探索空间。3.3 实现生成代理生成代理负责把任务描述转成代码。它的输入是 task_description 和 context输出是代码文本。def generate_code(model_name: str, task_description: str, context: str) - str: prompt f 你是一名资深后端工程师。请根据下面的任务描述和相关上下文编写代码。 要求 1. 给出文件路径和完整代码。 2. 代码要包含必要的异常处理。 3. 如果有边界条件请在注释中说明处理方式。 任务描述 {task_description} 相关上下文 {context} messages [ {role: system, content: 你是编码代理负责生成可用于生产环境的代码。}, {role: user, content: prompt}, ] return call_model(model_namemodel_name, messagesmessages, temperature0.4)生成阶段要避免让模型自己进入评审角色。prompt 里只要求生成不要求“同时说明潜在问题”目的是让两步职责边界先分开。3.4 实现评审代理评审代理是跨模型评审的核心。它接收任务描述、生成代码、上下文输出结构化 JSON。def review_code(reviewer_model: str, task_description: str, generated_code: str, context: str, dimensions: List[str]) - dict: prompt f 你是独立的代码评审员。你需要从评审视角检查下面这段代码而不是修改它。 请严格按照 JSON 结构输出不要输出 JSON 以外的内容。 评审维度 {json.dumps(dimensions, ensure_asciiFalse)} 任务描述 {task_description} 待评审代码 {generated_code} 相关上下文 {context} 输出格式 {{ verdict: pass 或 fail, score: 0, issues: [ {{ severity: high 或 medium 或 low, category: 缺陷类别, file: 文件名, line: 行号, title: 问题标题, detail: 问题说明, suggestion: 修复建议 }} ], summary: 评审总结 }} messages [ {role: system, content: 你是独立代码评审员只负责评审不负责修改代码。}, {role: user, content: prompt}, ] raw_text call_model(model_namereviewer_model, messagesmessages, temperature0.1) return parse_review_result(raw_text) def parse_review_result(raw_text: str) - dict: 解析评审模型返回的 JSON。如果模型输出了多余文本这里要尽量容错。 text raw_text.strip() if text.startswith(): text text.strip() if text.startswith(json): text text[4:].strip() return json.loads(text)评审 prompt 里最关键的是“输出格式”约束。很多模型在长 prompt 下会返回包含解释文本的 JSONparse_review_result 里的容错逻辑要保留否则下游解析会频繁失败。3.5 主流程生成、评审、是否继续主体逻辑是把生成、评审和裁决串起来。先定义裁决函数def decide(verdict: str, score: int) - str: 返回: pass / regenerate / human_review if verdict pass and score 75: return pass if verdict fail and score 60: return regenerate return human_review主流程def run_pipeline(task_description: str, context: str, max_rounds: int 2): generator_model model_generator reviewer_model model_reviewer current_code review_result {} for round_index in range(1, max_rounds 1): print(f第 {round_index} 轮生成) current_code generate_code(generator_model, task_description, context) print(f第 {round_index} 轮评审) dimensions [correctness, boundary_condition, error_handling, code_style] review_result review_code(reviewer_model, task_description, current_code, context, dimensions) decision decide(review_result.get(verdict, fail), review_result.get(score, 0)) print(f评审结论: {review_result.get(verdict)}, 得分: {review_result.get(score)}) print(f决策: {decision}) if decision pass: print(评审通过输出代码) return current_code, review_result if decision regenerate and round_index max_rounds: print(需要重新生成进入下一轮) continue print(需要人工介入) break return current_code, review_result if __name__ __main__: task 实现一个函数 compute_discount(amount, discount_rate)要求金额为 0 或负数时抛出 ValueError。 ctx 项目使用 Python 3.10不使用第三方依赖。 code, review run_pipeline(task, ctx) print(最终代码:, code)这个主流程只是为了演示编排逻辑。真实项目里生成代码后通常还要跑编译和测试把测试结果拼进 context 再交给评审模型效果会明显好于直接评审一段没有执行验证的代码。4. 评审维度与裁决策略跨模型评审不是“让模型挑毛病”4.1 评审维度怎么选评审维度决定了评审模型的注意力范围。维度太少评审会漏掉问题维度太多评审会输出大量非关键意见噪声盖过信号。常用维度如下表维度评审关注点典型问题示例correctness逻辑正确性和功能匹配需求是取最小值代码却实现了取最大值boundary_condition边界值、空值、极端输入列表为空、金额为负数、字符串超长error_handling异常处理和失败路径数据库连接失败时没有回滚security安全风险SQL 拼接、缺少权限校验、敏感信息落地日志performance时间复杂度和资源占用循环内重复查询数据库api_usageAPI 用法是否正确调用了不存在的参数或方法code_style风格统一和可读性命名不规范、魔法数字过多不同团队应该维护自己的维度清单。初始可以从 4 到 6 个维度开始运行一段时间后根据数据调整如果某个维度的意见总是空的说明该维度要么不适用于当前代码库要么评审模型没有足够上下文判断该维度。4.2 评分和阈值评分需要和 verdict 分开理解。verdict 是二值或三值结论score 是连续分数。两者结合的策略可以这样设计score 区间verdict自动化决策场景说明90-100pass直接通过低风险变更人工可以只看 summary75-89pass通过但留痕有 low/medium 意见人工抽查60-74pass_with_warning人工复核存在 medium 或 high 意见0-59fail重新生成或人工介入存在高危缺陷不能自动合入阈值不是从论文里抄来的而是要通过历史数据调整。建议前两周先记录所有评审结果不做强阻塞两周后根据“评审为 fail 但人工复核后认为没问题”的比例来校准阈值。4.3 两个模型结论不一致时怎么处理跨模型评审中生成模型说“代码没问题”评审模型说“存在缺陷”这是正常现象也是这套机制的价值所在。但评审模型之间也可能出现不一致如果同一段代码由两个不同的评审模型分别评审一个给出 pass一个给出 fail这时候需要第三层仲裁。仲裁策略按成本从低到高有三种。第一种是规则仲裁。两个评审都 pass 才 pass任一 fail 就 fail。这种策略最严格适合安全敏感场景。第二种是加权仲裁。给每个评审模型配置一个历史准确率权重按加权得分判断。比如模型 A 历史准确率 0.8模型 B 历史准确率 0.6最终得分按比例计算。适合需要平滑处理评审噪声的场景。第三种是仲裁模型仲裁。当两个评审结论冲突时再调用第三个模型把前两个评审意见作为输入让它给出最终结论。成本最高但处理复杂冲突时效果最好。在最小实现阶段建议先用规则仲裁。等积累了足够的评审数据再升级为加权或仲裁模型。5. 运行验证用一个容易暴露问题的最小用例检查评审链路5.1 设计一个能触发边界的验证用例写完编排逻辑之后最忌讳的是直接拿真实业务需求来试。真实需求复杂、上下文大、评价标准不明确一旦评审结果不符合预期很难定位是编排问题、prompt 问题还是模型能力问题。正确做法是先构造一个“小而能暴露问题”的验证用例。好的验证用例需要满足三个条件需求足够明确参与判断的人能快速给出正确实现。自带边界条件天然能检验生成模型是否遗漏。可以在几秒内人工验证结果不需要额外工具。比如任务描述实现一个函数 parse_config(raw: str) - dict把多行keyvalue格式的配置文本解析成字典。空行跳过重复 key 后者覆盖前者raw 为空串时返回空字典raw 为 None 时也返回空字典。这个任务看起来简单但包含多个独立边界点空行、重复 key、空字符串、None 输入、value 中可能包含等号。生成模型大概率能写出主逻辑但容易在 None 输入处理或 value 包含等号这两个点上出问题。评审模型如果能发现这些问题说明评审链路真正生效了。在运行前先准备一组人工确定的“应通过”和“应拒绝”的代码样本。应通过的样本是完整正确处理全部边界的实现应拒绝的样本是漏掉 None 处理的实现。用这两组样本分别跑评审观察评审结论是否符合预期这比看一两次随机运行更可靠。5.2 观察输出链路而不是只看最终代码运行 run_pipeline 后不要只盯最终代码而是把每一轮的输出都记录下来分析。预期中比较理想的输出第 1 轮生成 第 1 轮评审 评审结论: fail, 得分: 55 决策: regenerate 第 2 轮生成 第 2 轮评审 评审结论: pass, 得分: 82 决策: pass这个结果说明三件事第一轮生成存在缺陷且被评审模型捕获触发重新生成第二轮生成修复了缺陷并通过评审最终得分说明代码质量处于可接受范围。但更常见的情况有两种。情况一第一轮评审直接 pass此时要手动检查生成代码是否真的覆盖了所有边界。如果代码实际上漏掉了 None 分支说明评审模型存在盲区。情况二两轮都 fail此时要判断是生成模型能力不足还是评审标准过严可以通过切换 reviewer_model 或调低阈值来区分。5.3 评审链路验证清单运行验证结束后建议按以下清单逐项确认。每一项都是独立的故障点不能想当然地认为只要链路跑通就全部通过。检查项检查方式通过标准评审模型是否收到完整任务描述打印审查输入 prompt包含任务、代码、上下文、维度评审输出是否稳定解析连续运行 3 次3 次均能解析为 JSON明显缺陷样本是否被拒绝手工构造漏掉 None 的代码verdict 为 fail正确样本是否被通过手工构造完整实现verdict 为 pass生成模型是否在修复后通过运行两轮主流程第二轮通过或明确转人工评审模型是否真的与生成模型不同检查配置model_generator 和 model_reviewer 不同如果第 3 项或第 4 项不通过问题基本出在评审 prompt 或评审维度设置上而不是出在编排代码上。这时优先检查评审模型是否被 prompt 引导成“修改建议者”而不是“判定者”以及维度是否覆盖正确性。6. 常见问题与排查路径6.1 评审结果不稳定现象同一段代码连续评审两次一次 pass 一次 fail或者 score 波动超过 20 分。排查顺序temperature 是否设置过高。评审任务建议 temperature 在 0 到 0.2 之间。prompt 是否包含随机性来源。例如在评审 prompt 里要求模型“自由发挥”或“提供多条建议”会放大输出波动。上下文是否包含不稳定内容。相邻两次评审如果 context 不同结果波动是正常的。是否有缓存层。生产环境应该对相同输入的评审结果做缓存既降本又提稳。6.2 评审模型总是通过现象无论代码是否存在明显问题verdict 都是 pass。可能原因评审模型与生成模型是同一个模型或同系列模型