388个PR全部AI操刀，180个已合并！Claude之父：程序员只剩下签字

新智元报道

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还接不住：「这个抽象层算不算过度设计」「这次重构方向对不对」，验收标准全凭品味，写不进提示词。

所以它接走的第一批活儿，并非创造，是打扫。

生成侧已经不缺产能了，缺的是审查侧：谁先看、哪些重复、以及最后谁签字。

工程师的身价，也换了一套算法：以前看写得多快，现在看审得多快。

参考资料：

https://x.com/bcherny/status/2088014489438621990?utm_source=chatgpt.com

https://pages.faros.ai/hubfs/AI_Engineering_Report_2026_The_Acceleration_Whiplash_Faros.pdf

https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/

编辑：元宇