看到“Five Rust teams adopt LLM rules to protect human code review”这个信息我第一反应不是去查五个团队具体是谁而是盯着后半句看protect human code review。这个角度和很多团队的做法确实不一样。大多数人拿到 LLM 之后第一件事就是把整个 diff 丢进去让模型自由点评。结果很快就会出现一类评论这个函数太长建议拆分测试覆盖率还可以提高这个变量命名不够清晰。翻到最后reviewer 发现 clippy 已经报过的问题又被模型说了一遍。人工评审的时间没有被省下来反而多了一堆噪音。五个团队的做法换了一个方向先给 LLM 划边界再让它进入代码审查流程。LLM 不是替代人类 reviewer而是接手那些重复、机械、需要逐个文件扫一遍的检查项把真正需要判断力的部分留给人。下面按这个思路拆一遍为什么 Rust 团队适合这样接规则怎么设计完整流程什么样落地时哪些参数和指标值得盯出了问题优先排查哪里。1. 先说清楚LLM 规则到底保护的是什么1.1 不是把代码审查交给 LLM而是把人和模型的分工划出来代码审查本身是个高容错成本低的场景。一次误报不会让项目崩溃但十次没营养的评论足以让整个团队关掉这个机器人。普通 LLM 辅助审查之所以容易失败是因为模型没有编译环境、不掌握项目约定、不知道哪些问题是静态工具已经拦过的所以它最容易给出的评论恰恰是最泛的函数太长、建议加测试、命名可以更好。规则的作用是三个。第一限定范围。模型只能在规则列表内发表意见不能自由发挥。你允许它看 unsafe 块的安全注释它就不该去评论变量命名。第二限定格式。每条意见必须包含文件、行号、规则编号、证据、修复建议。格式稳定人工 review 才能快速扫读而不是在一堆散文里找重点。第三限定边界。没有把握的问题不要报。宁可漏掉也不编造。这里的“漏掉”不是问题真正的风险是模型为了显得有用而强行输出。所以“保护人工代码审查”保护的不是代码是人的注意力和团队对自动评审机制的信任。让 reviewer 相信每一条 AI 评论都值得花十秒看比让 AI 多报一百条问题重要得多。1.2 为什么 Rust 场景特别适合先做这件事Rust 生态里已经有一套很强的机械检查工具链。rustfmt 负责格式clippy 负责 lintrustc 负责类型、所有权和借用检查。这让一个非常关键的事实变得很清晰能编译通过、能通过 clippy 的代码依然可能存在语义层面问题。人工 review 真正要盯的是 unsafe 块的安全说明、trait 设计是否合理、错误处理有没有吞掉根因、并发共享状态是否安全、公共 API 变动会不会破坏下游、语义化版本是否需要调整。这些问题的共同点是需要读懂代码意图而不仅仅是扫描语法。它们刚好是 LLM 自由发挥时最容易说错的地方。Rust 还有一个现实因素编译通过不等于可维护unsafe 代码往往集中在少数文件里非常适合用规则锁定审查范围。你可以只让 LLM 看src/unsafe/、src/ffi/这类目录其他人不需要被机器打扰。1.3 五个团队方向不同接入方式为何高度一致五个团队涉及的代码库可能完全不同但接入方式收敛到了同一个模式先建规则库再上模型先小范围跑再扩大路径LLM 结果只做辅助不覆盖人工门禁。这背后不是巧合。代码审查是低容错场景团队对自动工具的信任建立起来很慢崩塌却很快。如果规则设计不合理模型评论里出现三条废话后面再想让人工 reviewer 认真看 AI 意见就难了。所以大多数成熟团队都会选择从“机器提候选人做判断”开始而不是追求全自动。2. 接入 LLM 规则前先搭好三层基础设施2.1 静态检查与格式化是前置条件不是可选项很多团队接入时犯的第一个错误是让 LLM 直接看 PR 代码没有先跑 cargo fmt 和 clippy。结果模型评论里出现“这里空格不一致”“这里可以改成map_or”这类问题。这些本来应该在 CI 阶段被机械地解决让模型去报等于把低价值噪音又搬回来了。更稳的顺序是先跑cargo fmt --check。再跑cargo clippy --all-targets -- -D warnings。静态检查全部通过后把 diff 交给规则引擎。规则引擎处理后再把候选问题交给 LLM 做语义判断。这样一层层过滤下来LLM 面对的不是原始 diff而是“静态工具查不出、但需要人工确认”的候选清单。模型被逼到它真正适合的位置上。注意CLI 或 CI 里不要省掉前置静态检查。LLM 不是 rustfmt 的替代品也不是 clippy 的替代品。2.2 规则分级拦截、建议、提示到底怎么分规则库不要只有一档。最好从一开始就分成三层避免后续全乱。级别用途是否阻塞 CI适合谁来判P0 拦截级格式、编译、明确违规的安全问题是clippy、rustc、脚本规则P1 建议级需要语义理解的问题否只建议规则引擎 LLMP2 提示级重构候选、命名、文档、测试建议否不通知LLM 可选输出P0 不能依赖 LLM 来判断。原因是模型有概率误报拿它当门禁会制造不稳定。像“非测试代码里出现unwrap()”“unsafe 块缺少 Safety 注释”这类问题用脚本和 clippy 配置就能精确匹配没必要让模型参与。P1 是 LLM 的主力。比如一个 unsafe 块虽然写了注释但注释没有解释前置条件和生命周期约束一个公共函数返回Result但错误分支把根因吞掉了一段异步代码在锁作用域里做了网络请求。这些判断需要“读懂代码意图”适合让模型给出候选。P2 只作为页面展示不进通知不进 CI。它的作用是让想深入看的人多一个参考不让它制造压力。2.3 模型服务、数据安全和上下文长度怎么处理模型服务这一层最优先考虑的是数据合规。代码是核心资产不能轻易发给不受控的外部服务。常见做法有三类团队内网自建模型服务代码不出内网合规压力最小。使用外部模型 API先对 diff 做脱敏再确认服务条款是否允许提交代码片段。使用开源模型本地部署把模型装到公司内部机器上由团队自己控制日志和留存。第二个问题是上下文长度。Rust 项目的语义通常分散在很多文件里一个函数的类型定义在types.rstrait 实现在另一个 crate调用点在测试目录。把整个仓库塞进 prompt 不现实也不能保证模型能抓住重点。更实用的做法是“按文件审查按需补充上下文”。一次只看一个文件的 diff把函数签名、相关结构体定义、关键 trait 实现拼到参考上下文里。如果新增代码超过 250 行就拆成多轮请求。单次审查控制在 200 到 400 行 diff 以内既省 token也减少模型注意力分散。第三个问题是版本固定。模型版本、prompt 版本、规则库版本都要固定。代码审查结果需要能回溯某一条评论是哪天、哪个模型、哪个规则版本生成的。没有版本管理后面很难排查“昨天不报、今天报”这类问题。3. 一次完整的 LLM 规则审查流程应该怎么设计3.1 从 diff 提取开始路径过滤、文件大小、上下文窗口完整流程可以按下面步骤拆。获得 PR 修改文件列表。过滤掉Cargo.lock、生成目录、vendor 目录、纯文档改动。对每个文件检查 diff 行数超过阈值就拆分。提取新增或修改的代码块同时把相关的类型定义、函数签名放进上下文字段。规则引擎先跑一遍可精确匹配的规则得到初步候选结果。把候选结果与代码块一起发送给 LLM让模型确认、补充证据、给出严重级别。关键在于第六步LLM 不必从零开始“找茬”而是在规则引擎划出的候选中做判断。这样既降低 token 消耗也减少幻觉。路径过滤这一步很容易被忽略。很多时候模型报出一个问题reviewer 点开一看文件是自动生成代码或第三方 vendor 代码根本不需要审。过滤规则要提前写好别等发生一次再补一次。3.2 Prompt 模板与 JSON 输出如何保持稳定Prompt 的稳定性决定了整个流程能不能自动化。建议至少包含这几块信息角色、审查边界、规则列表、输出格式、空输出处理。下面是一个我常用的伪模板实际字段需要按自己的规则库调整你是一名 Rust 代码审查助理。你只根据给定规则审查代码。 忽略格式、编译、clippy 已经覆盖的问题。 每条评论必须包含规则 id、严重级别、文件名、行号、证据和修复建议。 如果没有确认的问题只返回空数组。 规则列表 - rule_id: UNSAFE_INVARIANT_MISSING 描述: unsafe 块缺少或不充分地描述安全不变量。 - rule_id: ERROR_SWALLOWED 描述: 错误处理分支吞掉了原始错误上下文。 代码上下文 context {context} /context diff diff {diff} /diff 只输出 JSON不要输出解释。模型的输出应该是下面这种结构{ comments: [ { rule_id: UNSAFE_INVARIANT_MISSING, severity: warning, file: src/ffi/mod.rs, line: 42, title: unsafe 块缺少安全不变量说明, evidence: 该指针来自外部调用方但注释没有说明生命周期约束, suggestion: 补充 Safety 注释说明指针必须在调用期间保持有效 } ] }代码里一定要做 JSON 容错。模型经常会在 JSON 外面加 Markdown 围栏或者多输出一句解释。解析时先提取第一个{到最后一个}解析失败再重试一次。如果你现在没有这个容错建议尽快补上否则后续会一直在小问题上折腾。3.3 结果回填 CI标签、评论、通知各负责什么LLM 审查结果不能直接全量刷到 PR 页面。常见做法是先把结果聚合再做策略回填。P0 问题在静态检查阶段已经拦截LLM 一般不会看到。P1 问题以 bot 评论形式发出或者以 inline comment 形式写在对应行。P2 问题只做页面展示不通知 reviewer。同一个文件的多条评论要归并同一个规则 id 的重复问题要去重同一行多次命中取最高严重级别。CI 里建议单独设置一个状态检查例如名为AI Review / semantic的 check。结果可以是 success、neutral 或者 failed但要注意即使 LLM 服务超时也不应该阻塞代码合入。否则团队会被模型的稳定性拖住。更合理的做法是LLM 结果只作为建议状态真正是否合入仍然由静态检查和人工 reviewer 决定。模型挂了顶多标记为“AI 审查未完成”不制造阻断。3.4 先跑单 PR再开批量最小验证路径不要一上来就把所有 PR 都接入 LLM。我第一次验证时常用的路径是拿最近合并的 5 个 PR 做回放。用同样规则和模型跑一遍人工比对哪些评论有价值。只开启一个风险目录比如src/ffi/或src/unsafe/。先让 2 到 3 个 reviewer 试用一周看他们是否愿意继续保留 AI 评论。指标稳定后再扩大到全仓库。这一周里最值得看的不是 AI 报了多少条问题而是人工 reviewer 对 AI 评论的“已解决”“忽略”“有用”比例。如果大部分评论被忽略说明规则没有命中真实痛点。我一般建议从 P1 规则里挑 5 到 10 条最明确的先跑而不是把规则库建到 100 条再上线。先让团队建立信任再扩大范围。4. 五种团队的落地路径给你做参考五个团队具体做哪个方向不用太纠结。真正有价值的是它们在不同代码库上做的事归纳起来大概有五类。每类场景的规则重点和落地范围都不太一样。4.1 系统基础设施团队先保护高风险目录系统性基础设施 crate 往往是底层依赖改动会影响所有上层产品。这个场景下人工 review 的核心精力应该放在公共 API 兼容性、破坏性变更、错误处理、panic 路径上。落地时可以把 LLM 的审查范围缩小到src/api/、src/ffi/、src/lib.rs这类公共入口。规则集中在新增公开函数是否返回Result、是否可能在极端输入下 panic、错误路径是否回传了足够上下文、trait 约束是否被悄悄放宽。内部实现风格尽量不碰交给 clippy 和后续维护者自己决定。4.2 框架与开源库维护团队把规则当成贡献门槛开源库维护者面对大量外部贡献者水平差异大。很多新手提交的问题在第一个回合就会被格式、文档、测试覆盖度这类基础门槛卡住。人工维护者逐条去回这些意见很花时间。这个场景里LLM 规则可以作为初筛层自动检查文档注释是否齐全、是否包含相关测试用例、是否改了无关文件、错误处理路径是否完整。维护者看到的是过滤后的摘要而不是原始 diff。要注意的是AI 评论应该尽量给出修改建议语气保持中立不要变成“拒绝贡献者”的机器。目的是降低沟通成本不是提高门槛。4.3 嵌入式与底层团队重点盯 unsafe 和内存边界嵌入式 Rust 经常使用 unsafe 来访问寄存器、外设和内存映射。这类代码一旦出错调试成本非常高。规则可以这样定每个新增 unsafe 块必须有 Safety 注释。注释必须说明前置条件、生命周期、共享状态。LLM 对“注释是否充分”做判断而不是自己给出 unsafe 修改代码。这里要特别注意边界LLM 不直接修 unsafe 代码只负责提示人工 reviewer 重点关注。即使模型给出了修复方案也必须标注“未编译验证仅供参考”。底层代码的安全性最终还是要靠人的判断和测试覆盖兜底。4.4 CLI 工具团队围绕错误处理与输出稳定性CLI 工具 review 时最值得看的是错误链路、退出码、stdin/stdout 在管道环境下的可靠性以及错误信息是否对用户友好。静态工具很难判断“错误信息是否真正解释了原因”这一块比较适合 LLM。落地时可以扫描新增的unwrap()、expect()、panic!()路径并对错误信息的上下文做一致性判断。比如某个函数返回了空字符串错误但实际是权限问题说明错误信息没有传出来。这类规则很容易验证因为可以通过命令行用例回放。4.5 Web 服务团队把规则接进 CI 门禁用 actix-web、axum 这类框架写的 API 服务重点看请求处理、并发共享状态、锁持有范围、异步任务错误是否被吞掉、超时是否设置。这个场景和 CI 的集成可以做得更重一些。P0 仍然交给 clippy 和自研静态规则比如敏感接口没有鉴权、数据库连接没有超时等。LLM 可以作为“建议级门禁”接入输出 P1 问题。但不要把它当作发布门禁的唯一判断模型适合当带路党不适合当交警。5. 关键参数与验证指标怎么判断规则有没有真的保护到人5.1 流程指标reviewer 的注意力花在哪了接入前先记录一组基线数据每个 PR 平均人工评论数、reviewer 从接到通知到给出第一条有效评论的时间、人工 review 总耗时。接入后定期对比。我关注的核心不是评论总数下降而是人工评论的内容变了没有。如果人工评论从“建议改函数名”变成“这里并发锁的持有范围是不是太大了”说明 LLM 规则真的把人的注意力保护住了。另一个可以看的指标是 reviewer 每周是否需要重新“教育”提交者。很多团队里老 review 会反复提醒新人补充文档、处理错误分支。这些重复反馈完全可以由规则自动完成。如果 LLM 能把这些基础问题挡掉老 review 的负担会明显下降。5.2 质量指标误报率、漏报率、规则覆盖率怎么算代码审查质量不能只看模型输出数量要看这些输出是否真的被人工认可。建议统计这几类指标。指标计算方式合理起点AI 有效评论率有效评论数 / AI 总评论数大于 50%AI 误报率被判定无效的评论数 / AI 总评论数小于 20%重要问题漏报率人工发现且 AI 未发现的重要问题 / 重要问题总数尽量低平均单 PR 人工评论数人工评论总数 / PR 数对比接入前这里的“合理起点”只是经验范围不是标准。如果团队规则覆盖的场景很小数值会偏差很大。重点是通过这些指标判断规则库是否需要裁剪或补充。规则覆盖率这个概念容易被忽略。团队最关心的风险类别每类至少要有一条规则对应。如果这个季度重点是 unsafe 安全但规则库里没有 unsafe 相关规则就别指望 LLM 自发帮你覆盖。LLM 不会超越规则边界去保护你。5.3 模型参数温度、max_tokens、超时和重试代码审查是高精度任务不是创意写作。模型参数要往“稳定”方向调。temperature建议设 0 或 0.1。太高会让同样的 diff 每次跑出不同结果无法排查。top_p可以保持比较保守的值也可以不变影响通常小于 temperature。max_tokens给足避免 JSON 输出被截断同时设上限防止模型写长篇大论。超时单次调用建议 30 到 60 秒。超过就重试一次连续失败直接跳过该文件并标记未审查。并发根据模型服务限制调整通常 1 到 4 个并发足够。不要盲目拉高否则上游限流后整个流水线更慢。模型版本固定一个版本不要每周跟着更新跑。每次调整模型版本都要重新做历史 PR 回放。如果团队在本地自建模型还要考虑推理精度。用 fp16 或 bf16