编码代理返工复盘：先查任务单质量

Claude 负责规划，MiMo 负责写代码，同样的 token 成本约低 25 倍，听起来是套划算的组合。但作者加上自动审查和自检清单后，首轮通过率反而下降了。追查返工项才发现，大部分问题在任务交出去之前就已经埋下了。

这篇最有用的地方，是把「模型没干好」拆成两个问题：任务单有没有交代清楚，执行模型有没有照做。作者的样本不足以证明某种架构更优，却给日常 AI 编程提供了一套可以照着做的排查方法。

审查更严，为什么返工反而更多了

作者统计了两批任务：10 月 11 日至 23 日创建的任务中，62 个已合并，24 个首轮通过，占 39%；加入自动 reviewer 和自检清单后，10 月 25 日至 28 日创建的任务中，14 个已合并，只有 2 个首轮通过，占 14%。其中一个任务单独跑了九轮。

这不能直接说明新增审查让代码变差。审查标准提高，也会让原先漏过去的问题进入返工队列。后面这批样本又小，单个复杂任务就能明显影响结果。

作者于是抽取六个仓库里被退回的 10 个任务，整理第一次审查给出的 61 条「必须修复」意见，再逐条检查任务单有没有明确要求。

结果是：55 条，占 90%，属于任务单没写或表述含糊；另外 6 条，才是任务写清楚了，执行模型没有遵守。例如要求消息使用全角冒号，代码却用了 ASCII 冒号。

前一类问题更隐蔽。一个接口先读文件，再写回结果，任务单却没交代读写之间还有一次耗时 20 秒的模型调用。用户第二次点击，就可能让两次操作互相覆盖。

如果任务单允许一种有缺陷的实现，严格审查只能在实现完成后再把它退回来。

不过，90% 是作者使用 Claude Sonnet 分类的结果，人工只核对了一个任务，结果一致。它是这组样本的归因，不能当成所有 coding agent 的通用比例。

把「挑错」放在写代码之前

作者新增了一道 falsifier 检查，可以理解成「专门找反例的审查」。

它接收任务单，并在实际流程中获得仓库只读权限，但不写代码。它最多返回七条按优先级排序的问题，每条必须包含三个信息：引用触发问题的任务单原句，或者注明「未提及」；给出能让方案出错的具体输入；指出应该把修正补进任务单的哪个章节。

这个格式比「再想想边界情况」更有操作性。检查者不能只说「可能存在并发问题」，必须指出什么操作顺序会出错，以及任务要求该补在哪里。

作者拿同样的 10 个任务做回看测试，这次没有提供仓库访问权限。Sonnet 单次检查约花 $0.07、耗时 34 秒。两次运行的发现差异很大，因此作者选择每个任务检查两次。

作为对照，作者此前统计过：一轮完成的任务约消耗 3.6M tokens，两轮任务约消耗 9M tokens，后者还多一次审查和约 20 分钟等待。这些数字只对应他的流程，但解释了为什么提前检查可能划算。

当天发出的四个实现任务，每个都被找出至少两条 HIGH 问题，包括锁没有覆盖完整的读取、修改、写入过程，半条 JSON 记录可能吞掉下一条记录，以及简单解析器不接受带引号的 frontmatter 值。作者先补任务单，再交给 MiMo。

随后三个任务首次交付通过自动审查，第四个又返工两轮。但作者也明确承认，四个任务说明不了效果，MiMo API 当天持续卡顿，重启还干扰了轮次统计。

文中另提到旧任务按「不需要反馈轮次」计算的通过率是 63%。它与前面的 39% 使用了不同表述，原文没有充分解释统计口径，不能直接拼成一张效果对比表。

最有说服力的反例，恰好来自作者漏检的那个评估任务：任务引用的文件只存在于主工作目录，尚未提交，新的 git worktree 根本看不到。MiMo 花了 23 分钟确认文件不可读。后续检查在另一份任务单里抓到了同类问题。

子代理能不能留，要看隔离和成本是否有用

作者转述的 Anthropic Applied AI 团队 10 月 22 日文章，倾向于使用一个 agent 循环配合 skills，仅在三种情况下保留子代理：上下文膨胀已经造成可测量的退化；任务可以并行，各自需要独立且用完即弃的上下文；单个 agent 无法正确选择工具，或指令存在冲突。

作者保留了执行子代理。每个任务使用独立 git worktree 和新上下文，最多同时跑三个，分支合并后丢弃上下文。此外，MiMo 更便宜；全部收回 Claude 循环，会改变成本结构。

代价是交接时的信息丢失：执行者知道什么，几乎全靠那份 Markdown 任务单。

作者还做了两项调整。每天定时运行四次的发布 skill 原来有 53 KB，每次全部加载；现在拆成 14 KB 核心，其余步骤按需读取。调整前，他编写了 12 个场景、29 个判断点，新旧版本各跑两次。旧版两次都是 28/29，新版两次都是 29/29，旧版错的是跨文件指令冲突。

另一项是把禁止读取凭据的限制放进工具执行前的 hook。原先「不打印凭据」只写在提示词里，9 月被违反四次；现在对凭据路径执行 cat、sed -n 和 Read 时，会在调用前拦截。作者的原则是，同一规则违反两次，就该考虑结构性修复。

我的判断

我认同先查任务质量，再讨论换模型。尤其是多仓库、独立 worktree 的流程，文件是否已提交、修改依赖哪些状态，比补几句「认真检查」更具体，也更容易验证。

但这套方法仍是单人、以 Python 为主的经验。返工分类只抽了 10 个任务，前置检查只报告了四个新任务；评判者与挑错者还来自同一模型家族，可能共享盲点。作者想用 MiMo 做便宜的对照，却因 API 卡顿取消，因此没有跨模型对照结果。

和继续加严交付审查相比，前置检查适合修补需求遗漏；和直接合并成单 agent 相比，它保留了并行隔离与模型价差。但两次检查会增加时间和费用，是否值得，应看实际减少了多少返工。现有数据还不能替一般团队算清这笔账。

能拿来做什么

• 从最近 10 次 AI 编程返工开始，把问题分成「任务没写清楚」和「模型没有遵守」，先确认主要损耗发生在哪里。
• 给复杂任务增加一次只读的反例检查，要求提供具体输入、任务原句和补充位置；涉及异步读写时，明确检查整个读取、修改、写入过程。
• 使用独立 git worktree 执行任务前，确认引用文件已经提交，并把任务依赖写进交接说明，避免执行者耗时寻找不可见文件。
• 修改 skills 或代理架构前，先准备 10 个固定评估案例，每个运行两次；涉及凭据的硬限制，则落实到工具调用层。