
新智元报道

388个PR,180个被合并。
写这些代码的全是AI。
Claude之父Boris Cherny最近在X上贴出了这组数字。它们来自他过去几周一直在做的一个「奇怪实验」:让Claude接管自家App的日常维护。
他说,从一些早期迹象看来,这条路也许真能走通。


实验现场,是一个名叫「proj-claude-maintains-apps」的Slack频道。
在这个频道里,Claude Tag每天跑一组例行任务,覆盖iOS、Android、桌面端、Web、CLI和Agent SDK六类环境,每条线一个独立Routine,进展各自发进频道的顶层线程。
它像一个真正的同事一样,不等人派活,到点自己上班,找问题,改代码,提PR,然后等人来审。
定期发现问题、提交修改、接受审查、再根据反馈调整任务规则,这样一个闭环,在Anthropic内部已经转了几周。
工程师需要做的,只剩下一个决定是否合并的按钮。
Claude每天上班
干的都是脏活
Boris都给Claude安排了哪些活?先看清单。
崩溃巡检。
在模拟器里把App打开一通乱点,点到它崩为止,然后定位原因、开修复PR,每个PR还得附上复现步骤和一张真值表。
Boris还在Claude的原始指令里特意写了一句:跑起来的必须是真的App,不许拿假的替身糊弄过去。
重复抽象合并。扫描代码库里那些长得像、又不完全一样的实现,提PR把它们并成一个。
死代码清理。这一条最见功夫:静态能确定跑不到的代码直接删;只是「疑似」跑不到的,先埋一段日志观察一天,确认真没人走过,第二天再删。
抽象泄漏修复。谁把不该露的层次露出来了,它去补。
再往下还有:清掉那些怎么跑都通过的测试、揪出时好时坏的测试到底坏在哪、把全量上线的开关从代码里拿掉、那些做完就被遗忘的内部功能,按使用量决定是发出去还是删掉。
先加个日志观察一天再删,这是老工程师才有的手感。

这张清单从头扫到尾,Claude接管的十一项活,没有一项是「做个新东西」。
全是平时最不愿意干、干完也不出绩效、拖到下个季度也没人催的那种活。
写代码变便宜了
审代码就变贵了
一个团队几周内多出388个AI生成的PR,谁来看?
Anthropic在今年3月的Code Review公告里给过一个数字:过去一年,公司人均代码产出增长了200%,代码审查随之成了瓶颈。
而且,这并非Anthropic一家的问题。
工程数据平台Faros AI在2026年放出一份报告,两年遥测,覆盖2.2万名开发者、4000多个团队。

Faros AI《The Acceleration Whiplash》:高AI采用度下,人均epic完成量涨66.2%,每周部署数反而降11.7%。
产出侧确实涨了:人均完成的epic数涨66.2%,任务吞吐涨33.7%,PR合并率涨16.2%。
但每周真正部署上线的次数,降了11.7%。
合并得更多,发出去的反而更少。中间的环节,都堵在审查上。
代价,还得开发者来扛。
落在每个开发者身上的bug数,涨了54%;
每个PR对应的线上事故涨242.7%;合并进去又被删掉的代码,比值涨了861%;PR的平均体积涨51.3%;
最要命的是等待。
等一个人来审的中位时长,涨了441.5%,还有多出31%的PR,一次审查都没经过就合了进去。
这些数字堆下来,就是开发者的一天:按一下按钮,五分钟生成上千行;然后花掉一整个下午,把这上千行一行一行读完。
写代码那部分被AI拿走了,但看代码那部分还得开发者来干。
Code Review就是为这个问题造的,Anthropic公开过一组效果和成本数字:
上线之前,只有16%的PR能拿到实质性的审查意见,上了之后这个数字是54%。
超过1000行的大PR,84%能被查出问题,平均7.5个;50行以下的小改动,比例降到31%,平均0.5个。
工程师标记为「找错了」的发现不到1%。
审一个PR平均要跑20分钟,烧掉15到25美元的token。
这份公告里还提到:这套系统不批准PR,批准是人的事。
它划定的边界是:AI可以主动找问题、改代码、开PR,全程不用人批准。但每一处变更都停在PR里,合不合进主分支、上不上线,最后一下点确认的必须是人。
Boris在帖子里写了下一步:想办法降低这类机械性改动的合并成本。
他要降的是合并成本,因为卡点已经不在生成那一头了。
Boris修的不是PR
是Routine
再看这套系统是怎么搭起来的,三个部分分工很清楚。
Claude Tag是入口。它挂在Slack频道里,被@时响应,也会在权限和指令允许的范围内主动接活。
Anthropic在8月13日刚给它做过一次升级,让它结合整个频道的上下文判断什么时候该出手、什么时候该不动。
Routines(例行任务)是执行层。
这是4月14日推出的功能:一次性配好提示词、代码仓库和连接器,之后按时间表跑、由API调用触发,或者响应GitHub事件自动启动。
它跑在Claude Code的云端设施上,不依赖本地设备。

Claude Code Routines运行机制:定时、API调用与GitHub事件三种触发方式,跑在云端。
Claude Code Review是审查层,人类是批准层。
四层串起来,才有了那个每天早上自动开工的频道。
但最值得学的,是Boris的调优方式。
某一类PR老是不过关,他不去一个一个改那些失败的PR,而是回头改生成它们的Routine,然后观察接下来几天的表现。
有时候一类任务要连着调好几天,才稳下来。
一句话:不修结果,修规则。
提示词在这里不再是一次性的输入,而是一套要长期运维的资产:写好、上线、观察、迭代,跟养一个线上服务没区别。
这也是为什么这套东西能越跑越顺。
每一次调整都沉淀进规则里,第二天生成的那批PR里,就会少几个不该出现的。
想复刻
先过这几关
工具这一层是公开的。
Routines对Pro、Max、Team和Enterprise开放,Pro每天5个,Max 15个,Team和Enterprise 25个,在claude.ai/code里点几下就能建,或者在CLI里敲一个/schedule。
但真正的门槛在别处:
仓库权限敢开到什么程度,测试覆盖兜不兜得住,有没有能跑真机的模拟器环境,审查按次烧钱吃不吃得消,以及最难的:有没有人愿意为一个AI提的PR按下合并键。
同样是这个月,Rust项目刚给AI贡献立了规矩:AI生成的代码得事先打招呼、不能碰关键路径、测试要充分、还得如实披露用了大模型;涉及soundness的关键改动,强烈不建议交给大模型生成。
最要紧的,是维护者没有义务审查AI提交的PR,可以直接关掉。

个体开发者能从Boris这个实验里抄走的,也是这一条规则:先把验收条件最明确的那类活儿交出去。
能验出对错的活,AI现在接得住:这个操作能不能把App点崩、两处写法是不是同一件事、这条测试是不是永远不会挂,都能当场验一遍。
那些说不清怎么算做对的,AI还接不住:「这个抽象层算不算过度设计」「这次重构方向对不对」,验收标准全凭品味,写不进提示词。
所以它接走的第一批活儿,并非创造,是打扫。
生成侧已经不缺产能了,缺的是审查侧:谁先看、哪些重复、以及最后谁签字。
工程师的身价,也换了一套算法:以前看写得多快,现在看审得多快。





京公网安备 11011402013531号