Presentation: AI Works, Pull Requests Don’t: How AI Is Breaking the SDLC and What To Do About It

AI 正在发挥作用，而代码审查却不行：AI 如何打破 SDLC 以及应对之策 - InfoQ

InfoQ 首页 会议演讲 AI 正在发挥作用，而代码审查却不行：AI 如何打破 SDLC 以及应对之策

AI、机器学习与数据工程

在线 InfoQ AI 安全与隐私工程认证（8月26日）：在受监管的环境中部署 AI？

AI 正在发挥作用，而代码审查却不行：AI 如何打破 SDLC 以及应对之策

点赞

新下拉阅读列表

• 阅读列表

查看演讲

• 垂直

• 水平

• 全屏

速度：

• 1x

• 1.25x

• 1.5x

• 2x

下载

• 演示文稿

32:21

概要

Michael Webster 讨论了无头 AI 代理的兴起及其对软件交付管道的影响。他分享了大量由 AI 生成的代码审查请求如何成为人类审查者的严重瓶颈，并引入了持续的技术债务。学习工程领导者如何利用测试影响分析和自动化验证管道来验证代理输出而不牺牲稳定性。

个人简介

Michael Webster 拥有超过十年构建分布式系统和开发人员工具的经验，并涉足产品和商业策略。如今，他有兴趣了解如何最佳地使用 AI 来制造更好的软件。

关于会议

QCon AI 是一个由实践者主导的活动，专注于安全扩展这些工作负载所需的工程学科。它提供了直接访问同行组织在生产环境中使用的架构蓝图和失败指标。

INFOQ 事件

• 2026年7月9日，美国东部时间中午12点 从日志噪音到事件智能：AI辅助可观测性的成熟度模型 演讲者：Nicolas Jung - Datadog 日志产品经理

• 2026年7月16日，美国东部时间下午1点 代理时代工程：如何设计、构建、测试和运营 AI 驱动的系统 演讲者：Juveria Kanodia - Harness 工程高级总监

• 2026年8月6日，美国东部时间下午1点 为高风险事件响应构建 AI 代理评估 演讲者：Brianne Bujnowski - Datadog AI 高级产品市场经理，以及 Benjamin Barton - Datadog 高级软件工程师

演讲稿

Michael Webster：我的名字是 Michael。我是 CircleCI 的首席工程师。我今天将向大家介绍我们在 CircleCI 公司如何使用 AI，也许还能给大家一窥我们目前看到的软件交付领域中随着越来越多的人采用 AI 代理所出现的趋势。CircleCI 是一个持续集成和持续交付平台。我们服务于数千个组织。我们每月运行数百万个任务。基本上，如果你想以 AI 编写代码的速度来发布代码，我认为我们可能是最好的软件交付平台。这也让我们在跟踪趋势和识别行业动向方面拥有非常好的视角。

我想回顾一下 CircleCI 在人工智能领域经历的几个阶段。和很多人一样，当 ChatGPT 推出时，我们也迅速跟进，最初我们处于我称之为“复制粘贴”时代，那时你得自己处理上下文，把内容在各种工具之间复制粘贴。随后我们迎来了 Cursor IDE 和 VS Code 的 Copilot，它们具备了代理能力，可以执行更复杂的任务。最近，也就是过去六个月产品发布以来，我们开始看到无头代理的兴起。这些代理可以被直接嵌入到计算机中。一旦你将代理嵌入到计算机中，就可以按照预定的时间表运行它，也可以通过 Webhook 触发它。我认为，从整个行业来看，尤其是在 CircleCI，我们目前正处于中间阶段，我们正在尝试这些无头代理。

做个简要概述，基于我们目前的状况，我们仍然主要在这些 IDE 中工作，也许有些人使用的是 Claude Code 或 Codex。我们发现，目前机械性转换任务进行得相当顺利。我曾参加过一次最棒的 Slack 消息 Zoom 会议，当时我们内部的一位 AI 怀疑者表示，一旦他得到了他想要的验收测试，Claude 就能够理解并遵循模式，现在他只需要让其按照模式进行即可。就我们目前的情况而言，我认为，如果所有规则和标准都已就位，这些机械性转换任务实际上运行得相当不错。特别是当模型在笔记本电脑上运行并拥有完整的项目上下文时，它们能够生成的代码基本符合我们最资深工程师的标准，这主要是因为这些工程师已经投入了大量精力，确保他们的仓库结构易于理解。

我们还取得了非开发人员贡献方面的显著成功。我们一直有添加暗色模式到用户界面的长期请求，但一直无法优先处理。如果你不熟悉如何实现暗色模式，基本上你得去触碰用户界面中的每一个组件，并根据用户的设置改变它们的显示方式。这是那种没人会优先处理，但人人都会抱怨的问题：“为什么我们不能有暗色模式？”这个项目真正酷的地方在于，我们的设计团队主导了这个项目。他们对 UI 应该是什么样子，以及暗色模式应该如何运作有丰富的领域专业知识。他们能够创建所有样式，然后让代理完成大部分机械性转换工作。他们还需要一些工程方面的协助，其中有一些组件非常笨拙，但总体而言，我们已经看到这种将领域专业知识与 AI 相结合的方式是一种非常强大的组织属性，因为它让原本无法参与的人也能做出贡献。

我刚刚举了一些案例研究，说明在哪些情况下效果很好。但并不是所有情况都像阳光和玫瑰一样美好。结果仍然存在很大差异。来自 DX 的 Justin 提到，不同公司之间存在很大差异。我发现即使在我们公司内部，不同团队之间也存在差异。如果你有非常好的模式可以借鉴，那么你可以让这些代理表现得非常好。你必须编写规则。一切都是一个学习曲线。我们投入资源的一个方面，就是让人们能够接触到这些工具，接受培训以使用这些工具，但真正将这些模式建立起来，实际上比看起来要困难得多。

什么效果不好？

现在我们来谈谈真正效果不好的地方。有没有人早上提到一个 Jira 任务，然后下午就带着一个包含这么多行代码更改的 PR 出现？我甚至不特别针对 AI 的低效代码来说。这是指那些非常大的拉取请求。如果你有一个团队，拥有结构良好的规则可以生成代码，那么在某些情况下，比如在引导一个全新的功能或全新的着陆页面时，1500 行代码可能是合适的，但对人类来说，这太多了，无法进行审查。在我职业生涯中，我使用过的一些经验法则和研究指出，人类在一小时内能审查的代码量大约是 500 行。Claude 可能在 10 分钟内就能生成 1500 行代码。如果你幸运，他们可能会进行一些调整，可能需要 30 分钟，所以他们生成的代码量是人类审查量的六倍。即使代码质量很好，生成的代码量仍然远远超出人类的处理能力。

PR 的问题不仅仅在于大小。虽然大小确实是个问题，但 PR 本身通常效率很低。当你查看一些公司进行的研究，关于 PR 审查时间的中位数时，你会发现它可能在 3 小时到 14 小时之间。PR 合并时间的中位数是 14 小时。如果你是高级工程师，不等待别人提交 PR，而是自己直接合并，那么你可以将时间缩短到 3 小时，但这并不是一个理想的情况。我们希望人们进行代码审查，但 PR 的机制本身有很多复杂之处。它们通常异步进行，无论更改的大小如何，通常都需要进行审查。人们提到过，5 行代码会得到 50 条评论，10 行代码会得到 5 条评论，500 行代码会得到 LGTM（Looks Good To Me）。这是一个非常现实的影响。我们正在努力改进这一点，但目前我们仍然难以让代理生成适当大小的 PR。目前，这对我们来说仍然是一个远未解决的问题。

我们在某些方面取得了一些成功，那就是将我们的审查机器人应用于帮助一些在不熟悉的代码库中工作的团队。设想一个需要去 React 代码库工作的 Go 开发者。从组织的角度来看，Go 开发者通常在 React 代码库中工作的原因，是因为你无法找到那些通常负责 React 代码库的人来完成这项工作。他们可能正在推进自己的目标，也许是因为找不到合适的 UI 专家。对于处于这种情况下的人，代码审查尤其痛苦。如果你需要等待某人来审查代码，而这些代码对他们当前冲刺目标的实现并不那么关键，那么在基本的风格和设计指南问题上反复拉扯，是一个严重的问题。

在这些情况下，我们内部审查机器人取得了一些成功。如果你能够将规则编码，并以确定性的方式应用这些规则，无论你设置的是什么规则，比如 for 循环，都按规则执行，这对不熟悉代码库的人来说非常有用。再次强调，我们遇到的问题更多是 PR 的机制本身。它会打断你的流程。你可能本可以更早地获得反馈。我们希望它能更像一个 linter。目前，我们看到了一些成功。我们发现了一些错误，但毫无疑问，这是我们组织正在投入资源的领域之一。

展望未来，事情变得有趣

展望未来，我们谈论的主要是开发者在 IDE 和 CLI 中独立工作。正如我所说，CircleCI 的一个优势是，我们能提前看到组织中发生的事情。因为我们运行了大量构建，客户群体和语言种类非常广泛，这给了我们发现一些趋势的机会。目前，无头代理的趋势是我夜不能寐的原因。首先，让我们看看 GitHub 上的一些活动。在 Google BigQuery 中，有一个 GitHub 所有活动的存档，被称为 GitHub Archive，你可以使用 SQL 查询它，这非常酷且有趣。

这些无头代理一推出，我便想看看人们是否真的在使用它们。例如，在 Actions 中运行代理，在 CircleCI 中运行代理。如果你查看趋势，你会看到在这些代理大部分推出时，活动量出现了显著的激增。在此次分析中，我关注的是知名的代理，它们有明确的 GitHub 用户名。我可以明确地说，这些就是代理。你在这里可以看到趋势。在它们推出后不久，GitHub 每周的活动量迅速达到了数十万次。如果你曾经查看过 GitHub 的 Webhook 和它们支持的事件，你会发现有很多事件，所以我决定进一步深入分析。这呈现出一个非常有趣的画面。当你查看这些代理推出的时间，几乎所有代理的主要用例都是拉取请求审查或问题分类。它们重写问题、查找重复项、审查 PR。你可以在数据中看到这一点。你看到的那些显著的激增是关于审查和问题评论的，但今年五月份开始，你开始看到推送事件的激增。

现在我们每周都会看到这种情况，而且我最近没有重新运行这个分析，所以从那时起情况只可能变得更糟了。我手上并没有相关的图表。你已经看到一些AI生成的代码量和它们实际编写的代码量一样多。这确实令人担忧，因为现在我们已经真正将这些AI与系统解耦了。它们不再只是一个试图帮助你进行代码审查的友好机器人，而是直接将代码推送到你的仓库中。你已经查看了公开的时间线数据。也许这就是人们在尝试这些工具时的方式，但当我们内部查看CircleCI的数据时，我们看到的是一样的趋势。这是我们的使用情况。它落后于GitHub。我们只是众多CI服务提供商之一，我们并没有托管每一个开源项目，但关键的一点是，人们为这些构建付费了。这些活动是由一些突然出现的代理执行的，人们实际上设置了流水线来处理这些更改。这不仅仅是某人更新了一个README文件。这些是真实用户将这些工具应用到了真实世界的软件项目中。

我们已经实现了无头代理。它们全部都是自主运行的。太棒了。当然，这并不是现实情况。如果你看一下最新的DORA报告，这份报告聚焦于AI辅助软件开发的现状，他们发现的是，是的，这些代理确实提高了开发速度。这完全合情合理。我们在客户中看到了速度的提升。你也可以在GitHub上看到整体趋势。他们还发现不稳定性有所增加，缺陷率更高，变更失败率也更高。再次强调，这一切都取决于组织的不同。重点是，虽然我们有很多东西在推动代码，但它们并不总是能很好地工作，有些情况下甚至让我们的产品变得更加不稳定。

这是我找到的另一项研究，它关注了一些使用AI IDE的开源项目。这项研究的独特之处在于，它的目标是关注长期影响。之前有一些研究关注的是人们是否会合并这些AI机器人提交的PR，但这项研究则关注的是在数千个开源项目中，几个月内会发生什么。主要的结论是，从Cursor的使用中，他们获得了一个月的速度提升。这是他们研究的具体工具。在那个月之后，这种提升消失了。并不是说你的速度完全停滞不前，或者没有继续增长，而是你回到了基准线。他们将这种现象归因于这样一句话，令人不寒而栗：“我们观察到AI助手的更改中持续积累技术债务。”我认为这可能是大家直觉上已经意识到或理解的事情，但这项研究却以因果关系的方式展示了速度下降与这种技术债务之间的联系。再次强调，这里的总体影响是这些项目确实经历了一次显著但非常短暂的速度提升，然后基本上又回到了之前的状态。

输出并不理想。这些好处尚未实现。幸运的是，情况还会变得更糟，因为在某些时候，即使我们解决了这些问题，我们还必须面对一些基本的数学问题。这是排队论的一个非常简化的概念。那些有工作不断到达并进行处理的系统，它们的行为是怎样的？如果你曾经去到一个非常繁忙的商店，那里只有一个收银员，你可能对此有所体会。如果你的工作到达速度比处理速度更快，就会出现延迟。排队论的一个优点是，因为我们有这些数学模型，我们可以进行一些模拟。我们不需要真的等到每周有成千上万的 PR 被打开后，才能看到会发生什么。我们可以进行模拟。

在这个模拟中，我们假设一个组织能够以两倍于其编写代码的速度处理代码变更，并将其交付给客户。然后，我们根据 AI 是否使你更快，对各种情况进行模拟。如果你的 AI 通过率提高了约 75%，坦白来说，这将是一个非常大的提升，但并不不合理。你将看到的延迟，等待有人查看你的变更，基本上会趋于无限。我们看到的是，这些工具正在被越来越多地采用。使用率只会在增长。输入的速度可能甚至比 75% 还要快，但交付速度却远远达不到这个速度。这些模拟展示了某些场景，基本上，如果你无法以与 AI 编写代码速度相匹配的速度提升你的交付速度，你将看不到任何好处。所有的好处都会被你交付过程中的所有延迟所抵消。

现实情况是，对于大多数组织来说，即使你确实能让 AI 运行得尽可能快，作为组织，你们的目标可能也限制了你们无法加快速度，即使你们想这么做。目前，每个人都想这么做，并投入了大量资金。这不是一个理想的情况。我们有很多事情可以尝试去做。我们可以尝试优化我们的流水线。我们在内部就是这样做的，重写缓慢的脚本，优化测试的并行化方式，对代码审查非常高效。我认为这些措施最终都只是权宜之计。对我来说，更高杠杆的切入点是关注代理的输出验证。这是一个非常简化的代理循环视图。我们会给它一些工具，我们会给它一个任务。然后，在任务未完成之前，我们会继续运行。

我认为在行业中，我们很多时候都集中在任务部分，也经常谈论工具部分，这两部分都很重要，但我认为我们低估了检查部分的重要性。因为如果你有能力验证 AI，你就可以让它尽可能快地运行。不仅如此，当它失败时，你现在有了一个数据集，可以用来训练 AI，使其变得更好。我认为我们真正需要投入时间的是这个检查和验证阶段，而不是特定的任务和工具定义。我们已经看到这种情况在 AI 中发生了很多次，其中某种特定的提示策略变得占主导地位。我很高兴人们正在做这些研究，但很快会发生的是，这些提示策略会被训练进模型中。它们总是使用思维链。你不需要要求它们这样做。

我认为，就我们的投资优先级而言，越来越多地关注验证，是我们加快交付速度、实现目标的唯一途径。因为一旦你拥有良好的验证，一旦你拥有一套测试集，这些测试通过后，就可以确认代码可以顺利部署到生产环境，你基本上就消除了所有障碍和瓶颈。你仍然需要让这些测试运行得非常快，但你首先确实需要这套测试。

让我们来谈谈我们在这里通常会采取的一些方法。单元测试就是一个很好的例子。通常运行测试的方式是运行完整的测试套件。每次提交代码，你都会运行完整的测试套件。这种方式在规模相对较小的时候是可行的。我们在内部的大型单体应用上也采用这种方式，效果很好，但当提交次数增加到人类提交次数的十倍时，这种方式就会再次出现瓶颈。那如果我们换一种方式呢？我们现在正在实现一个功能，我们已经在其中一个大型的UI单体应用中使用了它。这是一种叫做测试影响分析的旧方法。这个方法的核心思想是，你的代码覆盖率可以指导你如何加快测试速度。如果你把代码覆盖率看作是源代码和测试之间的依赖图，你就可以利用这个依赖图来减少需要运行的测试范围。下面是一张这个方法的示意图。

这里我们有一个前端应用。你有一些用于用户待办事项的前端组件。你还有一些用于获取这些信息的API。根据这些文件的名称，我们可以推断出它们之间的关系。假设我们现在想要修改用户代码，我们可以立即排除与待办事项相关的测试。只要它们之间没有依赖关系，如果存在依赖关系，我们的覆盖率追踪会发现这一点。在某些情况下，我们甚至可以只运行用户组件测试的一个子集。比如，如果我们只是改变了获取用户信息的API，那么在这种情况下，我们可能需要测试组件，因为它会依赖于这个API来获取数据。但如果只是修改了组件，而没有依赖于获取API本身，那么我们甚至可以进一步减少测试运行的范围。

这就是测试影响分析的基本概念。起初，这个想法看起来似乎过于简单，无法奏效，但当我们在一个大型的前端单体应用上尝试它时，结果却令人惊喜。这是CircleCI UI应用的主要单体应用。我们当时运行了10个并行的测试任务实例，耗时大约四分钟。虽然这个时间并不算太长，但我们觉得还有改进的空间。当我们应用了测试影响分析方法后，我们能够在单台机器上不使用任何并行处理的情况下，将整个构建时间缩短到仅1.5分钟。这涉及大约7500个测试，所以对于一个单体应用来说，这个测试数量并不算多。

这是一个非常令人鼓舞的结果，这意味着我们现在可以使用AI代理，让它以我们愿意在令牌上花费的金钱速度运行，并让它只运行它需要运行的测试。我们不再需要考虑如何并行化和分配所有这些代理，以及如何并行运行它们的所有测试，也不需要考虑它们是否应该以这种方式使用CI。我们只需要确保它们可以在笔记本电脑或云上的Docker容器中轻松运行即可。

代码审查同样适用这一原则。我们目前对这一概念还处于实验和理论阶段，因此我不会过多详细说明它可能如何运作。测试影响分析的核心思想是，并非所有代码具有相同的风险水平或彼此之间的关系相同。代码审查也是如此。并不是每一次更改都会影响你如何在数据库中对密码进行加盐处理，或者如何进行身份验证和授权检查。其中一些更改可能不需要与其他更改一样高的审查程度。这再次为我们提供了一个机会，可以减少每次由代理做出更改时需要处理的工作量。

如果代理修改的是代码库中特别敏感的部分，显然需要标记出来进行审查。如果它修改的是不那么敏感的部分，只要测试通过，也许可以自动部署。至少理论上是这样。我们还在尝试一种想法，即审查代理的推理过程与其输出之间的关系。这是来自我们用户界面的一张截图，我们在这里首先展示的是推理过程。这主要是用户体验方面的问题，而不是你在这里首先看到的是代码差异。你看到的是代理所执行的操作日志。我认为最终这可能会成为我们处理问题的方式，即我们先检查推理过程，然后依赖测试套件、代码检查工具和静态分析工具来验证代码差异。

保持一切正常运行

当然，这并不是我们唯一需要做的事情。如果你还记得我们之前提到的图表，这个交付管道现在对于从AI中获取价值至关重要。它不仅仅是一个构建过程让人感到烦恼或缓慢的问题。许多公司希望全天候运行代理。他们希望生成令牌，希望拥有能够工作的AI同事。我们构建的这些管道不仅仅是“如果CI中断，谁今天可以玩桌球”的问题，它们已经成为我们基础设施中的关键部分。我认为，作为工程师，我们未来可能将更多的时间投入到这一领域，即如何确保围绕AI的整个工厂、相关机制以及AI运行的环境，能够促进代码更改，而不是过分关注每个具体的更改本身。

让我举一个例子。在座的各位中，有人曾经处理过不稳定的测试吗？不稳定的测试指的是即使代码没有更改，测试有时通过有时失败的测试。这是一个非常难以解决的问题。我之所以知道这是一个难以解决的问题，是因为它对开发人员的信任造成了极大的腐蚀。当开发人员不信任测试套件，当他们不相信红色构建确实意味着构建失败时，他们对发生的问题会变得不那么敏感。此外，这也会让人非常烦恼。如果你曾经处理过不稳定的测试，人们通常的解决方法是重新运行构建，然后再次尝试，希望它真的不是那么不稳定。

当我们审视这一点时，这似乎是一个值得我们投入改进验证流程本身的领域。因为如果我们能减少不稳定测试的数量，就能确保流程本身能够稳定运行，并且每次都能获得清晰的信号。如果我们希望这些代理能够编写代码，提供一个清晰的信号（判断某件事是好是坏）是非常重要的。一旦你开始思考，这是不是一个不稳定测试，或者让我去查看日志，或者这个依赖项又宕掉了，你就又得手动去检查所有内容，一切都会陷入停滞。我们的思路是，我们是否可以在后台持续改进所有项目中的测试套件？

事实证明，我们实际上已经拥有完成这项任务所需的所有数据。我们平台的一项功能是记录你的测试结果。你可以将它们上传给我们，我们会记录当时的 SHA 值以及测试结果。基于这些信息，我们可以对涉及的 git SHA 以及当时运行的作业进行分析，从而推断出测试是否不稳定。这可能看起来像这样：我推送代码，测试失败了。某人重新运行测试，测试通过了。这很可能是一个不稳定测试。要完成这个任务，你真正需要的只是一个数据库。如果你要为成千上万的人做这件事，就需要一个非常高效的数据库。你可以自己实现这一点。所有主要的测试结果报告工具都输出 XML 或 JSON，你可以使用这些数据来加载你的数据库。

然后，你可以让代理访问这个数据集，并让它开始尝试修复问题。我要强调的是“尝试”这个词。再次强调，这是我们最初考虑直接应用于 AI 代理的事项之一，而第一次尝试完全失败了。我们从一个提示开始，让代理非常自主地运行。这个简化版的核心思想是，我们可以告诉它一个我们已知是不稳定的测试，让它运行一定次数，尝试诊断失败，并将结果写入文件。我们遇到的主要问题是模型的幻觉。会发生的情况是，模型会声称它运行了测试，但实际上并没有运行这些测试。然后我们会将这个 PR 提交给客户，声称我们有一个修复方案，但代码检查器会失败，或者测试实际上会完全失败，这对任何人都不是很好的体验，也不是我们想要的结果。

我们提出了一个更加稳健的解决方案，这个方案看起来更像是代码。这属于构建代理的范畴。它更偏向于工作流程方面。如果你熟悉 Anthropic 的论文，它更像是一个预定义的工作流程，而不是一个代理。这里仍然有很多 AI 的参与，但我们的做法是，我们会列出我们已知存在问题的测试，然后为每一个测试制定修复计划。我们最初套件中遇到的一个问题是，无法隔离代理在不同测试之间所做的更改，因此你无法确定是哪些测试出了问题，或者是否真的出现了问题。有些修复可能是好的，有些可能是坏的，但我们把它们都打包在一起了。这是一个非常简单的修复方法，只需要将它改为一个真正的循环。

然后，我们添加了一些明确的步骤，以确保在代理运行之间保存上下文。我们会为特定的测试制定修复方案，然后尝试复现该修复方案。最重要的是，我们引入了这个 apply_plan 功能。我们为 apply_plan 功能添加的内容，最有效的是我们开始使用项目的 CI 流水线，作为一种方式来向代理证明修复是有效的。我们的思路是，你已经构建了这个流水线，你投入了大量时间来判断代码是好还是坏。它必须是绿色的才能合并，所以让我们直接使用它作为判断者，来判断修复是否有效。

我们没有使用 LLM 作为判断者，甚至没有尝试让 LLM 重新运行测试，而是认为我们已经有了一个修复方案。让我们直接在 CI 中运行它，至少我们可以验证是否没有回归，并且这给了我们一个可以回溯的能力。如果出现失败，我们可以查看失败的输出，然后重新运行它，并再次应用修复，同时考虑到它遇到的问题。

这将走向何方？

我将尝试在这里连接一些线索。如果你回顾 PR 的概念，以及我们遇到的这些问题，问题并不在于更改的大小，而在于反馈的及时性。当你看到那些一直在运行并持续生成代码的代理时，这真的给我们的软件交付模型带来了问题。在我们的脑海中，我认为这些过程被建模为线性和离散的过程。你推送代码，然后构建，然后测试，然后部署。如果你曾经在 CI 流水线中工作过，你就知道大多数流水线比这复杂得多。

你希望尽早失败。你希望在运行昂贵的集成测试之前先运行代码检查器。如果代码甚至无法编译，那就没有意义去运行这些测试了。我认为在我们的脑海中，这种思维模型仍然是一个非常线性的过程。我认为这个模型在面对 AI 时并不成立。当你创建这些大而慢的流程时，你实际上限制了你的吞吐能力。对于一个并行系统来说，最糟糕的事情就是强制所有工作都通过一个串行的流水线。这根本行不通。

我认为这将走向一个非常前瞻的方向，关于是否应该取消 CI 的讨论已经有很多了，这里有一个想法是，很多这些事情实际上并不需要在时间上是线性的。宇宙中并没有一条基本定律规定 PR 审查或代码审查必须在代码部署之前进行。有很多合规规则规定必须这样做，这些规则很重要。但这并不是软件交付的基本事实。没有任何东西规定一个已经通过所有单元测试的已签名 Git 提交，其内容和测试结果不能由开发人员在本地或云端运行并确认为通过。

我们所做的每一件事都遵循同样的原则。你唯一需要做的可能就是推送代码。在某个时间点，代码必须被推送。我认为这种模式将这些非常线性的流程打破，这些流程原本是直线式的流程，现在转变成一种在时间进程的不同阶段发生各种事情的模式。这样，我们不再需要一个线性的“是-否”判断，而是将这些事情合并到一个单一的关卡中，我们只需要跟踪发生了什么。你真的还需要什么？对于持续交付来说，如果测试通过了，你就应该部署代码。除此之外的其他事情，其实都是我们对其他事情的担忧，而这些担忧其实是因为我们对测试缺乏信心。因此，我认为越来越多的努力和精力将投入到测试和验证层，而不是去思考我们服务低层细节的具体设计。

Chunk by CircleCI

现在，就像CircleCI的许多同事一样，我们正试图将过去六个月到九个月中获得的这些经验总结并打包起来。正如我所说，比如测试影响分析、易出错测试分析、改进代码审查流程等。这些都是有趣的练习，但可能不是最有效率的练习。我们正在开发的一个代理叫做Chunk。Chunk的理念是将我们内部获得的所有经验真正地整合起来。如何让模型写出高质量的代码？如何让模型以符合你组织标准的方式审查代码？然后，如何保持交付管道的快速，以便代理能够尽可能快地编写代码，并将其付诸实践，最终将所有内容整合在一起？

当我们谈到Chunk时，这里的理念是它首先注重验证。对我们来说，你定义为足够好以用于生产环境的规则，就是我们对自己设定的标准。我们正在构建这个系统，以确保你的软件随时可以投入生产。从易出错的测试开始，逐步过渡到拥有正确的测试和适当的覆盖率，当然，我们也会在过程中不断学习。CI系统的一个好处是它知道你何时破坏了东西。我们知道你何时合并了代码，何时回退了，何时回滚了。

查看更多带有文字稿的演讲

录制于：

2026年6月26日

由

• Michael Webster

#### 相关赞助商

• 代理AI堆栈中缺失的一层：为什么AI应用需要持久会话

#### 相关赞助商

使用Ably AI Transport。专为整个代理到用户体验打造的基础设施。立即开始构建。

#### 本内容属于AI、机器学习与数据工程主题

##### 相关主题：

• AI、机器学习与数据工程

• QCon AI 2025

• 文字稿

• 软件开发生命周期

• 人工智能

• QCon软件开发会议

• 软件开发

• InfoQ

• 相关编辑

• 在 InfoQ 上广受欢迎的 Anthropic 领导：HTML 在保持人类在代理循环中的参与度方面正变得比 Markdown 更加出色 AWS 推出 Blocks，这是一个专为 AI 代理构建后端而设计的开源 TypeScript 框架 Anthropic 报告称 Claude 现在处理了 95% 的内部分析查询 Google OpenRL 是一个用于大语言模型后训练微调的实验性自托管 API Java 新闻综述：Spring Tools、Helidon、Open Liberty、TomEE、JobRunr、Hibernate、Commonhaus 如何通过 eBPF 在安全且不干扰的方式下，让开发者观察 Linux 内核内部情况