新智元报道
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还接不住：「这个抽象层算不算过度设计」「这次重构方向对不对」，验收标准全凭品味，写不进提示词。
所以它接走的第一批活儿，并非创造，是打扫。
生成侧已经不缺产能了，缺的是审查侧：谁先看、哪些重复、以及最后谁签字。
工程师的身价，也换了一套算法：以前看写得多快，现在看审得多快。
东南配资提示：文章来自网络，不代表本站观点。
