AI代码审查应作遥测而非临时评论——建立决策台账

问题所在：评论即对话

大多数 AI 评审集成将发现结果以内联评论的形式呈现，这对作者而言体验不错，但对组织几乎毫无价值。作者读到评论、修复问题、对话关闭，而模型的分类、严重程度和准确率也随之消失。你无法衡量评审者是否在改进、某些文件类型是否吸引误报、或者你的团队是否真正根据发现结果采取了行动。对话本质上是昙花一现的，而对于一个你想要信任的系统来说，这恰恰是错误的设计。

立场：评审即遥测

我的立场是，AI 评审应被视为遥测数据，而非第二意见，评审台账是任何 AI 评审流水线的首要交付物。一条台账记录包含文件路径、规则分类、严重程度、模型置信度、人工判定结果，以及补丁的最终命运——这将零散的评论转化为可查询的数据集。一旦数据集存在，你就能回答单个评审无法回答的问题，例如哪些分类浪费了最多人工时间、哪些评审者默默覆盖了模型的判断。评论是界面，台账才是资产。

为什么免费工具改变了局面

工具的经济模型决定了台账是否会被构建，因为按次计价使得每次评审都成为成本中心，而每次跳过评审都是一次小小的"胜利"。MonkeyCode 的免费模型访问和免费服务器选项消除了这种摩擦——你可以将评审工具作为共享服务运行，而无需盯着计量表。信息披露：本文是 MonkeyCode 产品推广的一部分。以下工作流程针对免费服务器选项，同样的模式也适用于任何输出结构化发现结果的评审工具。

付费评审工具会促使你减少评审次数，而这正是对于一个价值随重复次数增长系统而言完全错误的方向。免费评审工具让你可以在每个 Pull Request 上运行门控，让台账无预算压力地积累。这种激励差异才是真正的产品，也是为什么免费访问是工作流程决策而非营销决策。

工作流程：从评论到语料库

目标是构建一条在每个发现结果消失之前将其捕获的流水线，需要四个步骤来完成。

将评审工具作为服务运行。在小型 VM 或 CI 环境中启动服务器一次，将其视为基础设施而非开发工具，因为共享端点为每个 Pull Request 提供相同的评审器和相同的配置。

将 CI 指向服务器。添加一个作业，将 diff 发送到服务器，捕获 JSON 响应，仅在团队已归类为阻塞性的发现结果上让构建失败——这样门控既严格又不会产生噪音。

将每个响应追加到台账。使用下方脚本将服务器响应规范化为每条发现结果一行 JSONL，其中包含作者在评审后填写的人工判定字段。

每月分析台账。运行配套脚本计算每个分类的接受率和误报率，然后根据数据展示的内容调整提示词或规则。

产物：一套两个脚本的评审台账

第一个脚本从标准输入读取评审负载，并将每条发现结果追加到 JSONL 文件。

#!/usr/bin/env python3
"""Append AI review findings to a local JSONL ledger."""
import json
import sys
import uuid
from datetime import datetime, timezone

def append_findings(review_payload: dict, ledger_path: str = "review_ledger.jsonl") -> int:
    count = 0
    with open(ledger_path, "a") as ledger:
        for finding in review_payload.get("findings", []):
            entry = {
                "id": str(uuid.uuid4())[:8],
                "ts": datetime.now(timezone.utc).isoformat(),
                "file": finding.get("file"),
                "category": finding.get("category"),
                "severity": finding.get("severity"),
                "confidence": finding.get("confidence"),
                "human_verdict": None,  # filled in by the author after review
                "patch_merged": None,   # filled in when the pull request closes
            }
            ledger.write(json.dumps(entry) + "\n")
            count += 1
    return count

if __name__ == "__main__":
    payload = json.load(sys.stdin)
    print(f"logged {append_findings(payload)} findings")

第二个脚本读取台账并报告每个分类的人工判定分布，这是判断评审工具是否"狼来了"的最快信号。

#!/usr/bin/env python3
"""Summarize human verdicts per category from the review ledger."""
import collections
import json
from pathlib import Path

rows = [json.loads(line) for line in Path("review_ledger.jsonl").open()]
by_category = collections.defaultdict(list)
for row in rows:
    by_category[row["category"]].append(row)

for category, items in sorted(by_category.items(), key=lambda kv: -len(kv[1])):
    accepted = sum(1 for i in items if i["human_verdict"] == "accepted")
    rejected = sum(1 for i in items if i["human_verdict"] == "rejected")
    print(f"{category}: {len(items)} findings, {accepted} accepted, {rejected} rejected")

将这对脚本通过管道从 CI 运行，台账就成为每次评审的副产品，而非手动琐事。

curl -s -X POST http://localhost:8080/review -d @diff.json | python3 review_ledger.py

当服务器优于临时调用时

决策表让工作流程清醒地认识到何时共享服务器值得搭建。

模式很简单：任何你想要比较或审计的内容都属于台账，任何为台账提供数据的内容都应该放在共享服务器上。

局限性及适用人群

当评审工具输出非结构化内容时，这种方法就会失败——因此服务器必须发出具有稳定字段名的 JSON，且解析器必须能容忍缺失字段。台账的诚实度取决于 human_verdict 字段，这意味着作者必须填写它，而跳过这一步的团队最终得到的是一堆噪音语料库。工作流程也是面向批处理的，因此想要即时 IDE 风格反馈的开发者会觉得台账循环太慢，每月只有少量 Pull Request 的个人开发者花在搭建上的时间会多于节省的时间。如果你的团队无法就哪些严重程度应该阻塞合并达成一致，先修复那个政策再构建流水线，因为台账只会暴露分歧。

如果你已经在运行 MonkeyCode 的免费服务器，台账脚本可以在大约十分钟内接入同一条流水线，而第一次月度分析会让你比任何单条评论更了解你的评审工具。