这次要聊的不是一个新的 WebUI也不是某个生成模型而是一个更偏工程实践的事件五个 Rust 团队在公开的技术讨论中开始采用 LLM rules 来辅助代码审查。这件事最值得关注的点不在于“用 AI 看代码”这个动作本身而在于它的设计目标——保护 human code review而不是替代人类审查者。简单说LLM 先跑一遍“草稿审查”把能自动发现的风格问题、典型错误、潜在风险点列出来真正负责设计判断和最终拍板的仍然是团队里的工程师。如果你维护过一个 Rust 项目或者参与过开源社区的 PR 审查应该能理解这种需求的来源。Rust 的审查门槛天然比很多语言高所有权和借用、生命周期标注、unsafe 代码块、Send/Sync 约束、错误处理路径、宏展开后的行为这些都需要 reviewer 花相当多精力去判断。PR 一多人的注意力就会被大量低价值检查吞掉。LLM rules 的思路就是把这类“重复劳动”交给模型先做一轮让人类把精力留给真正需要经验的设计决策。这篇文章会按一套完整的落地路径来拆解先说清楚这次事件表明了什么、LLM rules 和传统静态检查工具的区别再讲环境准备、CI 接入方式、规则文件怎么设计、效果怎么验证最后给出接口调用、批量任务、资源占用和常见问题排查。适合 Rust 项目维护者、代码审查负责人、DevOps 工程化玩家以及正在思考怎么把大模型嵌进研发流程的技术团队阅读。1. 核心能力速览能力项说明项目性质工程实践方法论LLM 辅助代码审查关键词Rust、LLM、Code Review、CI/CD、AI 代码审查核心目标让人类 review 聚焦设计级判断减少低价值检查典型执行方式PR 触发 CI - 提取 diff - 构造审查规则 - 调用 LLM - 输出结构化建议 - 人类终审是否替代人类否所有建议都需人工确认LLM 不进入 merge gate运行平台本地命令行 / GitHub Actions / 自建 CILLM 服务云端 API 或本地模型均可按隐私要求选择批量能力可批量处理多个 PR、commit 或 review 请求接口能力依赖所选 LLM 服务通常可走 OpenAI 兼容接口或本地推理服务Rust 审查重点unsafe、所有权/借用、错误处理、并发、性能、依赖安全适合读者Rust 项目维护者、DevOps 工程师、大模型应用开发者这次“五个 Rust 团队采用 LLM rules”的消息更像是一个信号代码审查正在从纯人工走向“LLM 草稿 人工终审”的混合模式。团队名单本身不是重点重点在于这套流程可以被任何 Rust 项目复制。2. 为什么是“保护”而不是“替代”很多团队听到“用 LLM 做 code review”第一反应是担心AI 会不会抢走审查者的工作会不会在 CI 里自动合入不靠谱的代码这次事件给出的答案恰恰相反——LLM rules 的定位是保护人类 review而不是替代。保护体现在三个层面。第一保护审查者的时间。一个中型 Rust 仓库的 PR 可能包含几百行 diff里面有相当一部分是低风险修改格式不一致、冗余 clone、遗漏的 unwrap、不够严谨的错误处理。让 LLM 先扫一遍人类直接看模型筛选出的高风险项节省的不仅是打开 PR 的次数更是连续专注力。第二保护审查者的判断力。当一个人连续审查多个 PR 后很容易对“常见小问题”脱敏进而漏掉真正的设计缺陷。LLM 在第一轮给出结构化清单能让人类在进入 PR 时就有全局优先级。第三保护审查流程的严肃性。LLM 输出的每一条建议都只是评论不阻断合入、不自动打标签最终批准权保留在人工审查者手里。这样既享受了自动化带来的效率又没有把质量闸门交给一个不可解释的模型。所以如果你准备在项目里引入这套机制第一原则就是LLM 永远只做“建议者”不做“决策者”。任何建议被采纳都要经过人类 review 确认。这个边界越清晰团队对这套工具的信任度越高。3. 与 Clippy、rustfmt、cargo audit 的定位差异Rust 生态本来就有非常成熟的静态检查工具Clippy 能抓大量代码异味rustfmt 统一风格cargo audit 扫描依赖漏洞。那么 LLM rules 是不是重复造轮子答案是部分重叠但定位完全不同。维度Clippy / rustfmtLLM Rules能力范围确定性、规则化的静态分析开放式语义理解可解释上下文解释能力固定错误信息生成自然语言建议和修改思路上下文范围通常局限于单函数或单文件可结合整个 diff、PR 描述、相关文件误报率较低中高需要人工过滤执行速度毫秒级秒级到分钟级受模型和网络影响运行成本几乎为零有 API 费用或本地显存成本定位硬性规则门禁软性建议、探索性审查、辅助信息补充从工程角度更合理的组合是Clippy、rustfmt、cargo audit 继续充当硬性门禁跑不过就直接阻止合入LLM rules 做“第二层建议者”专门处理那些静态工具够不着的问题比如跨文件的设计一致性、PR 描述与实际代码的匹配度、错误处理路径是否完整、并发设计是否存在潜在竞态。这两层不是竞争关系而是互补关系。在 Rust 项目里LLM 真正有价值的地方是它能像一个人一样去读 diff 和上下文然后用自然语言解释“为什么这里可能有问题”。这种能力的成本是误报和幻觉所以下一节会重点讨论边界。4. 适用场景与使用边界先看适合什么。如果你的 Rust 项目同时满足下面几个条件这套方案就值得优先试PR 数量多、团队人手相对少、Rust 新手比例高、代码变更频繁、已有的静态检查已经跑通但 review 质量仍然不稳定。在这些场景里LLM 草稿审查能显著降低 review 负担也能给新人提供“为什么这么改不对”的额外讲解。再看不适合什么。第一高安全等级或强监管场景下不能把 LLM 输出作为唯一依据尤其在涉及密钥、用户隐私、支付逻辑的代码上人类必须逐行确认。第二如果团队没有预期的“人工 review”环节只是想用 LLM 自动合入那风险极大因为模型仍然会产生幻觉无法为后果负责。第三私有代码或未公开的商业代码如果直接发给第三方 API会带来代码泄露风险。这种情况需要优先考虑本地模型或者在发送前做严格的脱敏处理。这里还要强调一个合规边界代码是一种高价值知识产权审查过程中模型会拿到完整的 diff甚至包括未发布的 feature 逻辑。接入前必须确认企业是否允许代码流出内网如果允许需要选择有数据隔离承诺的服务商如果不允许就走本地部署路径。敏感仓库里出现密钥、Token 的场景也要专门识别。把这些边界提前写清楚比事后补救省钱得多。5. 环境准备与前置条件在动手搭 LLM code review 流程之前先把基础环境准备好。这里分三部分Rust 开发环境、LLM 服务、CI 执行环境。第一Rust 环境。常规做法是用 rustup 安装工具链然后通过 IDE 插件和 Cargo 来管理依赖。国内开发者如果直接拉取 crates.io 依赖经常超时可以配置镜像加速。这里给一套通用的设置方式实际地址请以当前可用源为准# 设置 Rustup 镜像 export RUSTUP_DIST_SERVERhttps://rsproxy.cn export RUSTUP_UPDATE_ROOThttps://rsproxy.cn/rustup # 设置 Cargo 镜像 mkdir -p ~/.cargo cat ~/.cargo/config.toml EOF [source.crates-io] replace-with rsproxy-sparse [source.rsproxy-sparse] registry sparsehttps://rsproxy.cn/index/ EOFWindows 用户还有一个常见选择如果不想使用 MSVC 工具链可以安装 GNU 工具链避免本机缺少 Visual Studio Build Tools 的问题。这种方式适合纯 Rust 项目但如果要链接 C 库建议还是按官方推荐装 MSVC。第二LLM 服务。有两种路线云端 API 和本地模型。云端 API 部署最简单只需准备 API Key但要把代码隐私风险考虑清楚本地模型可以用 Ollama 这类推理服务跑在带独立显卡的机器上隐私性更好但需要额外考虑显存和 CPU 内存。具体选择取决于仓库敏感程度和机器配置没有统一答案。第三CI 执行环境。GitHub 项目可以直接用 GitHub Actions自建 Git 服务可以对接自己的 Runner。关键要点是Runner 必须能访问 LLM 服务工作流里要有权限发布 PR 评论同时密钥要存放在 CI 平台的安全变量中而不是直接写进仓库。显存方面本地模型的需求波动很大。以常见 7B 级别模型为例用 FP16 精度推理通常需要 14GB 以上显存用 4bit 量化可以压到 8GB 以下但效果会打折。更稳妥的做法是先看模型的官方文档再根据本机实际跑一轮不要轻信别人给出的单一数字。6. 落地架构把 LLM 插进 code review 流水线整体流程可以这样设计开发提交 PR - CI 工作流触发 - 检出代码获取当前 PR 的 diff - 读取仓库内的 review_rules.yaml - 把 diff、规则、PR 描述拼成 prompt - 调用 LLM 服务要求输出结构化 JSON - 解析 JSON逐条发布 PR review 评论 - 人类 reviewer 查看建议做出最终判断这个流程的关键点有两个一是把 LLM 调用放在 CI 里而不是让开发者手动跑二是输出必须是结构化格式方便后续解析和展示。下面给一套 GitHub Actions 的 workflow 模板实际使用时需要按项目替换路径和脚本名。name: llm-code-review on: pull_request: types: [opened, synchronize] jobs: llm-review: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv4 with: fetch-depth: 0 - name: Setup Python uses: actions/setup-pythonv5 with: python-version: 3.11 - name: Run LLM review env: LLM_API_KEY: ${{ secrets.LLM_API_KEY }} GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} PR_NUMBER: ${{ github.event.pull_request.number }} run: | python scripts/llm_review.py \ --repo $GITHUB_REPOSITORY \ --pr $PR_NUMBER \ --rules config/review_rules.yaml这里scripts/llm_review.py是核心脚本需要自己实现拉取 diff、构造 prompt、调用模型、解析结果、通过 GitHub API 发布评论。后续章节会给出这个脚本内部的关键逻辑示例。注意secrets.LLM_API_KEY要提前在仓库的 Settings - Secrets and variables 里配置好不要写进代码。7. 设计一套 LLM review 规则核心LLM rules 的本质是“把审查经验固化成规则”而不是把整个 PR 直接丢给模型自由发挥。一个好的规则文件应该包含规则 ID、规则名称、适用场景、严重级别、提示词模板、是否阻塞合入。这里用 YAML 写一份 Rust 项目的示例规则文件项目可以根据自身经验继续扩展rules: - id: unsafe_detection name: Unsafe 代码块审查 severity: high description: 检查 unsafe 块是否有充分的安全注释和边界说明 prompt: | 请审查以下 Rust diff 中的 unsafe 代码块。 对每个 unsafe 块检查 1. 是否有清晰的 SAFETY 注释 2. 是否违反了 Rust 的内存安全约束 3. 是否存在可能导致未定义行为的操作 输出 JSON 数组每项包含 file、line、suggestion、confidence。 - id: error_handling name: 错误处理路径 severity: medium description: 检查 unwrap、expect、panic 的滥用 prompt: | 请审查以下 Rust diff 中的错误处理。 标记所有 unwrap、expect、panic 调用判断 1. 调用点是否已经保证不会失败 2. 失败时是否应该返回 Result 而不是 panic 3. 错误信息是否包含足够上下文 - id: concurrency_safety name: 并发与 Send/Sync severity: high description: 检查锁、Arc、线程间共享状态的使用 prompt: | 请审查以下 Rust diff 中的并发相关代码。 关注锁的持有时间、死锁风险、Send/Sync 约束是否满足、 共享状态的竞争条件。输出 JSON 数组按风险从高到低排序。规则文件设计得越细LLM 的输出质量越稳定。建议每个规则都配一个专门的 prompt 片段并在 prompt 里明确“输出 JSON 数组”这样后续解析脚本可以少写很多容错代码。规则文件本身要放进 Git 版本管理每次调整规则都相当于一次团队审查标准的迭代。Prompt 模板的基本结构可以这样理解设定角色你是资深 Rust reviewer- 给出任务上下文这是 PR diff- 给出规则要求只检查 unsafe 和错误处理- 规定输出格式JSON 数组- 提供示例可选。把规则 prompt 和 diff 拼接后发送给模型比单次大 prompt 的效果更稳定因为模型不需要同时处理“全部规则”和“全部代码”而是按规则分别聚焦。8. 功能测试与效果验证部署完成后先不要直接上线评估所有 PR先拿一段真实历史 diff 做功能测试。下面准备一个典型的 Rust 代码片段里面包含 unwrap 滥用、错误处理不完整等问题可以用来验证 LLM 是否能识别use std::sync::{Arc, Mutex}; struct Counter { count: u32, } impl Counter { fn increment(mut self) { self.count 1; } } fn main() { let counter Arc::new(Mutex::new(Counter { count: 0 })); let mut handles vec![]; for _ in 0..10 { let counter Arc::clone(counter); handles.push(std::thread::spawn(move || { let mut c counter.lock().unwrap(); c.increment(); })); } for handle in handles { handle.join().unwrap(); } println!(count: {}, counter.lock().unwrap().count); }这段代码在功能上能跑通但有很多值得审查的点Mutex::lock()的unwrap()在锁被 poison 时会 panic.join().unwrap()在线程 panic 时会传播 panic锁在increment期间持有虽然这里临界区很短但如果在真实系统里锁的粒度需要讨论。一个合格的 LLM review 输出至少应该覆盖这些点而不是只给出“代码看起来没问题”的结论。验证时可以围绕四组指标召回率代码里真实存在的问题LLM 找出多少。比如上面的 unwrap 风险、poison 风险。误报率LLM 认为有问题但实际无问题的建议数量。可执行性建议是否具体到文件、行号、修改思路而不是空泛的“建议优化代码质量”。格式稳定性输出 JSON 是否可解析字段是否完整。建议先选 10 个历史 PR 做回放测试把当时的 diff 喂给模型生成建议然后和当初人工 review 的评论做对比。这一步能直观看出 LLM 的补充价值在哪里、漏掉什么、误报多少。上线后也不要直接全量跑可以先在非关键仓库或只读评论模式下跑一周让团队成员观察建议质量再决定是否调整规则或扩大范围。9. 接口 API 与批量任务设计LLM review 的落地离不开接口调用。这里给两套通用示例云端 OpenAI 兼容接口和本地 Ollama 接口。项目实际使用的模型和 endpoint 可能不同但调用思路一致构造请求、传入 prompt、解析返回。OpenAI 兼容接口的 Python 调用示例import os import json import requests API_KEY os.environ[LLM_API_KEY] URL https://api.openai.com/v1/chat/completions MODEL gpt-4o-mini def call_llm(system_prompt: str, user_prompt: str) - str: resp requests.post( URL, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json, }, json{ model: MODEL, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperature: 0.2, }, timeout120, ) resp.raise_for_status() return resp.json()[choices][0][message][content]本地 Ollama 接口的调用示例import requests import json OLLAMA_URL http://localhost:11434/api/chat MODEL qwen2.5-coder:7b def call_ollama(system_prompt: str, user_prompt: str) - str: resp requests.post( OLLAMA_URL, json{ model: MODEL, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], stream: False, }, timeout300, ) resp.raise_for_status() return resp.json()[message][content]批量任务设计上不建议把所有 PR 直接并发打到模型。更稳妥的做法是维护一个队列按顺序处理控制并发数并加入失败重试机制。例如先拉取最近未审查的 PR 列表逐个调用脚本生成建议再批量发布评论。如果某个 PR 处理失败写入日志并重试最多两次最终失败就跳过不让 LLM 问题阻塞 CI。批量处理的成本也需要关注。云端 API 按 token 计费diff 越大、规则越多单次成本越高。一个实用的控制策略是只发送新增行和修改行不发送删除行规则 prompt 摘要化不要每次都把完整规则文档塞进去优先选择便宜的小模型做初筛命中高风险再让大模型深入分析。10. 资源占用与性能观察资源占用要分两条路线看。云端 API 路线不需要关心显存重点观察响应延迟和 token 成本本地模型路线则需要关注显存、CPU 内存和推理速度。本地模型跑 LLM 时影响显存的主要因素有三个模型参数量、量化精度、上下文长度。同样的模型FP32 比 FP16 更耗显存FP16 比 BF16 通常会多占一点显存4bit 量化则能把显存需求压到最低但会带来一定的效果损失。这些都是常见的工程权衡选择时以官方文档和本机实测为准。在普通消费级显卡上一个 7B 模型用 4bit 量化通常可以运行但推理速度会比云端 API 慢不少同时还会占用大量内存。如果机器只有 8GB 显存跑 7B 模型会比较吃力把模型降到 1.5B 到 3B 级别会更稳妥。实际占用必须以本机跑起来的真实数据为准不要相信任何人拍脑袋的“大概够用”。性能观察指标建议关注四个一次 PR 审查的端到端时长、单次请求延时、平均 token 消耗、评论生成的成功率。第一次部署时先拿一个 200 行以内的小 PR 跑通再逐步放大 diff 规模。如果发现上下文超长就要做 diff 截断或分段审查。一个项目如果每天有几十个 PR先估算出单次成本和平均延时再决定用哪个模型、要不要缓存历史审查结果。11. 常见问题与排查方法问题现象可能原因排查方式解决方案LLM 输出 JSON 解析失败模型返回了多余文字或非标准 JSON打印原始返回内容检查 prompt 输出格式约束在 prompt 中强调只输出 JSON并做二次清洗PR 评论没有发布GitHub Token 权限不足检查 workflow 日志和 Token 的 pull_requests 权限提高 Token 权限或改用 GitHub AppAPI 请求超时diff 太大或模型响应慢查看请求耗时日志截断 diff、减少规则数量、调大超时时间本地模型显存不足模型精度或参数量超出显卡容量用 nvidia-smi 查看显存占用换更小模型或降低精度和上下文长度CI 流程因 LLM 失败而卡住没有加失败兜底逻辑检查脚本是否抛出异常增加重试和跳过逻辑LLM 失败不阻塞 CI规则 prompt 被忽略prompt 描述不够具体复盘模型输出是否偏离规则修改规则文案增加输出示例API Key 泄露风险密钥写入了仓库或日志检查代码历史和日志文件改用 CI 密钥变量立即吊销泄露的 Key这里面最容易被忽略的是“LLM 失败不阻塞 CI”这一条。一旦接入 CI模型服务可能因为限流、网络波动、本地显存爆满而失败如果脚本直接抛异常导致 CI 变红整个团队会很快开始讨厌这个工具。正确做法是脚本捕获所有异常LLM 审查失败就输出 warning并且不影响 PR 合入流程只打一个“当前轮次未生成建议”的标记。12. 最佳实践与使用建议落地这套方案时有几点工程建议可以直接用。第一第一次运行先开“只读模式”。脚本只发布评论不产生任何门禁效果持续一周观察建议质量。团队成员把 LLM 评论当成一个“新来的初级 reviewer”有借鉴价值就采纳不靠谱就忽略让数据说话。第二规则文件要放在版本库里并且像代码一样做 review。每一条规则都对应团队的审查经验应该由资深工程师确认后才合入。新增规则时最好带上一两个真实历史 PR 的案例说明“这个规则能发现什么问题”。第三对大仓库做路径过滤。有些模块是核心逻辑需要完整上下文审查有些只是文档、配置、测试数据可以降低审查级别甚至跳过。这样能省下大量 token 成本。第四敏感内容识别必须前置。在构造 prompt 之前用正则或关键字扫描 diff 中的 API Key、Token、内网地址、员工个人信息等敏感字段命中就跳过该文件或者做脱敏处理后再发给模型。这个检查不能放在 LLM 之后。第五建立人工复查闭环。定期抽查 LLM 的建议按“采用率”和“误报率”做统计。如果某类规则长期零采纳就应该删除或重写。流程做得越久规则库会越贴合项目实际情况。第六涉及第三方代码、版权受保护的代码、以及包含个人信息的代码接入前必须确认授权和使用边界。代码审查工具会复制完整的代码片段到模型上下文如果这部分内容没有授权本身就存在合规风险。涉及人脸、声音、隐私数据等场景时同样要更谨慎地限制数据流向。13. 事件背后的启示与下一步这次五个 Rust 团队采用 LLM rules最值得注意的不是模型能力而是工程边界的设计LLM 被定位成“保护人类 code review”的工具而不是替代者。这种“人机流程分离”的思路比单纯追求更准的模型更值得复制。一个团队只要把规则文件写好、CI 流程跑通、人工终审环节保住就已经从“用 AI 的围观者”变成了“让 AI 进入流程的实践者”。如果要在自己的项目里试点建议从一个小仓库的 PR 流开始选一个非核心、PR 量适中的 Rust 模块先关掉 Clippy 已经能覆盖的规则只让 LLM 专注 unsafe、错误处理和并发设计这三类高价值检查。跑两周后对比历史 review 数据看 LLM 是否真的让人类的审查时间变得更集中。最容易踩的坑是“为了用 AI 而自动合入”——一旦把决策权交给模型LLM 的幻觉成本就完全转嫁到了项目质量上。保持 LLM 建议、人类决定这个边界这套流程才能长期运转。后续可以继续扩展的方向不少把审查规则沉淀成团队知识库让新成员通过规则文件理解项目的代码风格和风险点把 LLM 建议与 Clippy 输出做交叉验证进一步降低误报把批量审查能力接入内部研发平台让每个 MR 自动获得一次“草稿审查”而不是只有人看到后才开始检查。这些都是在一个可运行流程之上自然生长出来的能力前提是先把“保护人类 code review”这条主线守住。