责编 | 梦依丹 出品 | CSDN（ID：CSDNnews） Claude Code 团队成员 Addy Osmani 最近在一篇关于 Code Review 的文章中分享 Anthropic 内部正在发生的一个变化：Claude Code 团队约 90% 的代码已经由 AI 生成。 从今年 6 月到 9 月，Claude Code 代码库合并的 PR 数量翻了一倍以上，但回滚比例反而下降了 40% 以上。在更大的 Anthropic monorepo 中，每天落地的代码变更，也从 5 月约 2500 次增长到 9 月超过 3 万次。 真正值得关注的是软件工程的瓶颈正在随之迁移： 从写代码，转向测试、验证、评测、风险判断和质量控制。 测试、CI/CD、安全检查、分级审批、Feature Flag、灰度发布、回滚这些机制并没有消失，只是流水线上谁来完成每一步正在被重新分配。 90% 代码由 AI 写，Claude Code 怎么做 Review？ Claude Code 团队并没有试图用更多人工 Reviewer 去追赶 Agent 的代码产量，而是把 Review 拆成了多层验证。 在 PR 创建之前，Claude 会先运行测试、构建、Lint 等检查并提供结果。随后还会让一个拥有新鲜上下文的子 Agent 重新检查代码 Diff。进入 PR 流程后，代码还会经过 CI、AI Code Review 和独立的安全审查。其中 AI Reviewer 并不是简单让一个模型看一遍代码，而是让多个 Agent 并行寻找潜在 Bug，再对发现的问题进行交叉验证，尽量过滤低价值或错误告警。 人工审批也没有完全消失，而是开始按照风险分配。文档修改或被 Feature Flag 隔离的低风险变化，可以减少人工干预。普通产品代码、缓存、System Prompt 等敏感区域需要更严格审批，最高风险变更则需要更多人工确认。代码合并之后，还有 Merge Queue、渐进式发布、Feature Flag 和快速回滚等机制继续兜底。 因此，Claude Code 团队真正优化的指标并不是“有没有一个人读过每一行代码”，而是这个改动可能在哪里出错？哪一道检查最适合发现它？ 这其实是一个很大的思维转变。 流程没消失，变化的是“谁来做” 仔细看 Anthropic 的这套方法，会有一种很熟悉的感觉。 测试、CI/CD、安全审查、分级审批、灰度发布、Feature Flag、Rollback……这些并不是 AI 出现以后才诞生的软件工程方法。过去大型互联网公司的研发体系里，很多机制早已存在。 真正改变的是流水线上的每一步，开始重新分配给人和 Agent。 过去 CI/CD 更多按照事先写好的规则机械执行。现在，Agent 开始具备理解任务、检查代码、调用工具、分析测试结果甚至修改代码的能力。一个 Agent 写代码，另一个 Agent Review，测试系统给出确定性反馈，Security Agent 检查风险，最后只有真正需要判断力的部分才升级给人。 这也意味着，人的角色并没有因为 Agent 进入研发流程而消失，而是开始向更高一层移动。工程师需要更多地回答这件事该不该做？架构边界应该怎么划？哪些风险不可接受？哪些改动必须人工审批？出了问题谁负责？ 代码可以交给 Agent 检查，但意图、判断和责任仍然属于人。 AI 写得越多，Harness 反而越重要 这也是为什么最近一年，AI Coding 领域越来越频繁地出现一个关键词：Harness Engineering。 Claude Code 团队公开的 Code Review 方法，本质上就是一个很典型的 Harness 问题：它并没有把可靠性寄托在模型“更聪明”上，而是用测试、Review Agent、安全检查、风险分级、发布和回滚等机制，把 Agent 放进一套能够约束、验证并纠错的工程系统里。 但 Harness 仍然不是终点。 当系统能够验证一次任务是否完成之后，新的问题又会出现。这些测试结果、Review 结果、用户反馈和失败轨迹，能不能重新进入下一轮任务，让 Agent 自动调整、重新执行，并持续提高完成质量？ 这就开始从 Harness 走向 Loop。 任务进入系统，Agent 执行，测试和评测给出反馈，系统重新规划，再执行、再验证，直到满足既定目标。软件研发开始从人不断 Prompt AI 走向人设计一套能够持续驱动 AI 工作的系统。 因此，AI Coding 的工程重点也正在发生迁移： Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering 而这条技术路线背后真正变化的，是整