388 个 PR 的实践

核心亮点

Boris Cherny 在 X 平台分享了他把 Claude 接入自己应用日常维护的全新实验。说白了，他不再把那些重复、枯燥的工程杂活留给自己，而是让 Claude 通过一个专门的 Slack 频道统一接管。在短短几周时间里，这个自动化流程自动开出了 388 个 Pull Request，其中 180 个经过 Claude 自身的 Code Review 加上人工审核后，成功合并进代码主干。

具体能力或事件经过

整套工作流围绕一个 Slack 频道运转。Boris 让 Claude 在后台持续执行三类典型维护任务：崩溃模糊测试（crash fuzzing）、重复代码统一，以及死代码移除。说白了，这些都是代码库里最容易积累、也最容易被人类工程师忽略的脏活。Claude 会把每一次改动打包成独立的 PR，先由 Claude 自己做一轮 Code Review，再交给 Boris 做最终的人工确认。当 Claude 偶尔改错时，Boris 不需要推倒重来，只需要调整运行例程，第二天 Claude 就会在上一轮的基础上自我改进。

技术细节

这种做法的关键并不在于模型本身有多聪明，而在于把任务切得足够小、足够可验证。崩溃模糊测试能够自动发现边界条件与异常输入下的崩溃，重复代码统一显著降低了长期维护成本，而死代码移除则让代码库保持清爽。Boris 观察到，Claude 通常一次就能把改动改对，说明它在处理这类结构化、目标明确的工程任务时已经相当可靠。

与竞品对比

相比传统 CI 流程里靠人工编写脚本定期巡检，让编程智能体以 PR 的形式主动提交改动，等于把"发现问题"和"顺手修掉"合二为一。和单纯依赖 Lint 这类静态工具不同，Claude 能够理解语义层面的重复与冗余，做出的修改更贴近真实工程意图。

行业影响或适用场景

对于人手紧张的中小团队来说，这种"智能体当初级维护工"的模式相当有吸引力：它接管了最耗时的琐碎活，让人力集中在架构设计与产品创意上。但它也提醒我们，自动合并的环节仍然需要人工把关，尤其是 Code Review 这一关，并不能因为有了 AI 就省略。