2026 年 8 月 13 日，Claude Code 的作者 Boris Cherny 公开了一套实践：让 Claude 通过 Slack 频道接管一个应用的全部日常维护。数周下来，Claude 自动开出 388 个 PR，其中 180 个经 Claude Code Review 与人工审核后合并。
这个数字的意义不在"AI 写代码多快"，而在于维护工作第一次被拆成了可自动化的例程。对国内做定制开发的团队，这可能是 AI 软件开发从"写新功能"转向"维护存量"的分水岭------Anthropic 内部数据已经显示 80% 的代码由 AI 编写，维护环节的自动化只是同一趋势的下一站。
背景与数字：388 个 PR、180 个合并意味着什么
Cherny 公开的维护范围有三类：崩溃模糊测试（crash fuzzing）、重复代码统一、死代码移除。这三类工作有一个共同特征：确定性高、影响面小、可静态判定。
| 维护类型 | 具体示例 | 为什么适合自动化 |
|---|---|---|
| 崩溃模糊测试 | 对输入边界跑 fuzz，抓到 panic 就定位修复 | 输入输出可枚举，失败可复现 |
| 重复代码统一 | 同一工具函数散落多处，合并为公共实现 | 改动范围局部，回归风险低 |
| 死代码移除 | 删除未被引用的导出与分支 | 静态可判定，不影响运行时行为 |
388 个 PR、180 个合并，合并率约 46%。剩下的一半多没有进主干：有重复提案，有被审查驳回的，也有"修了但需求已经变"的。这个分布本身就是信号------自动维护的价值不在每条都成功，而在能持续产出、持续被审、持续改进。
落地方式拆解：维护例程怎么设计、Review 门禁怎么配
关键不是"让 Claude 随便改"，而是把维护拆成可重复的例程（routine）。Cherny 的做法里，Claude 不是收到一条改一条，而是按例程批量产出：固定入口、限定范围、Review 门禁、反馈回路四件事缺一不可。
-
**固定入口：**给 Claude 一个 Slack 频道或工单队列，输入是崩溃报告、扫描结果或巡检日志，而不是零散的自然语言需求。
-
**限定范围：**每个例程只处理一类问题，PR 粒度控制在单文件或单模块，便于 Review 和回滚。
-
**Review 门禁：**Claude Code Review 先做 diff 级审查，低风险变更走快速通道，人工按比例抽审；高风险变更强制双人复核。这背后的Claude Code 智能体循环设计决定了门禁的颗粒度。
-
**反馈回路：**被拒的 PR 带着 rejection reason 回到 Agent 的上下文，下一轮不会重复同样的错。
这套结构和 CI 里加自动化 lint 是同一个思路，只是把"自动修复"也纳入了管道。Review 门禁的价值是给错误设了成本上限：一次错误修复最多浪费几分钟审查时间，而不是上线后的一次事故。
一次就改对 vs 次日改进：容错回路设计
不要指望 AI 一次改对。"一次就改对"是运气，"次日改进"才是机制。Cherny 那 46% 的合并率不是靠单次准确率堆出来的，是靠回路把错误消化掉的。
回路设计可以这样落地：T 日 Agent 自动修并开 PR，T 日 Claude Code Review 加人工抽审，T+1 日把被拒原因和回归结果回灌到例程上下文。每跑一轮，同一类错误就少一次。
我们一开始吃过亏：让 Agent 大包大揽一次改一个模块，PR 又大又杂，Review 成本反而比人工改还高。拆小之后合并率明显上升------这个教训和 Cherny 的实践结论一致：自动化维护的单位必须是"小步快跑"，不是"毕其功于一役"。
反面边界：哪些任务不适合交给 AI
适用边界比适用场景更重要。以下四类任务，现阶段不建议放进自动维护管道：
-
**产品判断：**改不改需求、优先级怎么排、功能取舍，这些是人的决策，AI 只能提供信息。
-
**跨模块大重构：**接口契约变更、数据迁移、服务拆分，牵一发动全身，需要架构评审。
-
**合规敏感改动：**支付、隐私、安全策略、审计日志，任何自动合并都该被默认禁止，必须双人复核。AI 软件开发引入自动化后，安全边界的画法可以参考我们对供应链攻击的五层安全防线设计。
-
**对外承诺：**交付时间、SLA、报价口径，Agent 没有立场替团队承诺。
一个简单的判定标准：确定性高 + 影响面小 + 可回滚，交给 AI；三个条件缺一个，留在人手里。
给国内定制开发团队的迁移建议
国内定制开发团队手里最多的不是新项目，而是跑了两三年的存量系统：文档不全、重复代码多、没人敢动的老模块。这恰恰是 AI 软件开发最好的切入点。
-
圈定一个低风险维护类目（建议从死代码移除或重复代码统一开始），配好 Slack 或工单通道。
-
搭 Review 门禁：Agent 开 PR、Claude Code Review 先审、人工抽审，全程留痕。
-
跑 2 到 4 周，只看两个指标：合并率、回归率。合并率过低说明类目选错或例程设计有问题，回归率过高说明门禁太松。
对甲方来说，存量维护改造比重写便宜得多，也比继续堆人可控得多。先想清楚自研还是外包的决策框架，再决定维护管道搭在谁手里。我们半年 AIcoding 落地的一笔真实成本账也印证了同一个结论：维护类任务的自动化 ROI 最稳。
想评估你们仓库适不适合这套做法，可以先拿一个仓库做两周试点，把崩溃修复和死代码清理交给 Agent。需要帮忙搭这套维护例程的，直接联系蓝曜炬辉获取评估报价。
常见问题
Claude 自动开出的 PR 质量能信吗？
看合并率。388 个 PR 中 180 个合并，约 46%，而且这 180 个还过了 Claude Code Review 与人工审核。质量不是"信不信"的问题，是"怎么审"的问题------门禁配好，错误有上限。
为什么只有 180 个合并，剩下 208 个去哪了？
一部分是重复提案（同一问题多种修法），一部分被审查驳回或方向不对，还有一部分属于"修了但需求已变"。这正是容错回路的价值：被拒的 PR 带着原因回流，下一轮会改进。
5 人以内的小团队能复刻这套吗？
可以，但从单一类目开始，比如只做死代码清理。一个 Slack 频道加一条 Review 流水线就够，先跑两周看合并率与回归率，再决定扩不扩范围。
自动维护会不会引入安全事故？
会，如果门禁没配好。支付、隐私、安全相关的改动应默认排除在自动合并之外；生产环境的 PR 必须有双人复核和回滚预案。
从哪类维护任务开始最稳？
死代码移除和重复代码统一，这两类静态可判定、影响面小，合并率通常最高。崩溃模糊测试需要先有稳定的复现环境，难度高一级，建议放在第二批。
参考
-
Boris Cherny 个人博客------Claude Code 作者，公开实践记录
-
Bing 检索线索------2026 年 5 月相关访谈的线索来源