2026 年 8 月 14 日Claude Code 负责人 Boris Cherny 分享了一个已经运行数周的实验。他没有继续测试 Claude 能不能一口气写出一个新应用而是把 Claude 放进了软件开发里最琐碎、最容易被拖延的一层日常维护。Claude 会从 Slack 频道接收任务运行崩溃模糊测试统一重复代码移除死代码再把修改整理成 Pull Request。几周下来它创建了 388 个 PR其中 180 个在经过 Claude Code Review 和人工审核后合并。这组数字来自 Boris 的个人实践不是 Anthropic 对所有团队的效果承诺。388 个 PR 也不能直接理解成 388 次成功修复。已合并的 180 个约占 46%剩余 PR 可能仍在审核、被判定没有必要、与其他修改重复或者没有达到合并标准。原帖没有公布更细的分类。即便把这些限制写清楚这个案例依然很有参考价值。AI 编程过去主要发生在一个人盯着聊天框的时间里。人提出需求Agent 修改代码人继续追问。Boris 的实验把工作方式向前推了一步团队先定义长期任务、验收条件和权限范围Claude 按节奏反复运行工程师只处理到达审核口的结果。388 个 PR 背后变的是 Claude 在团队里的位置开发者让 Claude 写一个函数通常只会产生一次结果。日常维护没有明确终点。代码库每天都在变化。新的重复逻辑会出现旧功能下线后会留下死代码依赖升级可能引入兼容问题测试也会随着业务变化逐渐失效。靠人集中清理这些任务经常被挤到“以后有空再做”。Boris 采用的方式更接近一条持续运行的维护流水线text 复制代码Slack / GitHub / 定时任务发现维护需求 ↓ Claude 在限定仓库和环境中分析问题 ↓ 修改代码并运行测试、类型检查或复现脚本 ↓ 创建 PR附上证据、影响范围和回滚说明 ↓ Claude Code Review 做第一轮审查 ↓ 工程师决定合并、退回还是关闭人仍然负责规划和批准Agent 承担执行。Anthropic 在另一项针对约 40 万次 Claude Code 会话的研究中也观察到类似分工。典型会话里人类作出约 70% 的规划决策Claude 作出约 80% 的执行决策。这个比例不该被当成每个项目的固定公式却能解释为什么维护工作适合交给 Agent人先写清楚“该检查什么”和“什么结果能合并”Claude 再完成大量搜索、修改和验证动作。哪些维护任务适合交给 Claude能自动创建 PR不等于所有工程任务都应该自动化。第一批任务应当具备四个特征范围清楚、结果可验证、修改可回滚、失败影响有限。1. 重复代码治理Agent 可以定期扫描相似实现判断能否复用同一工具函数并在 PR 里列出被替换的位置。这类任务的验收标准比较明确测试通过、公开接口不变、重复代码量下降。难点在于“看起来相似”的业务逻辑未必应该合并所以第一阶段应限制到同一模块避免跨业务域抽象。2. 死代码和过期配置清理已经下线的 feature flag、无人引用的函数、旧版配置项和废弃脚本很适合进入周期性检查。Agent 需要同时检查静态引用、动态加载和部署配置。只跑一次文本搜索不够。PR 中还应说明它检查了哪些入口方便审核者判断是否漏掉反射、插件或运行时调用。3. 测试补齐与失败归因对于已有 bug、稳定复现步骤和明确预期结果的任务Agent 可以先补回归测试再修改实现。如果失败具有随机性可以让 Agent 汇总多次运行结果、环境信息和失败堆栈先创建调查报告不急着修改生产代码。Boris 提到的崩溃模糊测试就属于这一方向。4. 文档与代码同步接口参数、环境变量和 CLI 命令发生变化后文档很容易落后。Agent 可以在代码变更触发后检查 README、API 示例和迁移说明。Anthropic 的 2026 AI Agent 报告披露Doctolib 将 Claude Code 以 headless mode 嵌入 CI让代码变更自动触发技术文档更新。该公司还建立了集中管理的 prompts、commands 和 subagents 仓库减少每位工程师从头配置的成本。5. 低风险依赖更新补丁版本升级、锁文件更新和明确的安全修复可以进入候选范围。Agent 应运行完整测试并单独列出 changelog 中可能影响当前项目的变化。大型框架跨版本迁移、数据库驱动升级和身份认证依赖不适合作为第一批无人值守任务。它们需要迁移设计和分阶段验证。6. CI、Lint 和类型错误修复格式、类型和可稳定复现的 CI 错误有天然的机器验收标准。Agent 可以读取失败日志定位修改并重新运行检查。Claude Code 目前也提供 PR auto-fix 能力可以监控 CI 失败和审查意见在判断修复路径明确时继续提交修改。但自动修复不应绕过现有的分支保护和必需检查。三档权限比“全自动或全手动”更实用团队刚开始尝试时经常在两个极端之间摇摆。一种做法是每一步都弹出确认工程师很快会机械点击同意。另一种做法是直接开放写权限和自动合并一次错误就可能触及大量文件。更稳妥的做法是按照影响面划成三档。权限档位Agent 可以做什么典型任务人工位置绿色读取、分析、运行只读检查、创建报告重复代码报告、测试缺口、依赖清单人决定是否进入修改黄色创建分支、修改代码、运行测试、提交 PR死代码清理、文档同步、Lint 修复必须人工审核后合并红色不允许 Agent 直接执行只能给方案数据迁移、权限系统、账单逻辑、生产配置人工设计、实施和双人复核第一周只开绿色任务。输出稳定后再把其中一两个规则清楚的项目升到黄色。红色任务可以让 Claude 做影响分析但不要给它生产写权限。一条能复用的维护 Routine至少要写清六件事Claude Code Routines 可以按时间、API 请求或 GitHub 事件触发在 Anthropic 托管的云端环境中运行。它会自动执行因此任务描述不能依赖运行中再问人补信息。下面这份模板适合改成团队自己的维护例程markdown 复制代码# 任务检查 src/payments 目录中未被引用的代码只处理最近30天没有调用记录、 且不存在动态注册标记的内部函数。# 允许范围- 只读取和修改 src/payments 与 tests/payments - 可以运行单元测试、类型检查和静态引用分析 - 只能创建 claude/ 前缀分支和 Pull Request# 禁止操作- 不修改数据库 schema、权限策略和支付状态机 - 不访问生产环境、真实密钥或客户数据 - 不自动合并不直接推送 main# 验收标准- 全量单元测试通过 - 类型检查和 lint 通过 - 对每个删除项列出静态引用、动态加载和配置注册的检查结果 - 修改后公开接口保持不变# 失败处理- 证据不足时停止修改改为输出调查报告 - 测试不稳定时保留日志并标注复现次数 - 一次最多修改5个文件超出后拆分 PR# PR 必须包含- 为什么要改 - 改了哪些文件 - 运行了哪些验证 - 仍然存在什么不确定性 - 如何回滚模板里最容易被忽略的是“失败处理”。无人值守 Agent 遇到模糊条件时不能靠猜测继续推进。允许它停止并提交调查报告往往比逼它必须产出代码更省审核时间。PR 数只能看工作量质量要看另外四项388 很醒目也很容易把团队带到错误目标上。如果考核 Agent 每周创建多少 PR它会倾向于把修改拆得更碎甚至不断提交低价值清理。团队还需要记录以下四项指标计算方式它回答的问题有效采纳率最终合并的有效 PR / 已审结 PRAgent 找到的问题是否值得改首轮通过率无需返工即可通过的 PR / 已合并 PR任务说明和验证是否充分人工审核时长从开始审核到给出决定的中位时间Agent 有没有减少人的工作回滚与事故率合并后被回滚或引发事故的 PR / 已合并 PR自动化有没有把风险转嫁给生产环境还可以单独统计重复 PR、无变化 PR、测试不充分和越界修改。它们能直接指向 Routine 的哪一条规则需要调整。Boris 提到Claude 一次就能完成不少修改如果例程表现不好他会调整任务规则让第二天的运行吸收这次经验。需要持续修改的是任务范围、验证条件和结果出口组成的整套流程。7 天试运行方案不需要一开始就复制 388 个 PR 的规模。一个仓库、一类任务和一个星期已经足够发现大部分流程问题。第 1 天选择任务。从文档同步、Lint 修复或测试缺口中选一类不碰生产权限和数据结构。第 2 天建立基线。人工完成一次同类任务记录耗时、检查项和常见遗漏。这份记录会变成 Agent 的验收标准。第 3 天只生成报告。暂不允许改代码检查 Agent 找到的问题是否准确有没有重复和误报。第 4 天开放创建分支和 PR。限定目录、文件数和命令白名单禁止合并。第 5 天增加机器门禁。把单测、类型检查、lint、安全扫描和必要的回归脚本设为必需检查。第 6 天统计人工成本。记录审核者读 PR、验证结论和要求返工花了多久。Agent 创建 PR 很快但审核更慢就没有节省团队时间。第 7 天只调整一到两条规则。先修复最常见的误报或越界问题再决定是否增加任务频率和仓库范围。Claude Code Routines 和自建 API Agent不要混成一套方案落地时需要先决定执行环境。Claude Code Routines 是 Anthropic 的托管能力。它可以绑定仓库、连接器和触发条件在电脑关机后继续运行。官方文档也提醒Routine 会自主运行包含的连接器可以执行写操作分支推送权限和网络访问应按任务最小化配置。如果团队希望自己控制调度器、容器、模型路由、预算和日志可以通过 Agent SDK 或模型 API 搭建维护服务。常见结构如下text 复制代码GitHub / CI / 定时器 ↓ 自建任务编排与权限策略 ↓ 模型 API 接入层 ↓ 隔离执行环境 ↓ 测试、代码审查与人工合并在第二条路线中Apito.ai 可以放在模型 API 接入层用于集中管理 API Key、Base URL、模型调用和用量记录。实际可用模型和接口能力应以平台控制台当前展示为准。已经配置过旧请求地址的程序只需要把请求地址更新为apito.ai其他参数保持原有配置。上线前仍要在测试环境重新验证鉴权、流式输出、工具调用、超时和错误重试不能因为只改了域名就跳过回归测试。这里需要明确一个边界Apito.ai 不能替代 GitHub 分支保护、执行沙箱、代码测试和人工审核。模型接入解决的是调用入口能不能安全合并代码取决于后面的工程门禁。388 个 PR 给团队留下的可复制结论Boris 的实验没有证明 AI 可以独立接管软件项目。180 个合并结果反而提醒团队Agent 输出仍然需要筛选。这个案例展示了一条更现实的路线。开发者把重复发生、验收清楚的维护任务整理成 RoutineAgent 负责扫描、修改、验证和提交代码审查与工程师守住合并出口运行数据再反过来修改规则。新功能依旧需要产品判断和架构设计。那些长期堆在 backlog、每次都不难、却总没人愿意处理的维护工作已经可以先交给 Agent 跑一轮了。FAQ1. 388 个 PR 是否代表 Claude 成功修复了 388 个问题不能这样理解。388 是创建的 PR 数量180 个经过 Claude Code Review 和人工审核后合并。原帖没有说明其余 PR 分别处于待审、关闭、重复还是验证失败状态因此不能把 388 当成成功数也不能把 180/388 简单当成模型准确率。2. 哪类项目适合先试 Claude 自动维护测试较完整、分支保护明确、能在隔离环境运行、日常维护任务重复度高的项目更容易起步。缺少测试、依赖生产数据或存在大量动态行为的旧系统应先补验证能力再开放自动修改。3. 可以让 Agent 自动合并 PR 吗技术上可以配置相关能力但首轮试运行不建议开启。先观察有效采纳率、回滚率和人工审核时长。即使后续开放也只应覆盖低风险目录并保留必需 CI、分支保护和回滚机制。4. Claude Code Review 会替代人工代码审查吗官方 Code Review 会用多个 Agent 检查逻辑错误、安全漏洞、边界情况和回归风险并对候选问题进行验证和去重。官方文档明确写明它的发现不会自动批准或阻止 PR。业务逻辑、产品影响和上线决定仍然需要项目成员负责。参考资料Boris ChernyClaude 承担应用日常维护并创建 388 个 PRAnthropicClaude Code Routines 使用文档AnthropicClaude Code Code Review 使用文档Anthropic约 40 万次 Claude Code 会话中的人机分工研究Anthropic2026 State of AI Agents Report