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。这个分工，我觉得是未来代码审查的常态。
