AI时代-工程师的新工作不是写代码，是审核 AI 写的代码

导读：Claude Code 之父 Boris Cherny 最近在 X 上分享了一个实验：让 Claude 接管自家应用的日常维护。数周时间，Claude 自动开出 388 个 PR，其中 180 个被合并。这篇文章拆解这套机制到底怎么跑起来，以及它对 AI 时代的工程组织意味着什么。

一个值得细看的数字：388

388 这个数字，来自 Anthropic 工程师 Boris Cherny 的一条 X 帖子。

他是 Claude Code 的创建者。过去几周，他让 Claude 接管了自家应用的日常维护，通过一个 Slack 频道指挥，数周内自动开出 388 个 PR，其中 180 个经 Claude Code Review 加人工审核后合并。

这条帖子在 AI 圈很快传开。数字大是一回事，更值得看的是整套流程已经跑通了：从发现任务、执行任务、开出 PR，到代码审查、合并上线，中间几乎没有人参与。

这套流水线每天在运转，覆盖 iOS、Android、桌面、Web、CLI、Agent SDK 六类代码库。

指挥台：一个 Slack 频道

整套机制的核心设置简单得让人意外。Boris 开了一个叫 proj-claude-maintains-apps 的 Slack 频道，在里面 @Claude，然后 Claude 就开始跑一堆例行程序，也就是 routine。

routine 是 Anthropic 的云端定时 Agent 机制。它跟本地循环的区别在于，routine 跑在云端，你合上电脑它也在跑。每个 routine 按固定节奏重复执行同一类任务，可以每小时一次，也可以每天一次。

Boris 的用法是让 Claude 在频道里启动一批 routine，分别负责不同代码库的维护。于是整个维护工作变成了一条没人值守的流水线。

flowchart LR
A[Slack 频道\n@Claude 下达指令] --> B[routine 调度\n每天 20-30 个例行程序]
B --> C[自动执行维护任务\n崩溃修复 死代码清理 抽象统一]
C --> D[自动开出 PR\n几周累计 388 个]
D --> E[Claude Code Review\n+ 人工审核]
E --> F{通过?}
F -- 是 --> G[合并 180 个 PR]
F -- 否 --> H[反馈调优 routine\n次日更准]
H --> B
G --> I[工程师腾出时间\n做新产品 聊用户]

六个例行程序，把维护拆成了可重复的任务

Boris 在访谈里详细讲过这些 routine 分别干什么。挑几个有代表性的说。

崩溃模糊测试（Crash fuzzer）。Claude 在模拟器里打开应用，到处点，想办法把它点崩。找到崩溃后，自己定位根因，然后直接修复。这是一个过去需要专职 QA 反复手测的任务。每天跑一遍，意味着崩溃在用户遇到之前就被发现并修掉了。

重复抽象统一（Dup unifier）。大型代码库里，同一个抽象往往被重复实现了好几遍。Claude 每天扫描代码库，找出这些相似但有细微出入的抽象，提出 PR 把它们统一起来。

死代码清理（Dead-code remover）。先删掉静态分析可判定的死代码；拿不准的，加日志观察，第二天确认真的没被用到，再删。

抽象警察（Abstraction police）。这是 Boris 自己最喜欢的一个。它专门修复泄漏的抽象：本该是同一套东西，因为历史原因在不同地方被实现成了好几份。Claude 每天跨代码库找这种近似重复，然后统一。

实验开关清理。功能已经 100% 全量上线的实验代码，直接从代码库里删掉，让功能正式转正。这类收尾工作最容易被工程师遗忘，routine 会准时补上。

测试增删。给测试覆盖不足的地方补测试；同时删掉没用的测试，很多是以前的模型或者人写出来却从不执行的东西。

现在，每天有 20 到 30 个这样的 routine 在所有代码库里运行。Boris 说，有些 routine 的指令只有一句话，比如"清理死代码"，具体怎么做是 Claude 自己想出来的，他会用静态分析和动态分析结合的方式来确认。

规模意味着什么

Boris 给了一个换算：每天有数百个 agent 在跑这些 routine，有时候是数千个。这些工作过去需要几十名甚至上百名工程师。

工程师被解放出来做什么？做新产品，跟用户聊天，做真正需要人做的判断。

另一个数据点来自他的访谈：他现在约 90% 的代码是在手机上写的，通过 Slack @Claude 和 Claude iOS App 完成。状态好的时候，一天能产出 100 到 200 个 PR，而一年前这个峰值只有 30。

质量是怎么保证的

自动开 PR 不难，难的是开出来的 PR 值得合并。Boris 的做法是分层验证。

第一层是自动化测试，包括单元测试和集成测试。第二层是自动化的代码审查和安全审查，他提到这套自动安全审查的表现甚至超过红队。第三层最实在：通过 MCP 在模拟器、浏览器、终端里实际把应用跑起来，验证改动真的可用。

Claude 通常一次就能把 PR 改对。如果改错了，流程会反馈给 routine 本身：让 Claude 调整自己的 routine 指令，第二天会做得更好。有时候要调好几天，但每次调整都会沉淀到 routine 里，成为长期能力。

这套系统其实在自我训练。每发现一个反复出错的任务类型，就把它固化进 routine 的指令里，下一次同类问题会自动按新方法处理。

这套机制最精华的部分，是他分享的死代码清理原则，他自己叫它 sweeper loop：

静态能判断死的，直接删；拿不准的，加日志；第二天看数据；没命中，就删。

一句话，把静态分析工具界三十年没解决好的问题，变成了一个可观测、可闭环的流程。这套流程的核心在于，让"不确定"有地方安放，让判断可以在数据里自我修正，而不必强求一次删对。

最长的那个 loop：A/B 实验的端到端

他还有一个跑了很久的全自动闭环：A/B 实验的完整生命周期。

Claude 写好实验代码，提出 PR，落地，12 小时后检查线上数据，然后扩大曝光，持续监控，最后自动把赢家上线。整个流程不需要人介入。

这对 AI 从业者意味着什么

第一，维护工作正在变成 routine 的集合。崩溃修复、死代码清理、抽象统一、实验收尾，这些曾经靠人力和耐心堆出来的工作，现在可以被拆成可重复、可调优、可规模化的例行程序。判断哪些任务适合 routine，本身就是新的工程能力。

第二，工程组织的形状在变。过去需要几十上百人维护的代码库，现在由每天运行的 agent 舰队承担。人的价值从执行转移到定义任务、审核结果、做判断。

审核 180 个 PR 依然要花人力，机械劳动的部分已经彻底交给系统了，人审质量反而成了新的瓶颈。

第三，这套方法可以迁移。Boris 给出的入口是 claude.ai/code/routines，任何人都可以创建自己的例行程序。不需要从零发明流程，直接复制他的思路：把重复性维护任务交给 routine，给高层级目标，让模型自己设计方案，错了就让 routine 自我调优。

第四，注意评论区的一个真问题：180 个 PR 的合并背后，是工程师大量的人工审核。有人问 Boris，怎么避免审核多了之后两眼一闭直接点通过。这说明自动化的瓶颈正在从"能不能做"转移到"怎么保证人审质量"，这是下一阶段所有团队都要面对的课题。

结语

Boris 自己说，这还只是"早期迹象"，距离完全自动化维护还有距离。但他对流程设计的信念很明确：给模型一个高层级目标，剩下的交给它自己想办法，错了就调整，让它一天比一天好。

方向已经很清楚了：AI 正在接管 AI 的代码库维护，而工程团队的职责，正在从维护代码，变成维护那套维护代码的系统。

工程师可以去做真正想做的事了。剩下的问题只有一个：我们准备好了吗。