Claude Code 唯一对手！？AI 编程黑马 AmpCode 崛起的秘密：不设 token 上限，放手让 AI 自己死磕代码

编译 | 平川、Tina

近期，AI 编程领域又一匹 AI Coding 黑马正在快速崛起。在一次对主流 AI 编程产品的评级分类里，唯一与 Claude Code 并列 S 级的，是 Sourcegraph 最新推出的 AmpCode，而爆火的 Cursor 也只排在了第二档次的 A 级。

那么，AmpCode 究竟有何独特之处？Sourcegraph 工程师 Thorsten Ball 在近期一档播客中分享了这款产品背后的理念与 AI 编程的范式转变。

Thorsten 透露，AmpCode 的研发实际上早于 Claude Code 的发布。两者虽独立发展，但在智能编程助手的核心设计理念上却不谋而合。在他看来，AmpCode 和 Claude Code 目前代表了最具“代理性”（agentic）的 AI 编程产品：它们不仅能调用工具，还真正“参与”开发流程，具备高度自治能力。

而与 Cursor、Windsurf 等交互过程不够直接的产品不同，AmpCode 在架构设计上做出了关键决策：

“我们选择了放权——把对话记录、工具访问权限、文件系统权限全都交给模型，然后放手让它去做。”

Thorsten 表示，这种“让出控制权”的方式极大释放了大模型的潜力，也重新定义了开发者与 AI 的协作边界。这一大胆的设计思路也得到了不少一线开发者的共鸣。

“我一直挺喜欢 Cursor，但它的代理能力远不如 AmpCode。Amp 像是一位资深工程师，而 Cursor 更像一个不太听话的实习生。”

—— Jeff Haynie，Agentuity 创始人兼 CEO

我们翻译了这期播客，全文可见下文（有部分删节）：

让 LLM 像工程师一样“死磕问题”

主持人 Jerod Santo：你 4 月在 ampcode.com 上写的那篇《如何构建一个代理》（https://ampcode.com/how-to-build-an-agent）给我留下深刻印象。它用 Go 逐行讲解了一个简单却实用的编码代理，帮我理解了代理的工作原理。能说说你写这篇文章的初衷吗？也许能让听众了解，想在本地跑一个代理其实没那么难。

Thorsten Ball：当然。我写那篇文章，是因为我被模型的表现震惊到了，忍不住想分享。当时我在 Sourcegraph 内部写了份文档，后来整理成了这篇公开博文，反响很好，可能是我有史以来最受欢迎的文章之一。

起因是我和 Sourcegraph CEO Quinn 一起研究后来的 Amp 项目，用的模型是 Claude 3.7 和 Sonnet 3.7。我们发现这些模型已经强大到，你只要给几个简单的工具，比如读取文件、列出目录、执行终端命令，它就能开始自动写代码了。以前需要很多繁琐设计，现在只需提供能力，模型自己就能推理并完成任务。

有次我让模型改一个文件，虽然我没给它“编辑文件”的工具，但它竟然用 echo 命令修改了文件内容。它理解了我的意图，并找到了替代方法实现目标。当时我坐在编辑器前，彻底震惊了。这是一次“我好像看到了 AGI”的时刻，虽然只是玩笑说法，但它展现出的智能确实令人印象深刻。

为了传播这个发现，我写了这篇文章。它只用了约 300 行代码，读者纷纷跟我说，他们用 Python 等语言实现了自己的版本，也有不少人说“我也有类似的震撼瞬间”。

这篇文章受欢迎的原因之一，是它很“去神秘化”。你不需要看一堆 Karpathy 的视频去理解代理，也不需要研究神经网络原理。只要了解 LLM 是怎么通过对话调用工具的，写点代码，跑一下，你就会恍然大悟。很多人跟我说，看了文章后才第一次真正理解了“代理”。

主持人 Adam Stacoviak：你刚刚说“感受到了 AGI”，这是什么意思？你是认真的吗？

Thorsten Ball：只是半开玩笑，我并不是真的在说 AGI 实现了。我想表达的是，这种模型已经可以结合反馈，自主采取合理行动，解决实际问题。比如说“重启 Nginx”这种命令，它会检查 sysctl Nginx restart。如果命令失败、没有响应，它会查看错误信息，然后尝试其他方法。我见过这种情况：它会说，“等等，Nginx 真的在运行吗？我先查一下。”接着它会运行 ps 命令找出 Nginx 的进程，获取对应的 PID，然后再去 /proc 目录里找出这个进程对应的可执行文件路径。基于这些信息，它最后会回到终端，执行类似 “restart my Nginx” 的命令。

关于 AGI，我们当然可以讨论它究竟是什么、又不是什么。但我一时找不到更准确的词来描述这种情况：模型观察自己正在做的事情，查看了记录并根据 feedback 采取行动，最终设法完成目标。这虽然不一定是 AGI，但……谁知道呢。

主持人 Jerod Santo：你提到你看了“记录”文件，那是什么？里面有什么？

Thorsten Ball：记录文本就是整个对话过程的完整记录，包括每次的用户输入和模型回复。工具调用的机制其实也不复杂：你事先告诉模型，“当你需要读取文件或执行命令时，请以某种格式回复”。它就像你跟朋友说，“你一眨眼我就抬手”，然后你们以这个规则沟通。模型只是按设定好的协议格式发出“调用工具”的信号，背后并没有魔法，整个流程其实非常透明、可控。

主持人 Jerod Santo：我喜欢这个类比。

Thorsten Ball：所以你只需告诉模型“你是编程助手，有三个工具：读取文件、列出目录、执行命令”，然后开始对话。当用户说“帮我看下 readme”，然后模型说“让我读一下那个文件。就像是说，这就是我想做的事情。”实际上，你把这个发送给提供商，给 Anthropic、谷歌、OpenAI，然后返回了响应，说“助手或模型没有完成任务。它想调用一个工具。”然后你看它具体想调用什么工具。然后你“执行工具”，只需用给定的参数运行那个函数，然后你把结果发送回去。所以这很简单。如果你在 UML 图上画出来，这很简单。其魔力在于通过这种方式能够实现多少功能。

所以如果我们回到第一个例子，你会问——你有三个工具：列出文件、读取文件和运行终端命令。然后你说，“这是什么项目？”这就是你要问的。然后模型——这就是为什么我一直在说，就像我们一样——会做的是，“好吧，让我列出文件。让我看看这个目录里有什么。”然后你执行列出文件的操作，把执行结果发送回去……可以只是一个字符串的列表，或者是一个包含换行符的字符串。或者只是 ls-l 或类似的东西。有了这个文件列表，它自己就会说，“哦，我看到你有一个 go.mod 文件。”或者“我看到你有一个 package.json 文件。”或者“我看到你有一个 pnpm 日志文件。我假设这是一个 Web 应用，因为……让我在另一个文件中查看你是如何定义的，或者这个文件中包含了什么，它是如何被记录的。”然后它自己继续探索其他文件。再说一次，我想我在过去的 20 分钟里已经说了 18 次了：这太震撼了。真的，很疯狂，这些小小的工具能够实现这么多功能。

主持人 Jerod Santo：有趣的是，这是一个非常基础的算法，对吧？

Thorsten Ball： 是的。

主持人 Jerod Santo：就像是说，“循环直到你找到了解决方案。”

Thorsten Ball：是的。

主持人 Jerod Santo：其实我们人类工程师解决问题的方法，无非就是坚持还是放弃。而这玩意儿（LLM）不会放弃，它只会用蛮力不断尝试。

如果你问我，“Jerod，我需要解决一个问题，比如读取一个文件”，我会先试试最常见的办法。如果不行，就再换一个思路，再试一遍。一直试到所有办法都试过了。如果还没解决，我就去问朋友、上 Stack Overflow，或者现在，我可以问 LLM，获取更多思路——“给我更多方法，直到我搞定。”

过去几十年来，一个优秀程序员的标准就是：在遇到问题时，你能坚持多久直到解决。有些人会中途放弃，另一些人则坚持到底，并在过程中积累经验，慢慢能更快选中对的方法，提前跳出循环。

其实这就是个很简单的算法：“不断尝试，直到成功。”它的本质是用蛮力反复尝试，直到奏效。而 LLM 能做得更快、更广泛，因为它掌握了几乎所有做法的索引。它没有自己发明什么新方法，只是用速度和覆盖率震撼了我们。

这也正是让人惊讶的地方：它尝试了我没想到的办法，而且做得极高效。所以“震撼”这个词，我觉得非常贴切。

Thorsten Ball：关于这个算法的简单性，我们这几个月一直在讨论的一点是——其实在过去一年里，我们看到很多原本依赖工具实现的功能，现在已经被整合进模型本身了。我的意思是，一年前，这些模型在工具调用方面还不太行。那时候你可能会说：“这是这个文件的内容，你能帮我编辑一下吗？”然后模型会回复你，你还得反复提示它：“请用这种特定的 diff 格式回复。”接着你需要自己解析这个 diff，再手动应用，或者调用另一个模型去应用。

而现在，这些能力已经融入模型内部了。你只需要提供工具，它就能自己完成这些操作。看起来就像一个简单的 for 循环。

有趣的是，如果你去问一百个工程师，有一半会说：“这不就是个 for 循环嘛。”而另一半则会笑着说：“这不就是个 for 循环嘛……太疯狂了。”

现在一切都在模型里了。你只要输入五个指令，然后问它：“接下来我该做什么？”它就会试着做另外十五件事——因为它能从先前的上下文中推断出，接下来最合理的动作是什么。我现在都不想再用“疯狂”这个词了。只能说，这真的太离谱了。

Amp 如何适应快速演化的模型

主持人 Jerod Santo：这背后显然是个巨大的机会，Sourcegraph 正在抓住它，其他公司也在行动。我们知道 Google 刚加入战局，OpenAI、Anthropic 也都在做，开源阵营也很活跃——说明这个方向既有价值，也有潜力。你是 Sourcegraph 内部项目 Amp 的创建者之一。几周前我们和 Steve Yegge 聊过，他提到可以试试 OpenAI Codex、Amp、Claude Code 等不同组合，会有不一样的体验。正如 Adam 所说，我们今天就想深入了解 Amp。当然，Gemini CLI 也值得一提——这个月刚发布，你可能比我们更早体验了。我刚下载，觉得挺有意思：免费、开源、无限使用，谷歌果然一出手就不简单。不过先说说 Amp 吧。Sourcegraph 是怎么定义 Amp 的？Steve 一直说这是面向企业的解决方案，我也想听听你怎么看。

Thorsten Ball：Amp 是在今年 2 月构建出来的，现在想来好像已经是很久以前的事了。那时正是一个转折点：Claude 3.7 发布后，人们突然意识到，大模型在工具调用方面的能力已经非常强大了。你可以非常快地把一个原型跑起来——这也是我们写那篇博客的原因。而 Amp 的基本假设就是：只要你不去限制模型的发挥，它的表现会非常惊艳。

我们做的就是给模型足够的 token。这也是为什么 Amp 的定价可能比其他产品更贵——我们没有强行去匹配什么“20 美元/月”的订阅价位，也不做输出限制或精简 token。我们选择的是：给模型足够的空间，给它一套精心挑选的编程工具，让它跑起来，别挡路，把控制权交还给模型。

项目刚启动时，我们自己也很惊讶它的效果有多好。很快，Quinn 和我就开始用 Amp 来构建 Amp，我们整天互发消息：“太厉害了，它又自动完成了这个、那个。”可能没人会相信，但我们其实是在 Claude Code 发布之前就开始做这套东西的，后来 Claude Code 才发布。我现在仍然认为，在所有这类工具里，只有 Amp 和 Claude Code 是最具“代理性”（agentic）的。

当然，Cursor 和 Windsurf 也是很出色的产品。但它们的代理模式感觉慢一些，用户与模型之间还有某种抽象隔层，交互过程显得不够直接，像是被包了一层壳。我们当时明确做出了一些不同的产品决策，比如说：不要每次修改都手动确认；不要剥夺模型访问文件系统的能力；也不要限制它修改之前的对话内容。相反，我们选择了放权——把对话记录、工具访问权限、文件系统权限全都交给模型，然后放手让它去做。

我觉得现在越来越多的人开始意识到，这种方式真的很强大。

那么 Amp 是给企业用的，还是给个人开发者用的？我是个个人开发者，我非常喜欢用它。我认识很多个人开发者也同样喜欢。

谈到企业级应用，我认为关键在于，Sourcegraph 在与大客户及全球顶尖软件公司合作方面的专业经验，为我们赢得了客户的信任，使我们具备了根据他们的需求构建东西的能力。我们知道他们的代码库是什么样子。我们看到，他们拥有的成千上万的大型存储库。那在其中发挥了作用。但我不会做这样的市场定位，“好吧，Claude Code 是为个人开发者准备的，Amp 是为企业开发者准备的。”对我来说，Amp 是为所有人准备的。每个想要强大工具的人。

听起来确实有些疯狂，但我们现在已经进入了这样一个时代：个人开发者每个月愿意为 AI 编程工具花上几百美元。你们俩也在这个行业很久了，应该知道这意味着什么。放在两年前，如果我跟你说“一个开发者为了业余项目，周末会花 50 美元买 token 来写代码”，听起来简直不可思议。

但我们已经接受了这样的变化。这就是如今提升生产力的方式。这就是现在写代码的常态。

所以如果你还在说，“个人开发者用不起这个工具，每次最多只能花五美元、只能跑几个请求”——那 Amp 可能就不是你要找的。Amp 是为那些想要最强 AI 代理、愿意为其付费、然后放手让它跑的人准备的。

还有一点是从更实用的角度讲：Amp 是一个命令行工具（CLI 应用），也有 VS Code 插件，支持 VS Code、Cursor、Windsurf、Codium，甚至连 Firebase 的 Web 版 VS Code 也能用。你不需要换编辑器，也不需要换 IDE，直接就能上手。

还有一点是 Amp 与其他工具的重大区别：我们有服务端组件。这意味着你和模型的所有对话都可以和团队成员共享。他们可以看到你是怎么使用代理模型的，可以生成对话链接，也可以看到使用情况排行榜，比如每个人烧掉了多少 token、生成了多少代码行数……

这在大型企业里特别受欢迎。你可能想不到，但我们后来发现，大企业内部其实存在一个巨大分歧：一部分人已经意识到这些工具的强大之处，积极推动在工程组织中推广；另一部分人则非常怀疑，使用效果也差距明显。

所以当我们向客户（或潜在客户）展示说：“看，Amp 不仅能做这些操作，还能分享 prompt、对话记录和结果”，他们会立刻说：“太好了，这样我就能把用法分享给团队其他人，告诉他们我是怎么写提示词、怎么建立反馈机制的。”

这就是我们产品的大致轮廓。

还有一件我认为非常重要的“元”层级的事是：我们一开始构建 Amp 时就假设——每一周模型都有可能变得更强大，很多原本需要外挂工具处理的能力又会内化进模型本身。所以我们必须随时准备好迭代产品。

你们如果采访过 Sourcegraph CTO Beyang，他几个月前说过一句让我印象深刻的话。他说：

“在 AI 驱动的时代，过去 15～20 年里创业公司用的那套‘试错-找到产品市场契合点-规模化’的老剧本，可能已经过时了。”

因为现在，可能你刚刚找到了 PMF，下一波技术就来了，直接把你现有的优势掀翻。你根本没法说“我们定住了、可以开始扩张了”，你必须随时准备随着技术变化而调整。我们正在经历的是一个技术持续剧变的时期。

所以我们从一开始就接受了这种节奏。我们构建产品的方式是：尽量“让开”，别挡住模型本身的能力。我的比喻是：在模型周围搭建轻量的、木质的脚手架，当模型变得更强时，脚手架自然会坍塌，用户就能重新获得模型原始的全部能力。

这也是我们一直秉持的产品哲学：保持简洁、灵活、快速响应。

AI 编程助手中的模型选择器应始终作为一个选项存在。包括 AmpCode 在内的几家公司坚持认为，模型选择器并不是必需的。我尊重这种大胆的立场，但我对此观点非常不认同。

哦对了，我本来一开始就该说——我们没有“模型选择器”。我们会根据当前任务自动选择我们认为最适合的模型，并随时准备切换。如果明天出了更好的代码模型，我们会第一时间采用。

我们的目标不是让用户在“高端模型”“低价模型”“快速模型”等十几个选项里选来选去，也不是让用户在 ask 模式、planning 模式、execution 模式之间切换。我们要说的是：“就按这个方式来，这是最好的。”用户无需操心，我们自动帮你选出最优模型。

目前我们底层用的是多家模型提供商的组合，但目标只有一个：为用户提供最佳体验。

企业内部为何存在分歧与怀疑？

主持人 Jerod Santo：让我问你一个问题。你之前提到企业内部存在分歧。姑且用“信徒”和“怀疑者”来形容吧。也就是说，有看涨派和看跌派。有许多人和组织在向着这个方向努力。但也有很多人非常怀疑，原因各不相同。对于怀疑论者，你听到的论点是什么？也许你能为他们辩护，而不是简单地否定。企业内部的怀疑者对这些工具及其未来持怀疑态度的原因是什么？

Thorsten Ball：我不太想刻意区分企业用户和其他人，我们就泛泛地聊一聊吧。去年，我在意大利参加了一个 Rust 会议，期间和一位资深工程师聊了起来。他在过去 20 年里做出过很多非常出色的技术贡献，显然是位非常厉害的程序员。

当时我正在研究 Zed，我们聊到编辑器的功能，他问我：“你们有 AI 功能吗？”我说：“有的。”从他的语气我就能听出，他并不相信这东西有什么用。他接着问：“我可以把它关掉吗？”我说：“当然可以。”

然后我问他，“你之前用过 AI 吗？我挺好奇的。”他说，“我一两年前玩过一次，但它只给我一些垃圾。”我又问，“你当时用的是 ChatGPT 吗？”他说是“某个网站”。

这给我留下了深刻印象——完全没有兴趣，也没有一点好奇心。他的态度是：“我试过一次，不好用。”就彻底放弃了。

我觉得现在很多人已经对这些技术有些麻木了，就像有些人对加密货币或者区块链已经失去了兴趣一样。有一部分人已经完全不关心 AI 的发展了。每当他们听到“AI”这两个字，眼神就开始发散，注意力完全飘走了，根本不会去了解接下来发生了什么。我认为这是个大问题——不是他们认真了解过这些东西然后判断“不适合我”，而是他们根本没有意识到过去几年里这个领域已经发生了多么巨大的变化。这是我观察到的一个方面。

另一个有趣的现象是，有人用钟形曲线（bell curve）来比喻当前 AI 在工程师群体中的接受度：初级工程师在这波 AI 热潮中获益最多，因为他们原本掌握的知识还不多，AI 帮他们处理了很多繁琐的事情——比如，他们从来不需要自己去学怎么用 CSS 实现元素居中。

然后，在钟形曲线的另一端是资深工程师，他们也从中获益良多，因为他们知道很多，基本上知道如何审查 AI 在做什么，他们知道哪里有陷阱，以及应该写什么测试，不应该做什么，以及如何设计这个东西的架构。

但在钟形曲线的中间，有一类人处境就比较尴尬了：他们正在努力提升自己的技能，想学会所有这些东西，因此对“AI 接管方向盘”这类行为感到不安。他们会说：“我不知道这里发生了什么。我希望搞清楚。我不理解这个过程。”他们会有质疑。

这其实正是很多企业中员工的真实写照。

第三个问题是：你必须真正去学习和提升自己。你必须在这方面变得更擅长。

很多人在第一次尝试使用 Agent（智能代理）时，可能不会立刻获得惊艳的结果。在小规模场景下，有些人确实做出了一些令人惊叹的事情，但也有不少人会失败。

我认为这就是一个现实问题——过去几年间的炒作和市场营销把这件事吹得太厉害了，比如“你只需要说一句‘给我建个网站’，它就能生成一个看起来很棒的网站。”大家的期望值被拉得太高了。

所以现在有些工程师在实际尝试时，会说：“修复这个分布式数据库。”结果发现，它做不到，它根本不知道该怎么修复。于是他们就会想：“哦，原来不行啊。”第一次尝试不成功，他们就会感到失望，随后就直接放弃了。

最近，我想是在上周，Mitchell Hashimoto 说，“你什么时候只用了一天工具就变得更有生产力了？”你必须投入一些努力。你必须在这方面变得更好。我认为这是一个问题。这些模型被拟人化了，我也有责任。

还有一种常见的思维方式是：“哇，这些东西好聪明，简直像人类，已经接近 AGI 了。”但现实是，这些系统本质上还是基于 Transformer 架构的大型语言模型。

它们有自己特定的处理机制：根据你提供的上下文生成输出。但它们并不是无所不能的，也不是全知的。你必须清楚地知道，哪些信息该放进上下文，哪些不该放进去——否则，它们很容易跑偏，做出错误的判断或回应。

所以有一个学习曲线，但不是像网上有人告诉你的那样。没有人说，“我们有一个学习曲线。这太棒了。”在过去的 20 年里，软件领域的说法一直是“学习曲线不好”，比如 Vim 的用户。

放弃 Vim 转投 VS Code 的怀抱

主持人 Jerod Santo：你现在还在用 Vim 吗？我听说 IDE 要消亡了。我的意思是……你不是已经让 Amp 来接管了吗？

Thorsten Ball：是的。这是个热门话题。

主持人 Adam Stacoviak：所以，到底还用不用 Vim？直接说，是或不是？

Thorsten Ball：不用了。我现在在 VS Code 里用 Vim 模式。但说实话，我已经不怎么亲自写代码了，这真的挺疯狂的。

主持人 Adam Stacoviak：麻烦再说一遍。讲得更清楚些。

Thorsten Ball：好的。在过去一年半的时间里，我在 Sourcegraph 工作时，开始想尝试一些新东西。我当时的目标是尽可能“硬核”，成为那种特别厉害的程序员。

后来我去了 Zed，我们从零开始用 Rust 构建了一款文本编辑器，连 GPU 框架都是我们自己做的。团队里全是全球顶尖的程序员，代码库非常惊艳，产品本身也很出色。我当时觉得自己已经触碰到了编程的“核心”。

但随着 AI 的发展，我开始尝试一些新工具，比如 CursorTab。有一次我坐在那儿，正好我们在为 Zed 做补全功能，我要搞清楚竞争对手都在做什么，比如制表符补全、AI 补全等。我用了 CursorTab，正改一个 switch 语句，做一些重复性的工作。以前我会花心思写一个漂亮的 Vim 宏来解决。而现在，我会在 switch 语句的某个分支中输入控制台日志或类似的东西，然后它会说，“哦，你也想在这里添加这个吗？”我只需按下 Tab 键。

我连续按了 10 次 Tab，整个改动就搞定了。当时我坐在那儿，心里想：“靠，这比我用 Vim 自己写快多了。”

比如你要处理一个 CSV 文件，要删除最后一列。我以前的做法是在 Vim 里用普通模式跳到结尾，删除，或者写个宏，然后执行 990 次。现在用这些模型，我只要删掉第一列，它就会问：“你是想删所有列？还是最后一列？”我一按 Tab，就解决了。太疯狂了。这真的改变了很多事情。

然后我也开发 Zed 补全功能，我们自己完成了构建，并意识到“我不是 ML 专家”。和我一起工作的 Antonio 可能是我合作过的最好的程序员，但他也不是 ML 专家。但我们能够构建出与 CursorTab 同等质量的东西。我就想，“这真的要改变很多东西。”像开源模型，你可以使用 Qwen，或 DeepSeek，或其他任何东西。如果你能将这个变成一个补全模型，编辑代码的速度会比一个非常擅长 Vim 的人（我自己）还要快。那这说明什么？这说明开发工具必须变革，整个编程体验也要改变。

那一刻，我突然有个想法：我是不是在给马车做轮子？但我也不知道怎么说才不冒犯人。

主持人 Jerod Santo：但 Vim 确实是一个非常好的文本编辑器。它真的很棒。

Thorsten Ball：是的，它是一个令人惊叹的产品，但问题是，在 Zed，我曾与 Conrad 一起使用过 Vim 模式工作，所有功能都令人惊叹，但最终你还是会想，“我要变得高效。” 我不是那种因为宏和键盘快捷键而热爱编程并追求速度的人。我喜欢高效地完成事情。比如，我喜欢提高效率。

突然间，我意识到，我之前在 Vim 中使用的所有宏都有些过时了，因为在其他编辑器中，我只需连续按下 Tab 键就能轻松处理这些繁琐的任务。这改变了很多事情。这改变了我对开发工具的看法。

总结一下，基本上，我看了其他公司，与不同的人进行了交流，最终我回到了 Sourcegraph，因为我与 Quinn 进行了交谈，并向他讲述了刚才告诉你们的一切，我对他说，“老兄，一切都在改变。”他回应道，“你想来这里共同构建未来吗？我同意你的观点，很多事情都在发生改变。”

现在，我在用 VS Code，这是我从未想过的事情，我也不喜欢 VS Code。从审美角度来说，我不喜欢它。我也意识到我不再那么在乎了。我和很多人进行了交谈，包括 Sourcegraph 的同事和我在旧金山遇到的人，或者在会议上遇到的人，他们也使用 Amp 或者 Cursor、Windsurf。至少有五个人跟我说，“我曾经是一个铁杆的 Vim 用户，但我转而使用 VS Code/Cursor/其他东西，因为我意识到，它能把效率提升 10 倍，其他东西就不再那么重要了。”

如果你问 Primeagen，或者其他人，他们肯定会因为我这么说而骂我。但我有种感觉，很多人也有这种感觉，那就是在编辑器中快速机械运动的时代有点要结束了，因为这些模型更快。未来的话，这些东西会变得更快、更便宜，也许肯定会在你的笔记本电脑上运行……然后，你不再需要 Vim 键绑定，不再需要 Colemak，你只要和你的电脑说话。

Vim 和 Zed 是过时的马车？！

主持人 Adam Stacoviak：好的，你刚刚提到了“马车”的比喻，我想回到那个点上。先说清楚，我完全没有冒犯的意思，我只是想认真思考这个问题。作为一名播客主持人，我试图认真倾听，也在思考我们正走向何方，试图理解这个比喻的深意。

但你真正让我思考的是：“我今天到底该怎么做？”很自然地，我会选择最简单、最方便的方案，因为那已经极大地改善了我的生活。

最直观的例子是什么？交通工具。比如今天早上，我送孩子去夏令营。我没走路去，也没坐马车——我们开的是那辆“新马车”F-250，一辆柴油卡车。虽然它可能还不算最新最现代的技术，但它确实比马车快太多了。

我们开车往返，从 A 点到 B 点。过程中我完全没有因为我的曾祖父可能是骑马出行就感到难过。那是他们的时代，他们喜欢那样，但那个时代已经过去了，对吧？现在没人那样出行了。我就是开车，就这么简单。

你让我意识到，这其实就是一个最显而易见的选择——一旦体验过现代化的便利，我们很难再回到过去的方式。除非有一天我退休了，在牧场上无所事事，有闲钱买马，骑马消磨时间，那可能另当别论。但如果说哪个方案显然更高效，那肯定是更快的交通工具，这就是现实世界的趋势。

Thorsten Ball：我觉得你说得非常好。而且这里其实还牵涉到一个“代沟”的问题。我记得去年在慕尼黑某所大学做了一次演讲，来听的很多人年纪都比我小不少。我们聊到了 AI，聊到这代技术对编程的影响。

很多人提出疑问，比如：“这还算是‘真正的编程’吗？”“如果我用了 Cursor、Cody、Windsurf 这些工具，是不是就不算自己写代码了？”还有人担心：“我是不是会变笨？用这种方式学习对吗？”或者更具体地说：“如果不是我亲手敲出来的，那还算‘手工代码’吗？”

我和一群年轻人聊了一阵，突然意识到：他们根本不在乎这些争论。对他们来说，这些讨论早就过时了。他们从来不会想：“我的代码不算真正的代码，因为我没用 Emacs 写。”他们更关心的是怎么更高效地完成工作。

他们会告诉我：“我用这种方式整理文档，方便我用 Cursor 快速调用需要的东西，我还有个规则库，这样组织更轻松。”他们甚至不会花两秒钟去思考“这样做对不对”，因为这就是他们自然的工作方式。他们是与 AI 一起长大的一代人。如果编辑器不支持某功能，他们就去问 ChatGPT、Claude，或者别的模型。

就像 1965 年时有人质疑：“用电吉他还算真正的音乐吗？”——结果证明，年轻人完全不在乎，他们根本不想听这种争论。他们已经在看向未来了。

所以正如你说的，这是一个代际变化的问题。如果你现在去任何一所大学，找一个正在学计算机或在业余时间写代码的 20 岁年轻人，我敢保证他们正在使用 AI，而且丝毫不会去纠结“这是不是正统的编程方式”。对他们来说，这就是他们的工具，这就是当代的编程。

主持人 Adam Stacoviak：尽管我们想留在过去，但未来无论如何都会来。时间是线性的，我们无法停止。我们只拥有当下这一刻。过去已经过去，我们无法改变，因为我们能做的只有把握当下这一刻，而未来无论如何都会来。如果写代码或软件开发者不再使用 Vim 了？如果甚至不再使用 VS Code 了？如果使用的是这些工具演变而来的版本？

Thorsten Ball：是的，我 100%同意。

主持人 Jerod Santo： 你知道吗？如果你是个 Vim 的铁杆粉丝，那听到这些话可能真的会有点刺耳（笑）。虽然我在开玩笑，但说到底，这种“认同感”本身其实就是一种负担。我们真正需要改变的，也许正是这种认同。

就像有些人对自己青春期听的音乐，或成长阶段喜欢的乐队特别有感情，对当下的音乐却提不起兴趣——那是因为它承载了我们的身份和情感。而我们使用电脑做的许多事情，也同样映射了我们是谁、我们在意什么。我们会通过自己选择的工具、编辑器来表达这些认同。

所以这就是为什么会有那么多关于编辑器的激烈争论。归根结底，是因为我们在乎。如果我们根本不在乎，也不会花时间去争论。正因为我们关心，所以当你把 Vim 或 Zed 比作“马车”时，我们自然会有反应。即使你没有冒犯的意思，那也确实可能让一些人觉得不舒服。

除此之外，我觉得还有一种更理性的怀疑，它源于很多人经历过太多“新潮技术”的起起落落。要不是因为我做播客，经常从这个视角来观察这些趋势，我可能早就放弃追踪 AI 相关的东西了。如果你有时间翻翻过去的节目，会看到我的态度其实也在变化。一开始我对这些工具的体验很差，我的反应是：“这有什么用？纯粹是干扰。我还是继续手动写代码吧。”但随着时间推移，我持续关注它们的发展，最近才真正意识到：“哇，这太厉害了。”我开始真正被它震撼。

不过，我也很容易回到过去的那种思维模式，因为我见过太多曾被吹捧为“有前途”“颠覆性”的东西，最后都没能兑现承诺。所以，这种怀疑也不是完全没有道理的。

我想回到你刚才说的关于“阻力”的话题——那些还没有完全接受这波浪潮的人，他们的心态，其实我也能理解。

然后，你提到了钟形曲线。人们称之为中智梗，就是中间的那个人自以为最聪明，看法却最糟糕。就像初级的人因为不同的原因理解了，高级的人也理解了，而中级的人却不理解。我认为，在这种特定的情况下，这是因为技能的问题。比如说，Vim 是一种技能。你花了很多精力去学习。也许对你来说，它很容易，但对大多数人来说并不容易。因此，这里存在一些沉没成本谬误，“我已经为这些技能付出了很多努力。”

如果你看那个钟形曲线，初级没有任何技能，所以他们不在乎。他们会说，“酷，这帮我做了我做不到的事情。”至于高级，如果他们始终保持好奇心并具备良好的自我认知，他们就会意识到这些技能只是实现目标的手段，而真正重要的是目标本身。有了这个工具，他们会更强大，可以更好、更快地达到目的。我花了很多时间学习 Vim。然而，在我认为对我来说它不再是最好的选择时，我会把它放在一边。

但是，当你处于那个钟形曲线的顶峰时，你已经花费了大量的时间、金钱和努力来尽可能地提升你的工程技能。所以对你来说，说出“这些技能实际上不再那么有用，不再那么有价值”是最难的。我认为，对我们很多人来说，这只是一种伤害。

Thorsten Ball：我认为，这里面有很多身份认同的问题。就像你说的那样，人们认同，“我是那个从来不需要查找 Rust 方法的人。我是那个知道所有语法的人。我是那个非常擅长 Vim 的人。”再次以你提到的高级工程师的为例。我想你可以确认这一点，作为一名高级工程师，有时候你会意识到，代码并不是那么重要。比如，市场营销、商业、团队以及你如何发布产品也很重要。

主持人 Jerod Santo：对。除了代码之外，还有其他很多重要的东西。

Thorsten Ball：代码当然重要，但你最终会意识到，它有时候甚至可能成为一种负担。我觉得在工具这件事上，人们的经历往往也会经历类似的变化。

我一开始就有过这样的体验。我当时非常擅长使用 Vim，为此感到特别自豪。我曾经坚信：“每个真正优秀的程序员都应该用 Vim。”

后来我有一位资深同事，他用的是 Sublime，几乎没怎么配置快捷键。但他的速度依然非常快，做了很多出色的工作，也总是能做出明智的决策。他之所以成为高级工程师，是有充分理由的。那时候我才意识到，也许决定水平高低的，并不是你用的编辑器。

我觉得这种情况在我们行业里经常出现。现在很多人把 AI 当成一把大锤，用它来击碎旧有的认知，说：“一切都变了。你曾经花大量时间投入的东西，现在价值没那么高了。”从某种程度上来说，这确实是真的，也确实很残酷。

面对这种变化，我们应当多一份理解和同情。我自己也经历过这种转变，并且为此挣扎了很长一段时间。

代码价值改变了，但程序员仍处于有利地位

主持人 Jerod Santo：是的。我认为我们必须认识到，为了接受这个残酷的现实，同时也要克服它并真正地利用它，并不是我们的技能没用了，而是它们失去了价值。但是，由于我们作为工程师的经历，我们有很好的机会比其他人更好地利用新工具，并且能更快地适应，当事情出错时理解出了什么问题。我们还能帮助 Agent 做得更好，而那是新手做不到的。即使它已经很好，你只需要告诉它你想要什么，它就会变得更好。我觉得，高技能的人也可以采用新工具，只要他们没有我们正在讨论的包袱，而且与那些根本不会使用工具的人相比，他们可能可以更有效地采用新工具。

Thorsten Ball：是的。Kent Beck 说过一句很棒的话，“我刚刚意识到，作为程序员，我能做的事情中有 90%现在都一文不值，而另外 10%的价值增加了 100 倍。”

有很多机械性的工作，比如，“配置哪个框架，如何配置，什么东西放入哪个配置文件，如何输入这个，如何做那个？如何构建一个 FFmpeg 命令？命令行参数是什么？”，所有这些东西现在都一文不值。

但是，要构建什么，何时构建，以及如何组织它，如何设计它的架构，拉入哪些依赖项，避免哪些陷阱，如何为将来的使用构建它，所有这些都是关于权衡的，是关于在一组约束条件下如何构建某物的决策，这些现在就非常有价值。现在，那才是倍增器，而不是你打字有多快。

主持人 Jerod Santo： 百分百正确。我今天早上刚跟孩子们说了这件事，作为父母和老师，我们也在努力摸索如何应对这些新事物。目前学校体系正经历巨大的变革。外面一团糟。有很多作弊行为太好了，以至于作弊检测工具都跟不上了。我对孩子们说的，我认为特别适用于我们的工作，两者有很大的区别，那就是使用 AI 帮助你思考，和让 AI 为你思考之间的区别。如果你让它为你思考，那么我们正朝着白痴乌托邦的方向发展，你将无法成功。但是，如果你用它来帮助你思考，那么现在，你基本上就是一个超人。

我认为，当涉及到编码时，情况非常相似。我们确实需要参与并做出那些决策以及评判结果，做所有对我们、我们的环境、我们的商业目标以及我们知道的事情而言都独一无二的事情，因为编码代理只需你告诉它做什么，它就会尽力去完成；它可能会比你做得更好，但它不能决定做什么。我们还没有走得那么远。

因此，利用这些工具帮助我们比以往任何时候都更好地构建，而不仅仅是为我们自己构建，而我们只是随波逐流。

主持人 Adam Stacoviak：我刚才只是在反驳这个观点，也许是针对那些有 Vim 纹身的 Vim 用户。你今天仍然可以通过 SSH 连接到一台机器。但这种方式并不常见了。通常，你会使用 CLI 来做到这一点，而在某个时候，你会有一个代理使用 CLI 来做到这一点。或者，也许今天你就应该这样做。不过，SSH 仍然存在，你仍然有用户名和登录，你仍然可以控制你如何访问 Linux 机器。这并不意味着你不能再使用 Vim 了。这并不意味着这些技能就过时了。你还是可以维护和管理你的 Vim 文件。

这些仍然是事实，但那是一个不同的世界，那里曾经是 Ultra X 程序员的生产力工具，而现在，在某种程度上，那种类型的程序员已经停滞不前，因为 Agent 可以比它运行得更快。或者像照看孩子一样照看 Agent。

这并不意味着 Vim 不存在，或者 SSH 不存在。你仍然可以通过 SSH 连接到一台机器。只是现在由 Kubernetes 来管理你的机器集群，而不是你手动逐一连接并配置每台机器。这与当前的做法截然不同。SSH 仍然存在，Vim 也仍然存在，只是使用方式发生了变化。

Thorsten Ball：我觉得你刚才讲的内容其实也触及到了另一个问题，那就是在关于“编程是否会被人工智能取代”的讨论中，很多事情都被笼统地归为“编程”这个概念。但事实上，世界上存在成千上万种不同类型的程序员。有的是在大型科技公司里开发分布式系统的，有的是在硬件公司做嵌入式系统开发的，有像我这样专注于开发工具的，也有从事 Web 开发或是构建 AI Agent 的程序员。

我住在德国的一个小镇上。如果我去拜访离我最近的一百位程序员，大多数人其实并不在软件公司工作，而是在一些传统行业里维护旧的 Java 程序。还有些人是在给客户做 WordPress 网站。

所以当我们说 AI 会改变很多编程工作时，有人会反驳说：“AI 连 Postgres 的存储层都改不了。”但我并不是这个意思。我的意思是，每天可能有上万次，有人打电话说，“你能不能帮我改下我们 WordPress 网站上的这个东西？”而那个去做改动的人——可能被称作“程序员”——确实需要具备一定的技能。但我认为未来这类工作将会发生很大变化。也许不会在几个月内，但在稍远的将来，这些边缘的编程工作会逐渐被改变。

再说回你提到的“通过 SSH 登录服务器”这类观点。云计算刚兴起时，很多人也说，“云其实就是另一台远程计算机，本质没什么变化。我们还是会需要系统管理员来运维。”确实，到了 2025 年，我们仍然有系统管理员，但这个角色的边界和方式已经和以前非常不同了。

主持人 Adam Stacoviak：是的，他们只是有些领域毕业了。

Thorsten Ball：完全正确。如果你看一下招聘系统管理员的工作职位的数量，我敢肯定，过去 15 年里已经发生了变化。我认为，其中一些变化也会发生在编程上。我认为，未来几年里，前端开发者的数量会有变化。但如果你在谷歌开发分布式存储层，那么不会有 Agent 在接下来的两年内取代你的工作。大概率不会。

主持人 Adam Stacoviak：是的，如果你是在这些真正比较边缘的领域工作，可能会更安全。

我认为，如果你处于 80%的领域，即 80%的开发是由一个普通的、很容易招聘到的典型开发者完成，那么这份工作更有可能被压缩或者代理化，而你变成一个保姆，你有品味、审美以及人文倾向，如关怀和人性。你知道，到目前为止，机器可能可以推理它，但并不能真正像我们那样感受它。

这确实是一个值得深思的问题。我也在思考你正在编写的代码的类型。你有没有使用 Amp 来增强？你能给我们更清晰地描绘一下幕后的情况吗？因为我问过你这个问题，而你似乎也提到了，基本上，你描述了你所做的事情，而不是它实际看起来的样子。写这种级别的代码是什么样子。我希望你描述下你的工作 ，不是关于 Amp 的研发以及你将如何发展这个平台，而是你作为一个训练有素的专业软件开发者的工作。你如今不是在写代码，而是尽可能多地生成代码，解决尽可能多的大问题。对你正在做的事情而言，这种描述准确吗？

Thorsten Ball：好的，我想我的头衔仍然是软件工程师。

我认为，作为高级工程师，我的工作是思考“如何实现？”在过去几个月里，我一直在想的是，“Agent 能为我编写这个代码吗？它能做这个吗？”

如果问题过于复杂，或者我脑海中存在大量无法用文字表达的隐性知识，又或者将这些内容写下来过于繁琐，我会采用“填色式编程”的方法，直接输入代码行。我会说：“我需要这个文件、这个文件以及这个新服务，它应该包含这些方法，并实现这些功能和参数。请为我编写这段代码。”

在实际开发层面，我认为我们代码库中大概有 50%，甚至 60% 到 70% 的代码，是标准的 TypeScript、Svelte 和 SvelteKit 代码。也就是说，整个代码库看上去非常常规，但其中很多部分其实是自动生成的。而真正承载主要功能、承担复杂逻辑的部分，通常是手写的，或者是基于生成代码进行过手工修改的。

我猜我们的测试套件中，大概有 90% 是自动生成的，比如只需要一句“覆盖所有这些情况”。我们还有一个现在已经相当完善的 Storybook，它就是一个 Web 服务，用来展示我们所有的 UI 组件，包括 Svelte 组件，还能显示它们在不同配置下的表现。

比如某个组件是一个“箭头二号”，你可以看到它当前的状态，比如是激活还是未激活。在一个页面上，就能预览这个组件在所有状态下的样子。再比如一个活动指示器，它可能是蓝色、红色、绿色，或者处于空闲状态，并带有一个工具提示。开发过程中，你当然会想知道，“这个组件在各种状态下具体长什么样？”

搁在以前，我要做的是创建 storybook 页面，创建一个版本，创建一些模拟数据，做一些 Vim 操作，将模拟数据复制到不同的状态和不同的配置中，然后渲染它。或者换个说法，你有一个测试套件，有一些模拟数据，比如“五个不同的用户。一个用户被停用，一个用户被激活，一个用户是管理员，一个用户是组管理员”。以前，你会用编辑器多次复制这些信息，或者编写其他辅助脚本来消除代码重复。但现在，我用代理做测试或者 storybook。像这样，“这是组件，这是我想渲染的位置”。或者，“这是我想做的测试。去为我打出这段代码。”大部分代理都不是超级智能；它不会提出惊人的新算法，它只是干家务活。

还有另一件事。人们一直在说，我没有意识到我在编程时做了多少无意义的输入。我们都听过这个说法，“思考是瓶颈，打字速度不重要。”但当你真正去做的时候，就会发现，打字仍然占了很大一部分，而这就是我试图消除的部分。我不是试图消除思考的部分。我知道结构是什么，代理帮我写出剩下的部分。

我给你一个两小时前的具体例子。我在 UI 中有两个组件，它们应该做同样的事情。其中一个有两个按钮，另一个有两个按钮中的一个。我们称这两个按钮为登录和注销按钮。一个组件只有登录，另一个有登录和注销。这是一个愚蠢的例子，讲不通。它们的按钮应该是一样的，都有两个按钮。“如果要做到这点，那么我必须从这里复制代码，更新导入语句，调整它，确保它是 Flexbox 对齐的，并且渲染正确，然后调整这个按钮的高度……”等等。

所以我就跟 Agent 说，“这个组件有一个按钮，这个组件有两个按钮。第一个也应该有两个按钮。请帮我实现。”它看着两个组件，很快就明白了，这个任务不难。它复制过去，20 秒后就完成了。我不需要自己打出来。

显然，这只是一个很小的例子。今天早些时候，我想建一个测试脚本，我有一些数据，我想逐个处理这些数据。对于每一条数据，我想运行它，发送到 API 并看看返回什么。我注意到，我的反馈循环是“启动开发构建，手动尝试，点击按钮，执行操作。”我想，“我可以构建一个工具，连续做 50 次，然后可以在同一页面上看到所有结果。”

半年前，我绝不会尝试这样做，因为我不想构建另一个东西，我得打出 300 行代码，我需要想出怎么做一个三栏布局。但后来我就想，“我可以生成这个。”如果我和代理说，“这个文件夹里是数据，这里是 API。为我提供输入 API 密钥的能力，然后给我一个网站，三栏布局，左边列出数据，点击一行，显示数据，然后你有一个按钮发送请求，然后就可以在第三个面板上看到结果。”我说完它就去做了。我不在乎它看起来怎么样，它有没有样式。它很有用，这就够了。

我再讲一个非常具体的例子，几个月前的。那是在 Amp 早期，非常早，还不是在生产环境中。

我们有的代理在编辑文件时会失败。所以用户会说，“它有时会失败。”而我会说，“这帮不了我。我需要数据。比如，输入是什么？磁盘上的实际文件是什么？发生了什么？”为了弄清楚出了什么问题，在过去，我会做的是找出一些日志，比如一些错误报告。借助 Sentry 或其他什么工具把它们变成我能读懂的信息，从而找出问题在哪里。

但随后我想到，“我现在手头有一个代码生成器，一个可以非常快地生成代码的机器。如果那个代码是一个独立的项目，不到一千行，那么 99%的情况下它都能搞定。”所以我做的是在代码中放了类似这样的东西，“如果你在 Thorsten 的机器上遇到这个错误，把原始数据转储。拿走原始数据，把它放在 Thorsten 的计算机上的这个文件夹里。”我只运行了两天，就收集了一千个文件。

然后我说，“Amp，我们来构建点东西。这里有一个数据文件夹。我想让你构建的是一个数据查看器。我想让你用 Go 语言构建一个小的 Web 应用，列出所有这些文件，取这两个字段，语法高亮显示它们，并显示这两个字段之间的差异。然后给我一个键盘控制，让我可以浏览数据。”它用了不到 45 秒钟就完成了。我打开网站，点击，浏览。我浏览了 50 个，通过查看数据，我发现了一个 Bug。我意识到，“这是一个空格问题。”因为有语法高亮和差异，所以我可以轻松地浏览这些数据。

我永远不会自己建这个，因为语法高亮非常令人讨厌。想到要处理 JavaScript 中的 diff、三栏布局，我会放弃的。但是使用代理或者一般的 AI，入门门槛降得如此之低，你可以构建你以前从未尝试过的东西。回到我最初会尝试的东西，比如日志等。假如你得到了这样的日志，“输入这个，输出这个”，只有这一行日志，你会从中发现一个空格问题吗？比如，“它用了两个空格而不是一个 Tab”。我不认为我能。但是，只说句话就能生成代码，这改变了我从工程角度处理这个问题的方式。

我认为，现在很多人都已经意识到这一点。昨天推特上有人说，他想知道“Markdown 文档的每一节中有多少个词”。过去你会怎么做？你会坐下来手动编写一个工具来完成这件事吗？可能不会。你立刻就会放弃这个想法。他对代理说，“Claude，给我写个单文件脚本，不管什么脚本，只要能完成这件事就行”。结果它做到了，而这仅仅是因为现在负担得起了。

那么现在，回到真正的软件工程。有多少测试、调试工具、测试套件、自省工具或分析工具是因为太费力了才没有编写？现在这些都变得负担得起了。我们开始意识到这一点，问题是，我们何时才能真正利用这些？我们何时会利用这些？

再进一步说，自 2019 年以来，我一直在 Sourcegraph 工作，中间休息了一年。很多大客户会问，“你能让我们的代码库用上这个吗？你能把你们的工具运用到我们的大型代码库上吗？”现在我们看到，人们越来越多地利用 AI 修改代码库。他们会说，“对于代理来说，这些文件太长了，上下文窗口放不下。我们把它分成五个文件吧。”我告诉你，两年前没有人会为了任何工具分割他们的文件。他们会说，“这就是我们的文件。”

这就像我们有 20000 行代码，没有人会碰。但现在情况发生了变化，这些工具能提供的杠杆也发生了变化。现在，代码库将随之适应。这是我的预测。代码库将适应这些工具。

对我来说，真正有趣的是，我们的工程实践会会有什么变化？我们会手写什么代码？我们会生成什么代码？再进一步想，会不会有我们不提交的代码，我们只提交提示，然后即时生成它？还是所有的代码仍然会被提交，谁知道呢？

开源的价值也变了？

主持人 Jerod Santo：这实际上为我打开了一个全新的思路，我以前没想过的。这对开源有什么影响？

因为我在想你说的情况，“在过去，那种一次性工具帮助我做别的事情”，就像是一个支线任务。就像你说的，“工作量太大。有它很好，但我不需要它。”或者我会说，“算了。我要写一个，然后开源，其他人也可以用它，对我来说就值了。”或者我会说，“好吧，让我们去看看别人有没有做过，看看我是否可以只是使用别人的。”也许顺序不一样。我可能会先去看看，然后再决定是否要构建它。

但在一个我们可以临时生成一次性工具的世界里，我们可以把它们检入代码库，也可以不检入，可以保留提示，也可以不保留，开源的数量会减少吗？开源工具还重要吗，因为我可以生成我需要的任何东西？你想过这个吗？因为我甚至没想过对开源的影响。

Thorsten Ball：让我们说实话，GitHub 的贡献不像十年前、五年前、两年前那么有价值了。我认为，在过去一年左右的时间里，它的贡献有一个急剧的下降。现在我在想，有了 AI，我为什么要还引入一个小包？为什么我要亲手编写它？为什么我要去某个地方查找一个格式化时间戳的函数？我可以直接问 LLM，“这是时间戳，这是所有的五种格式。如果你没有所有五种格式，这是命令。给我写一个程序，生成所有可能的格式。所以你看到了所有可能的格式，然后给我写一个函数来解析它们。”即使是代码作为一种减少重复的方式也不再是理所当然。

主持人 Jerod Santo：你开始质疑了。

Thorsten Ball：我举了个愚蠢的例子，有人会说“Thorsten 是个白痴”。但为了说明这个点，假设你有一个函数来验证某件事，你想确保它验证了 50 个案例或者 150 个案例。过去，最好的做法是打出这 150 个案例。你会写一个正则表达式或者别的什么，对吧？你会说，“不要用正则表达式，因为我们无法维护这个列表。”现在，有了 LLM，你可以生成 150 个例子。你可以添加代码编写时间，生成所有的变体。您无需让 CPU 处理所有变体。Web 框架的目标是帮助你减少需要编写的代码量。但如果生成的代码量虽然庞大，但速度快、成本低，那么当我可以直接说，“将所有用户的头像组件改为绿色”时，我是否还需要复杂的模板辅助工具？

主持人 Jerod Santo：DRY 原则变成了“Do Repeat Yourself（重复你自己）”。

Thorsten Ball：也许吧。很多代码以及我们编写代码的方式都是基于这样的假设：编写代码需要时间，而且难度大，我们要尽可能避免那样做。但现在，情况变了，因为我可以一键生成网站，还可以有 50 种不同的变体。

让我们回到开源那个问题。存储预生成的代码片段，构建可供 15 种其他用例使用和配置的库，这是否还有意义？你会把一个版本输入到一个 LLM（大型语言模型）中，然后生成自己的版本吗？这有点科幻，显然它还没有实现，但事情正在改变。

还有一件事，更进一步，这也是我认为我所在的行业如此有趣的原因之一。

Facebook 前工程总监 Eric Meyer 是一个 Haskell 爱好者，一个非常聪明的函数式程序员，已经编程 40 年了。两年前，他做了一次演讲。他说，“当你可以让一个 LLM 生成它，为什么还要搜索代码？”他的意思是，当你去搜索 Stack Overflow，搜索你自己或公司的代码库时，你想解决的问题是“构建一个用户头像组件或者类似的东西。”我们通常怎么做这个？因为你不知道或者你不想去做。但如果有一个模型知道怎么做，并且可以在不到一秒钟内完成，为什么还要去找那些例子？为什么不在这里生成这个？当你不需要去寻找它，而是可以即时生成时，事情就变了。

主持人 Adam Stacoviak：嗯，你所说的是，我们过去所做的效率或感知效率都是基于人类的效率。

对吧？我们认为编写共享代码很高效，因为这样可以更高效地创建新项目。为此，团队需要统一编码方式、标准等。这些都是效率提升的措施。但它们不再重要了。对于大型语言模型（LLM）而言，或者说开始生成代码的系统来说，情况就像是这样，“我无需担心 25 个应用程序如何以一种统一的方式连接，因为我可以随时随地编写代码。”

Thorsten Ball： 是的。我过去用过的一个比喻是，在书的最后，你有一个索引，里面有不同的单词，你可以快速查找。那个索引的存在是因为在书中找到那个特定的东西需要很长时间。如果你能以每秒 1000 页的速度阅读，你还需要索引吗？这个东西本身是与现在的使用方式相匹配的，但如果方式突然变了，为什么还需要在书的最后有一个索引？我认为，很多代码就是这样的。它有赖于我们编写和消费代码的方式，以及编写难度。但当能力改变时，工具或我们用这些工具生成的东西也会改变。

主持人 Jerod Santo：孩子们会完全理解这一点。孩子们是 AI 原住民，他们不会问这些问题，因为他们将在一个没有这种限制的世界中长大。他们会说，“为什么你必须有一个共享库？当我可以告诉我的代理创建一个新库时，我为什么要共享我的库？当我可以重写，我为什么要重构？或者当我可以替换，我为什么要维护？”

维修汽车是因为替换很贵。但如果替换的成本接近零，为什么还要维修？

Thorsten Ball：我说一个有趣的例子。我开始构建这个是因为我发表的博文引起了人们极大的兴趣。这有点哲学意味，但归根结底，我们在使用计算机时所做的大部分事情，都是将信息以特定的形式和结构呈现，以便计算机能够处理。例如，静态网站生成器博文现在的格式是，你需要一个 YAML 文件，称为前置信息；其中包含文章链接、发布日期等信息，然后是文章正文。现在，借助大型语言模型（LLM），理论上，你可以用任何东西撰写博文。你可以创建一个名为“我的博文”的文件夹，其中可以包含一条短信的截图，这就可以作为一篇博文。

你也可以准备一个便签的截图、一张便签的照片、一个 Markdown 文件、一个文本文件，然后告诉 LLM，“这是我的五篇博文，这是我希望这些博文使用的基本模板，为我生成博客。” 你不需要在其中添加任何结构，因为这些 LLM 现在是“模糊到非模糊适配器”。我是这样称呼它们的。你可以向它们投喂图片、截图、语音消息、视频，任何内容，它们都能生成文本。这听起来像科幻和哲学。当我们不再需要严格遵循数据库的列结构进行思考时，我们能创造出多少美好的事物？我们可以说，“一篇博文可以是任何形式。它可以是一张图片、一段视频、一段音频”。我们现在有一款工具，可以将这些内容转换为另一种形式。我们无需将其固定为特定的格式。

主持人 Jerod Santo：这很有趣。那你到底在构建什么呢？

Thorsten Ball：我开始构建一个静态网站生成器，在构建时，它会浏览一个名为“Posts”的文件夹，并用图片、视频、音频文件和屏幕截图生成博文的索引，并将它们放入一个格式中。提示是这样的，“对于每篇博文，修改布局以匹配博文的内容”。比如，让它看起来严肃，或者让它看起来有趣，或者任何它应该成为的样子。我认为，这是我们在计算机或软件中从未有过的东西，你可以告诉它，“让这个看起来像手写的”。然后它就会出现，做一些让它看起来像这样的东西。

大概两个月前，有人给我发了一封电子邮件说，“你的个人网站仍然说你在 Zed 工作，但我听说你回到了 Sourcegraph。”我回复说，“你是对的。”我用 Amp 打开我的网站，截取了那封电子邮件，并把它粘贴到代理里说，“修复这个。”然后它就找到了我的网站上说当前工作地点的那一部分，并根据那封电子邮件的屏幕截图进行了更新。我就想，“这不是很神奇吗？我截取一封电子邮件的屏幕截图，然后一些东西就会根据它改变？”我把它发回给给我发电子邮件的那个人，那人说，“我敢肯定，你可以比代理做得更快。”我说，“伙计，你不觉得这太疯狂了吗？”我可以为你构建一些东西，你转发一封电子邮件，它就会在你的网站上打开一个拉取请求。现在构建这个不难了。

主持人 Adam Stacoviak：是的，要是以前，这是一家初创公司了，对吧？

Thorsten Ball：没错。

主持人 Adam Stacoviak：有人会带着一份商业计划，到处寻求资金。现在则是“随它去吧”。不过，我们之所以讨论到这里，主要是因为 Jerod 提到了开源。过去大约 35 分钟的讨论，全都是围绕开源这个问题展开的。起初，我差点说一切都是默认开源的。因为如果你能生成每一行代码，那么关键因素不是生成的代码，而是想法和知识产权，是这些决定了它是否具有专有性。如果默认情况下一切都是开源的，但随着对话的进行，“如果开源不再那么重要了怎么办？”因为当我们需要某样东西的时候，我们只需自己创建。不过，总得有一些在用的标准吧。

主持人 Jerod Santo：源代码的价值在哪里？一定要有一些源代码，供机器人学习。

Thorsten Ball：是的，那是一种次要影响。比如说，如果我们都认为分享东西不再有价值，那么用于改进这些模型的资源就会枯竭。

主持人 Adam Stacoviak：我认为，尽管如此，我们仍然会从分享中找到价值。我认为，仍然会有库和框架被创建，也许在某个时候，源代码将成为大型语言模型（LLM）使用这些内容的一种标准化方式，它们将成为用户，就像我们是用户一样。而我们之所以成为用户，仅仅是因为我们关心与之关联的名称。

主持人 Jerod Santo：但它们不一定想要源代码，它们想要的是工具。比如，在训练时它们需要源代码，但在实际构建中，它们更需要工具而不是源代码。所以我认为，我们无法在接下来的三到五年内回答这个问题。我觉得这是一个代际问题。比如，如果你现在展望 20 年后，“2045 年开源技术对世界的影响会是什么？”，与现在相比会大不相同吗？我认为可能会，但我不确定。

Thorsten Ball：我能做一个乐观的预测吗？我认为，那些创造性的、人类独有的、有品味的，基于独有经验的东西，其价值将会上升。比如，如果有一件事，在那个时刻，只有你用这个模型和那个模型的组合才能完成，我认为那仍然是有价值的。除了真正有创意的代码、真正有洞见的算法、真正高效、良好的数据结构，另一个 TUI 框架、日期解析库或者类似的东西，其价值会逐渐减弱。独特性、品味和创造力的价值会脱颖而出。

主持人 Jerod Santo：我觉得这是一个很好的结束语。Adam，你觉得呢？

主持人 Adam Stacoviak：我也这么认为。我唯一想要补充的是，似乎需要换个角度来看待这个问题，因为当你离问题越近，细节就越重要。比如，未来的人类可能会说，“你还记得人类的价值曾经是基于代码行数，或是他们一生中写下的文字，或是其他什么吗？而现在，这些都不重要了，因为当你从宏观角度看问题时，这些并不是需要追踪的指标。”当你聚焦于细节时，这些细节确实重要。但当你从宏观角度看问题时，你衡量事物的标准是基于整体趋势，而非细节的具体定义。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://changelog.com/podcast/648