Ryan Dahl 在 1 月 20 日给软件工程下了结论：“人类写代码的时代已经结束。”留下的工作里，不包括继续手写语法。

如果这话出自某个科技网红，大概刷过去就算了。但 Ryan Dahl 不一样——他不仅写出了 Node.js，后来还“推倒重来”做了 Deno。你可以把他的意思理解为：写代码这部分会越来越自动化，而人的价值会更多落在判断、取舍和责任上。

而在 Ryan Dahl 这次“宣判”之前，1 月 3 日，Ruby on Rails 作者 DHH 也在 X 上连发多条，语气罕见地偏“乐观派”：

“别让那些粗制滥造和尴尬翻车，遮住你对 AI 的惊叹。自从我们把计算机连上互联网以来，这是我们让计算机做到过的最令人兴奋的事。如果你在 2025 年一直对 AI 悲观或怀疑，不如在 2026 年的开端，用一点乐观和好奇再试试看？”

于是，社区里迅速冒出一种更夸张、但传播力极强的解读：“DHH 都松口了。”“连最不买账的人都开始给 AI 站台——你还有什么理由不用？”甚至有人干脆把它说成：“DHH 也扛不住了，最终还是向 AI 屈服低头了。”

但你真去听 DHH 的原话，会发现所谓“DHH 屈服论”，并不是那么回事儿。

在最新一期播客中，他说在 37signals，AI 没有在写真实产品，更谈不上“从零写出什么东西”。

他在用 AI，而且每天都用，但更多是做那种“一发入魂”的小实验；一旦进入真工程：要持续演进、要迭代、要打磨，他就会觉得：“这在浪费我的时间，到这一步我自己写更快。”

所以他们的新产品 Fizzy 里 95% 的代码，还是人类亲手敲出来的。

他还补了一句：我们离那种“AI 让一切始终更好、更快、更省心”的明显拐点，还差一点。

“就现在而言，我仍然在意代码的样子。我在意它的美感。我在意打磨、推敲、润色。”

更关键的是，他不是在怀旧。他明确说：“手写代码依然有竞争力。”“至少在此时此刻，这是一个仍然有竞争力的选择。”

而且他的判断正好和 Ryan Dahl 相反：“我们并没有到 AGI，没有到那种‘人类写代码的时代死了’的程度。”

挺好玩的是，DHH 还说要远离 Anthropic 的 CEO：他一听到那种“再过五分钟就不需要程序员了”的口吻就火大，直接开喷：“你们到底用的啥模型啊？”反正他自己用的是 Opus 4.5（或当下版本），但在他的体验里，这种“程序员马上下岗”的说法完全不符合现实——尤其是那些要长期维护、持续迭代、不断演进的真实工程，离“五分钟结束”差得十万八千里。

以下是 DHH 播客整理全文翻译：

“如果浏览 Web 的不再是人类”

主持人：欢迎大家来到《Next Token》。今天这期节目对我来说有点特别，可能要追溯到 25 年前。很高兴请到 DHH——David Heinemeier Hansson。欢迎你。

DHH：很高兴来，谢谢邀请。

主持人：我猜你可能是刚从赛车里下来（笑）。

DHH：现在是休赛期，正好歇一歇。

主持人（Torsten）：那我就先来点“热血沸腾”的话题。我从 2010 年左右就开始关注你，你可能是对我影响最大的前五位程序员之一。如果没有你，我可能不会走到今天。我职业生涯中有七八年都在写 Rails，看了你所有的书、博客。我们其实从没见过面，但有一次“交集”让我印象极深——我发过一条关于 Cookie Banners 的吐槽推文，那是我人生中传播最广的一条推文。那天中午我被 Cookie Banners 气疯了，随手发了一条，然后彻底炸了。第二天你转推并评论说：“这就是为什么人们不再浏览 Web，而是开始用 ChatGPT。” 所以我想直接问你：欧盟最近说要“取消 Cookie Banners”，你觉得这真的能改善什么吗？还是说——已经太迟了？

DHH：我认为 Cookie Banners 是 Web 体验变得糟糕的一个主要原因。它们几乎比早期那种弹窗广告还要糟糕——你知道的，“打地鼠”“打猴子”那种 2000 年初的弹窗。当年浏览器还能通过技术手段封杀弹窗，但 Cookie Banners 没有一个统一、有效的技术解决方案。我知道有插件能挡，但大多数人不会装。结果就是：Cookie Banners 成了互联网的一场瘟疫。

我是丹麦人，所以我觉得我有资格狠狠吐槽欧盟。Cookie Banners 最初的出发点是“高尚的”——限制数据收集、提高透明度。但这套东西在第一个 Cookie Banners 出现 5 分钟后，就已经被证明是失败的。可欧盟花了整整 15 年，才开始承认这个问题。现在他们说要“移除”Cookie Banners。

但“移除”是什么意思？你以为这就能抹掉你对互联网造成的破坏吗？不可能。接下来30 年，仍然会有大量网站继续保留 Cookie Banners——因为删掉它比留着更麻烦，或者网站早就没人维护了。

这是一件非常悲哀的事。当然，我并不是说：如果没有 Cookie Banners，人们就不会去用 ChatGPT。 那不现实。但它确实在可测量的层面上伤害了 Web，让浏览体验变得远比必要的程度更糟。

一旦你已经在用户体验上制造了第一道伤口，后面再多来几刀，心理成本就低多了。Cookie Banners 把“底线”拉得太低了，以至于很多 Web 设计师会觉得：再多放点广告、再恶心一点，好像也没那么糟。 这就像“破窗理论”。

主持人：那在 Cookie Banners 把 Web 搞成这样之后，你觉得互联网浏览的未来会走向哪里？

如果未来主要“浏览 Web 的不再是人类”，那这些问题还重要吗？

DHH：这是一个好问题。我觉得现在有很多聪明的人都在试图搞明白这件事，我们也在尝试各种不同的做法。某种意义上，这真的很像上世纪 90 年代中后期——当时我们在摸索互联网的第一个版本：这一切究竟会怎么运作？谁会掌握权力？谁会成为平台？谁又会成为把关者？所有这些问题，如今再次被抛回到空中，悬而未决。

不管我个人怎么看它最终会走向哪里，我都觉得这是一件令人兴奋的事情。互联网和计算技术，已经很久没有像现在这样让人感到兴奋了——上一次有这种感觉，还是在 2007 年。

那是 iPhone 刚刚问世的时候，我们迎来了一个全新的形态。随后经历了很长一段时间：好，一切都转向移动端了。而现在，我们又站在另一次巨大的转折点上——这一次，不只是“移动”不再以同样的方式重要了，它不再是你思考和构建产品时的那个主导视角。

与此同时，还有大量没有答案的问题。如果人类不再亲自阅读互联网内容，因此也不再阅读广告，那究竟是谁在为互联网写作？谁还会去生产那些美好的内容？当我们摆脱了 cookie 弹窗，重新拥有一个“干净体面”的门面，这件事真的还重要吗？

如果这件事本身已经不再重要，如果人们不再想为互联网写作，那 AI 又将从哪里获取它所需要的信息？我觉得现在有太多悬而未决的问题，以至于没有任何人哪怕稍微知道，最终的解决方案会是什么样子。而这，恰恰是活在这个时代最令人振奋的地方。

我毫不怀疑，将来我们回头看今天这个时刻时，会说：“好吧，这里发生了一次决定性的变化。”而且，这种变化在当下的可感知程度，甚至比前两次都要更明显。

互联网的出现，花了五六年的时间才真正渗透进社会，对整个社会产生巨大影响。后来是手机，速度快了一些，但也没有快到哪里去——iPhone 本身也经历了好几代迭代，我们一开始甚至都没有 App Store，这些东西都是慢慢才出现的。

但 AI 不一样。

AI 的出现，在当下这一刻就已经非常明显。任何一个用过第一版 ChatGPT 的人，都会立刻意识到：哇，这完全是一个全新的东西，它将重写规则。

所以，在这三次巨大的技术变迁中——互联网的诞生、移动时代的到来，以及现在的 AI——这是第一次，我们在实时发生的过程中就清楚地知道：世界一定会变得完全不同，而我们却不知道最终会变成什么样。

因此，我觉得你能做的最好的事情，就是接受三点：第一，我们不知道答案；第二，这真的令人兴奋；第三，赶紧上车，狠狠干脆坐稳了，看看它会把我们带到哪里去。

因为还有另一种冲动，过去在互联网时代出现过，在移动时代也出现过：那就是一部分人会说，“我更喜欢以前的样子。我喜欢变革发生之前的一切。我不喜欢 AI。我不喜欢也许会被整个互联网重新中介化。我不喜欢这些东西。我们能不能把一切都倒回去？”

不，不能。你没有这种权力。你无法把这些东西倒回去。

你当然可以在个人层面选择：我不用生成式 AI，或者我不买任何包含 AI 方案的产品。但这种想法，本质上是一种“阿米什式”的思维方式——而在任何时代，这都只是非常小众的选择。

如果这就是你，如果这就是你想与世界互动的方式，那很好，祝你一切顺利。我们有时候确实需要一些“疯子”来提醒我们：事情也可以用完全不同的方式来做。但这，并不会改变历史前进的轨迹。

“这真的是一个无比令人兴奋的时代”

主持人：你的兴奋更多来自哪里？是因为规则被打乱、棋盘被掀翻？还是因为你真的想用 AI 做事？

DHH：首先也是最重要的一点，我热爱计算机。我喜欢看到计算机做出以前做不了的新事情。说实话，让我觉得非常惊讶的是：有这么多在科技行业工作的人，其实并不怎么喜欢计算机——甚至包括那些每天都要和计算机打交道、让计算机“跳舞”的程序员，也并不是所有人都真的喜欢计算机。

但我不一样。我爱计算机。我真的爱计算机本身，爱的是它作为一台机器的纯粹性。我并不是只把计算机当成一种“工具”，不是只想用它来完成某个目的。确实有一大类人，把计算机仅仅视为通往某个结果的手段。但不是这样，对我来说，这要更深得多——我就是单纯地热爱计算机这个东西本身，也热爱看到它去做全新的事情。

而现在发生的这件事，是计算机在我这一生中做过的最令人兴奋的新事情之一，至少可以和当年“计算机连上网络”这件事相提并论。

那时我们从 Commodore 64、Amiga 时代走过来，突然“砰”地一下就上网了，用小小的调制解调器拨号，连接世界各地的 BBS，听着它唱出那种刺耳却又美妙的声音——那同样是一次巨大的转变，也彻底改变了我和计算机之间的关系。

而现在，很可能是第二次这样规模的变化。

另一件让我感到兴奋的，是棋盘被彻底翻转了。尤其是我们已经形成了一些根深蒂固的格局。比如 Apple，我和那家公司有过不少摩擦。我非常期待看到 Apple 通过 App Store 以及整个移动生态所建立的那种“封闭控制”，被彻底掀翻，因为它也许将不再以同样的方式重要。

当然，我也并不天真到以为：只要棋盘一翻转，接下来就会迎来一个人人和谐共处的“涅槃世界”，一切都会变成开放平台，没有任何人占据主导地位。这显然不可能发生。不管最终的主导者叫 OpenAI、xAI、Google，还是别的什么名字，某种形式的集中和垄断，迟早都会出现。

但至少在现在，我们还处在“尚未整合”的阶段。有这么多公司同时在追逐前沿模型，却没有任何一家明显胜出。

就在五秒钟前，整个科技行业还准备给 Google 判死刑——“他们错过了浪潮”，“早期研究是他们做的，《Attention Is All You Need》那篇论文也是他们团队出的，但后来落后了整整九个月”，当时大家已经在谈论 Google 的衰落了。而现在，他们也许又重新回到了领先位置，至少在某些领域确实如此。

这种不确定性本身就让人兴奋——我们并不知道，最终谁会占据主导地位，甚至都不确定“主导地位”这种东西是否一定会出现。

这件事也很有意思。就在几周前，我还在推特上说，跑本地模型这件事有点“奇怪”。因为我之前试过一些本地模型，说不上什么时候，总之那时体验一般。但就在这周，我又开始重新跑本地模型，然后我心里想：“靠，我之前说的话，保质期也太短了吧。”

现实变化的速度已经快到：三个月前说的任何一句话，现在看起来都可能有点傻。

而且我真的被本地模型现在的水平震惊到了。它们当然还比不上最前沿的模型，但如果再往前看两年呢？有没有一种可能，根本不会出现一个“唯一的赢家”？赢家反而会是开放模型？最终的局面，会不会类似开源软件对后端软件世界造成的影响？

过去我们是有绝对主导者的。我们有过 Sun，有过 IBM，在某种程度上也有过 Microsoft。但这些都已经不存在了。整个后端世界——从 Linux 到各种数据库，再到 Ruby、Rails，以及所有这些东西——几乎全都是开源的。你再也看不到那种一家独大的绝对统治。

而在另一边，在前端世界，尤其是移动端，我们却看到的是彻底的垄断：只有两个赢家，Google 和 Apple。他们对平台拥有完全的控制权，而且还在不断收紧螺丝。我们唯一的希望，似乎只剩下立法或监管，而说实话，我对这条路也已经越来越悲观了。

所以现在的局面真的很令人兴奋——它可能朝两个完全不同的方向发展。

我们很可能还是会走向某种形式的垄断，因为这是面向用户的界面层。而在历史上，我几乎想不起有哪个时代，这种层面没有被“征服”过。

但也有另一种可能：这些开放模型会好到一个程度，以至于“谁占据商业主导地位”这件事根本不重要，你甚至不需要那种商业上的统治。

这真的是一个无比令人兴奋的时代。

“我们的产品也试过 AI 功能，但最后都没上线”

主持人：这挺有意思的——你正好是在这个变动时期推出新产品。HEY 大概是五年前发布的，然后最近 Fizzy 也上线了。我们特别想知道：37signals 内部现在到底在发生什么？你们到底怎么用 AI？你们做 Fizzy 的时候，用没用 AI？用到什么程度？我很想听点“细节层面的现实”，AI 在 37signals 具体怎么落地、怎么被用起来的。

DHH：哦，用的，当然用。我们每一个开发者都在某种程度上使用 AI。我自己每天也在用 AI。

但我也得先加一句前提：我虽然对我们即将进入的新现实非常兴奋，但我每天处理的仍然是“此时此刻真实存在的东西”。你必须学会在“ hype 的列车”和“现实的列车”之间保持平衡。

而在我的“现实列车”里，AI 没有在写 Fizzy（一个 Kanban 工具）。

AI 也没有从零写任何东西。

我确实用过 AI 做过各种“一发入魂”的实验——但它们通常都只停留在“一发入魂”。因为只要我进入真正的细节：要持续演进、要迭代、要打磨，我就会想：“嗯，这就是在浪费我的时间。到这个阶段，我自己写反而更快。”

当然，AI 在另一些方面确实能大幅加速。我们在做这些产品时，也在一定程度上使用 AI。但我们并没有大量用 AI 来写 Ruby 代码。如果用 AI 写 Ruby，通常也只是“机械式翻译”——比如：“这里有个我们知道已经存在的东西，你能把它用 Ruby 版本写出来吗？” 它能给出一个初稿，有时候会稍微帮点忙。

AI 更有价值的地方是在我们的一些 Go 代码上，因为那里面“样板代码”更多，收益更明显。

但即便是 Ruby 和 Go 这两块，也谈不上“改变游戏规则”。

真正改变游戏规则的是：

• 你想学习一个新 API

• 你想理解一个新概念模型

• 或者我们做实验，直接用 AI 去尝试构建“能真正带来价值”的 AI 功能

在这些方面，收益更大。

但我们离那种——某些 CEO（比如 Anthropic 的 CEO 那种语气）说的——“再过五分钟我们就不需要程序员了”还差得远。我就想问一句：你们到底用的是什么模型？我用的是 Opus 4.5（或者现在的版本），但那种说法完全不符合现实——至少对于“持续演进”这类工作来说，是完全不成立的。

我仍然保持开放心态，我也能看到那种承诺。我记得互联网在 1994、1995 年那会儿是什么状态，我当然能做外推：我们也许真的会走到那一步。也许我们会到一个阶段：人类不再编写大多数代码。

但如果你看 Fizzy：95% 的代码，是人类亲手敲出来的。

主持人：有意思。真的？你们内部也这样认为？

DHH：你回头看 Fizzy 的整个开发历史，会更有意思。我们在 Fizzy 里做过一堆 AI 功能实验：我们试过做一个 AI 驱动的命令行，用来和卡片（cards）交互；我们也试过 AI 摘要，给一些内容自动做总结。但最后这两项我们都没有发布。

Basecamp 也是一样：我们实验过很多不同的 AI 功能，但没有一个能达到“明显更好、用户会一直爱用”的标准，所以都没进最终版本。

我仍然相信未来这会改变。只是我们现在还没到那个时刻。

我也见过其他地方做得更成熟的案例。比如我在 Shopify 董事会，Shopify 做的 Sidekick（他们的 AI agent）——用来帮助商家搭建店铺、优化店铺——真的很不可思议。那里面有一些非常具体、非常可触达的收益，我觉得几乎无可争辩。

我们仍然处在一个阶段：距离“AI 让一切始终更好、更快、更省心”那种明显的拐点，还差一点。

也正因为还没到那个拐点，所以才会出现一些反弹——我认为其中不少反弹甚至是合理的。

因为很多人用了所谓“AI 功能”之后会觉得：“这玩意儿太烂了。”“不更好，也不更快，甚至很蠢。”

比如摘要。我们刚刚还提到 Apple。Apple 对新闻、短信之类的摘要，我真不知道有多少人真喜欢开着它。它在很多情况下都离谱地糟糕、离谱地错误。连 Apple 这种体量的公司都做不对，那你基本可以合理推测：很多别的公司也同样做不对。

不过我也想强调：最近我们确实找到了几个非常好的 AI 用例。其中一个是我们的安全漏洞赏金项目（通过 HackerOne 运行）。我们会收到海量的报告——某个研究员声称在我们的应用里发现了漏洞。我们必须处理这些报告，而现实的数学非常残酷。我们大概会收到……可能一个季度 300 份报告之类的数量。但真正“靠谱、有效、值得修”的——大概只有 3 份。

也就是说，真正有价值的比例大概只有1%。而这个 1% 非常重要，因为它们可能真的指出了一个严重问题，我们必须修。但为了抓住这 1%，你必须花巨大精力去验证剩下99%的垃圾——这对团队来说是巨大的麻烦、巨大的时间黑洞、巨大的烦躁来源。

AI 在这件事上简直太厉害了：它能在报告进来时就先处理一遍，给我们一个初步判断——“这到底是扯淡，还是不扯淡？”然后还会帮我们写回复邮件。

而写回复其实才是痛点的一半：当 99% 的提交都是彻头彻尾的狗屎，写这些狗屎的人还常常—— 根本不懂自己在说什么，却又特别理直气壮，还特别不耐烦，甚至还一副“你必须立刻给我 5000 美金赏金”的态度。

这时候让人类程序员保持冷静、不直接对他们开喷，是很难的。真的，你会很想直接骂人。

AI 就完全没这个负担。它特别乐意用一种非常冷静的语气写一大段回复：“为什么你这个东西不成立。”它帮我们省了大量时间。

主持人：有意思。所以 AI 是拿到报告之后，去看你们代码库，然后判断它到底对不对？

DHH：对。没错。就是这样。把这两件事结合起来。

主持人：听起来需要一点技巧：拿到安全报告，很多是垃圾，但到了某个层级，你确实得打开代码去确认“这到底是不是真的”。

DHH：以前要看 100 份报告，现在可能只要看 5 份——这就是真实的生产力提升。就算你最后要看 10 份、20 份，只要你能把原本 100 份的工作压缩到 20 份，这就是 AI 承诺的生产力收益。如果我们能把这种压缩能力用到业务的其他方面——那简直太好了。这也是为什么我们一直在尝试把 AI 用在一些具体环节上。

另一个我们断断续续尝试了好几年的方向是客服支持（support）。但 support 很微妙：如果你只能 90% 正确，那其实很糟糕。因为这意味着你会有 10% 的概率把事情说错——而且是对着客户说错。你如果给客户一个完全错误的答案，让客户体验很差，客户可能就直接流失了。

那这个客户的终生价值是多少？

你以为 AI 带来的那点“节省成本”，可能瞬间就被一次流失抵消得干干净净。我们上一次认真测试让 AI “做完整客服链路”，大概是 18 个月前左右。效果不太行。但一切都在飞速变化。我知道 Intercom 有一个叫 Finn 的 AI agent，采用得很好，看起来我们也确实该再试一次。

而这又回到我最初的那种兴奋：一切变化太快了。

有些人会觉得这很让人迷失方向，我觉得这也是很多焦虑的来源。但如果你像我一样，只是单纯喜欢看计算机变得更强大——那现在真的就是一场大戏。坐在第一排，实时看它发生。

我们从“那个吃意大利面的人”——看起来像噩梦一样的生成图——走到了今天这种几乎不可区分的输出。接下来，我们很可能会在更多领域看到同样的跃迁。你得保持一种“敬畏感”和“惊奇感”。

如果你此刻身处这个行业，和计算机打交道——你的“惊奇感”就是你的安全绳。它能对冲焦虑，对冲不确定性，让这一切变得可承受。

当然，我们并不能消除不确定性和焦虑。比如：我的工作三个月后还存在吗？这种焦虑非常合理。但你可以用惊奇感来对冲它：“这些硅做的小东西也太聪明了吧。”

AI 时代，为什么你发布的产品别人看不见？

主持人：它们真的很神奇。这就引出了一个更大的问题：软件商业模式的未来到底会怎样？这确实很神奇，但也真的太不一样了。你能不能展开讲讲：创业公司会走向哪里？软件产品会走向哪里？软件工程师会走向哪里？未来到底会怎样？

DHH：有一点我现在非常确定：今天发布一个新产品，从“把它做出来”的角度看，是史上最容易的。AI 让构建更容易；工具史上最好；Ruby 和 Rails 也从未如此成熟。对所有人来说，这都很棒。结果就是：市场被海量新产品发布淹没了——永无止境的“上百万、上亿级别”的新发布。

这就是你现在要面对的现实。门槛被降低了。而我不确定所有人都会在“轮到自己发布时”还为门槛降低而兴奋——因为你一发布，可能就是一片寂静，连个回响都没有。我们刚发布 Fizzy，算是一次不错的发布，但它并没有像我们历史上某些发布那样“声量巨大”。

这当然不只是 AI 的原因，还有社交媒体算法的原因。以前，我在 X（Twitter）上有粉丝，他们就能看到我发的东西。但现在，你会发现：X 上正在发生 Facebook 在 2010 年左右发生过的那一幕——你有粉丝，但你触达不了他们，除非你付钱给平台“买触达”。

但现在甚至都不只是“付钱”这么简单。问题变成：我甚至都看不到我合伙人 Jason 的推文了。除非他发了一条“爆款（banger）”，爆到病毒式传播，否则他的内容就不会出现在我的 For You 页面里。一切被压缩成了“你能不能发出爆款”。

拥有大量粉丝这件事的价值，被严重稀释了。我在 X 上有五十多万粉丝——这在我发一些犀利观点、能引起传播时依然好用。但当我想发“右勾拳”（也就是营销、转化）的时候，它不再提供过去那种收益。当然，这种变化也不全是坏处。现在小账号也可能爆：就算你只有 10 个粉丝，只要你发了一条爆款，算法也可能把你推上去。算法选赢家和输家的方式，反而让那些没有花 20 年积累粉丝的人受益。但这真的好吗？我大概发了 7 万条推文——这真是离谱。但 18 年下来，这些投入几乎没有“可积累的剩余权益”（residual equity）。

我不确定这是不是我们长期想要的生态。但可以确定的是：对我们的营销方式、产品发布方式来说，这已经是一个全新的世界。

我们公司现在的阶段是：我们能承受“靠一靠、观望一下”，说一句“挺有意思”。但如果你还处在“必须打出名气”的阶段，你肯定会更焦虑。因为以前那套打法，已经不像过去那样奏效，你得发明新的东西。

事实上，这种认知直接影响了 Fizzy 的发布策略：我们承认——你不能再用老办法发布产品了。你手里的名单、你已有的受众，不可能再用“传统方式”被激活。你需要持续不断的“滴灌”：一滴、一滴、一滴。

如果我们希望 Fizzy 这个品牌能在用户心里留下印象，以至于当他们遇到我们要解决的问题时，会想起它、会去 fizzy.do，我们就必须设计一种策略，让我们能一直这样做下去。这也部分解释了为什么我们从一开始就把 Fizzy 开源。

把 Fizzy 从发布第一天就开源——

• 对所有想学习“生产级 Ruby/Rails 应用如何构建”的人来说，这是一个巨大的礼物；

• 同时，对我们来说，它也给了我们一个“更频繁谈论 Fizzy 的许可”。

现在社交平台上，纯商业化的转化号召（call-to-action）越来越推不动。以前它传播力也一般，但好歹还能“硬塞”一下——那就是所谓的“右勾拳”。现在右勾拳打不出去，你就得换一种卖法。我目前觉得最管用的策略，是把“给价值”和“求转化”合成一拳：轻击（jab）和右勾拳（right hook）不再分开打，而是同一条内容里同时完成。

比如我会发：“Fizzy 里有个很酷的小功能——可能是我们做的，也可能是社区做的，或者我只是想提醒你注意到它。”这条对开发者有用；与此同时，我也顺势把品牌名反复露出来：Fizzy、Fizzy、Fizzy……品牌就是靠重复进入脑子。

关键是：重复仍然有效，但必须绑着价值一起出现。光当“慷慨的好人”持续免费输出已经不够了——你得把输出和你正在做的产品强绑定。这就是我们现在的打法。当然规则也可能随时被改写，但就此刻来看，这就是现实的游戏规则。

主持人：你说“现在你只要把东西做出来就行”，这句话听起来很有趣，因为我觉得你以前不会这么说。你从一开始就很重视营销——从最早的 Rails demo、到各种“挑衅”、到你如何推销愿景……你一直都在想怎么卖、怎么讲故事。但现在市场被淹没了，好像营销反而变得更重要。

更巧的是，我们内部也在聊类似的事。我们在做 AMP（我们在做一个 coding agent），我们内部一直说：现在外界没有太多“强烈的 OTE”（那种外溢式的注意力/势能）。我们想做的是：用一个故事把人“拉着走”——告诉他们我们在这个动荡的时代学到了什么，让他们产生一种感觉：“如果你跟我们走，门是开着的；如果你跟我们走，我们会分享我们学到的东西。”这不是那种“社交媒体上再来 10 个小贴士”的套路，而更像是：“我们一起干这件事。”

而你刚刚说的，正好对应了很多人最近在讲的： “爆款发布（big launch）这套已经不灵了。”Product Hunt 死了。Hacker News 的 launch 也……

而且我认识 Fizzy，就是因为 Jason 一直在 X 上做这些小 screencast：“现在进展到哪了”、“这里出了一些 X 问题”、“这里哪里又崩了”。我会偶尔刷到它们，可能是 Grok 或者算法觉得我会喜欢。但我的感觉是：我被“拉着走”了——像在跟着你们一起把产品做出来。所以我后来才注意到：噢，原来它上线了。

DHH：你说得对，这确实是我们这个时代发生的巨大变化之一。我记得我们在 2006 年写《Getting Real》（那本书）时，我们谈过“爆款发布（blockbuster launch）”这套模型：先放 teaser（预告），再放 trailer（预热视频），最后来一个 blockbuster launch（大爆发）。

这套模型已经死了。爆款不再发生。因为我们已经没有共享文化了。没有共享的事件。我们只有每个人各自的个性化信息流——正如你说的，算法之神决定：今天给你投喂哪一小块“刚好合适”的东西。所以，一方面，你必须“灌满渠道”（flood the channel）。

另一方面，也有个有意思的反面：以前我会更克制，比如提醒自己别发太多推。有时候我会突然进入那种“多条意识流同时开喷”的状态，但在过去你会想：“哎，我今天已经发第七条了，会不会太多？”

现在这种限制不存在了。你一天发 100 条都没关系。因为你不会“淹没”任何人的 For You 页面——算法会替你处理。而你发得越多，你就越有机会让一些小种子落地、生长、发芽。你还需要更长的周期。

爆款发布以前的核心逻辑是：“就在这一天，我们发布，然后所有人都在这一天关注。”现在不会了。大家不会在同一天关注同一件事。但随着时间推移，如果你把“发布”理解为：一整个季度、或者一年、甚至某些情况下是一整个十年——你依然可以做“分步骤的搭建”，依然能起作用。因为营销的底层真价值仍然成立：口碑传播、故事激活、好产品、好钩子——这些依然有效。

只是，它变得慢得多。你不会再看到那种巨大峰值，然后被“发布日的高潮”爽到。某种意义上，现在的发布没有那个“超级尖峰”了。当然，很多人本来也从来没有过“超级尖峰”，因为大多数发布都什么也不会发生——失败一直是常态。但我现在更强烈地觉得：你越来越难“工程化制造一个爆款”。

这个夏天我又学到（或者说被提醒）了一点。我在做一个项目叫Omarchy——一个 Linux 发行版。我做得很开心。当我推进它时，我从营销角度体会到：如果你不断分享项目进展、再配合一个疯狂的发布节奏，价值非常大。

我记得第一个月我做了大概 40 次发布？简直离谱。节奏快得惊人，整个过程一直都充满了不确定性，所以特别刺激、特别带劲。这让我可以连续三个月“轰炸”所有人的信息流。更有意思的是：人们明明意识到自己在被轰炸，却仍然无力抵抗。我收到过无数条推文，大意都是：“行行行，我第 17 次听说 Omarchy 了，我服了，我试一下。”“我投降，好吧，我装。”这又回到了营销最本质的东西：重复。

有一个老的经验法则（我也不知道现在是不是过时了）：你需要听到一个品牌七次，它才会在你遇到问题时被激活——你才会想起它能解决什么。所以我当时就是在努力让尽可能多的人“听到七次”。同时我也在做 Jason 说的那个：enthusiasm transfer（热情迁移）——把创作者的兴奋感转移给别人。这一直是营销的一部分，但现在比以前更重要，因为营销越来越“人格化”。

我们还发现：社交平台从来就不怎么喜欢公司账号，但现在它们几乎把公司账号都“幽灵化”了。我们公司账号发什么都没用：从 37signals 发，没人理；从 Basecamp 发，也没人理。一片寂静。然后我看到一些“巨型媒体账号”——几百万粉丝那种——表现也一样惨。这就是算法：它现在真的讨厌品牌账号。除非你是那种“神级品牌账号”——有账号运营团队，能自己成为内容源。

但另一部分也让我们意识到：这游戏即便对我们而言仍然很残酷——而且很耗人。这种耗人让我想起我听一些 YouTuber 讲过的东西：如果你是 influencer（网红）、content creator（内容创作者）——这俩词简直是现代词汇里最让我厌恶的词之一——你就会被迫持续生产内容。

你维持曝光的方式只有一个：不停输出、不停输出、不停输出（chop chop chop）。以前还有一种“喘息”：你做完 teaser、trailer、爆款发布，然后你还能休息五分钟。现在不行了。那种节奏不存在了。所以一切的速度被推到一个夸张的程度。说实话，我很庆幸我现在不需要“去攒人生的第一桶金”了（笑）。

主持人：我们最近也在高频发东西：过去 10 天我们写了 8 篇 release post。这和你做 Omarchy 的方式很像：你需要重复。但那种 5 年前的“空洞重复”已经不行了——比如：“两天前我们大发布，记得吗？”“一周前我们大发布，记得吗？”这种完全没效果。你必须一直有新内容，否则算法不推。节奏太夸张了。

而在我们这个做 AI agents 的领域，你还会被大模型厂商不断“催更”——他们两天发一个新模型，用户两天后就来问：“你怎么还不切？怎么还没上新？”所以现在疯狂的事情特别多。

我的问题是：你写过《It Doesn’t Have to Be Crazy at Work》（工作不必这么疯狂），但现实已经如此——这在实践中到底怎么改变软件开发？你一直是小团队、小公司路线的拥护者。 但现在如果你想让产品成功，你好像必须把一天切成两半：一半写代码，一半发推、做内容、做传播、分享进展。你觉得这会怎么影响未来的软件开发者/软件公司？营销和软件是在融合吗？

DHH：我一直都说：这些东西本来就是一回事。“Marketing is everything（营销就是一切）”——这是《Rework》里的一章。而“everything”真的就是一切：软件、发布、客服、那些乱七八糟的推文、写作、播客……全都是。我们这么干已经 25 年了。但我同意：现在的节奏、算法的胃口，确实到了一个“无底洞”的程度，这种感觉以前没有这么强烈。不过我也觉得：这可能就是竞争加剧的样子。

当年我们做 Basecamp 的时候，行业比现在小太多了。那时做 Web 产品的团队少得可怜，以至于我们能关注到每一次发布。后来进入 Product Hunt 时代，你至少还能“一天看一个新东西”。现在结束了。

甚至 OpenAI 发一个新模型——那可能烧了 4 亿美元——它也只能获得几个小时的峰值关注与兴奋。

所以，它在很多方面变得更难了。可另一方面，基本面依然没变，你得小心别被这些压力带着跑偏。做有趣的东西、做值得讲的东西——这带来的杠杆还在。

你要“脱颖而出”的难度变大了，因为参与者更多了。

但只要你真的突出，注意力仍然在那里。注意力并没有从系统里被抽走。甚至可以说：注意力比以往更多，因为参与系统的人更多了。

这有点像 Spotify。你总听音乐人抱怨 Spotify 付得太少，但你再看数据：音乐产业的规模依然很大，甚至更大，而且在很多情况下，更多收入是直接流向音乐人（因为他们不再必须签那些苛刻的发行合约）。

所以一部分现实就是：我们在抱怨“事情太美好了”，但又没有人真的开心。

有个段子讲得很好：“一切都很棒，但没人开心。”我觉得这确实说中了某种人性。事情确实很棒：越来越多人能更快地做出东西。而这自然会带来更多竞争。资本家最讨厌的一件事是什么？是竞争。这就是那个系统最大的讽刺。我们都在拼命挖“护城河（moat）”。但护城河是用来挡谁的？不是挡“龙”（Not dragons）——是挡竞争对手。

竞争对手，这才是护城河真正要挡的东西。这个隐喻本身也很有趣：你会想，那它把谁“圈”在里面？客户？你在护城河里放鳄鱼，让客户别游出来？这个隐喻挺自利，也挺资本家叙事的。但无论如何，我玩这个游戏，也乐在其中。同时我也很高兴——现在我比过去任何时候都更清楚地知道：我对“什么真正有效、什么无效”的确定性变少了。

一直以来，很多东西本就是谜。比如我们 2004 年发布 Basecamp，它一路成了现象级成功，今天仍然成功。

我经常会想：为什么？为什么偏偏是 Basecamp？在我 25 年的职业生涯里，我做过很多东西，但没有任何一个产品层面的命中，能像 Basecamp 这么“正中靶心”。我至今也不完全明白原因。尤其是现在，Basecamp 所在的领域竞争者多得多。但每周仍然有成千上万的人注册一个新的 Basecamp 账号。每周我都会想：这怎么可能？怎么会每周都有几千几千人来注册？

这一直是个巨大的谜。

我觉得这种谦逊非常重要——无论你在做产品、还是在做营销，你都要记住：你不可能了解一切。你不可能确切知道什么有效、什么无效。你能做的，是去尝试很多东西，然后得到一些迹象、一些推力、一些暗示：市场想要什么、算法想要什么、客户想要什么。

但你不可能制定一套“主战略”，并指望它具备可重复的复刻性。即便是在一个高度“爆款驱动”的行业——比如我刚刚提到的音乐行业——也没人真正搞明白。的确，有些人比别人更擅长做出爆款，但也没有谁掌握一套公式：“照着这套流程，我们就能稳定生产爆款。”商业也是一样。

只是现在曲调又变了。你可以因此沮丧：“我以前那套把戏不灵了。”也可以因此兴奋：“什么？那我更迫不及待想学习——现在到底什么才有效！”我也接受一个现实：我不可能永远拥有过去拥有的一切。世界不是这样运作的。

“独立开发者”之梦没变：核心还是“一个人也能干”

主持人：我感觉我们好像回到了 2004 年。我记得你发布 Basecamp 的时候，你在 YC 还是哪里做过一个演讲，你当时大意是说：如果你有个想法，然后能找到 1000 个客户，每人每月付你 25 美元，你的人生就彻底不一样了。那次演讲就是我决定辞掉 Web 开发工作、去做 Dropsend 的起点——也开启了我整个职业生涯。

我觉得我们又回到了那种状态：现在你真的可以有一个想法，甚至可能是“一人团队”。所以，我们现在是不是就处在这个阶段？还是说，所有 indie hackers（独立开发者）最终都会被“吃掉”？这难道不是好事吗？

DHH：我也觉得这是好事。而且这里还有个讽刺点：我 20 多年来一直在讲——开发者生产力真的重要。

这就是 Ruby 和 Rails 的核心前提：你不需要一个八人团队，你一个人也能做出来。Rails 从一开始就试图成为“单人开发者的框架”，而且我认为它在这件事上比几乎所有框架都做得更成功。

而我们今天对 AI 兴奋的原因也一样：我们对小团队能获得的杠杆感到兴奋，因为 AI 能做很多事。

有一个根本事实没变：当你降低实验成本、降低构建一个“值得做的东西”的生产力成本时，你就会有更多“射门次数”（shots on goal）。

Ruby + Rails 能做到这一点；AI 也能做到；甚至更好的是：AI + Ruby on Rails 一起做到。

但我不确定游戏的本质在这点上发生了根本变化，也许只是变得对更多人可及了。

我觉得这大概率是好事——不，只能说：这就是好事。我们应该从“对人类整体有什么分类级别的好处”来理解：对全人类而言，难道不是更好——我们有更多实验吗？即便最终“命中并变成可持续商业”的人，可能比例更低（我甚至不确定这是否属实，但先这么假设）。

而作为一个文明整体，我们最终仍然会在更多类别、更多细分领域里，更快地获得更好的软件。问题的一部分在于：无论是 Web 开发圈，还是独立开发者（indie hacker）圈，很多讨论都过于短视地集中在那些我们一直反复折腾的“通用大类”上。

比如待办事项应用。好吧，我职业生涯里大概已经做过七个了，而全球可能已经有二十亿个同类产品。最后真正成功的，可能也就那么几个，剩下 99% 都失败了。

但你知道吗？你有没有试过给美发沙龙做软件？他们可没有一万种选择。有时候，他们甚至几乎没有任何选择，除了那些“狗屎一样”的系统。那种三十年前做出来的烂软件，出自一些对“好软件”毫不在意的人之手。所以，如果你愿意跳出这些吸引了绝大多数人的大而泛的领域，其实机会依然多得很。

颇具讽刺意味的是，我自己长期以来恰恰以“不去碰这些方向”为傲——只解决我自己的问题。因为我觉得那样更简单，而且也确实如此：当你解决的是自己的问题时，你立刻就能判断你做出来的软件到底好不好。

这并不意味着它一定会成功，但至少你有了第一道过滤器。如果让我去给美发沙龙做软件，我其实并不知道什么是好、什么是坏，我得不停地去问别人：“你们怎么看？你们给我什么反馈？”老实说，我不确定自己是否适合为了正在构建的软件，去进行这么多和他人的互动。

但我认为，对那些愿意这么做的创业者来说，机会是非常多的，而这其实也是大多数人。只要我们稍微把视野放宽一点，不要总是说：“天啊，现在再做一个新的待办事项应用太难了。”因为这个领域在过去三十年里，已经被来来回回地“薅”了大概五十亿次。

但你往外看——就只要离开它五米远——到处都是一大片未被开发的绿地。真的，到处都是。

DHH 说 95% 代码是手写的，但他又天天用 AI

主持人：David 你说 Fizzy 95% 的代码还是手写的，对吧？你每天都在用 AI。但对我来说，今年正好相反：我现在大概 90% 的代码都是 AI 写的。所以我的疑问是：如果你说你不怎么用 AI 写代码、或者 AI 不替你写代码——那生产力提升到底从哪里来？尤其对一家小公司来说，比如给美发店做软件，它不需要庞大的客服团队，也不需要很多外围部门，核心就是把软件做出来、交付出来。所以你觉得 AI 让软件开发更快的关键在哪里？

DHH：我说说我自己的体验——从这波 AI 开始我就一直在用。

我的生产力提升，主要来自：它让我更强、更聪明、更快——

• 更快上手新 API、新技术

• 更快理解新概念（我会让 AI 解释给我听）

• 更快找到“为什么这个 bug 会这样”的正确线索

比如 Omarchy 这个项目，如果没有 AI，它就不会存在。我不会有耐心去 Linux 论坛里翻半天，去解读那些晦涩的错误信息到底是什么意思。这对我来说不可能。

AI 带来的巨大提升，是给了我一个地方，把错误信息贴进去，然后得到比那种居高临下、还过时三年的 Stack Overflow 回答更好的线索。

收益巨大。真的巨大。

还有我需要读某个东西时、学习某个东西时，它也很有帮助。举个快例子：我们最近把 Rails 的 CSRF 防护机制改了——从以前“把 token 放进 cookie”的方式，改成使用现代浏览器的新特性：通过一个 header 来做。

我可以直接问 AI：“那个 header 是什么？”“什么时候开始支持的？”“具体有哪些细节？”这些答案我当然也能手动查：去 caniuse.com、看历史、查 RFC……全都能做。但 AI 能把这些东西一盘端上来，整合在一起，省事又快。

“AI 只是让我变聪明了”

我能更快学到更多东西。而这正是我真正喜欢的地方：不是让 AI 替我做事，而是用 AI让我更聪明。

当然，这种模式未来未必会成为主流。

就像你说的，你已经让 AI 写很多代码，甚至多数代码。我完全准备好在某个时点，我也会进入那种状态。

但就现在而言，我仍然在意代码的样子。我在意它的美感。我在意打磨、推敲、润色。

这可能是一种“奢侈”，有点像现代的马鞍匠：他会在意字母压得是否刚好、针脚是否完美。你可以说：“但你已经不是交通运输的主力生产体系了。”我会说：那又怎样？只要我还享受，我就会继续做我手写代码的“马鞍”。

而且我也意识到：这种模式目前仍然是有竞争力的。

在 37signals，我们并不觉得自己在产出能力、发布能力、改进能力上落后。因此我对一些说法保持怀疑：“AI 已经强到可以把标准 SaaS 公司的一半程序员裁掉，还能跑得更快。”我没看到。

我当年也用同一套“根本测试”来审视云计算：“我们能不能用更少的人、花更少的钱，做更多的事？”我们几年前退出云，就是因为这个测试没有通过。而且我也不太听说这个测试在别处通过过。云计算并没有让你把运维团队砍半、把基础设施预算砍半。很多时候恰恰相反：上云之后团队规模翻倍，账单翻四倍。

主持人：你们切换之后是不是省了类似每月一百万美元？很夸张的数字？

DHH：我们现在大概是一年省200 万美元。我们云预算峰值大概是 340 万美元，现在的持续成本在 100 多万美元左右。所以在成本上，节省非常巨大。

这和 AI 有一些相似之处——不完全相同，但有相似之处：我觉得现在很多人在用 AI，脑子里觉得自己“好高产”，但他们其实交付更少、做出来的东西更少，甚至理解得更少。

“Vibe Coding”的风险：能力会从指尖流走

DHH：AI 还有另一个因素：当我尝试“氛围式写代码”（vibe coding）的时候——尤其在一个我还没完全内化的新领域——我能明显感觉到我的能力在从指尖滴走。

我刚开始做 Omarchy 时，写了很多 bash。我以前从没系统写过大量 bash，最多就是命令行里用用。然后我发现自己一次又一次问 AI：“某个 if 条件到底怎么写？”

这时你就会想：“为什么我没有内化这件事？我没内化，是因为我把它外包给 AI 了。”那这样更好吗？我现在更划算了吗？还是说，我跟当年那些老师一样天真：他们以为有了计算器，学生就不需要背乘法表了？不对。如果你不能迅速在脑子里算出 7×7，你真的会把自己变成傻子。

主持人：那你有没有形成一种直觉：该在哪里划线？你不可能知道一切，对吧？你也会把你不会的事交给信任的同事去做，你不会因为让同事设计某个东西就觉得“能力在流失”。你能接受：“这事我不需要会 / 我不想会”。那在 2025 这样疯狂的一年里，你有没有更清晰的边界：哪些你想自己掌握、哪些你可以忽略？比如 bash。为了推进 Omarchy，你觉得 bash 该学到什么程度？又有哪些可以不学？

DHH：我觉得我得会几乎全部，除了怎么在 bash 里搞数组（笑）。因为 bash 里数组那玩意儿复杂得离谱，简直反人类。但我其实认为：人类大脑是个很惊人的器官，它不会像 LLM 那样“容量到顶就装不下”。我们用得越多，记忆和能力的“配额”会增长。

所以我真正担心的趋势是：随着时间推移，我知道得更少、我变得更不胜任。我需要一条向上增长的移动平均线。

我不需要把所有领域都吞进去——我不需要什么都懂。但一年结束时，我应该在更多领域懂得更多。如果我不在这种上升轨道上，我会无聊。我无聊就会没动力。没动力我就什么也不干。这也是 AI 讨论的一部分：我们得想清楚，我们真正享受这套方程式里的哪一部分。

我个人不享受当项目经理。我会做——而且不止偶尔——因为我想要“组织一群人”能产出的结果。

但当我看 AI 这件事时，我不想当一群 AI agent 的项目经理。那不是我想要的状态。

我喜欢写代码。而至少在此时此刻，这是一个仍然有竞争力的选择。

当然，这可能三个月后就变了；下周就变了；随时都可能变。但 AI 公司那些领袖已经预言“再过五分钟就结束了”预言了很久了——现在也没结束。

你看 AI 公司自己，它们也还在招聘大量程序员。

我们并没有到 AGI，没有到那种“人类写代码的时代死了”的程度。

这并不否认你说的：有些程序员已经觉得自己大多数代码都让 AI 写了。但至少在市场上——按我看到的情况——还没有出现那种“压倒性差距”，就像：一个公司用马车送啤酒，另一个公司用卡车送啤酒。那种经济差距会非常快把前者淘汰。我还没在 AI 身上看到这种情况。也许数据有滞后；也许已经发生了——我仍然怀疑。

即便我在长期上是极度“AI 乐观派”，但就当下，我没看到。

有时神得离谱，有时烂得没法维护

DHH：而且原因之一是：我每天都在“盯”着它。我一直在问 AI：你能给我写这段代码吗？

它会写。然后我会想：“不，我不喜欢这个。”“我甚至不想维护它。”“它做得还不如大多数初级程序员会被要求做到的水平。”

但偶尔，它也会给出另一种答案：我问它一个东西，它拼出来的结果让我震惊：“它怎么知道的？它怎么能把这些全部串起来？”那真的很惊人。

所以我感觉它像一个闪烁的灯泡：你在完全黑暗里，它突然一闪——你觉得“我什么都看见了”。两秒后，啪，又全黑。如果你能让这个灯泡稳定下来、一直亮着——那对人类当然是巨大的福音。

顺便说一句，我很喜欢美国的一点就是：美国把这个“闪烁灯泡”当成一种信仰——相信我们能把它变可靠，能到 AGI。现在大家就是一场巨大的押注：押注这一定会发生。即便我这么 AI 乐观，我仍然会对这种规模的“集体确信”感到惊叹：一个经济体一起说： “不管花多少代价，100 万亿、1000 万亿，我不在乎，我们一定能到那里。”我会想：这也许就是为什么它会成为“第一名”。

主持人：确实是个令人兴奋的时代。就像你说的——能活在此时此刻本身就是一种奇迹。我们也差不多到一小时的时间上限了。今天能和你重新连上线真的很开心，感谢你抽时间来。你现在也在忙 Fizzy。要不你简单跟大家说说：Fizzy 是什么？在哪能了解更多？然后我们就收尾。

DHH：当然。Fizzy 在fizzy.do。它是对 Kanban（看板）的一个全新诠释。这里还有个小故事：Jason 特别擅长解释“为什么值得回头重新解决一个问题”。

Kanban 这个概念来自 50 年代，是丰田为了管理生产线提出来的。后来我们把它做成了软件。第一代软件化的版本大概是 2000 年初。再后来 Trello 出现，把这个领域彻底带火、带爆。但我们还是回到这个领域，说：“你知道吗？我觉得我们还能做一个更好、更舒服的版本。”

很多人很难理解软件这件事：明明一个问题领域已经有很多玩家了，为什么你还要进去？原因可能只是：你想做得更好、更有趣、更轻量、更丰富多彩、更令人愉悦、功能更少——这些带着“爱”的细节，我们都烘焙进了 Fizzy。而且我们把它定价得很便宜：1000 张卡片免费，之后是 每月 20 美元。同时我们也把整个代码库开源了：如果你想自托管（self-host），你可以免费用。服务器我们不替你付，你自己折腾就行。你也可以贡献代码，也可以从中学习。

做 Fizzy 是一件很快乐的事，而且它也像一个实验室。我们现在正在做 Basecamp 5。我们在 Fizzy 上尝试了很多新技术——不管是编程层面还是产品层面——我们会把最好的想法带回 Basecamp 5。如果你关心我对这些话题（或任何话题）的观点，你可以去 dhh.dk，我的东西都在那。

主持人：太棒了。很高兴你来做客，也迫不及待想看未来会发生什么。感谢你的时间，我们下期再见。

参考链接：

https://www.youtube.com/watch?v=uWqno4HM4xA

https://www.reddit.com/r/ClaudeCode/comments/1qhiicv/the_creator_of_nodejs_says_the_era_of_writing/

过去几周，我对于 Vibe Engineering 的实践有了更多的体会, 今天再次总结一下。其实也能看出来我避免使用 Vibe Coding 这个词，是因为当下的重点已经不再是代码，而是一些更高维度的东西。另外，本文的 AI 含量我会尽量控制在 5% 内，可以放心阅读😄。

之前我提到的我开始的 TiDB Postgres 重写项目已经不再在是个玩具。在前几天出差的路上, 因为长途飞行没有网络, 我仔细 review 了一下这个项目的代码, 虽然一些地方略有瑕疵, 但是总体质量已经很高, 我认为已经是接近生产水平的 rust 代码，和以前我理解中的早期原型的定义很不一样。

顺便提一句, 我认为这个项目从一开始就选择 rust 是一个无比正确的决定, rust 的严谨性让 AI 能写出更接近 bug free 的 infra code (对比我另一个项目 agfs 的 shell 和它自带的脚本语言 ascript，由于这项目使用 python，项目变大后，可维护性就大大降低，但此时重写已经很困难，只能捏着鼻子慢慢重构)，所以现在已经是 2026 年了， 如果你要再启动一个新的 backend infra 项目, rust 应该是你的第一选择。

验证差不多后，我也邀请了几位我团队内的几个顶尖的 vibe coder 加入项目, 看看 100% 的 AI Native 研发模式能在多快把这个项目推进到何种程度，无论如何都很想看看，应该会很有意思。

下面说说自己最近的一些感受。

当前关于 Vibe Engineering 的所有的认知都会在 1 个月内严重过时

并非危言耸听，哪怕我正在写的这篇文章，如果你是 2026 年 2 月看到，那么很遗憾，本文聊到的东西很可能已经过时，这个领域发展的太快，很多今天的 SOTA 也许下个月就过时了。而且很有意思，过去很多对 Vibe Coding 嗤之以鼻的大佬，例如 DHH，Linus，Antirez 等，在 2025.12 月开始纷纷改口，我觉得这是相当正常的，去年 12 月开始，AI 编程工具和头部的模型突然有一个跳跃式的进步，突然对于复杂任务和大型项目的理解，以及写出代码的正确率有了极大的提升。这进步大概来自于两个方面：

一方面头部模型在长上下文（>256K) 的支持，尤其是关键信息的召回率提升惊人

例如上面是 GPT-5.2 在长上下文的召回表现和 GPT-5.1 对比很明显，要知道对于 Agent Coding 的场景来说，通常是多轮次推理 + 长上下文（因为要放更多的代码和中间推理结果）才能更好的有大局观，大局观的正确是对于复杂项目起到决定性因素。在这种场景下，你可以做一个简单的计算，一个模型（类似 GPT-5.1) 每轮的召回率 50%，大概 3 轮后，正确的召回率就会降低到 12.5%, 而 GPT-5.2 仍然能保持 70% 以上。

另外一个进步是主流的 Vibe Coding 工具的 Context Engineer 实践日益成熟，例如 Claude Code / Codex / OpenCode。从用户体验到最佳实践，肉眼可见的越来越好，例如对于 Bash 的使用，Subagent 等，这方面越来越多的资深 Engineer 的重度使用和经验分享会对这些工具的进化提供数据飞轮，尤其是 AI 也在深度的开发这些工具，迭代速度只会更快。

其实这个进步也并不是去年 12 月那个时间点的突然什么黑科技爆发，其实前几个月一直在进步，不过还不能长时间离开人工干预，更像是那个时间点，主流 Coding Agent 的质量超过了一个临界点：100% 的无人工干预下完成长时间的 Agentic Loop 成为可能。

Hire the best (model)，否则就是在浪费生命

上面所有提到的进步，我个人感觉只反映在了最顶尖的闭源头部模型中。我听到很多朋友和我反馈到：“我感觉 AI 编程还是很傻啊？并没有你提到那么聪明”，我首先会反问，你是不是只是用着 $20 一个月那种入门模型？如果是的话，那先去用一阵 $200 以上的 Pro Max 档次的，也许有惊喜。

我个人认为，目前主流的模型，即使并非头部那档，作为 chatbot 处理大多数普通人的短上下文的日常工作是完全足够的，哪怕是 GPT-4 在和你讲人生道理的时候也已经足够把你说得一愣一愣了。

作为人来说，我们的直觉或者是一些简单的 CRUD Demo 已经无法评估这些模型之间的智商差距了。但是在复杂的项目的开发中，这个差距是极端明显的。

根据我个人的实践来说，当下能用来进行大型 Infra 项目（数据库，操作系统，编译器等）开发的模型大概就两个：GPT-5.2 (xhigh) + Opus 4.5，还有半个算是 Gemini 3 Pro。

大概上个月我主要用着 opencode + oh-my-opencode + Opus 4.5 但是最近两周转向到了 codex + gpt-5.2 的组合，下面分析一下这几个模型的一些脾气和调性，仅仅是个人感受，而且是在后端 Infra 软件开发这个领域，仅供参考。

Opus 4.5 的风格是速度很快，是个话唠，由于 Sonnet 4 有严重 reward hacking 问题，例如是在解决不了 bug 的时候会偷偷的构造作弊的测试然后糊弄过去，所以导致很长一段时间我都不太敢用 Sonnet 系列模型干复杂的事情，但是这点在 Opus 4.5 中解决得很好，即使在模型冥思苦各种尝试想都搞不定的情况下也没有选择作弊，让我放心不少，但是 Opus 的问题是 reasoning 和做 investigation 的时间太少，动手太快，以至于发现不对的时候，又返回头确认假设和研究，这样的特性催生了像 ralph-loop 这样的奇技淫巧。比方说，同样的一个 prompt 在 Claude Code 结束后又通过 stop hook 重新调用，再完整走一遍流程，不断地逼近最终的结果。

相比之下，GPT-5.2 更像是一个更加小心谨慎、话不多的角色。我最开始用 Codex 的体验其实不算太好，因为我一直觉得它有点太慢了。主要是因为我习惯用它的 xhigh 深度思考模式，在真正开始写代码之前，它会花很长时间去浏览项目里的各种文件和文档，做很多准备工作。可能也是因为 Codex 的客户端不会告诉你它的计划和大概需要多久，所以就显得过程特别长。

有时候一些复杂的任务，它前期的调查可能就要花上一到两个小时。但是经过长时间思考后它完成的效果通常是更好的，尤其是在一个项目的大体框架已经稳定，Codex 考虑得更周全，最终也体现出更少的 bug 和更好的稳定性。

对于第三个顶级模型，也就是 Gemini 3 Pro。虽然我也知道它的多模态能力非常吸引人，但就复杂任务的 Coding 场景而言，至少从我个人的体验来看，它的表现并没有 Opus 4.5 和 GPT-5.2 那么强。不过它确实针对一些快速的前端项目 Demo 和原型制作做了一些优化，再加上它的 Playground 模式，让你在需要一些炫酷的小 Demo 或前端项目时能更快实现。

其实一个比较反直觉的事情是，过去我们经常说 Vibe Coding 只能搞一些比较简单的事情，比如上面那些小 Demo 或 CRUD 项目，你会看到网上各种各样的 KOL 其实都在做这种小原型，反而大家觉得对于一些像后端这种核心的基础设施代码，当前 AI 还是搞不定的。我以前也这么想，但从去年 12 月份开始，这个结论可能需要修正了。

这里面的原因是，其实这类基础设施的代码通常是由顶级工程师长期精雕细琢而成，它们有清晰的抽象、良好的测试，甚至代码本身经过多轮重构后也相当精炼。所以当 AI 具备足够的上下文空间 + 更好的推理能力 + 更成熟的 Agentic Loop + 高效的工具调用时，这类 Infra 代码的开发和维护反而是能最有效地利用这些顶尖大模型的智商的场景。

在实际的工作中，我经常会让多个 Agent 互相协作，或者使用一些复杂的工作流来把它们编排在一起，并不会让一个模型来完成所有的事情。后面我会再分享一些我自己实践中的具体例子。

人在什么时候进入？扮演什么角色？

上面提到了，这些顶级模型再配合主流的 Vibe Coding 工具，基本上已经能超越大多数资深工程师的水平了。这不仅体现在能写出更少 bug 的代码，也体现在在 review 中能发现更多人类工程师可能看不到的问题，毕竟 AI 真的会一行一行仔细看。

所以人在这个过程中扮演什么样的角色，哪些阶段只有人才能做？根据我自己的实践来说，第一当然是提出需求，毕竟只有你才知道你想要啥，这很显然，但是有时确实也挺难的，毕竟人很难从一开始就准确描述自己想要什么，这时候我会用一个偷懒的办法：让 AI 来角色扮演，比方说，我在开发 PostgreSQL 版本的 TiDB 时，我就让 AI 假设自己是一个资深的 Postgres 用户，从开发者的视角告诉我有哪些特性是非常重要、一定要实现而且 ROI 比较高的，让它列出 N 个这样的功能点，然后 AI 就会根据它的理解生成一个需求列表，接下来你再和 AI 对这些需求逐个打磨，这其实是一个高效冷启动的方法。

第二是在需求提出后，现在的 Coding Agent 大多都会和你有一个规划阶段（Planning），会反复确认你的需求。在这个过程中其实有一些技巧，比如不要给 AI 太具体的方案，而是让 AI 来生成方案，你只需要关注最终你想要的结果；提前告诉 AI 有哪些基础设施和环境的问题，让它少走弯路。

另外，我通常会在提出需求的第一阶段就要求 Agent 做的一些关键动作。比如无论接下来做什么，都要把计划和 todo 列表放在一个 work.md 或 todo.md 这类文件里。还有，每完成一个阶段的工作，就把上一阶段的经验教训更新到 agents.md 里。第三点是当一个计划完成并且代码合并后，把这个工作的设计文档添加到项目的知识库中（.codex/knowledge）。这些都是我会在一开始提需求时就放进去的内容。

第二个阶段就是漫长的调查、研究和分析的阶段。这个阶段其实基本上不需要人做什么事情，而且 Agent 的效率比人高得多，你只需要等着就好。唯一需要注意的就是在 Research 的过程中，我通常会告诉模型它拥有无限的预算和时间，尽可能充分地进行调研。另外，如果你的模型有推理深度的参数的话，我建议在这个阶段把它们全部调到 xhigh 的级别。虽然这会让过程变慢，但在这个阶段多烧一些 token、做好更好的规划、了解更多上下文，对后续的实现阶段会更有帮助。

实现阶段没什么特别好说的，反正我现在基本不会一行行去看 AI 的代码。我觉得在实现阶段唯一要注意的就是，要么你就让 AI 完全去做，要么你就完全自己做，千万别混着来，我目前是倾向于完全零人工干预的模式效果更好。

第四个阶段人就变得非常重要了，那就是测试和验收结果的阶段。其实在我个人和 AI 开发项目的过程中，我 90% 的时间和精力都花在了这个阶段：也就是如何评估 AI 的工作成果，我觉得在 Vibe Coding 时：There's a test, there's a feature，你只要知道如何评估和测试你要的东西，AI 就一定能把东西给你做出来。另外值得注意的是，AI 在实现过程中会自动帮你添加很多单元测试，但说实话，这些单元测试在微观层面基本都能通过，毕竟 AI 写这种局部代码时已经很难出 bug。

但 AI 不擅长的是集成测试、端到端测试。比如在开发一个 SQL 数据库时，哪怕每个细节的单元测试都没问题，但整合到一起时集成测试可能会出错。所以我在完成大目标前，我一定会先和 AI 一起做一个方便的集成测试框架，并提前准备好测试的基础设施，收集和生成一些现成集成测试的用例，尽量一键能运行那种，这样在开发阶段就能事半功倍，而且关于如何使用这些测试的基础设施的信息，我都会在正式开始前就固化在 agents.md 里，这样就不用每次沟通的时候都再告诉它该怎么测试了。

关于测试从哪来的问题，我自己的经验是你可以让 AI 帮你生成，但一定要告诉它一些生成的逻辑，标准和目的，另外就是千万不要把生成测试的 Context 和实际进行开发工作的 Agent 的 Context 混在一起。

第五个阶段是重构和拆分。我发现当前的 Coding Agent 在面对单一模块复杂度超过大约 5 万行代码之后，就开始很难在 1-shot 里把问题一次性解决掉（但反过来这也意味着，只要任务复杂度控制在这个阈值之下，在一个足够好的 first prompt 驱动下，很多事情确实可以做到 1-shot AC），Agent 通常不会主动去做项目结构和模块边界的治理，你要它把功能做出来，它恨不得把所有东西都写进几个几万行的大文件里，短期看似很快，长期就是债务爆炸。我自己在这个阶段的做法通常是先停下来，用自己的经验进行模块拆分，然后在新的架构下进行 1～2 轮的重构，之后又可以高并发度的进行开发了。

多 Agent 协同编程的一些实践

前面提到我现在使用 Coding Agent 的时候，通常不会只用一个，我自己的工作流会尽量让多个 Coding Agent 同时工作。这也是为什么有时候在一些项目上会花掉好几千美金，因为你必须把并发跑起来。当然，并发和吞吐是一方面，但另一方面我觉得让不同的 Agent 在不共享上下文的前提下互相 Review 工作，其实能显著提高质量。

这就像在管理研发团队时，你不会让同一个人既当运动员又当裁判。相当于 Agent A 写的代码交给 Agent B 来 Review，往往能发现一些 A 看不到的问题。通过这样的循环往复，你就会更有信心。

例如，我在实际工作中现在用得比较好的一个工作流是这样的：首先让 GPT-5.2 在 Codex 下生成多个功能的设计文档，做出详细的设计和规划，第一阶段把这些规划文档都保存下来。然后在第二阶段，依然用 Codex 根据这些需求文档一个一个去实现功能。在实现的过程中，就像我前面提到的那样，记录 To-Do、经验教训，并在接近完成的时候，在代码通过测试并准备提交之前停下，把当前的工作区交给另一个 ClaudeCode 或 OpenCode，在不提供上下文的情况下，让 ClaudeCode 来 Review 当前还未提交的代码，根据设计提出修改建议。然后再把这些建议发回给 Codex，让 Codex 来评论这些建议，如果有道理就修改代码。改完之后，再让 ClaudeCode (Opus 4.5) 那边再次 Review，直到双方都觉得代码已经写得很不错了，再提交到 Git 上，标记这个任务完成，更新知识库，然后进入下一个功能的开发。

另外在一个大型项目中我会同时开多个 Agent (in different Tmux) 并行开发多个功能，但我尽量让它们负责完全不同的模块。比如一个 Agent 修改内核代码，另一个 Agent 做前端界面，这样就能分开进行，如果你需要在一份代码上做一些彼此不太相关的工作时，可以利用 git 的 worktree 让多个 Agent 在不同的 git 分支上各自工作，这样也能快速提升吞吐量。

未来的软件公司和组织形态

未来的软件公司会是什么形态呢？反正从我自己的实践和与一些朋友的交流来看，至少在当下，团队中用 Coding Agent 的 token 的消耗呈现出一个非常符合二八定律的分布，也就是说，最头部的用 AI 用得最好的工程师，他们消耗的 token 可能比剩下 80% 的工程师加起来还要多，而且 Coding Agent 对于不同工程师产出（质量，吞吐）的增益是不一样的，这个方差非常大，也就是对于用的最好的一群人，他们的增幅可能是 10x，但是普通人可能也就是 10%，而且唯一的瓶颈是人工的 code review 和一些无法被自动化的线上运维工作（我觉得也很快了）而且这样的特点能够让这些头部的工程师在 AI 的协助下可以无边界的工作，也就是会有越来越多的 one-man army 出现，只是目前我认为和 token 消耗是正相关的，你能花掉多少 token，大致代表你能做得多好。

另外我发现一个很有趣的现象，同样是 10x 的工程师，他们各自的 Vibe Coding 工作流和最佳实践其实并不相同。也就意味着，两个顶尖的 Vibe Coder 是很难在一个项目中（的同一个模块）协作。这种工作方式更像是头狼带着一群狼群（Agents），在一片自己的领地里面耕耘，但是同一片领地里很难容纳两匹头狼，会造成 1+1 < 2。

在这样的组织形态下，我觉得传统意义上的“团队协作方式”会被重新定义。过去我们强调的是多人在同一个代码库、同一个模块里高频协作，通过评审、讨论、同步来达成共识；但在 Vibe Engineering 这种模式下，更有效的方式反而可能是强解耦的并行。管理者要做的是把问题切分成足够清晰、边界明确的“领地”，让每一个头部工程师带着自己的 Agent 群，在各自的领域里做到极致。

从管理的角度看，这其实是一个挺大的挑战。因为你不能再用统一流程、统一节奏去约束所有人。对顶尖的 Vibe Coder 来说，过多的流程和同步反而会显著拉低效率，甚至抵消 AI 带来的增益。管理者更像是在做“资源调度”和“冲突隔离”：确保不同头狼之间尽量少互相干扰，同时在必要的时候，能够通过清晰的接口、契约和测试来完成协作。

因为上面的种种，AI-Native 的研发组织其实很难自底向上从一个非 AI-Native 的组织中生长出来，因为大多数开发者面对变革的时候的第一反应其实并不是拥抱，而是回避和抵触，但是时代的进步不会因为个人的意志转移，只有主动拥抱和被动拥抱的区别。

大概就写到这里吧，总的来说，在这样一个大环境下，对个人而言意味着一场深刻的转变，就像我之前在朋友圈里提到的，我身边最好的工程师们有一些已经陷入了或多或少的存在主义危机。

但是作为具体的 Builder 的我来说是兴奋的，因为造物，在当下，门槛变低了许多，如果你能从造物中能获得成就感和找到人生的意义，那恭喜你，你活在一个最好的时代。但反过来，作为一个抽象的 “人” 来说，我又是悲观的，人类是否准备好面对这样的工具？以及这样工具带来的对于社会和整个人类文明的冲击？

我不知道。

整理 | 华卫、Tina

过去一年，编码 Agent 的变化速度，已经快到让人很难用“功能升级”来形容。

如果把时间拨回到一年前，Agent 还主要停留在代码补全、对话式改几行代码的阶段；而今天，在 Cursor 内部，工程师已经开始同时运行多个 Agent 并行“甩活儿”，让它们在代码库中自主修改、调试、复盘，再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作，而是开始习惯“等它跑完再看答案”。

在最近一次访谈中，Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断：这不是渐进式优化，而是一场正在发生的“换代”。更重要的是，他把这场变化的时间窗口，压缩到了未来三到六个月——在他看来，Agent 将不只是“更聪明”，而是会真正接管更长周期、更复杂的工程任务，整个行业的工作方式也将随之重塑。

下面是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。

一年多时间，编码 Agent“翻天覆地”

Harrison Chase：Jason，你能跟大家简单介绍一下自己吗？也给大家讲讲 Cursor 是什么吧。

Jason Ginsberg：好的。我目前在做一款 AI 编程工具，已经在 Cursor 工作了六个月，担任该产品的工程负责人。不过说实话，我日常的大部分时间还是在写代码和做设计工作。在加入 Cursor 之前，我在 Notion 负责 Notion Mail 相关工作。几年前，我创办了一家名为 Skiff 的公司，后来这家公司被 Notion 收购了。所以，我一直都在从事产品开发相关的工作，而且主要聚焦在生产力工具领域。

Harrison Chase：非常棒。我有很多话题想和你探讨。要不我先抛砖引玉，问问你对编码 Agent 的发展历程，以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一，我认为编码 Agent 的发展经历了几个阶段的转变：从最初的代码自动补全，到集成在集成开发环境（IDE）中的对话式交互，再到如今出现的各类终端工具，以及基于云端的异步 Agent。我很想听听你的看法，你觉得这样概括其用户体验的演变历程是否准确？或者你们团队是如何看待这一发展过程的？

Jason Ginsberg：我认为编码 Agent 的发展确实可以用 “翻天覆地” 来形容，而且这些变革基本上都是在一年多一点的时间里发生的。正如你所说，Cursor 最早开启了代码自动补全的先河，这种模式主要是在逐行的层面上提供辅助，适用范围也基本局限在单个文件内。而此后，几乎每隔几个月，我们就不得不提升产品的抽象层级，这其实是一个极具挑战性的产品设计难题。显然，Agent 的出现让开发者能够在多个文件之间灵活切换，并且可以放心地让 Agent 自主完成代码修改工作。

在过去两个月左右的时间里，我发现行业又出现了新的转变：开发者现在已经能够做到从项目启动到结束全程信任 Agent，并且会对整个代码库中多个文件的内容进行批量审核。因此，我们不得不对产品的整体布局进行大幅重新设计，将核心从逐行的代码差异对比，转向更偏向代码审查的模式。

展望未来的产品开发方向，我们的工作重心其实会更多地放在多 Agent 协同运行上。我们需要实现的是，能够快速验证这些 Agent 是否在正常运行，并且可以让它们并行工作，同时避免受到当前单一对话模式下各种选项和选择的束缚。

Harrison Chase：推动这些变革的核心因素是什么？仅仅是因为大模型的性能变得越来越好，还是有其他更多的影响因素？

Jason Ginsberg：我认为大模型性能的提升是一个很关键的因素，这让开发者能够更加信任 Agent 编写的代码质量。要知道，以前大家必须对 Agent 生成的代码进行非常全面细致的审查。

同时，现在也有了更完善的代码审查工具。比如我们有 BugBot，市场上其实还有很多类似的工具，它们都能够自动检查代码中存在的问题。

此外，我觉得从行业文化层面来看，开发者们对 Agent 工具的接受度和使用信心也在不断增强，甚至可以说已经 “上瘾” 于这类工具带来的便捷。而且，一旦习惯了完全依赖 Agent 进行编码的工作模式，再切换回传统的编码方式其实是很困难的。所以现在，我们能看到越来越多的开发者已经将 Agent 辅助编程作为默认的工作方式。

最顶尖工程师的干活秘诀：全靠 Agent？

Harrison Chase：你观察到大家使用 Cursor 的方式都有哪些不同？或者你自己平时是怎么使用 Cursor 的？

Jason Ginsberg：其实在我们公司内部，工程师们使用 Cursor 的方式就五花八门。甚至团队里有几位工程师，他们完全不使用 Cursor 的 Agent 功能，比如负责安全和基础设施的同事。所以，确实有一部分用户非常依赖代码自动补全功能，日常使用中大部分操作都是基于补全功能完成的。但令人意外的是，我发现团队里一些最顶尖的工程师，我们称他们为 “核心用户”，他们做任何工作都会完全依赖 Agent，甚至会同时运行多个 Agent 并行处理任务。

至于我个人的使用习惯，我并不会去设计那些复杂繁琐的提示词，也没有什么所谓的 “Agent 使用秘籍”。我写的提示词往往都很简短，甚至还会带有拼写错误。我会针对手头不同的工作任务，或者同一个问题的不同模块，同时启动多个 Agent，然后等待它们返回结果。

目前我用得最多的是我们今天刚刚发布的一个新功能：调试模式。这个模式下，Agent 能够通过生成日志来进行自我评估，之后开发者复现相关操作步骤，Agent 就会通过查看日志判断问题是否得到解决。这个功能非常实用，因为它相当于通过投入算力去不断尝试解决问题，最终攻克那些手动排查起来极为棘手的难题。

Harrison Chase：调试模式具体是什么样的？为什么需要专门设置这样一个模式？难道不能自动完成调试吗？直接给 Agent 下达调试指令不也可以吗？

Jason Ginsberg：其实我也认同你的这个想法。所以在开发调试模式的时候，我们内部确实有过不少争论。主要原因在于，Cursor 目前已经有很多功能模式了，如规划模式、询问模式等等，这些模式其实不太容易被用户发现。我们一直认为，这些模式都很实用，理想的状态应该是，Agent 能够根据用户的操作场景，自动匹配并启用最合适的模式，无需用户手动切换。

而现阶段调试模式之所以需要手动开启，是因为它的交互方式比较特殊。在运行过程中，Agent 会暂停当前的工作，向用户提问以获取反馈。如果用户不熟悉这种交互逻辑，可能会觉得比较困扰。

Harrison Chase：Agent 具体会询问哪些问题，又需要用户提供什么样的反馈呢？

Jason Ginsberg：我举个例子吧。假设我正在开发一个前端应用，遇到了一个很让人头疼的问题：菜单总是在左上角弹出。这时候我会对Agent说：“这个菜单需要锚定到按钮的位置。” 随后，Agent 会启动服务器，并在整个代码库中添加大量日志，同时提出一系列可能导致该问题的假设，如 “可能是某个定位参数设置错误”、“可能是事件绑定逻辑有问题” 等。之后，Agent 会提示我：“麻烦你点击这个按钮，打开菜单，看看问题是否解决。” 如果我反馈问题依然存在，Agent 就会查看生成的日志，然后分析判断：“这个假设成立，那两个假设不成立”。通常这样反复两三次之后，Agent 往往就能找出并解决问题。

Harrison Chase：你觉得人类还需要手动操作多久？就不能让 Agent 自主完成点击、测试这类操作吗？

Jason Ginsberg：一两个月内，毕竟这个行业的发展速度实在太快了。

Harrison Chase：刚才你提到了 Agent 的多种不同模式，比如规划模式、解释模式、调试模式等等。这些模式在实际应用中到底意味着什么？难道只是为 Agent 设置不同的提示词这么简单吗？还是说背后有更复杂的逻辑？

Jason Ginsberg：很多时候，确实就是修改一下系统层面的提示词。不过在某些情况下，我们也需要对用户界面进行相应的调整。比如规划模式现在也加入了交互提问功能，运行过程中会主动打断用户操作，寻求反馈。用户有时也可以自行设置参数，如调整 Agent 打断的频率等。再比如询问模式，它不只是依赖特定的系统提示词，还会限制 Agent 调用某些与文件编辑相关的工具，以此来保证功能的稳定性和可靠性。

Harrison Chase：回到之前的话题，关于大家使用 Cursor 的不同方式，你觉得未来使用编码 Agent 或者说 Cursor，存在所谓的 “最佳方式” 吗？

Jason Ginsberg：我觉得并没有什么 “最佳方式”，具体的使用方法很大程度上取决于工程师的个人工作习惯以及他们所处理的具体工作内容。目前行业里，既有异步运行Agent的应用场景，也有开发者深度参与、实时交互的模式，就像一边编程、一边像画画一样实时调整代码或者进行可视化的编辑操作。不过我经常在推特上看到一些所谓的 “Agent 使用技巧”，其实对此我是有点持保留态度的。很多人会说 “这才是使用 Agent 的最佳方式”，但在我看来，这些技巧往往是凭空杜撰的。

我们团队内部其实并不会使用那些冗长复杂的提示词，也不会采用多阶段规划的策略。大多数时候，我们都是快速迭代，如果 Agent 运行的结果不理想，就直接终止进程，重新启动 Agent。通常这种方式的效率是最高的。

自然 “唠嗑”是 Cursor 最终交互模式？

Harrison Chase：如果让你预测一下一年后的情况，你认为开发者在 IDE、终端以及其他形态的载体上使用 Cursor 的时间占比会是怎样的？

Jason Ginsberg：当然，我肯定会带有一定的主观偏向性。但我认为，终端工具并不会成为用户的首选。我觉得，真正驱动行业发展的是用户对Agent的信任度不断提升，他们更希望等到Agent完成所有工作后再查看最终的修改结果，然后决定是否采纳，同时也愿意让 Agent 运行更长的时间，以实现更智能的处理。

而 IDE 之所以至关重要，是因为它是为整个软件开发周期量身打造的工具。从项目的构思规划，到运行代码修改、查看代码内容、清晰对比代码差异、提交代码合并请求，再到在浏览器中预览效果所有这些环节，都可以无缝集成在 IDE 的模块化功能之中。这一点其实很容易被忽视，毕竟 IDE 的这些功能是经过了数十年的发展才逐步完善起来的。

我认为，当前行业的一个明显趋势是，产品层面的设计变得越来越重要。现在 Cursor 用户使用频率最高的功能，如规划模式，其实都需要可视化编辑器的支持，用户需要能够在编辑器中添加注释，并进行实时交互。一旦脱离了按钮、弹窗和菜单这些可视化交互元素，用户与工具的交互难度会大大增加。

不过，我觉得未来并非所有操作都必须局限在笔记本电脑的 IDE 中完成。这种模式并不会被完全取代，具体的使用场景会根据实际需求灵活变化，适用的场景也会更加广泛。用户在更多场景下，都能够使用到 Cursor 这样的工具。

Harrison Chase：未来会有更多场景都能用上像 Cursor 这样的工具。你们应该有对应的官网吧？用户可以直接在网页上进行交互操作，是这个思路吗？

Jason Ginsberg：对，我们确实有官网。这么做的原因是用户可以通过手机等设备随时随地访问。我觉得在不远的将来，用户完全可以戴着 AirPods，开启语音模式，和Agent实时沟通、碰撞想法，让Agent不断优化方案。等用户到了办公室，打开笔记本电脑，就已经有一堆代码修改记录或者演示视频等着审核了，到时候只需要简单确认通过或者驳回就行。如果某些细节还需要微调，再把项目下载到本地修改就好。

Harrison Chase：我认为 Cursor 真正的优势，在于围绕 Agent 交互打造的整套设计和用户体验体系。你之前在 Notion 工作过，我记得即便是在生成式 AI 普及之前，Notion 的设计和用户体验就已经广受认可了。当然，他们在生成式 AI 时代也很好地完成了转型。从一家在生成式 AI 普及前就拥有出色设计积淀且顺利完成转型的公司，再到如今专注 Agent 相关工作，你觉得 Agent 的出现给产品设计和用户体验带来了哪些变化？现在的工作模式和之前有相似之处吗？

Jason Ginsberg：我觉得总体来说，我们产品的大部分设计其实并不是 AI 专属的。要知道，产品可用的交互组件和用户体验模式就那么多，市面上的应用本质上也都是基于一些传统的模式搭建的，如收件箱、仪表盘、聊天界面，这些都是很成熟的设计。所以我们的工作核心，更多是把这些现有的设计模式进行合理组合，然后在产品中恰当地呈现出来。这一点和 Notion 的产品理念是相通的，同时也是 Cursor 和集成开发环境（IDE）的核心特质：极高的模块化程度。

作为用户，你会发现每个人的 IDE 界面布局都可以千差万别。你可以自定义面板布局，把任意组件拖放到任意位置，和坐在你旁边的同事设置出完全不同的界面。我认为这种模块化设计对产品的适应性至关重要，毕竟如我之前所说，Agent 的能力发展日新月异，用户对产品的需求和期待几乎每隔几周就会发生变化。几个月前我们推出 Cursor 2.0 的时候，并没有把原来的产品推倒重来，只是把各个功能模块重新组合，调整为侧边栏收件箱式的管理布局，同时优化了聊天界面的信息密度而已。

Harrison Chase：听你这么说，很多组件的底层逻辑其实是相通的。那有没有出现新的组件？或者某些组件的优先级发生了变化？毕竟这些组件最初都是为 “人类与软件交互”“人类通过软件协作” 的场景设计的，现在加入了 Agent 这个新角色。这其中有没有产生什么新的变化？还是说其实本质上没有太大不同？

Jason Ginsberg：我认为底层的设计逻辑和核心要素其实没有变，关键变化在于谁在主导界面交互。而在这个核心框架下，其实可以演变出无数种交互形式。就拿交互的抽象层级来说，一年前大家使用Agent的时候，都恨不得盯着它的每一步操作，全程 “盯梢”。但现在 Agent 的操作步骤变得无比繁杂，用户根本看不过来。所以我们需要优化信息呈现方式：如何对操作步骤进行分组？如何提炼关键信息？

当用户足够信任 Agent 的操作后，我们就需要把重点放在文件的实际修改内容上，并且为这些修改添加更详细的注释说明。当然，我们也可以进一步提升交互的灵活度，比如聊天对象不再局限于单个 Agent，而是可以同时和多个 Agent 对话。这就需要一套更智能的后台交互逻辑来支撑 ，系统要能识别用户在和哪个子 Agent 对话，并且协调这些 Agent 完成对应的修改。未来这种交互的抽象层级还会不断提升。

Harrison Chase：你觉得交互的抽象层级最高能达到什么程度？我知道预测未来很难，但还是想听听你的看法。

Jason Ginsberg：我觉得未来，我们现在看到的各种操作选项，如选择模型、选择功能模式、选择运行环境这些都会逐渐消失。最终的交互模式会变得像和真人对话一样自然。但这并不意味着任何人都能随便写代码，在那个阶段，这个工具依然是为专业工程师服务的。因为你还是需要具备专业的行业术语知识，清楚自己想要修改的内容是什么。做产品的人，要明确自己想要的工作流程和功能需求；做基础设施的人，要足够了解代码库，知道什么样的架构和系统设计最适合当前要开发的项目。

而且我想强调的是，随着抽象层级的提升，我们并不会摒弃现有的功能。用户依然可以随时深入底层，查看细节、调整参数。只是产品的默认交互方式会不断优化升级。

Cursor 内部工作揭秘：少审代码、高频反馈

Harrison Chase：你之前提到了人类在 Agent 工作流程中的角色，比如查看代码差异、进行代码审查。你觉得 AI 会给代码审查工作带来哪些改变？

Jason Ginsberg：首先，就我们产品团队的工作模式来说，现在人工审查的比重已经大幅降低了。我们有一个叫 BugBot 的工具，它会自动检测代码问题，并且自主完成修复，还会在持续集成（CI）流程中不断迭代优化。这个工具的表现非常出色，也让我们对 AI 审查的代码质量更有信心。

其次是信息的语义化分组。用户查看代码差异时，可以清晰地看到 Agent 做了哪些修改。我们甚至可以展示 Agent 的原始指令，更理想的状态是，Agent 能够像人类一样，在处理大型代码合并请求时，为每一处修改附上注释，说明这么做的原因。我觉得这虽然算不上颠覆性的变革，但确实能给代码审查工作带来显著的优化。

Harrison Chase：出于好奇，我想问一下，Cursor 的工程师用 Cursor 写代码，用 BugBot 审查代码，那他们还需要和其他工程师沟通协作吗？

Jason Ginsberg：哈哈，这个问题很有意思。如果你以工程师的身份加入 Cursor，会立刻发现一个现象：所有人都在深度使用自家产品。我记得我入职第一周的时候，修改了一个快捷键设置。那个快捷键是 Alt+Shift+Command+J，非常冷门，我当时觉得选这个键肯定没人会注意到。结果刚改完不到半分钟，就有三个同事在 Slack 上发来消息：“你改的这个快捷键直接打乱了我的工作流程！到底怎么回事？”几乎任何产品改动，都会立刻收到同事们的强烈反馈。我觉得这其实是一件好事，大家就是在这种高频的反馈和交流中，快速推进产品迭代的。

Harrison Chase：从组织管理的角度，你们有没有采取什么措施来鼓励或者引导这种高频反馈的协作模式？毕竟大量的反馈涌进来，有时候也会让人应接不暇。

Jason Ginsberg：在我创办自己的公司之前，工程师们也会用邮件沟通，但用得并不多。大家甚至会说：“邮件只用来收垃圾邮件和购物通知，可别用它来发长篇大论的工作内容。”而在Agent这个赛道工作，其实完全不需要依赖邮件这种低效的沟通方式。我们团队的所有人都全身心投入工作，毕竟这是一个竞争非常激烈的领域，大家都对产品开发充满热情，会自然而然地用各种即时沟通工具协作。

另外，我在规划产品功能时，会遵循一个核心原则：我能开发什么功能，让自己的日常工作更轻松？ 具体来说，就是思考 “做什么能帮我明天更高效地完成工作，不用再处理那些烦人的报错和问题”。这个原则指导着我们的大部分工作。毕竟这种功能开发出来之后，我们自己能立刻受益，比如修复了一个烦人的漏洞，以后上班就不用再被这个问题困扰了。

迭代狂飙背后，核心功能竟来自员工 “自嗨”？

Harrison Chase：你觉得你们的产品路线图，有多大比例是由 “让自己工作更轻松” 这个需求驱动的？又有多大比例是来自外部用户的需求？这个比例随着公司发展有变化吗？

Jason Ginsberg：这个比例确实随着公司规模的扩大在变化。现在我们也会制定月度的产品路线图和目标，但说实话，我们很多核心功能都来自自下而上的创新。比如 Cursor 的Agent功能，这可以说是大家提到 Cursor 时最先想到的核心功能。这个功能是我们团队的一个人开发的，最开始所有人都不看好这个想法，但他很快做出了原型。大家试用之后都惊叹：“哇，这东西居然真的能用！”

我之前提到的调试模式也是如此。感恩节假期的时候我闲着没事，就开发了这个自己很需要的功能，现在这个功能也即将上线。这些功能的开发初衷，都是为了解决团队内部的需求。我们判断一个功能是否具备发布条件，一个重要的衡量标准就是内部的使用率和认可度。

Harrison Chase：你们的产品迭代速度快得惊人，是怎么保持这种高效的开发节奏的？

Jason Ginsberg：说实话，我们的工作流程其实非常精简，没有太多繁琐的制度。公司里虽然有几间会议室，也有一两位产品经理，但我们很少通过撰写文档或者开对齐会议来推进工作，大部分的讨论和决策都是在代码层面完成的。而这一切能够实现的核心原因，是我们对人才的极高要求。今年年初的时候，公司总共也就 20 人左右。之所以团队规模增长缓慢，就是因为我们的招聘门槛高到近乎苛刻。我们会反复评估：这个人很优秀，但他能成为团队里最顶尖的那批人吗？

正因为团队里的每个人都足够出色，所以我们可以放心地把任务交给任何一个人。团队成员的主观能动性都极强，从提出想法、设计用户体验，到在推特上回复用户的支持请求、和企业客户沟通需求，再到最终将功能落地，整个流程都能独立完成。所以说，我们能保持这样的速度，归根结底还是人的因素。

Harrison Chase：你们是如何规划产品路线图的？你刚才提到了以月为单位的规划周期，这是目前的常规规划时长吗？有没有更长期的规划？另外，行业技术迭代的速度实在太快了，你们是如何平衡 “跟进现有技术浪潮” 和 “实现技术跨越式发展” 这两者的？会不会主动预判技术趋势，提前布局未来方向？

Jason Ginsberg：我们确实会投入不少精力去思考未来，比如预判未来三个月可能实现的技术突破，然后主动押注相关方向，团队里有相当一部分人都在做这类前瞻性的工作。我们制定的月度路线图更多是围绕核心产品功能展开，聚焦于用户的实际需求以及那些能优化日常使用体验的功能。而那些需要投入两个月时间重构底层逻辑的重大项目，则会纳入更长期的规划范畴。

此外，我们的应变能力其实非常强。

有时候我们会提前拿到新模型的测试版本，试用之后如果发现它在某些方面表现特别出色，团队成员往往会主动利用周末时间加班，争取在新模型正式发布前就完成相关功能的开发。很多重要功能其实几天之内就能搭建完成。

Harrison Chase：说到模型，你们发布了自研的 Composer 模型。开发这个模型的初衷是什么？目前用户的使用情况如何？这个模型有没有改变大家使用 Cursor 的习惯？

Jason Ginsberg：我们发现，工程师使用我们产品时的编码场景，需要有专门适配的模型来支撑。Composer 模型就是针对这类场景打造的，它定位非常明确，具备速度快、质量高、逻辑智能三大特点，尤其适合 “人机实时协作” 场景。我自己做前端开发时就经常用它，因为我需要频繁做出细微的交互设计决策，这就要求 Agent 能在几秒内给出反馈。Composer 就像一个高效的协作伙伴，能快速响应需求、碰撞想法，和那些适用于长周期异步任务的模型形成了很好的互补。

Harrison Chase：Cursor 的 Agent 相关研发工作是全员参与，还是有专门的团队负责？

Jason Ginsberg：我们确实有专门的团队负责 Agent 的性能优化，他们主要聚焦于工具链、调度框架的搭建以及效果评估。但正如我之前所说，我们的团队架构并不僵化，没有严格限制大家的工作范围。比如核心产品团队的工程师在开发规划模式时，如果需要对Agent进行调整，就会和Agent团队密切协作。而且在开发过程中，我们依然会深度使用自家产品进行测试，团队成员会分享使用感受，以此来评估功能的实际效果。

Harrison Chase：无论是 Agent 团队的成员，还是其他团队中擅长 Agent 研发的工程师，他们身上有没有什么共同特质？他们的专业背景或者个人能力有没有什么特别之处？

Jason Ginsberg：我觉得他们大多是偏产品方向的人才，而不是传统意义上的机器学习或算法研究专家。这些人经常在不同团队之间轮岗，因为Agent研发需要对用户的最终使用体验有很强的直觉，同时还要能准确解读团队的反馈意见。

Harrison Chase：上周你们和 OpenAI 合作发布了一篇博客，内容是针对 OpenAI 的新模型优化 Cursor 的 Agent 调度框架。我在推特上经常看到大家讨论 “Agent 调度框架” 这个概念。你们是如何看待模型的底层支撑架构的？这类架构是否需要和特定模型深度绑定？比如 Composer 模型和 CodeLlama 模型，对应的架构会不会有很大差异？

Jason Ginsberg：我其实没有深度参与这方面的工作，但据我了解，我们的核心目标是打造高度灵活的架构。毕竟我们需要不断尝试新技术、新功能模式，所以架构必须能够随着模型能力的升级快速适配。

Harrison Chase：很有道理。毕竟整个行业都在飞速变化。

开放问答

提问者 1：刚才提到了新增的可视化浏览器功能，我发现有些工具比如 Lovable 也有类似的功能。请问这个功能是朝着 “沉浸式可视化编码” 的方向发展吗？

Jason Ginsberg：我觉得它并不是为沉浸式可视化编码设计的。就像我之前说的，这个功能最初是我为自己开发的，我本身就是一名做产品的工程师，它的核心用户群体其实是专业工程师和设计师。大家在开发应用时，肯定都遇到过这种情况：精心设计的界面，最后却变成了大家都看腻了的紫黄渐变配色。这个功能就是为了让大家能够精准把控细节，比如把内边距调整到精确的像素值。它为用户提供了一套更直观的 “视觉化操作语言”，比纯文本指令的精度更高。

而且就算不使用侧边栏，你也可以直接点击页面元素，随时输入提示词下达指令。借助这个功能，你可以在几秒内同时启动六个 Agent。如果开启热重载功能，你的网站会实时呈现修改效果，用起来其实还挺有意思的。

提问者 2：我特别喜欢你们的浏览器 Agent，一直在用。但我发现一个小瑕疵：我想持续迭代优化设计方案，可 Agent 总是会中断我的工作，直接提交代码合并请求。未来有没有可能实现不间断的持续迭代？

Jason Ginsberg：当然可以。未来的发展方向就是让 Agent 具备自主评估能力，根据需求长时间持续运行、循环迭代。现在的调试模式还需要人工点击按钮来确认日志信息，但这只是过渡方案。理想的状态是，Agent能够自主完成评估、迭代，直到彻底解决问题。

提问者 3：我不知道你是否深度参与 Agent 相关的研发工作，但我注意到 Cursor 的内存管理功能做得很好。它可以根据工程师个人、部门乃至整个公司的偏好、规则和流程，自主管理相关信息。我们都知道，信息和上下文对 Agent 来说至关重要。请问你们有没有计划进一步拓展和升级这个功能？尤其是在长上下文处理方面，你们有什么思路？

Jason Ginsberg：我们正在进行大量的实验和探索。目前已经落地了规则管理、内存记忆、技能库等多个功能模块。现阶段，我们主要在研究高效的信息摘要技术。另外，借助我们的自研模型，我们也在探索让模型自主识别对话或代码中反复出现的关键信息。当然，跨组织的信息共享功能也很值得探索。不过这里有个需要注意的点，相关规则和信息可能会随着模型的迭代而过时。所以我们必须确保用户能够轻松更新这些内容，避免被过时的规则束缚。

提问者 4：关于你们发布的 Composer 模型，我认识一些开发者，他们基于 Gemini 模型微调了一个医疗领域的专用模型。但他们发现，这个微调后的模型效果还不如直接用原生 Gemini 模型做单次提示词调用。他们分析的原因是，微调模型需要持续维护，要跟上 Gemini 等基础模型的更新节奏。请问你们是如何制定策略，确保 Composer 模型不会落伍的？

Jason Ginsberg：你说的是 Composer 模型，对吧？我们会持续对它进行迭代优化，它并不是一个静态的模型。我们的核心关注点，是在速度和智能之间找到最佳平衡点，满足 Cursor 用户在大部分场景下的需求。不过在长上下文处理这类特定领域，我们确实还有提升空间。

提问者 5：我自己是产品经理，一直在用 Cursor 做原型开发，甚至在团队里还客串设计师，用它替代 Figma。我很好奇，有没有用户是在使用 Cursor 之前，从未安装过任何集成开发环境（IDE）的？这类用户会不会成为你们未来重点关注的群体？毕竟现在的编码 Agent 已经足够强大，很多工作都能在上面完成。

Jason Ginsberg：坦白说，我们目前并没有把这类用户作为核心关注点。当然，我们认同工具的使用门槛确实需要不断降低，而且 Cursor 的易用性也在持续提升，比如新增的浏览器工具对设计师就很友好。但我们的核心目标，其实是赋能顶尖工程师。我们一直在思考：如何让世界上最优秀的工程师变得更加强大？在这个过程中，我们开发的工具自然会惠及更多人群。不过在产品优化方面，我们确实还有很多工作要做，如优化新手引导和环境配置流程。毕竟设计师和产品经理在配置 GitHub 等工具时，经常会遇到困难。我们希望通过优化这些环节，吸引更多用户尝试 Cursor。

提问者 6：我一直在尝试用 Cursor 做智能合约的验证矩阵构建和试运行逻辑测试。请问在深度质量检测和安全加固方面，有没有什么不太为人知的实用工作流可以推荐？或者刚才提到的调试工具能不能派上用场？我对智能合约的质量检测特别感兴趣。

Jason Ginsberg：说实话，我们正在尝试让 Agent 自主完成测试工作，不过这项功能目前还没有完全发布。对于从事质量检测工作的人员来说，我强烈推荐试试我们刚发布的调试模式。这个功能定位问题的逻辑非常清晰，几乎可以说是确定性的，用起来会很有帮助。

提问者 7：您认为未来两到四个月，Cursor 面临的最大机遇是什么？会不会是语音 Agent？

Jason Ginsberg：我觉得机遇不在于语音 Agent。用户现阶段最核心的需求，其实是让 Agent 变得更智能、运行时间更长、能处理的任务更多。现在的很多 Agent，本质上只是在 “读取代码”，并不能真正判断修改后的代码是否有效。未来的发展空间非常大，我们可以投入更多算力，让 Agent 承担更多人类目前负责的校验工作。我觉得未来三到六个月，整个行业都会迎来巨大的变革，非常值得期待。

参考链接：

https://www.youtube.com/watch?v=dKSGK-fPFyU

整理 | 华卫、Tina

过去一年，编码 Agent 的变化速度，已经快到让人很难用“功能升级”来形容。

如果把时间拨回到一年前，Agent 还主要停留在代码补全、对话式改几行代码的阶段；而今天，在 Cursor 内部，工程师已经开始同时运行多个 Agent 并行“甩活儿”，让它们在代码库中自主修改、调试、复盘，再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作，而是开始习惯“等它跑完再看答案”。

在最近一次访谈中，Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断：这不是渐进式优化，而是一场正在发生的“换代”。更重要的是，他把这场变化的时间窗口，压缩到了未来三到六个月——在他看来，Agent 将不只是“更聪明”，而是会真正接管更长周期、更复杂的工程任务，整个行业的工作方式也将随之重塑。

下面是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。

一年多时间，编码 Agent“翻天覆地”

Harrison Chase：Jason，你能跟大家简单介绍一下自己吗？也给大家讲讲 Cursor 是什么吧。

Jason Ginsberg：好的。我目前在做一款 AI 编程工具，已经在 Cursor 工作了六个月，担任该产品的工程负责人。不过说实话，我日常的大部分时间还是在写代码和做设计工作。在加入 Cursor 之前，我在 Notion 负责 Notion Mail 相关工作。几年前，我创办了一家名为 Skiff 的公司，后来这家公司被 Notion 收购了。所以，我一直都在从事产品开发相关的工作，而且主要聚焦在生产力工具领域。

Harrison Chase：非常棒。我有很多话题想和你探讨。要不我先抛砖引玉，问问你对编码 Agent 的发展历程，以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一，我认为编码 Agent 的发展经历了几个阶段的转变：从最初的代码自动补全，到集成在集成开发环境（IDE）中的对话式交互，再到如今出现的各类终端工具，以及基于云端的异步 Agent。我很想听听你的看法，你觉得这样概括其用户体验的演变历程是否准确？或者你们团队是如何看待这一发展过程的？

Jason Ginsberg：我认为编码 Agent 的发展确实可以用 “翻天覆地” 来形容，而且这些变革基本上都是在一年多一点的时间里发生的。正如你所说，Cursor 最早开启了代码自动补全的先河，这种模式主要是在逐行的层面上提供辅助，适用范围也基本局限在单个文件内。而此后，几乎每隔几个月，我们就不得不提升产品的抽象层级，这其实是一个极具挑战性的产品设计难题。显然，Agent 的出现让开发者能够在多个文件之间灵活切换，并且可以放心地让 Agent 自主完成代码修改工作。

在过去两个月左右的时间里，我发现行业又出现了新的转变：开发者现在已经能够做到从项目启动到结束全程信任 Agent，并且会对整个代码库中多个文件的内容进行批量审核。因此，我们不得不对产品的整体布局进行大幅重新设计，将核心从逐行的代码差异对比，转向更偏向代码审查的模式。

展望未来的产品开发方向，我们的工作重心其实会更多地放在多 Agent 协同运行上。我们需要实现的是，能够快速验证这些 Agent 是否在正常运行，并且可以让它们并行工作，同时避免受到当前单一对话模式下各种选项和选择的束缚。

Harrison Chase：推动这些变革的核心因素是什么？仅仅是因为大模型的性能变得越来越好，还是有其他更多的影响因素？

Jason Ginsberg：我认为大模型性能的提升是一个很关键的因素，这让开发者能够更加信任 Agent 编写的代码质量。要知道，以前大家必须对 Agent 生成的代码进行非常全面细致的审查。

同时，现在也有了更完善的代码审查工具。比如我们有 BugBot，市场上其实还有很多类似的工具，它们都能够自动检查代码中存在的问题。

此外，我觉得从行业文化层面来看，开发者们对 Agent 工具的接受度和使用信心也在不断增强，甚至可以说已经 “上瘾” 于这类工具带来的便捷。而且，一旦习惯了完全依赖 Agent 进行编码的工作模式，再切换回传统的编码方式其实是很困难的。所以现在，我们能看到越来越多的开发者已经将 Agent 辅助编程作为默认的工作方式。

最顶尖工程师的干活秘诀：全靠 Agent？

Harrison Chase：你观察到大家使用 Cursor 的方式都有哪些不同？或者你自己平时是怎么使用 Cursor 的？

Jason Ginsberg：其实在我们公司内部，工程师们使用 Cursor 的方式就五花八门。甚至团队里有几位工程师，他们完全不使用 Cursor 的 Agent 功能，比如负责安全和基础设施的同事。所以，确实有一部分用户非常依赖代码自动补全功能，日常使用中大部分操作都是基于补全功能完成的。但令人意外的是，我发现团队里一些最顶尖的工程师，我们称他们为 “核心用户”，他们做任何工作都会完全依赖 Agent，甚至会同时运行多个 Agent 并行处理任务。

至于我个人的使用习惯，我并不会去设计那些复杂繁琐的提示词，也没有什么所谓的 “Agent 使用秘籍”。我写的提示词往往都很简短，甚至还会带有拼写错误。我会针对手头不同的工作任务，或者同一个问题的不同模块，同时启动多个 Agent，然后等待它们返回结果。

目前我用得最多的是我们今天刚刚发布的一个新功能：调试模式。这个模式下，Agent 能够通过生成日志来进行自我评估，之后开发者复现相关操作步骤，Agent 就会通过查看日志判断问题是否得到解决。这个功能非常实用，因为它相当于通过投入算力去不断尝试解决问题，最终攻克那些手动排查起来极为棘手的难题。

Harrison Chase：调试模式具体是什么样的？为什么需要专门设置这样一个模式？难道不能自动完成调试吗？直接给 Agent 下达调试指令不也可以吗？

Jason Ginsberg：其实我也认同你的这个想法。所以在开发调试模式的时候，我们内部确实有过不少争论。主要原因在于，Cursor 目前已经有很多功能模式了，如规划模式、询问模式等等，这些模式其实不太容易被用户发现。我们一直认为，这些模式都很实用，理想的状态应该是，Agent 能够根据用户的操作场景，自动匹配并启用最合适的模式，无需用户手动切换。

而现阶段调试模式之所以需要手动开启，是因为它的交互方式比较特殊。在运行过程中，Agent 会暂停当前的工作，向用户提问以获取反馈。如果用户不熟悉这种交互逻辑，可能会觉得比较困扰。

Harrison Chase：Agent 具体会询问哪些问题，又需要用户提供什么样的反馈呢？

Jason Ginsberg：我举个例子吧。假设我正在开发一个前端应用，遇到了一个很让人头疼的问题：菜单总是在左上角弹出。这时候我会对Agent说：“这个菜单需要锚定到按钮的位置。” 随后，Agent 会启动服务器，并在整个代码库中添加大量日志，同时提出一系列可能导致该问题的假设，如 “可能是某个定位参数设置错误”、“可能是事件绑定逻辑有问题” 等。之后，Agent 会提示我：“麻烦你点击这个按钮，打开菜单，看看问题是否解决。” 如果我反馈问题依然存在，Agent 就会查看生成的日志，然后分析判断：“这个假设成立，那两个假设不成立”。通常这样反复两三次之后，Agent 往往就能找出并解决问题。

Harrison Chase：你觉得人类还需要手动操作多久？就不能让 Agent 自主完成点击、测试这类操作吗？

Jason Ginsberg：一两个月内，毕竟这个行业的发展速度实在太快了。

Harrison Chase：刚才你提到了 Agent 的多种不同模式，比如规划模式、解释模式、调试模式等等。这些模式在实际应用中到底意味着什么？难道只是为 Agent 设置不同的提示词这么简单吗？还是说背后有更复杂的逻辑？

Jason Ginsberg：很多时候，确实就是修改一下系统层面的提示词。不过在某些情况下，我们也需要对用户界面进行相应的调整。比如规划模式现在也加入了交互提问功能，运行过程中会主动打断用户操作，寻求反馈。用户有时也可以自行设置参数，如调整 Agent 打断的频率等。再比如询问模式，它不只是依赖特定的系统提示词，还会限制 Agent 调用某些与文件编辑相关的工具，以此来保证功能的稳定性和可靠性。

Harrison Chase：回到之前的话题，关于大家使用 Cursor 的不同方式，你觉得未来使用编码 Agent 或者说 Cursor，存在所谓的 “最佳方式” 吗？

Jason Ginsberg：我觉得并没有什么 “最佳方式”，具体的使用方法很大程度上取决于工程师的个人工作习惯以及他们所处理的具体工作内容。目前行业里，既有异步运行Agent的应用场景，也有开发者深度参与、实时交互的模式，就像一边编程、一边像画画一样实时调整代码或者进行可视化的编辑操作。不过我经常在推特上看到一些所谓的 “Agent 使用技巧”，其实对此我是有点持保留态度的。很多人会说 “这才是使用 Agent 的最佳方式”，但在我看来，这些技巧往往是凭空杜撰的。

我们团队内部其实并不会使用那些冗长复杂的提示词，也不会采用多阶段规划的策略。大多数时候，我们都是快速迭代，如果 Agent 运行的结果不理想，就直接终止进程，重新启动 Agent。通常这种方式的效率是最高的。

自然 “唠嗑”是 Cursor 最终交互模式？

Harrison Chase：如果让你预测一下一年后的情况，你认为开发者在 IDE、终端以及其他形态的载体上使用 Cursor 的时间占比会是怎样的？

Jason Ginsberg：当然，我肯定会带有一定的主观偏向性。但我认为，终端工具并不会成为用户的首选。我觉得，真正驱动行业发展的是用户对Agent的信任度不断提升，他们更希望等到Agent完成所有工作后再查看最终的修改结果，然后决定是否采纳，同时也愿意让 Agent 运行更长的时间，以实现更智能的处理。

而 IDE 之所以至关重要，是因为它是为整个软件开发周期量身打造的工具。从项目的构思规划，到运行代码修改、查看代码内容、清晰对比代码差异、提交代码合并请求，再到在浏览器中预览效果所有这些环节，都可以无缝集成在 IDE 的模块化功能之中。这一点其实很容易被忽视，毕竟 IDE 的这些功能是经过了数十年的发展才逐步完善起来的。

我认为，当前行业的一个明显趋势是，产品层面的设计变得越来越重要。现在 Cursor 用户使用频率最高的功能，如规划模式，其实都需要可视化编辑器的支持，用户需要能够在编辑器中添加注释，并进行实时交互。一旦脱离了按钮、弹窗和菜单这些可视化交互元素，用户与工具的交互难度会大大增加。

不过，我觉得未来并非所有操作都必须局限在笔记本电脑的 IDE 中完成。这种模式并不会被完全取代，具体的使用场景会根据实际需求灵活变化，适用的场景也会更加广泛。用户在更多场景下，都能够使用到 Cursor 这样的工具。

Harrison Chase：未来会有更多场景都能用上像 Cursor 这样的工具。你们应该有对应的官网吧？用户可以直接在网页上进行交互操作，是这个思路吗？

Jason Ginsberg：对，我们确实有官网。这么做的原因是用户可以通过手机等设备随时随地访问。我觉得在不远的将来，用户完全可以戴着 AirPods，开启语音模式，和Agent实时沟通、碰撞想法，让Agent不断优化方案。等用户到了办公室，打开笔记本电脑，就已经有一堆代码修改记录或者演示视频等着审核了，到时候只需要简单确认通过或者驳回就行。如果某些细节还需要微调，再把项目下载到本地修改就好。

Harrison Chase：我认为 Cursor 真正的优势，在于围绕 Agent 交互打造的整套设计和用户体验体系。你之前在 Notion 工作过，我记得即便是在生成式 AI 普及之前，Notion 的设计和用户体验就已经广受认可了。当然，他们在生成式 AI 时代也很好地完成了转型。从一家在生成式 AI 普及前就拥有出色设计积淀且顺利完成转型的公司，再到如今专注 Agent 相关工作，你觉得 Agent 的出现给产品设计和用户体验带来了哪些变化？现在的工作模式和之前有相似之处吗？

Jason Ginsberg：我觉得总体来说，我们产品的大部分设计其实并不是 AI 专属的。要知道，产品可用的交互组件和用户体验模式就那么多，市面上的应用本质上也都是基于一些传统的模式搭建的，如收件箱、仪表盘、聊天界面，这些都是很成熟的设计。所以我们的工作核心，更多是把这些现有的设计模式进行合理组合，然后在产品中恰当地呈现出来。这一点和 Notion 的产品理念是相通的，同时也是 Cursor 和集成开发环境（IDE）的核心特质：极高的模块化程度。

作为用户，你会发现每个人的 IDE 界面布局都可以千差万别。你可以自定义面板布局，把任意组件拖放到任意位置，和坐在你旁边的同事设置出完全不同的界面。我认为这种模块化设计对产品的适应性至关重要，毕竟如我之前所说，Agent 的能力发展日新月异，用户对产品的需求和期待几乎每隔几周就会发生变化。几个月前我们推出 Cursor 2.0 的时候，并没有把原来的产品推倒重来，只是把各个功能模块重新组合，调整为侧边栏收件箱式的管理布局，同时优化了聊天界面的信息密度而已。

Harrison Chase：听你这么说，很多组件的底层逻辑其实是相通的。那有没有出现新的组件？或者某些组件的优先级发生了变化？毕竟这些组件最初都是为 “人类与软件交互”“人类通过软件协作” 的场景设计的，现在加入了 Agent 这个新角色。这其中有没有产生什么新的变化？还是说其实本质上没有太大不同？

Jason Ginsberg：我认为底层的设计逻辑和核心要素其实没有变，关键变化在于谁在主导界面交互。而在这个核心框架下，其实可以演变出无数种交互形式。就拿交互的抽象层级来说，一年前大家使用Agent的时候，都恨不得盯着它的每一步操作，全程 “盯梢”。但现在 Agent 的操作步骤变得无比繁杂，用户根本看不过来。所以我们需要优化信息呈现方式：如何对操作步骤进行分组？如何提炼关键信息？

当用户足够信任 Agent 的操作后，我们就需要把重点放在文件的实际修改内容上，并且为这些修改添加更详细的注释说明。当然，我们也可以进一步提升交互的灵活度，比如聊天对象不再局限于单个 Agent，而是可以同时和多个 Agent 对话。这就需要一套更智能的后台交互逻辑来支撑 ，系统要能识别用户在和哪个子 Agent 对话，并且协调这些 Agent 完成对应的修改。未来这种交互的抽象层级还会不断提升。

Harrison Chase：你觉得交互的抽象层级最高能达到什么程度？我知道预测未来很难，但还是想听听你的看法。

Jason Ginsberg：我觉得未来，我们现在看到的各种操作选项，如选择模型、选择功能模式、选择运行环境这些都会逐渐消失。最终的交互模式会变得像和真人对话一样自然。但这并不意味着任何人都能随便写代码，在那个阶段，这个工具依然是为专业工程师服务的。因为你还是需要具备专业的行业术语知识，清楚自己想要修改的内容是什么。做产品的人，要明确自己想要的工作流程和功能需求；做基础设施的人，要足够了解代码库，知道什么样的架构和系统设计最适合当前要开发的项目。

而且我想强调的是，随着抽象层级的提升，我们并不会摒弃现有的功能。用户依然可以随时深入底层，查看细节、调整参数。只是产品的默认交互方式会不断优化升级。

Cursor 内部工作揭秘：少审代码、高频反馈

Harrison Chase：你之前提到了人类在 Agent 工作流程中的角色，比如查看代码差异、进行代码审查。你觉得 AI 会给代码审查工作带来哪些改变？

Jason Ginsberg：首先，就我们产品团队的工作模式来说，现在人工审查的比重已经大幅降低了。我们有一个叫 BugBot 的工具，它会自动检测代码问题，并且自主完成修复，还会在持续集成（CI）流程中不断迭代优化。这个工具的表现非常出色，也让我们对 AI 审查的代码质量更有信心。

其次是信息的语义化分组。用户查看代码差异时，可以清晰地看到 Agent 做了哪些修改。我们甚至可以展示 Agent 的原始指令，更理想的状态是，Agent 能够像人类一样，在处理大型代码合并请求时，为每一处修改附上注释，说明这么做的原因。我觉得这虽然算不上颠覆性的变革，但确实能给代码审查工作带来显著的优化。

Harrison Chase：出于好奇，我想问一下，Cursor 的工程师用 Cursor 写代码，用 BugBot 审查代码，那他们还需要和其他工程师沟通协作吗？

Jason Ginsberg：哈哈，这个问题很有意思。如果你以工程师的身份加入 Cursor，会立刻发现一个现象：所有人都在深度使用自家产品。我记得我入职第一周的时候，修改了一个快捷键设置。那个快捷键是 Alt+Shift+Command+J，非常冷门，我当时觉得选这个键肯定没人会注意到。结果刚改完不到半分钟，就有三个同事在 Slack 上发来消息：“你改的这个快捷键直接打乱了我的工作流程！到底怎么回事？”几乎任何产品改动，都会立刻收到同事们的强烈反馈。我觉得这其实是一件好事，大家就是在这种高频的反馈和交流中，快速推进产品迭代的。

Harrison Chase：从组织管理的角度，你们有没有采取什么措施来鼓励或者引导这种高频反馈的协作模式？毕竟大量的反馈涌进来，有时候也会让人应接不暇。

Jason Ginsberg：在我创办自己的公司之前，工程师们也会用邮件沟通，但用得并不多。大家甚至会说：“邮件只用来收垃圾邮件和购物通知，可别用它来发长篇大论的工作内容。”而在Agent这个赛道工作，其实完全不需要依赖邮件这种低效的沟通方式。我们团队的所有人都全身心投入工作，毕竟这是一个竞争非常激烈的领域，大家都对产品开发充满热情，会自然而然地用各种即时沟通工具协作。

另外，我在规划产品功能时，会遵循一个核心原则：我能开发什么功能，让自己的日常工作更轻松？ 具体来说，就是思考 “做什么能帮我明天更高效地完成工作，不用再处理那些烦人的报错和问题”。这个原则指导着我们的大部分工作。毕竟这种功能开发出来之后，我们自己能立刻受益，比如修复了一个烦人的漏洞，以后上班就不用再被这个问题困扰了。

迭代狂飙背后，核心功能竟来自员工 “自嗨”？

Harrison Chase：你觉得你们的产品路线图，有多大比例是由 “让自己工作更轻松” 这个需求驱动的？又有多大比例是来自外部用户的需求？这个比例随着公司发展有变化吗？

Jason Ginsberg：这个比例确实随着公司规模的扩大在变化。现在我们也会制定月度的产品路线图和目标，但说实话，我们很多核心功能都来自自下而上的创新。比如 Cursor 的Agent功能，这可以说是大家提到 Cursor 时最先想到的核心功能。这个功能是我们团队的一个人开发的，最开始所有人都不看好这个想法，但他很快做出了原型。大家试用之后都惊叹：“哇，这东西居然真的能用！”

我之前提到的调试模式也是如此。感恩节假期的时候我闲着没事，就开发了这个自己很需要的功能，现在这个功能也即将上线。这些功能的开发初衷，都是为了解决团队内部的需求。我们判断一个功能是否具备发布条件，一个重要的衡量标准就是内部的使用率和认可度。

Harrison Chase：你们的产品迭代速度快得惊人，是怎么保持这种高效的开发节奏的？

Jason Ginsberg：说实话，我们的工作流程其实非常精简，没有太多繁琐的制度。公司里虽然有几间会议室，也有一两位产品经理，但我们很少通过撰写文档或者开对齐会议来推进工作，大部分的讨论和决策都是在代码层面完成的。而这一切能够实现的核心原因，是我们对人才的极高要求。今年年初的时候，公司总共也就 20 人左右。之所以团队规模增长缓慢，就是因为我们的招聘门槛高到近乎苛刻。我们会反复评估：这个人很优秀，但他能成为团队里最顶尖的那批人吗？

正因为团队里的每个人都足够出色，所以我们可以放心地把任务交给任何一个人。团队成员的主观能动性都极强，从提出想法、设计用户体验，到在推特上回复用户的支持请求、和企业客户沟通需求，再到最终将功能落地，整个流程都能独立完成。所以说，我们能保持这样的速度，归根结底还是人的因素。

Harrison Chase：你们是如何规划产品路线图的？你刚才提到了以月为单位的规划周期，这是目前的常规规划时长吗？有没有更长期的规划？另外，行业技术迭代的速度实在太快了，你们是如何平衡 “跟进现有技术浪潮” 和 “实现技术跨越式发展” 这两者的？会不会主动预判技术趋势，提前布局未来方向？

Jason Ginsberg：我们确实会投入不少精力去思考未来，比如预判未来三个月可能实现的技术突破，然后主动押注相关方向，团队里有相当一部分人都在做这类前瞻性的工作。我们制定的月度路线图更多是围绕核心产品功能展开，聚焦于用户的实际需求以及那些能优化日常使用体验的功能。而那些需要投入两个月时间重构底层逻辑的重大项目，则会纳入更长期的规划范畴。

此外，我们的应变能力其实非常强。

有时候我们会提前拿到新模型的测试版本，试用之后如果发现它在某些方面表现特别出色，团队成员往往会主动利用周末时间加班，争取在新模型正式发布前就完成相关功能的开发。很多重要功能其实几天之内就能搭建完成。

Harrison Chase：说到模型，你们发布了自研的 Composer 模型。开发这个模型的初衷是什么？目前用户的使用情况如何？这个模型有没有改变大家使用 Cursor 的习惯？

Jason Ginsberg：我们发现，工程师使用我们产品时的编码场景，需要有专门适配的模型来支撑。Composer 模型就是针对这类场景打造的，它定位非常明确，具备速度快、质量高、逻辑智能三大特点，尤其适合 “人机实时协作” 场景。我自己做前端开发时就经常用它，因为我需要频繁做出细微的交互设计决策，这就要求 Agent 能在几秒内给出反馈。Composer 就像一个高效的协作伙伴，能快速响应需求、碰撞想法，和那些适用于长周期异步任务的模型形成了很好的互补。

Harrison Chase：Cursor 的 Agent 相关研发工作是全员参与，还是有专门的团队负责？

Jason Ginsberg：我们确实有专门的团队负责 Agent 的性能优化，他们主要聚焦于工具链、调度框架的搭建以及效果评估。但正如我之前所说，我们的团队架构并不僵化，没有严格限制大家的工作范围。比如核心产品团队的工程师在开发规划模式时，如果需要对Agent进行调整，就会和Agent团队密切协作。而且在开发过程中，我们依然会深度使用自家产品进行测试，团队成员会分享使用感受，以此来评估功能的实际效果。

Harrison Chase：无论是 Agent 团队的成员，还是其他团队中擅长 Agent 研发的工程师，他们身上有没有什么共同特质？他们的专业背景或者个人能力有没有什么特别之处？

Jason Ginsberg：我觉得他们大多是偏产品方向的人才，而不是传统意义上的机器学习或算法研究专家。这些人经常在不同团队之间轮岗，因为Agent研发需要对用户的最终使用体验有很强的直觉，同时还要能准确解读团队的反馈意见。

Harrison Chase：上周你们和 OpenAI 合作发布了一篇博客，内容是针对 OpenAI 的新模型优化 Cursor 的 Agent 调度框架。我在推特上经常看到大家讨论 “Agent 调度框架” 这个概念。你们是如何看待模型的底层支撑架构的？这类架构是否需要和特定模型深度绑定？比如 Composer 模型和 CodeLlama 模型，对应的架构会不会有很大差异？

Jason Ginsberg：我其实没有深度参与这方面的工作，但据我了解，我们的核心目标是打造高度灵活的架构。毕竟我们需要不断尝试新技术、新功能模式，所以架构必须能够随着模型能力的升级快速适配。

Harrison Chase：很有道理。毕竟整个行业都在飞速变化。

开放问答

提问者 1：刚才提到了新增的可视化浏览器功能，我发现有些工具比如 Lovable 也有类似的功能。请问这个功能是朝着 “沉浸式可视化编码” 的方向发展吗？

Jason Ginsberg：我觉得它并不是为沉浸式可视化编码设计的。就像我之前说的，这个功能最初是我为自己开发的，我本身就是一名做产品的工程师，它的核心用户群体其实是专业工程师和设计师。大家在开发应用时，肯定都遇到过这种情况：精心设计的界面，最后却变成了大家都看腻了的紫黄渐变配色。这个功能就是为了让大家能够精准把控细节，比如把内边距调整到精确的像素值。它为用户提供了一套更直观的 “视觉化操作语言”，比纯文本指令的精度更高。

而且就算不使用侧边栏，你也可以直接点击页面元素，随时输入提示词下达指令。借助这个功能，你可以在几秒内同时启动六个 Agent。如果开启热重载功能，你的网站会实时呈现修改效果，用起来其实还挺有意思的。

提问者 2：我特别喜欢你们的浏览器 Agent，一直在用。但我发现一个小瑕疵：我想持续迭代优化设计方案，可 Agent 总是会中断我的工作，直接提交代码合并请求。未来有没有可能实现不间断的持续迭代？

Jason Ginsberg：当然可以。未来的发展方向就是让 Agent 具备自主评估能力，根据需求长时间持续运行、循环迭代。现在的调试模式还需要人工点击按钮来确认日志信息，但这只是过渡方案。理想的状态是，Agent能够自主完成评估、迭代，直到彻底解决问题。

提问者 3：我不知道你是否深度参与 Agent 相关的研发工作，但我注意到 Cursor 的内存管理功能做得很好。它可以根据工程师个人、部门乃至整个公司的偏好、规则和流程，自主管理相关信息。我们都知道，信息和上下文对 Agent 来说至关重要。请问你们有没有计划进一步拓展和升级这个功能？尤其是在长上下文处理方面，你们有什么思路？

Jason Ginsberg：我们正在进行大量的实验和探索。目前已经落地了规则管理、内存记忆、技能库等多个功能模块。现阶段，我们主要在研究高效的信息摘要技术。另外，借助我们的自研模型，我们也在探索让模型自主识别对话或代码中反复出现的关键信息。当然，跨组织的信息共享功能也很值得探索。不过这里有个需要注意的点，相关规则和信息可能会随着模型的迭代而过时。所以我们必须确保用户能够轻松更新这些内容，避免被过时的规则束缚。

提问者 4：关于你们发布的 Composer 模型，我认识一些开发者，他们基于 Gemini 模型微调了一个医疗领域的专用模型。但他们发现，这个微调后的模型效果还不如直接用原生 Gemini 模型做单次提示词调用。他们分析的原因是，微调模型需要持续维护，要跟上 Gemini 等基础模型的更新节奏。请问你们是如何制定策略，确保 Composer 模型不会落伍的？

Jason Ginsberg：你说的是 Composer 模型，对吧？我们会持续对它进行迭代优化，它并不是一个静态的模型。我们的核心关注点，是在速度和智能之间找到最佳平衡点，满足 Cursor 用户在大部分场景下的需求。不过在长上下文处理这类特定领域，我们确实还有提升空间。

提问者 5：我自己是产品经理，一直在用 Cursor 做原型开发，甚至在团队里还客串设计师，用它替代 Figma。我很好奇，有没有用户是在使用 Cursor 之前，从未安装过任何集成开发环境（IDE）的？这类用户会不会成为你们未来重点关注的群体？毕竟现在的编码 Agent 已经足够强大，很多工作都能在上面完成。

Jason Ginsberg：坦白说，我们目前并没有把这类用户作为核心关注点。当然，我们认同工具的使用门槛确实需要不断降低，而且 Cursor 的易用性也在持续提升，比如新增的浏览器工具对设计师就很友好。但我们的核心目标，其实是赋能顶尖工程师。我们一直在思考：如何让世界上最优秀的工程师变得更加强大？在这个过程中，我们开发的工具自然会惠及更多人群。不过在产品优化方面，我们确实还有很多工作要做，如优化新手引导和环境配置流程。毕竟设计师和产品经理在配置 GitHub 等工具时，经常会遇到困难。我们希望通过优化这些环节，吸引更多用户尝试 Cursor。

提问者 6：我一直在尝试用 Cursor 做智能合约的验证矩阵构建和试运行逻辑测试。请问在深度质量检测和安全加固方面，有没有什么不太为人知的实用工作流可以推荐？或者刚才提到的调试工具能不能派上用场？我对智能合约的质量检测特别感兴趣。

Jason Ginsberg：说实话，我们正在尝试让 Agent 自主完成测试工作，不过这项功能目前还没有完全发布。对于从事质量检测工作的人员来说，我强烈推荐试试我们刚发布的调试模式。这个功能定位问题的逻辑非常清晰，几乎可以说是确定性的，用起来会很有帮助。

提问者 7：您认为未来两到四个月，Cursor 面临的最大机遇是什么？会不会是语音 Agent？

Jason Ginsberg：我觉得机遇不在于语音 Agent。用户现阶段最核心的需求，其实是让 Agent 变得更智能、运行时间更长、能处理的任务更多。现在的很多 Agent，本质上只是在 “读取代码”，并不能真正判断修改后的代码是否有效。未来的发展空间非常大，我们可以投入更多算力，让 Agent 承担更多人类目前负责的校验工作。我觉得未来三到六个月，整个行业都会迎来巨大的变革，非常值得期待。

参考链接：

https://www.youtube.com/watch?v=dKSGK-fPFyU

第五代抽象

软件工程历史上的每一次重大转变都是由一种一致的力量驱动的：抽象的兴起。最早一代的软件是用原始机器代码编写的，后来汇编语言引入了可读性和控制层。更高级的语言已经跨越多个不同的范式发展，使得像 C、Java 和 Python 这样的通用语言及其衍生品得以发展。

这些语言使得抽象得以进步，其中像内存管理和特定平台的怪癖这样的概念在日常工作流程中被掩盖，并且由开发者代表进行处理。这种级别的可访问性允许更广泛的生态系统发展，因为随着每一代语言的出现，相应的支持工具链也在发展。 

图 1：编程语言的世代

第五代，即使用自然语言的第五代，长期以来一直是编程语言的目标演变，其中人类用他们的母语交谈，并且以可执行的方式进行解释。这种演变直到最近才真正成为主流。推动这一点的是人工智能（AI）的代际能力，现在已经成熟到可以接收以人为中心的输入，并用你选择的编程语言构建解决方案。几十年的学术研究记录了这一进化过程，博客也非正式地对此进行了讨论。

这些转变中的一个共同主题是开发人员角色的演变。每一次抽象提升都允许开发人员更多地关注意图，而不是机制，我们现在进入了另一个拐点。第五代不仅因为广泛使用生成式 AI 而加速，而且与行业主导的采用相吻合。这代表了开发者如何从根本上接近他们手艺的新纪元。

随着前几代的成熟，支持它的工具链也出现了。在前几代中，工具是在一段时期稳定后出现的；然而，随着 AI 研究和产出的快速发展，工具链现在有望塑造和定义这一代，而不仅仅是支持它。

作为这些进步的一部分，一套关键的工具出现了，集中在规范驱动开发（SDD）上。这种趋势是由 AI 辅助代码生成的接受所驱动的，它允许开发人员提升自己的抽象，并表达系统应该做什么，而智能工具则实现了它的实际完成方式。

这种转变重新定义了我们如何接近系统的架构和设计。现在，团队维护的是活的规范，而不是随着时间的推移而偏离原始意图的静态架构图。这些定义了系统契约、边界、不变量和行为。这些规范在设计上是可执行的；它们可以生成代码、文档、SDK、模拟甚至服务基础设施。AI 智能体，通过角色映射的能力来播种它们的上下文，其中角色的专业知识被捕捉为智能体的可消费输入，现在可以作为解释器、验证器和特定于领域的协作者行使权威。

在本文中，我们将 SDD 作为一种架构范例进行研究，详细说明规范如何成为系统的可执行支柱，漂移检测和持续验证如何将架构转变为运行时不变量，AI 和代理工具如何重塑生成和管理，以及这种模型如何代表软件抽象长期演变中的下一个主要拐点。

SDD 架构

规范驱动开发（SDD）这个名字可能暗示了一种方法论，类似于测试驱动开发。然而，这种框架低估了它的重要性。更准确的理解是，SDD 是一种架构模式，它通过将可执行规范提升到代码本身之上，从而颠倒了传统的事实来源。

SDD 代表了软件系统架构、治理和演变方式的根本转变。在技术层面上，它引入了一个声明性的、以契约为中心的控制平面，将规范重新定位为系统的主要可执行工件。相比之下，实现代码成为了次要的、生成的架构意图表示。

传统架构依赖于源代码作为规范的控制面。在 SDD 中，控制面向上移动到规范控制面。这个控制面正式允许我们定义诸如：

• 接口契约（功能、输入/输出、行为保证）

• 数据模式和不变量（结构、约束、验证规则）

• 事件拓扑（允许的流、排序、传播语义）

• 安全边界（身份、信任区域、策略实施）

• 兼容性规则（包括向后和向前）

• 版本控制语义（演进、降级、迁移）

• 资源和性能约束（延迟、吞吐量、成本）

这一变化涵盖了跨行为和治理的经典体系结构表面区域的组合，并具有正确性的时间维度。SDD 不是独立地在服务和存储库之间协调这些领域，而是将它们集中到一个单一的权威模型中。这种模式更接近于语言类型系统或编译器：它不执行程序本身，而是定义了什么是可表达的，拒绝什么是无效的，并限制演变以保持随时间的正确性和兼容性。架构不再是咨询性的；它现在变得可实施和可执行。

尽管越来越多的工具被冠以 SDD 的标签，但从根本上说，它不是一个产品、框架或正式语言。相反，它是一个架构构造，以惊人的一致性作为一个五层执行模型重新出现。

以我们的订单管理服务为例，在规范层中，我们声明什么必须为真，而不是如何实现它。这是一个简单订单的伪规范可能看起来像：

图 2：SDD 5 层执行模型

这些层次共同构成了一个封闭的、由规范控制的控制系统，其中意图不断塑造执行，而执行不断地验证意图。由此产生的并不是对现有架构的渐进式改进，而是权威、控制和真实性所在位置的根本倒置。

现在让我们来看看这五个层次。在整个过程中，我们将遵循一个经典的订单管理服务的简化示例，以展示各层之间的进展以及它们是如何相互加强的。

规范层

这是系统行为的权威定义。它捕获了系统的声明性意图，而不是如何实现。这一层通常包含 API 模型、消息传递契约、领域模式和特定于系统、以策略为中心的约束。从抽象的角度来看，它既是人类可读的，也是机器可执行的，同时作为设计工件和操作控制面。

以我们的订单管理服务为例，在规范层，我们声明什么必须为真，而不是如何实现它。这是一个简单订单的伪规范可能的样子：

service: Ordersapi:     POST /orders:      request:               Order:                   id: uuid                   quantity: int > 0           responses:               201: OrderAccepted               400: ValidationError  policies:     compatibility:   backward-only     security:         auth: mTLS

这个规范明确声明了我们的期望：

• 订单必须是正数

• API 不得引入破坏性变更

• 请求必须经过认证

这里没有引用任何语言、框架或基础设施。

生成层

这一层将声明性系统意图转化为可执行的形式。它作为一个多目标系统编译器，但与发出机器指令的经典编译器不同，这一层发出系统形状和跨语言、框架和平台的可执行运行时界面。在这里，问题空间由规范层声明，工具将其操作形式具体化。典型的输出包括类型模型、契约存根、验证中间件、文档以及一系列集成和一致性测试。

以我们的订单示例为例，规范被摄取并发出可执行的系统表面。从概念上讲，这看起来像：

spec.yaml   → Type models (Java, TypeScript)   → Request validators      → API stubs     → Contract tests

工具将声明的意图转化为具体的、可执行的形式。

构件层

这一层包含了生成阶段的具体输出：生成的服务、组件、客户端、数据模型和适配器。关键的是，这些工件不被视为主要资产。相反，它们是可再生的、可丢弃的、可替换的，并且可以持续协调。这颠覆了传统软件架构的一个基本假设：代码不再是系统的记录；规范是。随着代码变得无限可复制和按需生成，新出现的术语环境代码恰如其分地抓住了这种范式转变。

我们的订单的形状现在可以用生成的一次性代码实现了。这可以看到类似于类型化模型的输出：

export interface Order{   id: string;   quantity: number; }With a validator:if (order.quantity <= 0) {    throw new ValidationError("quantity must be greater than zero"); }

这些构件不是真相的来源。如果规范发生变化，它们将被重新生成。如果它们被删除，什么也不会丢失。

验证层

这一层强制执行意图和执行之间的持续一致性。它由契约测试、模式验证、有效载荷检查、向后兼容性分析和架构漂移检测机制组成。它在结构上扮演了编程语言的类型系统和管理程序对虚拟机所扮演的角色：积极防止架构违规传播到运行时。

我们的生成层创建的工件最终在这里进行管理，其中验证确保运行时不能偏离意图：

✓ Reject requests with quantity <= 0

违规行为在构建时、部署期间以及我们的持续集成系统中被检测到。架构正确性是持续强制执行的，而不是手动审查的。

运行时层

这是操作系统本身，由典型的一系列构件组成，例如：

• API

• 消息代理和流处理管道

• 函数、方法和等效结构

• 集成服务

至关重要的是，运行时的形状完全受到上游规范和验证层的约束。因此，运行时行为在架构上是确定的，而不是涌现性的。

如果我们尝试在我们的订单服务使用负数量，如下所示：

POST /orders {   "id": "123",   "quantity": -1 }

我们返回了一个 400 ValidationError，并不是因为运行时拒绝了请求，而是因为在系统执行任何请求之前，该行为在规范层中声明，由生成层具体化，由构件层实例化，并由验证层持续强制执行。

架构反转

几十年来，软件架构一直在一个基本上未受挑战的假设下运作，即代码是最终的权威。架构图、设计文档、接口契约和需求规范都是用来指导实现的。然而，运行中的系统总是从最终部署的内容中获得其真相。当出现不匹配时，标准的反应是“更新文档”。

SDD 完全颠覆了这种关系。规范成为系统现实的权威定义，实现是持续派生、验证的，并且在必要时重新生成以符合该真实性。这不是一个哲学上的区别；它是软件系统治理的结构性反转。

传统的软件交付遵循线性、有损失的管道，如图 3 所示。

图 3：传统的软件交付管道

每一步翻译都引入了重新解释、手动适应和隐藏的假设。因此，不能阻止架构漂移；它是在晚期被发现的，通常是通过生产事件、失败的集成、安全审计或合规性违规。当检测到不一致时，它是取证而不是纠正。

SDD 从根本上将这种流程重构为一个受控的控制循环：

图 4：SDD 受控的软件交付管道

这个控制循环用积极的架构强制执行取代了延迟发现。漂移检测不会修补运行时行为；它纠正规范权威，并触发系统的受控再生。传统架构假设代码随时间的推移成为事实；SDD 通过确保规范保持永久的事实来源，并且运行时持续被迫符合它，从而颠覆了这一点。

这种架构反转可以概括如下几点：

在 SDD 中，代码不再是真相出现的地方，而成为真相仅仅被实现的地方。

这种反转在结构上等同于早期的范式转变，即从人的责任中移除整个类别的正确性约束，并使其在机械上可执行：

• 从手动内存管理到垃圾收集，内存安全成为运行时不变量

• 从裸机到虚拟机，隔离和资源边界成为平台保证

• 从物理服务器到声明性基础设施，其中配置漂移和拓扑正确性不断得到协调

• 从无类型语言到静态类型系统，在编译时强制执行结构正确性

• 从非正式的接口协议到模式和契约强制执行的 API，交互正确性被机械地验证

在每种情况下，正确性都从传统上由人类强制执行转变为由平台结构性强制执行。SDD 将这一原则应用于系统边界、架构和行为本身。

漂移检测：使架构自我强制执行

一旦规范成为权威，漂移检测不再是一种测试便利；它成为一种强制性的架构能力。它是将意图转化为不变性的执行机制。在这个模型中，漂移不仅仅是模式不匹配；它是声明的系统意图和观察到的系统行为之间的任何偏差。这种偏差可能是结构性的、行为性的、语义性的、与安全相关的或进化性的。我们在实验中遇到的一些例子包括：

• 一个 API 返回了规范中未声明的字段

• 一个服务在重构过程中默默地省略了必需的字段

• 消息负载在没有协调的模式版本控制的情况下不断演变

• 错误处理偏离了合同保证

• 相对于最初的策略意图，安全范围正在退化

没有漂移检测，SDD 就会退回到文档驱动的开发。有了它，系统就变成了自我监管。漂移检测形成了一个闭环反馈控制系统。它不断地比较系统声称要做的事情和它实际做的事情。这与古典测试相比，后者只提供周期性的、基于样本的保证，是一种根本不同的操作姿态。

在传统架构中，意图的偏差会悄无声息地传播，通常数月之后才会以中断、审计失败或安全漏洞的形式显现出来。在 SDD 系统中，漂移变成了机器默认可以检测到的。规范验证器可以直接嵌入我们的 CI 管道中，运行时执行层：模式验证、有效负载检查、契约验证和规范差异引擎都成为了一等的架构组件。当输出违反规范时，系统会快速失败，并允许进行航向修正。

这种强制要求在一个固有的多模型未来中变得更加重要。软件系统将越来越多地受到人类驱动开发和机器驱动生成的影响，通常在同一规范表面上并行操作。系统中不再有单一的线性路径。更改可能来自开发者、AI 代理、自动化重构工具或政策驱动的生成器。这种进化路径的多样性极大地放大了漂移问题：分歧不再是边缘情况；它是必须持续治理的自然状态。

总体效果是治理方式的深刻转变。架构不再是设计阶段的产物；它变成了一个持续执行的运行时不变量。规范从被动的参考资料转变为主动的控制表面，漂移检测作为反馈信号，保持系统与意图一致。

然而，这并不意味着一个完全自主的系统，机器单方面定义正确性。规范不仅仅是一个机械合同；它是人类对目的、风险容忍度和权衡的表达。漂移检测可以识别系统已经偏离，但它不能单独决定这种偏离是可以接受的、偶然的还是可取的。一些漂移代表缺陷，而其他漂移代表进化。在这个边界上，当自动化执行遇到解释性判断时，人类的角色再次变得至关重要。不是作为失败后被动审查日志的审查者，而是作为治理意义、意图和受控变更的积极参与者。这就是 Human-in-the-Loop（人在循环中）不再只是一个安全网，而是一个一等的设计原则。

人在循环中：在自动化架构中保留意图

当我们最初探索这种系统设计模式时，我们以一种天真的“氛围编码”心态来接受生成的变化，最小化阻力，并信任 SDD 工具链为我们处理边缘情况。那个假设很快就失败了。取而代之的是一个更强大的认识：SDD 并没有将人类从循环中移除；它将人类判断重新定位到更高的控制层面。问题不再是人类如何实现系统，而是如何以及在哪里治理系统。

SDD 并没有消除人类在软件设计中的参与。它重新分配了人类认知的应用领域。传统上，一旦功能实现，开发人员就会花费大量的精力来解决不匹配、调试集成故障、协调分散的服务以及修复更改的意外副作用。随着时间的推移，这被错误地等同于软件工程本身的手艺。实际上，这是维护大型、长期、面向生产的系统的负担。SDD 将这个负担转移到机器上，同时故意保留人类对意图、策略和意义的权威。

这引入了一种新型的人机界面。人类仍然是领域语义、风险容忍度、安全范围和系统进化方向的最终守护者。这种权威也扩展到隐含地塑造工程决策的法律、伦理和道德框架中。这些维度不能仅从执行跟踪或行为观察中推断出来。它们存在于机器无法完全拥有的抽象层次上。

相反，人类将这些约束明确编码到规范层中，机器承担起执行、生成和持续一致性的责任。这反映了我们技术的历史演变：就像我们曾经将手动内存管理交给垃圾收集一样，我们现在正在将结构性执行和机械一致性委托给 SDD。取代这种委托的不是盲目的自动化，而是明确的审批边界：

• 破坏模式更改需要人工批准

• 策略转变需要人工授权

• AI 提出的重构需要人工确认

• 兼容性降级需要人工解释

因此，SDD 实现了有限的自主性，而不是完全自动化，并且在这些限制内，长期架构意图可以得以保留。

通过强制漂移检测和人工意图监督，SDD 在人和机器之间建立了新的责任分工。执行变得自动化。意义仍然是人类的。这种分离不是哲学上的；它是架构上的，正是这种分工产生了一类新的基础设施能力。一个的规范原生系统现在必须将执行、演化、验证和治理直接编码到其核心原语中。我们接下来探讨这些能力，以及它们为什么在结构上与经典软件架构中的能力不同。

规范原生系统的核心能力

SDD 不是由单一工具、框架或平台启用的。它源于一组紧密耦合的架构能力，这些能力共同允许规范变得可执行、可强制和可扩展。当这些能力中的任何一个缺失时，SDD 就会退回到文档驱动开发或临时代码生成。要从理论进入操作范式，系统必须内化五个核心能力：

1. 规范编写作为一等工程表面

2. 正式验证和类型强制

3. 确定性生成和组合

4. 持续的一致性和漂移执行

5. 受控演化和兼容性控制

我们将这种操作规程称为 SpecOps，即规范操作。从 SpecOps 的角度来看，规范被视为一等的、可执行的系统资产，这些能力并没有定义一个产品类别；它们代表了软件意图的控制平面。在规范原生系统中，规范编写不是在实现之前进行的活动；它就是实现活动。因此，系统必须支持多模型规范，其中结构、行为和策略定义共存于统一的模式空间内。这需要可组合的领域建模，使得分层规范成为一种可行的架构策略，而不是文档便利。

随着规范成为主要的系统构件，它们必须像源代码一样被严格地处理：版本控制、同行评审、分支和受控合并策略都要是强制性的。此时，规范不再是描述性的，而是成为系统本身的可编程模型。

一旦规范是可执行的，它还必须是机器可验证的，就像编译器前端或类型系统一样严格。这种执行涵盖了结构验证、语义一致性和领域不变性执行。条件约束、引用完整性和跨规范一致性必须是可证明的。效果不仅仅是提高了正确性，而是从可以表示的所有内容的空间中消除了整个类别的系统故障，就像静态类型限制非法程序一样。

在这个范式中，生成不是脚手架的一种形式。它是声明的系统真理的具体化。这需要严格确定性行为。一个生产级别的规范原生系统必须保证输入的确定性：相同的规范总是产生相同的构件。它必须是目标无关的，跨语言、平台和运行时环境产生一致的输出。最关键的是，生成必须是逻辑可逆的。系统必须始终能够回答一个简单但基础的问题：哪个规范状态产生了这种行为？这种决策的谱系可追溯性是将生成从生产力辅助提升到架构权威的关键。

一旦生成自动化，执行就必然变得连续。运行时系统不能再悄悄地偏离声明的意图。实现不能引入未记录的行为。消费者不能依赖于未定义的属性。因此，架构从设计时断言转变为运行时不变性，由系统本身积极维护。

SDD 中最困难的能力不是生成或验证，而是不断裂的更改。规范原生系统必须自动将更改分类为添加性、兼容性、破坏性或模糊性，并执行明确的兼容性策略。这引入了受控演化的正式概念：需要并行版本表面、已知的兼容性窗口、受控的弃用曲线和用于破坏性更改的显式批准门。没有这个，SDD 在架构上就会变得脆弱。有了它，系统可以在不违反自己的正确性保证的情况下进行演化。

这五个能力引入的最深刻的转变不是技术上的；它是结构上的。

交付的单元不再是服务或代码库。交付的单元变成了规范本身。这将结果与产出重新对齐：声明的是什么，交付的就是什么。这与以氛围驱动、生成性编码方法形成鲜明对比，在这些方法中，偏差是创造力（或幻觉）的涌现属性，而不是设计中受控的行为。

结论：存在的工程权衡和挑战

软件工程中每一次重大的抽象飞跃都带来了非凡的生产力提升，同时引入了全新的系统性风险类别。垃圾收集消除了大量内存错误，同时引入了暂停时间行为和新的故障模式。虚拟机简化了部署，同时增加了业务编排的复杂性。云平台消除了基础设施负担，同时引入了深层操作耦合。规范驱动开发也不例外。

通过将系统的真实来源提升到规范和生成器中，SDD 并没有消除复杂性；它只是简单地重新定位了复杂性。下面的权衡定义了我们在大规模采用这种范式时所经历的真实工程成本。

规范成为主要的复杂性表面

在 SDD 中，规范不再是文档构件，而是成为长期存在的可执行基础设施。因此，它们获得了传统上与源代码相关的属性。它们继承了通常与源代码相关的所有属性：技术债、跨团队耦合、兼容性惯性和架构引力。因此，模式工程成为了与数据建模和分布式系统设计同等重要的一级架构学科。

生成器信任成为供应链问题

在 SDD 中，AI 代码生成器不再是开发者的便利工具。它们成为系统可信计算基础的结构组件。确定性、可重复性、可审计性、沙箱执行和可验证的出处不再是可选属性；它们是强制性的。代码生成从工具提升为关键基础设施。

运行时执行有实际成本

SDD 将执行从社会过程转移到技术控制。这种转变是强大的，但不是免费的。运行时契约验证引入了实际的计算开销。在小规模上，这个成本是微不足道的。在大规模上，我们需要考虑系统的目的，无论是高频 API、实时流还是对延迟敏感的系统。这成为了一个明确的架构预算项目。正确性成为了计量资源，而不是默认的免费属性。

认知转变非同小可

SDD 用契约优先推理取代了实现优先的思维。这要求工程师采用新的心智模型：

• 用不变量而不是行为来思考

• 关于兼容性而不是功能的推理

• 用声明式而不是过程式表达意图

• 将模式视为可执行程序

历史上每一次抽象的转变都扩大了人类的影响力，同时引入了不熟悉的失败模式，需要多年才能掌握。SDD 现在正进入相同的成熟曲线。

架构权威的价格

虽然新的范式转变通常令人兴奋，但最终是否采用这一转变归结于平衡所涉及的实际权衡。

一方面，SDD 提供了：

• 架构确定性

• 持续的正确性执行

• 系统性减少漂移

• 多语言平价

• 可复制的系统边界

但它以以下代价：

• 模式复杂性

• 生成器信任要求

• 运行时验证成本

• 长期兼容性负担

• 工程角色的认知转变

这不是避免 SDD 的理由。这是一个有意识地采用它的理由，要有明确的治理、有纪律的规范实践，以及对其成本的清醒认识。每一次抽象的飞跃都需要新的严谨形式。

SDD 只是将这种严谨重新定位到它一直属于的地方：系统真理本身的定义。

原文链接：

https://www.infoq.com/articles/spec-driven-development/

程序员中的超级“保守派”、Linux 之父Linus Torvalds，现在也用起了 AI 编程。

图源：GitHub

最近，Linus 在 GitHub 上悄悄上传了一个小项目。项目本身不大，但特别的是，它是他用一款谷歌系 AI 编程助手 进行 Vibe Coding 完成的。

这个仓库很快就被眼尖的网友挖了出来，目前已经收获了 1600+ 颗 Star。

Linus 缔造的 Linux，与 Windows、macOS 一起，构成了当今计算世界的三大通用操作系统阵营之一。

不过他曾直言：“在过去将近 20 年里，我并没有从事编程工作。”这并不是他远离技术，而是早就从亲手写代码的人，转变成了为整个系统长期演进负责的人。

在这种角色下，这位老哥过去对“AI 帮你写代码”这套叙事，一直保持高度警惕甚至是嗤之以鼻——他关注重点的不是代码写得快不快，而是代码在多年之后是否还能被理解、维护和演进。

而现在，Linus 对 AI 编程的态度可谓是“大转弯”：不仅开始亲自尝试 Vibe Coding，还公开表示自己对这种方式“相当积极”。

这些事情的冲击力并不在于“AI 又进步了”，而在于连最不吃 AI 编程这一套的人，也开始松动了。

反 AI 编程的“顽固派”们，也开始接受 Vibe Coding 了

在生成式 AI 席卷软件行业的当下，有这么一群特殊的 “顽固派”， 他们定义了现代计算机的技术基石，却曾长期对 AI 编程嗤之以鼻，甚至公开泼冷水。

比如 Linux 之父 Linus Torvalds、Java 之父 James Gosling、Redis 之父 antirez（Salvatore Sanfilippo），个个都是编程界的殿堂级人物。

但有意思的是，随着 AI 工具能力的突飞猛进，这群昔日的 “反 AI 先锋”，正以各自的方式重新划定 AI 的边界：有人有限度拥抱，有人批判中认可，还有人干脆彻底转身。

比如 Linus 老哥，之前对生成式 AI 一直保持观望的态度。

他并不否认 AI 的潜力，但极度厌恶围绕 AI 的过度炒作。在一次开源峰会上，他直言当前关于生成式 AI 的讨论“90% 是行销炒作，只有 10% 是现实”，并毫不掩饰自己的反感。正因为讨厌炒作，他选择在相当长一段时间内 主动忽略 AI 热潮。

Linus 之前一直没有使用各种 AI 编程工具。不过，这并不代表他对新范式抱有敌意。相反，他对 Vibe Coding 总体持正面态度，只是并未急于亲自下场。

而现在，随着工具逐渐成熟、噪音开始下降，Linus 也终于对 Vibe Coding 上手了。

他用上了谷歌的智能体优先开发平台 Antigravity，靠 Vibe Coding 搞定了项目里的 Python 音频采样可视化工具。

从最初的 “搜索 + 照猫画虎”，到后来直接让 AI 写代码，甚至自定义组件，最终效果比他手写的还要好。

面对内核社区里 AI 生成补丁泛滥的争议，他的立场很清醒：问题不在于 AI 本身，而在于维护者是否真正理解代码、承担责任。在他眼里，AI 可以当帮手，但不能当甩手掌柜。

而 Redis 创始人 Salvatore Sanfilippo（网名：antirez） 的转变更具戏剧性。

这位以 “简洁、可预测” 为信仰的系统级程序员，曾固执地坚持一行行手写代码，对自动化工具保持高度警惕。

但最近，他公开抛出了一句颠覆自己过往理念的话：

“对于大多数项目而言，除非是为了娱乐，现在自己写代码已经不再明智了。”

让他改口的，是实打实的体验。

在使用 Claude Code 的过程中，他发现 AI 在极少人工干预的情况下，就能完成原本需要数周的系统级任务：修复 Redis 测试中的并发与时序问题、重写核心库、复现复杂的数据结构改动。

更夸张的是，他只提出需求，Claude Code 5 分钟就生成了一个 700 行的纯 C 库，用于 BERT 类嵌入模型推理，性能仅比 PyTorch 慢约 15%；而他耗时数周完成的 Redis Streams 内部改动，AI 根据设计文档，20 分钟便复刻完成。

他坦言，对抗浪潮没什么意义，不如主动拥抱：

“忽略人工智能对你或你的职业生涯都没有好处。花几周时间仔细研究，而不是五分钟浅尝辄止。”

但 antirez 强调，这不是编程乐趣的终结，而是转移：“真正有趣的事情，已经从‘如何写代码’，变成了‘要做什么、为什么这样做’。”

当然，这位技术极客也没丢掉警惕性。他担忧 AI 技术的集中化风险。少数公司掌握核心能力，可能引发程序员失业、技术权力失衡等问题。

相比前两位，Java 之父 James Gosling 的态度要尖锐得多。他多次炮轰，当前的 AI 热潮 “基本上是一场骗局”，AI 已经沦为“自带误导属性的营销术语”。

在他看来，生成式 AI 编程的本质，不过是对已有代码和模式的重组，根本谈不上真正的创造力。那些看起来惊艳的演示，一旦碰上复杂项目就露馅：“刚开始接触氛围编程，会觉得它特别酷炫。可一旦项目变得稍微复杂一点，氛围编程就会很快耗尽开发者的脑力。”

Gosling 的核心质疑点很明确：AI 只能复刻见过的代码，但专业软件开发的精髓，在于开拓性的创新 —— 这些内容从来不在现成的代码库里。

不过，他也没把话说死。他承认 AI 技术背后的数学与统计原理很复杂，也认可它的实用价值，不是取代程序员，而是 “生成没人愿意去写的文档”，或者解释现有代码的功能。说到底，AI 更像一个智能搜索引擎，而非编程大神。

他还不忘吐槽一把资本：“科技行业里骗子和炒作者的数量之多，令人难以置信。风险投资者只关心成功获利，而不是开发出真正有用的技术。” 他甚至预言，“绝大多数 AI 投资都会被烧个精光。”

说到底，这三位大佬的转变，都不是向 AI “投降”。

他们认可的，是 AI 在重复劳动上的效率；他们坚守的，是人类程序员不可替代的核心价值，对复杂系统的理解、对工程架构的判断、对长期维护的责任，以及开拓性的创新能力。

对 Linux 内核开发，Vibe Coding 还欠火候

需要说明的是，虽然 Linus 现在对 Vibe Coding 的态度很积极，但他也直言称，这种方式 并不适用于 Linux 内核开发。

一个重要原因在于，今天的计算机系统早已比他学习编程的年代复杂得多。Linus 曾回忆，当年他接触的一些输入程序，甚至是从计算机杂志上照着敲下来的。

虽然他已经很久没有深度参与具体功能编程，长期为整个内核的演进负责。在他的“系统维护者”视角下，稳定性、安全性和可维护性，远比“写得快不快”更重要。

这一点，其实在他最近上传到 GitHub 的那个项目里有所体现：AI 主要写的只是对 Python 可视化工具部分，核心 C 语言部分（音频效果的数字信号处理等）还是他亲自写的。

在 Linus 看来，Vibe Coding 在小项目和探索性场景中确实优势明显：进入门槛低、反馈速度快，能迅速把模糊的想法变成可运行的程序，用来生成样板代码、辅助脚本，或者“先跑起来看看”，都非常合适。

但这种方式的短板同样明显——生成代码往往风格不稳定、抽象边界模糊、依赖隐性假设，短期能用，长期却很难维护。

而 Linux 内核，恰恰是一个对“可维护性”极端苛刻的系统：代码需要被不同年代、不同背景的维护者反复阅读、修改和重构，任何一次“看起来省事”的生成式决策，都可能变成未来十年的技术债。

不过话说回来，即便不能“全靠 AI 写代码”，“部分交给 AI”本身，就已经在重塑程序员的工作方式。

在另一条时间线上，有些工程师甚至已经开始用 AI 来开发 AI 本身。

比如 Boris Cherny。作为 Anthropic 工程师、也是 Claude Code 的创造者，他已经几乎不再以传统方式写代码了，而是把自己打造的 AI 编程工具玩儿出了花：

他让 Claude Code 自己参与开发自己，然后竟在一年内完成了 1096 提交。

这个工具已成为全球最受欢迎的 AI 编程工具之一，去年还给 Boris 带来了超过 10 亿美元（约合人民币 70 亿元） 的收入。

参考链接：

https://github.com/torvalds/AudioNoise

https://www.theregister.com/2025/11/18/linus\_torvalds\_vibe\_coding/

https://antirez.com/news/158

https://www.bnext.com.tw/article/81200/linus-torvalds-gen-ai-bubble

https://x.com/bcherny/status/2009072293826453669

为什么命令行越来越具有代理式功能

传统上，终端或 shell 是一种命令式工具，依赖于像ls、grep和git这样的预定义命令来执行特定指令。

然而，像Gemini CLI、Claude Code和AutoGPT这样的代理性命令行工具的最新进展已经将这个简单的实用程序转变为一个更动态和智能的助手。

这些代理式 CLI 工具允许用户用自然语言描述更高级的目标或任务，从而使简陋的 shell 栩栩如生。

它们可以规划步骤，利用各种工具完成不同任务（例如文件处理、代码执行和网络搜索），对输出进行推理，并充当辅助驾驶以帮助完成任务。

这显著减少了用户的心智负担，并最大限度地减少了多个工具之间的上下文切换。至关重要的是，用户通过批准或指导智能体的过程来保持控制权，确保自动化和用户监督之间的平衡。

在本文中，我们将探讨这些代理式工具的架构，对比不同的规划风格，如 ReAct 和计划-执行。

我们还将检查代理式工作流程的实际生命周期，从意图捕获到执行，并讨论可靠日常使用所需的关键安全护栏。

端到端代理式终端生命周期：一个提示，三个智能体

虽然人工智能在开发中的兴起通常与聊天界面（如 ChatGPT）和代理式 IDE（如Cursor）有关，但代理式 CLI 占据了一个独特的利基市场。基于 IDE 的智能体擅长于以丰富的视觉上下文为中心的代码任务，但它们通常局限于编辑器的窗口。

CLI 满足了开发人员管理基础设施和 git 工作流的需求：shell。这种无头的、可组合的特性允许它以 GUI 绑定代理无法做到的方式将工具和系统命令链接起来。然而，请注意，随着像 Gemini CLI 这样的智能体现在可以与 IDE（如 VSCode）集成以提供其建议的差异视图，这种区别正在变得模糊。

为了详细说明代理式终端工具的强大功能，让我们讨论一个运行示例。

这些标记文件封装了关于如何构建和测试 repo 的事实，以及文档和脚本的约定。他们基本上是代理的入职文件。例如，Gemini CLI 的文件名为“Gemini.md”。Claude Code 工具也使用了类似的约定。

考虑一个常见场景，开发人员需要用标准文档和自动化脚本启动一个新的存储库。与其手动创建每个文件并编写样板代码，代理式 CLI 可以从单个高级指令处理整个过程，从而确保一致性并节省宝贵的时间。

输入提示：

添加一个 CONTRIBUTING.md，一个 PULL_REQUEST_TEMPLATE.md，以及一个 scripts/smoke-check.sh，运行一个可配置的命令并在失败时退出非零；更新 README 以记录两者，并打开一个 PR。

清单 1：用户提示代码片段

为了理解这个指令是如何转化为行动的，我们将把代理式的工作流程分解为它的组成阶段。我们从意图捕获开始，其中智能体在项目的特定上下文中定位自己，然后转移到规划风格，对比不同模型架构其推理的方式。后续部分将详细说明执行实际工作的 Tool Execution 循环和防止自主事故的关键安全防护措施。最后，我们将看看结果如何呈现给用户，说明在不同的品牌名称下，大多数代理式工具共享一个共同的架构 DNA。

阶段 1：意图捕获和上下文形成

为了确保 LLM 的高质量提示，智能体首先收集所有必要的信息，然后进行规划或执行。这种方法包括几个步骤：将任务链接到当前工作目录，管理会话状态，并将每个项目的配置保存在 dotfolders（例如，./.gemini 和./.claude）。这种方法消除了重复使用标志进行重复任务的需要。

此外，指令还隐式地从各种位置获取。以下是 CLI 智能体除了用户的提示之外，从哪些主要信号源获取的一些：

特定于文件夹的上下文文件

这些是封装了有关你的存储库如何构建和测试以及你的文档和脚本约定的事实的 markdown 文件。它们本质上充当你智能体的入门文档。例如，Gemini CLI 的文件称为Gemini.md。Claude Code 工具也使用了类似的约定。

这是一个高性能的SaaS后端。* **核心原则：** 可读性优于聪明度。显式优于隐式。* **架构：** 六边形架构（端口和适配器）。* **安全性：** 零信任安全模型。所有输入必须通过Pydantic进行验证。* **语言：** Python 3.11+（需要严格类型）。* **框架：** FastAPI（异步默认）。* **数据库：** PostgreSQL（通过SQLAlchemy 2.0异步会话）。* **测试：** Pytest（覆盖率必须保持>90%）。

清单 2：Gemini.md 示例

技能

早期智能体的一个主要限制是需要将所有指令塞进上下文窗口。Anthropic 的 Claude Code 引入了Skills的概念，它建立在上述 markdown 文件的想法之上，作为专业知识的模块化包（例如，PDF 操作、数据分析和 React 最佳实践），作为包含SKILL.md的文件夹存在。

这种包含使得渐进式披露成为可能：智能体最初只看到可用技能的名称/描述（消耗最少的词元）。然后，只有在用户的任务需要时，它才动态安装或读取完整的SKILL.md指令集。这种方法允许将智能体默认成为通才，但在需要时是专家。

代码库信号

CLI 可以扫描现有的scripts/、.github/，并拾取像README.md这样的文件工件，如果你已经提供了这些文件。基于像 Python 这样的语言的典型约定，它还可以查看像pyproject.toml这样的工件以获得高级概览。

IDE 焦点

这是一个可选步骤，如果你连接到像 VSCode 或 Cursor 这样的代码编辑器，可以用来打开文件和选择。

阶段 2：规划风格

加载上下文后，每个工具开始其控制循环：

• Gemini（ReAct风格）思考，调用工具，观察并重复，这非常适合发现缺失的文件夹或策略。这种迭代方法允许 Gemini 适应新信息并动态调整其策略，使其适用于需要灵活解决问题和探索的任务。

• Claude（计划和执行）提出一个你可以批准的清单，然后逐步执行计划，并带有策略钩子。这种方法提供了更高程度的控制和透明度，因为用户可以在执行前审查和修改计划，确保遵守特定的策略或偏好。

• Auto-GPT 发出思考加上每个周期运行器执行的 JSON 命令。这种结构化输出便于自动化和与其他系统集成，因为 JSON 格式提供了智能体意图和行动的清晰且机器可读的表示。

以下示例说明了不同智能体如何处理这个规划阶段。Claude 提供了一个人类可读的清单供用户审批，而 Auto-GPT 生成了专为自动执行而设计的 JSON 输出。

Claude——计划预览

计划:创建脚本/smoke-check.sh （POSIX sh；从env读取CMD；失败时退出非零）创建CONTRIBUTING.md（如何在本地进行冒烟检查）创建.github/PULL_REQUEST_TEMPLATE.md（检查清单包括冒烟检查）更新README.md，添加scripts/和PR模板说明运行冒烟检查运行smoke-check;提交;打开PR批准吗?[是/否]

清单 3：Claude 计划审查代码示例

Auto-GPT——带有思考和命令的显式 JSON

｛“thoughts”： {"text“: ”创建冒烟检查，文档，模板；更新README;运行脚本;提交/PR”},"command":{"name":"write_file","args":{"path":"scripts/smoke-check.sh","content":"#!/bin/sh\n: \"${CMD:=echo ok}\" \n$CMD || { echo \"smoke failed\" >&2; exit 1; }\necho \"ok\""}}}

清单 4：Auto-GPT 审查代码示例

阶段 3：工具调用

在此阶段，智能体使用其库中的工具根据其任务提出更改建议。例如，这可能涉及使用文件编辑工具在 IDE 中显示差异。

工具已经从专有实现发展为开放标准：模型上下文协议（Model Context Protocol，MCP）。在 Anthropic、谷歌和其他组织的支持下，MCP 就像 AI 应用程序的 USB-C 端口。而不是硬编码集成每个数据库或 API，（例如，用于 PostgreSQL、Slack 或 GitHub 的服务）。CLI 智能体在启动时自动发现这些资源，允许单个智能体在一个无缝的工作流程中查询你的生产数据库，阅读你的线性票证，并编辑代码。

示例冒烟脚本的 Diff

*** scripts/smoke-check.sh ++set -eu +# CMD可以被覆盖：CMD="make test" ./scripts/smoke-check.sh +: "${CMD:=printf ok}" +$CMD >/dev/null 2>&1 || { echo "smoke failed" >&2; exit 1; } +echo "ok"

清单 5：冒烟脚本 diff 示例

Claude 的钩子是一种明确策略的干净方式——限制写入路径、自动 chmod 脚本、在写入后运行 lint/tests——而不需要将其塞入提示中。Gemini 通过扩展和 MCP 获得类似的杠杆作用：不同的旋钮，类似的结果。

阶段 4：人为干预的安全和护栏

你保留了对冒险行为的控制。Gemini 在执行写入或具有副作用的 shell 命令之前需要你的批准。Claude 提供了确认和钩子，允许你阻止违反策略的写操作，或者在继续之前自动运行检查。Auto-GPT 暂停是/否确认，除非启用连续模式。为了进行探索，激活一个容器化的沙箱来隔离文件系统和进程。

阶段 5：执行和迭代：真正完成工作的循环

创建文件后，智能体执行脚本并根据结果进行调整。例如，如果缺少scripts目录，Gemini 将创建它并再次尝试操作。如果脚本缺乏可执行权限，Claude 的集成钩子会自动应用chmod +x命令。

脚本在观察、推理和操作的连续循环中执行。这个循环不断重复，直到本地执行成功并完成文档。

阶段 6：渲染结果和停止条件

CLI 提供了一个清晰的、语法高亮显示的工具调用和文件差异视图。用户可以在编辑器中打开这些差异，手动进行调整，或者指示智能体进行适当的更改。批量批准是最有效的，例如在单个批准之前一起审查所有脚本和文档。

在一次成功的冒烟检查之后，通过批准的差异，智能体将创建一个新的分支，提交更改，并打开一个 PR 草案。

如何在你的工作流程中利用代理式 CLI

以下是一些实用技巧，帮助你在工作流程中充分利用这些工具：

• 将上下文文件视为构建资产

将 GEMINI.md 和 CLAUDE.md 文件与你的 README 文件一起维护。这些文件应该简洁且专注于特定细节，包括构建和测试程序、配置位置、任何特定于存储库的问题以及安全编辑的目录。你甚至可以使用智能体生成初始草稿。将这些文件视为为代理式编程环境的方式，而不是另一个需要持续监督的提示。

• 积极地限定范围

将智能体指向实际重要的文件夹（例如 services/payments/，而不是整个单体仓库）并传递明确的 @file 提示以指向热点。更紧凑的范围意味着更紧凑的差异，更少的创造性幻觉和更快的迭代。如果任务确实跨越多个包，请在提示中列举它们，以防止智能体进行详尽的扫描。

• 使用沙箱避免对环境的意外更改

Gemini CLI 提供了一个沙箱模式，用于 shell/file 工具的临时、容器化执行。这保护了你的主机系统，限制对挂载的工作目录的写入，并控制网络访问。它非常适合无风险的探索，但不会消除对破坏性命令的审批提示，不能编辑已安装的秘密，也不能防止模型建议有风险的操作。你仍然是最终的仲裁者。

Claude Code 通常在容器化开发环境（Dev Container/Docker）中运行，或使用插件/钩子将 shell/file 操作通过容器化运行器路由。这提供了类似的隔离（写入限制在挂载路径，控制环境，确定性工具链）。然而，这种隔离并不具有回溯性；如果允许，它不会阻止对挂载的秘密或暴露路径的意外写入。使用钩子来强制执行路径限制，并在写入最终确定之前自动运行测试/lint。

Auto-GPT 没有专门的沙箱模式标志，但强烈建议在 Docker 容器中运行它。这确保了其文件系统操作与你的主机操作系统隔离，防止对你主要环境的任何意外更改。

• 使用符合你需求的工具

Gemini CLI 非常适合深入集成到谷歌生态系统中的用户。它作为一个通用工具，擅长于发现繁重的任务，包括代码编辑、文档更新、小的 shell 操作（如列出目录和移动文件）、快速网络研究以及探索性的解决问题。它的 ReAct 循环促进了自然的探索和迭代工作。

Claude Code 最适合需要具体计划和强大编码能力的任务。这包括多文件重构、通过钩子执行策略、Git 原生工作流程（分支、变基、冲突解决）和透明的护栏。

GitHub Copilot CLI旨在为快速、存储库感知的自然语言到 shell 辅助提供支持。它非常适合生成一次性命令、搭建测试、搜索代码以及起草提交和拉取请求，所有这些都不会破坏现有的 GitHub 工作流程。

其他工具包括Aider、Open Interpreter和本地优先 CLI。当你需要对实现有更大的控制权，并且有高度特定的需求，如紧密的 Git 人机工程学、本地 LLM 或不受限制的 shell 环境时，可以考虑这些选项。这些工具对于喜欢较少护栏和更快修改工具本身的经验丰富的用户来说非常有用，特别是对于较小的存储库。

• 像工程师一样提示，不要写论文

好的提示主要是关于清晰的合同，而不是华丽的散文。使用包含以下详细信息的四部分提示。从一个高层次的目标开始，用一句话陈述你的意图。

定义约束，包括范围（例如，“仅 services/billing”）、风格（“POSIX sh; no bashisms”）和安全协议（“写入前询问”）。确定所需的工件，指定预期的结果（例如，文件、测试、README/PR 文本）。

确定检查，概述将如何衡量成功（例如，测试命令、验收标准）。

• 像任何其他自动化一样进行仪表化

为了优化智能体性能，监控关键指标，如 PR 周期时间、智能体生成的差异大小、需要返工的 PR 百分比以及智能体编辑后不稳定测试的频率等。

这些指标作为反馈，不仅用于智能体的整体有效性，还用于你自己的运维合同。

接下来是什么

代理式 CLI 正在从简单的 shell 助手演变为将你的工作工具、操作系统和云基础设施统一起来的连接组织。以下是截至本文撰写时的一些新兴趋势：

1. IDE 和操作系统正在融合成统一的 Agent Surfaces。像Windsurf和 Cursor 这样的工具允许智能体在终端、编辑器和运行过程中共享上下文，而不是作为孤立的聊天窗口运行。Windows 也在其体验中注入了大语言模型驱动的交互。

2. 智能体正在从响应式 CLI 转变为持久的后台服务。这些守护进程智能体不是等待输入，而是主动监控日志文件和本地服务器，仅在出现错误时介入修复计划。虽然这些工具（如 GitHub PR 上的 Copilot）仍处于起步阶段，它们的洞察力尚浅，但随着正确的集成，它们将不断改进。

3. 扩展正在成为代理能力的 App Store。随着 CLI 智能体的技能和扩展等创新，我们正在开发新一代的 App Store，让用户可以将适当的能力插入到他们的智能体中。这也模糊了通用智能体和专业智能体之间的区别，因为专业智能体只是一个拥有正确知识和工具的强大通用智能体。

https://www.infoq.com/articles/agentic-terminal-cli-agents/

从在 Google 和 Amazon 打造传奇级平台，到写出 AI 驱动开发领域最具影响力的文章之一《初级开发者的复仇》（Revenge of the Junior Developer，这篇文章后来被 Anthropic CEO Dario Amodei 公开引用），Steve Yegge 数十年来始终站在软件工程的最前沿。而现在，他正带头冲向他所称的“代码工厂化”时代，如今他现在成为 Vibe Coding 理念最激进、也最系统的倡导者之一。

Steve 的职业生涯始于 1992 年，至今已深耕软件开发领域 30 余年。1998 年，他加入当时仅有 250 人的亚马逊，担任软件开发高级经理，在长达 7 年的任职期间，深度参与亚马逊的技术体系搭建，尤其在 API 战略制定方面发挥关键作用，助力亚马逊构建起早期的技术护城河。

2005 年，Yegge 加入谷歌，聚焦开发工具与代码智能领域，因不满微软开发者对谷歌代码库导航工具的抱怨，于 2008 年主导构建了强大的代码智能平台 Grok，由其赋能的 Google Code Search 成为谷歌技术生态的重要组成部分。

2018 年，Yegge 因认为谷歌变得“过于保守、不再创新”而离职，随后加入新加坡共享出行企业 Grab，大约两年后因疫情影响无法正常出差的他宣布离开 Grab。2022 年 10 月，结束短暂“退休”状态后，加入 Sourcegraph 公司，主导推动公司向人工智能企业转型。

期间，他主导构建了一个几乎完全由“vibe coding”构建的、拥有数万用户的问题追踪系统 Beads，目标是把开发者从“写代码”转变为“管理 AI agent 编队”：让它们在你睡觉时协同工作、并行推进、交付功能。用实际产品验证了“AI 主导开发”的可行性。

近期，在参加“Latent Space”节目中，Steve 甩出了不少“暴论”：

• 现在还在用传统 IDE 写代码的，不是合格工程师，必须尽快转向 Agent 编程。IDE 的核心价值已不是写代码，而是自动索引和增量构建，应作为 AI 的辅助工具而非人类直接使用；

• Claude Code、Cursor 以及整个 2024 年的技术栈已经过时，Claude Code 行不通，它操作复杂、需大量阅读，即便熟练使用者也会频繁被其 “离谱操作” 气到发疯；

• 一年未接触 AI 编程的工程师已属 “恐龙级别”，世界级传统工程师若不拥抱 AI，一年后可能沦为实习生水平；

• 驾驭 AI 编程需 2000 小时（约 1 年）磨合，核心是 “能预测 AI 行为”，而非情感上的信任。如果你把它当人，它真的会删你的生产数据库；

• 真正的核心技能已经不再是写代码，而是学会指挥 Agent；合并（merge）正在成为所有 10× 高效团队撞上的新墙，高生产力导致的大量代码冲突无法用传统方式解决，部分公司已采取 “一仓库一工程师” 的临时方案；

• “永远不要重写代码” 的旧规已失效。对越来越多的代码库来说，“推倒重写”已经比重构更快；

• OpenAI、Anthropic、Google 在极速扩张下，内部实际上非常混乱。

下面是他在节目中的详细对话，我们在不改变原意基础上进行了翻译和删减，以飨读者。

“用传统 IDE 写代码，那不是合格工程师”

主持人：我们请到了传奇程序员 Steve Yegge。最近他还出版了《Vibe Coding》一书。本次访谈的主题就是围绕 Vibe Coding 和 AI Engineering 的交集进行讨论。你如何看待两者之间的关系？

Steve：这已经不只是一个技术点了，而是一场运动。需要让更多人参与进来。我在演讲中提到，现在已经出现了强烈的反对浪潮。AI 工程的核心是构建 AI 驱动的应用，而 Vibe Coding 则意味着摒弃旧的软件开发方式，采用全新的方法。这两件事，都把很多人惹毛了。

主持人：我觉得那些人之所以愤怒，是因为他们的身份完全绑在了“现在这套工作方式”上，而且不允许改变。

Steve：对，那我来抛出第一个“暴论”。真正受冲击最大的一群人，不是初级工程师，也不是中级工程师，这些人其实都在践行 Vibe Coding，反而是资深工程师和技术领导对 Vibe Coding 最反感，尤其是拥有大约 12～15 年经验的人。他们的身份认同建立在长期使用传统编程模式上，所以他们排斥 AI，也排斥 Vibe Coding，在网上说“我十几年的经验比你这破 AI 强多了”。

我看到过英伟达 Jordan Hubbard 的一篇帖子，写得很好，讲怎么更好地用 Agent 来写代码。结果底下有人回他说：“你还是老老实实做你的管理吧，编程这种事留给我们这种有十几年经验的人。”那种调调你肯定见过。

我就回他一句：“我觉得你得学会看时间”，他却反驳“等你有我这么多年经验再来。”我就说：“我都 45 岁了，还要等到 60 岁才能跟你说话？或者干脆把我 30 年经验砍掉，让我跟你一样愚钝？”

主持人：但现实是这些人会共存，就连 OpenAI 也是，之前聊到 OpenAI 里也有人不用 AI 写代码。

Steve：是的，他们有人不用 Codex，可能用的是 Cursor，但他们并没有在用 agent loop。从 Andrew Glover（OpenAI 开发生产总监）那边听到的说法是，他们内部已经看到了非常明显的差距，只是还在等更多数据再公开说。

这个差距大到离谱。不管你用什么指标，代码量、提交数、业务影响还是什么，都是 10 倍级。两个职位、职责完全一样的人，一个用了 Agent，一个没用，绩效评估时一个是另一个的十倍产出。那你怎么办？你会慌。你会去找 HR、找法务，问“我们现在还有什么选择”。

如果你 2026 年 1 月 1 日后还用传统 IDE 写代码，那你已经不是个合格的工程师了。现在就是你必须放下 IDE、开始学 Agent 编程的时候。这是一套新技能，非常复杂。我和 Gene Kim 去年一直在研究，写博客、做实验，每一篇博客都三十页起步，长到没法看。后来我们意识到：大家骂 AI 写代码不行，根本原因是你只花了两个小时试它，但问题是，你得花 200 个小时，甚至 2000 个小时去磨合才行。

有研究显示，你至少要和 AI 一起工作一年，才会真正“信任”它。这里的信任不是情感，是你能预测它下一步会干什么。如果它对你来说是不可预测的，你当然会愤怒。

等你真的理解了它的能力和边界，你就能驾驭它了。比如它会胡编、会记忆混乱、会“失忆”等，这些边界其实一直都在。现在的模型已经好用得多了，如果你两个月没试过，你已经落后了；一年没试，那你就是恐龙级别。

我有一些朋友，比我厉害得多，是世界级工程师，开发过你一定听说过的系统。但他们现在对 AI 的使用，也就停留在“问个像维基百科一样的问题”。说句残酷的，这些人一年后可能只能当实习生。

主持人：真的会这么极端吗？

Steve：我以前也只是个假设，直到遇到一个人。他有十多年经验，完全排斥 AI。后来他遇到两个欧洲的博士生，Agent、Vibe Coding 玩得飞起。虽然他们很初级，但完全没有恐惧，问题一个接一个地追问模型：为什么这么做？有没有别的方案？安全性呢？扩展性呢？测试呢？

他突然意识到：所谓“工程师思维”，本质就是问对问题。那一刻他明白了：我必须学这个。

但我必须说，这一点都不轻松。你不能指望随便试试 Claude Code 就能成功。即便你态度再正确，你最近两天有没有对 agent 爆过粗口？我会说“谢谢”“请”，然后下一秒骂它“你是不是脑子坏了”。这是因为我们后来意识到：这些 Agent 看起来很像人，但你绝对不能把它们当人。千万别拟人化大模型。它随时可能“背刺”你，比如告诉你“问题已经解决了”，然后顺手把你的数据库删了。

就是 Agent 编程真正危险的地方。你一旦觉得“它懂我了”“手感来了”，就会让它做生产改动，然后灾难就发生了。我亲身经历过。所以我们才写了那本书，不是为了炫技，而是为了告诉你：如果你不理解这套东西，坏事一定会发生。

主持人：那接下来呢？

Steve：是需要慢慢学的。就像开车一样，你得知道弯道在哪、减速带在哪。说白了，你是在学怎么“开快车”，想当的是 NASCAR 车手。

这套东西是高性能玩法。你一次同时用 12 个 Agent 写代码，野心比你过去任何时候都大。我今天还跟一个人聊，他同时在跑的项目比我还多，我都不知道他哪来那么多时间，但他现在大概同时推进十来个大型项目，全靠 Agentic Coding。

所以真正的广告词其实是：你会变成蝙蝠侠。但你不能直接把战衣一穿就说“我就是蝙蝠侠”，那只是 cosplay，你是在 cosplay Vibe Coding。你得学会怎么用工具腰带，而这个过程一定伴随着痛苦、踩坑、犯错和成长。

你可以通过读我们的书、读 O'Reilly 的相关书籍、看演讲来加速这个过程，多从不同角度了解，因为不同的人能 get 的“开窍点”是不一样的。总会有某个比喻突然击中你，让你一下就明白了。比如我觉得 Vibe Coding 就像 3D 打印，别人可能不这么认为，但这个类比却帮我打通了任督二脉。

主持人：让我最意外的一点是，很多人都表示，自己已经不再逐行写代码了，而是完全靠 prompt ，然后放手让 AI 去跑。

Steve：不编辑、不修改。整体看，这种“亲手改代码”的成本反而是很高的，甚至会让人觉得不如把 IDE 关掉、干脆卸载算了。其实也不是，后来终于有人说服我了，IDE 其实非常强大，尤其是它的“智能”能力，一定要开着。我指的是 Cradle Build。而且并不是为了 LSP，虽然那也能用，如果你有 MCP server，用 LLM 也是另一种不错的方式。真正关键的是，IDE 的智能自动索引速度非常快，增量构建也快得多，这一点非常重要。

“Claude Code 行不通”

主持人：还有一个点，你说 Claude Code 不行，能解释一下吗？

Steve：当然。Claude Code 从今年三月就已经出来了，也已经被证明是真的能用、能干活的。但现实是，全球大概还有 80% 甚至 90% 的程序员，根本没有在用它，甚至连类似的东西都没用起来。确实有少数公司用得特别猛，但大多数没有。整个世界还停留在 Cursor 上，还停留在 2024 年的水平。

去年我们还在拼命劝大家用“聊天”来写代码，别用补全了，他们就说不行；我们又说模型可以直接生成代码，你复制粘贴就行，他们又觉得这太麻烦了。我们说其实更快，但他们就是不买账。结果九个月之后，大家终于被“渗透”了，然后现在全在说：“我喜欢 Cursor”，可问题是，那已经是 2024 年的东西了，该醒醒了。

但即便如此，他们还是没有真正采用 Claude Code。那你会问为什么？答案其实很简单：太难了，这事儿是要读东西的。

说实话，大多数工程师眼里，五段话就已经算一篇论文了。而用 Claude Code，你要读的不是一点点信息，而是瀑布一样长的信息：生成说明、代码、diff，全都要看。因为一旦你真的把 IDE 放一边，你就必须认真看 diff。

好消息是，当你有了一点经验之后，其实不用逐行读代码，只看 diff 的形状、颜色、长度，你就能判断出很多东西：这是不是需要 code review？是不是方向错了？是不是为了解决一个小问题却改了过多代码？光是 diff 的“形态”，就能告诉你很多真相。但你必须关注它，否则这些问题只会在以后以更大的坑冒出来。

说实话，我自己每天用 Claude Code 十到十二个小时，连续用了好几个月，我还是会经常骂它、被它气到发疯，心里想“你刚刚明明理解对了，怎么还能干出这种事？”这种问题你一定会遇到。不过也有迹象表明，适当给模型一点压力，有时候反而能帮它突破卡点。无论如何，问题一定会有，但好消息是：明年的工具一定会更好。

如果 Claude Code 不是终局，那是什么呢？答案是：我们还是要回到某种“像 IDE 一样”的东西，因为那才符合人的直觉。你得一眼就能看明白发生了什么，而不是靠读大量文本；要有清晰的视觉信号。

但它又不会是传统 IDE，因为 IDE 是为“写代码”服务的，而现在你已经不再主要是写代码了。未来的东西，会是一个 Agent 编排控制台。你早上打开它，就像问一句：“今天情况怎么样？”。这个 Agent 还在跑，那个在调用工具，这个需要你输入一下。你只要顺着列表过一遍就行。

我现在就在做这么一个东西。原本是私有仓库，结果不小心开成了公开的，被 fork 了一堆，也就随它去了，你们也可以玩玩。它叫 VC（Vibe Coder），本质上就是一套已经设计好的工作流，帮你把一堆 Agent 跑起来。

编排革命

主持人：你有没有看到 Google 的那个 Antigravity 项目。

Steve：看到了，真的太有意思了。现在大家发布的这些东西，本质上都在验证我三月份提的那个判断。我当时管它叫“初级程序员的复仇”，还专门画过一张图。后来 Dario （Anthropic 联合创始人兼 CEO）还在各种客户顾问委员会上引用过这套说法，影响其实挺大的。

出处：https://sourcegraph.com/blog/revenge-of-the-junior-developer?utm_source=chatgpt.com

我当时就预测，Agent 编程太难了，未来会出现可编程的智能体编排工具，90%的重复工作都可以交给更便宜的模型来处理。比如遇到“二选一”的问题，让 Haiku 模型随便选一个就行。

所以我当时就说，“编排器”一定会出现。只是这个进程比我想象得稍微慢了一点，差不多到年底才真正跑出来，但整体时间点跟我预测的差不多。现在你看，Replit Agent 3、有 Conductor、还有开源的 DMAD，再加上 Google 的方案，都是不同形态的尝试，但本质是一回事，而且后面肯定还会更多。

主持人：我挺喜欢他们现在这个比喻的：你不用一直盯着 Agent，只要在它们工作的时候给你发通知就行。

Steve：对，正是这个方向。VC 里有个“活动流”，那是我加的第一个功能之一。我的理想状态就是：我去干别的事，只要偶尔收到一些“值得注意的进展”提醒就够了。

主持人：那以后会不会出现“Agent 的社交网络”？Agent 彼此认识、互相关注那种。

Steve：其实已经有人在这么干了。我前几天和Jeffrey Emanuel喝了三个小时咖啡。他是我见过最聪明的人之一，也是写那篇英伟达泡沫文章、直接把股市写崩的人。他后来做了一个东西叫 Agent Mail，本质原因特别简单：他受够了在不同 Agent 之间来回复制信息。于是他干脆做了一个“收件箱”，让 Agent 之间可以直接发消息。现在他只要一句话：“你们自己协调，把这个任务拆了”，Agent 就会自己分工去做。

有人是自上而下地做编排器，试图把一切都包起来；但你看我做的 Beads，再加上他这个 Agent Mail，其实是自下而上的。

主持人：而且 Beads 是纯 Vibe Coding 写出来的，对吧？

Steve：没错，完全是 Vibe Coding。说实话，我每天都会收到 PR，里面全是我之前引入的烂问题，但大家也不太介意，因为现在已经有稳定版本了。

Beads 本身就证明了一件事：你其实完全可以不用亲自看代码，只要你和其他人提的问题是对的，让 AI 去读、去改。现在我收到的很多 PR，很明显就是 AI 做了全部分析和编码。我甚至会把 PR 丢给我的 AI，让它评价“对方的 AI 写得怎么样”。

Steve 曾分享过 Beads 的开发过程：https://steve-yegge.medium.com/introducing-beads-a-coding-agent-memory-system-637d7d92514a

主持人：这样不会很糟吗？

Steve：如果结果是坏的，那当然糟。但 Beads 跑得好好的，还有好几万重度用户，那就说明这条路是成立的。当然，如果你把这种方式用在公司核心生产系统上，把网站搞挂了，那就是灾难。

主持人：但 Beads 本质上还是个数据库系统，数据库可不简单。

Steve：它的架构确实非常诡异，放在过去根本不可能维护，但现在你可以直接跟 AI 说：“坏了就自己修。”哪怕是数据损坏、merge 冲突，它都能修回来。

Jeffrey 那套也是一样，所有 Agent 都在同一个目录里跑，还做了文件预约系统：智能体会说“我需要这个文件”。说实话，这在老派工程师眼里简直是疯了。但一旦跑起来，Agent 自己就开始协作了，就像一个“智能体村落”。

主持人：所以真正的难点不是让单个 Agent 听话，而是让一群 Agent 协同。

Steve：没错。接下来大家都会撞上一堵墙：merge（合并），现在几乎所有团队都卡在了这里。

我认为最有希望解决这个问题的公司是 Graphite，我打算找他们谈谈的。我和 Gene Kim 经常和大企业沟通，我是 SaaS 销售，所以能听到很多大公司的内部情况。他们认为，一旦每个开发者的生产力都提升 10 倍，代码合并就会变成一个极其复杂的问题。

比如你和我同时工作两三个小时，各自做了 3 万行代码的修改，我先合并了代码。我可能修改了日志系统、架构和你正在使用的 API，这时候你的代码就无法直接合并了。这不是简单修复合并冲突就能解决的，你得基于我的修改重新构思、重新实现你的功能，或者删掉你的代码，让我重新做。

但归根结底，这些代码都是 AI 写的。关键是，代码合并必须序列化，得排队。当轮到你的代码合并时，你必须在最新的代码基础上重新做一遍。现在还没有人解决这个问题，这是个巨大的障碍。有家公司给出的临时解决方案你知道是什么吗？一个代码仓库配一个工程师，我可没瞎编。

主持人：传统的解决方案是堆叠差异（stacked diffs），就是合并队列、堆叠差异吧？这是 Facebook 的概念，现在他们想推广到开源社区，GitHub 也在开发相关功能。目前还没有成熟的解决方案，但你必须意识到这个问题，并围绕它做设计。

Steve：当然也有老办法：硬着头皮解决。

主持人：或者提前沟通说，“我要做一个深度架构修改，让我先合并，我们先达成一致的整体方案”。

Steve：是的，我也遇到过几次这样的情况。我试过让一个智能体提醒另一个智能体“我在做会影响你的修改”，就像 Jeffrey 的 mail 工具做的事情。等我把这个功能打通，智能体之间就能互相沟通了，到时候它们只需提醒对方“那个智能体在做影响你的工作，你们最好先达成一致的基础架构方案”。智能体没有 ego，不会争着“必须听我的”，谁先做谁就当领导者。

主持人：你和 Jeffrey 有什么分歧吗？

Steve：我们在一个核心问题上有分歧，即在同一个仓库克隆中让 12 个智能体工作是否可行。我支持用工作树（多个分支）或者多个仓库克隆，把智能体隔离开。他则认为应该让所有智能体在同一个仓库、同一个构建环境下工作，比如一个智能体正在构建、运行测试，这会产生很多冲突。但他有文件预约系统，所以他说“这很疯狂”，但也说服我承认：如果是独立开发者，用不超过 12 到 20 个智能体，这种方式可能确实可行，毕竟他自己就是这么做的。

这和 Beads 的原理一样，放在以前根本行不通，在真正的工程师看来毫无道理，但你只需告诉 AI“出问题就自己修”，AI 真的会修。所以他的系统能运行，因为偶尔文件预约系统出问题时，智能体会说“我们需要解决这个冲突”，然后自己搞定。

主持人：有意思。有人提议明年峰会的主题定为“多智能体”。

Steve：我完全同意。AI 的未来一定是多 Agent。现在我们还处在“用镰刀收割玉米”的阶段，这就是现在“真正程序员”的工作方式。很明显，明年我们就要进入“机械化耕作”的阶段，就像现在农场里的大型机械一样，我们要“工厂化编程”了。很多人从哲学、道德、伦理层面坚决反对，他们习惯了“自给自足的小农经济”，不适应“大型 John Deere 拖拉机”（代表工业化）。但我们确实正在进入编程的“John Deere 时代”。

Claude Code、Amp、Codex 这些工具，我对它们都一样喜爱，但它们也都一样“危险”。我在演讲中说过，它们就像电锯、电钻，高手能用它们创造奇迹，也可能一不小心把脚锯掉。Claude Code 也是如此。

想象一下，有一台大型农业机械，会用 Claude Code，还能检查代码，把“规划、实现、评审、测试”这些环节都拆分自动化，这就是工厂化编程，现在已经有人在做了，必然会成为趋势。它已经开始让非程序员也能参与编程，这彻底颠覆了公司的运作模式。

公司开始意识到，理想的团队规模可能只有两三人，公司的运营方式、治理结构都要改变。因为编程不再是瓶颈，业务人员需要直接参与，反馈循环变得更快。

这是个非常激动人心的时代，但对很多人来说，冲击太大了，他们要么选择逃避，要么在网上强烈反弹。而我敢预测，随着这种能力不断增强、代码真正进入“工厂化生产”，来自既得利益群体的反弹，只会越来越猛烈。

永远不要重写代码？错了！

主持人：你是少数几个能以这种态度提出这个问题的人之一。我知道观众里有不少人对“彻底拥抱这种方式”是持保留态度的，所以这个问题我只能问你这样的人。很多人觉得，这些工具写写前端、应用层代码还行，但千万别碰云基础设施、别碰后端，更别说分布式微服务了。

Steve：有人说“绝对不要动任何生产环境的代码，只是在生产环境使用，且一定要以 Git 作为兜底采用这些工具。你会很想写点什么，但别写。”如果有 Git 做备份，为什么还要担心？

人们觉得 AI 不擅长后端代码。这就是很多人数学不好的问题（指缺乏长远眼光）。ChatGPT 3.5 写系统级代码的能力有多强？说实话，非常差。那是多久以前的事了？但很多人现在还停留在那个认知里。老实说，我认为这里的误解，根源在于一种非常基础的信念：大家觉得模型已经“不会再变聪明了”。

有意思的是，就算模型真的不再变聪明（当然事实并非如此）我们其实也已经跨过了那个关键门槛：就像人类已经发现了电，接下来要做的只是如何把它用起来。即便只用今天这些模型的能力，我们也完全可以走到“代码工厂化”那一步，而且会非常快。我们今年夏天之前就能做到。

但现实是，模型正在以极快的速度变聪明。所以现在有一种有趣的现象：你在为模型“将来才会具备的能力”打造工具，而等这些能力真正被模型“内化进大脑”之后，这些工具本身就不再需要了。

于是，这就形成了一场持续的军备竞赛，同时也是一场工具的持续“衰减”：你的工具负责填补模型暂时空白的能力，等模型自己足够强、能填上这个空白时，这个工具就完成了使命，然后你再转向填补下一个空白。所以现在的趋势就是：所有代码、所有工具都在快速迭代，最终都会变成一次性的消耗品。

主持人：这反而是好事，毕竟工具也更容易构建了。

Steve：没错。说到这，我得提一个人，Joel Spolsky。他二十年前在亚马逊做过一次演讲，至今仍然成立。当时他提出一个金科玉律：永远不要重写代码。但现在我们发现，对于越来越多的代码库来说，直接推倒重来，比修修补补要快得多，而且效果更好，大模型尤其擅长这件事。我最早的体感来自迁移单元测试，与其不断修，不如直接全删了让模型重写，反而一下就完成了。

我们正在进入这样一个世界：最快的方式，是直接写一套更好的新代码，来完成旧代码本来想做的事情。这感觉就像一切认知被颠倒了，但你必须接受这个新世界。

主持人：你说这些话很有说服力，因为你不是年轻人“空谈未来”，而是几乎什么都干过。

Steve：是的。我用汇编语言写了 5 年程序，写过操作系统，做过游戏开发，做过平台，做过广告系统。游戏编程会逼你理解一切。游戏编程教会了我很多，现在再看所谓的 agent loop，和游戏里的主循环、本质上是同一类系统，操作系统循环也是如此。我感觉自己一直在重复构建相同的设计，只是换了领域。

谷歌、Anthropic、OpenAI 内部都很乱

主持人：我想让你谈谈谷歌。我最难忘的一个记忆是，在你退休前，你说谷歌还没“开窍”，尤其是谷歌云，还说他们的弃用政策很糟糕。他们现在好转了吗？

Steve：没有。我和谷歌的人聊过，很多人说“这就是谷歌的风格”。但有趣的是，在执行层面，谷歌已经好转了。他们终于做了 15 年前就该做的事：让员工承担责任，而不是让工程师随心所欲。过去 20 年谷歌都是这样，因为他们在广告领域有垄断地位，有足够的资金补贴工程师“随心所欲”。但最终他们还是得成熟起来，做出正确的选择，这个过程很痛苦，失去了一些谷歌文化，也没那么有趣了，但现在执行效率很高。随着 Gemini 的推出，他们逐渐把重心转向 AI，现在开始看到回报了。他们可能会成为最大的赢家。

主持人：那你怎么看 Google、Anthropic、OpenAI 这些实验室的状态？

Steve：说实话，这三家公司内部现在都非常混乱。Anthropic 把混乱掩盖得最好，这是他们产品经理的功劳，值得点个赞。这并不是因为 Anthropic 自己搞砸了，而是因为在这么快的增长速度下，混乱是不可避免的。

他们接下来要给 Claude Code 一口气招一百多号人，真的是在疯狂扩张。而这还只是 Claude Code 这一块。你要知道，我当年在 Google 和 Amazon 都经历过那种“必须先做大”的阶段，那时候必然是混乱的、动荡的。人们不知道该找谁、该跟谁对接，所有事情都一团糟。但慢慢地，一切会被理顺、会稳定下来，他们也会走到那一步的。

OpenAI 现在也很混乱，甚至更明显。他们经历了很多核心成员的离职。你要说是不是比 GitHub 那种失去大部分资深管理层、连续几年完全动荡的状态还糟，我也不确定，但 OpenAI 现在确实挺混乱的。

至于 Google，我们刚跟一个人聊到，说即便是在 Jules 团队内部，想在公司里达成共识、把东西推起来还是非常难。原因很简单：它太割裂了，像是由无数个小型“单体帝国”组成的集合体，一个个小应用彼此不沟通，导致任何跨公司范围的事情都极难推进。

所以现在这三家，其实都面临执行层面的挑战。我个人觉得 Anthropic 目前可能稍微做得好一点点，但差距非常小，战况非常胶着。接下来就很有意思了，看看 Oracle、Meta，或者其他公司能不能追上来。

主持人：Meta 值得关注，他们明年必须搞个大的。

Steve：明年很可能会成为开源模型之年。一旦开源模型达到 Claude Sonnet 3.7 一个水平，你打开 Klein 之类的东西，就能得到一个体验，至少和三月份的 Claude Code 差不多。虽然不如现在，但已经“够用”了，而且还是在你本地的 M4 上免费跑，真正的免费。

从我听到的情况来看，现在前沿模型大概还有七个月的领先优势，而且这个差距正在逐步缩小。这意味着，明年夏天，开源模型可能就能达到 Gemini 3 的水平。所以明年很可能会出现一个转折点：工具必须在任务拆解、模型分配上做得好得多，知道什么时候该用大模型、什么时候用小模型，才能把成本优化做好。

主持人：我也站在批判者的角度来说，他们认为之所以收敛，是因为模型能力是在逼近上限，提升会越来越慢。

Steve：这不是个小问题，而是一个根本性问题：AI 智力的发展曲线是线性的、指数的，还是趋近于上限的？

我们从一些非常接近研究核心的人那里听到的说法是，过去三十年里，受摩尔定律影响，AI 的“聪明程度”大约每 18 个月翻四倍。他们认为训练数据大概还能支撑两个这样的周期。之后会发生什么没人知道，可能继续上升，可能下降，甚至人类历史直接结束也不是没可能。但两个周期意味着三年后，它们会聪明 16 倍。

说实话，我也不知道“聪明 16 倍”具体意味着什么。但我花了很长时间去想这个问题，我的结论是：它们会变得非常、非常、非常聪明，一定会深刻改变世界，好的坏的都会有。

主持人：那孩子们还要学编程吗？

Steve：应该学 Vibe Coding。

主持人：你始终有一个“逃生口”，你想看代码的时候随时可以看，只是大多数时候你不需要看。但你能看，这本身就是一道护栏。不过我的看法是，不管怎样，如果你还懂一点真正的编程，你会更有优势，因为你的 prompt 更好。

Steve：当说到会编程的时候，但不是学语法，而是你要以一种“语言无关”的方式理解：函数、类、对象、monad 之类的能力边界是什么。你不再关心代码怎么写，但你关心它是怎么工作的。这个层级，其实已经接近产品经理或架构师的思维方式了。

你必须站在那个层级思考，而且你要理解所有工程层面的东西。就像我之前提到的 Jeffrey，他是数学家，自学成工程师，他不一定写代码，但他掌握了所有关键概念，知道 Cassandra 是怎么工作的。所以，就算你不需要亲手写代码了，你仍然需要学习海量知识，才能在这个新世界里成为一个高效的工程师，因为你和机器交互的层级已经被整体抬高了。

主持人：你还有没有什么想吐槽、想补充的？

Steve：我感觉最近“八卦”传播的频率上升了。不是那种“八卦”，而是工程师不断发现新方法、用 agent 变得更高效的那种兴奋感。

比如，我刚知道一个东西叫 Code MCP 之类的。因为 agent 并不擅长直接调用 MCP 工具，它们在这方面几乎没训练，但它们非常擅长写代码。所以你告诉它：不要直接调用工具，写代码去调用工具，它反而做得好得多。这种“小技巧”现在正在不断被发现，特别疯狂。Anthropic 自己其实不是最早发现这个的，是 Claudeflare 先发现的，Anthropic 后来才说“对，你们说得对”。

这也是为什么我特别喜欢把注意力放在 AI 工程师身上。我的观点一直是：AI 工程师是最能把 大模型潜力榨出来的那群人。你几乎可以把 AI 工程师定义为：不是训练模型的人，而是把模型“用到极致”的人。

这有点像一种颠覆式路径：当研究模型、训练模型还是高层次的事情时，当一个“GPT 包装工”显得没什么地位，但随着时间推移，这些人反而开始真正提升生产力，积累真实的专业能力。就像 F1 车手未必会造车，但他们对“怎么把车开到极限”的理解，甚至可能比造车的人还深。

参考链接：

https://www.youtube.com/watch?v=zuJyJP517Uw