AI Agent 跑一天只出1个PR？复盘三个吞时间的错误

用 AI Agent 写代码，一整天只换来一个 merged diff——这是很多开发者的真实写照。一位开发者以「给昨天早上的自己写信」的形式，复盘了 14 次尝试、3 次被接受的 Agent 运行日，并归因出三个按时间损失排序的错误。本文基于其原始记录，拆解这三个陷阱与可直接复用的补救脚本。

错误一：只记录结果，不记录尝试

原文作者的自我诊断很尖锐：他记住了成功的那几次运行，忘掉了失败的十一次。这不是数据，是情绪。

没有尝试台账（attempt ledger），你无法区分「模型太弱」和「harness 坏了」，也无法在不靠猜的情况下比较两个模型。作者给出的补救方案是一个纯标准库的 Python 脚本 attempt_ledger.py，每次尝试追加一行 JSON，字段包括尝试序号、模型名、判定（accept/reject/error）、墙钟耗时、token 数与失败门（gate）。

脚本的关键约束是：每次尝试后立刻写入，不要在一天结束时批量补记。另一条规则同样重要——reject 也必须带上门名称，用 build、scope 或 proof 三选一，没有门就没有记录行。

作者还强调，summary 输出里的 tok/acc（每个被接受结果消耗的 token）应当被当作成本列来看待。原文给出的示例输出仅展示格式形状，并非实测结果，这一点引用时需留意。

尝试台账（attempt ledger） 借鉴自软件工程中的变更日志与实验科学中的实验记录本，核心思想是：任何一次 Agent 运行都是一次带假设的实验，必须留下可追溯的观测数据，而不是只保留被采纳的结果。它通常以追加式（append-only）的 JSON Lines 文件实现，一行一条记录，天然适合脚本统计与事后 diff。与 CI 日志的区别在于，台账记录的是“决策依据”（哪个门失败、消耗多少 token），而非完整执行输出，因此体量小、可长期保留。没有台账时，开发者只能凭记忆归因失败，容易把环境问题误判为模型能力问题。

错误二：把 Runner 机器当成「雪花」

第六次尝试死于 lockfile 不匹配。问题不在 prompt，而是那台机器相对于昨天已经漂移了。

这是免费服务器选项最诱人的地方，也是隐患藏身之处。作者的做法是在 Agent 运行之前冻结环境：先在干净的代码树上用 sha256sum package-lock.json > env.lock 生成基线，再写一个 preflight.sh，每次尝试前校验环境锁、检查 Git 工作区是否干净。

这个 preflight 能拦住三类失败：过期的 lockfile、未提交的改动、在旧状态上重跑。作者估算，每一类都让他损失了一小时以上。

顺序是全部要点——preflight 要在 prompt 之前跑，而不是在 diff 之后跑。

「雪花服务器」（snowflake server） 是基础设施领域的经典反模式：每台机器都像雪花一样独一无二，配置靠手工累积、无法复现，一旦漂移就难以排查。与之相对的是「凤凰服务器」或不可变基础设施——机器随时可以从代码和锁文件重建。本文的 Runner 机器虽然只是一台免费服务器，但同样适用这一原则：package-lock.json 的 sha256 就是环境指纹，preflight 则是把「不可变」这一约束前移到每次运行之前。理解这一点，就能明白为什么锁文件不匹配不是小毛病，而是环境已脱离版本控制的信号。

错误三：没有评分标准就审 diff

「看起来对」不是一道门，是带额外打字量的抛硬币。作者说，每一个凭感觉接受的 diff，后来都变成了一条 review comment——这是学费最贵的学法。

他的方案是三道门、一个判定，按顺序检查，遇到第一个失败即拒：

门	问题	失败动作
build	测试套件是否通过？	以 --gate build 记录
scope	diff 是否只触及允许的路径？	以 --gate scope 记录
proof	是否有新测试在改动前失败、改动后通过？	以 --gate proof 记录

三道门里最常被跳过的是 proof。具体做法是：先让新测试跑在旧代码上，看着它失败，再接受 diff。作者认为这一步把「模型看起来不错」变成了一个能在 review 里站得住脚的论断。

Proof 门背后的方法是测试先行（test-first），源自 TDD 的红-绿-重构循环：先写一个在旧代码上失败的测试（红），再接受让该测试通过的改动（绿）。在 Agent 场景中，这一步的意义在于验证因果性——新测试的失败证明了它确实覆盖了待修复的行为，而不是一个恒真的空测试。常见误区是只检查「新测试通过」，这在旧代码上也可能成立，从而失去区分力。实践中可要求 Agent 在 prompt 中附带失败测试的输出，作为 proof 门的证据。

免费额度不是万能答案

原文明确把免费层定位为预算选择，而非通用解法，并给出了一张边界表：临时重构、比较两种候选方案这类低爆炸半径的场景适合免费模型加免费服务器；涉及不能发给第三方的代码、需要确定性的发布门、以及延迟敏感的交互工具，则不适合——理由分别是数据处置权在你自己、免费容量是尽力而为而非 SLA、排队行为会传导到用户体验上。

作者的建议是：开工前就把边界写下来。到第六个小时才做这个决定，正是一天消失的方式。

完整闭环：七步循环

1. 提交一棵干净的代码树
2. 运行 preflight.sh
3. 附上失败的测试作为 prompt 输入
4. 应用 diff
5. 跑三道门
6. 记录判定与失败的门
7. 重复；只在一天结束时运行 summary

作者估算整套设置约十分钟，其余时间都花在尝试上。按他的说法，把这封信寄给早上九点的自己，一天的成本会从八小时降到四小时。

这套方法解决不了什么

原文结尾保持了克制：台账不会让弱模型变强，只会让你更早看到真相；免费容量是尽力而为，不要把无法推迟的截止日期压在它后面；没有任何评分标准能替代真正阅读 diff，它替代的是「记住」diff。

需要补充的是，本文引用的 MonkeyCode 免费额度（写作步骤的免费模型访问、运行步骤的免费服务器选项、免费层 1000 万 token 额度）来自原文作者的自述，且该文为 MonkeyCode 的产品推广内容。免费层的额度、服务器规格与条款会变动，围绕它构建一周工作流之前，应先到项目页面确认当前条款。