AI代码审查工程化：确定性流水线+LLM Agent混合架构解析

AI 代码审查喊了很多年“即将取代人工”，但真落到自己团队里，大家发现它更像一个“很会聊天但不太靠谱的新同事”——说得头头是道，细看全是正确的废话，偶尔还编出几个不存在的函数名来吓唬你。直到我拆解 open-code-review 这套方案，才真正想明白一件事：AI 代码审查能不能工程化，关键不在模型多强，而在用什么架构把它包起来。

open-code-review 的核心思路挺朴素：把“确定性流水线 + LLM Agent”拼成一条混合链路。前半段用传统工具把代码里“一定有问题”的部分筛干净，后半段才让大模型去处理那些需要语义理解、上下文推断和业务判断的问题。这篇文章我会完整拆解这个混合架构怎么设计、怎么落地、踩了哪些坑，以及最关键的——怎么让 AI 输出的审查结论真正被人接受。适合正在选型、准备自研或想优化现有 AI Review 流程的研发效能负责人和一线工程师。

1. 为什么 AI 代码审查需要“确定性流水线 + LLM Agent”的混合架构

1.1 纯 LLM 做代码审查，听起来很美，用起来很痛

先说说我最早踩的坑。当时兴致勃勃把 PR 链接直接丢给一个通用大模型，让它“帮我审查代码”，期望它像资深 Reviewer 一样给出精准意见。结果它确实给了——给了 12 条意见，其中 9 条是“请确保异常被正确处理”“建议增加日志记录”这类放之四海而皆准的废话，还有 2 条提到一个根本不存在的函数依赖图，1 条建议重构一个刚在隔壁分支被删掉的模块。

这就是纯 LLM 做 Review 的原生问题：它没有感知变更上下文的能力，没有“这个仓库本来长什么样”的准确记忆，更没有稳定判断“这段代码为什么这么写”的业务锚点。你给它看一个 300 行的 diff，它只能基于这 300 行做泛化推理，一旦 diff 里引用了外部函数、共享类型或历史遗留逻辑，它就开始“合理脑补”，一脑补就出错。

我后来想明白一个类比：让纯 LLM 直接做代码审查，就像让一个只读过三天项目文档的新人去做审计，他能说出“流程需要规范化”这种话，但你说不出“第 37 行这个事务边界有问题，因为 finally 里吞掉了异常”。前者是态度，后者才是审查。

1.2 纯规则做代码审查，稳定但天花板太低

那反过来，用传统确定性工具行不行？SonarQube、ESLint、Go Vet、PyLint，这些都是确定性的，给同一份代码永远是同一个输出，不会幻觉，不会漏判，性能还高。但它们的能力边界非常清晰：只能做有明确规则定义的检查。复杂语法、类型错误、未使用变量、安全正则遗漏、明显的坏味道，这些它们确实干得漂亮。

然而代码审查真正有价值的部分，恰恰是那些“规则没写但人一眼就能看出问题”的语义级判断。举几个例子：这个状态机里少了一条状态迁移路径、这个缓存失效策略可能导致数据不一致、这个接口设计在半年后必然导致调用方误用、这段逻辑放在事务里会锁表，这些都不是静态规则能表达的。它们需要理解业务模型、理解调用链、理解代码的隐含契约。

我之前维护的静态扫描集群一度跑了 200 多条规则，命中率很高，但团队 Review 时还是会忽略它，因为真正卡住线上事故的问题，它一个都没报出来。确定性工具的命门就是：它只能回答“有没有违反规则”，回答不了“这么写合不合理”。

1.3 混合架构的分工哲学：让规则的归规则，让模型的归模型

open-code-review 给了一个很干脆的答案：两者都别单干，让它们各管一段。

确定性流水线在第一层，负责三件事：先做编译/静态检查/Lint，把代码中确定性的错误和坏味道全部拦下来；然后对 diff 做精细化处理，区分新增行、修改行、删除行、上下文行，生成干净的“审查单元”；最后把已有问题打成基线，让第二层只盯增量。这一层的产出不是“审查结论”，而是一份结构化的、经过过滤的“最小审查包”。

LLM Agent 在第二层，只负责语义级审查。它拿到的是已经清洗过的 diff 数据、关联文件片段、团队规则，用它的上下文理解能力去判断“这段逻辑合理吗”“这个异常处理得当吗”“这个命名有没有歧义”。它不需要做编译检查，不需要去猜被删掉的行，不需要重复报告存量问题，所有体力活都被流水线干完了。

这套分工的核心原则我总结成一句话：凡是确定性工具能查的，绝不浪费 LLM 的上下文；凡是规则表达不了的判断力，才交给模型。这条原则直接决定了后面所有设计，也解释了为什么 open-code-review 会比裸调大模型稳定得多。

2. 确定性流水线：先把“一定错”的问题筛干净

2.1 前缀检查：编译、静态分析、Lint 层的设计

混合架构的第一道关卡，是传统的确定性检查。很多人以为这就是简单跑一下 CI，其实这里有一个关键设计：检查必须被分成“阻断型”和“非阻断型”。编译错误就是典型的阻断型问题，代码根本合不进去，这种问题交由流水线直接拦截并标记为 failed，压根不需要任何 LLM 参与。我之前见过一个团队硬要省事，让 LLM 先看一遍再决定要不要跑构建，结果模型把编译错误当成“建议修改”，整个流程就失去了意义。

非阻断型问题，比如代码风格偏好、轻微可读性建议，也应该由 Lint 规则处理，不要扔给模型。ESLint、RuboCop、go vet 这类工具在规则明确时输出是 100% 可复现的，成本几乎为零，对这类问题的处理能力远强于 LLM。这里最容易犯的错误是：什么检查都往提示词里塞，最后模型把“分号没加”和“事务边界错误”混在一起报，严重程度完全不可信。

我建议的检查分层逻辑如下：

• P0 阻断项：编译失败、类型错误、测试失败、安全漏洞模式匹配
• P1 规则项：Lint 错误、复杂度超阈值、明显反模式（由规则引擎处理）
• P2 语义项：架构合理性、逻辑边界、异步处理、业务语义，这部分才进入 LLM Agent

这套前缀检查的收益是实打实的，它把 LLM 从“什么都看”变成“只看语义问题”，把关的对象从几千行代码浓缩成几百行增量，上下文利用率高了一个数量级。

2.2 变更范围隔离：为什么必须让 AI 只看增量

这是我从 open-code-review 里学到的最有价值的设计之一：变更范围隔离。理论很简单——AI 审查的输入不应该是整个 PR 的全量代码，而必须是精确的增量 diff 加上必要的上下文。

实际执行时可以这样做：先跑git diff --unified=3拿到带三行上下文的变更，在此基础上用脚本解析出本次 commit 新增、修改、删除的代码块。然后做一个“文件影响面分析”，找出被修改函数的所有调用点，把调用点的代码片段也一并提取出来。这就是所谓的“审查证据包”。

举个具体例子，团队几乎每周都会遇到这种情况：开发者在工具函数里改了一个布尔判断逻辑，调用的地方有七个，其中四个调用点都会受影响，但 diff 里只能看到这个函数的两行变化。人来审查时都容易漏掉，更别提站在一个孤立 diff 上推理的 LLM。通过影响面分析把四个调用点一并塞进上下文，LLM 才能给出“这个改法会导致 XX 模块的权限校验失效”这种级别的判断。

这个阶段输出的审查包建议用结构化的 JSON 或 YAML 保存，包含：文件路径、改动行号、旧代码/新代码对、关联函数的调用点、依赖关系、变更类型。这是整个确定性流水线的核心产出，LLM 不直接读 git diff，它读的是这份已经整理好的“案件卷宗”。

2.3 已有问题过滤：怎么把噪音压下去

工作中一个真实的挫败场景是：模型第一次跑就报出 200 多个问题，开发一脸懵——这代码又不是今天写的，为什么突然全是问题？看细节才发现，绝大多数是仓库里沉淀了半年甚至一年的存量告警，并不是这个 PR 引入的。

要解决这个问题，就必须引入“基线化”思路。在把 LLM 接进来之前，先对主干分支做一次全量扫描，把当前所有问题打成一个基线清单保存起来。之后每次 PR 审查，确定性流水线只输出“新增问题”和“与基线相关的变化”，凡是基线里已经有记录的问题，直接过滤掉，不让它出现在 LLM 的输入里。

实际操作中，可以用一个简单的对比表来维护：

这套过滤机制可以把初始噪音直接砍掉 70% 以上。我第一次跑通这套流程时，审查报告瞬间从“一份没人愿意读的问题清单”变成了“几条有分量的异议”，Reviewer 的重视程度完全不一样。

2.4 确定性流水线的输出格式：喂给 LLM 的“结构化压缩包”

确定性流水线最后一步，是把审查包格式化。这一步很多人忽略，但其实直接影响 LLM 的推理质量。不要直接把原始 diff 丢给模型，一定要做结构化压缩——保留关键行号、代码片段、变量符号、依赖引用，同时去掉无关的空行、缩进噪声、被重命名但逻辑不变的纯噪音改动。

我常用的审查包结构类似这样：

{ "pull_request": { "id": "PR-1243", "title": "fix: 调整订单超时状态的迁移逻辑", "base_branch": "main", "changed_files": 3 }, "files": [ { "path": "src/order/state_machine.go", "change_type": "modified", "changed_lines": [ { "line_number": 87, "old_code": "if oldState == TimedOut { return false }", "new_code": "if oldState == TimedOut { return true }" } ], "related_symbols": ["OrderStateMachine", "TransitionTo"], "call_sites": [ { "file": "src/api/order_handler.go", "line_number": 142, "code": "if !sm.TransitionTo(target) { reject() }" } ] } ], "baseline_filtered": true, "linkage": "file_imports_diagram" }

这个 JSON 再配合一段简短的仓库背景描述（语言栈、框架版本、目录结构），组成 LLM 的完整上下文。核心原则是：给模型的信息必须是最小充分的——再多一点就会分散注意力，再少一点它就会开始编。这也是为什么 open-code-review 的设计里，LLM 不是纯提示词工程，而是数据工程的一部分。

3. LLM Agent 层：把代码当上下文，把规则当约束

3.1 Agent 的完整工作流：召回、组装、推理、结构化输出

第二层的 LLM Agent，设计上不应该是一个“聊天式问答机器人”，而应该是一个“按流程执行任务的专业审计员”。open-code-review 里的 Agent 工作流，我拆成五步。

第一步是召回：基于确定性流水线产出的审查包，从代码库中精准召回关联文件、函数定义、调用链、历史审查记录和团队规则。第二步是组装：把召回的上下文按照规定模板拼装成结构化提示词，减少原始 diff 里无效 token 的占比。第三步是推理：让模型按关注面逐项审查，每项审查只针对一个明确的语义问题，不做开放式总结。第四步是结构化输出：所有审查结论必须按固定 schema 生成 JSON，不允许自由发挥。第五步是回写：通过 API 把审查结果提交到代码托管平台的 PR 评论线程或审查记录中。

这个流程里最容易被忽略的是“召回”这一环。直接给模型一整包文件，它也能出结果，但质量不稳定。真正的做法是做针对性召回：要审查的文件引用了哪些模块，这些模块的公共接口长什么样，这个文件在历史上有过哪些相关审查记录，这些才是模型需要的上下文。召回质量决定了模型是“基于理解做判断”还是“基于猜测试探性输出”。

Agent 工作流五步设计：

• 召回：提取关联文件、符号定义、调用链、规则库条目
• 组装：将上下文压缩为“审查包 + 规则 + 任务指令”三件套
• 推理：按关注面逐项审查，每个关注面单独推理
• 结构化输出：按 schema 输出审查项，禁止自由文本
• 回写：通过平台 API 写入 review comment

3.2 上下文组装的艺术：文件内容、Diff、关联文件的取舍

上下文怎么组装，是这套架构里最考验功力的一环。窗口有限，代码无限，必须做取舍。我总结的优先级排序是：PR 描述和任务上下文 = 规则库 > 变更 diff（带上下文） > 关联文件片段 > 历史审查示例 > 完整文件源代码。

PR 描述为什么排在第一位？因为它给了模型业务意图——知道这次改动的目的是什么，模型才能判断“这么做是否合理”。否则它只能做文法级审查，看不出逻辑问题。规则库放在第二位，是因为团队规范是语义审查的标尺。模型没有量尺就没法测量。

diff 排在中间，但这里有一个重要细节：大 diff 必须拆。单文件超过 400 行变更、单 PR 超过 1000 行变更，都必须按函数边界拆成多个子任务。宁可发多次请求，也不要把 5000 行代码硬塞进一个窗口，模型一旦超出 token 预算，表现是断崖式下跌的——前面的记住了，后面的全瞎了。

关联文件的取舍标准是“是否被本次变更直接影响”。间接影响的文件先不放。比如改了一个公共方法的签名，就把所有调用方放进去；如果只是加了一个注释，那就什么都不用放。不要为了“以防万一”把所有相关文件都塞进上下文，“以防万一”的本质是没想清楚审查关注面。

3.3 规则注入：把团队规范写进 Prompt

团队规范是 LLM 审查的标尺，但直接把规范文档丢给模型是无效的。我实测下来的做法是：先从团队手册、代码规范、历史 review 记录里提炼出“机器可执行的审查规则”，每条规则必须满足三个条件：描述清晰、可验证、冲突时能给出改法。

一个典型的规则条目长这样：

- id: T-1024 category: concurrency severity: warning description: 在共享可变状态上进行并发写入时，必须显式加锁或使用原子操作 verification: > 检查本次变更中是否有对多个 goroutine 可见的 map / slice / struct 字段的直接写入， 且写入语句没有包裹在 sync.Mutex / atomic 等同步原语中。 suggestion: > 为共享状态引入 sync.Mutex，或在写入路径使用 atomic 操作； 如果该状态在单个 goroutine 内生命周期内，建议在代码注释中说明线程封闭。

规则注入的量要克制。我实测超过 20 条关键规则之后，模型的“准确性”反而下降，因为它开始权衡“哪条规则更值得遵守”，权衡过程就会产生幻觉。建议规则库按优先级分批注入：每次审查只注入与该变更最相关的 5~10 条规则，其余放远在低优先级上下文中。

从技术实现上，规则的存储格式用 Markdown 或 YAML 都可以，但一定要在运行时转成结构化对象，再插入 Prompt，而不是直接把整个规则文件塞进去。LLM 是文本模型，你给它的文本越结构化，它的输出越稳定。

3.4 从 Chat 模式到 Review 模式：结构化的输出设计

绝大多数 AI 代码审查工具翻车，不是模型不够强，而是输出的形态让人没法用。聊天模式下模型会输出“我觉得这里可能有问题，建议考虑一下并发场景”，这种话在人看来就是正确的废话，没有任何行动价值。

open-code-review 给了一个非常好的示范：强制模型按 Review schema 输出。每条审查结论必须包含严重级别、精确位置、引用代码片段、问题描述、修改建议、相关规则 ID。没有引用具体代码片段的问题，直接视为无效输出。

我定义了一套分级体系供参考，分四档：

• Blocker：必须阻止合入。例如内存泄漏、并发竞态、安全漏洞、核心逻辑逻辑反转
• Warning：建议修改。例如错误处理缺失、潜在的边界条件、不合理的资源释放
• Nitpick：风格偏好。不影响功能的微调建议，但如果和规则库冲突则升级为 warning
• Question：不是结论，是提问。例如“这里状态迁移路径是不是少了一条？”，留给开发者回答

这种结构化输出的好处显而易见：Reviewer 可以按级别筛选处理，也可以快速定位到具体行。更关键的是，它能被后续的“人工确认/驳回”流程自动处理——人工点一下“确认”，这条建议就进入案例库，成为以后模型审查的参考资料。这就是人机闭环的地基。

4. 工程化落地：把架构接到真实研发流程里

4.1 CI/CD 接入：从 PR 触发到结果回写

架构设计得再漂亮，接不进 CI 就是白搭。open-code-review 在工程化落地上最突出的地方，就是它没有做一个“命令行工具”，而是做了一套可以嵌入现有研发工作流的服务化组件。

以 GitLab CI 为例，可以在 merge request 事件上触发一个 review job，job 内部跑四个阶段：checkout 拉取代码、run deterministic pipeline 生成审查包、call LLM Agent 执行审查、writeback 调用 GitLab API 创建 review comment。GitHub Action 类似，只是用 pull_request 事件和 issues API。

这里有一个关键细节：LLM 调用不稳定，超时和失败是常态。所以要选择异步模式，不要阻塞 PR。我的做法是：触发 job 后，机器人先在 PR 里回复“AI 审查已开始，预计 2~3 分钟完成”，审查完成后通过更新评论的方式覆盖这条消息。跑挂了也无所谓，留一句“审查服务异常，请人工 review”，总不能因为 AI 服务抖动把整个 CI 卡死。

异常兜底机制必须有：定时器、重试逻辑、熔断开关。LLM 连续失败三次就自动熔断，后续审查请求直接走“跳过 AI 审查、只跑确定性流水线”的降级路径。我见过太多团队死在“AI 服务不稳定导致 CI 天天红”这个坎上，把稳定性问题列为第一优先级，而不是先堆功能。

4.2 人机协同节奏：AI 建议、人工决策、事后对话

工程化的第二层含义是：AI 的输出要能够被人的反馈持续改善。

理想的工作流是这样的：AI 在 PR 评论区发布审查结果，每条结果右侧带两个按钮“确认”“驳回”。Reviewer 对每条建议做出反馈。确认的建议进入“优秀例句库”，驳回的建议进入“屏蔽词库/规则抑制列表”。每周汇总一次数据，把高频确认的条目反向写入规则库，把高频驳回的模式提取出来加进 Prompt 屏蔽词。

这里要特别注意“驳回”的处理。模型报出一个问题，人觉得不对，点了驳回。这个信号是金矿——它说明模型的判断依据有问题，要么是上下文缺失，要么是规则注入有歧义，要么是模型本身幻觉。把驳回样本汇总起来分析，比调提示词更有效。说白了，这套系统里人的反馈才是真正的“监督信号”，模型只是推理引擎。

我建议团队先跑两周灰度：AI 审查结果只对资深 Reviewer 可见，且不参与合入门禁。两周后看数据——确认率、驳回率、漏报率、误报率——再决定要不要开放给全员并且接入门禁。不要一上来就搞“AI 审查不通过就不能合入”，那会把整个流程的口碑毁掉。

4.3 性能成本评估：几个关键数字和取舍

聊工程化不能回避成本和性能。先说延迟：纯确定性流水线，一般在 10~60 秒内能出结果；LLM 审查部分，单条小 diff 走本地小模型大概 20~40 秒，走商业化大模型 API 大概 5~15 秒。整条流水线的目标应该控制在 5 分钟以内，超过这个数开发者就开始烦躁了。

成本方面，核心变量是 token 消耗。一个常规中型项目的测算逻辑我列一下：假设每周 30 个 PR，每个 PR 平均 200 行变更，审查包大约 8000 token，加上规则和回写，单次审查的输入输出大概 12000 token。一个月就是 12000 × 30 × 4 = 144 万 token。如果按商业化 API 单 token 价格算，业务机型一个月几百块到一千多人民币，其实不算贵，但有一个陷阱——如果 review 包设计不合理，把无用的全文件上下文塞进去，成本会翻 3 到 5 倍，而且效果反而更差。

想降成本有四个办法：

• 启用语义缓存，相同文件片段（通过哈希判断）在上次审查后直接复用
• 小文件合并审查，大文件按关注面分片，拒绝“全量一次过”
• 优先部署本地开源模型，7B~14B 参数量的模型配量化后，审查质量已经够用
• 只审查“高风险变更”，用改动文件的复杂度、依赖数、历史 bug 数等特征做路由，低风险 PR 直接走纯确定性检查

4.4 开源方案选型与二次开发建议

如果团队想快速起步，open-code-review 这套设计思路可以直接作为底座。但很少有团队能直接拿过来就用，需要自己二次适配的部分，我按优先级排一下：首先对接自己的代码托管平台权限体系，这不是功能问题，是安全底线；其次适配自己的语言栈和构建体系，不同语言的 AST 差异巨大，确定性流水线的 parser 必须换成本地工具链；最后建立自己的规则库，把团队的代码规范、领域最佳实践、历史事故教训提炼成审查准则。

这里要特别提醒一个多语言架构的坑：如果你团队是 Java + Go + Python 混着用，确定性流水线的适配成本会陡然上升。每种语言的静态分析工具链完全不同、误报率不同、规则体系不同。有人会说“那让 LLM 看就好了”，错。语言适配没做好，LLM 会被迫承担原本属于规则层的检查任务，上下文被占用、误报率飙升、审查质量断崖下降。我的经验是：先将 OK 的语言栈跑通，再逐步扩展，不要一开始就铺到全语言。

另外一定要关注“审查结果的审计日志”。所有 AI 输出、人工确认、驳回、规则命中记录，都应该是可追溯的。这不是为了甩锅，而是为了让系统持续改良有数据喂养。没有审计数据的 AI Review，就是一次性玩具。

5. 常见问题与排查技巧实录

5.1 误报太多，Reviewer 不想看怎么办

这是落地时最致命的问题。一次 PR 审查报了 40 条建议，其中 35 条是误报或低价值提示，开发看完之后直接对 AI 审查失去信任，后续全部忽略。

排查方法分两步。第一步看确定性层：报出来的 40 条里，有多少是存量基线没滤干净？有多少是规则配置错误？有多少是 diff 解析脚本把“格式化变更”当成了“逻辑变更”？这一步修好，通常能砍掉一半。第二步看 LLM 层：报出来的语义问题，是不是没有引用具体代码片段？是不是问题描述模糊不清？给模型加硬约束——没有 code_snippet 字段的建议一律丢弃，大于 10 条的审查结果自动截断，并且只保留优先级最高的 10 条。

我实测经验是：把误报率从 40% 压到 15% 左右，核心手段不是换模型，而是“给模型一个最小证据约束”，强制它每条建议都必须带行号和代码引用。模型在没把握时会倾向于少报，而不是胡编。

5.2 长 Diff 被截断，审查覆盖不全

单文件变更超过 800 行，或者单 PR 涉及 10 个以上文件时，模型经常出现“前面写得很详细，后面零输出”的情况，因为窗口不够了。

解决思路是分片 + 分层。分层是指先做一个全局 summary 任务，让模型快速浏览整个 PR 的结构，输出一份“本次变更涉及哪些模块、主要风险在哪里”的概览；再基于概览做分片深度审查，按关注面（存储层、并发层、安全层、可读性）切分，每片单独提交上下文。全局 summary 决定深度审查的优先级，分片审查决定具体问题的质量。

分片粒度不要按文件机械切，而要按函数边界和关注面切。把“订单状态机的迁移逻辑”作为一个审查单元，而不是“order 目录下三个文件的分别审查”。模型在理解一个完整逻辑单元时表现远好于拼接碎片。

5.3 模型上下文复用与 Token 消耗失控

有些团队跑了一周，发现 AI 审查每天的 token 消耗高得惊人，一查全是把全量文件塞进上下文惹的祸。排查方向很明确：审查包日志里看单次审查的输入 token 数，如果经常大于“diff 实际内容”的 10 倍，说明召回阶段贪多了。

缓解机制我用过比较有效的是：加一个 token 预算，单次审查输入上限比如 8K，超出后按优先级丢弃最不相关的上下文；增加语义缓存，对未变化的文件内容做哈希缓存，重复出现的片段不重复计价；把文件按“变更密度”排队，先审查变更最密、影响最大的文件，变更只有一两个字符的文件一律跳过。

5.4 数据安全边界与敏感信息处理

代码是公司最核心的数据资产，这一点在接入 AI 审查时必须摆在最高优先级。我的建议很简单：代码优先进入私有化部署的模型环境，不要送到公有云 API；如果必须使用公有云 API，一定要先做敏感信息脱敏——把代码注释和字符串中的密钥、token、IP 地址、员工姓名替换成占位符再送分析；API 网关层记录审计日志时，不要把完整代码片段入库。

在代码审查这个场景下，宁可模型笨一点，也不要让数据出域。很多团队调研时看到商业 API 效果好，马上接上去，忘了代码托管平台本身有权限体系，而模型服务是绕开这一层的外部系统。让“代码不进公网”成为第一铁律，在私有模型质量不够时再考虑混合路由方案。

提示：所有涉及模型调用和代码传输的链路，都应该同步做权限穿透校验，确保调用方身份与代码库权限一致，而不是“只要拿到 token 就能看任何仓库”。

6. 关于标准的规则：把架构落地成可复盘的配置清单

最后分享一份我在实际项目中总结的配置清单，它不是 open-code-review 的标准答案，但照着这个框架搭，基本能把前面所有经验固化下来，方便团队复制。

这套架构里真正难的不是任何一个单点技术，而是把“确定性工具、模型推理、人工反馈、数据审计”串成一个闭环。我自己的体会是：AI 代码审查进入工程化时代，标志不是“模型能看懂代码”，而是“模型被嵌进了一条可信的、可追溯的、能持续学习的生产链路”。

最后再分享一个小技巧——如果你刚起步，别急着让 AI 全面审查。先让它只做两件事：标记“可能是 bug”的代码位置，和提出“它不确定但值得人确认”的问题。这两件事干好了，团队对 AI 审查的信任就有了；信任有了，再慢慢扩展它的审查范围。其他所有花哨能力，都可以往后放。