Claude 自动维护项目，几周开出 388 个 PR：AI 编程开始接管脏活累活

2026 年 8 月 14 日，Claude Code 负责人 Boris Cherny 分享了一个已经运行数周的实验。

他没有继续测试 Claude 能不能一口气写出一个新应用，而是把 Claude 放进了软件开发里最琐碎、最容易被拖延的一层：日常维护。

Claude 会从 Slack 频道接收任务，运行崩溃模糊测试，统一重复代码，移除死代码，再把修改整理成 Pull Request。几周下来，它创建了 388 个 PR，其中 180 个在经过 Claude Code Review 和人工审核后合并。

这组数字来自 Boris 的个人实践，不是 Anthropic 对所有团队的效果承诺。388 个 PR 也不能直接理解成 388 次成功修复。已合并的 180 个约占 46%，剩余 PR 可能仍在审核、被判定没有必要、与其他修改重复，或者没有达到合并标准。原帖没有公布更细的分类。

即便把这些限制写清楚，这个案例依然很有参考价值。

AI 编程过去主要发生在一个人盯着聊天框的时间里。人提出需求，Agent 修改代码，人继续追问。Boris 的实验把工作方式向前推了一步：团队先定义长期任务、验收条件和权限范围，Claude 按节奏反复运行，工程师只处理到达审核口的结果。

388 个 PR 背后，变的是 Claude 在团队里的位置

开发者让 Claude 写一个函数，通常只会产生一次结果。日常维护没有明确终点。

代码库每天都在变化。新的重复逻辑会出现，旧功能下线后会留下死代码，依赖升级可能引入兼容问题，测试也会随着业务变化逐渐失效。靠人集中清理，这些任务经常被挤到“以后有空再做”。

Boris 采用的方式更接近一条持续运行的维护流水线：

Slack / GitHub / 定时任务发现维护需求
                    ↓
Claude 在限定仓库和环境中分析问题
                    ↓
修改代码并运行测试、类型检查或复现脚本
                    ↓
创建 PR，附上证据、影响范围和回滚说明
                    ↓
Claude Code Review 做第一轮审查
                    ↓
工程师决定合并、退回还是关闭

Slack / GitHub / 定时任务发现维护需求
                    ↓
Claude 在限定仓库和环境中分析问题
                    ↓
修改代码并运行测试、类型检查或复现脚本
                    ↓
创建 PR，附上证据、影响范围和回滚说明
                    ↓
Claude Code Review 做第一轮审查
                    ↓
工程师决定合并、退回还是关闭

人仍然负责规划和批准，Agent 承担执行。

Anthropic 在另一项针对约 40 万次 Claude Code 会话的研究中也观察到类似分工。典型会话里，人类作出约 70% 的规划决策，Claude 作出约 80% 的执行决策。这个比例不该被当成每个项目的固定公式，却能解释为什么维护工作适合交给 Agent：人先写清楚“该检查什么”和“什么结果能合并”，Claude 再完成大量搜索、修改和验证动作。

哪些维护任务适合交给 Claude

能自动创建 PR，不等于所有工程任务都应该自动化。第一批任务应当具备四个特征：范围清楚、结果可验证、修改可回滚、失败影响有限。

1. 重复代码治理

Agent 可以定期扫描相似实现，判断能否复用同一工具函数，并在 PR 里列出被替换的位置。

这类任务的验收标准比较明确：测试通过、公开接口不变、重复代码量下降。难点在于“看起来相似”的业务逻辑未必应该合并，所以第一阶段应限制到同一模块，避免跨业务域抽象。

2. 死代码和过期配置清理

已经下线的 feature flag、无人引用的函数、旧版配置项和废弃脚本，很适合进入周期性检查。

Agent 需要同时检查静态引用、动态加载和部署配置。只跑一次文本搜索不够。PR 中还应说明它检查了哪些入口，方便审核者判断是否漏掉反射、插件或运行时调用。

3. 测试补齐与失败归因

对于已有 bug、稳定复现步骤和明确预期结果的任务，Agent 可以先补回归测试，再修改实现。

如果失败具有随机性，可以让 Agent 汇总多次运行结果、环境信息和失败堆栈，先创建调查报告，不急着修改生产代码。Boris 提到的崩溃模糊测试就属于这一方向。

4. 文档与代码同步

接口参数、环境变量和 CLI 命令发生变化后，文档很容易落后。Agent 可以在代码变更触发后检查 README、API 示例和迁移说明。

Anthropic 的 2026 AI Agent 报告披露，Doctolib 将 Claude Code 以 headless mode 嵌入 CI，让代码变更自动触发技术文档更新。该公司还建立了集中管理的 prompts、commands 和 subagents 仓库，减少每位工程师从头配置的成本。

5. 低风险依赖更新

补丁版本升级、锁文件更新和明确的安全修复可以进入候选范围。Agent 应运行完整测试，并单独列出 changelog 中可能影响当前项目的变化。

大型框架跨版本迁移、数据库驱动升级和身份认证依赖，不适合作为第一批无人值守任务。它们需要迁移设计和分阶段验证。

6. CI、Lint 和类型错误修复

格式、类型和可稳定复现的 CI 错误有天然的机器验收标准。Agent 可以读取失败日志，定位修改并重新运行检查。

Claude Code 目前也提供 PR auto-fix 能力，可以监控 CI 失败和审查意见，在判断修复路径明确时继续提交修改。但自动修复不应绕过现有的分支保护和必需检查。

三档权限，比“全自动或全手动”更实用

团队刚开始尝试时，经常在两个极端之间摇摆。

一种做法是每一步都弹出确认，工程师很快会机械点击同意。另一种做法是直接开放写权限和自动合并，一次错误就可能触及大量文件。

更稳妥的做法是按照影响面划成三档。

权限档位	Agent 可以做什么	典型任务	人工位置
绿色	读取、分析、运行只读检查、创建报告	重复代码报告、测试缺口、依赖清单	人决定是否进入修改
黄色	创建分支、修改代码、运行测试、提交 PR	死代码清理、文档同步、Lint 修复	必须人工审核后合并
红色	不允许 Agent 直接执行，只能给方案	数据迁移、权限系统、账单逻辑、生产配置	人工设计、实施和双人复核

第一周只开绿色任务。输出稳定后，再把其中一两个规则清楚的项目升到黄色。红色任务可以让 Claude 做影响分析，但不要给它生产写权限。

一条能复用的维护 Routine，至少要写清六件事

Claude Code Routines 可以按时间、API 请求或 GitHub 事件触发，在 Anthropic 托管的云端环境中运行。它会自动执行，因此任务描述不能依赖运行中再问人补信息。

下面这份模板适合改成团队自己的维护例程：

# 任务
检查 src/payments 目录中未被引用的代码，只处理最近 30 天没有调用记录、
且不存在动态注册标记的内部函数。

# 允许范围
- 只读取和修改 src/payments 与 tests/payments
- 可以运行单元测试、类型检查和静态引用分析
- 只能创建 claude/ 前缀分支和 Pull Request

# 禁止操作
- 不修改数据库 schema、权限策略和支付状态机
- 不访问生产环境、真实密钥或客户数据
- 不自动合并，不直接推送 main

# 验收标准
- 全量单元测试通过
- 类型检查和 lint 通过
- 对每个删除项列出静态引用、动态加载和配置注册的检查结果
- 修改后公开接口保持不变

# 失败处理
- 证据不足时停止修改，改为输出调查报告
- 测试不稳定时保留日志并标注复现次数
- 一次最多修改 5 个文件，超出后拆分 PR

# PR 必须包含
- 为什么要改
- 改了哪些文件
- 运行了哪些验证
- 仍然存在什么不确定性
- 如何回滚

# 任务
检查 src/payments 目录中未被引用的代码，只处理最近 30 天没有调用记录、
且不存在动态注册标记的内部函数。

# 允许范围
- 只读取和修改 src/payments 与 tests/payments
- 可以运行单元测试、类型检查和静态引用分析
- 只能创建 claude/ 前缀分支和 Pull Request

# 禁止操作
- 不修改数据库 schema、权限策略和支付状态机
- 不访问生产环境、真实密钥或客户数据
- 不自动合并，不直接推送 main

# 验收标准
- 全量单元测试通过
- 类型检查和 lint 通过
- 对每个删除项列出静态引用、动态加载和配置注册的检查结果
- 修改后公开接口保持不变

# 失败处理
- 证据不足时停止修改，改为输出调查报告
- 测试不稳定时保留日志并标注复现次数
- 一次最多修改 5 个文件，超出后拆分 PR

# PR 必须包含
- 为什么要改
- 改了哪些文件
- 运行了哪些验证
- 仍然存在什么不确定性
- 如何回滚

模板里最容易被忽略的是“失败处理”。无人值守 Agent 遇到模糊条件时，不能靠猜测继续推进。允许它停止并提交调查报告，往往比逼它必须产出代码更省审核时间。

PR 数只能看工作量，质量要看另外四项

388 很醒目，也很容易把团队带到错误目标上。如果考核 Agent 每周创建多少 PR，它会倾向于把修改拆得更碎，甚至不断提交低价值清理。

团队还需要记录以下四项：

指标	计算方式	它回答的问题
有效采纳率	最终合并的有效 PR / 已审结 PR	Agent 找到的问题是否值得改
首轮通过率	无需返工即可通过的 PR / 已合并 PR	任务说明和验证是否充分
人工审核时长	从开始审核到给出决定的中位时间	Agent 有没有减少人的工作
回滚与事故率	合并后被回滚或引发事故的 PR / 已合并 PR	自动化有没有把风险转嫁给生产环境

还可以单独统计重复 PR、无变化 PR、测试不充分和越界修改。它们能直接指向 Routine 的哪一条规则需要调整。

Boris 提到，Claude 一次就能完成不少修改；如果例程表现不好，他会调整任务规则，让第二天的运行吸收这次经验。需要持续修改的是任务范围、验证条件和结果出口组成的整套流程。

7 天试运行方案

不需要一开始就复制 388 个 PR 的规模。一个仓库、一类任务和一个星期，已经足够发现大部分流程问题。

第 1 天：选择任务。 从文档同步、Lint 修复或测试缺口中选一类，不碰生产权限和数据结构。

第 2 天：建立基线。 人工完成一次同类任务，记录耗时、检查项和常见遗漏。这份记录会变成 Agent 的验收标准。

第 3 天：只生成报告。 暂不允许改代码，检查 Agent 找到的问题是否准确，有没有重复和误报。

第 4 天：开放创建分支和 PR。 限定目录、文件数和命令白名单，禁止合并。

第 5 天：增加机器门禁。 把单测、类型检查、lint、安全扫描和必要的回归脚本设为必需检查。

第 6 天：统计人工成本。 记录审核者读 PR、验证结论和要求返工花了多久。Agent 创建 PR 很快，但审核更慢，就没有节省团队时间。

第 7 天：只调整一到两条规则。 先修复最常见的误报或越界问题，再决定是否增加任务频率和仓库范围。

Claude Code Routines 和自建 API Agent，不要混成一套方案

落地时需要先决定执行环境。

Claude Code Routines 是 Anthropic 的托管能力。它可以绑定仓库、连接器和触发条件，在电脑关机后继续运行。官方文档也提醒，Routine 会自主运行，包含的连接器可以执行写操作，分支推送权限和网络访问应按任务最小化配置。

如果团队希望自己控制调度器、容器、模型路由、预算和日志，可以通过 Agent SDK 或模型 API 搭建维护服务。常见结构如下：

GitHub / CI / 定时器
        ↓
自建任务编排与权限策略
        ↓
模型 API 接入层
        ↓
隔离执行环境
        ↓
测试、代码审查与人工合并

GitHub / CI / 定时器
        ↓
自建任务编排与权限策略
        ↓
模型 API 接入层
        ↓
隔离执行环境
        ↓
测试、代码审查与人工合并

在第二条路线中，Apito.ai 可以放在模型 API 接入层，用于集中管理 API Key、Base URL、模型调用和用量记录。实际可用模型和接口能力应以平台控制台当前展示为准。

已经配置过旧请求地址的程序，只需要把请求地址更新为 apito.ai，其他参数保持原有配置。上线前仍要在测试环境重新验证鉴权、流式输出、工具调用、超时和错误重试，不能因为只改了域名就跳过回归测试。

这里需要明确一个边界：Apito.ai 不能替代 GitHub 分支保护、执行沙箱、代码测试和人工审核。模型接入解决的是调用入口，能不能安全合并代码取决于后面的工程门禁。

388 个 PR 给团队留下的可复制结论

Boris 的实验没有证明 AI 可以独立接管软件项目。180 个合并结果反而提醒团队，Agent 输出仍然需要筛选。

这个案例展示了一条更现实的路线。开发者把重复发生、验收清楚的维护任务整理成 Routine；Agent 负责扫描、修改、验证和提交；代码审查与工程师守住合并出口；运行数据再反过来修改规则。

新功能依旧需要产品判断和架构设计。那些长期堆在 backlog、每次都不难、却总没人愿意处理的维护工作，已经可以先交给 Agent 跑一轮了。

FAQ

1. 388 个 PR 是否代表 Claude 成功修复了 388 个问题？

不能这样理解。388 是创建的 PR 数量，180 个经过 Claude Code Review 和人工审核后合并。原帖没有说明其余 PR 分别处于待审、关闭、重复还是验证失败状态，因此不能把 388 当成成功数，也不能把 180/388 简单当成模型准确率。

2. 哪类项目适合先试 Claude 自动维护？

测试较完整、分支保护明确、能在隔离环境运行、日常维护任务重复度高的项目更容易起步。缺少测试、依赖生产数据或存在大量动态行为的旧系统，应先补验证能力，再开放自动修改。

3. 可以让 Agent 自动合并 PR 吗？

技术上可以配置相关能力，但首轮试运行不建议开启。先观察有效采纳率、回滚率和人工审核时长。即使后续开放，也只应覆盖低风险目录，并保留必需 CI、分支保护和回滚机制。

4. Claude Code Review 会替代人工代码审查吗？

官方 Code Review 会用多个 Agent 检查逻辑错误、安全漏洞、边界情况和回归风险，并对候选问题进行验证和去重。官方文档明确写明，它的发现不会自动批准或阻止 PR。业务逻辑、产品影响和上线决定仍然需要项目成员负责。

5. 使用 Apito.ai 后，还需要自己做成本和调用监控吗？

需要。平台记录可以帮助团队查看模型调用和用量，但项目侧仍应记录任务 ID、仓库、运行时间、Token 消耗、失败原因和最终是否合并。只有把模型账单与实际交付结果关联起来，才能判断某条维护 Routine 是否值得长期运行。

6. 应该为所有维护任务选择同一个模型吗？

没有必要。报告整理、分类和简单静态检查可以使用成本较低的模型；跨文件分析、复杂测试修复和代码审查再使用推理能力更强的模型。切换前应使用同一批真实任务做对照测试，比较有效采纳率、返工次数和单个合并 PR 的总成本。

参考资料

说明：本文中的 388 个 PR、180 个合并等数据来自 Boris Cherny 于 2026 年 8 月 14 日前后公开的个人实践。团队落地效果会受到代码库、测试覆盖、任务设计、模型选择、权限和审核流程影响。