Presentation: The Ironies of A^2 I^2

[InfoQ 首页](https://www.infoq.com/ "InfoQ 首页")[演讲](https://www.infoq.com/presentations "演讲")A^2 I^2 的讽刺

查看演示文稿

速度：

45:16

/presentations/automation-incidents-ai/en/slides/Paul-1779367646199.jpg)

摘要

J. Paul Reed 讨论了"自动化的讽刺"——一个 40 年前的概念现在被 AI 放大了。他解释了高级系统如何常常使人类操作员变得更加重要，而不是更不重要，同时却降低了干预所需的技能。通过分享"AI 驱动的"事故真实故事，他分享了过度依赖 AI 如何使恢复时间翻倍，以及如何保持韧性。

简介

J. Paul Reed 从构建/发布和运维工程师开始他的职业生涯。在创办了一家成功的精品咨询公司后，他现在担任 Chime 的高级事件运营经理，专注于事件响应、分析和系统性风险识别。他曾与 VMware、Mozilla、Symantec 和 Netflix 等组织合作过。

关于会议

软件正在改变世界。QCon 旧金山通过促进开发者社区中知识和创新的传播来赋能软件开发。作为一个实践者驱动的会议，QCon 专为技术团队负责人、架构师、工程总监和项目管理者设计，他们在团队中影响着创新。

INFOQ 活动

• /filters:no_upscale()/sponsorship/eventsnotice/1302f11a-f90f-4a79-96d1-3dd20d032144/resources/1HarnessWebinarMay28-Transcripts-1776246863928.png)2026年5月28日，下午1点 EDT

#### 更快交付，更多故障：重新思考 AI 时代的交付系统

演讲者：Eric Minick - Harness 公司 DevOps 解决方案高级总监，Aaron Newcomb - Harness 公司高级产品营销经理

• /filters:no_upscale()/sponsorship/eventsnotice/34b23b6d-548d-473c-9ac7-ec2f8ca684b1/resources/1GuardsquareWebinarJune11-Transcripts-1777545596301.png)2026年6月11日，上午10点 EDT

#### 重新思考应用安全：为什么编译器级别的安全性改变了架构对话

演讲者：Anton Baranenko - Guardsquare 产品经理

• /filters:no_upscale()/sponsorship/eventsnotice/7dd71c7c-4b0e-4760-b97d-232ac1816637/resources/1NeuBirdWebinarJune25-Transcripts-1777458459989.png)2026年6月25日，下午1点 EDT

#### 为自主可靠性而架构：将 AI 嵌入到您的可观测性堆栈中

演讲者：Justin Griffin - NeuBird AI 产品负责人

• /filters:no_upscale()/sponsorship/eventsnotice/0b46c1f1-7263-457d-82d9-12be6fa07fbd/resources/1DatadogWebinarJuly9-Transcripts-1779204853394.png)2026年7月9日，中午12点 EDT

#### 重新思考 AI 分析时代的日志

演讲者：Nicolas Jung - Datadog 日志产品经理

转录

J. Paul Reed: 项目手册上印了这次演讲的标题，所以我想实际解释一下。这些插入符号应该是下标，就像自动化讽刺的 A 平方，I 平方，或者 AI 平方，这扩展为事故中自动化和人工智能的讽刺。我们将讨论自动化和 AI，以及它们如何出现在事故中。正如我所说，我们所说的自动化讽刺是什么意思？今天我们要谈什么？自动化讽刺，我指的是什么？这与 AI 有什么关系？我们所说的 AI 讽刺是什么意思？我承诺过事故故事时间，所以我们会有事故故事时间。我们会稍微谈谈 ETTO。然后我们以这个结束：这一切可能很有趣，现在我们用这些东西做什么？对我来说，实际上，我很好奇，谁是开发者？谁是运维、SRE、平台工程师？谁在值班轮换中？谁现在正在值班？

我想指出的一件事是人因工程和系统安全硕士。我提到这个的原因不是为了炫耀。我们要谈论的是我们学习的一些关于人因工程和系统安全的内容。有趣的是，越来越多的软件人员进入那个项目。我的同学是飞行员、护士、医生和空中交通管制员，当我说我在软件行业工作时，他们笑了。他们说，为什么那是一个安全关键系统？我想你们都知道为什么它可能是一个安全关键系统。我想起几周前的 AWS 故障，我们看到世界的部分区域、整个互联网的部分都崩溃了。我们都知道安全在这里的重要性。这里有趣的一点是，我们也关注这些系统中的人因工程和人为因素。你们所有人，在这些系统中的我们所有人。

自动化的讽刺

自动化悖论，我们指的是什么？我将深入探讨一些已识别的自动化悖论，然后我们会讨论这些概念的来源，这些悖论想法的起源。第一个是，当技能不被使用时，手动技能会退化。这看起来很直观。这个想法是，如果我负责操作一个系统，但后来我引入了一些自动化，我不再使用那些技能，那么它们会随着时间推移而退化。你们可能都有过这样的经历：你自动化了某些东西，然后在事故中，你必须回到它，比如"我忘记了这个命令的参数"或诸如此类的事情，然后你不得不去查找。这是第一个。

第二个是，生成新策略需要对系统有充分的了解。当我们谈论新策略时，我们指的是，同样是在事故上下文中，或者甚至在开发新功能时，比如新的策略，新的做事方式。这要求我们对工作系统有足够的了解，才能推理、思考并提出这些"新策略"。这是自动化悖论中的第二个讽刺。这是一个很长的引述，我会读出来然后解释。有人担心，当前一代由前手动操作员监控的自动化系统，正在依赖他们的技能，而后续几代操作员不可能期望拥有这些技能。

在我们的世界里，随着时间推移，一个有趣的事情可能是如果你把编译器视为自动化，还有谁写汇编语言吗？也许有些人会写，但我们大多数人都不会。这个想法是，当我们向系统引入自动化时，我们必须继续培养人们监控该自动化的技能集。我们必须让我们的初级工程师做这件事，否则我们会让他们处于准备不足的情况中。也许如果我们搬到别处或退休，我们可能会有一群对自动化较新的人员，他们可能没有我们在安装时拥有的熟悉度，因为他们习惯了它正常工作。

其中一个悖论是我们告诉人们只需运行操作手册。我们可能在事故中说，只需运行操作手册，没关系。一个有趣的事情是我们让人们处于某种情况并告诉他们遵循指令，但我们让他们处于那种情况的原因是为了提供专业知识。在事故中，我们说"坏了，你知道怎么修复吗？"他们说"我真正知道如何做的唯一事情就是运行操作手册。"这本身就是一个有趣的悖论。我喜欢这个，这是一个非常关键的点。自动化需要在速度与正确性之间做出权衡。

当我们自动化事物时，这适用于制造业，也适用于软件，当我们构建汽车时，比如建造得更快，我们实际上无法检查从生产线下来的每一辆汽车以确保它是100%正确的。这个悖论让我们进入统计学和我们生产事物的统计正确性领域，无论是软件，还是小部件。随着我们提高速度，我们只能开始验证可接受性。我们开始考虑，这不是对错问题，而是"它是否在这个可接受性能范围内，可接受的小部件范围内，可接受的服务范围内，我们在软件架构中部署它们？"关键是，我们不能两者兼得。我们不能断言正确性的同时拥有高速度。这个主题会再次出现，我们也会在这次演讲中再次回顾。

自动化可以掩盖当前系统的状态。实际上有很多航空例子，你有一个自动驾驶仪正在微妙地纠正飞机的一些问题。你告诉自动驾驶仪"我希望你这样直线飞行"，也许方向舵有问题，机械问题。它会在其容差极限内尝试保持飞机直线飞行，并会增加方向舵的偏转直到达到其限制。通常这里有一个设计限制。有许多事故，包括导致人员死亡的事故，其中自动驾驶仪因为超过了限制而关闭，突然飞机剧烈地向一边或另一边偏转，因为自动化掩盖了存在问题的事实。

对于操作员来说有趣的是，飞行员们从一个对他们来说一切看起来都正常的情况，突然变成了远远超出容差，完全进入危险情况。我们可以在我们的系统中看到这一点，比如自动扩展，或者我们实施的自动修复措施来扩展事物。你可能见过这种情况。自动扩展是我最喜欢的之一，因为亚马逊会为我们扩展这些服务，也许它没有考虑到这会为下游服务创建雪崩效应或其他类似性质的问题。这也是一个有趣的要点。这是我最喜欢的之一。自动系统应该失败，显然。我对这个的反应是"真的吗？这是个悖论。"有趣的是值得明确地说出来，因为自动系统有时会以不明显的方式微妙地失败。这本身就是个悖论，当我们构建自动化时，我们并不总是构建完整的方式来告诉我们它在通往失败的路上处于什么位置，或者距离潜在失败有多近。

这在今天非常适用，追踪算法做出的决策树可能很困难。这个想法是指当自动化正在做它正在做的事情时，我们来到现场试图理解它，因为发生了某些事情或者出了问题，我们很难弄清楚，自动化是如何从A点到达现在的T点的？它是如何到达那里的？因为我需要知道这一点，这样我才能知道如何让它回到A点，这可能是可接受的系统性能。现在有趣的是，今天这可能是不可能的。有了AI，我们可能无法知道那个决策树是什么，甚至可能根本不是一个树形结构。这可能非常不透明。另外，AI有趣的地方在于，你希望自动化是确定性的。就像if语句一样。

在AI中，这不一定是一个保证。这导致我们在被呼叫时无法完全理解当前系统上下文。对于那些在事件中值过班的人，都遇到过这个问题：你被呼叫了，你有一堆问题，因为我们云提供商中的各种自动化形式，以及我们设计的系统已经在你到达之前掩盖或尝试解决了正在发生的情况。除了实际的真实问题外，你还必须理解这些情况。你是否曾经在事件中问过自己或说过其中一些话？这是来自对飞行员和医生的研究。我不认为有人希望飞行员说，我如何阻止它做这件事？

我最喜欢的一个是，我知道有某种方法可以让它做我想让它做的事。那里有种希望。我知道它可以做到。我以前见过它做到过。这个自动化在做什么？所有这些自动化的讽刺都来自一位名叫Bainbridge的女士写的一篇论文。这篇论文的论点是，论文表明工程师对人为因素日益增长的兴趣反映了这样一个讽刺：控制系统越先进，人类操作员的贡献可能就越关键。如果你仔细看，可以在脑海中想一想，你认为这项研究是什么时候做的？多少年前？四十年前，是的，没错。这是1983年的研究。所有那些关于自动化讽刺的最后讨论中的内容，如果你认同它们，你会觉得，在事件中我有过那种感受，我们实际上已经思考这个问题整整40年了。

我想稍微谈谈联合认知系统，因为我们将使用的术语会回来，并且对我们的讨论有用。当我们谈论联合认知系统时，我们说的是通常具有某种边界形式的系统，该系统内有代理和参与者。当我们谈论操作员时，我们人类在做事，他们在联合认知系统中确定了一些我们可以做的事情。为了这个目的，让我们简单地说，就是我们人们在事件中一起工作。这是这里的人与人之间的互动。自主性，我们所说的自主性是什么意思？自主性意味着，很简单，我可以做一件事。我可以独立工作来实现一个目标。同样，对于双人系统，我们是自主的。权威，这意味着我在系统内有权做某事。这不是命令权威。更像是我可以拉这个杠杆，或者我可以转动这个开关，或者我可以输入这些命令。定向注意力。人类有定向注意力。

现在，你们的注意力，希望我足够有趣，是集中在我身上的。我们的注意力通常集中在一件事上，有很多关于大脑如何工作的研究。因为我们有定向注意力，所以我们也有重新定向的能力。这意味着如果我看到某人并且需要他们的帮助，我可以这样说："Lorin，我需要你的帮助。无论你在关注什么，你能过来和我一起关注这件事吗？"然后还有相互预测性的概念。表现非常好的团队有很好的相互预测性。典型的例子是如果你有一个非常好的朋友，你们能完成彼此的句子，你们都知道彼此的意思，而且你们不需要实际纠正你以为的意思，你们有很高的相互预测性。非常好的SRE团队和事件响应团队有很高的相互预测性，因为我可以预测我认为你在事件中会做什么，我可以以高信心度，80%、90%的正确率确信你会那样做。

让我们从自动化角度看看这个，也许也从AI角度看看。自动化当然有自主性。它可以自己做一些事情，而不需要我们告诉它去做。这就是我们构建它的原因。它当然有权威。我们需要给它权威去转换开关、部署东西和运行代码，否则为什么要有它呢？自动化没有定向注意力。我不能问自动化，你现在在关注什么？因为我不能这样做，这也意味着我不能停止自动化并说，那边的东西着火了，我需要你关注。你不能对自动化这样做。

然后，当然还有相互可预测性。这就是为什么当自动化出现问题时，它会违反我们以为拥有的任何相互可预测性。重要的是，这些最后三个要素——定向注意力、可重定向性和相互可预测性——是协调的基础。当我们谈论与团队协调解决事件时，所有这些认知工作都发生在这里。Dave Woods 是一位研究者，他从三里岛事故中成长起来，研究了该事件。他已经从事这项工作很长时间了。他在本次演示中会出现几次。我特别喜欢这句话："技术人员经常将连接性误认为是协调能力，连接不同方和数据源的能力并不等于协调。"然后我会再次回到这个区别：连接性与协调性的区别，它们不是同一件事。

我想带大家了解一下所谓的动画悖论，因为它对我们的讨论很有趣，但当我们谈论自动化时，它也可能引起共鸣——为什么我们在某些情况下对其感知会发生变化，为什么它是依赖于上下文的。随着自动化系统自主性和权威性的增加，人们对它们有两种解释。我们以两种不同的方式来理解它们。一种是将其视为确定性机器。我编写了这个脚本。我知道它会做什么。我已经运行了很多次。我可能做过一些错误修复。我可以预测它会做什么。它是确定性的。另一种解释是将其视为能够独立于操作员执行活动的有行动能力的代理。这两种解释有什么区别？其中一种解释是在特定上下文中的。

这个有行动能力的机器，这个正在做某事的自动化系统，而我不知道它在做什么，为什么它不停下来？为什么我不能重新定向它让它做其他事情？它在这个执行步骤列表中的哪个位置？这些问题出现在诸如事件处理、高节奏、高后果情况的上下文中。我相信你们都有过这样的经历，当我们去做事件响应时，发现当然脚本会这样做，它会调用那个功能。这不是高节奏的，也不是高后果的。我们是在事后考虑这个问题。是的，当然，它是一个确定性机器。我现在明白了。它不是一个能自己做事的奇怪有行动能力代理。我先告诉了你结论，但在这个例子中，上下文中的情况与事后回顾的区别在于这些高节奏、高后果的事件情况。在事件中，事物已经损坏，我们已经处于压力之下。我们试图掌控这种情况。这些代理，无论是自动化还是AI，往往看起来就像在四处乱跑，做着事情，而我不知道它们在做什么。我只是想让它们停下来，这样我才能掌控局面。这是 Bainbridge 在 1983 年提出的观点。很久以前，自动化的讽刺之处。

人工智能的讽刺

人工智能的讽刺。所有这些AI相关的内容，你们都知道总得有人来谈谈这个。Mica Endsley 是另一位研究者。她在情境意识方面做了大量工作。如果你知道什么是情境意识，她在这方面做了很多基础工作：这意味着什么？它是什么样子的？应该看到，40年后的今天，这是一篇非常新的论文，总结了AI的讽刺之处。这篇论文的论点是，AI可以被视为一种先进且可能更强大的自动化形式。但它对学习算法的依赖也为与这些系统交互的人们创造了额外的挑战。让我们谈谈她发现的那些讽刺之处。人工智能仍然没有那么智能。

至少在研究文献中，智能系统被定义为能够识别情况、适应变化、生成新颖问题解决方案并能够优化性能行为的系统。当数据集足够大时，机器学习在数据分析方面表现出色，但在面对新情况的部分存在不足。预测文本、预测模型预测的是它们之前见过的东西。这就是它们在做的事情。通常情况下，我们遇到的是新情况。我们可能依赖AI来给出答案。这里存在一个讽刺。此外，还指出基于机器学习的AI系统缺乏因果模型。同样，它们预测的是之前见过的事物。

它们在系统中因果关系模型的广泛性并不总是具备。我们拥有这种能力是因为什么？我们经历过很多事件。我们知道位于完全不同AWS区域的foo服务实际上会影响位于完全不同AWS区域的bar服务。AI越智能、越自适应，人们就越难理解系统。我知道我在AI方面遇到过困难。因为没有明确的逻辑规则或者它们不明显，AI存在这种不透明性。良好事件响应的一部分是拥有系统的心理模型，而许多AI工作模型都是不透明的。当你看到它给出答案时，你可以看到这种相互不可预测性：你会想，我知道它会给我什么答案，但它给出了完全不同的答案，这个答案也可能是错误的。

AI越强大，人们为补偿缺陷而进行自我调整行为的能力就越差。有趣的是，这是一个情境意识论证。一个很好的例子，现在你越来越多地看到，比如特斯拉自动驾驶。越强大的，比如说，特斯拉自动驾驶，我们就越容易分心，越少关注，情境意识也越少。这使得我们更难知道何时需要介入纠正AI，因为它正在做一些危险的事情。有趣的是，AI越强大，这个问题就越严重。

AI 越智能，它就越模糊，人们越难以确定其局限性和偏见，因此也不知道何时该使用它。稍后我们会在一些例子中更多地讨论这个问题，但这实际上关乎偏见。如果你关注很多 AI 相关的内容，就会知道 AI 模型是基于数据训练的，而数据可能存在偏见。当 AI 越来越多地这样做时，它会让我们更难判断：什么时候我应该更加质疑它？或者什么时候我应该说，实际上这并不是一个适合使用 AI 的场景？我认为这是我最喜欢的其中一个观点。AI 通信越自然，我们与 AI 交流的方式越自然，人们就越难理解 AI 的可信度。

我最喜欢的例子来自我的生活经历，这甚至成了一个梗：当你告诉 AI 它错了的时候，它会说"你说得完全正确"，好像对犯错感到非常兴奋。我不知道你们是否也有这种感受，但当我与人交谈时，如果我知道自己错了，我会感到有点难过，然后突然想与那个人深入聊聊："让我们多谈谈你掌握的那些正确数据吧。"而 AI 无论对错，都表现得极其自信。我知道现在你可以通过提示词等方式改变这一点，但是有一件事我想指出：通常人们依靠多种线索来判断信息的可信度有多高。在事故处理中，当工程师说"我觉得我们应该这样做"时，这与"我觉得我们应该这样做"（带有不同语调）是有很大区别的。当我们阅读 AI 生成的内容时，无论是它冷冰冰的声音还是文字，我们都在推断语气，人类就是会这样做。我们失去了关于 AI 可信度的重要信息。

事故故事

现在讲事故故事时间。我需要指出的是，这些案例都是众包收集的，所以如果你认为这些都是我个人亲身经历的事故，那你就错了。事实上，我们这些从事故中学习的人聚在一起，讨论你们所有人遇到的各种事故，就像在分享八卦一样。以下是一些来自各种来源的 AI 相关事故。我很喜欢这个例子，这是关于 Claude 的。指令是："你能为这个字符串添加本地化吗？"红色线条是你需要注意的地方。"在修改短语之前请先确认一下。"AI 说："好的，我要使用 Nabu 本地化代理来完成这项工作。"这是一个 Claude 代理的例子，然后子代理在我的代码库中执行操作。作为操作员，我告诉 Claude："我需要你做一件事，但在做之前先确认一下。"Claude 说："明白了，很好，要去执行了。"我需要做的是子代理，所以我去做这件事。

然后，Claude 在代理完成工作后代表我说："是的，看起来完美，可以提交了。"我告诉 AI 要先跟我确认，而 Claude 说："我听到了，但我要启动一堆代理，然后告诉他们没关系，对你来说没问题。"让我觉得有趣的是，人类一般不会这样做。如果我们一起解决问题，我说"没人碰按钮"，通常我们中的一个人不会说"他说不要碰按钮，但你可以去碰按钮，没关系"。这导致了一起事故。这些是按顺序排列的。这像是事前事故。这是在事故中。这里的背景是我们有两个部署的服务提供相同功能，我们正在用不同语言进行迁移。它们用不同的语言实现。两个都已部署。一个是 Java，一个是 Go。

Go 服务没有实现某个边界情况，所以留下了一些未标记的数据，这造成了一些问题。AI 被要求将相关的 Java 代码移植到 Go。不是全部代码，而是"这是功能，你能找到它吗？"是的，很好。把这个移植到 Go。这是一个很具体的问题。我以为 AI 应该很擅长这种任务。旁白：AI 实现的代码引发了另一起事故。它们拿了代码，AI 提交并部署了 Go 版本。又引发了一起事故。AI 实现的代码不包含单元测试，因为忘记要求了。响应者很难进行代码审查，而且他们专门使用 AI 是因为他们不懂 Go。编写该服务的人早就离开了。拥有该服务的团队几乎没有 Go 知识。

正如我提到的，又引发了另一起独立的事故，需要额外的清理工作。可能将事故持续时间增加了两到三倍。这是一个持续数天的事故。这是我的评论。可能，这是一个反事实。我无法证明这一点。我能告诉你的是，服务被部署了两三次，然后由于部署 AI 代码产生的问题，额外的补救工作花了几天时间。这是一个我原本以为"把这段 Java 小片段移植到 Go"很完美的例子，但也许并非如此。

第三个事故。这是一个关于摘要的通用类别。这是 Slack，遮挡的部分是姓名。"某某，确认一下，你和某某都在离席状态，应该在 7:40 回来。"这是在事故 Slack 频道中。这个人并没有请求这个。AI 就这样闯入了。"我在你的公司知识库中搜索，并在此线程中私下向某某分享了一个建议。"你想知道建议是什么吗？是的，姓名和姓名都在离席状态，应该很快回来。谢谢你，AI。真是太有用了。

我提出这个具体例子是因为我们现在有了 AI 代理。不是说有人决定让 AI 代理进入我们的事故 Slack 频道。而是一家公司，他们有一个工具，就是那种吞噬一切的工具，Confluence、Jira、Slack，所有的一切。它突然出现在一个事故中，就像，让我变得非常无用，同时也会分散你的注意力。这很有趣。也许有人有过这种经历。同样，这又回到了 AI 的语境下，定向注意力，可重定向性。我在 AI 方面最喜欢的词就是可重定向性。有多少次你说过，AI，你搞错了？就像，好的，不错。然后它又吐出一个更错误的建议。你还是错的。现在，有时候，如果我真的很无聊，我会继续找各种方式告诉它它是错的，只是想看看它会提出什么，因为我很无聊。

ETTO

让我们稍微谈谈 ETTO。什么是 ETTO？ETTO 是 Erik Hollnagel 博士在 2009 年创造的一个术语。代表效率-彻底性权衡（Efficiency-Thoroughness Trade-Off）。这是一个关键点，人们、个人和组织，在他们的活动中，必须在资源上做出权衡，主要是花在准备做某事上的时间和精力，以及花在实际执行上的时间和精力。如果安全和质量是主要考虑因素，权衡可能会倾向于彻底性而非效率；如果吞吐量和输出是主要考虑因素，则会倾向于效率而非彻底性。我认为这里的关键点是，你不能同时最大化效率和彻底性。总是一个权衡。你必须拥有两者的最低限度才能完成有用的事情。

我想说的是，应对事故的响应者，关于效率的赌注已经为他们做出了，无论是他们自己做出的还是组织自己做出的。因为他们处于事故中，他们已经输了这场赌局。钱已经没了。你输了。当你进入一个事故，你的第一个想法是，我打赌 AI 能解决这个问题，或者自动化能解决这个问题，你又在赌效率，而你已经输掉了那场赌局。这是值得思考的事情。

现在怎么办？

现在怎么办？你可能在想，Paul 讨厌 AI。我不是讨厌 AI。我想非常明确这一点。这不是一个关于 AI 很糟糕我们永远不应该使用它的演讲。我认为我们在事故背景下必须问自己的当前根本问题是，鉴于我们现在所处的位置，AI 在事故中的适用性如何？关于如何推理这个问题的一些想法。我想谈谈这个。这是非常近期的。你会看到日期，2025年7月15日。你会看到 Dave Wood 的名字和其他一些研究人员。他们做了一个非常有趣的研究我们要讨论，但 AI 如何在高风险环境和事故中降低人类表现。他们做了另一个研究，询问开发者，你觉得更有生产力吗？

他们基本上发现，即使开发者认为他们完成任务的速度快了 20%，但实际上使用 AI 完成任务的时间却长了 19%。有趣的是，这项研究实际上是针对护士的。他们的发现更加细致。他们发现当 AI 预测最准确时，这是对护士的研究，护士的表现比没有 AI 时好了 53% 到 67%。很好。这很好。然而，当 AI 预测最具误导性时，那些护士的表现比没有 AI 辅助时差了 96% 到 120%。这里的要点是，当它好的时候，它只是稍微好一点。它会有帮助。它在推动进展。当然，53% 很棒。那很棒。当它不好的时候，可能会非常糟糕。让我们处理自动化悖论。

我们必须做的其中一件事是参与培养购买时间能力的实践。我所说的购买时间是什么意思？在事故中，我们想要有策略给我们更多操作空间，给我们更多时间来思考问题，让我们能够彻底处理。我们如何做到这一点？模拟、仿真、混沌工程演练日，诸如此类的事情。这允许我们在事故中练习策略，以便在事故环境中随时调用。扩大系统理解。这就是全部内容。你听过很多关于心理模型的讨论。在事故响应方面最优秀的个人和团队对他们所工作的系统有着非常广泛的心理模型。

我认为 AI 的诱惑之一是，AI 有模型，所以我不需要把它记在脑子里。或者对初级工程师来说更糟糕的是，我会看 AI，所以甚至不需要建立心理模型。这实际上是对的。我们仍然需要那些心理模型，因为我们需要能够在 AI 的心理模型实际上错误并且在幻觉时告诉它。从自动化角度来看，在设计自动化时要考虑时间压力因素。有几种方法可以做到这一点。寻找在时间敏感情况下实际上可以放慢自动化速度的方法，这为你赢得了时间。通常你不会想这样做，但在某些情况下你可能会这样做。

让我们谈谈 AI 悖论，我们如何处理这些。支持人类互动和监督。这些目前还很初步。如果我们有代理在系统中运行。通常很难获得那些代理可能在做什么的监督，特别是在事故环境中。交互模型也还很初步。都是基于文本的，基于提示的。我也很喜欢的是，当我像你们希望的那样用 AI 做事情时，我说，它不起作用。他们说，问题是你的问题。提示错了。我说，好的。在这方面我们还有工作要做。归因。

AI 系统必须明确标识为 AI 系统和机器人。在事件处理中，我需要知道信息是来自人类还是 AI。不是因为哪一方更好或更差，我只是需要知道这一点，这样作为事件协调员（这也是我的日常工作），我才能理解自己面对的是什么情况。可解释性。AI 系统必须配备可解释性功能，让与之交互的人能够理解 AI 的能力和局限性。这就是我之前提到的培训和技能保持的问题。人们进入事件处理现场并开始使用 AI 的次数很多，这很有趣。没关系，但在可能每分钟损失 1000 美元的时候练习你的提示工程可能不是最佳时机。这些都不是假设的情况。同样，LFI Slack 中有很多有趣的事件案例。

从韧性工程的角度来看，ETTO 是效率-彻底性权衡，TETO 是彻底性-效率权衡。让我们总体上变得更高效的因素是，在某个时刻存在彻底性的组成部分。正是这种天平来回摆动。因为我们是不同的参与者，这意味着我们实际上可以帮助 AI 成为这种天平的效率臂，而我们利用节省的时间变得更加彻底，这样当彻底性成为我们工作的重要方面时，我们作为人类操作员具备响应和预见的能力。我想谈的关于处理 AI 讽刺现象的最后一部分是人机联合测试。这是一个新领域。许多人体因素专家正专注于这种联合活动测试，这实际上就是它的名称。我要给你们展示一个非常有趣的图表。这是来自护士研究的数据。基本上，x 轴是 AI 错误的幅度。越靠右表示错误越多。

然后 y 轴是任务复杂度。那里的三列中，第一列仅是 AI 推荐。第二列是 AI 推荐和 AI 与人类操作员之间的解释。第三列仅是 AI 解释。如果你观察这个图表，会发现当 AI 仅提供 AI 解释时结果更好。当它用作收集数据的代理，当你用它来重新引导自己的注意力时，但当你依赖它进行推荐，特别是当你仅依赖推荐和结论时，那些是左侧出现下降趋势的图表。右侧第三列是你仅获得解释的情况。随着事情变得越来越复杂，性能曲线的分歧程度不会那么大。

关键要点

我谈了很多内容。如果你从这次演讲中只记住一件事作为事件协调员，这就是我对你的请求。请帮助你们友好的事件协调员。如果你要在事件中使用 AI，请让他们知道。请让他们知道你在使用它以及你用它做什么。原因是有些事件花费了很长时间才解决，花了几天时间，因为团队正在使用 AI 编码解决方案。我可以保证，在那种情况下，如果事件指挥官知道团队正在使用 AI，他们本会调动更多资源，可能会找到懂 Go 语言的人来解决那个问题。如果你在事件中使用 AI，请让你身边友好的事件指挥官知道。

问答环节

参与者 1：我会总结你列出的大部分讽刺现象，或者实际上是你整个演讲，使用 AI 越多，你的技能退化越严重，你判断其输出的能力越强，但你对实际在做什么的理解却越来越少。这是个好的总结吗？关于如何激励人们在不需要再次手动完成实际体力工作的情况下修复这个问题，有什么研究吗？因为那样就违背了使用 AI 的初衷。

J. Paul Reed：就演讲总结而言，比刚才给你的更广泛的要点是，有很多我认为是无节制的 AI 热情。有很多情况下我认为它表现得并不特别好，但我们想到它表现良好时会获得很大的多巴胺刺激。如果我们正在编码，我们在感觉编码，我们在做周末项目，就像擦亮汽车一样，或者其他什么。那是令人愉快的。在事件操作、事件协调员工作的空间里，那不是做这件事的时间和空间。我希望围绕什么是使用 AI 的最佳场所以及什么不是展开对话。此外，在专业环境中，当我们使用它时，我们应该如何为自己设置成功条件，当不能使用或不应该使用它时该怎么办？你们可能都听说过 AI 代码的代码审查。代码生成部分更快。然后审查部分变得更加重要，不仅是为了正确性，这样如果两周后在事件中出现问题，我作为人类对发生的事情和它一般在做什么有一个心理模型。从总结的角度来看，这就是我会如何总结它。

参与者 1：如果人们没有保持这些技能和理解的实际动机，因为所有这些都被委托给了 AI，我们如何让人们真正保持这些技能和理解？

J. Paul Reed: 这是个有趣的问题。你在问一个组织动力学问题，即我们如何激励工程师去关心一件我们同时又告诉他们不再需要关心的事情。我认为这就是实际上你在谈论激励机制的地方，但当我们谈到工程师的专业知识时，无论你是否意识到，你都在不断地做效率与细致之间的权衡，真正有趣的是在压力之下发生的情况。那就是我们利用自己的经验和专业知识，比如"那件事结果不太好"，来实际讨论我们被激励去做什么。现在的一个笑话是代码生成，目前在我生活中，AI 对我生活的主要影响是更多的事故，因为我们在生成更多代码，我们现在正在与这些问题作斗争。我认为这就是人类专业人士的专长所在——当软件栈着火时，人们会叫这些人在燃烧的大楼里工作，这就是我们将如何改变那些激励机制，或者至少对它们进行更细致的对话。

参与者 2: 我在我的组织中看到一些事后分析和/或事故频道有 AI 总结。你有没有关于这方面出错的故事，以及人们如何仍然能够保留这种练习，继续详细地向事后分析或事故频道添加细节？

J. Paul Reed: 我已经多次进行过这种对话。实际上我在 QCon 这里也有过这样的对话。他们想用 AI 来生成回顾，生成事后分析文档。他们还想用 AI，比如我进入 Slack，我不想读全部内容，给我 AI 总结。这样做的主要问题是，Lorin、Molly 和我都有很多深度事故分析经验。当你做深度事故分析时，AI 只是在总结它能看到的内容。而事故分析是关于发现你看不到的、在发生过程中不可见的东西。我实际上采取了相当强硬的立场，因为我在进行这种对话，而我作为事故协调员的部分工作就是进行事故审查、事故报告和事故分析。他们说，是的，AI 做所有这些。我试图解释，这里有细微差别。

我有很多很好的事故故事，比如事故的发生不是因为某人去度假了，而是因为他们度假回来了。AI 不会告诉你这个。AI 无法弄清楚这一点。在这个对话的最后，那个人说，我其实并不关心事故审查。这些都只是我不想做的工作。我只想回去写代码。我们可以谈论这个问题。当我看到人们说"我只想用 AI 总结来做事故审查"时，是因为他们要么读过很多真的很糟糕的事故审查，其中有人时间匆忙，无论如何都在做总结。

当然，AI 可以做得更好，但你不会得到洞察。你不会得到学习，因为再次强调，总结是 AI 认为重要的东西，基于它出现频率的多少。那不是洞察。洞察是不同的。学习是不同的。此外，AI 无法向你的 CTO 提出论点，说明你应该投资或撤资于某项技术。我实际上说过，如果你把所有的事故审查都只用 AI 总结然后放在 Confluence 中就完事，那就别做了。没人会读它们。你没有真正写它们。没人关心。如果没人关心，为什么要做这项工作？那些做 LFI 并在组织中做这些工作的人，他们会就为什么要做这项工作进行非常好的对话，因为他们会有最好的故事，我可以保证 AI 永远永远抓不到的事故故事，因为它不知道要问这个问题。它不知道那是相关或有趣的，因为那都是美学和艺术，真的。

查看更多[带文字记录的演讲](https://www.infoq.com/transcripts/presentations/)

录制于：

2026年5月21日