夜雨聆风想象一下，一位顶级的软件工程师，每天能提交 10 到 30 个 Pull Request（代码合并请求），但他从去年 11 月起就没有亲手写过一行代码了 。这听起来像是科幻小说，但这正是 Anthropic Claude Code 负责人 Boris Cherny 的真实日常 。
在近期的一场深度访谈中，Boris 揭示了一个令人震惊的事实：AI已经不再仅仅是“代码助手”，它正在实质性地接管软件构建的全流程。这不仅将深刻改变程序员的命运，也将重塑每一个现代职场人的工作方式 。
💡 核心看点速览
• 颠覆性的生产力飞跃：Anthropic 内部工程师的生产力跃升了 200%，AI 正在全自动处理 Bug 修复和代码审查 。 • 从“对话”到“行动”的跨越：真正的 Agent（智能体）能够自主使用终端、浏览器和办公软件，打破了以往“聊天机器人”的局限 。 • “潜藏需求”驱动爆款产品：观察非技术用户如何“硬核”地滥用你的产品，是发现下一个千万级功能的最强信号 。 • 降维打击的开发逻辑：永远不要局限于当下的模型能力，要为 6 个月后的 AI 模型设计产品架构 。
编程的终局：当人类不再手写代码
如果你还在纠结“是否应该学编程”，现实的数据可能会让你清醒。根据近期的一份报告，目前全球公共 GitHub 仓库中，有高达 4% 的代码提交（Commits）是由 Claude Code自动生成的，并且这一比例还在呈指数级加速增长 。
在 Anthropic 内部，Claude Code 审查了 100% 的代码拉取请求（Pull Requests） 。随着 AI 承担了几乎所有的基础代码编写工作，工程团队扩充了4倍，而人均生产力（以 PR数量衡量）更是直接飙升了 200% 。以前几十名工程师花一年时间才能提高个位数的效率，现在 AI 直接带来了百倍级别的震撼 。
“到今年年底，每个人的头衔都会变成‘产品经理’，每个人都能编程。软件工程师这个头衔将开始消失，取而代之的是‘构建者(Builder)’。” (i think by the end of the year everyone's going to be a product manager and everyone codes the title software engineer is going to start to go away it's just going to be replaced by builder)
Boris 认为，“编程（Coding）”本身在很大程度上已经被解决了 。下一个核心瓶颈已经不再是“如何构建代码”，而是“我们需要构建什么” 。AI甚至开始介入产品决策环节，通过阅读用户反馈、Bug 报告和系统遥测数据，主动提出新功能的开发建议 。
从辅助到行动：真正的 Agent（智能体）时代降临
大多数人对 AI 的理解还停留在 ChatGPT 这样的“对话式 AI”层面。但 Boris 指出，接下来的大趋势是向具有行动力的 Agent（智能体）转移 。
Anthropic 的发展路径非常清晰：先让模型精通编程，再精通工具使用，最后精通计算机全局操作 。真正的 Agent不是一个只能聊天的盒子，而是一个能主动采取行动的数字员工。最近引发轰动的 Co-work 项目，正是这一理念的集中体现。开发团队仅用了 10 天时间，就依靠 Claude Code 写出了Co-work 的全部代码（包括底层复杂的虚拟机安全系统） 。
“编程在很大程度上已经被解决了，至少对于我所从事的这种编程来说，它只是一个已解决的问题，因为Claude能做它……所以现在我们开始思考，好的，接下来是什么，超越这些之后是什么。”
现在，Boris 将日程管理、回复 Slack 消息、支付停车罚单、甚至取消订阅服务等琐事，全部交给了并发运行的多个 AI Agent 来处理 。对于非技术岗位的职场人（如产品经理、设计师、数据科学家），这将是极其巨大的赋能 。
打造 AI 爆款产品的核心心法
为什么 Claude Code 和 Co-work 能取得如此不可思议的增长？Boris 分享了 Anthropic 内部打造产品的几个反直觉心法：
1. 追踪“潜藏需求（Latent Demand）”产品最好的迭代方向，往往隐藏在用户对产品的“滥用”中。团队曾震惊地发现，一位完全不懂技术的数据科学家，为了用 AI 处理 SQL 数据，竟然硬着头皮学会了安装 Node.js并在极客专属的终端命令行中运行 Claude Code 。这种用户为了达成目的“不择手段”跳过重重障碍的行为，直接促使团队在桌面端内置了门槛更低的 Co-work 。 2. “资金不足”反而带来奇效在项目初期，给团队配备极少的人手（甚至只有一名工程师），反而能逼迫他们极度依赖 AI 来实现自动化 。与其在早期精打细算控制 API 成本，不如给工程师发放“无限Token”，让他们最大程度试探 AI 的极限，跑通后再考虑优化成本 。 3. 为“6个月后的模型”构建产品不要被当下的模型限制了想象力。
“如果你为一个6个月后才会出现的模型来构建产品，当那个模型问世时，你就能迅速起步，产品就会一触即发。” (if you build for the model 6 months out when that model comesout you're just going to hit the ground running and the product is going to click)
不要试图给 AI 设置僵化的“工作流盒子”（如必须先做 A 再做 B）。根据“苦涩的教训（The BitterLesson）”法则，永远要押注在能力更强大、更通用的模型上。赋予它工具，给它目标，让它自己想办法完成 。
开发者与职场人的 AI 行动指南
面对如此汹涌的 AI 浪潮，普通人该如何自处？如果你想最大化利用类似 Claude Code 这样的前沿工具，以下是一份高度可落地的行动清单：
☑️ 永远使用最强大的模型：不要为了省钱去使用廉价版模型（如 Sonnet）。直接使用 Opus 4.6 这样的最强版本，因为它犯错少、无需反复修改，最终消耗的总 Token和时间成本反而更低 。 ☑️ 掌握“计划模式（Plan Mode）”：让 AI 写代码前，先通过提示词（例如在终端双击 Shift+Tab 开启计划模式）让它列出执行计划。一旦计划逻辑无误，AI几乎总能一次性写出正确代码 。 ☑️ 多开并行运行：不要只盯着一个窗口。试着同时开启多个 Agent 任务窗口，让它们在后台并行处理不同的工作（邮件总结、代码重构、数据清洗等），自己则去喝杯咖啡 。 ☑️跨界成为“通才”：随着纯粹的代码编写门槛降为零，未来最吃香的将是具备“跨学科能力”的人。无论你是产品型工程师、懂架构的设计师，还是懂业务逻辑的数据科学家，不要只懂代码，要懂如何通过技术解决商业问题 。
总结
正如 15 世纪活字印刷术的出现，曾让识字率极低的欧洲迎来了知识普及和文艺复兴 。今天，AI 正在让“编写软件”这项曾经少数精英垄断的技能变得大众化 。
转型必然伴随着阵痛与颠覆，甚至许多传统编码技能可能会退化 。但只要我们拥抱这一趋势，将个人的创造力与 AI 的执行力完美结合，一个人就是一支军队的时代，才刚刚开始。
💎 深度访谈：全章节精华记录
01 Claude Code：重塑软件工程的未来
👤 主持人 A： 我现在的代码 100% 都是由 Claude Code 编写的。从去年 11 月起，我没有手动修改过一行代码。我每天提交 10 个、20 个甚至 30 个拉取请求（PR），我抓住了这个技术红利期。就在我们录制节目的当下，我后台还有大约五个代理（Agents）在同时运行。
👤 Boris： 你会怀念亲手写代码的感觉吗？
👤 主持人 A： 我从未像现在这样享受编程，因为我无需再处理那些琐碎的细节。现在每位工程师的生产力都提高了 200%。总有人问我：现在还该学编程吗？
👤 Boris： 一两年后，这个问题可能就不重要了。
👤 主持人 A： 编程本身的问题基本已经解决了。我设想的是一个全民编程的世界，任何人随时随地都能开发软件。软件编写方式的下一个重大转变是什么？Claude 开始主动提出想法，它会查看用户反馈、错误报告和遥测数据，并据此修复错误、交付产品。它表现得更像是一位同事，而不仅仅是一个工具。
👤 主持人 A： 许多听众是产品经理，听到这里可能正在冒汗。但我认为到今年年底，每个人都将是产品经理，每个人也都会编程。“软件工程师”这个头衔将逐渐消失，取而代之的是“建造者（Builder）”。这种职业身份的转型对很多人来说会是一个痛苦的过程。
开场引言： 今天的嘉宾是 Boris Cherny，他是 Anthropic 公司 Claude Code 的负责人。Claude Code 对世界产生的影响难以言喻。本期节目播出时，正值 Claude Code 推出一周年。在短短一年内，它彻底改变了软件工程师的工作模式，现在也开始重塑科技领域许多其他职能的工作，这些我们都会在节目中深入讨论。
Claude Code 本身也是 Anthropic 整体增长的巨大推动力。在过去一年里，他们刚刚完成了一轮估值超过 3500 亿美元的融资。正如 Boris 所说，Claude Code 本身的增长仍在加速，仅仅在过去一个月，他们的日活跃用户就翻了一番。
Boris 是一位非常有趣、深思熟虑且思想深刻的人。在这次谈话中，我们惊讶地发现彼此竟然都出生在乌克兰的同一个城市，这很有趣，我之前完全不知道。非常感谢 Ben Mann、Jenny Wen 和 Mike Krieger 为本次对话提供的话题建议。
02 从Cursor到Anthropic：使命驱动的选择
👤 Boris： Boris，非常感谢你来到这里，欢迎收听我们的播客。
👤 主持人 A： 谢谢你的邀请。
👤 Boris： 我想先问一个比较“劲爆”的问题。大约六个月前，你离开了 Anthropic 加入 Cursor，但两周后又回到了 Anthropic。这期间到底发生了什么？我想我还没听过这个故事的真实版本。
👤 主持人 A： 这确实是我经历过最快的一次跳槽。我当时加入 Cursor，是因为我本身就是他们产品的忠实粉丝，而且坦率地说，见到团队后我留下了非常深刻的印象。他们是一个很棒的团队，正在开发非常酷的产品，我认为他们比大多数人更早地洞察到了 AI 编程的未来走向。
👤 主持人 A： 所以，开发一款好产品的想法让我感到非常兴奋。但当我到了那里，我开始意识到，我真正怀念 Anthropic 的是它的使命感。这实际上也是我最初加入 Anthropic 的原因。在加入 Anthropic 之前，我在大型科技公司工作，后来我希望能进入某个实验室，以某种方式帮助塑造我们正在构建的这个“疯狂事物”的未来。
👤 主持人 A： 吸引我加入 Anthropic 的核心是它的使命，而这一切都关乎安全。在 Anthropic，你随便在走廊里找个人问他们为什么在这里，答案永远是“安全”。这种使命驱动的特质深深打动了我，我个人也意识到，这是我获得职业幸福感所必需的。而这正是我在离开后真正怀念的东西。
👤 主持人 A： 我发现，无论工作内容本身多么令人兴奋，即便是在开发一个非常酷的产品，也无法真正取代那种使命感。所以对我来说，我很快就意识到自己缺失了那种感觉，这种认知非常清晰。
03 Claude Code的爆发式增长与起源
👤 Boris： 好的，那我们接着聊聊你回到 Anthropic 后的工作。本期播客发布时，恰逢 Claude Code 推出一周年，我想借此机会回顾一下你所带来的影响。最近 SemiAnalysis 发布的一份报告显示，目前 GitHub 上 4% 的提交是由 Claude Code 完成的；他们甚至预测，到今年年底，这一比例将达到 GitHub 全站代码提交量的五分之一。正如报告所言：在我们眨眼之间，AI 已经开始吞噬整个软件开发领域。
👤 Boris： 就在我们录制节目的当天，Spotify 发布了一条头条新闻，称他们最优秀的开发者自去年 12 月以来就没有写过一行代码。得益于包括你在内的努力，越来越多资深工程师都在分享一个事实：他们不再亲自动手编写代码，所有代码均由 AI 生成，许多人甚至不再审阅代码了。这在很大程度上要归功于你启动的这个小项目，以及你的团队在过去一年中将其规模化的成果。我很想听听你对过去一年的回顾，以及你如何看待这些影响。
👤 主持人 A： 这些数字简直令人难以置信。全球 4% 的提交量，这远远超出了我的想象，而且感觉这仅仅是个开始。这些还只是公开提交，如果算上私有仓库，数字肯定会高得多。对我来说，最惊人的不仅是现状，更是增长的速度。观察 Claude Code 任何指标的增长曲线，你会发现它在持续加速——它不仅在增长，而且增长得越来越快。
👤 主持人 A： 最初启动 Claude Code 时，它只是一个小型黑客项目。在 Anthropic，我们一直想推出某种编程产品，这符合我们构建安全 AGI 的思维模式：模型首先要擅长编程，接着是工具使用（Tool Use），再到计算机使用（Computer Use）。大致上，这就是我们长期努力的发展轨迹。
👤 主持人 A： 我最初加入的团队叫 Anthropic Labs，由 Mike Krieger 和 Ben Mann 重新启动。这个团队开发了一些非常酷的产品，包括 Claude Code、MCP（模型上下文协议）以及桌面应用。你可以看到这些想法的萌芽：从编程到工具使用，再到计算机使用。这对 Anthropic 而言至关重要，因为这关乎安全。
👤 主持人 A： 这又回到了核心点：AI 正在变得越来越强大。过去一年发生的变化是，至少对工程师而言，AI 不再仅仅是编写代码的助手或对话伙伴，它开始真正使用工具并在现实世界中采取行动。随着 Cowork 的推出，我们看到非技术人员也开始转变。对于许多使用对话式 AI 的人来说，这可能是他们第一次接触真正能“行动”的工具——它能操作你的 Gmail、Slack，为你处理各种事务，而且表现得相当出色，且持续进化。
👤 主持人 A： 在 Anthropic 内部，很长一段时间里我们都想构建些什么，但具体形态并不清晰。加入公司后的第一个月，我一直在摸索，构建了一堆奇特的原型。它们大多没有发布，甚至离发布还很远，纯粹是为了测试模型的能力边界。随后，我花了一个月时间研究后期训练（Post-training），以便从研究层面理解模型。
👤 主持人 A： 坦率地说，作为一名工程师，要想做好工作，你必须理解所处层级之下的那一层。在传统工程中，做产品开发需要了解基础设施、运行时、虚拟机和语言；而在 AI 领域，你必须在某种程度上理解模型。所以我绕了一圈去钻研模型，然后回来重新开始原型开发，最终演变成了 Claude Code 的第一个版本。
👤 主持人 A： 某处应该还留着那段视频录像，是我当时录制并发布的演示，那时它还叫 Claude CLI。我展示了它如何使用工具，令我震惊的是，当我给它一个 bash 工具时，它竟然能用它编写代码，甚至告诉我我正在听什么音乐。我问它：“我正在听什么音乐？”这太神奇了，因为我并没有指示模型“用这个工具去做这件事”，它完全是自发想出了如何使用工具来回答我的问题——一个我甚至不确定它能否回答的问题。
👤 主持人 A： 于是我开始深入开发，并为此发了一篇文章。我在内部宣布了这个项目，结果只得到了两个赞。当时的反馈仅此而已，因为公司内部的人提到编程工具时，想到的是 IDE 等复杂的环境，没人认为这可以是一个基于终端（Terminal）的工具。这是一种奇怪的设计路径，并非最初的意图，但因为前几个月只有我一个人，在终端构建是最简单的方式。对我来说，这是一个非常重要的产品教训。
👤 主持人 A： 起步时，资源稍微不足反而是好事。后来我们讨论过是否该尝试其他产品形态，但最终决定暂时坚持使用终端。最大的原因是模型改进得太快了，我们觉得没有其他产品形态能跟上这种迭代速度。坦率地说，那阵子我一直在纠结到底该构建什么，深夜里满脑子都是 Claude Code：模型在不断进化，我们怎么可能跟得上？最终，终端成了我唯一的答案。
👤 主持人 A： 结果它真的流行起来了。发布后不久，它在 Anthropic 内部大受欢迎，日活跃用户量呈垂直增长。早在正式发布前，Ben Mann 就催我做一个 DAU 图表，我当时还觉得太早了，但他坚持要做。事实证明，图表很快就直线飙升。到了二月份，我们正式对外发布了它。
👤 主持人 A： 大家可能不记得，Claude Code 发布之初并没有立即引爆。虽然有一批早期采用者立即接受了它，但实际上花了几个月时间，大家才真正理解这个产品是什么。因为它太不一样了。回想起来，Claude Code 之所以奏效，部分原因在于它满足了潜在需求——我们将工具带到了用户所在的工作流中；但另一方面，因为它在终端运行，这种陌生感也让人惊讶。用户必须保持开放的心态去学习如何使用它。
👤 主持人 A： 当然，现在 Claude Code 已经无处不在，无论是 iOS、Android、桌面应用、网页端，还是作为 IDE 扩展、Slack 和 GitHub 插件，它存在于工程师工作的每一个角落。它变得越来越让人熟悉，但这并非它的起点。起初，这个东西竟然有用，这本身就令人意外。随着团队和产品的成长，从初创公司到科技巨头，全球的用户都在使用它并提供反馈。回望这段历程，这是一种令人谦卑的经历，我们不断从用户身上学习。最令人兴奋的是，其实没有人真正拥有标准答案，我们只是在和大家一起摸索。用户的反馈就是最好的信号。这一路走来，我被惊艳过很多次。
04 AI编程：从解决问题到构思创意
👤 Boris： 在当今世界，事物的变化速度快得令人难以置信。你在一年前推出了这个产品，虽然这并非人们第一次尝试AI编程，但在短短一年内，整个软件工程行业已经发生了翻天覆地的变化。例如，曾有各种预测称“100%的代码将由AI编写”，当时大家会觉得这太疯狂了，甚至质疑这种说法的依据。但现在看来，这一切正如预言的那样正在发生，事实就是如此。
👤 主持人 A： 现在的形势发展和变化确实太快了。回想今年五月我们Anthropic举办的第一次开发者大会——“与Claude一起编程”大会，我做了一个简短的演讲。在问答环节，有人问我对今年年底有什么预测。我当时预测，到2025年五月，或者说就在今年年底，大家可能不再需要IDE来编程了，工程师们将不再沿用传统的开发模式。我记得当时台下的人都倒吸了一口凉气，觉得那是一个极其疯狂的预测。
👤 主持人 A： 但在Anthropic，我们思考问题的方式是指数级的，这已经深深植根于我们的基因中。我们的联合创始人中有三位是“扩展定律”（Scaling Laws）论文的前三位作者，所以我们习惯于用指数思维去推演。如果你观察Claude编写代码百分比的指数级增长曲线，在当时，只要你顺着那条线描绘下去，就会发现我们在年底前突破100%是显而易见的，即便这在直觉上让人难以接受。我所做的只是把那条线画了出来。到了11月，这对我个人而言已经成为了现实，并一直延续至今。我们也开始看到许多不同的客户身上出现了同样的情况。
👤 Boris： 我觉得这非常有趣。你刚才分享的这段旅程，体现了一种“随意尝试、看看会发生什么”的想法。这在OpenClaude中也经常出现，就像Peter只是随手尝试，然后突破就发生了。感觉这正是许多AI领域重大创新的核心要素：人们坐下来尝试各种可能性，将模型的极限推向比大多数人预想更远的地方。
👤 主持人 A： 这就是创新的本质，对吧？创新是无法强求的，也没有预设的路线图。你必须给人们空间，或者说给他们一种“心理安全感”，让他们觉得失败也没关系。即便80%的想法最终证明行不通，那也没关系；但同时你也必须让他们承担责任，如果想法不好，就及时止损并转向下一个目标，而不是盲目投入。在Claude Code早期，我根本不知道它是否真的有用。二月份发布时，它可能只写了我20%的代码；到了五月，这个比例大概也只有30%。我当时大部分代码仍然使用Cursor编写，直到十一月才真正达到100%。虽然这花了一段时间，但从最早的时候起，我就直觉自己发现了一些东西。我每个晚上和周末都在钻研，幸运的是我妻子非常支持。我当时只是觉得发现了一些线索，虽然还不清楚具体是什么，但当你抓到一个线索时，就必须顺藤摸瓜钻研下去。
👤 Boris： 所以现在，你100%的代码都是由Claude Code编写的。这是你目前编程的常态吗？
👤 主持人 A： 是的，我100%的代码都由Claude Code编写。我一直是一个相当高产的程序员，即便以前在Instagram工作时，我也是最高效的工程师之一。在Anthropic，情况依然如此。
👤 Boris： 哇，即便作为团队负责人也是如此。
👤 主持人 A： 是的，我仍然会编写大量代码。每天我都会提交10个、20个甚至30个拉取请求（PR）。每天都是如此。
👤 Boris： 天哪。
👤 主持人 A： 全部由Claude Code编写。自十一月以来，我没有手动编辑过一行代码。事实就是这样。当然，我确实会审查代码。我不认为我们已经到了可以完全放手不管的地步，尤其是在有大量用户运行程序的情况下。你必须确保代码是正确且安全的。在Anthropic，我们还有Claude对所有代码进行自动审查，它会审查100%的拉取请求，之后仍然会有人工审查环节。除非是那种纯粹的、不会在任何地方运行的原型代码，否则你仍然需要这些检查点，需要有人把关。
05 适应AI时代：工程师的思维转变与生产力提升
👤 Boris： 目前下一个前沿领域是什么？如果100%的代码都由AI编写，这显然是软件工程领域所有人的发展方向。这听起来像是一个疯狂的里程碑，但现在看来，这似乎就是当下的现实。那么，软件编写方式的下一个重大转变会是什么？是你的团队已经在实践的，还是你认为即将发展的方向？
👤 主持人 A： 我认为现在正在发生的一件事是，Claude开始主动提出想法了。它会查看反馈、错误报告、遥测数据等，并开始提出修复Bug和发布新功能的建议。它开始变得更像一个同事。第二点是，我们正逐渐脱离单纯的编码领域。我觉得现在可以肯定地说，编码问题基本解决了，至少对我所从事的编程类型来说是这样。因为Claude可以胜任，这已经成了一个“已解决的问题”。所以我们现在开始思考：接下来是什么？这之后还有什么空间？
👤 主持人 A： 有很多与编码相关的事情即将发生，但也有一些通用的任务。例如，我现在每天都用Cowork来处理各种与编码完全无关的事情，而且是自动化完成的。比如前几天我要交一张停车罚单，我直接让Cowork去处理了。我团队所有的项目管理也都由Cowork包办，它负责同步电子表格和消息数据，在Slack和邮件上联系相关人员等等。所以我认为前沿在于这类应用，而不是编码本身，因为编码问题已基本解决。在接下来的几个月里，我认为整个行业都会意识到这一点。针对每种代码库和技术栈，这种能帮助你构思工作内容的模式都非常有趣。
👤 Boris： 很多听众是产品经理，听到这里可能正在冒汗。你具体是怎么用Claude来实现这些的？只是简单的对话吗？你有没有总结出什么巧妙的方法，来帮助你利用它构思要构建的产品？
👤 主持人 A： 坦率地说，最简单的方法就是打开Claude Code或Cowork，然后将其指向一个Slack频道。例如，我们有一个内部频道专门收集Claude Code的反馈，从2024年首次发布以来一直如此。在公司内部，反馈信息就像消防水带喷涌一样密集。早期每当有人反馈，我都会尽快修复，通常在一到五分钟内。这种极速的反馈周期鼓励了人们提供更多建议，因为这让他们觉得自己的声音被倾听了。通常你向一个产品提供反馈后，它就像掉进了黑洞，再无音讯。但如果你让人们觉得被重视，他们就会更愿意贡献，帮助把事情做得更好。现在我依然在做同样的事，但坦白说，Claude承担了大部分工作。我把它指向那个频道，它就会自动分析并说：“好的，这里有几件事我可以处理。我已经提交了几个PR（拉取请求），要看看吗？”我就说：“好的。”
👤 Boris： 你有没有注意到它在这方面正变得越来越强？因为这现在就像是“圣杯”。构建问题解决了，代码审查就成了下一个瓶颈——这么多PR，谁来审查？接下来的大问题就是：人类需要弄清楚该构建什么，以及如何确定优先级。你是说Claude Code已经开始在这方面提供帮助了吗？它在Opus 4.6等版本上的表现是否有显著提升？它的发展轨迹是怎样的？
👤 主持人 A： 是的，它改进了很多。我认为一部分归功于我们针对编码进行的专项训练。显然，它是目前世界上最好的编码模型，而且还在持续进化。例如，4.6版本的表现简直不可思议。但实际上，我们进行的许多非编码训练也转化得很好，这种“迁移效应”确实存在——当你教会模型做X，它在Y方面也会变得更出色。
👤 主持人 A： 过去一年，Anthropic的收益简直疯涨。自从引入Claude Code以来，虽然我无法提供确切数字，但我们可能将工程团队的规模扩大了约四倍，而每位工程师在拉取请求（PR）方面的生产力竟然增加了200%。对于任何致力于开发效率的人来说，这个数字都是令人难以置信的。以前我在Meta工作，职责之一是负责公司的代码质量，涵盖Facebook、Instagram、WhatsApp等所有代码库。那项工作很大程度上是为了提升生产力，因为提高代码质量能让工程师更高效。但当时的情况是，即便数百名工程师努力一年多，生产力也只能提高几个百分点。所以现在看到这种几百个百分点的增长，简直是奇迹。
👤 Boris： 同样令人惊叹的是，这一切竟然变得如此常态化。我们听到这些数字，反应却是：“当然，AI理应做到这些。”软件开发、产品构建乃至整个科技界正在发生的变革是前所未有的。虽然这种变化太容易让人习以为常，但我们必须认识到，这背后的进步是非常疯狂的。
06 编程的本质与工作的未来
👤 主持人 A： 这是我偶尔需要提醒自己的事情。这种思维定式也有缺点，因为模型在不断进化。我们可以谈论很多缺点，但我认为在个人层面，一个显著的挑战是模型迭代太频繁，有时我会陷入旧的思维方式。我甚至发现团队中的新人，甚至是刚毕业的员工，有时处理问题的方式比我更具“AGI思维”。
👤 主持人 A： 例如，几个月前我遇到了一个内存泄漏的问题。当时是在开发 Claude Code，内存占用持续上升，最终导致崩溃。这是一种非常典型的工程问题，每个工程师都调试过无数次。传统上，解决办法是获取堆快照（heap snapshot），将其导入专门的调试器，利用这些工具来追踪并排查问题。我当时正忙于此，盯着追踪信息试图理清头绪。而团队里一位新来的工程师直接把任务交给了 Claude Code。他说：“嘿，Claude，好像有内存泄漏，你能查出来吗？”结果 Claude Code 采取了和我完全一样的步骤：它获取了堆快照，甚至为自己编写了一个临时的分析小工具。这就像一个即时生成的程序。它迅速发现了问题并提交了拉取请求，速度比我快得多。所以对于我们这些长期使用模型的人来说，必须时刻让自己保持与时俱进，不要停留在旧模型的认知里。现在的模型已经不再是最初的 Sonnet 3.5 了，新模型的能力完全不同，这种思维模式的转变至关重要。
👤 Boris： 我听说你为团队制定了非常具体的原则，并在新人入职时向他们强调。我相信其中一条是：“有什么是让 Claude 做比自己做更好的？那就让 Claude 来做。”感觉你刚才描述的内存泄漏案例正是如此——你几乎忘记了那个原则，没有第一时间去想：好吧，让我看看 Claude 能不能帮我解决。
👤 主持人 A： 当你对人力投入保持一种“适度紧缺”的状态时，会发生一件有趣的事情：人们会被迫使用 Claude 来解决问题。这就是我们观察到的现象。在工作中，有时我们只让一名工程师负责一个项目，他们反而能非常快速地交付。这源于一种内在的动力，一种想把工作做好的纯粹渴望。如果你有一个好主意，你会迫切地想把它实现出来，这种动力源自自我驱动，无需他人强迫。在这种情况下，如果你拥有 Claude，你就会利用它来自动化大量工作。这种情况在我们这里反复发生。
👤 主持人 A： 所以我认为一个原则是“保持人力投入的适度紧缺”；另一个原则则是“鼓励提速”。如果你今天能完成某件事，就应该今天做。这是我们团队非常推崇的文化。在公司早期这至关重要，因为当时只有我一个人，速度是我们唯一的优势。这是我们在竞争激烈的编程工具市场中推出产品并保持竞争力的唯一途径。即便到了今天，这依然是团队的核心原则。如果你想追求极致的速度，一个非常有效的方法就是让 Claude 承担更多工作。所以，这种对速度的追求自然会鼓励“人力精简”的想法。
👤 Boris： 这很有趣。通常人们认为 AI 会导致裁员，减少对工程师的需求。但你不仅是在谈论效率提升，你是在说，如果刻意保持人力投入不足，实际效果反而更好。这不只是 AI 让你变快，而是通过减少项目人手，反而能逼出 AI 工具的最大潜力。
👤 主持人 A： 是的。如果你雇佣的是优秀工程师，他们总会想方设法达成目标，前提是你要赋予他们足够的自主权。这实际上是我经常与 CTO 及各类公司讨论的话题。我的建议通常是：起初不要试图去优化，也不要急于削减成本。首先，要尽可能多地为工程师提供 tokens。现在你会发现像 Anthropic 这样的公司，员工可以使用大量的 tokens，这正成为一种新的员工福利。在某些公司，入职即意味着拥有“无限 tokens”。我非常鼓励这样做，因为它让人们可以自由地尝试那些原本可能被认为过于疯狂的想法。一旦某个想法被证明行之有效，那时你再考虑如何扩大规模。
👤 主持人 A： 那才是优化和控制成本的时机。你可以研究是否能用 Haiku 或 Sonnet 代替 Opus 来执行任务。但在起步阶段，你应该投入大量的 tokens 去验证想法的可行性，并给予工程师充分的探索自由。
👤 Boris： 所以你的建议是，在 tokens 的分配上要大方。考虑到这些模型的运行成本，听众可能会想：“他当然会这么说，他在 Anthropic 工作，自然希望我们多用 tokens。”但你表达的核心观点是：最有趣、最具创新性的想法，往往来自于那些将工具发挥到极致、不断探索可能性边界的人。
👤 主持人 A： 没错。现实情况是，在小规模实验阶段，你并不会收到巨额账单。如果只是一个工程师在做实验，token 成本相对于其工资或业务运营的其他成本来说，依然是非常低的。即便他们构建出了一些很棒的东西，导致 token 消耗量激增、成本上升，那也正是你开始优化它的时机。但千万不要过早进行优化。
👤 Boris： 你见过 token 成本高于人力工资的公司吗？你认为我们会看到这种趋势吗？
👤 主持人 A： 在 Anthropic，我们已经看到有些工程师每月消耗价值数十万美元的 tokens 了。这种情况正在发生，在其他一些公司里，我们也开始看到类似的苗头。
07 编程的本质与工作的未来
👤 Boris： 回到编程的话题，你怀念写代码吗？作为一名软件工程师，当你不再亲手写代码时，会感到遗憾吗？
👤 主持人 A： 这很有趣。对我来说，工程学是非常实用的。我学习工程就是为了能亲手构建东西。我是自学成才的，虽然在学校学的是经济学，没修过计算机科学，但我很早就开始钻研工程了。我从中学起就开始编程，初衷非常纯粹：为了在数学考试中“作弊”。那是我的第一个作品。当时我们用那种 TI-83 Plus 图形计算器，我就把答案编进了程序里。
👤 主持人 A： 后来到了下一年，数学课变得太难了，我没法预知题目，也就没法直接把答案编进去。于是我写了一个小型求解器，一个能自动解代数题的程序。我发现可以用一根小电缆把程序传给班上其他人，结果全班都得了 A。当然，后来我们都被抓住了，老师叫我们别再搞这些。但从一开始，编程对我来说就是一种极其务实的构建手段，它本身并不是目的。
👤 主持人 A： 不过，我也曾沉迷于编程之美。我写过一本关于 TypeScript 的书，还组织过当时全球最大的 TypeScript 聚会。那是因为我爱上了这门语言本身，深入研究过函数式编程等领域。我觉得很多程序员都会被这些东西吸引。编程确实有一种美感，尤其是函数式编程和类型系统。当你平衡好类型，或者写出一段漂亮的程序，那种兴奋感不亚于解决了一个复杂的数学难题。但这终究不是最终目的。对我而言，编程更多是一种工具，一种实现目标的手段。当然，并非每个人都这么想。比如我们团队的工程师莉娜，她周末还会手写 C 语言代码，纯粹是因为她热爱这门手艺。每个人对此的追求都不尽相同。
👤 主持人 A： 即便行业在变，一切都在进化，但如果你愿意，总会有空间让你去钻研这门艺术，去亲手打磨一些东西。
👤 Boris： 你会担心作为工程师的技能退化吗？这是你会焦虑的事，还是你觉得这只是行业发展的必然？
👤 主持人 A： 我觉得这是必然发生的，我个人并不太担心。编程是一个连续体。很久以前，软件还是个新鲜事物。比如我们今天编写程序的方式，大多是在虚拟机上运行软件，这种模式自 20 世纪 60 年代以来已经存在了约 60 年。在那之前是打孔卡，再之前是物理开关，更早则是纯硬件。而在那之前，编程其实是纸笔工作——一屋子人在纸上进行数学计算。所以，编程的形式一直都在演变。
👤 主持人 A： 在某些方面，你仍然需要了解底层原理，因为它能帮你成为更好的工程师。我觉得这种状态可能还会持续一年左右，但很快底层细节就不再重要了。它会变得像现在程序员眼中的汇编代码一样。从情感层面来说，我感觉自己总是在学习新事物。作为程序员，我们其实很习惯这种变化，毕竟总有新框架、新语言出现。但这种心态并不适用于所有人。对一些人来说，他们可能会感受到更强烈的失落感、怀旧感，或者对技能退化的恐惧。
👤 Boris： 不知道你有没有看到，埃隆·马斯克曾问：为什么 AI 不能直接写二进制代码？如果最终能做到这一点，那么现在所有的编程抽象层还有什么意义呢？
👤 主持人 A： 是的，这是个好问题。我的意思是，只要你想，AI 完全可以做到。
👤 Boris： 天哪。所以我听到的是，关于“学生是否还该学习编程”这个经典问题，你的看法是：一两年后，这可能就不再是必须的技能了。
👤 主持人 A： 我的看法是，对于今天使用 Claude Code 或 AI 代理（Agent）进行编程的人来说，理解底层逻辑依然必要。但确实，一两年后这就不再重要了。我一直在思考历史上有哪些合适的类比，来帮助我们理解这种转变。我觉得最接近的类比是印刷术。在 15 世纪中叶的欧洲，识字率极低，不到 1%。当时所有的书写和阅读都由“抄写员”负责。他们受雇于领主和国王，而那些雇主自己通常是不识字的。书写在当时只是极少数人的专业工作。
👤 主持人 A： 后来古腾堡发明了印刷术。有一个惊人的统计：在印刷术诞生后的 50 年里，印刷品的产量超过了此前一千年的总和。印刷材料的数量激增，成本大幅下降，在随后的 50 年里下降了约 100 倍。虽然识字率的提升花了一些时间——因为学习读写需要教育系统和闲暇时间，需要人们从农活中解放出来——但在接下来的 200 年里，全球识字率上升到了 70%。我觉得我们正在经历类似的转变。
👤 主持人 A： 有一份有趣的历史文献记录了 15 世纪对一位抄写员的采访。当被问及对印刷术的看法时，他其实非常兴奋。他说：“我最讨厌的工作就是抄写书籍，我真正喜欢的是在书里画插画和装订书籍。现在我的时间终于被解放了。”作为一名工程师，我感同身受。我不再需要做那些繁琐的编码工作了，因为那向来是细节中最枯燥的部分。处理 Git 冲突、摆弄各种工具，这些都不是乐趣所在。真正有趣的是构思产品、与用户交流、设计大型系统、思考未来以及团队协作。现在，我可以把更多精力投入到这些事情上了。
👤 Boris： 令人惊叹的是，你正在构建的工具让任何人都能做到这一点。即便没有技术背景的人，也能实现你所描述的过程。比如我最近在做一些零散的小项目，每当遇到困难，我只需说“帮我解决这个问题”，AI 就能搞定。我职业生涯早期做了 10 年工程师，记得那时要花大量时间处理库和依赖项，遇到问题得去查 Stack Overflow。而现在，直接下令，AI 就会给出分步指南。一、二、三、四，搞定。
👤 主持人 A： 没错。我今天早些时候和一位工程师聊天，他用 Go 语言写一个服务写了一个月，现在运行得很好。我问他感觉如何，他说：“其实我到现在还是不太懂 Go 语言。”我觉得这种情况会越来越多。只要你能确保它正确、高效地工作，你就不必了解每一个实现细节。
👤 Boris： 显然，软件工程师的生活发生了巨变，这在过去一两年里几乎变成了一份全新的职业。你认为下一个受 AI 深度影响的角色会是谁？是产品经理、设计师，还是科技行业之外的岗位？AI 下一步会走向何方？
👤 主持人 A： 我觉得会是所有与工程相关的角色，包括产品经理、设计、数据科学。它将扩展到几乎所有能在电脑上完成的工作，因为模型的能力在不断进化。Claude Code 只是实现这一目标的第一步。我认为它将“代理式 AI”（Agentic AI）带给了以前从未接触过它的人。人们才刚刚开始感受到它的存在。回想一年前，工程领域还没人真正了解或使用代理，但现在，它已成为我们的工作常态。
👤 主持人 A： 当我观察现在的非技术或半技术性工作（如产品或数据科学）时，发现大家还在使用聊天机器人这种对话式 AI。虽然“代理”这个词被滥用了，但“代理”实际上有一个非常具体的专业含义：它是一种能够使用工具、能够采取行动并与系统互动的 AI 模型。它不只是和你聊天，它还能操作你的 Google 文档、发送邮件、在电脑上运行命令。因此，任何需要通过电脑工具完成的工作，都将是下一个受冲击的对象。这是整个社会和行业都必须面对并弄清楚的问题。
👤 主持人 A： 这也是为什么在 Anthropic 推进这项工作让我感到责任重大。我们对此非常认真，团队中不仅有工程师，还有经济学家、政策制定者和社会影响专家。我们希望发起广泛讨论，让社会共同决定该如何应对，而不是由我们几家公司说了算。
👤 Boris： 你暗示的是关于就业和失业的大问题。这里有一个“杰文斯悖论”的概念：当我们做事的效率越高，需求反而会增加，从而雇佣更多的人。所以情况可能没那么可怕。到目前为止你的经验是什么？随着 AI 成为工程的核心，你们的招聘需求是增加了吗？
👤 主持人 A： 是的，我们团队一直在招聘。Claude Code 团队正在招人，感兴趣的话可以关注 Anthropic 的招聘页面。就我个人而言，AI 让我更享受工作了。我从未像今天这样热爱编程，因为我不再需要处理那些琐碎的细节。这是我们从许多客户那里听到的反馈：Claude Code 让编程再次变得愉快且充满乐趣。
👤 主持人 A： 但很难预测最终的走向。我还是想用印刷术做类比：这项技术让原本掌握在少数精英手中的能力变得人人可及。这本质上是一种“民主化”。如果没有这种普及，文艺复兴就不可能发生，因为文艺复兴的核心就是知识的传播。那么，编程的普及会带来什么？这是让我感到非常乐观和兴奋的部分。
👤 主持人 A： 试想，如果没有印刷术，我们今天就不可能坐在这里交谈，麦克风和周围的一切都不会存在，因为没有印刷术就无法协调如此庞大的人群。我设想几年后的世界，每个人都能编程。那会释放出怎样的潜力？当任何人都能随时随地构建软件，世界会变成什么样？就像 15 世纪的人无法预言今天一样，我们也无法完全想象未来。但我确信，这个过程会充满颠覆性，对很多人来说甚至是痛苦的。作为社会整体，我们必须共同面对这场对话。
👤 Boris： 对于那些希望在动荡中取得成功的人，你有什么建议？是精通 AI 工具，还是有其他保持领先的方法？
👤 主持人 A： 是的，首先是拥抱工具，去尝试、去了解，不要害怕它们，甚至要去挑战它们的极限。第二个建议是：尝试成为一个“通才”。过去，很多计算机专业的学生只钻研编程或系统架构。但我合作过的一些最优秀的工程师和产品经理，都是跨学科人才。
👤 主持人 A： 在 Claude Code 团队，每个人都编程：产品经理、工程经理、设计师、财务人员、数据科学家，全员都会写代码。而最顶尖的工程师往往是混合型的：既懂产品又懂基础设施，或者是有出色设计感的产品工程师，亦或是能深刻理解业务并以此驱动决策的人。我认为未来几年最受青睐的人才，不仅是“AI 原生”的工具专家，更是那些充满好奇心、能跨学科思考、能关注问题全貌而非仅仅盯着工程部分的通才。
👤 Boris： 你觉得工程、设计、产品经理这三个独立职能，作为团队构建方式还有效吗？当大家都在编程并参与产品思考时，这些角色还会长期存在吗？
👤 主持人 A： 短期内会存在。但我们已经看到，这些角色的重叠度已经达到了 50%。大家在做很多相同的工作，只是专长不同。比如我负责更多编码，而其他人可能侧重于协调、规划或利益相关者管理。我确实认为，到今年年底，这些界限会进一步模糊。在某些公司，“软件工程师”这个头衔可能会消失，取而代之的是“构建者”（Builder）。到那时，每个人都是产品经理，每个人也都是程序员。
08 用户反馈、潜在需求与产品迭代
👤 Boris： 你提到现在更喜欢编程了，这让我想起我在 Twitter 上做的一个非正式小调查。我发起了三个不同的投票，询问工程师、产品经理和设计师：在采用 AI 工具后，你们是更喜欢还是更讨厌自己的工作了？结果显示，工程师和产品经理的反馈非常一致，70% 的人表示更喜欢现在的工作，只有约 10% 的人表示反感。有趣的是，设计师群体中只有 55% 的人表示更喜欢工作，而 20% 的人觉得更不喜欢了。这个差异真的很有趣。
👤 主持人 A： 这确实很有意思。我很想和这些人聊聊，无论是更喜欢还是更不喜欢的那部分人，去了解背后的原因。你有没有跟进过他们的反馈？
👤 Boris： 有几个人回复了，我们目前正在做一个后续投票，链接会放在节目备注里，以便深入探讨。让工作变得有趣或无趣的因素有很多，但那些表示“更不喜欢工作”的设计师并没有分享太多细节，所以我很好奇那里到底发生了什么。
👤 主持人 A： 是的，我在 Anthropic 也观察到了类似的情况。我认为我们团队的技术氛围很浓，这是招聘时就会筛选的条件。即使是非技术岗位，也要经历多轮技术面试，我们的设计师大部分时间都在编程。对他们来说，AI 工具非常棒，因为他们不再需要麻烦工程师，可以直接动手解决问题。甚至一些以前不编程的设计师也开始尝试了。但我很想听听更多人的经验，因为我敢打赌，情况并非全都是这样。
👤 Boris： 没错。所以如果你正在收听节目，请给我们留言。如果你觉得工作的乐趣减少了，或者更不喜欢这份工作了，请告诉我们。因为正如你所说，我从 70% 的产品经理和工程师那里听到的都是正面反馈，如果你不属于这一类，那说明可能有些特殊情况正在发生。
👤 主持人 A： 是的。我们也观察到人们在尝试不同的工具。例如，我们的设计师更倾向于使用 Claude 桌面应用程序进行编码。你只需下载桌面端，它就运行在 Cowork 旁边，使用的是完全相同的 Claude 代码和代理。这个功能我们已经推出好几个月了。它的优势在于，你不需要打开一堆终端就能编程，同时还能获得 Claude 代码的强大功能。最重要的是，你可以并行运行任意数量的会话，我们称之为“多重 Claude”。对于非工程师用户来说，这种体验更原生。这其实回到了“将产品带到用户所在之处”的理念：你不想强迫用户改变现有的工作流程，也不想让他们特意去学习新东西。无论人们在做什么，如果你能让过程变得更容易，产品就会更受欢迎。这就是“潜在需求”原则，我认为这是产品领域最重要的原则。
👤 Boris： 你能详细谈谈这个吗？我正想请你解释一下这个原则的具体含义，以及当你释放这种潜在需求时会发生什么。
👤 主持人 A： 潜在需求是指，如果你构建的产品被用户以一种“破解”或“误用”的方式使用——即并非按最初设计，而是为了满足某种特定需求时，这就能引导开发者了解产品的下一步走向。Facebook Marketplace 就是一个典型例子。该团队的创始经理 Fiona 经常谈到这一点。Marketplace 的诞生源于 2016 年左右的一个观察：当时 Facebook 群组中竟然有 40% 的帖子是关于买卖东西的。这太令人难以置信了，人们在“滥用”群组功能来实现交易。这种“滥用”并非指安全问题，而是指人们在没有专门设计的情况下，想方设法利用现有工具达成目的。显然，如果能构建一个专门的买卖产品，用户一定会喜欢。所以，从创建专门的买卖群组到最终推出 Marketplace，逻辑是非常清晰的。
👤 主持人 A： Facebook Dating 的起源也非常相似。当时的观察发现，在个人资料浏览量中，有 60% 的流量来自非好友关系的异性用户。这其实就是传统的约会模式，人们在互相“窥探”。如果能为此构建一个专门产品，成功的概率就会很高。所以，潜在需求的概念非常强大。
👤 主持人 A： 例如，Cowork 的诞生也是如此。在过去半年里，我们发现许多使用 Claude Code 的人并不是在编程。Twitter 上有人用它来研究番茄种植，有人用来分析基因组，有人从损坏的硬盘里恢复婚礼照片，甚至有人用它分析核磁共振图像。这些用例完全超出了技术范畴。很明显，用户为了完成这些任务，不惜费劲周折地去使用复杂的终端工具。我们意识到，也许应该直接为他们开发一个产品。其实早在去年五月，我就看到了这种苗头。我记得走进办公室时，看到数据科学家 Brendan 的电脑上运行着 Claude Code。我当时很震惊，问他：“Brendan，你在干什么？”他竟然掌握了如何操作终端，这可是非常硬核的工程化产品，甚至很多工程师都避之不及。但他学会了使用终端，下载了 Node.js 和 Claude Code，然后在终端里进行 SQL 分析。紧接着下一周，所有的数据科学家都在做同样的事情。
👤 主持人 A： 当你看到人们以这种非设计用途的方式“滥用”产品来解决问题时，这强烈预示着你应该开发一个专门的工具。我认为现在的潜在需求还有一个有趣的维度：传统的框架是观察人们在做什么，并让它变得更容易；而过去六个月我看到的现代框架略有不同，那是观察“模型”正在尝试做什么，并让它变得更容易。
👤 主持人 A： 最初构建 Claude Code 时，很多人设计 AI 产品的方式是将模型关在一个“盒子”里，规定它只能完成某个特定组件，并限制它与 API 交互的方式。但在 Claude Code 中，我们颠倒了做法。我们认为产品就是模型本身，我们希望暴露它的能力，只提供最少量的脚手架和工具，让模型自主决定运行哪些工具以及执行顺序。这很大程度上是基于模型自身表现出的潜在需求。在研究中，我们称之为“在分布上（on-distribution）”。你想观察模型尝试做什么，在产品术语中，这与潜在需求是完全相同的概念，只是应用对象变成了模型。
👤 Boris： 你提到了 Cowork，我记得它发布时你说过团队只用了 10 天就构建完成了，这太不可思议了。发布后很快就有数百万人使用。除了是用 Claude Code 构建的，这背后还有什么故事吗？
👤 主持人 A： 是的，很有趣。Claude Code 发布初期并没有立即大火，它是随着时间推移，经历了几个转折点才爆发的。比如 Opus 4 发布时是一个转折，11 月又是一个转折，之后增长就越来越快。但在最初几个月，很多人不知道怎么用它，模型在那时也还不够完善。
👤 主持人 A： 相比之下，Cowork 一发布就立即大受欢迎，热度远超早期的 Claude Code。坦率地说，这要归功于 Felix、Sam、Jenny 所在的强大团队。Cowork 的诞生正是源于那种潜在需求。我们看到人们用 Claude Code 做非技术任务，团队探索了几个月，尝试了各种方案，最后有人提议：“如果我们把 Claude Code 封装进桌面应用程序会怎么样？”这个方案奏效了。于是，他们完全利用 Claude Code，在 10 天内构建了它。
👤 主持人 A： Claude Code 内置了一个非常复杂的安全系统，即确保模型不脱轨的“护栏”。例如，我们随它发布了一个完整的虚拟机，而 Claude Code 编写了所有相关代码。我们只需要考虑如何让它对非工程师用户更安全、更具引导性。这个过程只花了约 10 天。虽然发布时还很粗糙，现在也仍有不完善之处，但这正是我们学习的方式：必须比预期更早地发布产品，通过用户反馈来了解真实需求，从而塑造产品的未来。
👤 Boris： 这种“尽早发布、向用户学习”的理念非常独特。在 AI 领域，甚至很难预知 AI 能做什么以及人们会如何使用它，这使得尽早发布变得尤为重要。正如你所说，这能帮你发现那些之前无法预见的潜在需求。
👤 主持人 A： 没错。对于 Anthropic 这样一个安全实验室来说，这还涉及另一个维度：安全。考虑模型安全有不同的研究层面。最底层是对齐和机械可解释性。在训练模型时，我们利用先进技术追踪神经元的活动。例如，如果某个神经元与欺骗行为有关，我们现在已经能监控它何时被激活。这是第一层。第二层是评估（evals），即在实验室的“培养皿”环境中模拟情境，观察模型的表现是否安全。第三层则是观察模型在真实环境中的表现。
👤 主持人 A： 随着模型变得复杂，第三层变得至关重要，因为模型可能在实验室表现良好，但在现实中却不尽如人意。我们很早就发布了 Claude Code，部分原因也是为了研究安全性。实际上我们在内部使用了四五个月才发布，因为当时并不确定。它是第一款被广泛使用的编码代理，我们必须在内部长时间研究，直到对安全性感到满意。即便如此，我们后来学到的关于对齐和安全的知识，依然在不断反馈到模型和产品中。
👤 主持人 A： Cowork 的情况也类似。模型处于新环境中，执行非工程任务并代表用户行动。它在对齐和评估方面表现良好，内部及部分客户的试用反馈也不错，但我们必须确保它在现实世界中同样安全。这就是我们将其作为“研究预览版”提前发布的原因。通过不断改进，这是确保模型长期保持对齐并做正确事情的唯一方法。
👤 Boris： 你所处的领域确实疯狂，既有激烈的竞争，又要担心失控造成的损害。平衡这两者极具挑战。你提到的安全处理分为三个层面：观察模型运作、测试评估以及提前发布。我之前很少听到关于第一部分（观察模型“大脑”）的内容，这非常棒。
👤 主持人 A： 是的，你们以后应该邀请 Chris Olah 来节目，他是这个领域的专家。他开创了“机械可解释性”研究。核心思想是，大脑是一堆相互连接的神经元，你可以从机械层面研究人脑或动物大脑，了解神经元的功能。令人惊讶的是，这种研究同样适用于模型。虽然模型神经元与生物神经元不同，但行为模式非常相似。
👤 主持人 A： 我们已经掌握了大量关于神经元如何映射到特定概念、如何编码、如何规划以及如何提前思考的知识。很久以前，人们不确定模型只是在预测下一个 token，还是在进行更深层次的思考。现在已有有力证据表明它确实在做更深层的事情。现在的结构非常复杂，随着模型增大，不再是一个神经元对应一个概念，而是一个神经元可能对应十几个概念。当它与其他神经元共同激活时，这种“叠加”状态代表了更复杂的概念。
👤 主持人 A： 我们一直在学习这些知识。对 Anthropic 而言，以安全且有益的方式推动领域发展，是我们存在的初衷。我们开源了很多工作，自由地讨论研究成果，就是为了激励其他实验室也以安全的方式进行研究。这也是我们对 Claude Code 的态度。我们内部称之为“争优竞赛（race to the top）”。例如，我们为 Claude Code 发布了一个开源沙盒，确保代理在运行是有边界的，无法随意访问系统内容。这个沙盒适用于任何代理，我们希望让其他人也能轻松实现安全防护。这就是我们的原则：通过提供工具和杠杆，确保整个行业向好的方向发展。
09 AI时代的焦虑与编程新范式
👤 Boris： 很棒。我肯定想在这方面投入更多时间，也会跟进这个建议。我在工程师、产品经理以及其他与 Agent（代理）打交道的人群中还注意到一件事：当 Agent 停止工作时，人们会感到一种焦虑。那种感觉就像是，“天哪，有个问题急需回答”，或者它被什么东西卡住了。我感觉自己正在丧失生产力，必须赶紧把它唤醒，让它重新运行。你有这种感觉吗？你的团队有这种感觉吗？你觉得这是我们需要关注和思考的问题吗？
👤 主持人 A： 我手头总是有很多 Agent 在运行。比如现在，我就有大约五个。我每天醒来后的第一件事就是启动一堆 Agent，因为我急着想检查某些东西。我会打开手机上 Claude iOS 应用的代码标签，让 Agent 去处理各项任务。因为我昨天写了一些代码，我总在反复琢磨：“等等，我写对了吗？”虽然结果证明是正确的，但现在验证这些实在太容易了。所以，也许确实存在一点焦虑，但我个人感受并不深，因为我一直让 Agent 跑着。而且我不再被束缚在终端（Terminal）里了。现在我的代码大约有三分之一在终端里完成，三分之一使用桌面应用，还有三分之一竟然是在 iOS 应用上完成的。这很令人惊讶，我没预料到即便到了 2026 年，我还会以这种方式编程。
👤 Boris： 我很喜欢你依然将其描述为“编程”，尽管本质上是与 Claude Code 对话并让它代写代码。有趣的是，这确实就是现在的编程——重点在于描述你想要什么，而不是编写实际的代码。
👤 主持人 A： 我很好奇，那些以前用打孔卡编程的前辈如果看到现在的软件会作何感想。我记得在早期 ACM 杂志上读过，当时的人们认为这根本不是一回事，觉得“这不是真正的编程”。有趣的是，他们当时就称之为“编程”（programming），我觉得“编码”（coding）这个词反而是后来才流行的。这让我想起我的家人，我出生在乌克兰，我爷爷是苏联最早的程序员之一，他就是用打孔卡编程的。我妈妈常讲她小时候的故事：爷爷会把一大叠打孔卡带回家，她就在上面用蜡笔乱涂乱画。那是她的童年记忆，但对爷爷来说，那是他的编程生涯。他其实从未亲历向现代软件开发的转型，但行业确实在某个节点完成了过渡。我想，可能曾有一代老程序员根本不把现代软件开发当回事，觉得这不算真正的编程。但我认为，这个领域一直以来都是这样不断演变的。
10 构建AI产品的策略与使用技巧
👤 Boris： 好的，我想再深入请教几个问题。你刚才分享了一些非常棒的技巧，关于如何充分利用AI、如何基于AI进行开发，以及如何用AI打造优秀的产品。其中一个技巧是给团队尽可能多的token，让他们去大胆实验；另一个普遍建议是“面向未来构建”，即针对模型未来的能力而非现状进行开发。对于那些正在尝试开发AI产品的人，你还有什么建议吗？
👤 主持人 A： 我再补充几点。首先，不要试图限制模型。很多开发者在基于模型构建应用时，本能地想让模型以一种极其特定的方式运行，将其视为大型系统中的一个固定组件。常见的做法是叠加非常严格的工作流程，比如强制要求执行第一步、第二步、第三步，并使用复杂的编排器来管理。但实际上，如果你只是给模型提供工具并设定目标，让它自己去解决问题，结果几乎总是更好。一年前，你确实需要很多这种“脚手架”来辅助，但现在真的不需要了。这个原则可以理解为：不要过度管理模型，不要试图把它框死，也不要提前塞给它一堆上下文。相反，给它工具，让它自己去获取所需的上下文，你自然会得到更好的结果。
👤 主持人 A： 第二个原则是“苦涩的教训（The Bitter Lesson）”，这可以看作前一个原则的普适版。Claude Code团队的成员应该都读过Richard Sutton在大约十年前写的这篇博客。它的核心观点非常简单：更通用的方法（模型）总是会胜过针对特定领域设计的复杂方法。他当时谈论的是自动驾驶等领域，但这个观点有很多推论。对我来说，最重要的一点就是永远押注于更通用的模型。从长远来看，不要试图执着于小模型或过度依赖微调。虽然某些特定场景确实需要这些手段，但只要条件允许，请务必选择更通用的模型。那些复杂的工作流程本质上是在通用模型周围搭建脚手架，虽然短期内可能提升10%到20%的性能，但随着下一个更强模型的出现，这些提升往往会变得毫无意义。所以，与其费力搭建脚手架，不如等待下一个更强的模型。
👤 主持人 A： 第三个原则，也是Claude Code最成功的经验之一：从第一天起，我们就押注于为“六个月后的模型”构建产品，而非当下的模型。在产品的早期版本中，我们写的代码其实很少，因为当时我对Sonnet 3.5（或后来的更新版本）的编程能力还不够信任。那时模型只能帮我处理一些git操作或自动化琐事，无法完成大规模编码。但Claude Code的赌注是：模型终究会进化到能胜任重度编码工作的程度。这个转折点出现在Opus 4和Sonnet 4发布时——那是我们去年五月推出的首款ASL3级别模型。当时我们看到了增长的指数级爆发，并一直延续至今。所以我常给创业者的建议是：即使产品在最初六个月里没有很好的市场契合度（Market-Fit），也会感到很不舒服，但只要你是为六个月后的模型能力而构建，那么当新模型发布时，你的产品就能瞬间爆发，占据先机。
👤 Boris： 当你提到“为六个月后的模型构建”时，人们应该基于什么假设去预测？是假设它在某些特定方面会变得更好，还是说如果它现在已经表现出某种苗头，就预判它在那方面会产生质变？你有什么具体建议吗？
👤 主持人 A： 这是一个很好的切入点。显然，在AI实验室内部，我们能预见到模型具体的进化方向，这确实有点“信息差”优势，但我们也一直在尝试公开讨论这些趋势。一个确定的方向是：模型将越来越擅长使用工具和操作计算机，这一点我敢打赌它会在很长一段时间内持续进步。另一个观察维度是“自主运行的时间长度”。从我的经验来看，一年前使用Sonnet 3.5时，它运行15到30秒就会开始“脱轨”，需要你手把手引导才能完成复杂任务。但现在的Opus 4.6，平均可以无人值守运行10、20甚至30分钟。我可以同时启动多个Claude实例让它们独立工作，有些甚至能持续运行数天乃至数周。我认为这种“长程运行”将变得越来越普遍，你不再需要时刻坐在那里照看它们。
👤 Boris： 关于构建AI产品的技巧我们聊了很多。那么对于刚开始使用Claude Code，或者想用得更精通的人，你有什么专业建议或“黑科技”可以分享吗？
👤 主持人 A： 首先声明，使用Claude Code并没有唯一正确的标准路径。它是一个开发工具，而开发者的偏好和环境各不相同，所以你可以灵活探索。好在你可以直接询问Claude Code，它了解自己的设置，能为你提供建议。不过，我个人觉得有几个技巧非常实用。
👤 主持人 A： 第一，务必使用最强大的模型。目前是Opus 4.6，并且我总是开启“最大努力（Best Effort）”模式。很多人为了省钱会尝试用成本较低的模型（如Sonnet），但因为低阶模型不够聪明，完成同一任务可能需要更多的轮次和纠错，最终消耗的token反而更多。所以，使用最强模型往往不仅效果更好，实际上也更便宜、更高效，因为它能一次性做对，减少了反复指导的成本。
👤 主持人 A： 第二，善用“计划模式（Plan Mode）”。我大约80%的任务都是从计划模式开始的。这个模式的逻辑很简单：我们在提示词中注入一条指令，要求模型“暂时不要编写任何代码”。这并不深奥，但非常管用。终端用户只需按两次Shift+Tab即可进入，桌面端、网页端也都有专门的按钮，移动端和Slack集成也即将上线。在计划模式下，模型会先和你沟通方案，一旦计划达成一致，再让它执行。配合Opus 4.6，它几乎每次都能在执行阶段一次性写对，我只需要自动接受编辑即可。
👤 主持人 A： 第三，尝试不同的界面形态。很多人提起Claude Code就想到终端（Terminal），虽然我们完美支持Mac、Windows等所有终端环境，但我们也提供了iOS/Android应用、桌面应用以及Slack集成等多种形式。每个工程师的工作习惯不同，我建议大家多尝试。你不必拘泥于终端，因为后端运行的是同一个强大的Claude代理。
👤 Boris： 太棒了。最后再问几个关于行业竞争的问题。你对Codex怎么看？你觉得他们的发展方向如何？在编码代理这个竞争极其激烈的领域，他们是如何与你们竞争的？
👤 主持人 A： 说实话，我没怎么深度用过Codex，只在它刚发布时体验过。它看起来和Claude Code有些相似，这其实让我们感到很荣幸。我认为有竞争是好事，用户应该有选择权，这也会促使我们做得更好。坦率地说，我们团队的精力完全集中在解决用户问题上，并不会花太多时间去研究竞品或尝试其他产品。了解它们的存在是必要的，但我更喜欢把时间花在与用户交流、根据反馈迭代产品上。对我来说，打造一个好产品才是核心。
👤 Boris： 最后一个问题。我之前和Anthropic的联合创始人Ben Mann聊过，他建议我问你一个问题。他给出的很多建议我已经融入到之前的对话中了，但他特别想知道：在实现AGI（通用人工智能）之后，你有什么计划？一旦我们达到了那个目标，无论它具体意味着什么，你的人生下半场想做什么？
👤 主持人 A： 在加入Anthropic之前，我住在日本的农村，那里的生活方式与旧金山截然相反。我是镇上唯一的工程师，也是唯一说英语的人。每周我会骑车穿过稻田去农贸市场，节奏非常缓慢。我最喜欢的一点是，邻居之间通过交换腌菜来建立友谊。在那个小镇，每个人都会制作味噌和腌菜。我也学得不错，现在还在坚持做。制作味噌很有趣，它教会你用长远的眼光思考，这和工程学完全不同：一小批白味噌至少需要三个月，而红味噌则需要两到四年。你必须极具耐心，混合好原料后就静静等待。我非常喜欢这种长周期的思考方式。所以，如果实现了AGI，或者哪天我不在Anthropic工作了，我可能会去专职制作味噌。
👤 Boris： 我太喜欢这个答案了。Ben让我问你关于味噌的故事，很高兴你分享了它。所以你的未来可能就是追求味噌的极致。这太棒了，Boris，我觉得我们现在像兄弟一样亲近。在你进入激动人心的闪电问答环节之前，还有什么想对听众强调或分享的吗？
👤 主持人 A： 我想强调一下Anthropic的愿景。从一开始，我们思考模型进化的路径就是从编码能力出发，延伸到工具使用，再到计算机使用。这不仅是我们构建模型的方式，也是我们研究和提升安全性的方式。现在，围绕Claude Code已经形成了一个巨大的业务，我身边的朋友都在用它，并不断给我发反馈。这在某种程度上是个惊喜，因为我们最初并不知道它会进化成现在的产品形态，也不知道它会从终端起步。但在另一方面，这又在预料之中，因为这始终是公司的信念。同时，我觉得一切才刚刚开始。世界上绝大多数人还没开始使用Claude Code，甚至还没开始使用AI。我们只完成了1%的工作，前路漫漫。
👤 Boris： 看到那些财务数字，这种“早期感”简直不可思议。你们筹集了巨额资金，据我所知，仅Claude Code一项就创造了20亿美元的收入，而Anthropic公布的总收入甚至达到了150亿美元。在如此惊人的数字面前，你依然觉得这只是早期阶段，这太疯狂了。
👤 主持人 A： 确实令人难以置信。Claude Code之所以能持续增长，完全归功于像我们一样的用户。大家对这款产品充满热情，不仅爱用，还会直言不讳地告诉我们哪里不好用、想要什么功能。产品能不断改进的唯一原因，就是每个人都在使用、讨论并提供反馈。这对我来说是最重要的。我理想的生活方式就是：白天与用户交流、改进产品，剩下的时间就去制作味噌。
👤 Boris： 你只需要耐心等待味噌熟成。好的，Boris，接下来进入闪电问答环节。我有五个问题，准备好了吗？
👤 主持人 A： 开始吧。
👤 Boris： 第一个问题，你最常向别人推荐的两三本书是什么？
👤 主持人 A： 我非常爱读书。先推荐一本技术书：《Scala函数式编程》。这是我读过最好的技术书。虽然现在大家可能不怎么用Scala了，但书中关于函数式编程和类型思考的优雅逻辑，深刻影响了我的编码方式和思维模式。你可以把它看作一件提升思维的艺术品。
👤 Boris： 我喜欢这个推荐，这本书很少被提及，也是我的最爱。
👤 主持人 A： 太好了。第二本是查尔斯·斯特劳斯的《加速世界》（Accelerando）。我主要看科幻小说，这本书节奏极快，完美捕捉了我们这个时代的精髓。故事从技术起飞前夕开始，逐渐接近奇点，最后以木星轨道上的集体意识结束，而这一切仅发生在几十年间。那种速度感非常震撼。第三本推荐刘慈欣的《流浪地球》。大家都知道他的《三体》，但我认为他的短篇小说集更精彩。中国科幻的视角与西方非常不同，写得极其优美且引人深思。
👤 Boris： 科幻小说确实能帮我们预演未来的各种模型，让我们在现实发生时觉得“我见过这个世界”。
👤 主持人 A： 没错。对我来说，科幻小说甚至是我加入Anthropic的原因。当时我住在日本农村，生活极其缓慢，一切随四季更迭——柿子季结束就是葡萄季。那种长周期的生活让我开始思考长远的时间尺度，而读科幻小说让我意识到，我知道未来会如何发展，我必须参与其中去贡献一份力量。这最终促使我联系了Ben Mann并来到Anthropic。
👤 Boris： 我真想专门做一期节目聊聊你的日本之旅。顺便我也给你推荐一本科幻小说：弗诺·文奇的《深渊上的火》，它从AI和AGI的角度看非常有趣。
👤 主持人 A： 是的，我看过，那是维吉的作品。我也很喜欢它的续集《天渊》。
👤 Boris： 那本书很复杂但非常棒。继续闪电问答：你最近有没有特别喜欢的电影或电视剧？
👤 主持人 A： 坦白说，我几乎不看电视或电影，最近实在没时间。不过，我看了Netflix版的《三体》，我觉得那是对原著非常棒的改编。
👤 Boris： 看来AI领袖们都没时间看电视。那么，你最近有没有发现什么特别喜欢的产品？
👤 主持人 A： 稍微“推销”一下Cowork吧，因为它确实改变了我的生活。它的Chrome集成功能非常出色，帮我处理了交交通罚款、取消订阅等各种繁琐事务。另外，除了Lenny的播客，我非常喜欢Ben和David的《Acquired》。他们深入挖掘商业历史的方式太棒了，建议从任天堂那一集开始听。
👤 Boris： 关于Cowork，给没用过的人解释一下：你只需输入目标，它就能自动操作浏览器帮你完成任务。我听说Anthropic有人休陪产假时，用它自动填写了极其复杂的医疗PDF表格。
👤 主持人 A： 没错，它现在真的非常可靠。一年前我们做过类似实验，但当时模型能力不够，现在它真的能用了。很多人还没意识到这种“代理”的威力，它给我的感觉和一年前的Claude Code非常像，但增长速度甚至更快。
👤 Boris： 而且那个Chrome扩展可以让你实时看着Claude在浏览器里操作、总结页面内容或进行对话。
👤 主持人 A： 对。对于想尝试Cowork的人，我建议下载Claude桌面应用，进入Cowork标签页。你可以先试着让它执行简单的工具任务，比如清理桌面或回复前三封重要邮件。第二步是尝试跨工具连接，比如“查看重要邮件并汇总到电子表格”。我甚至用它管理整个团队的项目状态：它每周一会自动检查电子表格，给没填状态的工程师发Slack提醒。第三个技巧是并行运行多个任务，你可以同时启动好几个Claude代理，然后去喝杯咖啡，让它们自己搞定。
👤 Boris： 我会分享一个关于Claude Code非技术用例的帖子。很多时候人们只是缺乏想象力，一旦看到例子就会惊叹“原来还能这么用”。
👤 主持人 A： 是的，其中很多灵感也来自你，Lenny。你发过一个关于Claude Code的50个用例的帖子，我们的产品经理在发布Cowork前，就是用那50个案例来做评估的。当Cowork能完成其中的48个时，我们就知道它可以发布了。
👤 Boris： 哇，我竟然无意中成了你们的评估员，这种感觉很棒。
👤 主持人 A： 这叫“反向突破”。
👤 Boris： 太酷了。好的。
👤 Boris： 我很好奇最后两个问题是什么。好的，还有两个问题。你有没有一句在工作和生活中经常回味的人生格言？
👤 主持人 A： 运用常识。我认为我看到的很多失败，尤其是在工作环境中的失败，都是因为人们未能运用常识。例如，他们不假思索地遵循流程，或者随波逐流地去开发一个糟糕的产品或想法，而没有独立思考。我认为最好的结果往往源于人们从第一性原理出发，并发展出自己的常识。如果某件事感觉不对劲，那它可能就不是个好主意。所以，这是我给同事们最多的一个建议。
👤 Boris： 我觉得光是这一点就能聊出一期播客了——什么是常识？你是如何构建常识的？但我们还是长话短说。最后一个问题：你最近在 Twitter（也就是 X 平台）上变得更活跃了，我很好奇你为什么这么做，以及在那里的体验如何？因为你在 X 平台上获得了大量的互动。
👤 主持人 A： 很长一段时间里，我只用 Threads，因为我以前参与过 Threads 的开发。我喜欢它的设计，它是一个非常简洁的产品，这一点很吸引我。我开始用 Twitter 其实是因为无聊。去年十二月，我和妻子在欧洲环游，去了哥本哈根等几个不同的国家。对我来说，那更像是一个“编程假期”——我每天都在写代码，那是我最喜欢的度假方式，整天编程的感觉太棒了。后来有段时间我略感无聊，有几个小时没什么灵感，我就想接下来该做点什么？于是我打开了 Twitter，看到有人在讨论 Claude Code，我就开始回复。
👤 主持人 A： 然后我想，也许我应该做的一件事就是寻找用户遇到的 bug 或反馈。所以我做了自我介绍，询问那些有很多反馈的人。我想他们对我们处理反馈的速度感到惊讶，但对我来说这很正常。如果有人发现 bug，只要描述清楚，我可能几分钟内就能修复，因为我动作很快。处理完之后，我就会去忙别的事，或者回复下一个问题。这种互动对很多人来说相当令人惊讶，但体验真的很酷。在 Twitter 上的感觉一直很棒，能直接与人互动，了解用户需求，并听取关于 bug 和功能的反馈。
👤 Boris： 前几天我在 Twitter 上看到有人向 Nikita Beer 抱怨，他们发了很多帖子，结果系统崩溃了，当时大家都在想：天哪，这是怎么回事？
👤 主持人 A： 是的，确实有个 bug。我希望现在已经修复了。
👤 Boris： 很棒。噢天哪，Boris，我能和你聊上好几个小时，但我该让你走了。非常感谢你分享这一切，你太棒了。大家可以在哪里找到你？听众们能如何帮助你？
👤 主持人 A： 在 Threads 或 Twitter 上找我，那是最好的地方。请在相关内容上 @我，发送 bug 或功能请求。还缺少什么？我们能做些什么来改进产品？你喜欢什么、想要什么？我非常乐意倾听。
👤 Boris： 很棒。Boris，非常感谢你的到来。
👤 主持人 A： 酷，谢谢，很有趣。大家再见。