开发者对工具的情感依附与AI时代工作流重塑

Trisha Gee 是一位开发者倡导者和 Java 冠军，拥有超过 20 年的软件开发经验。

你可以在 LinkedIn 和 X 上与 Trisha 联系。

恭祝用户 citelao 获得著名问题徽章，获奖问题是《VS Code SSH keeps dropping connections, but I can SSH just fine》。

Ryan Donovan：大家好，欢迎来到 Stack Overflow 播客，这是一个讨论软件和技术的地方。我是主持人 Ryan Donovan，今天我们将讨论 IDE 在 AI 时代中的地位。我今天的嘉宾是 Trisha Gee，她是 Java 冠军和开发者生产力倡导者。Trisha，欢迎来到节目。

Trisha Gee：感谢邀请。

RD：在我们深入讨论 IDE 之前，能否给我们分享一下你的背景，你是如何进入软件和技术领域的？

TG：随着年龄增长，这个故事变得越来越长。我走过的是一条相当经典的道路。我年纪相对较大，开始编程是在9岁左右，那是在80年代，就像我这一代的很多人一样，用 BASIC 开始的。然后我在16到18岁时学了计算机 A-level 课程，因为我来自英国。之后我读了计算机科学学位，专业是计算机科学与人工智能，那是在世纪之交的时候。当时的 AI 和现在完全不同。

RD：我那个时候也上过一门 AI 课。

TG：是的，完全不同。当时只有两种学派，一种是经典的基于搜索的 AI，另一种是现代的神经网络 AI。学习这两种不同的方法很有意思。幸运的是，我就读于苏塞克斯大学，那时他们教授 Java，那时 Java 还是 1.1 版本，刚发布不久，非常新鲜。所以我很幸运，当我在本世纪初进入职场时，已经有了 Java 的经验。作为本科生，我曾在福特汽车公司工作过。所以我对专业软件开发是什么样的有了认识，后来我进入了 web 开发和 Java 领域。作为一名传统的软件工程师，我工作了约10年，从事 Java 和 web 方面的工作。然后我在 LMAX 工作过，和 Dave Farley 一起，他当时正在写《持续交付》这本书。我们进行了大量的极限编程实践、实施持续交付，以及那些我读了10年但从未见过有人真正在实践中运用的东西。我那时想，这就是软件工程应该是什么样的。我在那里工作了四年，每一分钟都很享受。在那期间，我学到了很多关于如何使用 IDE 的知识。我们在 IntelliJ IDEA 中进行配对编程。在此之前我当然用过 IDE，但只是做一些基础的东西——那大概是2012年左右。当你与他人配对编程时，每个人都有一套他们使用的技巧。所以作为一个团队，你们都会变得更好，因为你们都能学到彼此的小技巧。我学到了大量关于 IDE 的知识。我也学到了很多关于如何有效地工作、生产力问题，以及极限编程在现实世界中是如何运作的。我想，我想去告诉其他开发者有希望存在，不是所有的事情都必须很糟糕。那些你正在做的工作，那些经典的软件开发日常工作，不一定非得那样。有很多事情你可以在不同维度上做，来改善你作为软件开发者的生活。这就是我如何进入倡导领域的原因，因为我想参加会议、写博客文章和制作视频，向人们展示 IDE 的技巧，告诉人们某些敏捷技术或设计方法的权衡，以及讨论书中内容的务实实现方式。因此，我最终在 MongoDB、JetBrains（从事 IntelliJ 相关工作）和 Gradle（从事开发者生产力倡导工作）工作过。这就把我们带到了现在。现在有了 AI，起初我想，我的 IDE 经验和我传统的软件工程经验在这个新的秩序中处于什么位置？尤其是因为我不再从事实际的编码工作，虽然我确实用 Claude 改写了我的网站，当然了，因为大家都这么做。但真正有趣的是我现在所做的就是试图弄清楚在 AI 时代中什么仍然相关，什么是真正的生产力，以及当我们沿着 AI 的炒作曲线前进时什么是噪音。

RD：IDE 的生产力提升是什么样的？我们不久前发表了一篇关于 IDE 的文章，作者对 Vim 和 Emacs 做了一些有点不敬的讽刺评论，人们对此反应很大。

TG：人们对他们的工具有非常强烈的感情，完全就是这样。我对 IntelliJ IDEA 感情很深，我之所以对拥抱某些 AI 编程有所保留，是因为我用 IDE 会更快，因为我很了解它。我见过同样的情况，那些非常精通 Vim 和 Emacs 的人，我说，但你可以使用 IntelliJ IDEA 的重构工具。他们说，是的，但那需要学习成本。我不愿意付出这个代价。我用现有工具已经足够高效了。关键是，不管是什么工具，对它的深入理解会让它变成一种无意识能力。所以你的手指知道用什么快捷键。当人们问我 IntelliJ 里某个东西的快捷键是什么时，我得在脑子里想象一个键盘，然后看我的手指会做什么，因为我不知道快捷键是什么，但我知道我的手指想做什么。

RD：这是肌肉记忆，对吧？

TG：是的，肌肉记忆。所以一旦我们熟悉了工具，一旦我们找到了适合我们工作流的工具，它们就会变成肌肉记忆，会深深地融入我们的工作方式，也会成为我们自身的一部分。我们不希望有人说 IntelliJ 很糟糕，因为我们会想，不对，我用它非常高效。如果你说 IntelliJ 很糟糕，那一定意味着我很糟糕，但事实绝对不是这样。

RD：有趣的是每个人都有自己的工具——每个人都把快捷键记住了，但 AI 似乎在打乱这个生产力流程，对吧？你不需要魔法词或按键来导航。你觉得我们会因为失去这些而失去生产力吗？还是全是好处？

TG：我认为我们还不知道。我们仍然处于一个非常模糊的区域，我们知道 AI 肯定会改变一切。AI 会一直存在，就像高级编程语言一样。NoSQL 数据库、云计算。在所有这些东西的早期，有很多炒作，有很多人在做超级用户的东西，也有很多人抵制变化。真相在中间的某个地方。就 IDE 而言，我认为这也会有所不同。比如，如果你是一个经验丰富的开发者，对 IDE 了如指掌，知道如何使用重构工具，知道如何在不思考的情况下做各种事情，你就不会花 AI token 去做那些东西。为什么要花 AI token 做你能在 IDE 内快速、可靠、确定地完成的事情呢？对于那些没有这种肌肉记忆或没有深度融入他们自己 IDE 的人来说，这是一个有趣的问题。我一直在思考，有没有办法教开发者在哪里找到平衡？我一直在想，"零token 生产力课程"怎么样？这将以以下假设为前提教授：当然你会在很多其他事情上使用 AI。当然你有 AI 智能体在做这些事情。但这里 IDE 在这些方面真的很好。我认为这是一个很好的想法，但我认为这将非常取决于——你的团队、你在做什么，以及你对学习不同工具的兴趣。所以有些开发者很乐意使用 AI 进行重构，用 IDE 来做重构，有些开发者真的只是想使用 IDE 的 diff 工具，以便他们能更有效地进行代码审查或其他工作。但我不认为 IDE 会消失，但它的角色确实在非常迅速地演变是真的。

RD：是的，听起来似乎有一个新的角色，其中一些 IDE 快捷键是更确定性地构建的技能，对吧？

TG：是的。如果我要求 Claude 为我重构什么东西，我希望它使用 IntelliJ 的确定性重构工具。我不希望它做一些我没有预期的东西。

RD：对。我观察到，对于那些从一开始学习编程就使用 LLM 的人来说，很容易什么事情都交给 LLM，对吧？我看到有人问：“哪个 LLM 适合转换 PDF？”我的反应是：“没有一个适合，对吧？”

TG：要么都不适合，要么都适合，你懂的。

RD：是啊。问题在于，那不是合适的工具。那么，对于那些只会从提示词角度思考的人，我们要如何重新激发他们对 IDE 的认识呢？

TG：AI 与其他任何类型的工具都不一样。比如 Docker 刚出现时——我拿 Docker 举例，是因为我花了好几年才弄明白它在整个生态系统中的位置，因为我之前担任工程师时没有使用过它，而在从事 Java 开发者布道工作时，我也基本不需要接触它。所以，我花了一段时间才搞清楚 Docker 的定位。你必须亲自尝试和摸索，但之后你就会明白：“这就是它的生态位，这就是它适合的位置，对吧？这是它擅长的事情，这是它不太擅长的事情。”AI 则非常不同，因为它无处不在。

RD：对。它几乎什么都能做，对吧？

TG：它几乎什么都能做。因此，你可以用它生成代码、编写演示文稿、进行代码审查或调试，也许还能用它编写 Docker 脚本、运行测试以及识别不稳定测试。我觉得这非常酷，但这也是它的弱点。如果你使用非常通用的模型，试图让它们完成所有事情，那就像是样样都会、样样不精，最终没有任何一件事能做得特别好。我认为每个团队，甚至每个人，都会逐渐弄清楚哪些 AI 工具适合自己、它们如何融入自己的工作流，以及自己要在多大程度上依赖 AI，而不是使用 IDE 或命令行工具。

PDF 就是一个很好的例子。我写书时使用 AsciiDoctor 生成 PDF，但我花了很长时间才弄清楚该怎么做，因为它比我希望的复杂得多。不过现在，我不会让 LLM 替我完成这件事，而是会让 LLM 告诉我如何设置好一切，以便我自己完成。所以，是的，我认为最终的关键在于，为团队和个人找到 AI 适合发挥作用的细分场景。

RD：是的。我认为我们也在逐渐遇到这样的情况：人们开始意识到 token 消耗所带来的负担，对吧？我参加过一场会议，会上 Uber 的 CTO 好像提到，他们在五个月内就用完了全年的 token 预算。

TG：我觉得这很有意思。尤其是一些 AI 公司正在改变定价模式，而且基础设施本身也有负担。作为开发者，我们未必能看到这种负担，但总得有人支付这笔成本。一开始，我们当然会把所有东西都扔给 AI。我们想看看它能做什么、不能做什么。我们发现可以把一堆事情委派给它，这样自己就不用操心了。

我认为现在是一个很有意思的阶段，因为我们应该开始思考并重视成本了。这种成本可能是财务上的，甚至可能是环境上的，也可能是认知上的，因为把所有事情都委派出去会积累认知债务。要弄清楚成本出现在哪里、哪些成本是你愿意承担的，以及哪些成本或许可以通过其他更好的方法来避免。

RD：那么，无论是新工具还是旧工具，有哪些能够在新的 AI 工作流中提供帮助？

TG：其实我不知道这个问题的答案。我可以告诉你，任何开发者工具的创造者现在都在急切地设法把 AI 塞到产品里的某个地方。原因有几个。

第一，人们确实通过使用 AI 提高了生产力，尤其是在代码生成方面，但在故障排查、代码审查等方面也是如此。因此，AI 确实能带来改进。

第二，许多企业有 AI 预算，却没有工具预算。所以，它们购买的工具必须包含 AI，否则就拿不到预算。我不想说这是一场军备竞赛，因为那可能意味着所有东西都在变得更好。目前的情况更像是一窝蜂地要求所有开发者工具都必须包含 AI，不管这是否合理。我们仍在不断探索什么合理、什么不合理。

然后还有 Anthropic 这样的公司，它们会针对第三方工具改变 API 的工作方式、定价方式或其他规则。因此，那些把 AI 附加到产品上的工具，现在的处境可能已经不同于几个月前。

所以，是的，说了这么长一大段，其实就是我不知道该怎么回答这个问题。我认为我们正处在一个非常有意思的时期：所有人都想争夺你的注意力；所有人都有某种 AI 生产力工具；所有原本就存在的开发者工具，也都以某种形式加入了 AI。

我认为我们真的需要非常审慎——尤其是工程负责人，以及负责为团队采购产品的人。我们面临什么问题？我们想如何解决这些问题？这个工具真的能解决那个问题吗？

作为技术人员，我们总是对能解决问题的工具感兴趣。IDE 就是一种经典工具，它解决了很多问题，但工具本身未必能够自动落实某种实践。我的意思是：你有一台 Jenkins 服务器，并不意味着仅仅因为有了持续集成服务器，你就在真正进行持续集成，对吧？你有一个 AI 智能体替你进行代码审查，也不一定意味着你拥有正确的代码审查流程，不一定意味着你审查的是正确的内容，甚至不一定意味着你需要代码审查。如果团队里有资深工程师，你可能根本不需要它。

RD：听起来你的意思是，工具解决不了文化问题，对吧？

TG：完全正确。我认为，作为技术人员和工程师，我们往往会直接奔向工具，因为工具让我们感到熟悉和舒适。但我们确实需要退后一步，问一问：“我们的问题究竟是什么？摩擦点在哪里？”

许多 AI 工具或开发者生产力工具都以……当然，很多都以代码生成为目标，也有一些面向故障排查、代码审查之类的工作。但如果我们构建东西的速度很快，却没有构建正确的东西；或者，虽然我们为它生成了代码，却无法轻松地对其进行测试、构建和部署，因为 CD 流水线负载过重，而我们从未认真思考过这个问题；又或者，我们之所以没有构建正确的东西，是因为代码生成成本很低，所以我们对所有需求都一概答应——那么，继续向这个问题投入更多工具就没有意义。

更合理的做法是退后一步，问：“好吧，我们希望工具解决哪些问题？”然后，我们才能评估这些工具是否真的解决了问题。

RD：我看到很多人都在尝试为此开发工具。出现了很多 AI SRE，也有很多人可能正像你说的那样，试图弥补 CI/CD 流水线中现有的缺陷。

TG：关于这个领域，我有一些想法。确实有一些优秀的工具能够加快构建和测试，还能让你观察构建流水线。因为很多人甚至没有关注这一过程：我们编写了一些代码，把它扔进生产环境，然后在生产环境里观察它；但是，在“我们编写了代码”和“代码是如何进入生产环境的”之间，存在一个很大的空白。因此，为这部分流程提供可观测性非常重要。

所以，是的，有很多工具——或者至少有一个我知道的工具——能够解决其中一些问题。但我还是忍不住觉得，对于其中一些问题，你只是在贴创可贴而已。

我经常思考测试这个问题，因为我是自动化测试的坚定支持者。我喜欢任何能够加速测试的工具，无论是并行运行测试、使用机器学习判断哪些测试有价值并且只运行这些测试，还是缓存测试结果，从而不必重新运行某些测试。这些都很棒。

但如果你的开发团队编写的测试——或者你的所有智能体编写的测试——有 99% 都是集成测试，而这些测试每次都需要花两分钟启动、运行，然后再关闭，那么你当然需要这些生产力解决方案来修复这个问题。可你根本不需要让 99% 的测试都采用这种形式。你只需要保留端到端测试，同时可以运行快速的单元测试。单元测试更加灵活、速度快得多，也能更快地提供反馈。

这对智能体同样很有帮助，因为如果反馈循环足够快，智能体就可以编写代码、运行测试、确认代码有效，然后以更快的速度继续迭代。

RD：你有某种启发式方法或经验法则来判断一个问题是工具问题还是流程问题吗？

TD：噢，没有。但既然你这么说，我觉得我应该有一个。

RD：我的意思是，也许不管是哪一种，你都在看真正的问题所在。也许是工具问题还是文化问题，其实都不重要。重点是存在一个问题。

TD：我觉得这个特定问题的有趣之处在于，人类在这方面确实很擅长。我不认为你能把所有信息都输入给 Claude，然后问，这里的问题是什么？有没有工具可以解决它？Claude 可能能给你答案。但为了正确地提示 Claude，你需要说，我的开发团队是这样的，我们的流程是那样的，我们的利益相关者期望这样，我们遇到了这些问题。这需要人类来综合所有这些信息，并运用自己的直觉。《Frictionless》这本关于开发者体验的书谈到在一开始进行开发者访谈，以找出开发者体验是否失败或可以改进。尽管《Frictionless》充满了很好的开发者体验指标和衡量方式，但我从中得到的一个收获是，开发者的感受和具体指标（如构建需要多长时间、生产部署需要多长时间）一样重要。因为你的开发者、你的工程负责人会说，这个东西总是很痛苦，对吧？或者当我看到这个东西出现时，我就知道我的时间会消失，对吧？这些是来自于在第一线实际体验的人的直觉。所以我没有很好的启发式方法。但我确实认为这是人类非常有价值的地方。

RD：是的，我有点觉得新冠前最好的改进开发者体验方式就是周五聚会，因为我从来没有比那时更多地了解过工程团队。

TG：我最初 10 年的软件工程师生涯都是在伦敦度过的，所以你会在周五下午 6 点下班，然后出去喝酒。有些公司甚至会在周五给你免费饮料，但只能从下午 6 点开始——这样你就会一直工作到 6 点。正是在那种时候，你能学到最多关于业务领域的知识。那也是你从管理层的角度了解最多的时候——了解他们在担心什么，听到什么谣言，什么即将发生。或者你会从其他团队听到他们的问题，所以你不会想，"哦，总是其他团队的错"，而是会想，"哦，我们可以怎样一起解决其中一些问题？"这种人与人之间的沟通真的是出乎意料地重要。

RD：随着每个人都转向远程工作，我认为人们在试图通过工具来恢复这一点。你对于如何为远程团队恢复这种非正式沟通有什么想法吗？

TG：远程团队进行沟通和感受联系确实很重要，我知道我说这些话听起来像只是空话，对吧？但这做起来真的很难。我的意思是，我已经远程工作 13 年了，所以远早于新冠疫情我就已经这样做了。我既做过个人贡献者和团队成员，也做过团队负责人和高级管理人员。我知道这些角色各自是什么样的。在更多以领导力为中心的角色中，不幸的是需要开更多会议。就是这样。当然你有团队会议，但你还需要那些非正式的一对一谈话——让我们跳上一个通话，你知道的，即使只是上午 9 点 30 分，我并不真的想工作，我会给 Oliver 打电话，因为我知道我可以和他聊天，这给了我一种联系感。我们可能会交换一些背景信息，也可能不会，或者它可能激励我去工作。这让我想起在福特工作时，我们会上楼到咖啡厅，坐下来喝咖啡。你不在办公桌前，但你在工作——因为你在交换信息。所以是的，不幸的是，这就是 Zoom 和 Slack，以及和人类交谈。但同样，面对面地聚集也很重要。所以通常在每年的这个时候，Gradle 会举办全球会议，我会在现场呆整整一周，整个公司的人都来了，有几百人。我总是想，哦天哪，这是离开我的家人一个星期，我真的不想这样做。但去了之后，我想，哦天，这太棒了。我完成了这么多工作。我学到了这么多。我见到了人。我更好地理解了人们如何相互沟通，我可以更好地理解这个人。面对面的东西也出乎意料地重要。

RD：所以这是面对面对话的混乱性质使其有价值的原因，你从某个话题开始，这个、那个、那个，然后在对话的很久以后，你会说，哦。你刚好识别了我们可以一起解决的问题。

TG：我确实认为这很重要。我相当喜欢 Zoom 会议记录这样的东西。所以你不一定要参加所有会议，因为你可以赶上那些内容。它并不总是会议的替代品。它可以帮助避免一些会议。它也可以帮助你不忘记在那些会议中做出的决定。

RD：是的。你认为开发者体验团队今天最应该解决的高价值问题是什么？

TG：我最近读了很多东西，有这样一种感觉，就是如何为智能体编码重新调整软件交付生命周期。它会是什么样的？如果你有智能体而不是人类，它从根本上是不同的吗？还是只是同样的东西，但量更大？相关的还有这种平衡，也许这更多是我的个人观察。我认为我们需要在人类价值和智能体能做什么之间找到平衡。我可以告诉你，没有工作的开发者体验肯定不是很好。

TG：多年来，我们一直在招聘开发者，就像