1. 从提示词到产线为什么代码审查需要多智能体代码审查这件事做过几年开发的人都有体会它重要但没人愿意干。一个中等规模的团队每天产生的 PR 少则十几个多则几十个每个 PR 动辄几百行 diff。让资深工程师逐行去看时间成本高得离谱让初级工程师去看又看不出深层问题。结果就是要么审查流于形式点个 Approve 了事要么审查成为瓶颈PR 排队等好几天。大模型出来之后很多人第一反应就是能不能让 AI 来帮我审代码这个想法很自然也确实可行。但真正动手做过的人会发现单靠一个提示词丢给大模型效果远没有想象中好。你写一个“请帮我审查这段代码”的提示词模型会给你一堆泛泛而谈的建议比如“建议添加错误处理”“变量命名可以更清晰”这些东西说了等于没说。问题出在哪里出在代码审查本身是一个多维度、多阶段的复杂任务而单个提示词只能覆盖其中一个切面。LinkedIn 工程团队在这方面做了一次比较系统的探索他们的思路是把代码审查拆解成多个智能体每个智能体负责一个专门的审查维度再通过编排层把它们的结果汇总起来。这套思路的核心洞察是代码审查不是一件事而是一组事的集合。风格检查、逻辑缺陷、安全漏洞、性能隐患、测试覆盖这些维度需要的上下文、判断标准和输出格式都不一样。用一个提示词去覆盖所有维度就像让一个医生同时看内科、外科、眼科、骨科不是不可能但效果一定打折扣。我自己的团队在过去半年里也踩过类似的坑。最开始我们用一个统一的提示词模板把 diff 和仓库上下文拼在一起丢给模型结果发现模型经常顾此失彼你强调安全它就忽略性能你强调性能它又漏掉边界条件。后来我们改成多轮调用每轮聚焦一个维度效果明显好转但新的问题又来了——多个维度的结果怎么合并冲突怎么处理优先级怎么定这些问题逼着我们去研究多智能体的编排方式。这篇文章就是把这半年的实践和 LinkedIn 公开分享的思路结合起来从提示词设计讲到产线落地把多智能体代码审查这件事拆开揉碎讲清楚。不管你是刚开始尝试 AI 辅助代码审查还是已经在做但效果不理想应该都能从中找到一些可以直接抄作业的东西。2. 多智能体代码审查的整体架构设计2.1 为什么不是一个大模型加一个长提示词很多人对 AI 代码审查的第一印象是写一个足够详细的提示词把审查规则、代码规范、历史案例全塞进去然后让模型一次性输出所有问题。这个思路在 demo 阶段能跑通但一上产线就崩。原因有三个。第一上下文窗口是有限的。一个真实的 PR 可能涉及十几个文件、上千行改动再加上仓库的规范文档、历史审查记录很容易就超出模型的上下文限制。你可能会说现在有些模型支持很长的上下文但长上下文带来的问题是注意力稀释——模型在几千行代码里找问题很容易漏掉关键细节。第二不同审查维度的判断逻辑差异很大。安全审查需要模型具备攻击者视角去想“这段代码能不能被注入”“这个权限检查能不能绕过”性能审查需要模型理解算法复杂度和资源消耗风格审查则更多是模式匹配。把这些逻辑混在一个提示词里模型很难同时保持多个视角的敏锐度。第三输出格式和后续处理不一样。安全漏洞需要标记为高优先级并阻断合并风格问题可以自动修复或作为建议测试覆盖不足需要触发额外的测试流程。如果所有问题混在一起输出后续的自动化处理就很难做。多智能体的思路就是把这些问题分开解决。每个智能体有自己的提示词、自己的上下文范围、自己的输出格式最后通过一个编排层来汇总和决策。这样做的好处是每个智能体可以专注做好一件事提示词可以针对性地优化输出也可以结构化。2.2 智能体的角色划分与职责边界LinkedIn 的方案里代码审查被拆成了几个核心智能体。结合我自己的实践我觉得下面这个划分比较合理也容易落地。风格与规范智能体负责检查代码是否符合团队的编码规范包括命名约定、缩进、注释要求、导入顺序等。这个智能体的提示词里需要嵌入团队的规范文档输出的是可以直接自动修复的建议。它的判断标准相对客观误报率低适合作为第一道过滤。逻辑与缺陷智能体负责检查代码的逻辑正确性包括边界条件、空值处理、循环终止条件、异常路径等。这个智能体需要看到完整的函数上下文不能只看 diff 片段。它的输出需要标注置信度因为逻辑问题有时候需要人工确认。安全智能体负责检查潜在的安全漏洞包括注入风险、权限校验缺失、敏感信息泄露、不安全的反序列化等。这个智能体的提示词需要包含常见漏洞模式库输出需要标记严重等级。安全问题的误报率通常较高所以需要设置一个阈值只有高置信度的问题才阻断合并。性能智能体负责检查性能隐患包括不必要的循环嵌套、重复计算、大对象创建、数据库查询在循环内等。这个智能体需要理解代码的运行上下文输出需要附带优化建议。测试覆盖智能体负责检查新增代码是否有对应的测试测试是否覆盖了关键路径和边界条件。这个智能体需要访问测试文件输出的是测试补充建议。这五个智能体各司其职每个的提示词都可以独立迭代。比如你发现安全智能体漏报了一种新的漏洞模式只需要更新它的提示词或知识库不影响其他智能体。2.3 编排层的设计汇总、去重与优先级决策多个智能体各自输出结果之后编排层的工作就开始了。这一步比很多人想象的要复杂因为不同智能体的输出会有重叠和冲突。去重是第一件事。同一个问题可能被多个智能体发现比如一个空指针解引用逻辑智能体可能标记为“边界条件未处理”安全智能体可能标记为“潜在崩溃风险”。编排层需要识别这些是同一个问题合并成一条记录。优先级决策是第二件事。不同智能体给出的严重等级标准不一样安全智能体说“高危”的问题在逻辑智能体那里可能只是“中等”。编排层需要有一套统一的优先级映射规则把所有问题映射到统一的等级体系里。冲突处理是第三件事。有时候两个智能体的建议是矛盾的比如性能智能体建议“把循环内的查询提到外面”但逻辑智能体发现“提到外面会改变语义”。这种情况下编排层需要标记冲突交给人工决策而不是自动选一个。我自己的做法是给每个智能体分配一个权重安全问题的权重最高逻辑问题次之风格问题最低。当多个智能体对同一个代码片段有不同判断时按权重排序高权重的意见优先展示。同时编排层会记录每个智能体的历史准确率准确率高的智能体在冲突时更有话语权。2.4 数据流转与状态管理多智能体系统的一个工程难点是数据流转。每个智能体需要不同的输入风格智能体需要规范文档和 diff逻辑智能体需要完整的函数上下文安全智能体需要依赖库版本信息性能智能体需要调用链信息。这些数据从哪里来、怎么组织、怎么传递给智能体都需要设计。我们的做法是建一个上下文仓库在 PR 创建时触发一次数据采集把 diff、相关文件、依赖信息、历史审查记录都拉取下来存成一个结构化的上下文对象。每个智能体从这个对象里取自己需要的部分而不是各自去拉数据。这样做的好处是减少重复请求也保证各个智能体看到的是同一份数据快照。状态管理方面每个智能体的执行是独立的可以并行跑。编排层维护一个状态机记录每个智能体的执行状态等待中、执行中、已完成、失败所有智能体完成后触发汇总流程。如果某个智能体失败编排层可以选择重试或者跳过不影响其他智能体的结果。3. 核心智能体的提示词设计与实操要点3.1 风格与规范智能体让规则可执行风格智能体的提示词设计有一个关键原则规则必须可执行不能是模糊的描述。你写“代码应该清晰易读”模型没法判断你写“函数名必须使用驼峰命名且长度不超过 30 个字符”模型就能准确检查。我们的风格智能体提示词模板大致是这样的你是一个代码风格审查助手。请根据以下规范检查代码 规范文档 {style_guide} 待审查代码 {diff} 请逐条检查以下项目并输出 JSON 格式的结果 1. 命名规范变量、函数、类名是否符合约定 2. 缩进与格式是否使用统一的缩进和换行风格 3. 注释要求公共函数是否有文档注释 4. 导入顺序导入语句是否按标准库、第三方库、本地模块分组 输出格式 { issues: [ { file: 文件路径, line: 行号, rule: 违反的规则编号, message: 问题描述, suggestion: 修复建议, auto_fixable: true/false } ] }这个提示词的关键点在于规范文档是动态注入的每个团队可以有自己的规范输出是结构化的 JSON方便后续自动处理auto_fixable字段标记哪些问题可以自动修复。实操中有一个坑要注意规范文档不能太长。我们最开始把整个编码规范文档几十页都塞进提示词结果模型经常忽略后面的规则。后来改成只注入与当前 diff 相关的规则比如 diff 里只有 Python 代码就只注入 Python 相关的规范效果好了很多。另一个经验是风格问题不要阻断合并。风格问题即使漏掉几个也不会造成严重后果但阻断合并会严重影响开发效率。我们的做法是风格问题只作为评论展示开发者可以选择一键修复但不强制。3.2 逻辑与缺陷智能体上下文比提示词更重要逻辑缺陷审查是难度最高的一个维度因为逻辑问题往往需要理解代码的意图而不仅仅是模式匹配。这个智能体的提示词设计重点不在于写多少规则而在于给模型足够的上下文。我们的逻辑智能体提示词模板你是一个代码逻辑审查助手。请分析以下代码改动找出潜在的逻辑缺陷。 函数完整代码包含改动前后的上下文 {full_function} 改动说明 {pr_description} 相关测试 {related_tests} 请重点检查 1. 边界条件空值、零值、最大值、最小值是否处理 2. 异常路径异常是否被正确捕获和处理 3. 循环逻辑终止条件是否正确是否存在死循环风险 4. 状态一致性多线程或异步场景下状态是否安全 5. 返回值所有路径是否都有返回值 对每个发现的问题请给出 - 问题描述 - 置信度高/中/低 - 触发条件 - 修复建议这个提示词里full_function是关键。如果只给 diff 片段模型看不到函数的完整逻辑很容易误判。比如 diff 里删了一行if (x ! null)模型可能认为这是引入了空指针风险但实际上函数开头已经做了空值检查。给完整函数代码模型就能做出更准确的判断。pr_description也很重要。如果 PR 描述里写了“这个改动是为了修复某个 bug”模型就能理解改动的意图减少误报。我们实测下来加上 PR 描述后逻辑智能体的误报率下降了大约三成。还有一个实操技巧让模型输出置信度。逻辑问题很难做到百分之百准确有些问题需要人工确认。我们设置了一个规则置信度为“高”的问题直接展示并阻断合并置信度为“中”的问题展示但不阻断置信度为“低”的问题只记录不展示。这样既保证了重要问题不被漏掉又避免了大量误报干扰开发者。3.3 安全智能体攻击者视角的提示词工程安全审查智能体的提示词设计核心是让模型切换到攻击者视角。普通的代码审查提示词是“这段代码有什么问题”安全审查的提示词应该是“如果我是攻击者我会怎么利用这段代码”。我们的安全智能体提示词模板你是一个安全审查助手具备攻击者视角。请分析以下代码改动 找出可能被利用的安全漏洞。 代码改动 {diff} 依赖库信息 {dependencies} 请从以下角度分析 1. 注入风险SQL 注入、命令注入、模板注入、XSS 2. 权限校验是否有未校验的访问路径 3. 敏感信息是否有硬编码的密钥、密码、令牌 4. 反序列化是否处理了不可信的反序列化数据 5. 加密使用是否使用了不安全的加密算法或模式 6. 依赖漏洞依赖库是否有已知漏洞 对每个发现的问题请给出 - 漏洞类型 - 严重等级严重/高/中/低 - 攻击场景描述 - 修复建议 - 置信度这个提示词里dependencies的注入是一个亮点。很多安全问题不是出在业务代码里而是出在依赖库的已知漏洞上。把依赖库版本信息传给模型模型可以结合已知漏洞库来判断风险。安全智能体的误报率是所有智能体里最高的。我们最开始上线时每天产生几十条安全告警开发者很快就麻木了。后来我们做了两件事一是提高置信度阈值只有置信度为“高”且严重等级为“严重”或“高”的问题才阻断合并二是建立了一个反馈机制开发者可以标记误报我们定期用这些反馈来优化提示词。还有一个经验安全智能体需要定期更新知识。新的漏洞模式层出不穷提示词里的漏洞模式库需要定期更新。我们的做法是每个月 review 一次安全智能体的提示词把新出现的漏洞模式加进去。3.4 性能与测试覆盖智能体容易被忽视的两个维度性能和测试覆盖这两个维度在很多团队的 AI 代码审查方案里是缺失的。原因很简单这两个维度的问题往往不是“对错”问题而是“好坏”问题判断标准更模糊。但恰恰是这两个维度对产线质量的影响很大。性能智能体的提示词设计重点是让模型理解代码的运行上下文。同样一段代码在低频调用的初始化逻辑里没问题在高频调用的请求处理路径上就是性能瓶颈。我们的提示词里会注入调用链信息告诉模型这个函数被谁调用、调用频率大概是多少。你是一个性能审查助手。请分析以下代码改动找出潜在的性能问题。 代码改动 {diff} 调用链信息 {call_chain} 请重点检查 1. 循环内的数据库查询或远程调用 2. 不必要的重复计算 3. 大对象的频繁创建和销毁 4. 算法复杂度是否合理 5. 缓存使用是否恰当 对每个问题请给出 - 问题描述 - 预估影响高/中/低 - 优化建议测试覆盖智能体的提示词相对简单但需要访问测试文件你是一个测试覆盖审查助手。请分析以下代码改动 判断测试是否充分覆盖了新增或修改的逻辑。 代码改动 {diff} 相关测试文件 {test_files} 请检查 1. 新增的公共函数是否有对应测试 2. 边界条件是否有测试覆盖 3. 异常路径是否有测试覆盖 4. 测试断言是否有效不是只调用不验证 输出 - 未覆盖的代码路径列表 - 建议补充的测试用例这两个智能体的输出通常不阻断合并而是作为建议展示。但我们会跟踪它们的建议采纳率如果某个智能体的建议长期不被采纳说明它的提示词需要优化。4. 从提示词到产线的工程化落地4.1 触发时机与执行流程多智能体代码审查系统在什么时候触发直接影响到开发者的体验。触发太早代码还没写完就收到一堆评论很烦触发太晚问题发现得晚修复成本高。我们的做法是分两个阶段触发。第一阶段在 PR 创建时触发跑风格、逻辑、安全三个智能体快速给出初步反馈。这个阶段的目标是让开发者在提交 PR 后几分钟内就能看到主要问题。第二阶段在 PR 更新时触发跑全部五个智能体包括性能和测试覆盖。这个阶段的目标是全面审查为最终合并做准备。执行流程上我们用的是并行执行加汇总的模式。PR 创建后编排层先拉取上下文数据然后并行触发三个智能体。每个智能体独立执行完成后把结果写入一个共享的结果队列。编排层监听队列所有智能体完成后触发汇总流程去重、排序、生成最终的审查评论。这里有一个工程细节智能体的执行要有超时控制。我们遇到过模型响应特别慢的情况一个智能体跑了十几分钟还没结果阻塞了整个流程。后来我们给每个智能体设置了 3 分钟的超时超时后标记为失败编排层用剩余智能体的结果继续汇总同时记录失败日志供后续排查。4.2 结果汇总与评论生成多个智能体的原始输出是结构化的 JSON但开发者看到的不应该是 JSON而应该是可读的评论。汇总层的工作就是把 JSON 转换成人类可读的评论同时做好去重和排序。去重的逻辑是这样的如果两个问题指向同一个文件的同一行且问题类型相似比如都是空值相关就合并成一条。合并时保留严重等级最高的描述其他描述作为补充信息。排序的规则是先按严重等级排严重问题在前同等级按文件路径排同一个文件的问题放在一起同一文件内按行号排。这样开发者在阅读评论时可以按文件逐个处理效率更高。评论的格式我们打磨了好几版。最开始是纯文本后来改成 Markdown 表格再后来改成带折叠的详情。最终的格式是这样的### 安全审查发现 2 个问题 | 严重等级 | 文件 | 行号 | 问题描述 | 建议 | |---------|------|------|---------|------| | 高 | src/auth.py | 45 | 权限校验缺失 | 在访问资源前添加权限检查 | | 中 | src/api.py | 112 | 输入未做长度限制 | 添加输入长度校验 | details summary查看详细分析/summary ... /details这种格式的好处是开发者一眼能看到有多少问题、严重程度如何需要详细信息时可以展开。实测下来开发者对这种格式的接受度最高。4.3 与 CI/CD 流水线的集成多智能体代码审查系统最终要嵌入到 CI/CD 流水线里才能发挥最大价值。我们的集成方式是在 CI 流水线里加一个审查阶段PR 创建或更新时自动触发。集成的关键点有几个。第一审查结果要能阻断合并。我们在代码托管平台上配置了分支保护规则只有审查通过没有严重和高危问题的 PR 才能合并。第二审查结果要能触发自动修复。对于风格问题我们提供了一个自动修复的按钮点击后系统会自动提交修复 commit。第三审查结果要能追溯。每次审查的结果都存档方便后续分析智能体的准确率和召回率。这里有一个坑要注意不要让审查成为流水线的瓶颈。我们最开始把审查放在流水线的最后一步结果发现审查跑完要等好几分钟开发者等得不耐烦。后来我们把审查改成异步执行PR 创建后立即返回审查结果通过评论的方式异步通知。这样开发者提交 PR 后可以继续做其他事审查结果出来了再回来看。4.4 效果度量与持续优化多智能体代码审查系统上线后怎么判断它有没有效果我们跟踪了几个核心指标。准确率智能体报告的问题中有多少是真实问题。我们通过开发者反馈来统计开发者可以标记“这是误报”。准确率低于 70% 的智能体需要优化提示词。召回率真实问题中有多少被智能体发现。这个指标比较难直接统计我们的做法是定期人工抽查一批 PR看看有没有智能体漏掉的问题。采纳率智能体建议的修复中有多少被开发者采纳。采纳率低的智能体要么是误报多要么是建议不可执行。平均修复时间从问题被报告到被修复的时间。这个指标反映了审查系统对开发效率的影响。我们每个月会 review 一次这些指标根据数据来调整提示词和阈值。比如安全智能体的准确率一直上不去我们就把它的置信度阈值调高减少误报逻辑智能体的召回率偏低我们就在提示词里增加了更多的检查项。5. 常见问题与排查技巧实录5.1 智能体误报太多怎么办误报是 AI 代码审查最常见的抱怨。开发者被大量误报淹没后就会对审查系统失去信任甚至直接忽略所有评论。解决误报问题我们总结了几个有效的方法。提高置信度阈值是最直接的方法。让模型对每个问题输出置信度只展示高置信度的问题。代价是可能漏掉一些低置信度的真实问题但相比误报带来的信任损失这个代价是值得的。增加上下文是治本的方法。很多误报是因为模型看不到完整上下文。比如模型看到x.foo()就报告“x 可能为 null”但如果函数开头有if (x null) return;这就是误报。给模型完整的函数代码这类误报会大幅减少。建立反馈闭环是长期的方法。让开发者可以标记误报定期用这些标记数据来优化提示词。我们每两周会 review 一次误报标记把高频误报模式从提示词里移除或调整。5.2 智能体漏报关键问题怎么排查漏报比误报更危险因为漏掉的问题可能直接导致线上事故。排查漏报问题我们有一套流程。首先确认上下文是否完整。漏报最常见的原因是模型没看到关键信息。比如安全智能体漏掉了一个注入漏洞可能是因为它没看到这个函数的输入来自用户请求。检查上下文注入逻辑确保模型能看到必要的信息。其次检查提示词是否覆盖了该问题类型。如果漏掉的是一个特定类型的漏洞比如 SSRF检查提示词里有没有相关的检查项。没有就加上。最后考虑模型能力边界。有些问题确实超出了当前模型的能力范围比如需要理解复杂业务逻辑才能发现的缺陷。这种情况下不要强求 AI 解决而是把它作为人工审查的重点提示。5.3 多智能体结果冲突怎么处理多个智能体对同一段代码给出矛盾建议这种情况在实际运行中并不少见。我们的处理原则是安全优先逻辑其次性能再次风格最后。具体来说如果安全智能体说“这里有漏洞需要修复”性能智能体说“这样改会影响性能”我们优先采纳安全建议但在评论里注明性能影响让开发者自己权衡。如果逻辑智能体说“这个改动会改变语义”性能智能体说“这样写性能更好”我们优先采纳逻辑建议因为语义正确性比性能更重要。冲突无法自动裁决时编排层会生成一条“需要人工决策”的评论把两个智能体的观点都列出来让开发者判断。我们统计过需要人工决策的冲突大约占总冲突的 15%比例不高可以接受。5.4 提示词迭代的版本管理提示词是智能体的核心资产需要像代码一样做版本管理。我们的做法是把每个智能体的提示词存成独立的文件放在 Git 仓库里每次修改都走 PR 流程。提示词文件里包含几个部分角色定义、检查项列表、输出格式、示例。修改提示词时我们会跑一个回归测试集看看修改后准确率和召回率有没有变化。回归测试集是一批标注过的历史 PR每个 PR 都有已知的问题列表。提示词修改后用这批数据跑一遍对比结果。版本管理还有一个好处是可以回滚。有时候提示词改完后效果反而变差了可以快速回滚到上一个版本。我们遇到过好几次这种情况有了版本管理回滚只需要几分钟。5.5 成本控制与性能优化多智能体系统意味着多次模型调用成本是单智能体的好几倍。怎么控制成本是我们上线后重点优化的问题。按需触发是最有效的成本控制手段。不是每个 PR 都需要跑全部五个智能体。我们根据改动范围来决定跑哪些智能体只改文档的 PR 只跑风格智能体改配置文件的 PR 跑风格和安全智能体改业务逻辑的 PR 跑全部智能体。缓存是另一个手段。同一个文件在短时间内多次修改如果改动不大可以复用之前的审查结果。我们实现了一个简单的缓存机制基于文件内容和提示词版本做哈希命中缓存就直接返回之前的结果。模型选择也很重要。不是所有智能体都需要用最强的模型。风格智能体用轻量模型就够了安全智能体需要用能力更强的模型。我们实测下来混合使用不同规模的模型成本可以降低一半左右效果没有明显下降。5.6 开发者接受度与文化建设技术方案再好开发者不用也是白搭。推广多智能体代码审查系统技术只是一部分更重要的是文化建设。我们的经验是先做加法再做减法。最开始上线时只启用风格和逻辑两个智能体而且只作为建议不阻断合并。让开发者先习惯有 AI 参与审查这件事。等大家适应了再逐步启用安全智能体并设置阻断规则。透明化也很重要。我们会在团队会议上分享审查系统的统计数据发现了多少问题、避免了多少潜在事故、平均节省了多少审查时间。让开发者看到这套系统的价值而不是觉得它是个负担。允许反馈是长期运营的关键。我们建了一个反馈渠道开发者可以随时反馈误报、漏报、不好用的地方。每个月我们会根据反馈做一次优化并把优化结果同步给团队。让开发者感觉到他们的反馈被重视参与感会强很多。6. 我踩过的坑和最后分享的几个技巧先说几个我踩过的坑。第一个坑是过早追求全自动化。最开始我们想让系统自动修复所有风格问题并自动合并结果有一次自动修复引入了一个逻辑错误导致线上故障。后来我们改成自动修复只针对风格问题而且修复后需要人工确认才能合并。自动化是好事但在代码审查这个场景里人工确认的环节不能省。第二个坑是忽视提示词的维护成本。我们最开始觉得提示词写一次就行了结果发现随着代码库演进提示词需要不断调整。新框架、新库、新规范都需要更新到提示词里。后来我们把提示词维护纳入了常规迭代每两周 review 一次。第三个坑是没有设置合理的期望。上线前我们跟团队说这套系统能发现所有问题结果上线后发现漏报了一些大家的信任度一下子就降了。后来我们调整了说法这套系统是辅助工具能发现大部分常见问题但不能替代人工审查。期望管理做好了接受度反而更高。最后分享几个实用技巧。技巧一给每个智能体设置一个“静默期”同一个问题在同一个 PR 里只报告一次避免开发者被重复评论骚扰。技巧二审查评论里附上修复代码示例开发者可以直接复制粘贴采纳率会明显提高。技巧三定期清理历史审查记录只保留最近三个月的避免数据积累太多影响查询性能。技巧四给审查系统加一个“紧急跳过”开关遇到紧急发布时可以临时关闭审查避免阻塞流程。这套系统我们跑了半年多现在已经成为团队开发流程里不可或缺的一环。它不能替代人工审查但确实把人工审查的效率提高了很多。人工审查者可以把精力放在架构设计、业务逻辑这些 AI 不擅长的领域而把风格、安全、性能这些模式化的问题交给 AI。这个分工我觉得是未来代码审查的常态。