文章摘要
Claude开发者Boris分享实验数据，团队几周内产出388个AI生成的代码合并请求，180个成功合并。Claude接管自研应用日常维护，自动完成问题排查、代码修改等流程。但随着AI提升代码产出效率，审查环节成新瓶颈。该AI运维系统架构分三层，调优核心是优化规则。使用Claude Routines功能有门槛，个体开发者可先将验收条件明确的工作交给AI。

近期，Claude的开发者Boris Cherny分享了一项极具参考性的实验数据：团队在几周内产出了388个由AI生成的代码合并请求（PR），其中180个被成功合并，而所有这些代码全部由AI独立完成。

这项实验的核心，是让Claude接管一款自研应用的日常维护工作，相关协作流程都在名为「proj-claude-maintains-apps」的Slack频道中完成。Claude Tag作为交互入口，每日定时启动一组覆盖iOS、Android、桌面端、Web、CLI和Agent SDK六大环境的例行任务，每个运行环境对应独立的执行流程，任务进展会同步到频道的顶层线程中。

它就像一名全职的运维工程师，无需人工指派任务，到点自动启动，完成问题排查、代码修改、PR提交等全流程，最后等待人工审核确认。这套闭环流程已经在公司内部运行了数周，工程师需要做的仅仅是点击一个按钮，决定是否将AI提交的PR合并到主分支。

AI包揽的全是研发杂活

Boris为Claude安排的工作，全都是研发团队日常避之不及的「脏活累活」，没有一项是从零开发新功能：

  • 崩溃巡检：在真机模拟器中反复操作应用直至触发崩溃，定位问题后提交修复PR，每个PR都需要附带复现步骤和真值表，且必须使用真实应用测试，严禁使用模拟替身。
  • 重复代码合并：扫描代码库中结构相似但不完全一致的实现逻辑，提交PR将其整合为统一实现。
  • 死代码清理：静态分析确定无法执行的代码直接删除；仅疑似未被调用的代码，先添加日志观察一天，确认无任何调用后再执行删除。
  • 抽象泄漏修复：修正代码中暴露了不该公开的内部层次的问题。
  • 清理冗余测试：删除所有始终通过的测试用例，排查时好时坏的测试的根源问题。
  • 移除上线开关：将代码中硬编码的全量上线开关移除。
  • 功能迭代评估：针对长期无人维护的内部功能，根据使用量决定是正式对外发布还是直接删除。

这些工作既不会带来亮眼的绩效产出，也常常被拖延到下个季度，却又是保障代码库健康运行的必要环节。

代码生成变快，审查压力陡增

随着AI大幅提升代码产出效率，团队的研发产能得到显著提升，但代码审查环节却逐渐成为新的瓶颈。Anthropic在今年3月的技术公告中提到，过去一年公司人均代码产出增长了200%，但审查压力陡增。这并非个例，行业数据平台在2026年发布的一份覆盖2.2万名开发者、4000余个团队的两年遥测报告显示：高AI采用率下，人均史诗级任务完成量增长66.2%，任务吞吐提升33.7%，PR合并率上涨16.2%，但每周实际部署上线的次数反而下降了11.7%。

合并的PR变多，但真正上线的变少，问题全部卡在了审查环节。开发者承担了所有额外的代价：每个开发者遇到的bug数量增长54%，每个PR对应的线上事故上涨242.7%，被合并后又删除的代码比例增长861%，PR平均体积扩大51.3%。最致命的是等待时间：等待审查的中位时长增长了441.5%，更有31%的PR未经任何审查就直接被合并。

现有的代码审查机制也存在诸多问题：上线前仅有16%的PR能获得实质性的审查意见，上线后这一比例才提升至54%；超过1000行的大PR中，84%能被查出问题，平均每个PR发现7.5个问题，而50行以下的小改动，这一比例仅为31%，平均发现0.5个问题；工程师标记为「误报」的审查发现不到1%。此外，审查每个PR平均需要20分钟，消耗15到25美元的token成本。

Anthropic的Code Review系统明确了边界：AI可以自主完成问题排查、代码修改、PR提交的全流程，无需人工审批，但所有变更都必须停留在PR阶段，最终是否合并到主分支、是否上线，必须由人工点击确认。Boris在分享中提到，下一步的目标是降低这类机械性改动的合并成本，因为当前的卡点已经不再是代码生成环节，而是审查环节。

系统架构：从入口到审批的完整闭环

这套AI运维系统的架构分为三个清晰的层级：

  • Claude Tag作为交互入口，挂载在Slack频道中，既可以被@唤醒，也能根据权限和指令主动承接任务，8月13日该工具刚刚完成升级，能够结合频道上下文判断何时需要启动任务、何时无需操作。
  • Routines作为执行层，是4月14日推出的功能，用户可以一次性配置提示词、代码仓库和连接器，支持定时执行、API调用触发或响应GitHub事件自动启动，所有运行都依托Claude Code的云端基础设施，无需依赖本地设备。
  • Claude Code Review作为审查层，最终的批准环节则由人类完成。

四层架构协同，才实现了每日自动启动的AI运维流程。

调优核心：不修结果，只修规则

这套系统最值得学习的，是Boris的调优思路：当某一类PR反复无法通过审核时，他不会逐个修改失败的PR，而是回头调整生成这些PR的Routine规则，随后观察后续几天的运行效果。有时候一类任务需要连续调整数天才能稳定运行。

简而言之，不是修改结果，而是优化规则。提示词不再是一次性的输入，而是需要长期运维的资产：编写完成、上线运行、持续观察、迭代优化，和线上服务的运维逻辑一致。这也是这套系统能够越跑越顺畅的原因，每一次调整都会沉淀到规则中，次日生成的PR中，不必要的问题会越来越少。

想要复刻？先过这几道门槛

Claude的Routines功能已经对Pro、Max、Team和Enterprise版本开放，Pro用户每天可使用5次，Max用户15次，Team和Enterprise用户25次，既可以在claude.ai/code页面一键创建，也可以通过CLI输入/schedule指令配置。但真正的门槛并不在工具层面：

  • 仓库权限的开放程度
  • 测试覆盖的完整性
  • 是否拥有能够运行真机的模拟器环境
  • 审查环节的成本承受能力
  • 最难的一点：团队是否愿意为AI提交的PR按下合并按钮。

就在同一个月，Rust项目针对AI代码贡献制定了明确规则：AI生成的代码需要提前声明、不得触碰关键路径、必须经过充分测试、如实披露使用的大模型；涉及代码安全性的关键改动，强烈不建议交由大模型生成。更重要的是，项目维护者没有义务审查AI提交的PR，可以直接关闭。

个体开发者可以从这项实验中借鉴的核心经验是：先将验收条件明确的工作交给AI。那些可以明确验证对错的任务，AI已经能够胜任：比如某个操作是否会触发应用崩溃、两段代码是否实现了相同的逻辑、某条测试用例是否永远不会失败，这些都可以当场完成验证。而那些难以明确对错的工作，比如抽象层是否过度设计、重构方向是否正确，验收标准依赖主观判断，无法写入提示词中，AI暂时无法胜任。因此，AI接手的第一批工作并非开发新功能，而是代码维护的打扫工作。

当前代码生成的产能已经不再稀缺，稀缺的是审查环节的处理能力：谁来优先审查、如何归类重复的PR、最终谁来签字确认。工程师的价值评价体系也正在发生变化：过去看编写代码的速度，未来则看审查代码的效率。

以上内容不代表本平台立场，仅供读者参考