一句话看懂：Claude 被安排了一个新的角色——替开发团队日常维护应用代码库。在几周实测中，它自动开出了 388 个 PR，其中 180 个被合并，这可能是 AI 从“辅助写代码”走向“主动维护项目”的一个早期信号。
事件核心：发生了什么
X 用户 Boris Cherny 分享了一项为期数周的实验。他在 Slack 里建了一个名为 proj-claude-maintains-apps 的频道，让 Claude Tag 在这个频道中每天对 iOS、Android、Desktop、Web、CLI 和 Agent SDK 等代码库执行固定维护任务。这些任务包括：崩溃模糊测试（在模拟器里打开应用乱点找崩溃点，再定位根因并修复）、重复抽象统一（扫描结构相似但略有差异的代码并合并）、死代码清理（先给疑似死代码加日志做验证，确认后次日删除），以及修复“泄漏抽象”等。
结果显示，这套流程在几周内为多个仓库提交了 388 个 PR，其中 180 个经过 Claude Code Review 加人工审核后被合并。Boris 提到，Claude 的 PR 第一次通常就能做对；如果不对，他们会要求 Claude 调整自己的日常程序，第二天再试，有时需要调几天。相关提示词已公开在 claude.ai/code/routines，供想尝试的人直接使用。
为什么重要
这则新闻的意义不在“AI 写代码”，而在“AI 接管代码维护的日常”。过去 AI 编程助手的工作模式是人提需求、AI 给改动建议；现在 Claude 被赋予的是一个持续运行的“维护岗位”：它自己发现问题、自己修复、自己提 PR，再走一遍人机协作的审查流程。
从行业角度看，这种“自动化维护代理”如果能稳定运行，意味着企业里相当一部分低风险、高重复度的代码卫生工作（清死代码、统一抽象、修崩溃）可以被 AI 消化掉，从而释放开发者的时间。Boris 也说，他们正在思考如何简化流程，让这类机械性改动更容易被合并。这背后折射出的方向是：AI 不只是建议者，而正在成为开发流程中一个正式的“执行节点”。
需要说明的是，这仍是一个个人实验，样本量有限，合并率虽高但并非全自动运转——180 个合并数中也包含了不少后续调优成本，不能据此断言 AI 已能全面接管代码维护。
对用户/开发者/创作者的影响
对开发者而言，这个工作流最直接的启发是：把“重复度高、判断成本低”的维护任务整理成可复用的 routine（日常程序），交给 Claude 这类模型去做，人工只在提交 PR 后做审查，而非逐行参与编写。对于小团队或开源维护者，这种模式可能缓解长期困扰的“技术债没人还”的问题，因为 AI 不需要休息，且可以记住前一天的修正反馈。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对于以 API 方式接入 Claude 的开发者，这套实践也提供了“如何把模型当程序跑”的参考：设定明确目标（例如“扫死代码”）、给执行策略（如加日志验证）、接收失败反馈并调参。这套流程本质上和写合格的自动化测试脚本没有太大区别，只是执行体从脚本换成了大模型。
值得关注的后续
这个方向有几个值得继续观察的点。一是 Claude 的 routines 能力是否会从 claude.ai/code 入口升级为正式产品功能，并被纳入企业版服务；如果成行，它可能是继 Code Review 之后，AI 在开发流程中嵌入更深的一步。二是其他 AI 编程工具是否会跟进类似“持续维护代理”模式，毕竟目前还没有第二家公开做如此高频的自动 PR 实践。三是这个工作流的真实边界：180/388 的合并率中，有多少改动真正有价值？合并率的提升是靠模型变强，还是靠放宽合并标准？这些数据目前公开信息不够，后续值得进一步追踪。
