同一个错误转第二圈，就该叫第二个模型了

我现在的活儿基本是两套模型分着干：一个负责写，一个只在三处被叫醒。

刚开始我是反过来的，什么任务都挂在最贵的那档上。跑了一阵发现，钱不是花在改代码上，是花在每一轮都重新问一遍"方向对不对"上。而后者的答案，绝大多数轮都是"对，继续"。

这套分工值不值得？值得。但它值钱的地方不是多买了一个模型，而是少叫它几次。下面是我实际在用的配置，以及踩过的坑。

先说清楚浪费在哪

很多人算这笔账只算单价：强模型贵几倍，那就少用。这个算法会误导人。

浪费真正的产生方式是：一轮里模型要做两类事。一类是继续干，改一改、跑一下、看一眼报错；另一类是判断，该不该换方案、是不是挖错了方向、这活能不能收了。第一类每轮都发生，第二类其实很少发生。可你要是把强模型挂在主会话上，它每一轮都会顺带把第二类也想一遍。

想一遍不一定有产出。大多数轮里它想完还是"按刚才说的继续"，这部分开销换不来任何新信息。

所以判断标准可以先简化成两个问题：这个动作是不是每轮都发生？它大多数轮里有没有改变结论？两个答案分别是"是"和"没有"，就该把它从主循环里挪出去。

三个值得打断的节点

评审角色我单独放在一个配置里，只在三个时刻叫醒。

出方案之前。这是最贵也最值的一次。方向错了，后面每一轮都在给它打工。

同一个错误第二次出现。第一次报错，主模型自己修是合理的；同一个错又以相近的样子回来，说明大概率不是手滑，是找错了地方。这时候叫第二个模型进来，换个角度排查。

宣布完成之前。用一个验收的视角过一遍：说好的都做了吗，边界情况呢，有没有"看起来好了"但压根没跑起来的东西。

怎么把这套分工落下去

主会话挂主力模型，推理档位拉高。我这边是 GPT-6.1 Sol，档位 high。

三个执行角色拆开：读代码的、改代码并跑测试的、查文档的。前两个轻，放中档模型加中等推理档位就够，改代码那个可以给好一点。查文档这种活尤其不值钱，用最便宜的模型加中等档位完全能扛。

评审位单独一个模型，高推理档位，职责只有一条：审方案、审重复出现的错误、审收尾。它不碰代码，写完就退场。

需要人工批准的动作用自动评审过一层，省掉那些一眼就能过、但你得挨个点的确认。

落到文件上无非三处：agents 目录里给每个角色一份配置；主配置里定主模型和推理档位；项目说明文件里加一条规则，写明"大方案开工前、同一个错误第二次出现时、宣布完成前，叫评审"。

改配置这一步有个姿势值得抄：让工具先把每一处改动做成 diff 给你看，你说继续它才动手。顺便让它列出"有哪些东西会覆盖掉这套配置"——别处的 profile、你 shell 里的别名、默认子代理模型。这些不报出来，配置改完跟没改一样。

别一次上全套。先只加第二个节点，也就是"同一个错第二次出现"那一处，跑通了再加另外两个。

四个容易翻车的地方

第一个是触发条件。这套东西成立的前提是"同一个错误第二次出现"能被自动认出来，靠人盯着就不成立了。务实的做法是盯报错指纹，或者干脆盯同一个命令连续挂两次。再不行就用固定节点兜底，比如测试连挂两次就进评审，牺牲一点精度换自动化。

第二个是评审看不到现场。别丢一句"我卡住了"就完事，那样它只能给你一堆正确的废话。交底要给四样：失败的命令、完整报错、相关的那段改动、已经试过哪些修法。然后要它做两件事：提出另一个可能的原因，以及给一个能区分这两种原因的测试。这样评审给出来的不是建议，是可验证的下一步。

第三个是分工不等于并行。多个角色看着像同时在跑，实际可能都在一条队列里排队，时间并没有省下来。另外评审意见得落成明确的改动，执行位接不住的话，多出来的那一层就只是多了一层翻译。

第四个是收尾评审替代不了验收。收尾自检能挡住"说完成了其实没跑起来"这类问题，但它本身也不是免检的——gate 自己跑的命令一样会失败。最终还是要有一个能跑起来的验收步骤，评审只是让它少漏。

还有一种情况不值得上这套：任务短到一轮能做完，或者需求本身你还没想清楚。前者多一个模型就是多一份开销，后者需要的是先想明白，不是一个更聪明的评审。

我会怎么起步

先加一个点，就"同一个错第二次出现"那一处，其余照旧。

跑一周看两个数：返工次数有没有降，平均每轮的花销有没有下来。有变化就留着，再加第二个节点；没变化就砍掉，别因为配置都写好了就硬留着。

用一句话收尾：把贵的判断力花在岔路口上，别让它陪着跑直线。