开源 AI 代码审查工具 lazycoder 发布

lazycoder 是一款基于大模型的自动化代码审查工具，通过 17 条固定规则对代码改动逐块评估，并给出可追溯到具体文件与行号的评审结论。该项目已在 Hacker News 上发布，强调「确定性核心 + 模型在末端」的架构设计，以隔离 LLM 调用失败的影响。

工具定位与运行流程

lazycoder 把代码审查拆成三个阶段：解析 diff、对每个代码块按规则评估、汇总结论。系统对每一处变更都强制执行 R1–R17 全部规则，任何规则未给出明确通过 / 失败记录前，工具拒绝输出 APPROVE 结论。

工具支持两种运行模式：

• Fake client（默认，CI 环境）：离线确定性运行，由 pytest 覆盖解析、聚合与判定策略；
• Real client（按需启用）：调用 Anthropic API，由大模型完成规则评估。

退出码映射评审结论——0 表示 APPROVE，1 表示 REQUEST_CHANGES，2 表示 BLOCK，可直接接入 CI 流水线作为合并门禁，--json 参数输出完整报告。

设计原则：确定性核心，模型在末端

项目最核心的设计决策是把所有可纯逻辑实现的环节（diff 解析、规则聚合、判定策略）写成确定性代码，把非确定性的 LLM 调用放在流水线最末端。这样一旦审查出错，问题可定位到提示词或模型本身——而不会是已经通过测试的「水管」部分。

域模型采用严格的 pydantic 校验：

• 已通过的规则不能附带问题；
• 失败规则必须附带具体问题；
• 每条问题必须引用规则 ID 与精确的 file:line；
• 评审结论是基于问题列表计算的派生字段，不可手工赋值。

这种设计使「虚假的评审报告」在结构上无法构造。在系统边界，工具会对 LLM 输出做规范化（如「HIGH」转为「low」），但保持核心域严格不变。

17 条规则覆盖范围

R1–R17 规则覆盖以下维度：

• 代码层面：数据结构（R1）、控制流（R2）、输入输出（R3）、失败模式（R4）、副作用（R5）、依赖（R6）；
• 安全：校验、密钥、注入（R7）；
• 简洁性：最简形式（R8）；
• 系统层面：状态（R9）、同步 vs 异步（R10）、单体 vs 服务（R11）、不变量（R12）；
• 其余至 R17 涵盖可维护性、测试与兼容性。

配置驱动的策略管理

项目行为通过 config/ 目录下若干 JSON 文件声明式定义，包括：

• harness.json：项目上下文与技术栈；
• guardrails.json：智能体行为边界与注入防御；
• review_rules.json：R1–R17 评审规则；
• production_readiness.json：发布门禁；
• evals.json：已知有缺陷 / 无缺陷的测试用例；
• observability.json：追加式决策日志与脱敏策略。

每个文件独立可审、可对比、可替换，策略变更不需改动核心代码。

人机协作边界

项目文档明确表示 lazycoder 不替代人类评审者——后果性决策仍由人确认。它的价值在于把人容易遗漏的部分自动化：记住全部 17 条规则、在大量文件中保持一致、证明检查真的执行过。截至发布时，E3 评估的首次真实 API 调用已通过，模型识别出 SQL 注入并触发 R7，最终聚合得出 BLOCK 结论。