Claude 接管 App 日常维护：388 个 PR 已有 180 个合并

Anthropic 工程师 Boris Cherny 最近在 X 上公布了一组数据：过去几周，Claude 为公司 App 提交了 388 个 PR，其中 180 个已被合并。这些代码全部由 AI 生成，工程师的角色被压缩为「按下合并键的人」。消息一出，迅速在开发者社区引发对 AI 编程时代工作流重构的讨论。

实验现场：Claude 像同事一样上班

整个实验运行在一个名为「proj-claude-maintains-apps」的 Slack 频道中。Claude Tag 每天跑一组例行任务，覆盖 iOS、Android、桌面端、Web、CLI 和 Agent SDK 六类环境，每条线对应一个独立 Routine，进展各自发到频道的顶层线程。

Claude 不等人派活，到点自己上班，找问题、改代码、提 PR、等审查，再根据反馈调整规则，形成闭环。工程师需要做的，只剩一个决定是否合并的决定。

Boris 给 Claude 安排的十一项任务包括：崩溃巡检、重复抽象合并、死代码清理、抽象泄漏修复、揪出时好时坏的测试、清理全量上线开关、按使用量决定内部功能去留等。这些工作有一个共同特征：全是平时最不愿干、干完也不出绩效的「脏活」。

388 个 PR 背后：审查才是真正的瓶颈

Anthropic 在今年 3 月的 Code Review 公告中披露：过去一年，公司人均代码产出增长了 200%，代码审查随之成为瓶颈。工程数据平台 Faros AI 在 2026 年的报告进一步印证了这一趋势，其遥测覆盖 2.2 万名开发者、4000 多个团队。

报告中的关键数据：

人均完成的 epic 数上涨 66.2%
任务吞吐上涨 33.7%
PR 合并率上涨 16.2%
每周部署数反而下降 11.7%
每个开发者承担的 bug 数上涨 54%
每个 PR 对应的线上事故上涨 242.7%
合并后又回退的代码比值上涨 861%
等审查的中位时长上涨 441.5%
31% 的 PR 未经任何审查即被合并

写代码那部分被 AI 拿走了，但看代码那部分还得开发者来干。Anthropic 的 Code Review 系统数据显示，上线前只有 16% 的 PR 能获得实质性审查意见，上线后这一比例升至 54%；超过 1000 行的大 PR 中 84% 能被查出问题，平均 7.5 个。审一个 PR 平均耗时 20 分钟，消耗 15 到 25 美元的 token。

系统架构：Tag、Routines 与 Review 三层协作

整套系统由三部分组成：Claude Tag 是入口，挂在 Slack 频道里，被 @ 时响应，也在权限范围内主动接活；8 月 13 日的升级让它能结合频道上下文判断何时出手、何时不动。

Routines 是执行层，今年 4 月 14 日推出，配置好提示词、代码仓库和连接器后，可按时间表、API 调用或 GitHub 事件触发，运行在 Claude Code 的云端设施上，不依赖本地设备。

Claude Code Review 是审查层，人类掌握最终批准权。AI 可以主动找问题、改代码、开 PR，但每一处变更都停在 PR 环节，合不合进主分支、上不上线，最后一下必须由人确认。

Boris 的调优思路也值得关注：某一类 PR 老是不过关时，他不逐一修改失败 PR，而是回头修改生成它们的 Routine，观察后续表现。「不修结果，修规则」，提示词在这里成为需要长期运维的资产，跟养一个线上服务无异。

复刻门槛与行业回应

工具层面，Routines 已对 Pro、Max、Team 和 Enterprise 用户开放，Pro 每天 5 个、Max 15 个、Team 和 Enterprise 25 个，在 claude.ai/code 中即可配置。

但真正的门槛在于：仓库权限敢开到什么程度、测试覆盖是否充分、有没有能跑真机的模拟器、审查成本能否承受，以及是否有人愿意为 AI 提的 PR 按下合并键。

Rust 项目同月发布的 LLM 政策也呼应了这一方向：AI 生成代码需事先声明、不得碰关键路径、测试要充分、涉及 soundness 的改动强烈不建议交给大模型，维护者无义务审查 AI 提交的 PR，可直接关闭。

个体开发者能从 Boris 的实验中抄走的经验是：先把验收条件最明确的任务交给 AI——能当场验证对错的活，AI 接得住；那些「算不算过度设计」「重构方向对不对」之类依赖品味的判断，AI 还接不住。生成侧已不缺产能，缺的是审查侧的能力：谁先看、哪些重复、最后谁签字。