用 Git 与 PR 核验 AI 编码任务是否交付

AI 编程代理说「完成了」，代码却可能还躺在本地分支里。作者带着一个小型电商工程团队，用 Codex 和 Claude Code 写代码、开 PR、互相审查，还启动子代理。他盘点最近 60 天的记录后发现：启动任务很容易，确认交付却没有跟上。

他的做法很直接：每小时用程序读取 Git、PR 和会话记录，把完成状态交给可核对的事实。这个案例值得看的，是如何把代理的工作汇报变成一份可信的待办账本。

看起来很忙，究竟交付了多少

作者统计到，最近 60 天里，他创建的 560 个 PR 有过更新；Codex 里约有 4,800 条子代理线程，另有约 360 个手动启动的会话。一个仓库的磁盘上甚至留着超过 100 个 worktree，也就是供不同任务独立工作的检出目录。

但约 490 个分支从未合并，也没有 PR、审查记录或作者本人参与的会话。多数来自子代理任务：写完总结，就继续下一件事。

这些数字不能直接算出失败率。PR、线程、会话、分支不是同一个统计单位，未合并分支也可能已经废弃。它们能说明的是：代理报告任务结束，不能证明代码已经进入交付流程。

「完成」应该由什么证据决定

作者做了一个每小时运行的采集器。它不读取代理对成果的描述，只检查实际记录。

下面这段代码定义了完成、待审查和未完成三种状态：

def status(branch, prs, sessions):
    if any(p.state == "MERGED" for p in prs):
        return "done"
    if branch.merged_into_default and not branch.dirty and not branch.unpushed \
            and last(sessions) <= branch.last_commit:
        return "done"
    if any(p.state == "OPEN" for p in prs):
        return "in_review"
    return "unfinished"   # dirty, unpushed, unmerged, or a session after the last commit

重点看 last(sessions) <= branch.last_commit：即使分支合并过，只要之后又有会话操作，就不能仅凭旧提交认定任务完成。第二条路径还要求没有未提交、未推送的内容。

仓库外的工作，以及主分支上没有后续提交的会话，会被标为 unknown。无法验证，就保留不确定性。

状态之外，采集器另加提示：开放 PR 超过 3 天无人处理，标记 waiting；仅存在本地的工作标记 unpushed 或 uncommitted；14 天没有活动，标记 stale。标题和分支中的关键词用于提示 prod、security、deadline，但这只是关键词匹配，不代表做过风险分析。

待办太多，也会让账本失去作用

第一版列出了 313 个 unfinished 项，作者认为根本没法用。大量条目只是再也不会处理的代理分支。

他随后加了一条折叠规则：没有 PR、没有本人会话、连续 3 天没有活动的分支，按仓库合成一行，例如「12 个没有 PR 的未合并分支」。它们进入清理视野，不再逐条挤占日常待办。

性能也得收敛。外置磁盘上，对超过 100 个 worktree 执行 git status 需要几分钟。改成只检查最近两周确实被会话使用过的检出目录后，一轮采集约需 25 秒。

采集器只用 Python 和标准库，把结果写成私有仓库里的几个 Markdown 文件和一个 JSON 文件。聊天助手可以读取它们安排当天工作，但不能修改状态。

第一次运行就发现了等待审查六天的 PR、默认分支上的未提交文件，以及 PR 已关闭、分支上却仍有未推送提交的情况。信息一直存在，只是之前没有集中呈现。

我的判断

我赞成把状态判定和自然语言总结分开。代理可以解释做了什么，是否提交、推送、合并，则适合由确定性规则核验。相比让另一个模型阅读聊天记录判断进度，这套办法更容易追查依据。

但这里的 done 更接近「Git 流程已收口」。合并不能证明功能正确、测试通过或已经上线；原文也没有说明如何处理 squash、rebase，以及分支与多个 PR 的对应关系。实际复用时，这些都会影响判断。

把闲置分支折叠起来很实用，但「3 天」「14 天」属于作者团队的经验阈值。原文没有前后交付效率的对照数据，也没有证明这套工具让团队更快。它目前证明的是：作者找到了遗漏，并降低了核对状态的成本。

能拿来做什么

• 给日常 AI 编程任务约定可验证的结束条件，例如代码已提交并推送、PR 已创建；验收时同时核对记录和代理总结。
• 如果经常让 Codex 或 Claude Code 并行处理任务，可以定期汇总 PR、分支和会话，把未提交、未推送、待审查分别列出。
• 给废弃代理分支设置聚合规则，先集中展示需要人接手的事项，再安排清理；折叠展示不等于确认可以删除。
• 让助手基于采集结果安排工作，同时把状态修改权留在采集规则中；无法关联到仓库或提交的任务，明确显示 unknown。