Vibe Coding，在不少专业开发者看来，几乎不值得认真讨论。不查看代码，不关心实现质量，AI 生成什么就先用什么，能运行即可。它更像一种“许愿式”开发：仅限个人使用也许无妨，一旦进入生产环境、服务于他人，就很难说是负责任的软件开发。
但最近出现了一个趋势：这种被嫌弃的外行做法，正在与专业开发者的 Agent 工程走向融合。
不久前，拥有 25 年编码经验的软件专家、Django 联合创始人 Simon Willison 谈到了这一现象。他此前将两者区分得很清楚：Vibe Coding 是完全不看代码的编程，适合个人工具，用在别人身上是“极其不负责任的”（grossly irresponsible）。Agentic Engineering 则是专业工程师在安全、可维护性、性能等约束下使用 AI，对每行代码负责。
他以为这两条线会一直保持距离。但现在，二者开始“重叠”了，远没有以前那么泾渭分明了。
原因现在的 Agent 写的代码，看起来越来越可靠，他开始发现自己不再逐行审查 AI 生成的代码，哪怕是生产环境里的代码。他把 AI 的输出当作“半黑盒”来用——就像信任公司里的另一个团队，你不会去读他们每一行代码，先拿来用，出了问题再去看他们的 Git 仓库，“不到万不得已不会去看”。
他把这叫做“偏差正常化”：AI 每次写对，都让他更容易在未来某个时刻盲目信任它。但他仍然感觉不太舒服，因为人要为自己的行为负责。
另一个问题是评估软件的方式变了。以前看到一个有上百次提交、完整 README 和测试的仓库，基本能确信作者投入了心血。现在他用 AI 半小时就能生成一个一模一样的。唯一可靠的检验标准变成了：是否有人真正使用过它。
这些思考出自他在 Heavybit 播客《High Leverage》的访谈。节目上线后，Hacker News 上多了八百多条评论，多数并不否认这一趋势，争议在于如何理解这种变化。
有评论非常尖锐，写道：“Vibe Coding 至少是诚实的，但 Agentic Coding 更像一套包装精致的骗局。”
所谓 Agent 工程，本质上是假定 LLM 是完美可靠的规则执行器，仿佛行业唯一的问题就是规则写得不够细。所以那些塞满几十个 memory、agent、skill 文件，并在其中写满一页又一页规则的论证的所谓 harness，同样完全站不住脚。只有那些没怎么接触过 LLM 或不懂其原理的人才会这么想。“但很多技术水平很高的人也陷进去了，这非常令人遗憾。”
也有评论给出了务实的区分标准。有人指出，区别在于流程的质量和严谨性。Vibe Coding 是一到几次尝试，冒烟测试，能用就一直用到出问题，适合低风险的个人项目。Agentic Engineering 则关注功能正确性、性能、基础设施、弹性、可维护性，采用多阶段流程，每个阶段有确定性质量门和对抗性评审。但也承认，这是个滑块，有时也会跳过部分评审，直接把工单提交到系统。
还有人很赞同 Simon 的“出了问题再看”的观点，他补充说，很多人是在一种“等它真成问题了再修”的心态里成长起来的。只是现在前沿模型把“出了问题”的时机推迟了。但代码库终会变成一层层你没有参与决策的碎片，而你不再亲手写代码，也就失去了那种“这样加东西会有很大张力”的本能反应。这是讨论中最敏锐的观察，被称为对代码的“本体感觉”——通过编写和重构，你能感知抽象泄漏和接缝错位。风险不在于 AI 写坏代码，而在于开发者丧失辨别坏代码的能力。
而造成这一切更根本的原因是，市场缺乏对高质量代码的奖励机制。
有评论指出，代码质量在 AI 出现之前就已经非常糟糕，大公司技术债务堆积如山。那些在 AI 时代之前阻碍高质量代码开发的激励机制，如今依然占据主导地位。未来，你仍然会被迫交付质量低劣的产品，就像过去一样。
但这是否意味着“软件作为一个行业已经死透了”？在播客中，主持人提到了一个正在流行的观点：既然 Claude 能写出跑得通的软件，软件公司的价值终将归零。Simon 的回答是：真正重要的不再是代码本身。代码正在贬值，但结构、接口和确定性数据层的价值反而在提升。Agent 带来的非确定性，恰恰让那些能够减少非确定性、提供稳定边界的东西变得更加珍贵。
至于 Willison 那份内疚与不安，他承认仍然存在，并未解决。
以下是完整的访谈翻译：
“AI 擅长编程”变得不容置疑
Joseph：我们现在正处于职业生涯中规模最大的一个炒作周期，你似乎总是能精准地定位在那些所谓的“涅槃论”思想领袖和另一端的“末日论者”之间。
Simon：中间其实有一个非常好的位置，但令人惊讶的是，很少有人站在那里。
Joseph：能不能请你快速分享一下你的“起源故事”？你是如何占据这个中间位置的？在 AI 时代开启之前，你的经历是怎样的？
Simon：我在 AI 领域的所有影响力都源于我的博客，而且我经常更新它。我还在像 2005 年博客鼎盛时期那样经营它，那是大家还没转向短视频、LinkedIn 或 TikTok 的时代。从 2002 年起我就开始记录关于 Web 开发、CSS 和 JavaScript 的内容，后来是 Python。职业生涯早期我还参与共同创建了 Django 框架，所以博客里很多都是 Django 相关的干货。
大约三年前，Stable Diffusion 成了我进入 AI 领域的契机。我和 Andy Baio 合作，深入挖掘了 Stable Diffusion 的训练数据，结果发现他们从新闻网站、Pinterest 等地方抓取了大量内容。我们觉得这件事很有趣，公众应该知道这些模型是在未经授权的抓取数据上训练的。于是我们写了几篇文章，还做了一个探索工具让大家能看清训练集的构成。
大概两个月后，ChatGPT 问世了。其实在 ChatGPT 之前，我已经玩了一年半的 GPT-3，当时我就觉得这技术很牛，但很难让别人也感兴趣。因为 GPT-3 的交互是文本补全模式，你得输入一段特定的提示词，比如“一个能执行 XYZ 功能的 JavaScript 函数是：”，然后它才给你补全。这种交互方式太怪了，不符合大多数人的思维直觉。而 ChatGPT 说白了就是给 GPT-3 套了一个 Chat Interface。这个小小的 UI Hack 彻底打开了局面，因为一旦人们能用对话的方式进行交流，它的能力就变得显而易见了。
我正好是在对的时间出现在了对的地方，手里已经攒了不少关于 GPT-3 的素材。之后我就是顺势而为，持续追踪新出的模型。我还搞了个被某些人当真、但我自己完全是当乐子的 Pelican Riding a Bicycle（鹈鹕骑自行车）测试基准。此外，我每年会做一次 LLM 年度盘点，还有月刊和周报。现在的挑战在于，每天都有没完没了的新鲜事儿，我得在精力被分散之前挤出时间干点正事，比如 Mistral Medium 3.5 两小时前刚发布。
Joseph：原本咱们上周就要录这一期，结果因为网络故障推迟了几天。就在这短短四五天里，Poolside 模型发布了，DeepSeek v4 也出来了，迭代速度简直不可思议。你去年底的那篇年度回顾里，对软件开发以及 AI 在其中的应用似乎有一些非常深刻的思考。
Simon：去年是“AI 擅长编程”变得不容置疑的一年。在 2024 年底，你可能还会辩解说 AI 写的代码 Bug 太多，搞不好会拖慢进度，但现在这种论调已经过时了。
Anthropic 和 OpenAI 在 2025 年投入了海量资源进行代码训练。Claude Code 去年二月发布后，大家很快意识到：如果你想让用户每月掏 200 美元，代码就是他们愿意买单的核心。到了十一月，Claude Opus 4.5 和 GPT 5.1 几乎同时发布，那是一个临界点，Coding Agents 变得真正可靠了。
在那之前，这类工具还处于一种时灵时不灵的状态。但从十一月开始，Agent 变成了你可以信赖的长期合伙人，你有 90% 的把握确定它生成的代码是能跑通的。现在它们已经成了很多人的 Daily Driver（日常工具），很多同行甚至说他们 70% 到 80% 的代码都是 Agent 写的。如果是一年前，说这种话会被人笑死，但现在这已经成了理所当然的常态。
Joseph：Claude Code 发布才一年多，交互范式已经从基于 IDE 的自动补全进化了。以前我们觉得“这只是意味着我不用写 for 循环或查找函数定义了”，而现在的模型，我可以给它更高层级的指令。
我们的一家投资组合公司 exe.dev（一种新型云平台），我在圣诞假期用了他们的 Agent，连着两三周一直在往一个小 Demo 里加功能。结果我突然意识到，我竟然一次都没看过这玩意儿生成的代码，但它居然一直运行得好好的。
Simon：你甚至都没意识到这一点，因为我们已经习惯了“它们写代码，代码能跑，偶尔我们会看一眼”的模式，其中的经济学原理很迷人。以前你想做一个东西，得交给工程团队，等上两到四周才能见到雏形，现在变成了两到四小时。
Vibe Coding 和 Agentic Engineering 已经开始融合
Joseph：既然这种可靠性已经成了某种 primitive（原生能力），那我们到底能走多远？通往未来的新实践和新原则又是什么？我特别欣赏你的一点是，你试图区分 Vibe Coding 和 Agentic Engineering 这两个概念。
Simon：奇怪的是，这两件事情对我来说已经开始变得模糊不清了。
Vibe Coding 是那种你完全不看代码，甚至可能根本不懂编程，只要它跑通了就行；如果不通，就祈祷再试一次能行，你不会在意代码质量或维护性。Vibe Coding 在个人工具层面非常棒，出了 Bug 也就是坑你自己；但如果你是给别人写软件，还搞 Vibe Coding 就是极度不负责任，因为别人的数据和利益会因为你的低级 Bug 受损。
相比之下，Agentic Engineering 是专业软件工程师的打法。你理解安全、可维护性、运维和性能，依靠自己 25 年工程经验，利用这些工具把挑战的规模拉大，目标是构建更高质量的生产系统。如果用 AI 只是为了更快地制造低质量的垃圾，那我认为是退步。
但问题是，随着 Coding Agent 越来越可靠，我也开始不再 Review 每一行代码了。比如让 Claude Code 写一个 SQL 查询并输出 JSON 的 API 端点，我知道它肯定能搞定。我会让它加测试、加文档，生成的代码质量很高，但我确实没去审。这让我产生了一种负罪感：如果不 Review，我把它用在生产环境真的负责任吗？
后来我想通了：这就像我在大厂当 Engineering Manager 的时候，我信任其他团队交付的模块。比如人家给了一个缩略图服务，我只要看好文档、确认功能正常就会接入。除非出了 Bug 或是性能拉胯，否则我不会去翻人家的源码。我开始把 Agent 当作一个半黑盒的合作伙伴，虽然 Claude Code 没有像人类那样的“职业信誉”来提供信用背书，无法为自己的行为负责，但它一次又一次地证明了自己——不断地生产出简单明了的产品，而且是以我喜欢的风格把事情做好。
Joseph：而且挺逗的是，我发现模型非常乐意为你指出的错误“承担责任”。当你问它：“等一下，你刚才是不是干了那档子事？”它会立马滑跪：“噢，真的很抱歉，我确实刚干了那事”
Simon：没错，但这态度对我来说毫无意义。况且现在 Claude 4.7 已经出来了，我好不容易才跟 4.6 建立起了一点信任，结果新模型又来了，我得花多长时间才能确信它不会犯一些我预料之外的低级错误？
Joseph：在一个大规模的人类工程团队里，总会有那么几行“承重墙”级别的核心代码（Load bearing code）。但说实话，到底有多少人真的仔细看过那段代码？可能最初是一个人写的，另一个人在 PR 里草草点了个赞同就合入发布了，可能现在这两个人都不在公司干了。
Simon：这也是我在做 Side Projects 时的困惑，甚至整个行业都在面临这个问题。以前如果你在 GitHub 上看到一个仓库，有一百多次提交、一份精美的 Readme 还有完善的自动化测试，你基本可以确定作者投入了巨大的心血。但现在，我半小时内就能敲出一个同样有一百多次提交、文档漂亮、测试覆盖每一行代码的仓库。它看起来和那些呕心沥血的作品一模一样，甚至质量可能真的同样出色。但我看不出来，甚至对我自己用 AI 生成的项目，我也没法一眼分辨。
所以我意识到，相比于测试质量或文档，我更看重“是否有人真的用过它”。如果你 Vibe Coding 出了一个东西，并且在过去两周里每天都在用它，那这玩意的价值对我来说，远高于一个你刚随口说的、甚至都没怎么跑过的代码。
Joseph：你刚才提到了一点，在 Opus 和 Codex 那个关键时刻到来前，Vibe Coding 和 Agentic Engineering 之间还有一个清晰的准则：只要是重要的活儿，人类必须介入 Review 并把关。但我最近也有一种和你一样的顿悟：这些工具已经好到一定程度了，如果还要求每一行代码进入生产系统前都要经过人工 Review，这在逻辑上已经快说不通了。
Simon：但你刚才用的“承重墙”这个词非常关键，任何安全相关的代码，我一定会亲自 Review。把安全责任完全外包给 Agent 是极其不负责任的，而判断哪些代码涉及安全、哪些不涉及，这种直觉需要深厚的工程经验积累。
人类审查成为软件开发新的瓶颈
Joseph：如果换个视角看软件开发史，它其实就是一个不断“消除瓶颈”的过程。云计算最重要的价值（除了财务上的成本转换）在于，工程师不用再坐等另一个大楼里的人去机架上插服务器，才能部署代码。现在一个 API 调用，服务器就到位了。这消除了一个大瓶颈，从而引发了过去二十年开发者生产力工具的大爆发，因为现在的瓶颈变成了“人类开发者的动作有多快”，而不是网络架构师什么时候有空给你开个防火墙端口。
到了去年底，尽管自动补全和 Cursor 这类工具很火，但人类的 Review 依然是开发到生产之间的那个“瓶颈网关”。如果我们把这个瓶颈也移除了，下游的所有流程是不是都会崩溃，或者需要推倒重来？
Simon：百分之百。这里核心的问题是：如果你能从每天写 200 行代码进化到每天写 2000 行，还有什么会坏掉？事实证明，整个软件开发生命周期（SDLC）都是围绕着“一天只能写几百行代码”这个前提设计的，现在这个前提不存在了。
这不仅影响下游，也波及上游。我看到 Anthropic 的设计负责人 Jenny Wen 做过一次很棒的分享。她说，传统的 UI/UX 设计流程是为了确保“一次性做对”，因为如果设计错了，交给工程师花三个月做出来才发现不行，那是灾难性的，所以我们才会有那么多繁琐的设计评审。但如果构建一个东西不需要三个月，那么设计流程或许可以承担更大的风险，因为做错的代价已经被极大降低了。
Joseph：这其实也适用于产品管理。以前之所以强调精细的 Specification 和深度思考，是因为工程师做错东西的成本太高了。
说回 Vibe Coding 在专业开发中的角色，这让我想起 Extreme Programming（极限编程）里的一个术语叫 Spikes（探针测试/尖峰开发），你熟悉吗？
Simon：我超爱 Spikes。
Joseph：给年轻听众解释一下：以前人类写代码时，如果你有个理论想验证，你会花两天时间（这对人类开发者来说是很小的一笔支出）做个 Spike，撤掉所有防撞墙，不写测试，直接硬攒一个原型出来，看看手感对不对。现在有了 Vibe Coding，你一小时能做 10 个不同的 Spikes，而且你甚至不需要是工程师就能完成。
Simon：这就引出了“并行 Agent”（Parallel Agents）的概念——同时运行多个 Coding Agent。去年我觉得这纯属胡闹，因为如果你要 Review 代码，同时开五个 Agent 简直是灾难。但现在我开始这么干了，尤其是在做 Spikes 的时候。
我可以一边让网页版的 Claude Code 跑一个 Spike 去探索方案 A，同时让 Codex 在这边跑方案 B，而我本人则在处理其他真正的工作。虽然 Review 这些 Spikes 的产出依然有很大的认知负荷（Cognitive load），但这确实意味着只要我有一个随机的灵感，我就可以立刻让 AI 去打个样，看看行不行得通。
Joseph：软件开发历史上一直推崇“深度聚焦”和“流状态”，我也一直是这一派的信徒。在我的第一个初创公司里，我认为给开发者一个带门的独立房间让他们专注是非常重要的。
Simon：有那种“如果你打断一个程序员只为了问个小问题，他得花 15 分钟到一小时才能重新找回状态”的理论，因为他得把所有逻辑重新加载回大脑里。
Joseph：这种专注的状态，和你同时开五个 Agent 干活儿的时候相比，是什么感觉？
Simon：没有可比性。我现在甚至能边遛狗边写代码，我会打开 ChatGPT 的语音模式，告诉它写段 Python，然后趁着遛狗的功夫跟它来回对需求。甚至在做晚饭的时候也能写不少代码，笔记本就搁在一边，我每隔五分钟跑过去敲个 Prompt，然后接着回去切菜。
比起以前，我现在进入“可被打断”状态的门槛低了太多。我花了多年时间建立自己的“抗干扰机制”，，把所有工作都记录在 GitHub Issue 的评论里。我会不断写下“下一步准备干嘛”，这样一旦被打断，我只要翻翻这些像“工程师实验笔记”一样的评论，就能快速找回状态。
但现在我完全不这么干了。当你手敲一百行代码时，那种深度沉浸、脑子里装满逻辑的能力至关重要；但当你只是在给模型下达下一个架构方向的指令时，这种负担就轻多了。我以前从没想过能同时推进两三个项目，但现在轻而易举。而且项目越难，反而越容易并行——因为你可以给一个 Agent 发个指令，让它花 10 分钟去构建下一个模块，而这 10 分钟你可以心安理得地去处理别的事情，这种工作方式真的非常诡异。
AI 时代的“结对编程”
Joseph：我做投资八年了，在此之前，我有 25 年的技术背景，拿了计算机科学博士（虽然退学了），写了很多代码。我发现这种背景在使用这些工具时非常有帮助，体现在我能与它们进行的对话深度以及我能指引的方向上。你觉得对于未来的成功使用，对底层技术的理解到底有多重要？
Simon：这真是个灵魂拷问。因为我有 25 年的写代码经验，很多东西已经刻在骨子里了。但当我回头看我跟 Agent 的对话记录时，我很清楚这些对话对绝大多数人来说简直就像是“外星语言”。但我并不担心软件工程师的职业生涯会因为电脑能写代码就终结，其中一个原因就是：这些工具其实是现有经验的放大器。如果你知道自己在做什么，它们能让你跑得飞快。
AI 对新人同样非常有帮助。我想起以前带新人，头六个月简直是人间炼狱：你要配开发环境，这玩意儿随时会崩；漏个分号就会报一堆莫名其妙的错，你可能得花半小时去死磕。最理想的情况是身边坐个老司机，指着屏幕说“这儿缺个分号”，但大多数人没这条件。现在这个问题解决了：报错了就往 ChatGPT 里一贴，它每次都能给你答案。所以那种“由于死磕分号而导致五小时没进展”的挫败感被磨平了。以前很多人觉得自己不够聪明学不会编程，其实根本不是，只是没人告诉他们，在感受到编程的乐趣前，得先经历六个月枯燥透顶的磨练。
现在这些原本会放弃的人都在学编程。我见过很多人热衷于从 Vibe Coding 入门，在这个过程中他们得到了即时反馈，学到了知识。现在悬而未决的问题是：三年后，这些“氛围程序员”是会进化成能构建生产系统的工程师，还是停留在只会搓点没有长期价值的小玩意儿的阶段？我想三年内我们就能见分晓。
Joseph：即便这半年技术突飞猛进，我依然认为人类有其不可替代的角色。把视角拉远，软件工程师的本质角色其实一直是：坐在那堆混乱、模糊且不断变化的业务需求和硅片上那些确定性的逻辑之间，充当翻译官。
Simon：而且这活儿永远不会变简单。每当我用这些工具时，我都在感叹：写软件真是一件极其困难的事情。就算你把全世界最好的 AI 工具都给我，我们想要达到的那个目标依然极具挑战。
Joseph：未来的挑战在于当涉及安全等核心领域时，依然需要深入理解代码细节的能力。我圈子里有很多像你一样资深的工程师，有些人会有职业危机感：“我干了一辈子，现在这算怎么回事？”我的看法是，“原子能时代之前的钢铁”（pre-atomic steel）。虽然我们会找到训练和指导新人的新模式，但我认为那些模式可能最终都比不上“在 AI 出现之前就已经干了 25 年”所积累的底蕴。
Simon：如果五年后，唯一管用的程序员还是那帮有 20 年“前 AI 经验”的老家伙，那这个行业就完蛋了，那绝对不是什么好局面。
Joseph：最近 Scott Hanselman 上了我们节目，他和同事在 ACM 刊物上写了一篇很有意思的文章，探讨了新的导师制模型以及如何提升初级工程师的技能。其中提到一点：像 Claude Code 这样的工具应该有一个模式，让 AI 回到“结对编程”的逻辑中去，就像以前说的“驾驶员”（Driver）与“领航员”的概念。
你跟 Claude 说，咱们得给这 App 加个功能，Claude 会说：“没问题，我知道怎么弄。咱们分三步走……”甚至在修 Bug 时也是。但重点是，由你来负责敲键盘。这种训练模式能让你既不用跑三个工位去求助老司机找分号，又必须亲自经历那种“动手写”的过程。
Simon：结对编程最棒的一点就是有人帮你查资料，比如你问“某某功能的正则语法怎么写”，当你敲代码时，他在旁边查，而模型干这事儿简直无懈可击。
评论员 Matthew Yglesias 昨天发了条推特，大意是说：“玩了五个月 AI，我决定不搞什么 Vibe Coding 了。我想要的是那些专业的软件公司，利用 AI 系统开发出更多、更好、更便宜的软件产品，然后卖给我。”我觉得这话说得很到位。如果看足够多的 YouTube 视频，我确实能自己修家里的水管，但我还是更愿意雇个专业的管道工。
Joseph：这是我最近经常参与“激辩”的一个领域，现在有很多聪明人的结论是：“既然 Claude 能写出跑得通的软件，那‘软件’作为一个行业基本上就死透了。”现在的公开市场，软件类的估值倍数被锤得很惨，大家似乎都默认这些公司的价值终将归零。
但从几个维度来看，我总觉得这逻辑不通。首先，换回我以前做 CTO 的思维：如果在生成软件的系统中增加了“非确定性”，那么在系统的其他任何地方，凡是能减少非确定性、增加确定性的东西，价值反而会提升。所以，我给 Agent 提供的底层工具层级越高越好。就像你刚才说的图像生成的例子：我难道要让 Agent 从零开始写个数据库吗？不，我应该给它一个稳定的 API。
真正重要的，不再是代码本身
Simon：我最近一直在想，如果我现在要从头做一个 Issue Tracker（问题追踪器），比如仿照 GitHub Issues 或者 Linear，我会怎么做？我会投入全部精力去设计一个极佳的核心数据库 Schema，把 Issue、评论、标签、里程碑这些关系的逻辑打磨得极其扎实。然后，我把这个模式转化成一套极其稳健的 API。
至于上面的 UI，我完全可以用 Vibe Code 去搓。甚至我可以把这个能力开放给客户，让他们说：“我需要一个带特殊过滤功能的看板。”没问题，随便你怎么搓 UI，但底层数据必须写入那个确定的、稳定的、定义严谨且备份良好的 API 和数据模型里。
只要你把数据模型做对了，用户可以拥有无限的自定义灵活性，而不用承担那种“因为 Vibe 出来的数据库模式太烂，导致数据最后全乱套了”的风险。
Joseph：我觉得 Agentic Engineering 应该能开启一个新的软件光谱。在历史上，有一大块“可能的软件”其实是因为经济上不划算，所以从未被开发出来。
Simon：比如你想给镇上的小肉铺开发一套定制软件，在过去，这个市场太小了，根本支撑不起程序员的开发成本。
Joseph：以前哪怕做一个最简单的东西，也要两三周的开发时间，保守估计就是几万美元；后续每年的维护成本还得十几万美元，肉铺哪有这种利润率？
所以当我听到有人说“软件已死，以后大家都自己搓工具”时，我听到的其实是另一种潜台词：过去人们很沮丧，因为一个平台想要活下来，唯一的经济手段就是做得足够“通用（Horizontal）”，横跨足够多的行业，这样潜在市场（TAM）才够大。但我也相信，企业之所以购买软件，是为了得到深思熟虑的、内聚的、安全的数据层。
Simon：我想到我之前说的——我只想用那些“开发者自己已经用了几周”的小项目。它的企业版表述就是：除非至少有两家大企业已经成功使用某个 CRM 系统半年，否则我绝不会买。这其实是同一种心态，在承担风险前，你想要的是经过验证的方案。
“AI 反弹”背后的真实情绪
Joseph：我想起昨晚在《The Verge》上读到的一篇 Nilay Patel 的文章，标题是《人类并不渴望自动化》（The People Do Not Yearn for Automation）。
Simon：简直是诗，那是我见过的关于“AI 反弹”浪潮中最好的评论。如果你去调查大众对 AI 的看法，支持率正在崩塌。Nilay 甚至提到，AI 现在的受欢迎程度可能还不如 ICE（美国移民海关执法局）。
Joseph：负面得惊人，在某些调查里，支持率甚至跌破了 20%。
Simon：尤其是在 Z 世代里，最常使用它的人反而最讨厌它。Nilay 的核心观点是：我们这些搞软件的人会为了“自动化一切”而兴奋，但这套逻辑对普通人行不通。就像智能家居除了在极客圈，始终没能在大众市场爆发，因为大多数人并不觉得“拍拍手就能关窗帘”有什么好激动的，这不符合主流人类的兴奋点。
Joseph：我最近在给 Claude 调教一些技能，让它在几个 CRM 工具上跑 RPA（机器人流程自动化）。做着做着我突然意识到，这跟我几十年前写复杂的 Shell 脚本一模一样：我得考虑各种边界情况、我要处理什么、我要规避什么……而所谓的“正常人”根本不会这么思考，不是因为他们没能力，而是因为他们生活里根本不需要这种思维。
Simon：这是一种需要多年培养的习惯：敏锐地察觉生活中的小摩擦，然后动手修好它。一旦你学会了，你就再也无法容忍任何可以被自动化的冗余。但大多数人生活里没时间搞这些，他们有太多别的事情要忙。
Joseph：大多数人对 AI 的感知其实就是“搜索”。一个更好用的搜索：我有个问题，你从语料库里或者实时搜索中帮我总结、去重，然后按我的视角呈现出来，但这和“坐下来通过 AI 自动化工作”完全是两码事。
Simon：而且现在的舆论氛围也很吓人，全是“这玩意儿太危险了，会毁灭世界，代码会被黑，大家都会失业”。AI 现在的形象公关确实做得一塌糊涂。
Joseph：大厂的人确实该认真对待这个形象危机了。
Simon：现在针对 AI 数据中心的抵制，本质上就是大家对 AI 的厌恶。人们在想：生活中有什么东西是我可以站出来反对，以此来宣泄对这股浪潮的不满？于是那些耗电惊人的巨大建筑物就成了靶子，数据中心成了 AI 在物理世界的化身。
算力成本博弈：涨价与中国模型的冲击
Joseph：你之前提到，现在的分水岭时刻是因为一年半前，基础模型实验室决定把“代码能力”作为核心。
Simon：OpenAI 和 Anthropic 在 2025 年把几乎所有的算力预算都砸在了“针对模拟软件环境的强化学习”上，他们开启了数万台带 Python 解释器的虚拟机，生成代码，跑一遍，看结果：跑通了就点赞，崩了就差评。有些中国实验室也这么干，比如 Qwen 的论文里就提到过动用一万台虚拟机做这件事。
我认为 xAI 和 Gemini 稍微落后一点的原因，就是因为他们没能在 2025 年整年都在代码强化学习的闭环里狂奔。现在这两家公司都在翻倍投入代码能力，但在我看来，他们已经错过了追赶的黄金 12 个月。
Joseph：而且生成软件这件事很特别，虽然强化学习理论上可以应用在很多领域，但代码编写拥有极其干净、明确的奖励信号。
Simon：简直是天作之合。代码跑通了吗？是或否。这非常明确。你对比一下律师行业，如果你想对法律条文做强化学习，你得把 AI 生成的文本投放到法庭上，看几个月后法官和陪审团是否认可。这种反馈周期长达半年，显然不像跑个 Python 脚本那么简单直接。
Joseph：在 ChatGPT 刚火的时候，很多“激进派”预言律师或类似职业会消失。我个人觉得没有任何职业会彻底消失，不过翻译行业确实处境艰难。
Simon：数据录入（Data entry）也是个非常危险的领域。
Joseph：有趣的是，软件工程反而是最容易因为这些技术而发生巨变、甚至是被“颠覆”的行业。
你提到了 Qwen。还有一些其他的模型，比如 Kimi（Cursor 的 Composer 模式据说就基于此）。还有你提到的 Poolside，就在我们录制节目的昨天，他们刚刚发布了开源权重的编程模型。
Simon：过去一年半我一直在密切关注中国的 AI 实验室，因为他们真的出了不少好东西。目前至少有五家极具竞争力的中国实验室，他们出的模型只比头部的闭源模型落后三到六个月，这成就非常了不起。
而且有些模型直接能在我电脑上跑。目前我最喜欢的本地模型是 Qwen 3.6-27B，它只需要大约 20GB 内存，在配置不错的笔记本上就能跑得飞快。它的能力感觉和半年前甚至一年前的头部闭源模型旗鼓相当。我以前觉得要运行这种级别的模型得买价值 5 万美元的服务器 GPU，现在居然能塞进我的 MacBook Pro？这简直不可思议。
Joseph：长期来看，尤其是在企业级软件和计算领域，我们必然会进入一个“混合模型（Mixed models）”的多模态世界。企业会根据不同的任务切换模型：这个活儿用基础模型，那个活儿用私有化的开源模型，从而在数据来源和成本之间寻找平衡。你认同吗？
Simon：我觉得现在最大的问题是，如果你把自己完全绑定在一个模型供应商身上，万一另一家突然发现了一个让性能暴涨的新技巧怎么办？不过目前的现实是，供应商们都在互相追赶。Anthropic、OpenAI 和 Gemini 一直在玩“跳马”游戏。Gemini 之前因为不够重视代码稍微掉队了，但他们现在正倾尽所有资源补课。我敢打赌到今年底，Gemini 的代码能力会追上另外两家。
所以核心问题变成了数据安全性（Data provenance）。你选本地模型是为了避免把数据传到云端 API 吗？大多数情况下，我觉得这是一种“伪优化”，甚至是某种被害妄想。如果你和 Anthropic 签了协议，明确他们不能拿你的数据去训练，你是可以信任这种商业协议的。当然，我经常和记者合作，他们的情况比较特殊：为了保护信源，他们必须防止政府通过调取数据中心记录来追查信源。这种情况下，本地模型就有非常现实的必要性。
我个人对本地模型的兴趣也是起伏不定的，一年前我完全失去了兴趣，因为本地模型太弱了，跟云端大模型比起来就像小孩子玩具。但在过去的六个月里，情况变了。我现在在笔记本上跑的模型已经能处理真正的业务逻辑了。
不过，所谓的“干正事”现在已经演变成了：把一个极其复杂的架构问题丢给 Claude Opus 4.7，让它自己推演 10 分钟。这种能力本地模型目前还做不到。所以我对这个问题的态度一直在反复。但有一点是肯定的：在现阶段把自己锁死在单一模型里是非常短视的。
顺便一提，我自己在 Python 里写了一层抽象层，做了一个开源库来调用不同的模型。
Joseph：你目前是怎么构建自己的工具链来兼容不同模型的？
Simon：我有个自己写的工具叫 LLM，它既是命令行工具也是 Python 包，通过插件系统可以调用 DeepSeek、Mistral 等各种模型。去年我用得很凶，但今年用得少了，因为 Claude Code 和 OpenAI Codex 太强了。我现在笔记本上大部分活儿都直接走这两个通道。不过你不能直接把这两个强大的 Agent 插到本地模型上，因为它们有长达两万 Token 的 System Prompts，本地模型根本处理不了这么复杂的操作指令。
我最近在玩 Pi，这是一个更轻量级的开源代码 Agent。晚些时候我会给我的工具做一个大更新，让它能更好地适配推理模型。另外我也在关注 OpenClaw。虽然我不完全信任它，但我觉得现在 AI 圈的“Hello World”就是亲手撸一个自己的 OpenClaw。我也在基于我自己的 LLM 框架开发属于我的“Claw”。
不过我目前的 Daily Driver，一周前是 Claude Code，现在主要是 OpenAI Codex。Codex 的最新版本表现非常出色，而且说实话，我不怎么信任 Anthropic 关于 Claude Code 的定价策略，他们最近一直在那儿变来变去的。
Joseph：Claude Code 的定价，不管是 AB 测试还是什么，关于 Pro 用户是否还能免费用它的争议挺大。还有 GitHub Copilot 好像也有动作？
Simon：GitHub Copilot 和 Windsurf 之前都是“按次计费”，不管你的 Prompt 触发了多少次工具调用，价格都一样。这在一年前还行得通，但现在行不通了，因为一个 Prompt 可能会让 Agent 跑上 10 分钟，所以现在大家全都转回了按 Token 计费的老路。
Joseph：过去几年 AI 圈给人的感觉很像早期的 Uber 时代：你可以花 3 美元就打到一辆高级黑车跨越整个旧金山，因为背后全是补贴。
Simon：我觉得现在有两股力量在角力。一方面，因为代码 Agent 的出现，重度用户消耗的 Token 数量是以前的 100 倍。如果你重度使用 Claude Code，你烧掉的算力远超去年的 ChatGPT，这直接导致了调价。
但另一方面，开源权重模型（尤其是中国的模型）在把价格往相反的方向拽。DeepSeek 比 Claude Opus 便宜 20 倍，但它的跑分表现可没比 Opus 弱 20 倍。你可以用他们的 API，也可以在自己的硬件上跑。
希望这些开源模型形成的力量能抵消掉那些急着 IPO 的公司想要赚取实际利润的冲动。但目前在定价方面，确实泡沫感很强。
Joseph：我认为涨价的时间点不是偶然的。去年年底，这些能让你在软件工程上大展拳脚的新模型发布了。现在是 2026 年 4 月，正好做完 Q1 季报。估计各公司的财务团队刚看完今年第一季度的 Token 账单，全都会惊掉下巴：“等等，这数字是怎么回事？”
Simon：光本周我们就迎来了两次大幅涨价。Opus 4.7 虽然单价没变，但分词器变了，处理同样内容的 Token 数多了 40%，相当于变相涨价。而 GPT 5.5 在 API 上的价格直接比 5.4 翻了一倍。这是我追踪价格以来波动最剧烈的一次。
Joseph：今年会是一个转折点。有远见的企业会意识到这些工具是未来，但他们必须开始计算投入产出比了，我们已经过完了“预算无上限”的蜜月期。通常新技术都要靠工程师苦苦哀求才能要到一点经费，但 AI 过去几年完全是反过来的。
Simon：唯一确定的是，以后不能再搞那种“Token 消耗排行榜”了。如果你不想让预算见底，千万别鼓励这种浪费。
Joseph：我第一次在媒体上看到有公司搞这种“Token 消耗王”排行榜时，就想这老板肯定从没试过给人类工程师定过可被“刷榜”的考核指标，他们即将学到极其昂贵的一课。
访谈原链接：
