CI on AI博士万戈

Claude Code 团队的代码审查方法：六层检查、按风险分级审批、一个审批只覆盖一个 commit

admin@yesmiracle.net (万戈) — Sat, 24 Oct 2026 00:00:00 +0000

Anthropic 的 Claude Code 团队在 10 月 15 日发了一篇工程博客，把自己团队怎么做代码审查讲了一遍。里面有一组数字值得先放在最前面：

从 6 月到 9 月，合并进 Claude Code 代码库的 PR 翻了一倍多，而其中被迫回滚的比例降了 40% 以上。同一时期，Anthropic 那个 monorepo 的日均落地变更数从 5 月的约 2,500 涨到 9 月的 30,000 以上。

在变更量涨一个数量级的前提下把返工率压下去，这本身就是个反常结果。而它靠的是把「审查」这件事的骨架换掉，跟模型是不是更聪明关系不大。

他们把人工时间拆成了两个账本

这套流程里最容易被漏掉的一句判断，藏在它对「省时间」的定义里。

团队把人工时间看成两笔账：一笔是花在审查上的时间，另一笔是花在修复坏代码上的时间。原文的说法是，如果只砍第一笔，而第二笔跟着涨，那就没有省下人工时间，只是把它挪了个位置。

于是 revert 率和事故率在这套流程里被当成护栏来用，不再是事后的附带统计。他们真正在优化的目标写得很清楚：Claude Code 那几个仓库（CLI、桌面、Web、移动端）的多数 PR，最多只要一个「人在环里」，这个人甚至可以是作者本人，前提是回滚率和事故率不上升。

度量方式也具体：每个 PR 的人工批准数（看中位数和第 95 百分位）、人工评论数、以及 PR 等一个人等了多久。三个指标一起看，才能区分「审查变快了」和「审查被跳过了」。

这个双账本框架是我觉得这篇文里最值得抄走的部分。很多团队引 AI 审查时只看「平均审查时长下降」，而返工时间悄悄转移到另一个地方去了，账面上看不出来。

六层，每层的洞都在不同地方

他们给出的结构是一张六层图，从上到下依次是：验证、必需 CI、AI 审查、安全审查、人工批准、合并队列加特性开关。原文的比喻是每层都有洞，而洞的位置各不相同，漏过某一层的问题会被后面某一层接住，穿过所有层的才落到最底下的快速回滚。

层	谁在跑	拦什么	关键设计
1 验证	作者（人或 Agent）	「做完了」其实是假的	给 Agent 一个能跑的东西（测试、构建、截图比对），要求它展示输出而不是声称完成
2 AI 审查	每个 PR 必过	常规错误	读 diff 对比整个仓库和 PR 声明的意图；发现项先由多个 Agent 投票复核，只投真实的
3 安全审查	自动	安全问题	与第 2 层一样可以阻塞合并：有未关闭的发现项就合不了
4 必需 CI	自动	平台兼容、类型、lint	一个 CLI PR 在有人看之前可能已经跑了几十个检查
5 人工批准	人	高风险判断	按变更风险分级，见下一节
6 合并队列 + 开关	自动	两两合并才炸的情况	合并队列把每个 PR 应用到 main 上重跑全部检查；新行为先给内部员工用

第一层里有个细节值得单独说。他们要求 Agent 展示可验证的输出，而不是汇报「已完成」。Boris Cherny（Claude Code 的作者）说这大概是拿到好结果最重要的一件事，他估的价值是最终效果变好两到三倍。这个习惯的落点是让「完成」这个词有证据。

第二层的机制也值得拆开：发现项在交给人之前，先由另一组 Agent 投票。几个 Agent 同时找 bug，然后另一组对每个发现项投票，票数够才发布出来。只涉及风格、诊断信息、清理类的发现项直接丢掉。他们还用自己仓库里的 PR 做过 A/B，确认这套过滤器值得留下。剩下的发现项按严重度排序，以行内评论的形式出现，并且标注为重要、小问题或先前就存在——后面这个标签的意义是：一个不是这次变更引入的 bug，不该看起来像作者的锅。

审批粒度缩到了单个 commit

第五层是整篇里最反直觉的部分。他们没有给「谁有权限批准」设计一套角色体系，而是让变更本身决定风险档位。

风险档	例子	需要几个人批准
低	文档、文案、仅内部的功能、藏在开关后面的增量变更	自动审查与安全检查全绿后，不需要人
中	常规产品变更，以及缓存、自动更新器、系统提示词这类敏感区域的改动	一个人
高	风险最高的代码，加上一小撮「永远需要两个人」的路径	两个人

档位由分类器读变更内容来定，第二个分类器再单独判断「这次变更是否还需要额外一个人，哪怕它的档位说不需要」。有些路径永远需要人：代码所有者标为敏感的，以及任何 CI 工作流文件。

配套还有三条规则，我认为是这套流程在制度上最硬的部分：

只有受信任的作者走轻量路径。 只有在该仓库受信任名单上的人（基本就是拥有这个仓库的团队）才能免掉人工批准，其他人一律需要第二个人签字。

Agent 的批准永远不算人的批准。 自动审查可以放行一个低风险变更，但它不能去填一个要求由人填的位子。

谁下的提示词，谁对这个变更负责。 一个由 Agent 写出来的 PR，下指令的那个人算作必需审查人之一，跟这些代码是他自己敲的没有区别。

还有一条粒度上的规定：一个批准只覆盖一个具体的 commit。如果之后落进了系统无法担保的新提交，比如 Agent 自己推的、或者有人手工解决冲突产生的合并，批准就得重新给一次。

把这几条连起来看，审查的对象已经从「人」换成了「commit」。审批不再是一份持久的授权，而是对某个具体状态的一次性确认。这大概是「持续集成」在 Agent 时代的对应物：持续授权。

审查者自己也在被审查

第六层之后是这套流程里我觉得最有意思的部分：他们怎么让审查者本身变好。

事故变成评测集。 团队把历史上导致过事故的 PR 收集起来，连同当时的修复提交和回滚一起，让熟悉那段代码的工程师逐条确认 bug 是什么、在哪里。审查者每天对这套集合跑一遍，而每一次对审查者的改动，都要在这套集合上打分，分数涨了才留下。

噪声用人的行为来量。 想多抓 bug 很容易，代价是多报非 bug。他们不靠内部打分，而是把审查者留下的每条评论按 PR 上的人的反应归类：改了、说它错了、说这个行为是故意的、或者认为不重要。另外还会拿一批已知干净的 PR 跑审查者，统计它有多少次会让人做出有害改动。优先级写下来是：抓真 bug 排在减少审查轮次前面。

这里有一句我认为值得所有做 AI 审查的人记下来：当作者是 Agent 时，噪声的代价更高。 人可以在一秒内把一个小问题挥掉，Agent 会去修它，于是多一个提交、多一轮审查。

真正没解决的是收敛问题

如果这篇文只讲六层和分级，那它是一份漂亮的流程说明。但团队自己写出了这套机制的失败模式，而且写得比外部批评更狠。

Agent 作者和 Agent 审查者可以互相喂活，无限期。 有一个 CLI 的 PR，在一夜之间经过了五十多轮审查与修复，直到作者手动叫停。

他们去查了审查者反复标记的那些代码是谁写的：用 git blame 追下去，约 59% 是在审查者第一轮时就已经在那里的代码。也就是说，审查者很少发现新 bug，它每一轮多找出的是几个旧的 bug。

更诚实的是，他们把责任归到了自己身上：团队习惯了默认跑好几轮，因为每一轮总能捞出点新东西。这在一次高风险变更上可能值，但在每个 PR 上都跑就不值了。

对策有四条：三轮封顶，超过三轮审查者会要求作者退回去重新考虑方案；前几轮之后只审查增量 diff；按 bug 类别标记，让作者一次修掉所有同类实例而不只是一行；以及已经发过的发现项不再重复。

这一段是整篇里对我冲击最大的地方。人类代码审查的失败模式通常是漏看，而 Agent 审查 Agent 的失败模式是不收敛：双方都有耐心、都能一直干活，于是这里缺的东西变成了终止条件。「多审几轮更安全」在这里是个错觉，边际收益在几轮之后变成了对历史债务的重复曝光。

而且团队承认自己也没有全部解决：他们还没有「当回滚率或事故率上升时自动收紧审批」的熔断器，工程师们希望在更多代码走向零人工合并之前先把这东西做出来。

被让出去的那一半职责

文章开头说代码审查干两件事，第二件是在团队内部建立共享理解和代码库认知。这一半在机器审查主导之后怎么办，文章到很后面才回答。

给出的答案是几个偏文化的做法：有人会让 Claude 生成一个小产物，把要改的那部分代码可视化出来，用这个人自己喜欢的方式讲给他听；团队默认在开放的 Slack 频道里干活，于是别人在建什么你能看见。原文的论证是：一个一行的文案改动几乎教不会你什么，而一个即将修改的模块的讲解能教会你很多，所以后者比逐行读琐碎的 diff 更值。

这个回答我持保留意见。它用一个由 AI 生成的产物去补一个原本发生在人与人之间的过程。讲解质量、提问与追问、以及「我知道隔壁组为什么这么设计」这类隐性知识的传递，是不是能被等价替代，文章没有给出证据。这是我认为这套流程里最值得观察的一个缺口。

「你合的，你负责」：把回滚当成一等公民

六层之外还有一层不写在图里的东西，是团队对责任的处理方式。

他们的默认规范是：你合入一个中小变更，之后它出了问题，通常由你来修。这条听起来像追责，但原文列出的几条前提把它的性质改了。变更都很小，所以好审、好查、好回滚；所有东西都可逆，特性开关、revert 和分阶段发布能在几分钟内撤销大部分错误；影响面决定规格，贵的代码自然拿到更多人和更多检查；回归通过遥测和内部使用快速浮出水面；以及最关键的，这不算追责，负责修的人恰好掌握最多上下文，而事故复盘看的是系统而不是人。

这一段解释了为什么前面那些自动层敢放开。流程之所以能把大部分阅读交给机器，是因为兜底成本被压得很低：错了能几分钟撤掉，撤掉之后有人认领。如果回滚一次要半天、要开三个会，那自动放行就是不负责任。所以这套设计里，可逆性不是附属能力，它和审查层是同一个结构的两半。

团队也写了「方向要变的时候怎么办」：Agent 让起一个事情变得很便宜，所以有些工作本来就不该落地。通常的做法是有人在频道里问一句为什么、指一个早先的决定、或者提一个更简单的路子，然后作者关掉或者改写那个 PR。因为代码写得快，关掉一个 PR 不觉得是损失。前提是这种不同方向要早说，而不是等到 PR 做完了再给一条阻塞性评论。

能直接拿走的部分

抛开 Anthropic 的规模，这套流程里有几件小事是可以明天就开始做的。

在 PR 之前：给 Agent 一些它能跑的检查，写进一份简短的 CLAUDE.md；用钩子跑格式化和 lint；本地先跑一遍 /code-review 或 /security-review；再加一份 REVIEW.md，把反复出现的审查意见沉淀进去。

在 PR 上：要求 CI；把「怎么测试的」和「怎么回滚」写进 PR 模板；先在一个仓库上加 AI 审查，调几周 REVIEW.md 再铺开；让审查努力匹配风险，常规变更快过一遍，一个漏掉的 bug 很贵的路径上深查。

关于 REVIEW.md 的写法，原文给了一条很实用的标准：好的 REVIEW.md 很短，它会写清在这个仓库里「失败长什么样」（文档仓库的失败是「它在撒谎」，配置仓库的失败是「它路由错了」），限制小问题的数量，列出该跳过的路径，并且要求证据给到文件和行号而不是从名字猜。它还会要求总结以数字开头，没什么可修的时候要明说。

写在最后

我读完这篇的主要收获，是它把「AI 审查」这件事从工具选型问题变成了流程设计问题。杠杆落在六层怎么分、审批粒度切到多细、以及谁为 Agent 写的代码签字，而不是换一个更强的审查模型。其中「Agent 的批准永远不算人的批准」和「一个批准只覆盖一个 commit」这两条，是制度设计而不是技术设计，而它们恰好是最容易被抄漏的部分。

另一面是，他们公开了自己流程的失败模式（五十轮不收敛、59% 是旧 bug、没有熔断器），这部分的价值我认为高于流程本身。一份把缺陷写出来的工程文，比一份只讲做法的工程文可信得多。

GitHub 八天崩六次！Actions 宕机 10 小时波及 Copilot 和 Pages，AI 流量压垮了全球最大代码平台！

admin@yesmiracle.net (万戈) — Sat, 08 Aug 2026 00:00:00 +0000

如果你在过去一周 push 过代码、等过 CI 绿、或者依赖 Copilot 做 code review，你一定感受到了：GitHub 正在「慢性崩塌」。

8 月 6 日，GitHub Actions 从 UTC 15:22 开始降级，整整 10 小时 42 分钟后才宣告恢复。但这不仅仅是一次孤立事故——这是 8 月份前 6 天的第 6 次故障。

平均每天一次。不是玩笑。

更让人脊背发凉的是，这次宕机并不是 Actions 一个人在扛——Copilot code review、Copilot coding agent、GitHub Pages、Webhook、Enterprise Importer 迁移，全线瘫痪。你自建 Self-Hosted Runner？也没用——调度层一崩，所有 Runner 都成了摆设。

GitHub 8 月「故障日历」：6 天，6 次

先别急着说我夸张。直接看 GitHub Status 的历史记录：

月份	故障次数	备注
2026 年 8 月（前 6 天）	6	日均 1 次
2026 年 7 月	26	接近每天一次
2026 年 6 月	23
2026 年 5 月	23
2026 年 4 月	26	约 86% 月正常时间，超过 100 小时宕机
2026 年 2 月	37	峰值，日均 1.3 次

三个月内超过 70 次故障。作为对比，四个 9 的可靠性意味着全年宕机不超过 52 分钟——GitHub 的 4 月单月就超过了 100 小时。

对于全球数百万开发者将 CI/CD 管线、代码审查、甚至生产部署都绑在 GitHub 上的生态来说，这不是一个 nuisance，这是结构性的交付阻塞。

8 月 6 日事故全还原

我们来拆解一下这次事故的时间线（UTC）：

时间	事件
15:22	首次报告 Actions 降级
15:41	Actions 可用性标记为 degraded
15:45	工作流无法启动、中途失败、API 返回错误、意外限流
15:53	Pages 被拉入事故
17:02	开始缓解，但仍在扩散
17:40	Copilot code review、Copilot coding agent、Hosted Runner、Enterprise Importer 全中
18:11	Self-hosted Runner 注册也报错/限流
20:34	Webhook 吞吐降到正常水平的 15%；队列任务成功从 30-40% 爬回 65%
21:30	发现「无效 job 分配」问题——调度层给 Runner 分配了已经失效的任务
00:05 (8/7)	标记缓解
02:04 (8/7)	事故关闭。但提醒用户：部分 push/PR 触发事件已丢失，无法回放

10 小时 42 分钟。从 Actions 到 Copilot 到 Pages 到 Webhook，整个 GitHub 的 CI/CD 和 AI 代码工具链被打了一个贯穿。

最讽刺的是 GitHub 说的那句话：“工程师已经确认了中断源，正在推进修复”——这话在 15:45 就说了，然而直到午夜才标记缓解。中间经历了 Copilot 被拖下水、Webhook 吞吐只剩 15%、到最后发现调度层分配了「无效 job」给所有 Runner。

为什么 GitHub 就是修不好？

这个问题很多人都在问。答案比想象中复杂，但也比想象中残酷。

原因一：AI 代码流量爆炸

GitHub CTO Vlad Fedorov 自己承认：AI 生成的代码在过去两年让基础设施负载增长了 3.5 倍。2025 年 10 月，GitHub 规划了 10 倍容量增长。到 2026 年 2 月，修正为 30 倍。

但容量规划是一回事，基础设施能不能在扩容过程中保持稳定是另一回事。《The Pragmatic Engineer》的分析一针见血：

在大规模系统中，小低效会叠加：队列加深 → 缓存未命中 → 数据库负载 → 索引落后 → 重试放大流量 → 一个慢依赖拖垮多个产品体验。

原因二：AWS → Azure 迁移撞上了负载高峰

GitHub 正在从 AWS 迁移到 Azure——一个本身就极其复杂的跨云基础设施迁移，偏偏撞上了史上最大的流量增长期。就像一个高速公路在拓宽施工的时候，车流量翻了 3 倍。

原因三：18 年的技术债

GitHub 的代码库和架构是从 2008 年的 Rails 应用一路长起来的。你不可能在不停产的情况下重写所有东西。

4 月 GitHub 为此道歉过。6 月 SVP Jakub Oleksy 承诺「结构性改进将永久消除故障模式」。但从 7 月的 26 次故障和 8 月的 6 天 6 次来看，这些承诺和道歉一样，没什么实质变化。

Self-Hosted Runner 不是逃生舱

很多团队以为自建 Runner 就能躲过 GitHub 的平台故障。8 月 6 日的事故彻底证伪了这个假设。

Self-hosted Runner 依赖 GitHub 的调度服务来接收和分配任务。当调度层崩了，你的 Runner 要么注册失败，要么被分配了无效 job。Hacker News 上的开发者直接验证了：“就算是自托管 worker，宕机时一样不工作。”

这不是单个节点的失效，这是控制面的失效。你可以在边缘加再多计算节点，控制面塌了，所有节点都是瞎子。

那些已经离开的人

Mitchell Hashimoto，GitHub 第 1299 号用户，Vagrant 和 HashiCorp 的创始人，在 GitHub 上活跃了近 18 年。今年 4 月，他花了一个月时间做了一件事：每天在日历上打一个 X，记录 GitHub 宕机是否影响了他的工作。

结果是——「几乎每天都有一个 X」。

他把自己 52000+ Star 的终端模拟器 Ghostty 搬离了 GitHub。“我想发布软件，但平台不让我发。18 年了，我得走了。”

他并不孤独。Zig 编程语言的维护团队在 2025 年 11 月就把项目迁到了 Codeberg，理由是「Actions 有严重 bug，GitHub 的工程文化也出了问题」。

这不是 casual users 因为小不爽而离开。这些人是在 GitHub 上建立了一整个职业生涯的开发者。当他们都觉得「够了」，说明问题真的到了临界点。

写在最后：GitHub 的「慢性崩塌」

GitHub 正在经历一个所有高速增长平台都会遇到的致命问题：成功本身就是失败的种子。

AI 代码生成推动的流量暴涨不是 GitHub「做错了什么」，而是它做对了所有事之后的结果。但问题在于——当一个平台的可靠性从「基础设施」退化为「运气」，开发者的信任就会一点一点流失。

8 月初的 6 天 6 次故障告诉我们的不是一个「运维事故」，而是一个生态级信号：当全球最大的代码托管平台开始成为发布管线的瓶颈，整个软件行业的交付效率都会被打上一个问号。

对于还在犹豫要不要离开的团队，我的建议很简单——开始做多平台冗余。GitLab、Codeberg、自建 Gitea，至少让 CI/CD 管线不绑定在单一平台上。不是 GitHub 不好，而是它现在的可靠性，已经配不上你对它的信任。

延伸阅读：《Microsoft 急刹车：下令工程师停止「Tokenmaxxing」》——微软系产品全线承压的另一面。

代码爆炸了！AWS DevOps Agent 新增 AI 发布管理，自动审查 + 自动测试一条龙！

admin@yesmiracle.net (万戈) — Mon, 13 Jul 2026 00:00:00 +0000

如果你在任何一个正在用 AI 编码助手的团队待过，你一定碰到过这个场景：

开发者用 Cursor 或 Copilot 刷刷刷一天写了平时三天的代码量，PR 一提交——然后就卡住了。Reviewer 看着暴涨的代码行数一脸懵，测试团队堆积如山的回归用例跑不完，合规检查、依赖审计、发布审批……每一个环节都在拖后腿。

AI 把代码生产的油门踩到底了，但发布流水线还停留在工业革命时代。

这可能是 2026 年软件工程面临的最大结构性矛盾。亚马逊云科技（AWS）上周在纽约 Summit 上扔了个解决方案：AWS DevOps Agent 新增发布管理能力（Preview），通过两大核心功能——Release Readiness Review（发布就绪审查）和 Autonomous Release Testing（自主发布测试）——把 AI 的触角从「写代码」延伸到了「发布代码」的最后一公里。

Release Readiness Review：代码还没合并，AI 已经帮你审完了

传统的代码审查靠的是人工 Reviewer 一行一行地看 diff。但面对 AI 生成的动辄几百上千行的 PR，人类的注意力天花板是真实存在的。

AWS DevOps Agent 的 Release Readiness Review 做的不是「简单扫一眼」，而是构建了一个跨仓库的知识图谱——你的服务依赖什么、谁依赖你、每条变更可能影响哪些下游——然后对照你定义的标准逐条检查。

哪些标准？AWS 说你自己用自然语言写就行。安全策略、合规要求、网络访问规则、可观测性最佳实践……不用学政策引擎 DSL，直接写「所有对外 API 必须经过鉴权」这种大白话，Agent 就能理解并执行。

检查结果直接以评论形式出现在 GitHub 或 GitLab 的 PR 上，或者通过 Kiro（亚马逊的 AI IDE）和 Claude Code 插件直接在 IDE 里展示。开发者提交代码之前就能看到：「⚠️ 这条变更会影响下游 3 个服务的 API 契约」或「✅ 加密策略检查通过」。

更狠的是，Agent 还会在** AWS 托管的隔离环境**里跑一遍轻量级的用户旅程测试，确认代码真能 build 通过、服务真能启动。相当于每个 PR 都自带了一个沙盒验收环境。

Autonomous Release Testing：测试不再是静态的手工活

如果说 Release Readiness Review 是「AI 门卫」，那 Autonomous Release Testing 就是「AI 质检员」。

传统 CI 的测试套件是静态的——你写一批用例，随着项目膨胀，回归测试越跑越慢，但覆盖的场景却越来越有限。Autonomous Release Testing 的做法完全不同：它根据每次代码变更的具体内容，动态生成测试计划。

Agent 会分析「这个 PR 改了什么东西——是一个 API 的返回格式？一个数据库查询的逻辑？一个前端组件的交互流程？」然后针对性地构造包含功能验证、行为回归、集成场景的测试方案。测试在你的生产级环境中执行（Customer-provisioned production-like environments），输出结构化的日志、追踪、指标和执行摘要——不只是「通过/失败」，而是「为什么通过、为什么失败、行为有什么变化」。

分析师 Pareekh Jain 评价说，自主发布测试「自动化了软件交付中最耗时的部分」，开发者能减少手写测试的时间，SRE 能降低回滚频率，系统可靠性自然就上去了。

不是只有 AWS 在打这场仗

AWS 当然不是唯一看到这个问题的玩家。

GitHub 已经推出了 Copilot Autofix，能在安全漏洞进入生产之前用 AI 自动提修复方案。微软把这些能力集成进了 Azure DevOps。CircleCI 发布了 Chunk Sidecars，把 CI 质量的验证直接塞进 AI 编码工作流。Dropbox 的 Nova 平台让编码 Agent 在隔离的开发环境里运行，对接真实的构建和验证管线。

但 AWS 的差异化在于：它把发布管理和运维能力绑在了一起。 你不是在一个孤立的工具里做代码审查——你的代码审查、发布决策、生产运维全在一个 Agent Space 里，Agent 知道服务在生产环境中实际怎么跑的，也知道哪条变更可能会出问题。

这套能力 built on top of AWS DevOps Agent 已有的运维功能（自动调查故障、根因分析、修复建议），等于打通了从「写代码 → 审查 → 测试 → 发布 → 运维」的完整链路。

这对你意味着什么

说人话就是三件事：

第一，Review 不再是瓶颈了。 如果 Agent 能自动跑完安全检查、依赖审查、合规审计、环境验收，Human Reviewer 只需要关注那些 Agent 标记为「高风险」或「不确定」的变更。这能让团队在不增加人手的情况下应对 AI 带来的 PR 洪峰。

第二，测试效率真正对齐了代码生产效率。 AI 写代码是弹性的、动态的，那测试也该是弹性的、动态的。Autonomous Release Testing 的思路——根据变更内容自动生成测试——才是未来，手工维护的静态回归用例迟早会成为过去式。

第三，组织标准变成了 AI 可执行的。 之前很多团队的安全策略和发布标准是写在 Wiki 里的文档，经常被跳过或遗忘。现在用自然语言定义标准，Agent 能在每个 PR 上严格执行——不是替代人的决策，而是确保「该检查的都检查了」。

关于价格

Preview 期间免费，部署在美东（us-east-1）区域。GA 后的定价是 $0.0083/agent-second，新客户有 2 个月免费试用期。比起团队为 Review 和测试投入的人力成本，这笔账应该不难算。

使用前提是：至少把一个 GitHub 或 GitLab 仓库连接到你的 Agent Space。

写在最后

过去两年，AI 编码助手的普及从根本上改变了「写代码」这件事的效率曲线。但正如 AWS 自己在博文里说的：「AI 编码工具带来的价值在 Review 队列里等着，而不是到达最终用户手里。」

代码生产效率上去了，但软件交付效率——审查、验证、测试、发布——成了新的瓶颈。这是一个「AI 造了更多活，人类反而更慢了」的悖论。

AWS DevOps Agent 的这次更新，本质上是对这个悖论的一次正面回应：如果不解决发布瓶颈，AI 写代码再快也是白搭。让 AI 来审 AI 写的代码，让 AI 来测 AI 改的逻辑——不是要取代人，而是要把人的注意力从「执行」转移到「决策」上。

毕竟，2026 年的软件工程，真正的竞争力可能不再是「谁写得快」，而是**「谁发得稳」**。

CI on AI博士 万戈

Claude Code 团队的代码审查方法：六层检查、按风险分级审批、一个审批只覆盖一个 commit

他们把人工时间拆成了两个账本

六层，每层的洞都在不同地方

审批粒度缩到了单个 commit

审查者自己也在被审查

真正没解决的是收敛问题

被让出去的那一半职责

「你合的，你负责」：把回滚当成一等公民

能直接拿走的部分

写在最后

GitHub 八天崩六次！Actions 宕机 10 小时波及 Copilot 和 Pages，AI 流量压垮了全球最大代码平台！

GitHub 8 月「故障日历」：6 天，6 次

8 月 6 日事故全还原

为什么 GitHub 就是修不好？

Self-Hosted Runner 不是逃生舱

那些已经离开的人

写在最后：GitHub 的「慢性崩塌」

代码爆炸了！AWS DevOps Agent 新增 AI 发布管理，自动审查 + 自动测试一条龙！

Release Readiness Review：代码还没合并，AI 已经帮你审完了

Autonomous Release Testing：测试不再是静态的手工活

不是只有 AWS 在打这场仗

这对你意味着什么

关于价格

写在最后

CI on AI博士万戈