在本期《培育智能体》（Raising an Agent）播客中，Amp 团队的 Quinn 和 Thorsten 深入探讨了当今 AI 开发者工具的演进趋势。随着 AI 模型的不断演进，单纯在代码编辑器侧边栏中与 AI 助手进行“一来一回”的单对单交流已经不再是未来的方向。为了真正迈向自动化的“软件工厂”时代，他们宣布了一项极其大胆的决定：正式关停并销毁 Amp 的 VS Code 编辑器扩展插件。
此外，本期访谈还详细介绍了全新的“深度模式”（Deep Mode），探讨了如何为 AI 智能体优化代码库（例如构建各种“技能”），并在权衡人类开发者体验与智能体开发体验时做出艰难但必要的取舍。两位对话者认为，在模型迭代日新月异的今天，固守原有的工作流只会成为公司的羁绊。无论是代码编辑器本身，还是传统的手动上下文管理机制，都正在逐渐成为历史。为了不在瞬息万变的技术浪潮中被淘汰，开发者工具团队必须像经营“艺术装置”一样，保持绝对的敏捷性，勇于自我颠覆并不断重建。
Thorsten: 你在侧边栏里与智能体进行一对一交流的时代，我认为即将走到尽头。你在文本编辑器里看着代码，然后在底部或侧边栏让它看到你打开了哪些文件，接着进行这种“打乒乓球”式的来回对话——这并不是未来。
Quinn: 只有那 1% 想要走在最前沿的开发者，才会想要以未来大家都会用的方式来写代码。实际上，他们只需要在编辑器里完成最后 20% 的工作，我们认为我们可以把这个比例降到 10% 甚至 1%。为了实现我们创建 AMP 去探索软件开发前沿的初衷，我们将关停我们的编辑器扩展，比如 AMP VS Code 扩展和 Cursor 上的扩展等等。我们认为侧边栏模式已经宣告死亡，接下来我们就来详细聊聊原因。
大家好，欢迎收听《培育智能体》（Raising an Agent）第10期。我是 Thorsten，和我在一起的是 Quinn。你好，Quinn。
Quinn: 嘿，Thorsten。我们刚刚发布了“深度模式”（Deep Mode）。还有很多新东西在路上，不过你最近是怎么使用深度模式的？你有没有爱上这些新模型？
Thorsten: 是的，这可能是我的一大“缺点”，但没错，我们上周发布了深度模式。对于那些还不知道的人来说，深度模式是 AMP 中的一种新智能体模式。我们现在只有三种模式。我们不仅有“智能模式”（Smart Mode）——这是我们当前由 Opus 45 驱动的主力模式；还有“极速模式”（Rush Mode），它使用了一个非常快的模型——如果我没记错的话，我们目前在极速模式中正尝试其他模型，但现在用的应该是 Haiku。
Quinn: 没错。这是一个速度很快、但相对没那么聪明的模型，适合用来快速处理一些任务。
Thorsten: 我们还发布了一个叫“深度模式”的新模式，它由 GBD52 codeex medium 驱动。这名字挺有意思的。我们发布它是因为我觉得 52 codeex 在很多方面都非常出色。它非常聪明，这虽然听起来有些好笑，但它确实很聪明。它可以写出非常好的代码，并且在研究和查找资料时非常全面。
我们之所以叫它“深度模式”，是因为我们意识到了这个模型的优势与劣势：它并不擅长处理那种“嘿，帮我设置一下 Zshell RC，然后做这个，再重新加载那个”这种需要极速来回互动的助手类任务。对于这类任务，它有些过于慵懒，有时候只会回复“你应该运行这些东西”，或者它会花太长时间去研究。
但是，如果你有一个范围明确的问题、一项大型任务，或者你想找出某些问题的答案，你可以把这个任务交给它，说“去把这个做完”。在这个过程中，你需要切换标签页去做点别的事情，它会以非常细致的方式去研究，通常能带回极其令人惊叹的结果。所以我们把它做成了一个独立的模式。
而且我必须要说，它是一个不同的“模式”，而不仅仅是一个模型选择器。这是与 AMP 互动或使用 AMP 的一种全新方式。我们还专门针对这种模式调整了工具。比如，有些测试体系里有一种“用户反馈问题”工具，但我认为这对“深度模式”没用，因为在深度模式下，你希望把任务派发出去，然后在 60 或 45 分钟后再来检查。
所以，当我们在内部大量试用一个新模型时，我们是如何意识到“这其实是一个需要用不同方式去使用的模型，而不是用来替代大家用 Opus 的方式”的呢？我想，当我第一次尝试它的时候——关于 52 模型有很多讨论，比如 Peter Steinberger 就非常喜欢它——大家都说它是个完全不同的“猛兽”。刚出来时我们试过，感觉它并不适合我的工作方式。后来我又认真试了一次，并调整了我的预期。我们意识到，你不再需要死死盯着这个助手了。
我们过去一直强调的“你应该这样写提示词、我们应该做反馈循环”等等，很多都不再适用于它，但结果不会骗人。也就是说，这两种模型可能会得到相同的结果。
我甚至不能说深度模式总是更好，或者总能写出更好的代码，但它们能达到同样好的结果，只是方式不同。Opus 是“急脾气”，它想立刻运行东西，想赶紧回复你、问你问题；而深度模式只是默默走开去帮你把事办了。当你看到这些，并意识到“哦，原来有另一种方式可以达到这样的结果，只是我们需要区别对待它”时，公司内部的很多人（比如 Nico 和 Hesh）就开始致力于开发深度模式，并针对这种工作方式进行优化。基本上，我们的目标不是“让它像 Opus 一样工作”或者“让它像个小助手”，而是“让它成为一个你可以派发任务并替你办事的工具”。
Quinn: 是的。所以很多时候当你听到人们说“哦，这个模型比那个模型好”时，很多都是因为他们已经习惯了某个模型，当他们用同样的提示词和期望去测试新模型时，自然会觉得行不通。我们在智能体模式上想做的一件事，就是把你从那种固有的思维模式中拉出来。如果你在其他工具里，只是从下拉菜单中选择 GBD52 codeex，那这并不能促使你改变思维方式去尝试新的做法。我们尝试了很多不同的方法来教育用户。不过有趣的是，等我们或其他人终于搞清楚某个模型的正确使用方式时，又会有一个新模型冒出来，把一切都打乱。而且我不认为这种步伐会放缓。
Thorsten: 是的。如果可以的话，我希望当用户切换模式时，应用程序的外观和感觉能完全改变。比如，假设在“智能模式”下你用的是某种字体，切换到“深度模式”后突然变成了另一种字体，而且你的提示词长度要求至少 100 个字。这应该让人感觉就像是发短信和写一封长信的区别。这很难实现，但它应该传达出这样一种感觉：你在做一件不同的事情，你在为一个不同类型的任务与一个不同的模型对话，你需要用不同的方式来对待它。这也是所有 AI 产品的挑战——它们都是文本框，而在全是文本框的情况下传达不同的预期真的很难。
Quinn: 是的。即使你不亲自去用这些功能，它们依然显得如此神奇，并且经常能发挥作用。
Thorsten: 没错。这就是深度模式。我想我们在上期播客（大约发布深度模式前一周录制的）就已经暗示过这一点，那一期的副标题是“助手已死，工厂万岁”。那其实已经是基于我们在深度模式中的尝试得出的结论了。当我们开始使用深度模式时，事情变得很明显：如果模型正在朝着这个方向发展，变得能够运行更长时间、更加自主，终于兑现了过去两年的承诺，那么传统的助手模式就显得……
Quinn: 你这话听起来好像这些模型还不够惊人似的。这不是说它们没有兑现承诺，而是那种“哇，这些真是奇妙的东西”的感觉。
Thorsten: 它们确实很惊人。我现在的观点其实和我去年说的完全相反。去年就在这个播客上，我还说“这是给高级用户准备的专业工具。它就像一把电钻，你必须握紧它，通过提示词进行沟通和反馈循环来管理这些模型。”我不是说这种方式死了，但 52 codeex 展示出了一种可能性：哇，现在只要你写一个详尽的提示词，然后让它自己去跑，它就能带回令人惊讶的结果。这是一种趋势。想象一下，如果 codeex 55 或者其他什么模型在执行此类任务的可靠性上再提高 10%，那你就得问自己了：为什么每次只能跑一个任务？为什么要一直在侧边栏盯着它看？对于一个需要 45 分钟的任务，哪怕它不需要你输入任何东西，你难道就只是坐着看它跑完吗？所以我们才提出了“助手已死，工厂万岁”的想法，因为你会想要同时启动许多这样的任务，优化它们的长时间运行能力。现在，模型终于跟上了这个理念：你可以同时生成一大批任务，等它们做完再去检查结果。
Quinn: 是的，没错。那我们来谈谈我们在代码库里做了什么，以及你如何改变编写提示词的习惯来适应深度模式的。有什么不同？
Thorsten: 我引用一下你的话。过去几个月，我们对开发工具进行了大量的针对性优化，以适应智能体的需求，这也是大家目前都在做的事情。简单来说，我们增加了更多关于“如何在我们的代码库中做事”的“技能”（Skills），智能体可以直接调用这些技能去完成任务。举个简单的例子，我添加了一个技能，让它知道我们是如何发布 Web 服务器和客户端的。所以，如果我遇到一个 Bug，我可以问它：“帮我弄清楚为什么这个没有部署”或者“当前的线上版本是什么”。它就会加载这个技能并知道怎么做。这种技能积累得越多，它在系统里的导航能力就越强，你也不需要给它那么多提示。感觉“技能”已经成为解决这类普遍问题的一个很好的抽象方案。它比 MCP（模型上下文协议）或自定义命令、自定义子智能体等其他东西更有黏性。
Quinn: 是的。我不知道是谁在推特上说的，但大概意思是：如果你通过指示智能体“使用 GitHub 的 GH 工具分析构建失败原因，然后做这个做那个”，最终解决了你们工具链中的一个问题，那么在对话结束时，你可以跟它说：“现在帮我创建一个技能，把你刚才学到的关于解决这个问题的所有知识都封装进去。”在 AMP 中，我们内置了一个用来“创建技能的技能”。所以它可以加载这个技能，然后自己弄清楚该把新技能放在哪里，以及如何编写它。
这带来了巨大的改变。我们从最底层说起，比如我们有一个 Tmux 技能，它解释了如何在我们的代码库中使用 Tmux。这意味着它知道“这是使用 Tmux 测试 CLI（比如我们的 AMP TUI）的方法”。里面还记录了一些不是百分百可靠但通常有用的东西。比如，我们的 TUI 需要按两次 Ctrl+C 才能关闭。智能体以前总是搞错这一点。所以我把它写进了技能里：“如果你在测试 CLI，请记住要双击 Ctrl+C。”这种小细节不断积累，产生复利，你就再也不用在提示词里赘述了。现在当你让它测试 CLI 时，你经常能看到它自动执行双击 Ctrl+C，或者说“这是我运行的命令，输出在这里”。这是最底层的一端。
另一方面，我们还有关于 GCloud（谷歌云）的技能。说来好笑，那是关于如何使用 GCloud 命令在 GCP 上托管内容的。我两天前还在和 Tim 聊这个，我们感叹道：“老天，我以前一点都不喜欢 GCloud。”它的 CLI 感觉很难用，你往往会去用其他的日志查看器，或者 Prometheus 和 Grafana 等等，因为它们更容易上手。但现在有了智能体，这已经不重要了。我只需给它一个错误信息：“用户说这个请求失败了”，然后让它“使用 GCloud 去找出原因并获取日志”，你就能看到它熟练地执行一连串的 GCloud 命令。
这让我不禁思考：软件到底是什么？如果你构建了一个 Web 面板，但同时我只要给智能体提供一个包含 GCloud 使用方法的技能，它就能弄清楚怎么进行最复杂的日志分析查询……那我为什么还要去用 Web 界面呢？
Quinn: 是的。GCloud CLI 非常强大，我经常看到智能体用它飞速地筛选日志或者审计记录。
AMP 是连接到官网的，那里有许多共享的对话线程（Threads）。所以我想展示一个我们即将推出的新功能：让你可以查看团队里最常用的技能都有哪些。通过检索你团队的对话线程（加载有点慢，所以只展示了我们团队过去一天的记录），我们可以看到最常用的技能。通过这些数据，我们可以发现：“哦，你看这个 GCloud 技能过去一天只用了一次，但其他人今天大量使用了 BigQuery 技能。”
Thorsten: 喔，确实！我想说 BigQuery 技能简直太棒了！显然它涉及敏感数据，但我认为这可能是不再频繁从 ChatGPT 复制粘贴内容的最大理由。这就是它的魅力所在。你可以问它：“有多少用户使用了某个功能？”然后让它使用 BigQuery。它自己跑去查表名、写 SQL 查询，它写 SQL 真的非常厉害。
Quinn: 有多少人用了 Ralph 技能？只有 Tim 吗？不，让我看看，今天用了 23 次。代码审查（Code review）技能也很有趣。我们会把这个功能发布出来。
Thorsten: 所以说“技能”只是一方面。另一件值得一提的事是，我们优化了代码库，现在只用一个命令 PNPM test 就能运行所有测试，而且非常容易记住。它利用了缓存，所以你可以连续运行五六次，如果你没有修改某个特定包的代码，它就不会重复跑那部分的测试。
Quinn: 听起来像是用了 Bazel？我们肯定是用了像 Bazel 这样庞大且笨重的工具吧？因为我们怎么可能自己写出一个自带缓存的测试体系呢？
Thorsten: 我这么说可能会得罪人，尤其是某个人肯定会因此恨我。但我感觉，智能体的出现并没有证实“这些复杂的构建工具和可重复构建将会大获全胜”。我觉得智能体非常擅长使用那些“笨”工具。你不需要极其沉重复杂的工具。PNPM test 只是你要求它“必须永远运行这个命令”，命令本身会给出输出，这就够了。你根本不需要 Bazel 周边的那些繁文缛节和冗长的输出，至少在我们的规模下不需要。
Quinn: 没错，我们有 19 个人在开发 AMP。如果我们精通 Starlark（Bazel 的语言），用 Bazel 确实不错，但我们没用。Tim Culverhouse 和我们的团队构建了这个测试体系，他还极大地优化了许多测试和 Svelte 检查。这引出了一个有趣的问题：随着我们让代码库越来越像一个工厂，并建立起可靠的反馈循环，你可能会认为人类开发者的体验也应该相应提升。毕竟一切都在变得更好，不是吗？
但实际上，为了让针对 SvelteKit Web 应用的检查命令跑得非常快，Tim 实际上用 Zig 语言重新实现了一个 Svelte 检查工具，叫 Zveltch check（它是开源的，可以在 GitHub 上找到）。事实证明，这反而使我们在 VS Code 里的 SvelteKit 开发体验退步了一点。
于是我们面临一个艰难的选择：到底是保留人类开发者的体验更重要，还是保证智能体的开发体验更重要？我们团队大约有一半人在用 VS Code，另一半人在用 Neovim 等工具。用 Neovim 的人表示：“我才不在乎 VS Code 的开发体验。”虽然为了兼顾人类体验，我们最终短暂地回退了那个版本，但实际上，我们已经做好了让人类开发者体验降级的准备。
这让我觉得，如果留在 VS Code 里继续使用我过去 7 年（从 Emacs 换过来之后）积累的所有扩展，会拖慢我们为了适配智能体而改造代码库的进度，那我宁愿离开 VS Code。当你让智能体进入你的代码库，并且你针对智能体对其进行了优化后，事情会进展得更快，即便这意味着人类的工作方式不再像以前那样顺手。这也成了促使我们脱离传统编辑器的动力，进入一种不再局限于编辑器内部、可以实现高度并行化工作的新流程中。我们已经看到这种效应在自己的代码库里显现了。
Thorsten: 其实很简单。许多年来，大家常说“开发工具如果很差，一定要尽快修复”，就像“破窗理论”一样。开发工具太重要了，最好的公司拥有最好的开发工具。但他们所说的“最好”，是指对人类而言最好。现在，尽管我们在开发工具领域有着几十年的综合经验，我们却说：“虽然这对人类来说不理想，但并不重要，因为智能体要调用这个命令非常多次。”这种心态的转变是巨大的。你觉得“这玩意儿可读性太差了”，但智能体却能比你更轻松地看懂锁文件（lock file）。这非常有趣。
Quinn: 是的，为了获得智能体带来的红利，你必须学会放手。对我们来说，这是一个有趣的问题：我们在为谁开发？我们一直希望 AMP 走在最前沿，一切都在改变。既然只要针对智能体优化代码库就能成倍放大其能力，那我们就想专门为那些愿意付出这种投资的人打造 AMP。目前，可能 99% 的团队和代码库还不愿意这样做。但我们想要探索：如果那 1% 的人做到了，会发生什么？如果将智能体放入一个专门为其构建的代码库中，你能走多远？我们不知道确切答案，但我们相信一定比现在走得远得多。
Thorsten: 那我们来说说这个大新闻吧。我们刚刚聊到的所有内容，核心主题正如我们上次所说：“助手已死，工厂万岁”。我们上次谈论这个时，重点是你需要为这些能够更长久、更自主运行的智能体优化你的代码库，但我们并没有过多地去否定现有的“助手”模式。但今天我要明确地说：我认为，你在侧边栏里跟一个智能体进行一来一回的一对一交流的时代，已经走向终结。
你在文本编辑器里看着代码，助手在底部或侧边栏，看到你打开了什么文件，然后你俩开始打乒乓球一样的互动——这正是我们过去一年在做的事。但我现在觉得，这已经不再是未来了。时代已经变了。
Quinn: 我们所说的“终结”，是指对那 1% 想要遥遥领先、想要以未来的方式编写代码的开发者而言的。对于这 1% 的人，在他们当前的工作流中，只有最后 20% 的工作需要在编辑器内完成。而且我们认为，我们还能把这个比例降到 10% 甚至 1%。所以，我们不是在打造一款适合所有人的产品。针对那些使用 AMP 的人，以及我们打造 AMP 去探索软件开发前沿的初衷，我们将正式关停我们的编辑器扩展程序（比如 AMP 的 VS Code 扩展、Cursor 上的扩展等）。我们觉得侧边栏模式已经死了。接下来我们聊聊为什么我们要这么做，以及这会在什么时候发生。
为什么这么做？第一，我们认为这种工作模式限制了你使用智能体并行化工作的能力。而在接下来的几个月里，并行化将是让你从智能体中获取更多价值的最佳途径。侧边栏束缚了你。
第二，侧边栏成了一种“拐杖”。当你在编辑器和侧边栏工作时，你——作为一个反应迟缓、本该去做更有价值事情的人类——变成了系统中的“反馈循环”。即便是在智能模式下，模型正在做着令人惊叹的事情，你依然是那个被迫提供反馈的瓶颈。我们想让你摆脱这个角色。我们希望你能主动去设置自动化的反馈循环（比如测试命令、构建命令、技能等等），从而不再需要亲自充当反馈节点。这是你未来能更好地榨取智能体价值的另一种方式。
第三，AMP 并不想取悦所有人。如果我们在这一点上不够果断，不做出大胆的改变，那么一两个月后，我们不仅会因为提供了一种不代表未来的产品而对不起大家，我们的用户群体也会发生变化。如今我们的用户都是站在最前沿、以最先进方式工作的先行者；如果我们妥协，我们的用户就会沦为落后者，这将使我们以后更难做出改变。
这就是我们将关停 AMP 编辑器扩展的原因。什么时候关停？它大概会在 60 天后自行启动自毁程序。具体哪一天我们还不确定，但我们会放一个倒计时，你会看到的。我们目前还不完全确定拿什么去取代它，因为我们正在尝试很多方案。我们相信会有一种更高层次的交互方式能够跑通，但无论如何，我们都坚信必须替换掉它。我们要“破釜沉舟”。
所以，大家还有一点时间可以继续使用它。在此期间，我们强烈建议大家切换到 AMP CLI（命令行界面）。如果在切换到 CLI 的过程中，你发现有什么功能是 VS Code 里有但 CLI 里缺失的，并且你非常怀念它，请务必告诉我们。我们非常需要听到这些反馈，因为我们希望你们能和我们一起留在技术的最前沿。
这就是大新闻。我知道很多人可能会问：“你们不能保留它但不维护了吗？或者降低它的优先级让它苟延残喘？”答案是：这关乎焦点。如果我们保留它，就难免会分散我们的注意力，而忽略了你们大家都认为重要 100 倍的东西。
Thorsten: 是的。很有必要重申一下我们开发 AMP 的初衷：我们希望让软件构建者能充分驾驭人工智能的全部力量。这就意味着此时此刻，我们必须站在 AI 能力的最前沿。这是一个不断移动的靶子，模型一直在迭代。你必须紧跟步伐去弄清楚什么是可能做到的最好的事情。
我们是一个小团队。如果还要去维护一个代表了“一年前行业顶尖水平”的老古董，我们是无法跟上节奏的。我们的超能力之一就是一直在高频地“吃自己的狗粮”（内部试用产品），并且能在用户报告问题的几分钟内发布修复。如果整个团队越来越少地使用 VS Code 扩展，这种超能力就会消退。所以我们必须把精力集中在“下一个大事件”上，而不是守着过去的辉煌。
Quinn: 没错。如果我们去雇 10 个人来支持所有被我们砍掉的东西，那我们就不再是一个小团队了，这绝对是错误的一步。这就引出了你刚才多次提到的宏观视角。在前 10 期节目中，我们已经无数次感叹过“一切都在改变”。你认为未来的软件会是什么样？
Thorsten: 我们现在面临的处境，你可以想象一下：如果从“个人电脑”向“互联网”再向“移动端”的范式转移，全都在仅仅一年内发生，那是种什么感觉？
这就好比你刚说：“哦，个人电脑时代来了！我们要开发个人软件，我们要把软件用塑封包装好卖给客户。太棒了，我要建个工厂来生产塑封软件、刻录 CD 和 DVD。”结果四个月后，互联网出现了。你心想：“既然用户可以输入 www.myapp.com，为什么我还要做塑封软件？”过了六个月，应用商店（App Store）和移动互联网又爆发了。你又疑惑：“既然可以下载个 App，为什么还要让人去浏览器里输网址？”
所有这一切的极速演变，现在正发生在软件开发领域。举两个简短的例子：
几个月前，大概是 Jeffrey Lit 发推特说，他在酒店的健身房想锻炼，于是他对着当时的 Claude 拍了张照片，说：“嘿 Claude，我在酒店健身房，这是我可用的器械照片。给我制定一个个性化的锻炼计划。”如果你健过身，你知道市面上有很多这样的 App。但通过 Claude，你只需发张照片和一段自由文本，它就搞定了。而且 Claude 在网页上直接生成了一个小巧的 HTML 界面，让你可以勾选组数和次数。我当时就觉得：“天哪，新兴的软件 UI 出现了！”我们知道它还不完美，不一定能每次精准复现，但这已经是一个非常值得深思的苗头了。
接着是做 RemixJS 的 Ryan Florence，他说：“这很酷，看看我怎么做的。”他发了一段在家庭健身房的视频。他直接使用 OpenAI 的语音模式说：“嘿，ChatGPT，我在这间屋子里，带我完成一次锻炼。”ChatGPT 回答：“好的，我希望你先做一组，准备好了告诉我。”他说：“准备好了。开始。”当他做完后说“我做完了”，ChatGPT 回答：“休息 60 秒。”然后他再次准备好……所有看得见的“界面”都消失了，只剩下语音。
这一切还是传统意义上的“软件”吗？计算机在引导你完成工作流，这是不是软件？但在这个过程中，代码又在哪里呢？它已经消失了。
另一个例子发生在我身上。我原本打算给妻子和我自己配置一个类似 Pi Assistant 或 OpenClaw 这样的开源机器人，用来通过发短信管理购物清单。但我突然想到：“我为什么要在 Todoist（一款带有各种集成的 SaaS 待办应用）里管理购物清单呢？”购物清单通常只有 10 到 15 项，智能体完全可以在某个地方写个文本文件当作记忆，或者干脆存在上下文窗口里就行了。根本不需要 Todoist 这种应用。当然，如果我想要一些对话模式无法提供的特定数据视图，可能还需要某种应用。但我举这些例子是想说：所有的东西都在消融。
过去 20 年的商业法则一直是：找到一个有市场的软件需求，找到目标客户，占据利基市场，然后规模化。这就是过去二三十年大家都在用的剧本。但现在，你的目标市场每三到六周就在发生巨变。所以，不被淘汰的唯一方法，就是不断自我重塑。
这也是我们现在在做的事情：我们开发了 VS Code 扩展，发布了它，但现在我们觉得它所处的市场已经不对了，它正在拖我们的后腿。时代已经滚滚向前，我们也必须随之向前。这是我的非 CEO 观点。作为 CEO，结合销售团队、MCP 或者业务合规等，你是怎么看的？
Quinn: 你刚才解释了为什么企业必须保持极度谦虚，并随时准备迎接变革。对 AMP 来说，我们是一个 19 人的团队，每个人都在使用 AMP，每个人每天都在写代码。最近 AMP 发展得非常快。有人可能会问：“既然我们似乎掌握了某种魔法，为什么不把它做成企业级产品？为什么不去组建销售和营销团队，甚至去买超级碗广告？”
如果几个前提条件成立的话，这么做是合理的：如果产品在一年后完全不改变依然能保持竞争力；如果你能非常有把握地留住客户；如果培训一个销售人员的知识不会很快过时……这种模式依赖于太多的假设。然而在当下，尤其是在开发 AI 编程智能体这个领域，没有任何一个假设是站得住脚的。我们所说的这些变化，不仅适用于健身应用或待办事项软件，对编程智能体领域的影响更大，因为这是目前竞争最激烈的赛道，它就处于技术浪潮的最前沿，非常容易受到技术进步的巨大冲击。
当我们审视同行时，我们的竞争优势之一就是我们要成为最具前瞻性、最彻底融入前沿的公司。我们要做行动最快的团队，承担最大的风险，不断推动用户尝试新事物，并在尝试中从用户身上学到最多。我们要比任何人更早、更坚决地砍掉旧功能，我们不想背负历史包袱。
要做到这一点，你不能因为“还有很多人喜欢”就留下 VS Code 扩展。如果你在这些地方开始妥协，一切就会分崩离析，你必须时刻保持偏执。你总说，我们要有一种随时可能被新技术或新模型颠覆的恐惧感。在我们这里，没有任何东西是神圣不可侵犯的，我们时刻保持警惕。
Thorsten: 是的。我们来聊聊 Pi 和 OpenClaw 吧。你不得不惊叹他们是怎么做出来的。从团队规模和结构的极端程度来看，他们甚至比 AMP 还要极致。Mario Zechner 非常厉害，他做了一个叫做 Pi 的通用智能体架构，并在此基础上做了一个带四个基础工具的编程智能体。它有一个非常好的插件 API 便于扩展。随后 Claudebot、Moltbot 以及 OpenClaw 都基于这个架构构建。这充分展现了一个架构优良的通用智能体的美丽与强大。理论上，你可以把 OpenClaw 的那些工具提供给任何编程智能体。
Peter Steinberger 做了 OpenClaw。这两个人都有非常强烈的个人观点、坚定的毅力和对自己想做的东西的清晰愿景。他们有着极高的独立性，而不是像那些被风投机构投资、带着庞大销售团队、背负季度指标的公司那样。在那种公司里，销售员会抱怨：“如果不加上这个功能，我就拿不下这单，我就辞职。”无论你多么努力想避免，只要你稍稍让步，这种诱因就会逐渐磨平产品的锐角。所以，这些极具生命力的独立项目能够在世界上风靡，我一点也不意外。
Quinn: 是的，我今天在斯坦福校园里，每一个跟我交谈的人都提到了它。很多人都用过，我还特意问了细节确认他们真的用过。这种产品不可能诞生自谷歌这样的大公司。因为如果大公司发布它，承担的风险和连带责任太高了。这是一条极端的路线，而我们希望尽可能地靠近这种极端。这也就要求我们必须做出艰难的决定，比如砍掉 VS Code 扩展。
Thorsten: 是的。但连他们也会承认，这依然不是最终形态。他们肯定不会说“3年后你们还会用 OpenClaw”。我不认为他们一开始就知道它会像现在这样大火。
即便是现状，每过两个月到半年，行业就会出现彻底的洗牌，就会有新的东西抽走你的地毯。一旦你意识到这种事情必然会发生，你还会坐在地毯上安心搭乐高，声称“这就是我要做的东西”吗？还是会选择把乐高抓在手里，时刻准备跳到下一张地毯上？这正是 AMP 在做的。
我们把视角拉远，看看 Cursor。他们建立了一个惊人的商业帝国，实现了历史性的增长奇迹，团队也非常聪明。
Quinn: 令人难以置信。而且我认为他们依然在极速增长。
Thorsten: 但是现在，大家开始议论：“Cursor 团队，VS Code 正在拖你们的后腿。把智能体塞在编辑器里已经被时代抛弃了。”早在一年前的活动上，我就说过编辑器的日子屈指可数了。现在，历史上增长最快的初创公司被告知他们受到了编辑器的掣肘；而另一边，只在 Telegram 上交互、在后台自动运行的 Pi 和 OpenClaw 智能体却展现出了巨大的潜力。这就证明了这是一个疯狂的时代。你绝不能躺在功劳簿上，必须时刻思考价值最终将流向何方。我也不认为 Cursor 在原地踏步。
Quinn: 是的。只要回顾去年的一些销售对话就会发现，去年大家还在说“Cursor 让 GitHub Copilot 显得过时了”，而 Copilot 曾经长期是行业王者。但半年后，Claude Code、AMP 以及自动智能体又让 Cursor 显得老旧，他们不得不努力追赶。现在大家又在讨论“文本编辑器还会存在吗？”所以一切都在飞速衰老，这是一个狂野的时代。
在这个行业里最让人谦卑的教训就是：一旦你看到了趋势的方向，它发展的速度将远超以往任何时期，也远超你的想象。有些人极其擅长把握 AI 浪潮中的某一站，当他们留在那一站时，他们会受到很多赞誉。但这可能只是因为第一个月他们在和早期采用者交流，两个月后他们接触到了多出百倍的大众用户，但真正的先锋早就去追逐新东西了。我们心中始终怀有一种偏执：我们要保持领先，让我们的用户保持领先，并不断尝试有趣的新事物。这个世界最不需要的，就是第 10 个或者第 20 个做着和大家一模一样事情的编程智能体工具。
Thorsten: 举个实际的例子。大约半年前，当时流行一种“由 PRD（产品需求文档）驱动”的模式。大家讨论的都是：“你先构建出一个规格说明，然后从 PRD 生成待办事项列表，再让模型去实现这些任务。”这就是当时大家心中的“完美产品”。
但随着 Opus 或者 GPT-4o 等模型的出现，我们发现以前以为必需的很多死板结构根本不需要了。我现在在用智能体时，虽然还是会说“请分析这个并提出计划”，但这比人们想象的要灵活、松散得多。如果你当初打造了那个隐藏模型能力、让用户按按钮走流程的“一键生成产品”，那现在肯定早就崩溃了。这种现象我们在太多事情上都看到了。
这引出了我们在 AMP 中想要抛弃的另一件事。它已经死了，但某种意义上又得到了重生。这番话日后可能会打脸，但我目前认为：“手动上下文管理”的时代也正在走向终结。去年大半年的时间里，我都在强调你必须善于管理上下文窗口：放进去了什么、何时创建新对话、何时去参考旧对话……这些技巧曾经能带来很好的效果。但现在，尤其是有了像 GPT-4o 这样的模型后，就算你不做这些，也能得到极好的结果。这就让人不禁要问：如果能得到同样的结果，为什么还要去做那些繁琐的管理呢？
Quinn: 是的。“手动上下文管理”指的是你的对话线程容量固定，如果满了就得手动交接给新线程。而我们最初曾经有过、目前许多工具仍在使用的那种“自动压缩”（Autocompaction）机制——通过自动浓缩让你感觉不到上下文限制——现在实际上已经变得非常可行了。
Thorsten: 我过去很长时间都认为自动压缩行不通，因为这会导致信息丢失和模型表现下降。但你看看最新的模型，它本身就倾向于在动手前先去搜索研究。如果在一个长对话中触发了自动压缩，它会说“让我去研究一下重新建立语境”。而以前的模型更急于行动，它做完一件事，上下文满了被压缩后，它就会直接按照脑子里最先冒出的想法去运行命令，这导致的结果完全不同。所以对于新的模型，自动压缩来隐藏上下文窗口正在变得越来越有价值。
看看 ChatGPT 和 OpenAI 瞄准的客户群体，这很合理。Anthropic 相对来说没那么偏向终端消费者。而 ChatGPT 从未向用户展示过上下文窗口——大概两年前他们就开始隐藏这个概念了。整个公司的产品优化逻辑都是：用户期望在一个主题上进行连贯的单一对话。我作为一个深知“上下文窗口”概念的人，在用 ChatGPT 记录健身等生活琐事时，也会在几个星期里一直使用同一个对话。即便我明知道它在背后丢掉了最初的信息，但对我的需求来说依然足够好。这就是趋势所在。它的方向不再是手动管理对话线程。
当然，这不是说你现在可以用一个对话搞定一切。在开启一个新对话时，清楚地知道自己想要什么结果依然非常重要。如果你要做两件完全不相干的事，那依然需要两个不同的对话线程。你可以把它看作是一个“主题”、“任务”或是针对项目的特定指引。
Quinn: 所以，我们将去探索如何改变“对话线程（Threads）”的概念。在这之上是否还有更高层级的组织形式？比如与特定的代码库、分支或提交相关联的线程组？这会是一个非常有趣的探索。不再需要去支持 17 种不同的模型，意味着我们可以专注研究哪些模型最擅长自动压缩。也许我们只需支持两个模型，甚至开发出一种全新的交互模式。比如保留 Opus 模型作为真正的“互动模式”，让你能在需要用“手术刀”精细操作时使用。
因为我们砍掉了许多东西、对很多事情说了“不”，我们现在拥有了巨大的自由度去探索这些未知。所以，我想对所有 AMP 的用户说声感谢，感谢你们陪我们一起体验这段旅程。这确实有些颠簸，充满了未知和需要学习的东西。也感谢你们分享的反馈，帮助我们做出更好的决策。
Thorsten: 确实有必要再说一次，我们有多感激我们的用户。在某种意义上，我们是一家赚钱的成功企业，数据很好，也有很多客户。但从另一个角度来看，AMP 又很像一个“艺术装置”，而不只是一家软件公司。我前两天还跟你开玩笑说：“如果 AMP 本身也自毁了会怎样？”然后我们就宣布：“旧的 AMP 没了，这是全新的 AMP！”我们在不断地解构和重建。
有趣的是，我们的客户非但没有抱怨，反而很欣赏这一点。他们会来问我们：“下一步是什么？我们该如何帮助你们？我们应该跟你们分享我们的发现吗？”当我们在一月份砍掉四项功能（比如待办事项、分支功能、以及自定义命令）时，我原本以为没人会在意，甚至不太想发公告，怕这又是一次只会招人烦的“做减法”。但实际上，人们非常喜欢我们移除累赘功能。
Quinn: 是的。大家会说：“太好了，砍掉那些我们都知道已经不管用的东西吧。”当然，也有几个人在抱怨：“我其实更喜欢以前那样，Claude Code 就是这样做的。”我就问他们：“那你们用的是 AMP 还是 Claude Code？”他们回答：“哦，我在用 Claude Code。”在我看来，如果在某个特定功能上我们和它做得差不多都没能赢得他们的心，那我们就算把自己变得更像 Claude Code，又能怎样呢？我们必须去做与众不同的事。
关于我们产品的“自毁”，我们内心深处都坚信：我们目前的客户、收入和产品使用量，每隔三个月都需要我们重新去争取一遍。产品会呈现不同的形态，你们会以不同的方式去使用它，并且为不同的价值买单。我们必须自己去弄明白这些。如果我们不这么做，三个月后我们的产品就会变得一文不值，或者沦落到在“落后市场”里混日子赚一年的快钱，然后彻底被淘汰。我们绝对不要这样。
这正是我们的动力来源，这也让我们觉得自己像个艺术装置，而你们就是参与其中的一部分。我们有这段从 Sourcegraph 拆分出来的独特历史，我们 19 个人都是联合创始人。大家彼此信任，经验丰富，都是自愿加入这场冒险的。我们不需要去外部招聘并画大饼说“这公司很稳定”。大家都知道自己签的是什么生死状。这世上没有其他公司像我们这样。这种结构让我们敢于做极其疯狂的事，比如在几周后的新加坡团队聚会上，我们可能会直接删掉代码库里的整个目录，然后从头重写。能这样做简直太酷了。
Thorsten: 我最后想补充一点。当一切都在变、总需要推倒重来时，直觉上你可能会觉得：“那你们是不是该先退后一步，等局势明朗了再动手？”很多大公司都是这种心态，他们觉得“这太疯狂了，我们先按兵不动，等尘埃落定再开始跟进开发”。你当然可以这么做。
但我认为——这也正是我们的做法——一旦你选择了等待，等到尘埃落定时，你可能早就被远远抛在后面了。你必须不断抬头看趋势，努力跟紧它。你必须发布产品，让它接受现实的毒打，从像我们这样的一线客户那里获取反馈，搞清楚哪些行得通、哪些行不通。
正如我们常说的，“发布（Shipping）本身就是一种研究”。我们通过发布产品来验证猜想并帮助客户。我们绝不能说：“因为我不确定这个功能是否能活过接下来的三个月，所以我们就不发布了。”这不是做事的方法。你必须把它推向市场，亲自和客户一起见证它的成败。
Quinn: 说得好。我们绝不是那种会坐以待毙的人。时间差不多了。这一期聊了这么多翻天覆地的变化。还有什么想对用户说的最后寄语吗？
Thorsten: 祝大家编码愉快（Happy coding）。
Quinn: 祝大家黑客行动愉快（Happy hacking）。再见。
Thorsten: 再见。 (音乐)