代码审查这个环节最近正被 LLM 悄悄改变。但有意思的是真正成熟的 Rust 团队并不是急着让 AI 把人工 review 干掉而是反过来——用 LLM 规则把人从重复劳动里解放出来让人类 reviewer 把注意力留给真正需要判断力的地方。Five Rust teams adopt LLM rules to protect human code review这句话的关键词不是 replace而是 protect。这里有个很容易被忽略的判断code review 里真正有价值的部分从来不是盯着代码找空格、找拼写错误、找没写文档的 pub fn。人工审查的核心价值在于理解业务上下文、评估架构取舍、判断边界条件、识别安全风险而这些恰恰是 LLM 目前最不擅长做决定的部分。把机械劳动交给规则化的 LLM 检查把判断工作留给人类这才是这五个 Rust 团队落地 LLM rules 的真实意图。这篇文章会讲清楚这套思路怎么落地LLM rules 在 Rust 代码审查里到底能管什么、规则怎么写、怎么接入 CI、怎么设计“AI 预审 → 人工终审”的流程、批量审查怎么做、接口怎么调、遇到误报和隐私问题怎么处理。全文偏工程实践适合 Rust 项目维护者、DevOps 工程师以及正在给团队引入 AI 辅助开发流程的技术负责人阅读。1. 核心概念LLM rules 如何保护人工 code review1.1 先明确问题人工 code review 的困境大型 Rust 项目的 code review 有一个典型痛点PR 里大量改动是机械性的。例如新增公共 API 没有写///文档注释闭包参数可以简化为Self或impl Trait但保留了冗余写法和多余.clone()unwrap()出现在库代码或边界代码里缺少错误处理unsafe块出现但没有安全注释错误类型直接用String没有用thiserror或自定义错误新增依赖没有在Cargo.toml里说明用途格式化、命名不一致需要反复提醒。这些问题不是看不懂而是数量庞大且重复会消耗 reviewer 大量注意力和情绪。如果人工 reviewer 把 70% 的时间花在这些低价值检查上真正需要深度思考的架构、安全、数据一致性问题反而容易被一带而过。1.2 LLM rules 的定位第一层过滤器不是终审者从这几个 Rust 团队的实践看LLM rules 在 code review 里的角色很明确作为第一层过滤器和预检工具。它的任务是快速把明显问题标记出来给人工 reviewer 一份筛选后的清单让人类只需要看“值得判断”的部分。典型流程是开发者提交 PR → CI 拉取代码 → 提取 git diff → LLM 按规则批量审查 → 生成结构化的审查报告 → 人工 reviewer 基于报告做二次判断 → 高风险/存疑项由人类最终决定关键在于LLM 的输出是“建议”不是“结论”。规则引擎负责召回问题人工负责最终裁定。没有人工 review 兜底的自动化检查在这个场景里风险会很高。1.3 为什么是多个团队一起落地单个团队用 LLM 审查代码很容易写出偏主观的提示词规则覆盖不完整效果也难以横向比较。多个 Rust 团队一起落地意味着他们可以共享一套规则集、审查模板和效果评估标准并且把规则沉淀为团队规范的一部分。这样做的直接好处是规则可以版本化跟着仓库走新人接手时不用凭感觉写提示词误报和漏报可以汇总成修正反馈持续迭代规则集成本、速度、覆盖范围可以基于真实数据进行评估。所以这不是某个开发者写个 prompt 玩一玩而是把 LLM 引入 code review 流程后的一种工程化沉淀。2. 适用场景与使用边界2.1 适合用 LLM 审查的内容机械规范性检查。Rust 社区的编码规范相对统一cargo fmt和clippy已经解决了一部分但仍有大量“clippy 管不到、但人工一眼能看出来”的问题例如文档注释是否完整、错误处理是否合理、模块职责是否清晰。常见模式识别。LLM 对常见的 Rust 反模式识别效果不错比如不必要的clone()、可合并的 match 分支、可简化的迭代器链、冗余类型标注。这类问题有固定模式LLM 的识别稳定性和速度都高于人工初筛。变更影响说明。给定一个 diffLLM 可以生成变更摘要、影响范围、风险点提示。这项工作不需要高深判断但很耗时适合自动化。测试补充建议。LLM 可以根据新增函数自动建议测试用例方向人工决定是否采纳。2.2 必须保留人工审查的内容架构设计与模块边界。一个模块是否应该拆分、接口粒度是否合理、是否需要引入新的抽象层这些判断依赖对项目全貌和历史演进的理解LLM 不具备。安全影响评估。即使 LLM 发现了unsafe代码判断这个unsafe是否真的安全、内存布局是否正确、并发访问是否会导致数据竞争仍然需要熟悉体系结构和项目上下文的人类 reviewer。业务逻辑正确性。需求是否被正确实现、异常路径处理是否符合产品预期这类判断只能由理解业务的人完成。关键决策与回滚判断。代码合并前的最终签字、是否回滚、是否需要更多测试这些责任不能交给 AI。一句话总结LLM 负责“发现问题”人工负责“做决定”。越靠近语法和模式层自动化程度可以越高越靠近架构和业务层越要让人工介入。2.3 隐私与合规边界把源代码发送到外部 LLM API本身存在数据和版权风险。代码是团队最核心的资产之一一旦发送到第三方服务就超出了本地掌控范围。Rust 项目的 code review 场景尤其要注意公共开源项目使用外部 API 时要确认项目许可证和版权协议闭源商业项目优先考虑本地部署模型或使用企业内部网关涉及用户数据、密钥、内网地址的代码必须脱敏后再送审任何情况下LLM 的审查结果都只能作为参考合并权限必须保留在人类 reviewer 手里。合规不是一句空话。团队在引入 LLM code review 之前最好先和法务/安全团队确认数据流向和模型托管范围。3. 环境准备与前置条件3.1 Rust 工具链准备要在 Rust 项目里验证 LLM code review首先要有一个可运行的 Rust 工具链。Rust 官方推荐使用rustup管理工具链。国内开发者设置镜像可以明显提升安装和依赖拉取速度# 以 rustup 官方安装脚本为基础设置镜像环境变量 export RUSTUP_DIST_SERVERhttps://rsproxy.cn export RUSTUP_UPDATE_ROOThttps://rsproxy.cn/rustup curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh安装完成后确认版本rustc --version cargo --version同时配置 cargo 国内镜像把下面内容写入~/.cargo/config.toml可以显著加速依赖下载[source.crates-io] replace-with rsproxy-sparse [source.rsproxy-sparse] registry sparsehttps://rsproxy.cn/index/Rust 项目还需要rust-analyzer提供语言服务。在 VS Code 里安装 rust-analyzer 插件或直接在命令行确认rust-analyzer --version这一步方便后续本地验证代码补全和检查结果。3.2 代码审查工具链LLM 审查需要读取代码变更最通用的方式是读取 git diffgit diff origin/main...HEAD -- *.rs review.diff这条命令会提取当前分支相对于 main 分支的所有 Rust 文件变更保存为review.diff。后续 LLM 审查脚本可以直接读取这个文件。CI 集成时通常用 GitHub Actions 或 GitLab CI 在 PR 阶段自动执行这个提取流程。仓库的.github/workflows里可以放一个独立的审查 job专门跑 LLM 预检。3.3 LLM 模型与 API 选择这一步取决于团队的数据边界需求外部 API 方式。适合公共开源项目或对数据外发没有强限制的团队。优势是无需 GPU 资源模型能力强响应速度快维护成本低。缺点是 token 成本随审查量线性增长且代码库内容会经过第三方服务。本地部署方式。适合闭源项目和严苛的合规场景。本地部署需要 GPU 资源显存占用取决于模型大小和量化方式。一个 7B 级别的量化模型通常需要 6GB 以上显存但具体占用会因量化位数、上下文长度和推理框架不同而变化需以本机实测为准。优势是代码不出内网但部署和维护成本更高。无论哪种方式都要先准备一个可用的 LLM API endpoint。如果是外部 API通常需要 API Key如果是本地推理服务一般会暴露一个兼容接口。4. 规则配置与审查流程设计4.1 规则集的核心构成LLM code review 不能只靠一句“帮我 review 这段代码”。没有明确规则输出质量会非常不稳定。多个团队能一起落地核心原因就是他们把规则做成了可配置、可版本化的文件。一份 Rust 代码审查规则集通常包含四层规则层审查目标示例规范性命名、文档、格式化一致性公共 API 是否缺文档正确性常见错误、反模式unwrap 是否被滥用安全性unsafe、并发、边界条件unsafe 块是否附安全注释可维护性结构、依赖、可测试性错误处理是否合理规则文件可以用 YAML 或 JSON 维护放到仓库的.review/目录下随项目版本一起管理# .review/rules.yaml 示例 review: language: rust rules: - id: RUST-DOC-001 level: warning category: documentation description: 公共 API 必须包含文档注释 - id: RUST-ERR-001 level: warning category: error-handling description: 库代码不应直接使用 unwrap() - id: RUST-SAFE-001 level: critical category: safety description: unsafe 块必须附带安全说明注释 output_format: markdown这种规则文件的价值在于它把 LLM 的行为边界和团队编码规范绑定在一起。规则文件变了审查行为就变不需要每次改 prompt。4.2 提示词模板示例LLM 审查的提示词要结构化。直接粘贴代码让模型“看一看看出什么问题”很容易得到泛泛而谈的结果。更可靠的方式是把角色、规则、代码、输出格式全部固定在提示词里你是 Rust 代码审查助手。请基于以下规则集对给定 diff 进行审查。 规则 1. 公共 API 必须包含文档注释。 2. 库代码不应直接使用 unwrap()。 3. unsafe 块必须附带安全说明注释。 4. 新增依赖必须说明用途。 输出格式 按markdown表格输出列包含问题位置、问题描述、所属规则、严重级别、修复建议。 如果没有发现问题请回答未发现明显问题。这里的要点是输出格式必须固定。只有输出格式固定后续才能用脚本自动把审查结果解析成 CI 评论或报告否则每次返回的格式都不一样批量处理会非常痛苦。4.3 完整审查流程示例# 1. 提取变更 git fetch origin main git diff origin/main...HEAD -- *.rs review.diff # 2. 读取 diff 和规则文件 DIFF_CONTENT$(cat review.diff) RULES_CONTENT$(cat .review/rules.yaml) # 3. 将内容传给 LLM 审查脚本 # 具体命令取决于 LLM API 和本地脚本实现 python scripts/review.py --diff review.diff --rules .review/rules.yaml # 4. 人工审查生成的报告并做出最终决定实际落地时第二步和第三步会被封装到 CI 脚本里开发者只需要在 PR 里查看自动生成的审查评论。5. 功能测试与效果验证5.1 测试场景准备接入规则后第一步先做功能验证。不要直接拿线上大 PR 测试建议构造一个包含已知问题的小型 Rust 示例确认 LLM 能否稳定识别。下面是一个带几个故意问题的 Rust 函数use std::fs; pub fn read_config(path: str) - String { let data fs::read_to_string(path).unwrap(); data } pub fn parse_port(value: str) - u16 { value.parse().unwrap() }这个示例包含两个问题公共函数read_config没有文档注释库函数里直接使用了unwrap()没有错误处理parse_port对非法输入会直接 panic。把这段代码交给配置了规则集的 LLM 审查预期输出应该包括位置、问题描述、严重级别、修复建议。5.2 审查输出示例| 问题位置 | 问题描述 | 所属规则 | 严重级别 | 修复建议 | | --- | --- | --- | --- | --- | | src/config.rs:2 | 公共函数 read_config 缺少文档注释 | RUST-DOC-001 | warning | 添加以 /// 开头的文档注释 | | src/config.rs:4 | 直接调用 unwrap()输入路径无效时 panic | RUST-ERR-001 | warning | 改用 Result 返回错误信息 | | src/config.rs:9 | parse_port 对非法输入直接 panic | RUST-ERR-001 | critical | 返回 Resultu16, ParseIntError |5.3 判断成功与否的标准功能验证是否通过可以从三个维度评估召回率。已知的问题是否都被识别出来。漏掉一个都说明规则集或提示词需要修正。定位准确度。问题位置是否正确。如果 LLM 报的位置和真实位置偏差很大后续自动评论就无法做到精确定位。格式稳定性。多次运行时输出格式是否一致。如果 10 次有 8 次格式不同说明提示词约束不够强。5.4 失败排查现象可能原因排查方式已知问题未被识别规则描述太模糊或提示词里规则丢失检查规则文件是否被正确注入把规则描述写得更明确输出格式不固定提示词约束不足在提示词中加强输出格式要求或在解析脚本中增加容错大量误报规则层级划分不合理先按 severity 过滤只把 warning 以上级别发送到人工 review开始阶段 token 消耗过高整个文件被重复发送只发送 diff不要发送完整文件人工 review 最怕的不是 LLM 报错而是报出来的问题不值得看。规则集的迭代方向就是不断降低误报率让报告真正可读。6. 接口 API 与批量任务6.1 LLM API 通用调用方式无论使用外部 API 还是本地推理服务Rust 项目做 code review 时最常用的方式是 HTTP 调用。下面是 Python 的通用调用模板实际使用时需要按你的模型接口、鉴权方式和输出格式调整import requests url http://127.0.0.1:8000/v1/chat/completions headers { Content-Type: application/json, Authorization: Bearer YOUR_API_KEY } system_prompt 你是 Rust 代码审查助手严格按照规则输出 markdown 表格。 user_prompt 请审查下面这段 Rust 代码 def read_config(path: str) - String { let data fs::read_to_string(path).unwrap(); data } payload { model: your-model-name, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperature: 0.1, max_tokens: 1000 } response requests.post(url, jsonpayload, headersheaders, timeout120) print(response.json()[choices][0][message][content])注意点temperature要设置得很低比如 0.1code review 需要确定性输出timeout 要设置足够长尤其是本地模型推理时间可能明显超过外部 API每个请求只审查一个 diff 或者一个文件不要一次性塞入过多上下文否则输出质量会下降。6.2 批量审查多个文件Rust PR 通常涉及多个文件。批量审查要设计成一个可控的队列任务而不是循环调用 API 然后把结果拼在一起。建议流程输入PR 变更文件列表 → 逐个文件生成 diff → 过滤大小超限或二进制文件 → 按文件优先级排列队列 → 逐文件调用 LLM 审查 → 汇总为单个 markdown 报告 → 人工检查批量脚本可以参考下面的骨架逻辑import subprocess import requests import time files subprocess.check_output( [git, diff, origin/main...HEAD, --name-only, --, *.rs], textTrue ).strip().splitlines() results [] for f in files: diff subprocess.check_output( [git, diff, origin/main...HEAD, --, f], textTrue ) # 这里调用 LLM API伪代码需按实际接口调整 result call_llm_review(diff) results.append({file: f, result: result}) # 控制请求频率避免触发速率限制 time.sleep(1) with open(review_report.md, w) as fp: fp.write(# LLM Code Review Report\n) for item in results: fp.write(f## {item[file]}\n) fp.write(item[result]) fp.write(\n)批量处理的三个要点单文件失败不影响整体任务。某个文件调用超时或返回异常时记录错误并继续后续文件。上下文长度控制。diff 过长时要截断或分段超出模型上下文会导致输出截断或丢失。失败重试。API 返回 429 或 5xx 时指数退避重试是基本操作。6.3 在 PR 中自动生成评论批量报告生成后可以通过 GitHub CLI 把结果追加到 PR 评论gh pr comment PR_NUMBER --body-file review_report.md或者通过 GitHub API 直接提交 review 评论。这个环节把 LLM 的审查结果直接送回到开发者工作流里人工 reviewer 只需要打开 PR 看评论再决定哪些意见真正值得跟进。7. 资源占用与性能观察7.1 本地推理 vs API这是接入 LLM code review 时最先要做的评估。外部 API 模式本地不需要 GPU资源占用几乎可以忽略但请求会受到网络延迟、限流和 token 费用的影响。对于小型 Rust 项目外部 API 模式启动最快成本也比较容易估算。本地推理模式需要准备 GPU 资源和模型文件。显存占用取决于模型参数量、量化精度和单次请求的上下文长度。实测时重点观察推理延迟、显存峰值、多并发请求时的稳定性。在接入正式流程前建议先用一个真实 PR 的 diff 做压测确认模型在目标上下文长度下不会 OOM。7.2 显存与性能观察方法本地部署模型时观察资源占用可以用nvidia-smiwatch -n 1 nvidia-smi重点看两个指标Memory-Usage推理过程中显存峰值判断当前配置是否可稳定运行GPU-Util实际计算利用率判断瓶颈是否在算力上。上下文越长显存占用越高。审查大型 Rust 文件时diff 尽量按文件拆分不要一次把所有变更塞进同一个请求。7.3 Token 成本控制LLM API 模式下的成本主要由 token 数量决定。审查一个 Rust PR 的 token 消耗通常包括输入 diff、规则文件和输出报告三部分。降低成本的常见手段只审查*.rs文件忽略锁文件和生成代码按文件拆分请求避免重复发送无关内容设置max_tokens限制输出长度低风险 PR 可以只做规则检查不生成详细解释对规则做分级不是所有规则都需要每次都跑。实际成本会因模型、上下文长度和输出长度差异明显建议先在干净的小 PR 上记录 token 消耗再估算整月成本。8. 常见问题与排查方法问题现象可能原因排查方式解决方案LLM 审查结果非常泛泛而谈没有给规则文件或提示词太宽泛检查请求是否真正传入了规则集将规则文件和提示词模板固定到仓库并版本化多个文件审查时输出混乱批量脚本没有按文件拆分结果检查每个文件的输出是否单独解析每个文件独立报告最后统一汇总审查报告大量误报规则描述不具体或严重级别混乱记录每个误报对应的规则和置信度迭代规则文件细化描述降低低价值规则级别API 报错或超时网络问题或模型推理过慢检查日志和响应时间增大 timeout增加指数退避重试本地模型显存不足模型太大或上下文太长用 nvidia-smi 观察峰值换更小模型或降低量化精度拆分长 diff代码库包含敏感信息密钥、内网地址被发送到外部 API审查请求日志检查 data 流向增加脱敏脚本或切换到本地部署审查结果与代码实际不符模型幻觉或 diff 提取不完整核对审查脚本读取的 diff 内容固定 diff 提取方式必要时同时提供文件路径和上下文PR 评论位置不精确LLM 无法精确到行号检查输出是否包含行号字段在提示词中明确要求行号或改为按函数维度给建议这里最容易踩的坑是LLM 会一本正经地给出不存在的行号或函数名。解决方案是提示词里明确要求“只报告 diff 中实际存在的行号”并在解析脚本里对位置的合法性做校验。9. 最佳实践与使用建议9.1 先建立“人工终审”机制再接入 LLM把 LLM 引入 code review 的前提不是 LLM 审查得有多准而是团队保留完整的人工 review 流程。LLM 只是预检工具合并权限永远在人类 reviewer 手里。如果团队原本就没有 code review 规范先补流程再谈自动化。9.2 规则文件入库随项目版本演进规则文件不是一次写死就完了。每次出现误报、漏报或新规范都要更新规则文件。建议规则文件放在仓库根目录的.review/下通过 PR 的形式变更这样规则本身也被 code review。9.3 分阶段落地建议按这四步推进离线试用。先用最近 10 个已合入的 PR让 LLM 生成审查报告比对人工 review 结果统计漏报和误报只读接入。在 CI 上跑 LLM 审查但只输出报告不阻塞合入人工采纳。开发者自己决定是否参考 LLM 建议规则收紧。在误报率足够低之后再把部分规则提升为“必须清零”的硬性检查。9.4 保护代码资产代码审查比一般的文本生成更接近核心资产边界。外部 API 方案要格外谨慎先确认项目许可证、代码敏感程度和法务要求。闭源团队如果条件允许优先考虑本地推理。不能为了省 GPU 成本把客户数据、密钥或未发布功能泄漏到外部服务里。9.5 前置脱敏措施即使使用外部 API也应该加一层自动脱敏替换疑似密钥、token、密码的字段替换内网 IP 和域名删除注释中的敏感信息检查 diff 中是否包含AK/SK、private key、BEGIN关键字等。脱敏脚本可以放在 CI 的审查 job 里和 diff 提取同步执行。10. 总结与下一步这次梳理了五个 Rust 团队把 LLM rules 引入 code review 的核心理念和落地路径。真正值得关注的不是“AI 审查代码有多准”而是流程设计上让 AI 和人类各司其职LLM 负责快速过滤和标记人类负责判断和决策。规则集是这套流程的关键资产必须做成可配置、可版本化、可迭代的文件而不是随手贴在提示词里的一句话。对于 Rust 项目团队下一步建议从三步开始用最近合入的 PR 做一次离线评测记录 LLM 审查结果和人工 review 结果的差异写一个最小化的规则文件先覆盖文档注释、错误处理、unsafe 安全注释这几类高频问题在 CI 上以“不阻塞合入”的方式运行一周收集误报数据再决定是否把规则升级为强制项。最容易踩的坑有两个一是把 LLM 输出当结论省掉人工 review二是规则集不维护第一次跑完就不更新导致误报率越来越高、报告没人看。建议收藏备用。如果你正在给团队的 Rust 项目搭建 LLM 辅助 code review 流程先从最小规则集和离线评测开始跑通后再逐步扩大覆盖范围这是一条稳妥且可回退的路线。 Rust团队用LLM规则守护人工Code Review的工程实践
代码审查这个环节最近正被 LLM 悄悄改变。但有意思的是真正成熟的 Rust 团队并不是急着让 AI 把人工 review 干掉而是反过来——用 LLM 规则把人从重复劳动里解放出来让人类 reviewer 把注意力留给真正需要判断力的地方。Five Rust teams adopt LLM rules to protect human code review这句话的关键词不是 replace而是 protect。这里有个很容易被忽略的判断code review 里真正有价值的部分从来不是盯着代码找空格、找拼写错误、找没写文档的 pub fn。人工审查的核心价值在于理解业务上下文、评估架构取舍、判断边界条件、识别安全风险而这些恰恰是 LLM 目前最不擅长做决定的部分。把机械劳动交给规则化的 LLM 检查把判断工作留给人类这才是这五个 Rust 团队落地 LLM rules 的真实意图。这篇文章会讲清楚这套思路怎么落地LLM rules 在 Rust 代码审查里到底能管什么、规则怎么写、怎么接入 CI、怎么设计“AI 预审 → 人工终审”的流程、批量审查怎么做、接口怎么调、遇到误报和隐私问题怎么处理。全文偏工程实践适合 Rust 项目维护者、DevOps 工程师以及正在给团队引入 AI 辅助开发流程的技术负责人阅读。1. 核心概念LLM rules 如何保护人工 code review1.1 先明确问题人工 code review 的困境大型 Rust 项目的 code review 有一个典型痛点PR 里大量改动是机械性的。例如新增公共 API 没有写///文档注释闭包参数可以简化为Self或impl Trait但保留了冗余写法和多余.clone()unwrap()出现在库代码或边界代码里缺少错误处理unsafe块出现但没有安全注释错误类型直接用String没有用thiserror或自定义错误新增依赖没有在Cargo.toml里说明用途格式化、命名不一致需要反复提醒。这些问题不是看不懂而是数量庞大且重复会消耗 reviewer 大量注意力和情绪。如果人工 reviewer 把 70% 的时间花在这些低价值检查上真正需要深度思考的架构、安全、数据一致性问题反而容易被一带而过。1.2 LLM rules 的定位第一层过滤器不是终审者从这几个 Rust 团队的实践看LLM rules 在 code review 里的角色很明确作为第一层过滤器和预检工具。它的任务是快速把明显问题标记出来给人工 reviewer 一份筛选后的清单让人类只需要看“值得判断”的部分。典型流程是开发者提交 PR → CI 拉取代码 → 提取 git diff → LLM 按规则批量审查 → 生成结构化的审查报告 → 人工 reviewer 基于报告做二次判断 → 高风险/存疑项由人类最终决定关键在于LLM 的输出是“建议”不是“结论”。规则引擎负责召回问题人工负责最终裁定。没有人工 review 兜底的自动化检查在这个场景里风险会很高。1.3 为什么是多个团队一起落地单个团队用 LLM 审查代码很容易写出偏主观的提示词规则覆盖不完整效果也难以横向比较。多个 Rust 团队一起落地意味着他们可以共享一套规则集、审查模板和效果评估标准并且把规则沉淀为团队规范的一部分。这样做的直接好处是规则可以版本化跟着仓库走新人接手时不用凭感觉写提示词误报和漏报可以汇总成修正反馈持续迭代规则集成本、速度、覆盖范围可以基于真实数据进行评估。所以这不是某个开发者写个 prompt 玩一玩而是把 LLM 引入 code review 流程后的一种工程化沉淀。2. 适用场景与使用边界2.1 适合用 LLM 审查的内容机械规范性检查。Rust 社区的编码规范相对统一cargo fmt和clippy已经解决了一部分但仍有大量“clippy 管不到、但人工一眼能看出来”的问题例如文档注释是否完整、错误处理是否合理、模块职责是否清晰。常见模式识别。LLM 对常见的 Rust 反模式识别效果不错比如不必要的clone()、可合并的 match 分支、可简化的迭代器链、冗余类型标注。这类问题有固定模式LLM 的识别稳定性和速度都高于人工初筛。变更影响说明。给定一个 diffLLM 可以生成变更摘要、影响范围、风险点提示。这项工作不需要高深判断但很耗时适合自动化。测试补充建议。LLM 可以根据新增函数自动建议测试用例方向人工决定是否采纳。2.2 必须保留人工审查的内容架构设计与模块边界。一个模块是否应该拆分、接口粒度是否合理、是否需要引入新的抽象层这些判断依赖对项目全貌和历史演进的理解LLM 不具备。安全影响评估。即使 LLM 发现了unsafe代码判断这个unsafe是否真的安全、内存布局是否正确、并发访问是否会导致数据竞争仍然需要熟悉体系结构和项目上下文的人类 reviewer。业务逻辑正确性。需求是否被正确实现、异常路径处理是否符合产品预期这类判断只能由理解业务的人完成。关键决策与回滚判断。代码合并前的最终签字、是否回滚、是否需要更多测试这些责任不能交给 AI。一句话总结LLM 负责“发现问题”人工负责“做决定”。越靠近语法和模式层自动化程度可以越高越靠近架构和业务层越要让人工介入。2.3 隐私与合规边界把源代码发送到外部 LLM API本身存在数据和版权风险。代码是团队最核心的资产之一一旦发送到第三方服务就超出了本地掌控范围。Rust 项目的 code review 场景尤其要注意公共开源项目使用外部 API 时要确认项目许可证和版权协议闭源商业项目优先考虑本地部署模型或使用企业内部网关涉及用户数据、密钥、内网地址的代码必须脱敏后再送审任何情况下LLM 的审查结果都只能作为参考合并权限必须保留在人类 reviewer 手里。合规不是一句空话。团队在引入 LLM code review 之前最好先和法务/安全团队确认数据流向和模型托管范围。3. 环境准备与前置条件3.1 Rust 工具链准备要在 Rust 项目里验证 LLM code review首先要有一个可运行的 Rust 工具链。Rust 官方推荐使用rustup管理工具链。国内开发者设置镜像可以明显提升安装和依赖拉取速度# 以 rustup 官方安装脚本为基础设置镜像环境变量 export RUSTUP_DIST_SERVERhttps://rsproxy.cn export RUSTUP_UPDATE_ROOThttps://rsproxy.cn/rustup curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh安装完成后确认版本rustc --version cargo --version同时配置 cargo 国内镜像把下面内容写入~/.cargo/config.toml可以显著加速依赖下载[source.crates-io] replace-with rsproxy-sparse [source.rsproxy-sparse] registry sparsehttps://rsproxy.cn/index/Rust 项目还需要rust-analyzer提供语言服务。在 VS Code 里安装 rust-analyzer 插件或直接在命令行确认rust-analyzer --version这一步方便后续本地验证代码补全和检查结果。3.2 代码审查工具链LLM 审查需要读取代码变更最通用的方式是读取 git diffgit diff origin/main...HEAD -- *.rs review.diff这条命令会提取当前分支相对于 main 分支的所有 Rust 文件变更保存为review.diff。后续 LLM 审查脚本可以直接读取这个文件。CI 集成时通常用 GitHub Actions 或 GitLab CI 在 PR 阶段自动执行这个提取流程。仓库的.github/workflows里可以放一个独立的审查 job专门跑 LLM 预检。3.3 LLM 模型与 API 选择这一步取决于团队的数据边界需求外部 API 方式。适合公共开源项目或对数据外发没有强限制的团队。优势是无需 GPU 资源模型能力强响应速度快维护成本低。缺点是 token 成本随审查量线性增长且代码库内容会经过第三方服务。本地部署方式。适合闭源项目和严苛的合规场景。本地部署需要 GPU 资源显存占用取决于模型大小和量化方式。一个 7B 级别的量化模型通常需要 6GB 以上显存但具体占用会因量化位数、上下文长度和推理框架不同而变化需以本机实测为准。优势是代码不出内网但部署和维护成本更高。无论哪种方式都要先准备一个可用的 LLM API endpoint。如果是外部 API通常需要 API Key如果是本地推理服务一般会暴露一个兼容接口。4. 规则配置与审查流程设计4.1 规则集的核心构成LLM code review 不能只靠一句“帮我 review 这段代码”。没有明确规则输出质量会非常不稳定。多个团队能一起落地核心原因就是他们把规则做成了可配置、可版本化的文件。一份 Rust 代码审查规则集通常包含四层规则层审查目标示例规范性命名、文档、格式化一致性公共 API 是否缺文档正确性常见错误、反模式unwrap 是否被滥用安全性unsafe、并发、边界条件unsafe 块是否附安全注释可维护性结构、依赖、可测试性错误处理是否合理规则文件可以用 YAML 或 JSON 维护放到仓库的.review/目录下随项目版本一起管理# .review/rules.yaml 示例 review: language: rust rules: - id: RUST-DOC-001 level: warning category: documentation description: 公共 API 必须包含文档注释 - id: RUST-ERR-001 level: warning category: error-handling description: 库代码不应直接使用 unwrap() - id: RUST-SAFE-001 level: critical category: safety description: unsafe 块必须附带安全说明注释 output_format: markdown这种规则文件的价值在于它把 LLM 的行为边界和团队编码规范绑定在一起。规则文件变了审查行为就变不需要每次改 prompt。4.2 提示词模板示例LLM 审查的提示词要结构化。直接粘贴代码让模型“看一看看出什么问题”很容易得到泛泛而谈的结果。更可靠的方式是把角色、规则、代码、输出格式全部固定在提示词里你是 Rust 代码审查助手。请基于以下规则集对给定 diff 进行审查。 规则 1. 公共 API 必须包含文档注释。 2. 库代码不应直接使用 unwrap()。 3. unsafe 块必须附带安全说明注释。 4. 新增依赖必须说明用途。 输出格式 按markdown表格输出列包含问题位置、问题描述、所属规则、严重级别、修复建议。 如果没有发现问题请回答未发现明显问题。这里的要点是输出格式必须固定。只有输出格式固定后续才能用脚本自动把审查结果解析成 CI 评论或报告否则每次返回的格式都不一样批量处理会非常痛苦。4.3 完整审查流程示例# 1. 提取变更 git fetch origin main git diff origin/main...HEAD -- *.rs review.diff # 2. 读取 diff 和规则文件 DIFF_CONTENT$(cat review.diff) RULES_CONTENT$(cat .review/rules.yaml) # 3. 将内容传给 LLM 审查脚本 # 具体命令取决于 LLM API 和本地脚本实现 python scripts/review.py --diff review.diff --rules .review/rules.yaml # 4. 人工审查生成的报告并做出最终决定实际落地时第二步和第三步会被封装到 CI 脚本里开发者只需要在 PR 里查看自动生成的审查评论。5. 功能测试与效果验证5.1 测试场景准备接入规则后第一步先做功能验证。不要直接拿线上大 PR 测试建议构造一个包含已知问题的小型 Rust 示例确认 LLM 能否稳定识别。下面是一个带几个故意问题的 Rust 函数use std::fs; pub fn read_config(path: str) - String { let data fs::read_to_string(path).unwrap(); data } pub fn parse_port(value: str) - u16 { value.parse().unwrap() }这个示例包含两个问题公共函数read_config没有文档注释库函数里直接使用了unwrap()没有错误处理parse_port对非法输入会直接 panic。把这段代码交给配置了规则集的 LLM 审查预期输出应该包括位置、问题描述、严重级别、修复建议。5.2 审查输出示例| 问题位置 | 问题描述 | 所属规则 | 严重级别 | 修复建议 | | --- | --- | --- | --- | --- | | src/config.rs:2 | 公共函数 read_config 缺少文档注释 | RUST-DOC-001 | warning | 添加以 /// 开头的文档注释 | | src/config.rs:4 | 直接调用 unwrap()输入路径无效时 panic | RUST-ERR-001 | warning | 改用 Result 返回错误信息 | | src/config.rs:9 | parse_port 对非法输入直接 panic | RUST-ERR-001 | critical | 返回 Resultu16, ParseIntError |5.3 判断成功与否的标准功能验证是否通过可以从三个维度评估召回率。已知的问题是否都被识别出来。漏掉一个都说明规则集或提示词需要修正。定位准确度。问题位置是否正确。如果 LLM 报的位置和真实位置偏差很大后续自动评论就无法做到精确定位。格式稳定性。多次运行时输出格式是否一致。如果 10 次有 8 次格式不同说明提示词约束不够强。5.4 失败排查现象可能原因排查方式已知问题未被识别规则描述太模糊或提示词里规则丢失检查规则文件是否被正确注入把规则描述写得更明确输出格式不固定提示词约束不足在提示词中加强输出格式要求或在解析脚本中增加容错大量误报规则层级划分不合理先按 severity 过滤只把 warning 以上级别发送到人工 review开始阶段 token 消耗过高整个文件被重复发送只发送 diff不要发送完整文件人工 review 最怕的不是 LLM 报错而是报出来的问题不值得看。规则集的迭代方向就是不断降低误报率让报告真正可读。6. 接口 API 与批量任务6.1 LLM API 通用调用方式无论使用外部 API 还是本地推理服务Rust 项目做 code review 时最常用的方式是 HTTP 调用。下面是 Python 的通用调用模板实际使用时需要按你的模型接口、鉴权方式和输出格式调整import requests url http://127.0.0.1:8000/v1/chat/completions headers { Content-Type: application/json, Authorization: Bearer YOUR_API_KEY } system_prompt 你是 Rust 代码审查助手严格按照规则输出 markdown 表格。 user_prompt 请审查下面这段 Rust 代码 def read_config(path: str) - String { let data fs::read_to_string(path).unwrap(); data } payload { model: your-model-name, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperature: 0.1, max_tokens: 1000 } response requests.post(url, jsonpayload, headersheaders, timeout120) print(response.json()[choices][0][message][content])注意点temperature要设置得很低比如 0.1code review 需要确定性输出timeout 要设置足够长尤其是本地模型推理时间可能明显超过外部 API每个请求只审查一个 diff 或者一个文件不要一次性塞入过多上下文否则输出质量会下降。6.2 批量审查多个文件Rust PR 通常涉及多个文件。批量审查要设计成一个可控的队列任务而不是循环调用 API 然后把结果拼在一起。建议流程输入PR 变更文件列表 → 逐个文件生成 diff → 过滤大小超限或二进制文件 → 按文件优先级排列队列 → 逐文件调用 LLM 审查 → 汇总为单个 markdown 报告 → 人工检查批量脚本可以参考下面的骨架逻辑import subprocess import requests import time files subprocess.check_output( [git, diff, origin/main...HEAD, --name-only, --, *.rs], textTrue ).strip().splitlines() results [] for f in files: diff subprocess.check_output( [git, diff, origin/main...HEAD, --, f], textTrue ) # 这里调用 LLM API伪代码需按实际接口调整 result call_llm_review(diff) results.append({file: f, result: result}) # 控制请求频率避免触发速率限制 time.sleep(1) with open(review_report.md, w) as fp: fp.write(# LLM Code Review Report\n) for item in results: fp.write(f## {item[file]}\n) fp.write(item[result]) fp.write(\n)批量处理的三个要点单文件失败不影响整体任务。某个文件调用超时或返回异常时记录错误并继续后续文件。上下文长度控制。diff 过长时要截断或分段超出模型上下文会导致输出截断或丢失。失败重试。API 返回 429 或 5xx 时指数退避重试是基本操作。6.3 在 PR 中自动生成评论批量报告生成后可以通过 GitHub CLI 把结果追加到 PR 评论gh pr comment PR_NUMBER --body-file review_report.md或者通过 GitHub API 直接提交 review 评论。这个环节把 LLM 的审查结果直接送回到开发者工作流里人工 reviewer 只需要打开 PR 看评论再决定哪些意见真正值得跟进。7. 资源占用与性能观察7.1 本地推理 vs API这是接入 LLM code review 时最先要做的评估。外部 API 模式本地不需要 GPU资源占用几乎可以忽略但请求会受到网络延迟、限流和 token 费用的影响。对于小型 Rust 项目外部 API 模式启动最快成本也比较容易估算。本地推理模式需要准备 GPU 资源和模型文件。显存占用取决于模型参数量、量化精度和单次请求的上下文长度。实测时重点观察推理延迟、显存峰值、多并发请求时的稳定性。在接入正式流程前建议先用一个真实 PR 的 diff 做压测确认模型在目标上下文长度下不会 OOM。7.2 显存与性能观察方法本地部署模型时观察资源占用可以用nvidia-smiwatch -n 1 nvidia-smi重点看两个指标Memory-Usage推理过程中显存峰值判断当前配置是否可稳定运行GPU-Util实际计算利用率判断瓶颈是否在算力上。上下文越长显存占用越高。审查大型 Rust 文件时diff 尽量按文件拆分不要一次把所有变更塞进同一个请求。7.3 Token 成本控制LLM API 模式下的成本主要由 token 数量决定。审查一个 Rust PR 的 token 消耗通常包括输入 diff、规则文件和输出报告三部分。降低成本的常见手段只审查*.rs文件忽略锁文件和生成代码按文件拆分请求避免重复发送无关内容设置max_tokens限制输出长度低风险 PR 可以只做规则检查不生成详细解释对规则做分级不是所有规则都需要每次都跑。实际成本会因模型、上下文长度和输出长度差异明显建议先在干净的小 PR 上记录 token 消耗再估算整月成本。8. 常见问题与排查方法问题现象可能原因排查方式解决方案LLM 审查结果非常泛泛而谈没有给规则文件或提示词太宽泛检查请求是否真正传入了规则集将规则文件和提示词模板固定到仓库并版本化多个文件审查时输出混乱批量脚本没有按文件拆分结果检查每个文件的输出是否单独解析每个文件独立报告最后统一汇总审查报告大量误报规则描述不具体或严重级别混乱记录每个误报对应的规则和置信度迭代规则文件细化描述降低低价值规则级别API 报错或超时网络问题或模型推理过慢检查日志和响应时间增大 timeout增加指数退避重试本地模型显存不足模型太大或上下文太长用 nvidia-smi 观察峰值换更小模型或降低量化精度拆分长 diff代码库包含敏感信息密钥、内网地址被发送到外部 API审查请求日志检查 data 流向增加脱敏脚本或切换到本地部署审查结果与代码实际不符模型幻觉或 diff 提取不完整核对审查脚本读取的 diff 内容固定 diff 提取方式必要时同时提供文件路径和上下文PR 评论位置不精确LLM 无法精确到行号检查输出是否包含行号字段在提示词中明确要求行号或改为按函数维度给建议这里最容易踩的坑是LLM 会一本正经地给出不存在的行号或函数名。解决方案是提示词里明确要求“只报告 diff 中实际存在的行号”并在解析脚本里对位置的合法性做校验。9. 最佳实践与使用建议9.1 先建立“人工终审”机制再接入 LLM把 LLM 引入 code review 的前提不是 LLM 审查得有多准而是团队保留完整的人工 review 流程。LLM 只是预检工具合并权限永远在人类 reviewer 手里。如果团队原本就没有 code review 规范先补流程再谈自动化。9.2 规则文件入库随项目版本演进规则文件不是一次写死就完了。每次出现误报、漏报或新规范都要更新规则文件。建议规则文件放在仓库根目录的.review/下通过 PR 的形式变更这样规则本身也被 code review。9.3 分阶段落地建议按这四步推进离线试用。先用最近 10 个已合入的 PR让 LLM 生成审查报告比对人工 review 结果统计漏报和误报只读接入。在 CI 上跑 LLM 审查但只输出报告不阻塞合入人工采纳。开发者自己决定是否参考 LLM 建议规则收紧。在误报率足够低之后再把部分规则提升为“必须清零”的硬性检查。9.4 保护代码资产代码审查比一般的文本生成更接近核心资产边界。外部 API 方案要格外谨慎先确认项目许可证、代码敏感程度和法务要求。闭源团队如果条件允许优先考虑本地推理。不能为了省 GPU 成本把客户数据、密钥或未发布功能泄漏到外部服务里。9.5 前置脱敏措施即使使用外部 API也应该加一层自动脱敏替换疑似密钥、token、密码的字段替换内网 IP 和域名删除注释中的敏感信息检查 diff 中是否包含AK/SK、private key、BEGIN关键字等。脱敏脚本可以放在 CI 的审查 job 里和 diff 提取同步执行。10. 总结与下一步这次梳理了五个 Rust 团队把 LLM rules 引入 code review 的核心理念和落地路径。真正值得关注的不是“AI 审查代码有多准”而是流程设计上让 AI 和人类各司其职LLM 负责快速过滤和标记人类负责判断和决策。规则集是这套流程的关键资产必须做成可配置、可版本化、可迭代的文件而不是随手贴在提示词里的一句话。对于 Rust 项目团队下一步建议从三步开始用最近合入的 PR 做一次离线评测记录 LLM 审查结果和人工 review 结果的差异写一个最小化的规则文件先覆盖文档注释、错误处理、unsafe 安全注释这几类高频问题在 CI 上以“不阻塞合入”的方式运行一周收集误报数据再决定是否把规则升级为强制项。最容易踩的坑有两个一是把 LLM 输出当结论省掉人工 review二是规则集不维护第一次跑完就不更新导致误报率越来越高、报告没人看。建议收藏备用。如果你正在给团队的 Rust 项目搭建 LLM 辅助 code review 流程先从最小规则集和离线评测开始跑通后再逐步扩大覆盖范围这是一条稳妥且可回退的路线。