从零构建代码审查 CLI：我如何在团队协作中找到第一轮审查的“自动替身“

从零构建代码审查 CLI我如何在团队协作中找到第一轮审查的自动替身前言更现实的问题是效率——一个 PR 动辄几百行纯靠肉眼审完要半小时。不同同事的代码风格差异很大我又不太敢提太多意见。特别是遇到 unsafe 代码、FFI 调用这些我确实不太懂的区域不审显得不负责审了又怕审错。于是我就想能不能用 Rust 写一个 CLI 工具再接入 AI 的能力帮我自动做第一轮代码审查至少先把格式问题、明显的安全风险筛出来让我把精力集中在真正需要人工判断的地方。这篇文章就是我这段时间折腾出来的方案复盘。Week 4 的主题是行业场景与项目复盘而这个项目恰好是从真实痛点出发、在公司场景下落地的实践希望能给同样在协作开发中挣扎的朋友一些启发。一、从真实痛点出发——为什么需要自动代码审查在团队协作中做 Code Review对于新人来说有几个很现实的困境。首先是基础薄弱——有时候看不出代码里的潜在 Bug特别是所有权和生命周期相关的。Rust 的编译器已经很友好了但编译通过不代表代码就是对的。一个通过了编译的 PR可能藏着 unwrap 滥用、死锁风险、或者数据竞争的隐患。其次是效率问题。我一天大概要审 4-5 个 PR每个平均 200-400 行。纯靠肉眼逐行看完再加上理解上下文、查相关代码一个 PR 至少要 20-30 分钟。有些同事代码写得比较紧凑逻辑跳转多读起来更费劲。第三是标准不统一的问题。不同同事的代码风格差异大——有人习惯把所有逻辑写在 main 里有人喜欢拆成很多小函数有人注释详细有人几乎不写注释。作为新人审 PR我不太敢提太多风格层面的意见因为我自己也没有足够的经验来判断哪种方式更好。最后是知识盲区。unsafe 代码块、FFI 调用、复杂的异步逻辑——这些我确实不太懂但不审又显得不负责任。我需要某种第一轮筛选帮我识别明显的风险点这样我在第二轮人工审查时就能更有针对性地深入。CLI 工具在代码审查场景有几个天然优势可以直接嵌到 GitHub Actions 或 GitLab CI 里实现自动化不需要装特定编辑器有终端就能跑可以和 git hook 绑定在提交前自动检查核心检查逻辑可以离线运行不依赖网络。二、核心引擎的设计思路整个工具的核心设计思路是规则引擎 AI 协作。静态规则负责确定性检查——格式问题、命名规范、clippy 警告这些不需要理解代码语义就能判断。AI 审查负责语义层面——潜在的安全问题、逻辑错误、不合理的错误处理方式。规则引擎的设计遵循 Rust 的 trait 模式。每个检查类型实现一个ReviewRuletrait包含规则名称、描述和检查方法。规则执行器RuleEngine管理所有注册的规则并统一调度。这样以后要加新的检查项只需要实现一个新的ReviewRule并注册到引擎里不需要改动核心流程。审查结果统一用ReviewIssue结构体表示包含文件路径、行号、严重程度Error/Warning/Info和问题描述。严重程度的分级很重要——Error 级别的问题必须修改才能合并Warning 级别是建议修改Info 级别只是参考信息。这个分级直接影响了 CI 流程的行为如果有 Error 级别的 IssueCI 会标记为失败如果只有 WarningCI 通过但会在 PR 评论里提示。// 规则引擎的核心接口定义 pub trait ReviewRule { fn name(self) - str; fn description(self) - str; fn check(self, change: FileChange) - VecReviewIssue; } // 审查发现的问题统一结构 pub struct ReviewIssue { pub file: String, // 文件路径 pub line: usize, // 行号 pub severity: Severity, // 严重程度分级 pub message: String, // 问题描述 pub suggestion: OptionString, // 修改建议可选 }Git 变更的解析思路比较直接通过git diff --name-status获取变更文件列表然后逐文件获取详细 diff 内容。--name-status的输出格式很规整每行是变更类型\t文件路径A 表示新增、M 表示修改、D 表示删除。解析这个输出只需要按行分割、按制表符分离字段、匹配变更类型。在解析过程中我踩了一个小坑git diff 的输出可能包含非 UTF-8 字符特别是二进制文件的 diff。解决方案是用String::from_utf8_lossy做安全转换虽然会丢失部分信息但对文本代码文件的 diff 来说基本没有影响。三、AI 审查的集成策略AI 审查是这个工具的核心亮点但也是最容易出问题的环节。我的策略是把代码 diff 喂给 AI让它从四个维度做智能审查——潜在的内存安全问题所有权、生命周期、错误处理是否完善unwrap 滥用、并发安全风险、代码可读性和最佳实践。AI 审查的 prompt 设计是关键。我用了两层 prompt系统 prompt 定义审查角色和审查维度用户 prompt 附带具体的 diff 内容。系统 prompt 中特别强调了请以 Markdown 格式输出审查意见包含文件、行号、严重程度和修改建议这样 AI 的输出可以直接被解析成结构化的 ReviewIssue。temperature 参数设为 0.3这是经过多次测试后的选择。代码审查不是创作任务需要稳定性和确定性低温度能让审查结果更一致。但也不能设到 0因为某些边缘情况需要 AI 做一些推理判断。在实际使用中发现AI 审查的准确率大约在 60-70%。它能准确识别出大部分 unwrap 滥用和简单的所有权问题但对复杂的并发场景和业务逻辑错误的判断不太靠谱。所以 AI 审查的结果全部标记为 Warning 或 Info 级别绝不标记为 Error——最终是否修改由人工决定。另一个实际问题是延迟。每个文件的 AI 审查需要调用一次 API5-10 个文件的 PR 整体审查时间在 30-60 秒。在 CI 场景下这个延迟是可以接受的但如果想和 git hook 绑定做提交前检查就需要限制 AI 审查的文件数量或者改用本地模型。四、CI 集成与实际效果工具的真正价值在于嵌入 CI 流程。我把它集成到了 GitHub Actions 里PR 创建和更新时自动触发。CI 的设计有两个关键点第一AI 审查步骤用continue-on-error: true确保 AI 分析出错不会阻塞整个 CI 流程第二审查结果以 Markdown 格式写入文件然后通过 GitHub API 发表到 PR 评论里。// 终端报告的核心输出逻辑 pub fn print(issues: [ReviewIssue]) { // 按严重程度分组统计 let errors issues.iter() .filter(|i| matches!(i.severity, Severity::Error)).count(); let warnings issues.iter() .filter(|i| matches!(i.severity, Severity::Warning)).count(); println!(统计: 错误 {}, 警告 {}, errors, warnings); for issue in issues { // Error 级别红色高亮Warning 黄色提示 match issue.severity { Severity::Error println!(❌ ERROR | {}:{}, issue.file, issue.line), Severity::Warning println!(⚠️ WARN | {}:{}, issue.file, issue.line), Severity::Info println!(ℹ️ INFO | {}:{}, issue.file, issue.line), } } }在公司内部试用了一个月后效果比预想的要好。静态规则部分格式检查 clippy 警告的准确率接近 100%这本身就帮我省了大量时间——以前我审 PR 里有大约 30% 的时间花在指出格式和命名问题上现在这些全部由工具自动完成了。AI 审查部分虽然在准确率上只有 60-70%但它的价值不在准确判断而在提供方向。比如 AI 指出某个函数可能存在 unwrap 滥用即使它判断错了具体位置至少让我有意识地去仔细检查那个区域的错误处理方式。这比毫无方向地逐行审读效率高很多。五、总结作为一个 Rust 初学者这次从零构建代码审查 CLI 的经历让我收获很大。首先Rust 的工具生态确实很成熟。clap 做 CLI 参数解析、reqwest 做 HTTP 请求、serde 做 JSON 序列化——这些库的 API 设计和文档质量都远超我之前用过的 Python 和 Node.js 生态中的同类库。对于一个还在学习阶段的新人来说能用这么高质量的工具来做项目本身就是一种加速学习的方式。其次AI 传统规则的组合是正确的方向。静态规则负责确定性检查格式、命名、clippy 警告AI 负责语义理解安全问题、逻辑错误。两者互补而不是互相替代。把 AI 审查结果限制在 Warning 级别、最终决策留给人工这个设计让工具既有用又不越权。第三CLI 是 Rust 的舒适区。编译完就是独立二进制文件分发部署都没有额外依赖。在 CI 场景下这个优势尤为明显——不需要安装 Python 环境、不需要 npm install一条cargo install就搞定了。最后CI/CD 集成是工具真正发挥价值的前提。如果只是本地手动跑一下大多数人会懒得用。只有嵌入到 CI 流程里让审查变成自动化环节才能真正改变团队的工作方式。当然这个工具还有很多不足AI 审查的 prompt 可以更精细错误定位的行号有时不太准对大型 PR 的响应速度也有待优化。但作为一个从零开始折腾出来的项目至少让我少加了好几个班。保持学习保持输出。虽然现在还是个菜鸡但我相信只要坚持总能写出越来越好的代码。