本文翻译自 Beyond Agentic Coding，原载于 Haskell for All 博客。

前言

总的来说，我非常支持 AI，但在一个主要领域上是个例外：Agent 编程（agentic coding）。

我一直以来的印象是，Agent 编程并没有真正提高生产力，反而降低了用户对代码库的熟悉度和舒适感。这个印象来自三个方面：

• 个人经验：每次使用 Agent 编程工具，我对结果质量都不满意。
• 面试经历：我允许候选人使用 Agent 编程工具，但使用这些工具的候选人的表现更差——要么无法完成挑战，要么产生错误结果。这让我很意外，因为我原以为 Agent 编程会给他们带来不公平的优势，但结果并非如此。
• 研究文献：Becker 研究和 Shen 研究表明，当你用固定结果而非代码速度/数量来衡量生产力时，Agent 编程用户的表现并没有更好，有时甚至更差。

我并不认为 Agent 编程是一条死路，但我相信当前的 Agent 编程形态对软件开发弊大于利。同时，我也认为继续改进 Agent 编程的不足是值得的，这样它才能真正赋能开发者并提高代码质量。

不过，本文我要换个角度：我想提出其他利用 AI 进行软件开发的方法。我认为 Agent 编程已经如此占据了公众的想象力，以至于人们忽略了其他良好的、未被充分探索的 AI 辅助软件开发解决方案。

主导原则

我喜欢从第一性原理设计工具和界面，而不是对行业趋势/炒作做出反应。在 DevProd 领域工作了十多年，加上更长时间的开源项目贡献经历，我积累了一些通用的设计原则。

其中之一是我的个人”主导原则”：

一个好的工具或界面应该尽可能长时间地让用户保持心流状态

这个原则甚至不特定于 AI 辅助软件开发，但仍然突显了 Agent 编程为什么有时会偏离目标。研究和开发者证言都表明，Agent 编程会打断心流，让开发者比普通编程时更多地处于空闲/可中断的等待状态。

例如，Becker 研究录制了屏幕，发现空闲时间大约增加了一倍。

我相信，如果我们将北极星设定为”保持心流状态”，我们就能改进 AI 辅助编程工具（无论是 Agent 还是其他类型）。

冷静技术

冷静技术（Calm Technology）是一个在我们构建的工具中促进心流状态的设计学科。与编程最相关的设计原则是：

• 工具应该最小化对我们注意力的需求

  打断和侵扰我们的注意力会让我们脱离心流状态。

• 工具应该被构建为”通透”的

  工具不应该成为我们注意力的对象；相反，工具应该揭示我们注意力的真正对象（工具所作用的事物），而不是掩盖它。我们使用工具越多，工具就越应该淡入我们意识的背景，同时仍然支持我们的工作。

• 工具应该创造并增强平静感（因此得名：冷静技术）

  平静状态有助于用户进入并维持心流状态。

非零样本的冷静技术示例

工程师已经在工作中使用”冷静”的工具和界面，这里有几个你可能已经熟悉的例子：

内联提示（Inlay Hints）

IDE（如 VSCode）可以支持内联提示，在代码中散布有用的注释，例如推断的类型注释：

function greet(name: string) {
  // name: string
  return `Hello, ${name}!`;
}

这些类型的内联提示体现了冷静设计原则，因为：

• 它们最小化对我们注意力的需求

  它们存在于我们注意力的边缘，如果我们感兴趣就可以看到，如果不感兴趣也不显眼。

• 它们被构建为”通透”的

  它们不替代或替换我们正在编辑的代码。它们增强代码编辑体验，但用户仍然直接接触被编辑的代码。我们使用类型提示越多，它们就越淡入我们意识的背景，代码仍然是我们注意力的焦点。

• 它们创造并增强平静感

  它们通过被动地告知我们对代码的理解来促进平静感。正如冷静技术原则之一所说：“技术可以沟通，但不需要说话”.

文件树预览

VSCode 或 GitHub 的拉取请求查看器等工具可以让你一目了然地预览文件树的变化，像这样：

你可能想”这是一个非常无趣的例子”，但这正是重点。最好的工具（用冷静技术原则设计的）是我们认为是理所当然的、普遍存在的无聊东西（比如电灯开关），它们已经如此强烈地淡入我们注意力的背景，以至于我们忘记了它们作为日常工作流程的一部分而存在（也像电灯开关）。

文件树预览：

• 最小化对我们注意力的需求

  如果我们需要这些信息，它们就在那里；如果我们不使用，也很容易忽略（甚至忘记它们存在）。

• 被构建为”通透”的

  当我们与文件树查看器交互时，我们直接与文件系统交互，表示（查看器）与现实（文件系统）之间的交互感觉直接、快速、精确。我们使用查看器越多，表示在我们的脑海中就越与现实难以区分。

• 创造并增强平静感

  我们不需要不断与文件树交互来收集项目结构的最新信息。它在我们对项目进行更改时在后台被动更新，这些更新不打眼、不抢注意力。

基于聊天的编码 Agent 不够冷静

我们可以通过同样的视角来思考基于聊天的 Agent 编程工具的局限性：

• 它们对我们的注意力提出很高要求

  用户要么坐着等待 Agent 报告，要么做其他事情并以半自主方式运行 LLM。然而，即使是半自主会话也会阻止用户进入心流状态，因为他们必须保持可中断状态。

• 它们没有被构建为”通透”的

  聊天 Agent 是一个高度中介的代码界面，它是间接的（我们更多地与 Agent 而非代码交互）、缓慢的（我们花费大量时间等待）和不精确的（英语是一个钝化的界面）。

• 它们破坏平静感

  用户需要不断刺激聊天来收集新信息或更新对代码的理解（聊天 Agent 不会被动或安静地告知用户的理解）。聊天 Agent 也经过微调以最大化参与度。

冷静设计的先例

GitHub Copilot 的内联建议

最早的开始体现冷静设计原则的 AI 编码助手示例之一就是元老级 AI 助手：GitHub Copilot 对内联建议的支持，有一些我需要说明的注意事项。

它有一件事做得很好：

• 被构建为”通透”的

  用户仍然直接与代码交互，建议相当快速。用户也可以忽略或直接输入覆盖建议。

然而，默认情况下，这些内联建议违反了其他冷静技术原则：

• 它们要求我们的注意力

  默认情况下，Copilot 相当频繁地展示建议，用户必须暂停他们正在做的事情来检查建议的输出。经过足够多次后，用户开始将自己条件反射为定期暂停并等待建议，这让他们脱离心流状态。现在用户不再是主动的，而是被工具训练为被动的。

• 它们破坏平静感

  GitHub Copilot 的内联建议界面视觉上繁忙且侵入性强。即使用户忽略每个建议，效果仍然是破坏性的：建议出现在用户屏幕的视觉焦点中心，用户必须在决定接受或忽略之前当场决定，然后才能继续进行。用户也无法容易地被动吸收以这种方式呈现的信息：理解每个建议需要用户的专注注意力。

…但是这些问题部分可以通过禁用自动建议并要求通过 Alt + \ 显式触发来修复。然而，不幸的是，这也会禁用下一个功能，我更喜欢它：

下一次编辑建议（也来自 GitHub Copilot）

下一次编辑建议是相关的 GitHub Copilot 功能，它在整个文件/项目中显示相关的后续编辑，并让用户在它们之间循环，并可能接受每个建议的更改。它们的行为像一个”超级查找和替换”：

这些建议在让用户保持心流状态方面做得非常出色：

• 它们最小化对用户注意力的需求

  用户的认知负荷比内联建议更小，因为建议更可能是小批量的（因此更容易让人类审查和接受）。

• 它们被构建为”通透”的

  就像内联建议一样，下一次编辑建议仍然让用户与他们正在修改的代码保持密切接触。

• 它们创造并增强平静感

  建议以一种不打眼的方式呈现：它们不会倾倒在用户注意力的正中心，也不要求立即审查。它们存在于用户注意力的边缘，作为代码建议，用户可以忽略或随意关注。

AI 辅助的冷静技术

我相信 AI 辅助编程工具中有大量未开发潜力，在本节中，我将概述几个小例子，说明我们如何在构建下一代编程工具时体现冷静技术设计原则。

基于方面的项目导航

你可以通过语义方面的树来浏览项目。例如，如果你正在编辑 Dhall 的 Haskell 实现，树查看器可能看起来像我 hacked up 的这个原型：

这里的目标不仅是提供一种按意图快速探索项目的方法，而且在用户越多使用该功能时提高对项目的理解。”字符串插值回归”比 dhall/tests/format/issue2078A.dhall 有用得多。

另外，上面的视频是基于真实的工具，而不仅仅是模拟。你可以在这里找到我用来生成那棵语义方面树的代码，我很快会写另一篇文章来解释那段代码是如何工作的。

自动提交重构

你可以获取一个编辑器会话、差异或拉取请求，并自动将其拆分为一系列更集中的提交，这样人们更容易审查。这是 AI 可以减少人工审查劳动的情况之一（大多数 Agent 编程工具创造更多的人工审查劳动）。

这里有一些先例，但这仍然是一个新兴的发展领域。

文件透镜

你可以向用户的工具栏或上下文菜单添加两个新工具：“专注于…“ 和 “编辑为…“.

“专注于…“ 将允许用户指定他们有兴趣更改的内容，并仅显示与其指定兴趣相关的文件和代码行。例如，如果他们想专注于”命令行选项”，那么编辑器中只会显示相关的文件和代码行，其他代码行将被隐藏/折叠/收起。这基本上就像”禅模式”，但是针对感兴趣的功能领域。

“编辑为…“ 将允许用户编辑文件或选定的代码，就好像它是不同的编程语言或文件格式。例如，不熟悉 Haskell 的人可以”像 Python 一样”编辑 Haskell 文件，然后在完成编辑后，AI 尝试将其更改反向传播到 Haskell。或者，修改命令行解析器的人可以”像 YAML 一样”编辑文件，并被呈现命令行选项的简化 YAML 表示，他们可以修改它来添加新选项。

结论

这显然不是想法的详尽列表，我写这篇文章是为了鼓励人们思考除了构建另一个聊天机器人之外，将 AI 融入人们工作流程的更多创新方式。我坚信聊天是 LLM 最无趣的界面，AI 辅助软件开发也不例外。

核心要点

1. 当前的 Agent 编程工具问题：研究表明，它们实际上降低了开发效率，增加了开发者的空闲时间，打断心流状态。

2. 心流状态是关键：好的编程工具应该让开发者尽可能长时间地保持专注和心流状态，而不是不断地中断和等待。

3. 冷静技术的三大原则：
   • 最小化注意力需求
   • 设计为”通透”的（让代码成为焦点，工具淡入背景）
   • 创造和增强平静感

4. 现有好例子：内联提示、文件树预览、GitHub Copilot 的下一次编辑建议都体现了冷静设计。

5. 未来方向：基于语义方面的项目导航、自动提交重构、文件透镜等工具比基于聊天的 Agent 更有潜力。

6. 重新思考 AI 辅助开发：聊天界面可能是 LLM 最无趣的应用，我们需要探索更多创新的、不打断开发者工作流程的 AI 辅助方式。

个人思考

这篇文章对当前 AI 编程工具的批评非常到位。我们确实过度关注了”聊天”这种交互方式，而忽略了开发者真正的需求——在不被打断的情况下获得帮助。

“冷静技术”这个概念给了我很大启发。最好的工具往往是那些你意识不到它们存在的工具，就像电灯开关——你需要时它就在那里，但不会占据你的注意力。

下次当你觉得被 AI 编程工具打断心流时，不妨想想：如果这个工具更”冷静”一点，它应该怎么工作？是被动地提示而不是主动地弹出？是在边缘等待而不是占据中心？是增强而不是替代你的理解？

这些问题的答案，可能就是下一代 AI 辅助开发工具的方向。