把一段 Git Diff 交给模型再附上一句“请认真审查”当然可能得到有价值的评论。问题是文件选错、生成物混入、上下文超预算、评论落到不存在的行号这些都不是“模型再聪明一点”就该解决的问题。更稳妥的做法是把 AI 代码审查拆成两层确定性代码固定范围、规则、预算和评论位置模型只负责需要语义理解的缺陷判断。本文用一个脱敏 TypeScript 小实验验证这条分工不调用模型也不把 AI 评论当作合并批准。一次审查其实有五个不同问题“审查代码”听起来像一个动作工程上至少包含五步确定 Git 范围、选择文件、匹配规则、判断缺陷、定位评论。只有第四步天然需要模型的语义能力其余步骤更适合写成可测试的程序。步骤更合适的执行者原因解析提交或分支范围确定性代码输入和输出都可重复排除依赖、生成物和二进制确定性代码规则明确错误会浪费预算按路径与语言匹配规则确定性代码需要稳定、可审计判断业务缺陷与上下文风险模型需要语义理解和跨行推理校验评论文件与 Diff 行号确定性代码不能让模型伪造位置OpenCodeReview 的公开架构也采用类似分工先处理 Git Diff、文件筛选、规则匹配和分文件任务再让 Agent 生成候选评论最后做评论过滤与行号重定位。本文不是对它的复刻只把这条可复用的架构原则做成一个更小的实验。先把审查输入压成一个确定性计划模型不应该直接面对“整个仓库”。审查入口先产出一个ReviewPlan哪些文件入选、命中了哪些规则、哪些文件被跳过以及跳过原因。exporttypeReviewPlan{readonlyselected:readonlySelectedFile[]readonlyskipped:readonly{readonlypath:stringreadonlyreason:excluded_path|file_budget|line_budget|no_rule}[]}这里保留跳过原因不只是为了日志好看。审查范围本身就是交付证据如果一个支付文件因预算不足没进入模型上游不能把“模型没有发现问题”解释成“该文件没有问题”。路径过滤要发生在模型调用之前dist/、node_modules/、vendor/和明确的生成目录通常不应进入模型。规则最好使用仓库配置中的 include / exclude而不是让 Prompt 临时猜哪些文件重要。constEXCLUDED_PREFIXES[dist/,node_modules/,vendor/,generated/]asconstif(EXCLUDED_PREFIXES.some((prefix)file.path.startsWith(prefix))){skipped.push({path:file.path,reason:excluded_path})continue}真实项目还应处理二进制、Lockfile、压缩产物、迁移文件和超大文件。关键不是列出一份万能黑名单而是让范围规则进入版本控制并能在 CI 中回归。规则匹配与预算必须可解释同一个文件可能同时命中 TypeScript 通用规则和支付目录规则。实验把所有命中规则都挂到文件上再按文件数和新增行数预算决定是否入选。跳过原因应如何解释能否等价为“没有问题”excluded_path配置明确排除不能no_rule没有匹配审查规则不能file_budget文件数超过本轮上限不能line_budget新增行数超过上下文预算不能construleIdsrules.filter((rule)matchesRule(file.path,rule)).map((rule)rule.id)if(usedChangedLinesfile.addedLines.lengthbudget.maxChangedLines){skipped.push({path:file.path,reason:line_budget})continue}预算耗尽时不应静默截断。更合理的策略是输出部分完成状态并让 CI 或人工决定拆分审查、提高预算还是继续依赖其他门禁。模型评论必须重新锚定到 Diff模型返回“第 30 行有问题”时不能直接把评论发到代码托管平台。文件可能没入选行号也可能因上下文拼接或后续提交而漂移。实验只允许评论落在已选文件的新增行上无法定位的候选被降级为未锚定评论并记录原因。constselectedFileselectedByPath.get(comment.path)if(selectedFileundefined){return{kind:unanchored,comment,reason:file_not_selected}}constaddedLineNumbersnewSet(selectedFile.addedLines.map((line)line.newLine))if(!addedLineNumbers.has(comment.line)){return{kind:unanchored,comment,reason:line_not_in_diff}}“降级”比“硬贴一个附近行号”更诚实。未锚定评论仍可进入总结区但不能伪装成精确的行级发现。最小实验验证了什么实验使用 Bun 1.3.1、TypeScript 7.0.2 和 Biome 2.5.6。测试先失败于缺失实现补齐最小代码后路径排除、规则组合、预算截断、评论锚定和 CLI 场景共 5 项测试通过。Checked 7 files. No fixes applied. TypeScript --noEmit: passed 5 pass, 0 fail, 8 expect() calls CLI: {selected:1,skipped:1,anchored:1,unanchored:1}这能证明确定性骨架的示例行为符合测试不能证明真实模型评论准确也不能证明 OpenCodeReview 的官方 Benchmark。本文没有执行真实仓库的模型审查没有连接 CI 评论接口也没有把测试通过写成 AI 审查有效性。AI 评论仍然只是第二意见即使范围和行号都稳定模型仍可能漏报、误报或误解业务约束。AI 审查应该与类型检查、Lint、单元测试、集成测试、SAST / SCA 和人工合并并列而不是覆盖它们。闭源代码还要增加另一层门禁Diff 会发给哪个 Provider本地 Session 是否保存 Prompt 与源码CI Secret 如何管理日志保留多久路径元数据能否外发。OpenCodeReview 的官方资料明确说明默认审查会把 Diff 和读取的上下文交给所选模型并在本地保存会话 JSONL遥测默认关闭也不等于会话产物没有敏感内容。接入真实仓库前的检查表Git 范围、文件选择和排除规则进入版本控制每个入选文件记录命中规则和 Diff 身份文件数、Changed Lines、Token、时间和费用都有上限超预算与未匹配规则显式报告不伪装成审查完成模型只输出结构化候选评论评论文件和行号在发送前重新对照当前 Diff无法锚定时降级不猜测附近行号类型检查、测试、SAST / SCA 和人工复核继续独立运行Provider、Session、Secret、遥测和数据保留边界已确认CI 固定工具版本升级后重新跑范围与定位回归。AI 代码审查真正需要优化的往往不是 Prompt 的长度而是模型前后的确定性接口。把范围、规则、预算和行号写死模型的语义判断才会变成可审计的候选发现而不是一段无法证明覆盖面的漂亮评论。来源与验证边界OpenCodeReview 官方仓库OpenCodeReview 架构说明OpenCodeReviewv1.8.5ReleaseOpenCodeReview 遥测说明OpenCodeReview 安全策略本地实验脱敏 TypeScript 确定性审查骨架验证边界本文核验了官方架构、配置、安全与 Release 资料并完成脱敏确定性骨架的本地测试没有执行真实模型审查没有独立复现项目方 Benchmark也没有验证评论准确率、成本或 CI 平台集成。