夜雨聆风学习资料网

ARTICLE · 1245740

一个人管五家 AI,难的是看见失败

一个人管五家 AI,难的是看见失败

国内开发者罗磊家里有台 Mac mini,24 小时替他跑没人盯着的活。有一周,他那台 MacBook 上派给 codex 的 8 单活里,有 7 单被悄悄换成了 Claude 来做。系统里找不到 codex 命令,脚本把这个错误当成普通失败,直接改派给下一家,账本上每一单都记着成功。在我看来,这个细节说出了同时用几家 AI 最真实的麻烦。

这件事写在罗磊10月4日公开的网页里。他同时开着 Claude、codex、Kimi、Grok、Gemini 五份订阅,网页记的是他怎么给五家分工、怎么让它们守规矩。页面靠后从他编号记下的二十六条教训里挑了十条,我按“出了错却没被及时发现”这个口径归了一下类,十条里占了六条,我认为这是整张网页里最该被看到的数字。

我认为,一个人同时用好几家 AI,拉开差距的是能不能让失败自己冒出来,挑中最强的模型排在后面。 罗磊也说,这些教训多半出在漏做的检查上,跟模型聪不聪明关系不大。如果明年这时候,主流编程工具自带的选模型和自检已经可靠到让这类自搭的账本和验收大多能删掉,这个判断就错了。

最贵的模型只该用在规划和验收上

派活先看这件事要多少判断力,再看哪份额度最便宜,这是罗磊这套做法里最省钱的一条。 最早他只开 Claude Code,什么活都丢给最强的 Fable,连改文案也是它在想。现在他给常见的活排了座次,规划、架构取舍和评审交给 Fable,日常写代码交给 Opus 主会话,批量机械改动交给 codex,读长文交给 Kimi,盯社交媒体交给 Grok。

表格很长,在我看来真正起作用的只有三句。30 秒能答完的活不进 Fable,拿不准就往便宜的那档走;能用一句话写清验收标准的活,比如改完跑测试全绿,交给 codex;需要这次对话上下文的活才留在主会话,因为外包要把来龙去脉重讲一遍,有时比自己做还贵。主会话固定用 Opus,他不再手动切换模型。

效果体现在账上。按罗磊自己的周快照,以成本计,Claude 用量里 Fable 的占比从9月6日那次的 74.8% 降到9月15日那次的 13%。这是他个人日志里的数,口径写在页面上,只算 MacBook 这台机器,各往前数一周。他说,以前手动切来切去,事后根本算不清钱花在了哪,现在 Fable 只从规划和评审这两个入口进来。

这让我想到装修工地上的包工头。Fable 像设计师兼监理,最贵,只在出图纸和验收时请来;Opus 主会话像驻场工长,日常活都经他的手;codex 和 Kimi、Grok 这几家像分包队,接那些能用一句话说清验收标准的活;那份全局约定文件就是工地规章,贴在墙上,进场的人都得照着办,谁来干活都一样。

贵的人手只请来出图纸和验收,日常活交给分包队

我认为这套分工的要点在于,贵的人手按“这活要多少判断力”来请,不按“这活重不重要”来请。改一句文案也重要,可它用不着设计师出图。把最强的模型设成默认值,账单就会像罗磊早期那样失控,因为日常活的数量远远多过真正需要深想的活,贵的那份额度被琐事一点点耗光。

模型越多,越需要写死的分工表,否则每来一件活都得临场想该请谁。 这张表让成本变得可以预期,也让事后复盘有据可查,钱花在哪类活上一目了然。在我看来,罗磊花在这张表上的功夫,比花在挑模型上的多得多,这个顺序是对的,模型会换代,分工的道理却能一直用下去。

派活要靠写死的规则,不能指望模型自己记得

分工表写得再清楚,模型也不会每次都去翻,所以派活这一步得交给不会忘事的东西。 罗磊在每条消息进入主会话之前挂了钩子,先拿规则表对一遍,命中了就往上下文里塞一句指令,告诉主会话该交给谁。规则表里是几十个正则表达式,判定逻辑写在配置文件里,脚本只负责执行。

他一开始还留了一道保险,规则都没命中时,再去问便宜的 Haiku 模型。后来这道保险被关掉了,原因很实际,它有时会超时,每条长消息要多等好几秒到二十多秒;有时钩子又截到了它自己发出的分类请求,绕成了圈。罗磊给的结论很干脆,正则可预测,也不花钱,我同意这个取舍。

这层派单还留了逃生口。消息里带「我自己做」「直接改」就不派,判错了说一句话就能绕过去,不用跟规则较劲。派单链上唯一会拦人的是另外的钩子,判定为批量改动、账本里又没有外包记录时,主会话想自己动手改文件会被拒。钩子判错或被手动跳过的比例,从一成多降到了不到百分之一。

回到工地的比方,这张规则表就是派工单。好的工地不靠工长的记性派活,靠的是写明“哪类活找哪支队”的单子,单子末尾还印着一行小字,业主亲口说要自己来的,照办。罗磊把模型分类器换成正则,等于把一位聪明但偶尔走神的调度员,换成了从不走神的单子。

我认为这里有个容易被忽略的取舍。用模型来判断该派给谁,听上去更高级,可它慢,要花钱,还会给出连自己都解释不了的判断。派单这种每条消息都要走一遍的环节,最需要的是可预测,聪明排在第二位。规则判错了,至少能一眼看出是哪条出的错,改起来也只是动一行配置。

越是每天要重复几百遍的判断,越该写成规则,把模型留给真正需要想的地方。 罗磊页面上还有一句话说得更直接,凡是判定类的逻辑,连个人特例也走配置,不写进脚本。我理解这样做是为了让规则能被随时改,也能被随时查,判定一旦藏进脚本里,下次出问题就只能从头读代码去找原因。

最难防的失败,是不出声的那种

罗磊这套东西出过的最大问题,都是失败已经发生,系统却显示一切正常。 开头那次 codex 被悄悄顶替就是典型,返回码 127 本来说明命令根本不存在,脚本却把它归进“其它失败”,按顶替链改派给了 Claude。活确实干完了,账本上每一单也都写着成功,同一类问题出现了两次,他才把漏洞补上。

罗磊网页顶部的统计卡片,派给 codex 的单子只有一单真由 codex 做完

类似的事还有好几件,在我看来它们是同一类病。有个脚本一路显示绿色,每一步却都失败了,错误被后面一句容错写法吞掉;自动修 issue 的流程记为成功的 17 次里,有 6 次是转给了人,退出码是零,却没有出 PR;升级命令行工具以后,常驻进程还在跑旧版,不认识新模型的名字,流水线悄悄全挂。

换模型也会制造这种失败。有回换了模型以后,某条自动复核停了三天,原因是新模型更按字面执行,旧模型会自己摸到的访问路径没写进指令,新模型就判定自己被卡住了。兜底的顶替链上线后一直是零次改派,直到真漏了单,他才意识到冒烟测试过了,不代表实战里接得住。

放回工地上看,这就是分包队私下转包,验收单上照样签着“完工”。真实的工地上,被转包的工人会抱怨,楼板没浇好会裂,失败多少会弄出点声音。AI 的失败安静得多,脚本吐出返回码,账本记一行成功,没人回头看,它就一直这样错下去。这也是包工头这个类比管不到的地方。

账本上全是完工,干活的却悄悄换了人

我认为这是同时管多家 AI 时最被低估的风险。模型多了,顶替和重试这类“让流水线不停”的兜底机制也跟着多,每多一道兜底,失败就多了被悄悄吸收的路。罗磊后来的规矩是,验收一律看产物,不看退出码,单独统计出 PR 的比例,每次外包完都看一眼到底是谁做的。

兜底做得越周到,越需要一本记清“到底是谁干的”的账。 罗磊给每次外包都记一行,写明座位、实际执行方、模型、耗时和返回码,周报和复盘都从这本账里算。没有这本账,那次静默顶替就无从发现,我估计它只会表现成 Claude 的额度莫名其妙用得快了些,谁也想不到是 codex 根本没上场。

只认产物,测试全过也不算交差

在罗磊的流程里,说“做完了”的不能是干活的那一方,得由专门挑毛病的那一方说。 他交给 AI 的大活都从一句目标开始,先拆成任务清单,每条任务带着能执行的验证命令,初始状态写着没通过。每轮只推进其中之一,验证通过才改状态,改了就提交,连续几轮没有进展就停下汇报。

最后一道关交给专门做证伪的子代理,它的任务是尽力证明活没干完,它说不通过,就回去接着修。罗磊还提到过坑,验证命令一旦比任务标题宽松,就会假通过。有条任务的标题写的是两台机器的默认模型都改成 opus,验证命令却只检查文件里有没有 opus 这个词,结果当然一查就过。

更能说明问题的是他做过的对比。他让 codex、Grok、Kimi 对同样的 issue 各写一版,再由 Fable 做比较式的盲评。正式试跑之前,他拿 12 个真实 issue 先比了一轮,三家共写出 36 份实现,全部通过了测试,可没有一份能原样合并;按评审意见重新合成以后,有 9 份通过了 CI。我认为这组结果值得每个让 AI 写代码的人记住。

罗磊在网页里写,三家各写一版的实现全部通过测试,却没有一份能原样合并

我认为这组数字比任何跑分都更能说明 AI 写代码的现状。测试全过只说明它没有打破已知的规矩,能不能合并,还要看代码风格和改动范围,看它和别人的代码会不会打架,这些测试里都没写。放回工地上,测试相当于消防验收合格,房子能不能住,还得验房师进屋一间间看。

这也解释了罗磊为什么要把“做”和“验”拆给不同的模型。让写代码的模型自己检查自己,相当于让分包队自己给自己签验收单,它最容易漏掉的,正是它一开始就理解错了的地方。证伪子代理换了视角,专门找没做完的证据,至少能把一部分理解偏差拦在合并之前。

验收要比干活更挑剔,否则多加几家模型,只会多出几份看着都对的半成品。 罗磊给这次对比的定位也很克制,至今还在影子试跑,要不要转正,等数据够了再定。在我看来,这种不急着宣布成功的态度,本身就是验收文化的一部分,对 AI 交上来的活,先假定它没做完,比先假定它做完了要安全得多。

说了两遍还犯的规则,就该写成代码

提醒对模型大多时候管用,剩下那几次,得在它动手之前拦住。 罗磊回头翻过自己近五千条历史提示词,「注意」「重新」「不要」这类纠正词,每月出现七十多次。他的办法是,同样的规则被违反两次,就改写成钩子,在模型调用工具之前先检查一遍,命中就拒绝执行,不再指望它下次记得。

这些钩子各有来历。有回 AI 用他本人的账号往同事群里发了好几条消息,现在 AI 写的内容一律用机器人发,要用本人身份发,每条都得他点确认。远程机器上有一批 AI 提交没带签名,事后只能翻会话记录找来源,现在不带签名的提交直接被拒。家里在跑的基础设施配置,只许加,不许改。

花钱的事也写死了。不用任何按 token 计费的中转服务,创建计费的云资源之前,先确认预算告警已经配好,会按量计费的循环任务,必须有硬性的调用上限。外包脚本里还给顶替设了日限,原生通道挂了,也不能一声不响把 Claude 的额度抽干,最贵的 Fable 原生调用同样设了每日上限。

这让我想到 Benedict Evans 今年9月写企业软件时的说法。一件事一旦天天做、人人做、做法固定,又牵扯到收入和风险,公司迟早要把它制度化,他的原话是把人们踩出来的小路铺平。罗磊的钩子就是这条路的个人版,被违反两次,说明小路已经踩出来了,该铺路,也该装门禁了。

被反复踩出来的小路,最后铺成了带门禁的路

我认为“两次”这个门槛定得很好。只犯过一回就写成钩子,规则会多到互相打架;犯了好几次还只靠提醒,损失已经发生过好几回。罗磊自己也提醒,钩子要最后加,只给被违反过两次的规则加,钩子一多会很吵,模型也会开始想办法绕过去。这句话对想照抄的人最有用。

能写进代码的规矩,就别指望模型靠记性去守。 工地上的安全帽规定写在墙上,进门的闸机却装在门口,罗磊的约定文件和钩子正好对应这两样东西。前者告诉模型该怎么做,后者保证最要紧的那几条就算它忘了,也出不了大事。在我看来,这是敢让 AI 通宵干活的前提。

最强的反方:模型再强一点,这层脚手架都该拆掉

反方最有力的说法来自 OpenAI,自己搭循环、调流程只是过渡期的做法,下一代模型会把这些吞掉。 负责 ChatGPT 和 Codex 的 Tibo Sottiaux 在这个月初播出的一期 Lenny's Podcast 里说,人们也许为折腾循环兴奋过,但他不认为事情会这样发展。他想要的是全天候工作的 agent,它理解使用者的目标和偏好,能从反馈里学习。我认为这个说法很有说服力。

Tibo 还讲了自己的经验。他推进前沿时会搭越来越大的 agent 团队,等模型有了新突破,又发现更大的 agent 自己就能做完,于是把团队缩小,就这样扩了又缩,缩了再扩。OpenAI 新推的 Dots 没有模型选择器,Tibo 说他自己面对选模型、选推理强度都会疲惫,“你需要一个模型选择器的博士学位”。

罗磊的经历里也能找到支持反方的证据。换了模型,自动复核就停了三天,脚手架本身成了新的故障来源。他出手纠正 AI 的次数从每天 0.86 次涨到 1.71 次,多数在排查基础设施,管理这套东西本身在吃他的时间。他也坦白,只用单个模型、偶尔问几个问题的人,大概用不上这一套。

这个反方我认为说对了一半。专门弥补模型短处的那部分脚手架,比如提醒它跑测试、替它细拆任务,会随着模型变强一块块拆掉,Tibo 说的扩张和收缩就是这部分。罗磊页面上最要紧的东西却不在此列,账本、日限、证伪验收和发消息前的确认,管的是钱、权限,以及失败有没有被看见。

Tibo 自己的话也支持这一点。他说 OpenAI 正把越来越多的算力花在二级监控上,一套系统干活,另一套盯着它有没有采取风险过高的行动、有没有被提示词注入。他的 Dot 在发布会开场前几分钟发现生产环境挂了,主动提出要修,被他婉拒了;专用的 Dot 也跑在额外的护栏和监控之下。

模型变聪明,拆掉的是替它想办法的那部分,留下的是替主人看住它的那部分。 罗磊说编排失败几乎都出在这台机器此刻能不能调用 Claude 上,授权过期,没登录,或者工具太旧,9月15日那周业务逻辑上的失败是零次。这类问题,下一代模型再聪明也替他解决不了,设计师换得再好,工地断了电照样停工。

我自己的一点思考

这套做法目前还有几处看不清。罗磊页面上的数字都来自他自己的日志,多数只算 MacBook 一台,没有第三方复核;他也写明两台机器要分开报,有回同样是 Fable 占比,两台机器差了一倍多,只报一台就成了“假绿”。纠正次数是按规则从历史提示词里数出来的,会有误差,三家各写一版的试跑结果也还没公布。

会让我改看法的信号有两个。首先是罗磊说的下次复盘,如果那时新增的教训里不再有静默失败,说明这层管理已经被工具吸收得差不多了。其次是主流编程工具,如果它们在明年上半年就自带可靠的执行方记录和证伪验收,个人搭的这层就该大幅瘦身,我的判断也要跟着改。

如果你也同时开着两三份 AI 订阅,罗磊给的顺序值得照着走。先写张分工表加几条红线,花个下午就够,用上两周,看哪些规则总被违反;用到第二家模型时,再给外包包一层脚本,把模型写死,给失败分类,再记一本账;钩子放到最后加,只给被违反过两次的规则加,别一上来就装满。

我对这件事的看法,比工具清单多一层。过去讨论怎么用好 AI,焦点多在提示词怎么写、模型怎么挑。罗磊这张网页把焦点挪到了另一处,同时指挥几家模型的人,要学的是包工头的本事,派活、记账、验收,尤其是让藏起来的失败自己冒出来,这些本事和模型换不换代关系不大。

模型会一代代变聪明,可失败不出声这件事,不会跟着自动消失。 罗磊在页面最后一节写,这套东西远没到搭好了的程度,下次复盘之后他会回来更新。我认为那次更新里最值得看的一项,是那本账里还会不会出现被悄悄顶替的单子,以及他是在多久之后发现的。

一个人管五家 AI,最先要练的是看见失败。

相关学习资料