最近 Rust 社区有一则消息值得关注五个知名的 Rust 团队开始引入“LLM 规则”来辅助代码审查但目的并不是让 AI 替代人类 Reviewer而是反过来——保护人类 Code Review 的时间和注意力。这件事很容易被误读成“AI 接管代码审查”但实际上它背后的技术判断要克制得多LLM 只负责处理机械性、重复性的检查人只负责真正需要判断力的部分。这篇文章会从 Code Review 的现状痛点讲起解释这套“LLM 规则”到底在解决什么问题然后落到 Rust 项目里可以怎么落地实践最后给出明确的边界建议。如果你是 Rust 开发者或者正在团队里推动 Code Review 流程改进这篇文章应该能帮你省下不少沟通成本。1. 代码审查的真实困境不是质量问题是注意力问题先说一个可能有点反直觉的判断现代软件开发里代码审查的真正瓶颈不是“代码质量”而是“人类评审者的注意力”。过去几年PRPull Request的规模越来越大依赖越来越多CI 检查也越来越复杂。但代码审查这件事本质上仍然依赖一个资深工程师打开 Diff 页面逐行看代码。问题是一个资深工程师每天能投入到 Code Review 的时间是有限的而 PR 里真正需要人类判断的内容往往只占很小一部分。大部分 Review 时间消耗在哪里呢举几个很典型的例子格式不一致、命名风格不统一明显的错误处理缺失比如unwrap()直接用在可能为None的场景常见的安全隐患比如不安全的unsafe块使用文档注释缺失或过时没有遵循项目里既有的模式比如错误类型没有实现std::error::Error简单的逻辑错误比如边界条件判断反了。这些内容不是不重要但它们有一个共同点不需要“资深工程师”也能发现。可现实是它们确实消耗了资深工程师的审查时间。等 Reviewer 把这些问题一个个挑出来、写评论、等作者修改真正需要他投入判断力的架构问题、并发安全问题、API 设计问题反而可能因为精力耗尽而被草草放过。这就是为什么五个 Rust 团队会不约而同地选择“LLM 规则”这条路。他们不是在用 AI 替代人类审查而是把人类从重复劳动里解放出来让注意力重新回到高价值判断上。2. 什么是“LLM 规则”它不是你想的那个东西很多人第一反应是LLM 规则 把 PR 丢给 ChatGPT让它直接给结论。这其实是最容易踩的误区。从 Rust 团队的实际做法来看LLM 规则更像是一种可编程的审查辅助层。它的核心不是“问 AI 怎么看这段代码”而是“给 LLM 定义一套明确、可执行的检查规则让它按规则去扫描代码输出结构化的审查意见”。用一句话概括LLM 规则不是让 AI 代替人思考而是让人把“如何检查代码”写成规则然后让 AI 按规则去执行。这里有一个很关键的区别传统静态分析工具比如clippy依赖确定性规则优点是稳定缺点是只能识别模式不能理解上下文。通用 LLM 审查比如直接把代码贴给 GPT依赖模型的模糊能力优点是理解力强缺点是输出不稳定容易漏检也容易误报。LLM 规则介于两者之间用规则约束 LLM 的检查范围和输出格式用 LLM 理解代码上下文。打个比方clippy像一个拿着检查清单的保安只会按清单打勾通用 LLM 像一个知识渊博但容易跑题的顾问而 LLM 规则像是一个“带了行业规范手册的审计员”——他知道规则也知道怎么理解实际情况但最终报告必须按规范格式输出。从公开资料看这些 Rust 团队的做法通常包含几个要素规则文件用自然语言或结构化格式描述检查项例如“检测所有直接对Result调用unwrap()且函数签名返回Result的场景”。LLM 推理将规则文件和代码片段一起提交给 LLM要求它按规则检查。结构化输出LLM 返回的结果被解析成标准格式比如 JSON包含问题位置、严重级别、建议修改方式。人工确认最终审查意见必须有人类 Reviewer 确认LLM 的输出只是辅助草稿。这个流程的意义在于规则是团队定义的AI 只负责执行。如果 LLM 误报修正的是规则不是让团队去适应 AI 的随机发挥。3. 为什么是 Rust 团队先跑通这条路很多人会好奇为什么是 Rust 团队先大规模讨论和采用这套方案这其实和 Rust 语言本身的特性、社区文化都有关系。3.1 Rust 的编译器已经把一部分“人类审查”自动化了Rust 有一个非常强大的编译器加上cargo fmt、clippy这些工具已经消灭了大量原本需要人工审查的问题。比如所有权、借用检查、生命周期、空指针这些在其他语言里需要 Reviewer 重点关注的领域在 Rust 里大部分是编译错误根本到不了 Code Review 阶段。这意味着什么意味着 Rust 团队的 Code Review 可以更早地把注意力放在“人类才能判断的问题”上。但与此同时Rust 也引入了新的复杂性问题生命周期标注是否合理、unsafe块是否真的安全、抽象层次是否恰当、错误处理是否符合项目惯例这些都是编译器管不了的。换句话说Rust 的 Code Review 比很多语言更“纯粹”也更适合让 LLM 介入。因为 LLM 不需要处理“这段代码会不会空指针”这种低级问题它可以直接处理“这个错误处理模式是否符合项目惯例”这种规则性问题。3.2 Rust 社区对“工具链”的接受度极高Rust 社区可能是所有编程语言社区里最拥抱工具链的。从cargo、clippy、rustfmt到各种 Cargo 插件Rust 开发者习惯“用工具解决问题”。因此把 LLM 规则纳入开发流程对 Rust 团队来说不是一个文化冲击而是工具链的自然延伸。3.3 安全和正确性敏感性Rust 经常被用于系统编程、嵌入式、网络协议、区块链等对安全和正确性要求极高的场景。这类团队的 Code Review 压力更大也更愿意尝试能在“不降低标准”的前提下提高效率的方案。LLM 规则正好符合这个诉求——它不改变审查标准只是把重复性检查自动化。这里有一个值得注意的技术背景Rust 生态里有一个非常流行的工具cargo-deny用于检查依赖许可证和安全漏洞还有cargo-geiger用于检测unsafe代码的使用比例。这些工具证明了 Rust 团队很习惯“把安全审查自动化”。LLM 规则是这条路线的一个延伸只不过检查的对象从依赖变成了代码本身。4. LLM 规则和传统 Code Review 工具的区别要理解 LLM 规则的价值必须把它和现有的工具放在一起对比。很多团队会问我已经用了clippy、cargo fmt、SonarQube为什么还需要 LLM 规则下面这张表可以比较直观地说明问题维度传统静态分析工具通用 LLM 审查LLM 规则辅助审查规则确定性高同一代码永远同一结果低输出不稳定中高规则约束输出格式上下文理解弱只能识别模式强能理解语义较强能够按规则结合上下文误报率中模式匹配容易误报中高容易过度解读中可通过规则调优是否可团队定制有限依赖插件生态弱Prompt 不可控强规则文件由团队维护是否替代人类否只辅助容易造成依赖明确不替代结果需人工确认适合检查的内容格式、模式、已知问题开放性问题团队定义的规则性问题从这个对比可以看到LLM 规则的定位非常清楚它填补的是“传统工具查不了、通用 LLM 不敢信”的中间地带。举个例子一个团队可能有一条内部规则所有公开 API 的文档注释必须包含# Panics部分说明可能的 panic 场景。clippy查不了这个因为它需要理解“这个 API 是否可能在哪些场景 panic”通用 LLM 可以查但结果不稳定LLM 规则可以用一段明确的话定义这条规则然后让 LLM 逐函数检查。5. 在 Rust 项目中落地 LLM 规则的完整流程聊完了理念下面进入实操部分。我们以一个真实的 Rust 项目为例演示如何把 LLM 规则集成到 Code Review 流程中。5.1 明确你要检查什么这是最重要的一步也是最容易被跳过的。很多团队拿到 LLM 就直接说“帮我看看代码有什么问题”结果得到一堆泛泛而谈的建议毫无价值。在 Rust 项目里比较适合用 LLM 规则检查的场景包括错误处理模式是否所有可能失败的函数都返回了Result是否存在应该使用?却手动match的场景unsafe块审查每个unsafe块是否都有注释说明为什么安全是否被限制在最小范围内公开 API 文档所有pub函数是否都有# Panics、# Errors部分生命周期标注是否存在不必要的生命周期参数特性Trait一致性相同概念是否使用了不同的 trait 命名并发模式是否存在不必要的Mutex使用是否应该用Arc的场景漏掉了注意这些规则必须写成能让 LLM 理解的形式。规则不是“检查错误处理”而是类似这样检查每个返回 ResultT, E 的公开函数确认错误类型 E 是否实现了 std::error::Error。 如果没有实现报告为 WARNING 级别问题。5.2 设计规则文件我们可以在项目根目录创建一个llm-review-rules.md文件作为团队的审查规则文档。这样规则本身也可以被 Code Reviewmeta review后续修改也有迹可循。示例内容如下# Code Review LLM 规则 本文件定义 LLM 辅助代码审查时需要执行的规则。 LLM 的输出仅作为 Reviewer 的参考不直接作为合并依据。 ## R1: 错误类型规范 - 所有公开函数返回的 Result 错误类型必须实现 std::error::Error。 - 如果错误类型是自定义 enum必须实现 Display 和 Error。 ## R2: unsafe 块安全性 - 每个 unsafe 块上方必须有一行注释解释为什么这里的 unsafe 操作是安全的。 - unsafe 块内不得包含与该操作无关的代码。 ## R3: 文档完整性 - 所有 pub 函数必须包含文档注释。 - 如果函数可能 panic文档必须包含 # Panics 部分。 - 如果函数返回 Result文档必须包含 # Errors 部分。 ## R4: 生命周期参数 - 如果生命周期参数在函数签名中只出现一次视为多余应改用_。这个文件的价值在于它让 LLM 的检查行为变得可预期、可审计、可改进。如果 LLM 在某个规则上反复误报团队可以直接修改规则描述而不是靠运气调试提示词。5.3 编写一个最小可用脚本为了避免把 LLM 的 API 调用逻辑散落在 CI 配置里更推荐写一个独立的 Python 脚本负责获取 PR 变更的代码文件读取规则文件将规则和代码片段发送给 LLM解析 LLM 的响应输出结构化的审查意见。这里给出一个简化示例重点演示流程生产环境需要根据实际 LLM API 调整。# 文件路径tools/llm_review.py import json import os import subprocess import sys from openai import OpenAI RULES_FILE llm-review-rules.md MODEL os.getenv(LLM_REVIEW_MODEL, gpt-4o-mini) def get_changed_rust_files(): 获取当前分支相对 main 分支变更的 Rust 文件列表 result subprocess.run( [git, diff, --name-only, origin/main...], capture_outputTrue, textTrue, checkTrue, ) files [ line.strip() for line in result.stdout.splitlines() if line.strip().endswith(.rs) ] return files def read_rules(): with open(RULES_FILE, r, encodingutf-8) as f: return f.read() def review_file(client, rules, filepath): with open(filepath, r, encodingutf-8) as f: code f.read() prompt f你是 Rust 代码审查助手。请严格按照以下规则审查代码。 规则 {rules} 需要审查的文件{filepath} 代码 rust {code}请以 JSON 数组格式输出审查结果每个元素包含file: 文件名line: 行号如果可判断rule: 违反的规则编号severity: ERROR 或 WARNINGmessage: 具体问题描述suggestion: 修改建议如果没有任何问题输出空数组 []。 response client.chat.completions.create( modelMODEL, messages[{role: user, content: prompt}], temperature0, ) content response.choices[0].message.content.strip() # 清理可能的 markdown 代码块标记 if content.startswith(): content content.split()[1] if content.startswith(json): content content[4:] return json.loads(content)def main(): api_key os.getenv(LLM_API_KEY) if not api_key: print(错误请设置 LLM_API_KEY 环境变量, filesys.stderr) sys.exit(1)client OpenAI(api_keyapi_key) rules read_rules() files get_changed_rust_files() if not files: print(没有变更的 Rust 文件跳过 LLM 审查。) return all_findings [] for filepath in files: print(f正在审查{filepath}) try: findings review_file(client, rules, filepath) all_findings.extend(findings) except Exception as e: print(f审查 {filepath} 失败{e}, filesys.stderr) print(json.dumps(all_findings, indent2, ensure_asciiFalse))ifname main: main()这段代码的核心逻辑是**先读取团队规则再逐文件调用 LLM最后统一输出结构化结果。** 有几个细节值得解释 - temperature0 是为了尽可能让 LLM 输出稳定减少随机性。 - 要求输出 JSON 数组是为了让结果可以直接被后续流程消费比如自动评论到 PR 上。 - 用 git diff 只获取变更文件而不是全仓库扫描是为了控制成本和保证反馈速度。 - 对 LLM 的异常做了捕获避免单个文件失败导致整个流程崩溃。 ### 5.4 集成到 GitHub Actions 有了脚本之后可以把它接到 CI 流程里。下面是一个 GitHub Actions 配置示例 yaml # 文件路径.github/workflows/llm-review.yml name: LLM Code Review on: pull_request: types: [opened, synchronize] jobs: llm-review: runs-on: ubuntu-latest steps: - name: 检出代码 uses: actions/checkoutv4 with: fetch-depth: 0 - name: 设置 Python uses: actions/setup-pythonv5 with: python-version: 3.11 - name: 安装依赖 run: pip install openai - name: 运行 LLM 审查 env: LLM_API_KEY: ${{ secrets.LLM_API_KEY }} LLM_REVIEW_MODEL: ${{ vars.LLM_REVIEW_MODEL }} run: python tools/llm_review.py注意一个隐藏的坑uses: actions/checkoutv4默认只检出单个提交git diff origin/main...会失败。因此必须设置fetch-depth: 0否则脚本拿不到完整的 Git 历史。5.5 把结果写回 PR 评论脚本输出 JSON 数组后还需要一个步骤把结果发布到 PR 评论。上面actions/github-script做得比较干净- name: 发布审查结果到 PR uses: actions/github-scriptv7 with: script: | const fs require(fs); const findings JSON.parse(fs.readFileSync(llm_findings.json, utf8)); if (findings.length 0) { console.log(LLM 审查未发现问题); return; } let body ## LLM 辅助审查结果\n\n; body 以下结果由 LLM 根据团队规则自动生成仅供 Reviewer 参考不直接作为合并依据。\n\n; for (const f of findings) { const icon f.severity ERROR ? : ; body ${icon} **${f.file}:${f.line || ?}** [${f.rule}] ${f.message}\n; if (f.suggestion) { body 建议${f.suggestion}\n\n; } } github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: body });这里需要把 Python 脚本的输出保存到文件而不是只打印到控制台。可以在main()的最后一行做一个小修改with open(llm_findings.json, w, encodingutf-8) as f: json.dump(all_findings, f, indent2, ensure_asciiFalse)这一步的意义在于LLM 审查只是 Code Review 的第一个 Pass而不是最后一个。把结果写回 PR 后人类 Reviewer 仍然需要逐条确认区分“真问题”和“误报”。6. 运行结果与效果验证脚本运行成功后你会在控制台或 JSON 文件里看到类似下面的输出[ { file: src/storage/engine.rs, line: 42, rule: R1, severity: ERROR, message: 错误类型 StorageError 未实现 std::error::Error, suggestion: 为 StorageError 实现 std::error::Error可使用 thiserror 宏 }, { file: src/network/server.rs, line: 87, rule: R2, severity: WARNING, message: unsafe 块缺少安全说明注释, suggestion: 在 unsafe 块上方补充注释解释为什么该操作是安全的 }, { file: src/api/client.rs, line: 15, rule: R3, severity: WARNING, message: 公开函数 connect 的文档缺少 # Errors 部分, suggestion: 补充 # Errors 部分说明可能返回的错误类型 } ]如何判断这套流程运行成功可以从三个维度来看格式正确LLM 返回了合法的 JSON并且能被后续流程解析。规则响应对明显违反团队规则的新代码LLM 给出了有效提示。比如你故意在一个pub fn上缺失# Errors文档规则 R3 应当能捕获。误报可控对符合规范的代码LLM 没有输出大量无关建议。如果误报太多需要回到规则文件把描述写得更精确。如果运行失败第一步应该检查LLM_API_KEY是否设置正确规则文件是否存在、格式是否正确git diff origin/main...是否能获取到变更文件LLM 返回的内容能否被json.loads解析。如果模型返回了多余的文本需要增强清理逻辑。7. 常见问题与排查思路在实际使用中团队可能会遇到下面这些典型问题。我把它们整理成一张排查表问题现象可能原因排查方式解决方案LLM 返回的内容不是合法 JSON模型输出带有多余文本或 markdown 代码块打印原始响应检查清理逻辑增强清理逻辑或在 prompt 中强调“只输出 JSON”审查结果经常重复同一类误报规则描述太模糊模型理解偏差对比误报案例查看规则文本把规则改得更具体补充正面和反面示例审查时间太长CI 超时变更文件太多或模型选择过重查看 CI 日志统计耗时限制文件数量、使用更快更小的模型、增加并发调用漏报明显问题规则覆盖不全或 LLM 上下文窗口被截断检查是否只审查了 diff 文件完善规则清单对超大文件做分段审查API 调用失败Key 过期、额度不足、网络问题查看错误日志配置重试机制或接入备用模型人类 Reviewer 不信任 LLM 结果LLM 评论与人工判断不一致统计一段时间内的采纳率在评论中标注“由 LLM 生成”并逐步调整规则减少噪音在这里要特别强调LLM 规则的维护成本是真实的不是一次配置就能一劳永逸。规则文件需要随着项目的演化持续调整。新引入的 crate、新的架构模式、新的团队约定都需要映射到规则文件里。这个维护成本本质上是在建设团队自己的“审查知识库”。8. 最佳实践与工程建议8.1 规则先行工具其次这是最重要的一条建议。不要先接 LLM再想规则。先让团队坐下来列出 Code Review 中最常见、最机械、最消耗时间的问题清单然后写成规则文档。规则越具体LLM 的效果越好。一个好的规则应该具备三个特征可判定、可操作、可举例。比如“检查错误处理是否正确”是一个不可判定的规则而“所有公开函数返回的 Result 错误类型必须实现std::error::Error”就是一个可判定的规则因为它有明确的是非标准。8.2 LLM 只做第一遍人类始终有否决权无论 LLM 的输出看起来多专业都要保持一个原则LLM 是提议方人类是决策方。PR 的合入权限永远不能交给 AI。在 CI 配置里LLM 审查结果可以输出为 annotation但不能设置为required check更不能让它直接 approve PR。8.3 控制成本和延迟对大型项目全量扫描成本很高。推荐的做法是只审查git diff中的变更文件按文件大小拆分超过 500 行的文件分段审查选择延迟和成本合适的模型小问题用轻量模型复杂问题用强模型设置并发上限避免触发 API 限流。8.4 把规则文件当作代码来维护llm-review-rules.md和普通代码一样需要版本管理、变更记录和 Review。建议放在仓库根目录任何人修改规则都要触发一次 Code Review。规则变更后可以拿历史 PR 做一次回归测试看看新规则会不会引入大量误报。8.5 建立反馈闭环如果 LLM 的某个检查结果被人工 Reviewer 否决了建议记录下来。一段时间后统计分析哪些规则采纳率高、哪些规则经常误报、是否有重要的规律被遗漏。这些数据反过来驱动规则优化形成一个可持续改进的闭环。8.6 不要忽略隐私和数据安全把代码发送给外部 LLM API 之前需要确认代码是否包含敏感信息。涉及商业机密、安全密钥、未公开协议的项目应该选择私有部署的模型或者在发送前做脱敏处理。这一步在接入初期就要评估不要等技术债积累后再补救。9. Rust 生态里可配套使用的工具LLM 规则并不是孤立存在的它可以和 Rust 生态里现有的工具链组合使用形成一套更完整的检查体系工具解决的问题与 LLM 规则的关系cargo fmt代码格式统一格式化问题交给工具LLM 不需要管clippy常见代码模式和潜在 bugLLM 规则可以检查 clippy 覆盖不到的“团队约定”cargo-deny依赖许可证和安全漏洞依赖问题交给工具LLM 聚焦代码本身cargo-geiger统计unsafe使用情况定位有unsafe的文件后用 LLM 规则检查安全性注释sccache编译缓存加速 CI间接提升 LLM 审查流程的整体效率这个组合思路的核心是确定性工具负责确定性问题LLM 负责需要理解的规则性问题。两者不是竞品而是互补。如果一个规则能被clippy实现就应该去写clippylint而不是用 LLM只有当规则需要理解代码语义和团队上下文时才值得使用 LLM。10. 对 Rust 开发者的现实建议回到开头的问题这套方案适合你的团队吗从 Rust 团队的实践来看适合采用 LLM 规则的是那些已有明确工程规范、Code Review 压力巨大、且团队成员具备工具链改造能力的项目。如果团队还没有基础的行为规范直接引入 LLM 规则只会增加噪音。对个人开发者来说这套思路同样有参考价值你可以为自己的开源项目写一套 LLM 审查规则每次提交 PR 前先跑一遍让 LLM 扮演“第一轮 Reviewer”。这比直接让 AI 从头到尾审查整个项目要可靠得多因为它有明确的目标和边界。对 Rust 社区来说这则消息真正的启示不是“AI 取代了人类审查”而是**“人类对 AI 的使用方式正在变得更成熟”**。我们不再追求让 AI 做所有事而是让 AI 做它擅长的事同时把人类的精力留给真正需要人类判断的领域。如果你打算在团队里尝试建议从一个小范围开始选一个模块定三条规则跑一个月看看采纳率和误报率再决定是否推广。这个循序渐进的过程本身也是对 LLM 规则方案最理性的验证方式。 Rust团队引入LLM规则辅助代码审查：保护人类注意力而非替代
最近 Rust 社区有一则消息值得关注五个知名的 Rust 团队开始引入“LLM 规则”来辅助代码审查但目的并不是让 AI 替代人类 Reviewer而是反过来——保护人类 Code Review 的时间和注意力。这件事很容易被误读成“AI 接管代码审查”但实际上它背后的技术判断要克制得多LLM 只负责处理机械性、重复性的检查人只负责真正需要判断力的部分。这篇文章会从 Code Review 的现状痛点讲起解释这套“LLM 规则”到底在解决什么问题然后落到 Rust 项目里可以怎么落地实践最后给出明确的边界建议。如果你是 Rust 开发者或者正在团队里推动 Code Review 流程改进这篇文章应该能帮你省下不少沟通成本。1. 代码审查的真实困境不是质量问题是注意力问题先说一个可能有点反直觉的判断现代软件开发里代码审查的真正瓶颈不是“代码质量”而是“人类评审者的注意力”。过去几年PRPull Request的规模越来越大依赖越来越多CI 检查也越来越复杂。但代码审查这件事本质上仍然依赖一个资深工程师打开 Diff 页面逐行看代码。问题是一个资深工程师每天能投入到 Code Review 的时间是有限的而 PR 里真正需要人类判断的内容往往只占很小一部分。大部分 Review 时间消耗在哪里呢举几个很典型的例子格式不一致、命名风格不统一明显的错误处理缺失比如unwrap()直接用在可能为None的场景常见的安全隐患比如不安全的unsafe块使用文档注释缺失或过时没有遵循项目里既有的模式比如错误类型没有实现std::error::Error简单的逻辑错误比如边界条件判断反了。这些内容不是不重要但它们有一个共同点不需要“资深工程师”也能发现。可现实是它们确实消耗了资深工程师的审查时间。等 Reviewer 把这些问题一个个挑出来、写评论、等作者修改真正需要他投入判断力的架构问题、并发安全问题、API 设计问题反而可能因为精力耗尽而被草草放过。这就是为什么五个 Rust 团队会不约而同地选择“LLM 规则”这条路。他们不是在用 AI 替代人类审查而是把人类从重复劳动里解放出来让注意力重新回到高价值判断上。2. 什么是“LLM 规则”它不是你想的那个东西很多人第一反应是LLM 规则 把 PR 丢给 ChatGPT让它直接给结论。这其实是最容易踩的误区。从 Rust 团队的实际做法来看LLM 规则更像是一种可编程的审查辅助层。它的核心不是“问 AI 怎么看这段代码”而是“给 LLM 定义一套明确、可执行的检查规则让它按规则去扫描代码输出结构化的审查意见”。用一句话概括LLM 规则不是让 AI 代替人思考而是让人把“如何检查代码”写成规则然后让 AI 按规则去执行。这里有一个很关键的区别传统静态分析工具比如clippy依赖确定性规则优点是稳定缺点是只能识别模式不能理解上下文。通用 LLM 审查比如直接把代码贴给 GPT依赖模型的模糊能力优点是理解力强缺点是输出不稳定容易漏检也容易误报。LLM 规则介于两者之间用规则约束 LLM 的检查范围和输出格式用 LLM 理解代码上下文。打个比方clippy像一个拿着检查清单的保安只会按清单打勾通用 LLM 像一个知识渊博但容易跑题的顾问而 LLM 规则像是一个“带了行业规范手册的审计员”——他知道规则也知道怎么理解实际情况但最终报告必须按规范格式输出。从公开资料看这些 Rust 团队的做法通常包含几个要素规则文件用自然语言或结构化格式描述检查项例如“检测所有直接对Result调用unwrap()且函数签名返回Result的场景”。LLM 推理将规则文件和代码片段一起提交给 LLM要求它按规则检查。结构化输出LLM 返回的结果被解析成标准格式比如 JSON包含问题位置、严重级别、建议修改方式。人工确认最终审查意见必须有人类 Reviewer 确认LLM 的输出只是辅助草稿。这个流程的意义在于规则是团队定义的AI 只负责执行。如果 LLM 误报修正的是规则不是让团队去适应 AI 的随机发挥。3. 为什么是 Rust 团队先跑通这条路很多人会好奇为什么是 Rust 团队先大规模讨论和采用这套方案这其实和 Rust 语言本身的特性、社区文化都有关系。3.1 Rust 的编译器已经把一部分“人类审查”自动化了Rust 有一个非常强大的编译器加上cargo fmt、clippy这些工具已经消灭了大量原本需要人工审查的问题。比如所有权、借用检查、生命周期、空指针这些在其他语言里需要 Reviewer 重点关注的领域在 Rust 里大部分是编译错误根本到不了 Code Review 阶段。这意味着什么意味着 Rust 团队的 Code Review 可以更早地把注意力放在“人类才能判断的问题”上。但与此同时Rust 也引入了新的复杂性问题生命周期标注是否合理、unsafe块是否真的安全、抽象层次是否恰当、错误处理是否符合项目惯例这些都是编译器管不了的。换句话说Rust 的 Code Review 比很多语言更“纯粹”也更适合让 LLM 介入。因为 LLM 不需要处理“这段代码会不会空指针”这种低级问题它可以直接处理“这个错误处理模式是否符合项目惯例”这种规则性问题。3.2 Rust 社区对“工具链”的接受度极高Rust 社区可能是所有编程语言社区里最拥抱工具链的。从cargo、clippy、rustfmt到各种 Cargo 插件Rust 开发者习惯“用工具解决问题”。因此把 LLM 规则纳入开发流程对 Rust 团队来说不是一个文化冲击而是工具链的自然延伸。3.3 安全和正确性敏感性Rust 经常被用于系统编程、嵌入式、网络协议、区块链等对安全和正确性要求极高的场景。这类团队的 Code Review 压力更大也更愿意尝试能在“不降低标准”的前提下提高效率的方案。LLM 规则正好符合这个诉求——它不改变审查标准只是把重复性检查自动化。这里有一个值得注意的技术背景Rust 生态里有一个非常流行的工具cargo-deny用于检查依赖许可证和安全漏洞还有cargo-geiger用于检测unsafe代码的使用比例。这些工具证明了 Rust 团队很习惯“把安全审查自动化”。LLM 规则是这条路线的一个延伸只不过检查的对象从依赖变成了代码本身。4. LLM 规则和传统 Code Review 工具的区别要理解 LLM 规则的价值必须把它和现有的工具放在一起对比。很多团队会问我已经用了clippy、cargo fmt、SonarQube为什么还需要 LLM 规则下面这张表可以比较直观地说明问题维度传统静态分析工具通用 LLM 审查LLM 规则辅助审查规则确定性高同一代码永远同一结果低输出不稳定中高规则约束输出格式上下文理解弱只能识别模式强能理解语义较强能够按规则结合上下文误报率中模式匹配容易误报中高容易过度解读中可通过规则调优是否可团队定制有限依赖插件生态弱Prompt 不可控强规则文件由团队维护是否替代人类否只辅助容易造成依赖明确不替代结果需人工确认适合检查的内容格式、模式、已知问题开放性问题团队定义的规则性问题从这个对比可以看到LLM 规则的定位非常清楚它填补的是“传统工具查不了、通用 LLM 不敢信”的中间地带。举个例子一个团队可能有一条内部规则所有公开 API 的文档注释必须包含# Panics部分说明可能的 panic 场景。clippy查不了这个因为它需要理解“这个 API 是否可能在哪些场景 panic”通用 LLM 可以查但结果不稳定LLM 规则可以用一段明确的话定义这条规则然后让 LLM 逐函数检查。5. 在 Rust 项目中落地 LLM 规则的完整流程聊完了理念下面进入实操部分。我们以一个真实的 Rust 项目为例演示如何把 LLM 规则集成到 Code Review 流程中。5.1 明确你要检查什么这是最重要的一步也是最容易被跳过的。很多团队拿到 LLM 就直接说“帮我看看代码有什么问题”结果得到一堆泛泛而谈的建议毫无价值。在 Rust 项目里比较适合用 LLM 规则检查的场景包括错误处理模式是否所有可能失败的函数都返回了Result是否存在应该使用?却手动match的场景unsafe块审查每个unsafe块是否都有注释说明为什么安全是否被限制在最小范围内公开 API 文档所有pub函数是否都有# Panics、# Errors部分生命周期标注是否存在不必要的生命周期参数特性Trait一致性相同概念是否使用了不同的 trait 命名并发模式是否存在不必要的Mutex使用是否应该用Arc的场景漏掉了注意这些规则必须写成能让 LLM 理解的形式。规则不是“检查错误处理”而是类似这样检查每个返回 ResultT, E 的公开函数确认错误类型 E 是否实现了 std::error::Error。 如果没有实现报告为 WARNING 级别问题。5.2 设计规则文件我们可以在项目根目录创建一个llm-review-rules.md文件作为团队的审查规则文档。这样规则本身也可以被 Code Reviewmeta review后续修改也有迹可循。示例内容如下# Code Review LLM 规则 本文件定义 LLM 辅助代码审查时需要执行的规则。 LLM 的输出仅作为 Reviewer 的参考不直接作为合并依据。 ## R1: 错误类型规范 - 所有公开函数返回的 Result 错误类型必须实现 std::error::Error。 - 如果错误类型是自定义 enum必须实现 Display 和 Error。 ## R2: unsafe 块安全性 - 每个 unsafe 块上方必须有一行注释解释为什么这里的 unsafe 操作是安全的。 - unsafe 块内不得包含与该操作无关的代码。 ## R3: 文档完整性 - 所有 pub 函数必须包含文档注释。 - 如果函数可能 panic文档必须包含 # Panics 部分。 - 如果函数返回 Result文档必须包含 # Errors 部分。 ## R4: 生命周期参数 - 如果生命周期参数在函数签名中只出现一次视为多余应改用_。这个文件的价值在于它让 LLM 的检查行为变得可预期、可审计、可改进。如果 LLM 在某个规则上反复误报团队可以直接修改规则描述而不是靠运气调试提示词。5.3 编写一个最小可用脚本为了避免把 LLM 的 API 调用逻辑散落在 CI 配置里更推荐写一个独立的 Python 脚本负责获取 PR 变更的代码文件读取规则文件将规则和代码片段发送给 LLM解析 LLM 的响应输出结构化的审查意见。这里给出一个简化示例重点演示流程生产环境需要根据实际 LLM API 调整。# 文件路径tools/llm_review.py import json import os import subprocess import sys from openai import OpenAI RULES_FILE llm-review-rules.md MODEL os.getenv(LLM_REVIEW_MODEL, gpt-4o-mini) def get_changed_rust_files(): 获取当前分支相对 main 分支变更的 Rust 文件列表 result subprocess.run( [git, diff, --name-only, origin/main...], capture_outputTrue, textTrue, checkTrue, ) files [ line.strip() for line in result.stdout.splitlines() if line.strip().endswith(.rs) ] return files def read_rules(): with open(RULES_FILE, r, encodingutf-8) as f: return f.read() def review_file(client, rules, filepath): with open(filepath, r, encodingutf-8) as f: code f.read() prompt f你是 Rust 代码审查助手。请严格按照以下规则审查代码。 规则 {rules} 需要审查的文件{filepath} 代码 rust {code}请以 JSON 数组格式输出审查结果每个元素包含file: 文件名line: 行号如果可判断rule: 违反的规则编号severity: ERROR 或 WARNINGmessage: 具体问题描述suggestion: 修改建议如果没有任何问题输出空数组 []。 response client.chat.completions.create( modelMODEL, messages[{role: user, content: prompt}], temperature0, ) content response.choices[0].message.content.strip() # 清理可能的 markdown 代码块标记 if content.startswith(): content content.split()[1] if content.startswith(json): content content[4:] return json.loads(content)def main(): api_key os.getenv(LLM_API_KEY) if not api_key: print(错误请设置 LLM_API_KEY 环境变量, filesys.stderr) sys.exit(1)client OpenAI(api_keyapi_key) rules read_rules() files get_changed_rust_files() if not files: print(没有变更的 Rust 文件跳过 LLM 审查。) return all_findings [] for filepath in files: print(f正在审查{filepath}) try: findings review_file(client, rules, filepath) all_findings.extend(findings) except Exception as e: print(f审查 {filepath} 失败{e}, filesys.stderr) print(json.dumps(all_findings, indent2, ensure_asciiFalse))ifname main: main()这段代码的核心逻辑是**先读取团队规则再逐文件调用 LLM最后统一输出结构化结果。** 有几个细节值得解释 - temperature0 是为了尽可能让 LLM 输出稳定减少随机性。 - 要求输出 JSON 数组是为了让结果可以直接被后续流程消费比如自动评论到 PR 上。 - 用 git diff 只获取变更文件而不是全仓库扫描是为了控制成本和保证反馈速度。 - 对 LLM 的异常做了捕获避免单个文件失败导致整个流程崩溃。 ### 5.4 集成到 GitHub Actions 有了脚本之后可以把它接到 CI 流程里。下面是一个 GitHub Actions 配置示例 yaml # 文件路径.github/workflows/llm-review.yml name: LLM Code Review on: pull_request: types: [opened, synchronize] jobs: llm-review: runs-on: ubuntu-latest steps: - name: 检出代码 uses: actions/checkoutv4 with: fetch-depth: 0 - name: 设置 Python uses: actions/setup-pythonv5 with: python-version: 3.11 - name: 安装依赖 run: pip install openai - name: 运行 LLM 审查 env: LLM_API_KEY: ${{ secrets.LLM_API_KEY }} LLM_REVIEW_MODEL: ${{ vars.LLM_REVIEW_MODEL }} run: python tools/llm_review.py注意一个隐藏的坑uses: actions/checkoutv4默认只检出单个提交git diff origin/main...会失败。因此必须设置fetch-depth: 0否则脚本拿不到完整的 Git 历史。5.5 把结果写回 PR 评论脚本输出 JSON 数组后还需要一个步骤把结果发布到 PR 评论。上面actions/github-script做得比较干净- name: 发布审查结果到 PR uses: actions/github-scriptv7 with: script: | const fs require(fs); const findings JSON.parse(fs.readFileSync(llm_findings.json, utf8)); if (findings.length 0) { console.log(LLM 审查未发现问题); return; } let body ## LLM 辅助审查结果\n\n; body 以下结果由 LLM 根据团队规则自动生成仅供 Reviewer 参考不直接作为合并依据。\n\n; for (const f of findings) { const icon f.severity ERROR ? : ; body ${icon} **${f.file}:${f.line || ?}** [${f.rule}] ${f.message}\n; if (f.suggestion) { body 建议${f.suggestion}\n\n; } } github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: body });这里需要把 Python 脚本的输出保存到文件而不是只打印到控制台。可以在main()的最后一行做一个小修改with open(llm_findings.json, w, encodingutf-8) as f: json.dump(all_findings, f, indent2, ensure_asciiFalse)这一步的意义在于LLM 审查只是 Code Review 的第一个 Pass而不是最后一个。把结果写回 PR 后人类 Reviewer 仍然需要逐条确认区分“真问题”和“误报”。6. 运行结果与效果验证脚本运行成功后你会在控制台或 JSON 文件里看到类似下面的输出[ { file: src/storage/engine.rs, line: 42, rule: R1, severity: ERROR, message: 错误类型 StorageError 未实现 std::error::Error, suggestion: 为 StorageError 实现 std::error::Error可使用 thiserror 宏 }, { file: src/network/server.rs, line: 87, rule: R2, severity: WARNING, message: unsafe 块缺少安全说明注释, suggestion: 在 unsafe 块上方补充注释解释为什么该操作是安全的 }, { file: src/api/client.rs, line: 15, rule: R3, severity: WARNING, message: 公开函数 connect 的文档缺少 # Errors 部分, suggestion: 补充 # Errors 部分说明可能返回的错误类型 } ]如何判断这套流程运行成功可以从三个维度来看格式正确LLM 返回了合法的 JSON并且能被后续流程解析。规则响应对明显违反团队规则的新代码LLM 给出了有效提示。比如你故意在一个pub fn上缺失# Errors文档规则 R3 应当能捕获。误报可控对符合规范的代码LLM 没有输出大量无关建议。如果误报太多需要回到规则文件把描述写得更精确。如果运行失败第一步应该检查LLM_API_KEY是否设置正确规则文件是否存在、格式是否正确git diff origin/main...是否能获取到变更文件LLM 返回的内容能否被json.loads解析。如果模型返回了多余的文本需要增强清理逻辑。7. 常见问题与排查思路在实际使用中团队可能会遇到下面这些典型问题。我把它们整理成一张排查表问题现象可能原因排查方式解决方案LLM 返回的内容不是合法 JSON模型输出带有多余文本或 markdown 代码块打印原始响应检查清理逻辑增强清理逻辑或在 prompt 中强调“只输出 JSON”审查结果经常重复同一类误报规则描述太模糊模型理解偏差对比误报案例查看规则文本把规则改得更具体补充正面和反面示例审查时间太长CI 超时变更文件太多或模型选择过重查看 CI 日志统计耗时限制文件数量、使用更快更小的模型、增加并发调用漏报明显问题规则覆盖不全或 LLM 上下文窗口被截断检查是否只审查了 diff 文件完善规则清单对超大文件做分段审查API 调用失败Key 过期、额度不足、网络问题查看错误日志配置重试机制或接入备用模型人类 Reviewer 不信任 LLM 结果LLM 评论与人工判断不一致统计一段时间内的采纳率在评论中标注“由 LLM 生成”并逐步调整规则减少噪音在这里要特别强调LLM 规则的维护成本是真实的不是一次配置就能一劳永逸。规则文件需要随着项目的演化持续调整。新引入的 crate、新的架构模式、新的团队约定都需要映射到规则文件里。这个维护成本本质上是在建设团队自己的“审查知识库”。8. 最佳实践与工程建议8.1 规则先行工具其次这是最重要的一条建议。不要先接 LLM再想规则。先让团队坐下来列出 Code Review 中最常见、最机械、最消耗时间的问题清单然后写成规则文档。规则越具体LLM 的效果越好。一个好的规则应该具备三个特征可判定、可操作、可举例。比如“检查错误处理是否正确”是一个不可判定的规则而“所有公开函数返回的 Result 错误类型必须实现std::error::Error”就是一个可判定的规则因为它有明确的是非标准。8.2 LLM 只做第一遍人类始终有否决权无论 LLM 的输出看起来多专业都要保持一个原则LLM 是提议方人类是决策方。PR 的合入权限永远不能交给 AI。在 CI 配置里LLM 审查结果可以输出为 annotation但不能设置为required check更不能让它直接 approve PR。8.3 控制成本和延迟对大型项目全量扫描成本很高。推荐的做法是只审查git diff中的变更文件按文件大小拆分超过 500 行的文件分段审查选择延迟和成本合适的模型小问题用轻量模型复杂问题用强模型设置并发上限避免触发 API 限流。8.4 把规则文件当作代码来维护llm-review-rules.md和普通代码一样需要版本管理、变更记录和 Review。建议放在仓库根目录任何人修改规则都要触发一次 Code Review。规则变更后可以拿历史 PR 做一次回归测试看看新规则会不会引入大量误报。8.5 建立反馈闭环如果 LLM 的某个检查结果被人工 Reviewer 否决了建议记录下来。一段时间后统计分析哪些规则采纳率高、哪些规则经常误报、是否有重要的规律被遗漏。这些数据反过来驱动规则优化形成一个可持续改进的闭环。8.6 不要忽略隐私和数据安全把代码发送给外部 LLM API 之前需要确认代码是否包含敏感信息。涉及商业机密、安全密钥、未公开协议的项目应该选择私有部署的模型或者在发送前做脱敏处理。这一步在接入初期就要评估不要等技术债积累后再补救。9. Rust 生态里可配套使用的工具LLM 规则并不是孤立存在的它可以和 Rust 生态里现有的工具链组合使用形成一套更完整的检查体系工具解决的问题与 LLM 规则的关系cargo fmt代码格式统一格式化问题交给工具LLM 不需要管clippy常见代码模式和潜在 bugLLM 规则可以检查 clippy 覆盖不到的“团队约定”cargo-deny依赖许可证和安全漏洞依赖问题交给工具LLM 聚焦代码本身cargo-geiger统计unsafe使用情况定位有unsafe的文件后用 LLM 规则检查安全性注释sccache编译缓存加速 CI间接提升 LLM 审查流程的整体效率这个组合思路的核心是确定性工具负责确定性问题LLM 负责需要理解的规则性问题。两者不是竞品而是互补。如果一个规则能被clippy实现就应该去写clippylint而不是用 LLM只有当规则需要理解代码语义和团队上下文时才值得使用 LLM。10. 对 Rust 开发者的现实建议回到开头的问题这套方案适合你的团队吗从 Rust 团队的实践来看适合采用 LLM 规则的是那些已有明确工程规范、Code Review 压力巨大、且团队成员具备工具链改造能力的项目。如果团队还没有基础的行为规范直接引入 LLM 规则只会增加噪音。对个人开发者来说这套思路同样有参考价值你可以为自己的开源项目写一套 LLM 审查规则每次提交 PR 前先跑一遍让 LLM 扮演“第一轮 Reviewer”。这比直接让 AI 从头到尾审查整个项目要可靠得多因为它有明确的目标和边界。对 Rust 社区来说这则消息真正的启示不是“AI 取代了人类审查”而是**“人类对 AI 的使用方式正在变得更成熟”**。我们不再追求让 AI 做所有事而是让 AI 做它擅长的事同时把人类的精力留给真正需要人类判断的领域。如果你打算在团队里尝试建议从一个小范围开始选一个模块定三条规则跑一个月看看采纳率和误报率再决定是否推广。这个循序渐进的过程本身也是对 LLM 规则方案最理性的验证方式。