背景

在 AI 越来越发达的今天，我们传统业务开发不得不面临的一个问题是：面对越来越膨胀的 AI 写的代码，我们该如何 Review？

不同的业务场景 AI 能够介入的效果不同。有些业务 AI 能够轻松介入，比如智慧客服、智能 OA 等等。但在 C 端支付结算领域，从来没有说过有"智能支付"、“智能交易”、“智能结算”。

AI 是不可控的。它有时会写出完全正确、优雅的代码，有时也会编造不存在的 API、生成有资金风险的逻辑，甚至自信地告诉你一段危险的变更"没有问题"。

因此我们做了 AI 代码评审。 不是让 AI 直接写代码上线，而是在代码上线前，让 AI 做第一道防线——做好事前评审，防范因对业务的不理解和 AI 写的代码没有被充分理解而产生的风险。

这件事是从 2025 年中开始做的。那个时候 Skill 还没有那么火，我只是进行了初步尝试，利用大模型的基础能力加上我写的 Prompt，配合一些工具对项目代码进行拉取、Diff 等，做 AI 代码评审。我甚至为了这盘醋包了一个饺子，搭建了一个完整 Agent 平台，只为了让代码评审能够更好地工作。

这篇文章就来讲讲这个 Skill 的完整架构和设计思路。

核心思路：为什么选清结算垂直领域？

做一个通用的代码评审工具不难，但要做得好，必须垂直。理由有三：

  1. 通用评审太浅 — 通用模型只能检查代码风格、空指针、SQL 注入这些通用问题，但支付结算领域的核心风险它看不到：资金方向错了怎么办？分布式锁没加上怎么办？日切回滚没覆盖怎么办？

  2. AI 代码膨胀后的现实问题 — 在清结算这样资金密集的领域，AI 写的代码越来越多，但 Review 的人往往对 AI 生成的代码心存顾虑，不知道它"写的对不对"。

  3. 单点突破可行 — 与其做一个大而全的评审工具，不如聚焦一个具体的垂直领域，把领域知识沉淀到规则引擎中，把评审做深做透。

架构全景

这个 Skill 的核心是一个 9 步执行流水线，从初始化到最终通知，每一步都有明确的产物和质量门禁。

保存后继续：执行流概览

Step 1: Init       → 初始化仓库、配置
Step 2: Explore    → 探索仓库结构与分支
Step 3: Log        → 获取提交历史
Step 4: Diff       → 获取代码变更
Step 5: Review     → LLM 初步评审
Step 6: Trace      → 深度溯源（强制！）
Step 7: Report     → 生成最终报告
Step 8: Fix Plan   → 生成修复方案
Step 9: Notify     → 发送通知

全局执行纪律

无论任何单步脚本是否失败，都必须继续执行下一步。每步结束后生成 stepN-status.json（success/degraded/failed）。Step 6 溯源为强制步骤，禁止因为"没有 H 级问题"而跳过。

违反后果：如果跳过 Step 6 溯源，可能导致大量误报被标记为高风险，浪费开发团队排查问题的时间！

评审深度配置

级别 说明 适用场景
fast 仅检查高危模式（SQL 注入、空指针、事务、硬编码密钥） 紧急热修复
standard 检查安全、正确性、性能、可维护性 常规迭代
deep 额外检查架构、并发安全、业务一致性、数据流追踪 核心资金类变更
payment 专项深度检查（分库分表、分布式锁、日切、幂等、脱敏等） 支付结算域变更

六步核心流水线详解

Step 1: Init — 收集配置与初始化

这一步直接使用原生 Git 命令克隆仓库，创建 meta.json：

git clone "https://{username}@{repo_host}/{repo_path}.git" /workspace/settle-center
git fetch origin "{target_branch}"
git checkout "{target_branch}"

异常处理链：git clone 失败 → 检查凭据 → 分支不存在 → 列出可用分支 → 仍失败 → 询问用户是否手动提供 diff。

Step 2: Explore — 探索仓库与分支

解析业务文档（如用户提供附件），提取业务线、模块、功能点、资金方向。获取分支列表展示给用户选择。

必须等待用户回复，禁止自动选择！

Step 3: Log — 探索提交历史

git log "{selected_branch}" --max-count=50 \
  --date=iso --pretty=format:"%H|%an|%ad|%s"

展示提交历史后，等待用户选择 commit 或范围。Commit 数量 > 20 时提示预警。

Step 4: Diff — 获取代码变更

# 单个 commit
git show --no-color "{commit_hash}" > evidence.diff

# 分支间比较
git diff --no-color "{branch1}...{branch2}" > evidence.diff

验证步骤：

  • 检查 diff 是否包含错误 → 报错则停止
  • 检查 diff 是否为空 → 为空则生成空报告
  • 文件数 > 50 → 仅评审前 50 个（按风险权重排序）
  • diff 行数 > 5000 → 截断处理

Step 5: Reviewer — 初步评审

评审检查项分类：

类别 检查项 适用深度
安全 SQL 注入、XSS、权限绕过、敏感信息泄露、硬编码密钥 all
正确性 空指针、事务边界、并发安全、金额精度、时区处理 all
性能 N+1 查询、资源未关闭、循环嵌套 standard+
可维护性 重复代码、过长方法、魔法数字 standard+
架构 循环依赖、分层违规、设计模式滥用 deep+
业务一致性 与需求文档对齐、资金方向正确、状态机合规 deep+
领域专项 分库分表、分布式锁、日切、幂等、脱敏 payment

支付结算域专项检测规则

这是整个 Skill 最有价值的部分——它不仅仅是检查代码规范，而是理解支付结算业务：

  • 分库分表 — 检查分片键是否合理、跨分片事务是否正确处理
  • 分布式锁 — 检查资金操作是否有分布式锁保护，锁的粒度和超时设置是否合理
  • 日切机制 — 检查日切回滚逻辑是否完整，T+1 清算数据是否一致
  • 退款幂等 — 检查退款请求是否有幂等保障，防止重复退款
  • 日志脱敏 — 检查关键字段（身份证、银行卡号）是否正确脱敏
  • 资金流追踪 — 检查资金流向是否正确，借贷方向是否匹配
  • 事务边界 — 检查事务范围是否合理，长事务是否有拆分策略
  • 并发安全 — 检查并发场景下的数据竞争和状态不一致问题

假阳性过滤（三层规则引擎）

这是保证评审质量的关键——没有假阳性过滤的评审工具，开发团队不会用。

  • L1: 语法模式匹配 — 防御性判空、try-with-resources、Optional 包装等
  • L2: 领域模式匹配 — 支付结算域专用（金额比较、分布式锁、幂等注解、日切、脱敏等）
  • L3: 上下文模式匹配 — 基于上下文的降级判断（如基础框架类代码降级检查标准）

Step 6: 风险溯源（强制步骤，不可跳过）

这是整个 Skill 设计中最重要的一步——不溯源的评审只是在重复 LLM 的第一印象。

六个维度的溯源

  1. 上游调用链 — 哪些方法调用了目标方法？调用链路是否存在风险？
  2. 下游调用链 — 目标方法调用了哪些方法？是否引入了不安全的依赖？
  3. 数据流溯源 — 敏感字段和资金字段如何流转？是否存在泄露风险？
  4. 事务链溯源 — 事务边界在哪里？是否存在事务过长或不合理嵌套？
  5. 并发链溯源 — 是否存在并发安全问题？锁机制是否正确？
  6. 配置溯源 — @Value 和 @ConfigurationProperties 的值从哪来？

溯源命令示例

python review.py context-trace \
  --repo-dir "${repo_dir}" --target-class "${TARGET_CLASS}" \
  --target-method "${TARGET_METHOD}" --direction upstream

python review.py dataflow-trace \
  --repo-dir "${repo_dir}" --target-class "${TARGET_CLASS}" \
  --target-fields "sensitiveFields,moneyFields"

风险重新评估

根据溯源结果动态调整等级：

  • 上游已做防护 → 降级
  • 下游有补偿机制 → 保持或降级
  • 完全没有防护 → 保持 H
  • 风险叠加 → 升级为 H
  • 数据已脱敏 → 降级或移除

Step 7-9: 报告、修复与通知

报告结构

最终报告遵循严格的结构，必须包含：

  • 执行摘要 — 评分雷达图、关键风险清单
  • 变更统计 — 表格 + Mermaid 饼图、风险热力图
  • 风险明细清单 — 按 H/M/L/INFO 分组，含证据和溯源结果
  • 修复建议汇总 — 按优先级排序，预估工时
  • 附录 — 假阳性过滤记录、溯源工具调用日志

修复方案类型

类型 适用场景 说明
auto_patch 规范类、简单安全类 自动生成代码补丁
test_template 缺陷类、并发类 生成单元测试模板
checklist 架构类、业务一致性 生成检查清单

质量门禁

只有所有步骤都 success 才能发正式钉钉通知（gate = full_pass）。如果存在降级步骤，通知中必须包含"执行完整性说明"。

钉钉通知集成

python review.py notify \
  --webhook-url "{webhook_url}" \
  --title "代码评审完成" \
  --text "发现了 N 个问题（H:N, M:N, L:N）"

防幻觉机制

LLM 在代码评审场景中特别喜欢"编造"，为此我设计了一套严格的约束：

禁止项 说明
伪造 commit hash 必须使用 Step 3 返回的 hash
凭空编造代码 所有 evidence 必须来自真实 diff
猜测行号 行号必须与 diff 一致
忽略空 diff diff 为空时必须停止
跳过假阳性过滤 必须应用三层规则引擎
自动选择分支 必须等待用户选择
伪造溯源结果 工具失败时必须标注
绕过 notify 禁止用 bash/curl 直接发通知

与 Harness 的关系

这个 Skill 在运行时同样依赖于之前那篇文章中提到的 Harness 架构：

  • 控制平面 — Skill 的执行纪律和约束规则
  • Query Loop — 9 步流水线的迭代执行
  • 权限门 — 每一步的产物校验和质量门禁
  • 上下文治理 — diff 内容的分段处理和预算控制
  • 错误恢复 — 单步失败不阻塞整体流程

这也印证了我在 Harness Engineering 中提到的观点：今天模型之间的差距，远小于系统设计好坏带来的差距。

总结

从 2025 年中开始，我用一年时间做了一个垂直领域的代码评审 Skill。它的核心价值不在于"AI 能不能评审代码"，而在于：

  1. 垂直化 — 只有深入支付结算领域，才能发现真正有意义的代码风险
  2. 流水线化 — 9 步执行流水线保证评审质量和可追溯性
  3. 可溯源 — 每一个 H 级问题都有 6 个维度的溯源证据
  4. 防幻觉 — 严格约束 LLM 的输出，防止编造
  5. 可落地 — 通过钉钉集成和自动修复方案，真正融入开发流程

这个 Skill 最终以这个平台为切入点，我规划了需求分析 → 产品文档 → 代码编写 → 代码评审 → 测试案例生成的完整工作流。目前代码评审模块已经相对成熟，其他模块还在初步阶段。

但正如我做这件事的初衷：在 AI 越来越强的今天，我们要做的不是阻止 AI 写代码，而是确保 AI 写的代码在进生产之前，被充分理解、充分评审。