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