388 个 PR，几周时间，一个工程师没动手。Boris Cherny 把应用日常维护交给 Claude，从崩溃模糊测试到死代码移除，全部跑在 Slack 频道里。AI 代码维护这件事，开始从演示走向批量生产。更值得注意的不是数量，而是他如何把机械性代码改动从逐条审查转向批量合并。
几周 388 个 PR，这不是实验，是流水线
三条固定例程盯住最脏的活
Boris 没有让 Claude 自由发挥。他把维护工作拆成三类：崩溃模糊测试、重复代码统一、死代码移除。每类都是一条定时例程，不是一次性命令。崩溃模糊测试负责往边缘输入里撞，重复代码统一把散落各处的相似实现收拢，死代码移除清掉没人再调用的函数。三件事都足够机械，边界清晰，不需要产品判断。这正是能批量跑起来的前提。
Slack 频道成了调度层，而不是聊天工具
很多人把 Slack 当成通知出口，Boris 把它当成调度中枢。例程触发、PR 生成、审查状态都在频道里流动。好处是可视化，所有变更像消息一样滚动，随时可以插话叫停。Claude 在同一个频道里读上下文、执行任务、响应反馈，不需要额外搭一套控制台。这个选择看起来轻，但实际降低了操作摩擦，让“每天跑一遍”变成现实。
例程化之后，维护任务变成可重复的命令
一次性自动化容易，持续自动化难。Boris 的关键动作是把维护任务拆成可复用的定时例程。每天固定时间跑，跑完出 PR，次日根据反馈调整提示词再跑。这个循环让机械性代码改动拥有了生产节拍。不是“让 AI 试试看”，而是“把它排进班表”。批量合并的前提，正是这种可重复性。
为什么它通常一次就能改对
任务切得足够小，正确率才有保障
Claude 通常一次就能改对，这不是模型突然开挂。回头看任务设计：崩溃模糊测试、重复代码统一、死代码移除，每一项都足够小、足够明确。输入是代码和规则，输出是 diff，没有模糊的产品取舍。AI 擅长在边界清晰的盒子里工作，Boris 恰好给了它一个盒子。任务越机械，一次成功率越高。若让 AI 理解整个系统再动手，388 个 PR 可能变成 388 个事故。
Claude Code Review 先审，人再复核
生成的 PR 不是直接合并。180 个合并的 PR 都经过两层把关：Claude 自己先做代码审查，人工再复核。有人会问，AI 审 AI 有意义吗？有。Claude Code Review 先过滤掉低级错误和格式偏差，把人工注意力留给逻辑和影响面。人工审核从逐行挑错变成最终确认。这个分工把人的审查成本打了下来，同时保留了必要的安全阀。
出错时不改代码，改例程
Claude 出错怎么办？Boris 的做法是：不急着改那个 PR，而是调整例程。比如提示词没写清楚边界，当天反馈，次日改进，重新跑。这个细节容易被忽略，但它是整套玩法的核心。错误被当作流程输入，而不是偶发事故。一次失败带来一次例程升级，几周下来，Claude 的正确率被不断拉高。这也是为什么数量能滚起来。
从逐条审查到批量合并，门槛塌了
审查成本从逐条降到批量
传统维护里，每一条机械改动都要人写、人审、人合并。时间不多，但琐碎，堆积起来吃掉大量精力。Boris 把流程翻转过来：AI 批量生成，审查只看差异和风险。180 个合并的 PR 没有逐条消耗一个工程师的一整天，而是通过批量审查完成。审查对象从“每一行代码”变成“每一个例程”。这是成本结构的变化，不是效率的小幅提升。
把 AI 当实习生带，当日反馈次日改进
这套系统里最像管理的地方是反馈节奏。Claude 不是扔进去就完事，而是每天看 PR，给出具体反馈，调整提示词或规则。就像带实习生：第一天做错，说明要求，第二天改好。区别在于实习生会累，Claude 不会。当日反馈次日改进，让错误不积累，模型在具体任务上越跑越稳。这种持续校正，比选一个更强模型更实际。
机械性代码改动的价值重估
死代码移除、重复代码统一这些事，向来被视为低价值苦力。但它们堆积多了，会拖慢构建、增加理解成本、埋下隐患。AI 把这些活接过去，工程师的价值反而被释放出来。但更关键的是，机械性改动第一次有了规模化可能。过去一个下午改三处，现在例程一跑出几十个 PR。价值不在单条改动，在于系统性的整洁。
别急着照搬，先看清边界
适合自动化的维护任务长什么样
不是所有维护都适合丢给 Claude。适合的任务有三个特征：边界清晰、判定客观、影响面可控。崩溃模糊测试可以自动跑，因为崩溃与否一目了然。死代码移除需要静态分析，但规则相对明确。涉及架构调整、性能权衡、安全策略的改动，仍然需要人。Boris 的三条例程之所以跑得顺，是因为它们都落在 AI 擅长区间。超出这个区间，批量生成可能变成批量制造麻烦。
想上手，先做三件事
第一，选一个足够小的维护任务，别一上来就重构整个模块。第二，把任务写成定时例程，固定触发、固定输出 PR。第三，建立反馈闭环，每天看 PR，调整提示词，再跑。不需要一开始搭复杂平台，Slack 加 Claude 就能起步。关键是先让循环转起来，再逐步扩展任务范围。很多人失败在第一步选太大，第二周就放弃。
流程问题别让 AI 背锅
如果代码库本身没有测试、没有清晰模块边界、没有一致的编码规范，AI 自动化只会放大混乱。Boris 的例程能跑，是因为他的工程基础足够扎实。AI 可以承担机械性维护，但不能替代工程治理。先理清流程，再谈自动化。否则 388 个 PR 不会让系统变好，只会让审查更崩溃。这是所有 AI 代码维护尝试的底线。
