个PR由AI完成180个已合并，程序员只负责签字？

时间：2026-08-16 | 作者：318050 | 阅读：0

新智元报道

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，可以直接关掉。