今年的重点：让 AI 实践扩散、自动化审查、建设远程环境
大家好吗？刚才我们听 Scott 讲了大家如何转向云端 Agent。今天台上还有几位知名编程 Agent 的负责人。这类圆桌的好处就是，我都不用逐个介绍各位了。让我特别兴奋的是，你们正在各自的社区里定义软件工程的未来。如果把今年想推动的事情概括一下，最重要的主题是什么？先从 Cat 开始。
好。我想有三个主要方向。第一，我们在合作的企业里看到，大概 10% 的人真正摸透了 AI，从中得到了巨大的生产力提升；另有 90% 的人还不知道怎样把它的价值发挥到最大。我想推动的是创造一些机会，让那 10% 的人把最佳实践分享出去。可以是黑客松、工程团队全员大会上的演示，也可以在 Slack 里使用类似 CloudTag 的工具，让大家公开地展示自己怎样工作。
第二，很多人告诉我，代码审查已经成了瓶颈。因此我们内部花了大约 6 到 12 个月尝试把代码审查自动化。这既包括构建大量评测，也包括回顾过去发生的每一宗事故，确保从事后视角看，代码审查确实能抓到当时的问题。把代码审查自动化，起初会觉得任务大得吓人，过程也不会短，但做成以后非常值得。
第三，一定要投资远程开发环境。等你真正准备让这些 Agent 自动运行任务时，需要一个能支持所有工具、所有依赖包，并运行全部测试的开发环境。要把这套环境调顺需要不少时间，所以越早动手越好。
这句话对 Modal 真是太友好了（笑）。这些话题后面还会深挖。现在也想先听听 Dax 的总体方向。
是，我们的想法很相近。我认为编程 Agent——实际上所有 Agent——都有这样一个问题：
用 Slack 中的共享 Agent 扩散最佳实践
它们开箱即用时已经不错，但只要有人花时间配置、接入其他系统，能力就会好得多。不幸的是，在任何组织里，不可能人人都愿意吃这份配置的苦。可如果一个人配置一次，全公司就都能使用，那种工作方式就开始在组织里传播。你刚提到了 CloudTag，我们也有类似的体会：Slack 很合适，因为大家本来就在里面。如果团队在同一个 Slack 里和同一个 Agent 协作，它每天都会变得更好用。
总会有人主动说：「嘿，我给它接上 ElevenLabs 吧，这样它就能替我们生成音频了。」接好以后，整个组织就都能用上这项能力。所以很重要的一点，是把 Agent 放进团队协作的过程中。真的非常好玩，我们团队这么工作特别开心，比一个人单独使用有意思多了。这是第一件事。
第二件是成本，也就是这一切到底要花多少钱。显然，你我所在的公司都能想用多少 token 就用多少，成本并不是最主要的限制；但世界上绝大多数人没有这种条件。
编程 Agent 的真实成本：从每月几十美元到薪资级支出
每家公司心里都有一笔账：我们的收入是多少？人均收入是多少？如果员工成本突然翻倍，不是所有公司都承受得了。所以我们现在在思考，怎样把推理服务的价格压到一个利润率大约只有 10% 的业务所能接受的水平。
我想追问几个具体的成本数字，毕竟我以前做过金融分析师，也听到过其他人的一些数据点。假设普通用户每月花 20 美元使用编程工具，普通开发者可能是 200 美元，前沿模型实验室的员工大概是 2,000 到 5,000 美元。最顶层、百分位极高的那群人，开支可能达到几十万甚至上百万美元。这个区间大致合理吗？大家应该怎样看待自己或客户的成本上限——如果他们真的设有上限的话？
在公司内部我们没有设置成本上限，但我们相信工程师会负责任地使用。我认为其中一个关键，是让支出可见。我们每周末都会给公司的每一个人发一份报告，告诉他：「这是你本周最贵的几个任务。」这样每个人就能自己检查、自己调整。我们发现这确实让成本下降了不少。
对，不过我更多是想问外部用户。我不知道现在是否已经有一个普遍标准……人们聊 token 排行榜、疯狂刷 token 也有一阵子了。但今年夏天，舆论风向似乎明显变了，大家开始说：「好，先克制一点。」我现在心里粗略的目标，其实是员工薪资和 token 支出接近一比一。不知道这样是不是太高了。这个数量级算合理吗？
我觉得完全取决于你是什么类型的公司。如果一家公司团队很小，却能创造数亿美元收入，那 token 支出在总体上就只是九牛一毛。团队再怎么用，可能也不会对整个业务造成什么实质影响。对我们来说，相对团队规模，我们的收入还不错；公司总共只有 25 个人。目前如果拿工资总额和 token 成本相比，后者大概是工资的 1 到 2 倍。因此平均每名员工的总成本，差不多成了原先的 2 到 3 倍。
是，这很夸张。
但从我们的财务全局看，这实际上没多大关系。如果换成传统的非科技公司，它们能承受的倍数要低得多，根本没有这么宽裕的试错空间。
明白。想回到刚才的一点。Cat，你之前在后台跟我们聊过一些细节……
Anthropic 如何用事故回溯和评测实现代码审查自动化
关于你们怎样搭建整套事故复盘机制和自动代码审查。我想这可能是你被问得最多的问题。Anthropic 是怎样逐步解决它的？是用了六个月吗？
其实做做停停过一段时间，但过去六个月我们真的把重心放在这上面，取得了很大的进展。
那就从起点讲起吧，带我们走一遍这个过程。
好。我们最初在内部推广 Claude Code 时，第一感觉是：哇，大家提交的 PR 数量变成原来的十倍了！可是资深工程师马上被十倍的代码审查任务淹没。我想对多数工程师而言，代码审查大概是工作中最不喜欢的环节。我们很快意识到必须解决这个问题，却还不确定当时的模型能力是否足够。
所以我们试过几次，随后决定用更严格的方法推进。我们遍历所有代码库，挑出一些确实需要有分量审查意见的 PR，再从中筛出「合并前无论如何都必须修复」的关键意见。我们把这些整理成一套评测，并确保覆盖全部核心产品，包括 CLI、桌面端的 Cowork、聊天产品、桌面端 Claude Code 等。过去大约四个月里，我们一直沿着这些评测指标反复优化。
另一个重要目标是减少事故。我们原本就有事故复盘流程：每周开会，检查所有相关事故记录。往回追查，每次事故最后往往都能追溯到一两个导致事故的 PR。我们就把这些 PR 拿来，对自动代码审查提出要求：「下次必须抓到这个 PR 里的这类问题。」每次事故复盘，又会给评测集增加案例，然后回测新版代码审查，确认准确度没有倒退。这样持续运行了大约六个月，最终我们已经能自动审查绝大多数 PR。
你怎么看？你们的流程也类似吗？
是。
OpenCode 不做传统代码审查：作者必须为改动负责
我们从来就不是一家做代码审查的公司，所以算是……直接避开了这个问题（笑）。不过现在确实也出现了新问题，因为已经有别的东西在替我们写代码了。
澄清一下：你们对每个工程师的要求，就是自己审查自己的代码，然后自己决定发布？
对，完全正确。向别人苦苦请求帮忙审查，那种感觉太痛苦了。真正的问题是：怎样有把握相信即将发布的改动是好的？这是我们努力让每个人培养的一项能力。说到底这都很新，我们自己也在摸索。我甚至觉得传统代码审查也没想象中可靠：给别人一个很小的 PR，他可能写一大堆反馈；给他一个巨大的 PR，他却会说「嗯，看起来没问题」，因为没人愿意读，也真的没人读，最后大家还一起假装审过了。
所以，面对大范围代码变更，我们要怎样建立信心？我们的做法，是不断跟 Agent 讨论改动：「这里呢？那里呢？」你利用自己的经验，有意识地向它追问某些点；自己也快速扫一遍代码，看看有没有明显不对劲的地方。我们发现，一旦你指出几个问题，它往往就会重新通盘检查并改写整个方案，顺手也把别的问题修好。
我脑中有个画面：这很像捏陶器。你一遍又一遍地整体塑形，直到最后看上去是对的；而不是从第一行读到最后一行，试图一次性给出所有逐行意见。
嗯。
对我们来说，Anthropic 可以从模型本身着手解决这个问题；但我们不在模型那一层工作。我们更像普通公司，只是在思考团队怎样把这些工具用好。
我特别赞同这个文化层面的观点：代码作者必须负最终责任。许多公司都需要经历这样一次文化转型。因为一旦真正实现了代码审查自动化，你最终信任的还是作者本人的判断力。代码审查有点像「瑞士奶酪模型」：你想把一层层奶酪上的漏洞都堵住，可归根结底，作者仍然必须能为这次变更背书、承担责任——哪怕之后 Claude 已经盖章通过了。
对。为了树立这种文化，我们偶尔还会在 Slack 频道里公开训斥某个人（笑）。
哇。这段真好。如果我现在是在录一档播客，肯定会把「瑞士奶酪模型」直接打开给观众看。DataSpace 上的置顶帖子讨论的头号问题，就是怎样消灭代码审查。我们往前推演一下：从过去走到今天，再过一年会怎样？你们能不能做个预测，说说代码审查以及软件开发流程可能会走向哪里？
下一步：少看代码，还是让工作彻底脱离人工循环？
具体说说，有哪些今天还做不到、但你们希望将来做到的事？
我也不知道。说真的，谁知道一个月后会发生什么？就像刚才说的，我们现在看的代码都比以前少了。每个人在这条连续谱上的位置不同，但大方向应该一致：无论你现在看得有多细，未来都会比过去看得更少。所以问题最终还是，你怎样对自己交付的东西建立信心？
就我们所在的层面而言，关键还是利用目前已经有的工具得到这种信心。这是一种我们正在培养的技能，我不认为我们的团队一定会发明什么新工具、新技术。我只是想让团队学会提出正确的问题；如果某个没仔细关注的地方出了岔子，大家应该真的在意、真的感到不安。这其实是个老问题：怎样让人更在乎自己的工作？过去一直如此。
Cat，你会怎样展望？
未来确实很难预测。但我们正在更积极地推动大家问自己：「我每天到底在重复做什么？为什么我还身处这个循环之中？我怎样教会 Claude 在 99%、乃至 100% 的情况下替我做掉它？」很多自动化工作其实卡在「半自动」阶段：Claude 做了 80%，你仍然需要做剩下的 20%，于是每天还是不断重复同一件事。
远程开发环境：值得指定专人消灭一切摩擦
因此我们给团队的一项要求是：要能认出自己什么时候陷入了这样的局面，并投入精力把半自主运行变成完全自主运行，好让时间真正释放出来，去做别的事。即使因此要少做一些新功能，也值得。
这刚好可以过渡到另一个建立工作信心的话题：你们的远程开发环境。我觉得很有意思的是，现在大家对这种环境的基本要求已经高得惊人，比如人人都期望里面有浏览器。Codex 最近宣布从 gVisor microVM 转向完整虚拟机，当然 Modal 一直都在做这类事情。你们对每个人应该具备什么开发环境，有什么强烈的主张？
我们自己提供远程开发环境，也允许用户带来自己的远程开发环境。我觉得最重要的事，是公司里必须有一个人专门负责把远程开发环境打磨得非常好，不断清除每一个摩擦点。不管你选择的是 Modal、OpenCode、Codex，还是其他什么方案，都需要这样一个人。
因为开发者都喜欢本地工作。在本地，你几乎不用考虑网络问题，以及各种意想不到的麻烦。第一次转到远程时，你会收到成千上万条投诉，大家都会说「这对我根本不好使」。我的建议是找到一个真正相信这条路的人，让他一项项坚持解决问题，因为要想做成，几乎只有这条路。
前期投入确实很大，但一旦环境运转起来，你就可以随时随地写代码，自动化任务能够自己跑、测试也能自己跑。甚至非技术人员都能在 Slack 里 @Codex 或其他服务，让 Agent 直接提交修复 PR。所以它值得你在最开始投入资源。
对我们来说也是这样。其实在有 AI 之前，我自己就一直在用远程开发环境。我在自己住的城市放了一台性能很强的服务器，延迟很低，所有工作都通过它完成。我很喜欢那种感觉：机器一直开着，一直在那里；换个设备连进去，就能从上次停下的地方继续。
这是我该插播一个 SSD 广告的时候吗？还是说……
不，这只是我的……
这个切入点太好了（笑）。
我就是一直很喜欢拥有自己的机器，直到今天仍是这样。作为程序员，那种感觉挺好的。
而且在做 OpenCode 以前，Dax 就在云基础设施领域做过很多事情，这个也可以聊。
对。我们喜欢云，不怕用云。以前我一直以为自己的配置非常小众：我所有操作都通过 SSH，编辑器用 Vim。我觉得这么玩很有趣，但从没认为大多数程序员都应该复制这种模式。
现在有了 AI，这件事变了。你可以用一台远程机器，却不必懂得怎样管理它，甚至不需要知道里面的所有细节；你真正关心的是如何跟运行在上面的 Agent 对话。所以越来越多人开始采用类似方式，因为他们想要你刚才说的那种体验：边走边写代码，随时继续工作。
我觉得这里有两个版本，就是经典的「宠物和牲畜」（pets vs. cattle）之分。我的服务器是一只宠物：我多年精心布置，里面有各种只属于我的配置。如果明天把它清空，我可能都没法原样重建。这样的模式有它的好处。
另一种是「牲畜」模式。它要求组织极其严谨：怎么销毁机器、再把它重新启动到一个可用状态？怎么确保每台机器都有人人需要的精确配置和工具？怎么一下子启动一千台？这很难。但就像我先前说的，你只需要团队里有一个人每天花一点时间改进它。
比如我们有一个例子：我们的协作全部发生在 Slack 中。
一个工程师接通 macOS，整个团队的 iOS Agent 就升级了
我们在 Slack 里有一个 OpenCode 机器人，它会运行 sandbox 来完成工作。后来我们开始开发 iOS App，起初大家觉得只靠输入提示词就可以推进。直到有天有人说：「我想实际把这个 iOS App 跑起来、测试一下。」于是有人特意给自己的 Agent 接入一台可以通过 SSH 访问的 macOS 机器。Agent 现在能在那台机器上启动 App、录下运行画面。第二天，我们所有人就在 Slack 的回复里看到新增功能的演示视频。
一夜之间，整个系统就变得更好用了——只因为一个人愿意花时间把这件事搞定，结果人人受益。你需要团队里有这样一个在乎这些事、也喜欢做这些事的人。尤其在大组织，大多数人不会主动去折腾；但如果有人愿意解决一个问题，它带来的好处就能成倍扩散到所有人身上。
对。这其实是一种很常见、但讨论得还不够多的组织转变。到了某个规模——也许是 50 人或 100 人——真的值得配备一个人，他唯一的工作就是让团队里其他所有人跑得更快。他要去观察：大家在做什么？瓶颈在哪里？因为每个人都忙着交付功能，不太可能突然停下来优化构建时间之类的东西。你提到的自动录制并回放视频的能力，就是一个很关键的摩擦点。
从 CLI 到桌面端：给开发者和非技术用户不同入口
对，对。那就是最经典的开发者体验（developer experience）工作。
我想到另一个关于软件工程未来的变化，刚才你们后台也提过：你们两家一开始都是 CLI、终端工具，现在都有桌面端了。这个转换背后的用户规模和趋势是什么？大家应该从中读出什么？
我们最早做 CLI，是因为它最方便快速开发，也最方便别人安装。只要运行一行命令，就不必先下载一整个庞大的 Mac 应用。但后来发现，越来越多非技术用户开始学习怎么用终端。
有一次我坐在市场团队的 Nicola 旁边，看她在终端里安装 Claude Code。屏幕上不断弹出吓人的提示框，她问我：「Cat，这正常吗？」后来我们应用 AI 团队的一位同事，专门给 Anthropic 的非技术员工写了一份文档，列出安装 Claude Code 时可能遇到的所有提示框——居然有大约 20 个。文档几乎每隔一行就写：「别担心，这很正常。」「你不需要明白它是什么意思，直接点 OK 就行。」我当时就想：这绝对不能是我们面向大众的产品体验。
当时团队还很小，重心仍然集中在终端上，但我们越来越明显地感觉到：其他很多人也想要能力很强的 Agent。现实中大多数软件都是图形界面，于是我们有非常强烈的动力去服务那些希望更直观、更可视化的人。
甚至在工程师内部也是这样。很多前端开发者其实更喜欢桌面端，因为 Claude 可以替他们运行 App、展示视觉效果；在终端里如果不做一番非常复杂的折腾，很难做到这一点。
现在早期用户中有很多仍然使用 CLI，但刚开始接触 AI 编程或 AI 知识工作的新人，往往直接从桌面应用入门，因为它友好得多。终端非常依赖纯文本，而不少新用户更喜欢通过成品、幻灯片或文档看到 Agent 做出来的工作。Claude Desktop 能把这些产物当成一等公民来呈现；终端的形式毕竟存在一些限制。
我们的出发点稍有不同。我们就是一群迷恋终端的人，喜欢在里面折腾一切。
还在终端里买咖啡。
没错！我们一开始甚至在终端里做过一家咖啡店。我们就是喜欢这样，也知道刚才说的这种玩法可能非常小众。因此从一开始设计 OpenCode 时，我们就采用无头（headless）架构：后面运行一个服务器进程，终端只是连接它的一个客户端。因为我们知道，大多数人其实不应该被迫使用终端。
反常的是，现在使用终端的人实在太多了。甚至我们这里，每月都已有数千万人使用终端界面。我觉得这不太对：让这么多人用终端，已经过头了。行业可能有点过度向终端倾斜。
不过终端也有自己的优点。它限制很多，比如不能自由设定不同字号，所有字得一样大。这会迫使你在设计上非常聪明。终端应用通常非常干净、性能很好。我们甚至能在终端里显示图片，所以即使受限，仍然可以做不少事情。
为什么终端不该是所有人的默认界面
但很难说它应当成为每个人默认使用的体验。尤其看看我们的数字、Claude Code 的数字，以及其他公司的数字，大家实际看到的用户规模已经明显超过了传统意义上「程序员」这个群体的规模。
一个 Agent，多种界面：跨终端、桌面、Slack 和手机延续会话
这个市场现在大得多了，AI 明显扩大了潜在用户范围。所以默认体验很可能应该是网页或桌面应用；我们两家公司也都在这方面投入不少。我们现在的比例是：月活用户中，大约三分之二仍使用 TUI（终端界面），三分之一使用网页或桌面端。后者增长得比终端更快，未来两条曲线会相交。我觉得那才是正常的状态。
太好了。我喜欢这种大致的份额数字，让大家能校准预期。不过我自己已经有点疲惫、也有点困惑了：我到底应该在哪里用 Agent？终端里有，桌面应用里有，Slack 里有，现在各种聊天软件里也有。这些产品还都想进我的 iMessage。你们怎样平衡这些入口？我知道你们大概会说「用户在哪儿就去哪里」，所以什么都支持。但用户最后主要会选择哪个？这些界面会整合到一起，还是会一直并存？
我们现在的策略确实是到用户所在的地方服务他们，同时确保无论你在哪一个入口，都能看到从其他入口发起的所有会话。这点目前还没做到百分之百，比如 Claude Tasks 的会话还不能在 Claude.ai 里看到。但我们希望各个平台都能做到：从任何地方启动，也能从任何地方查看。
这些统一在 Claude Projects 之下吗？那是共同的组织入口？
它们会出现在侧边栏。对。
我之前也经常听 Anthropic 讲这件事。上周我刚和 Tarik 录过播客，聊到的概念有点像「云端大脑、本地双手」：桌面也好、终端也好，都是 Agent 的本地表现形式，而 Agent 本身应该存在于云端，不受当前使用哪种界面所限制。
我们的定位和这个有些不同。多数产品默认要求登录：你注册 Anthropic 账户，有云端体验，即使运行本地应用，背后也有一个中心枢纽，因此比较容易把体验统一起来。我们的切入点不一样，因为 OpenCode 默认不是一款必须登录的应用。你在自己的机器上运行它，而我们要想办法让你也能在手机上继续同一段会话、从不同设备看到不同地方的会话，却不能强迫你把数据交给我们的后端。
理想情况下，你跨设备使用，可以完全不和我们的服务器通信；也可以慢慢过渡，选择在我们的云端运行一部分工作，从而获得更多能力。这使得「用户在哪里，我们就在哪里」对我们复杂得多，所以通常会比别的公司稍慢一点。
但最终，只要有文本输入框的地方，你大概就会想要一个 Agent。我现在的 iMessage 里，Agent 发来的消息比真人还多，因为所有产品我都试。我收到的基本都是 Agent 向我汇报邮件里发生了什么。我都不确定自己喜不喜欢这样，但正在试验。
过去六个月，我们把大量精力放在底层原语（primitives）上：这些基础能力的设计合理吗？能否在很多地方复用？用户要不要用云服务，都有没有一条自然、顺畅的升级路径？
模型还不会什么：第一性原理、架构判断与选择该做的事
现在我们尝试把这些基础能力拼装成各种有趣的产品形态。我觉得其中不少最终会消失，但我们总得逐个试，看看什么真正说得通。
很好。接下来聊聊模型仍然不擅长的事情。你们每天都在能力前沿工作，肯定不断碰到问题。还有哪些类别没解决？很多人已经觉得「软件工程被解决了」，显然并没有。为什么？
天哪，我真希望现在能给在座各位发个问卷，问问大家究竟还缺什么、下一版有什么希望改进的。
产品经理开始上班了（笑）。
对！我真的希望大家更大声地告诉我们，希望模型改进什么。对于字幕所称的「Phi-5」这一版，我们主要瞄准的是 token 效率、成本效率、写作风格和沟通质量。
我认为还需要大幅进步的方面之一，是第一性原理推理。我自己和许多知识工作者一样，用 Claude 写文档。但它对逻辑链条、业务背景的理解，还不足以完整走通「为什么应该或不应该做出某个商业决定」的所有理由。它比以前好了很多，但从第一性原理出发思考，以及清晰交流这种推理，仍有提升空间。
代码方面，我们一直在努力提升它做架构决策的能力。每个模型版本都会进步，但如果我们看自动代码审查无法直接盖章通过的那些改动，通常涉及大的架构判断。Claude 有时做出的决定，和资深工程师的判断还不完全一样。我相信新模型会继续改善，但现在还没到完全可靠的程度。
我很想听你们的反馈，只是不确定最好的收集机制是什么。我在 Twitter 上的用户名是 `_catwu`。欢迎告诉我们使用感受，这样我们可以把反馈融入下一版模型；你们二位也一样。
对我们而言，至少对我自己来说，最大的难题是决定「究竟应该做什么」。我大概 90% 的精力都用在这上面。机会是无限的，可是该做什么？又该怎样做？我也会和 Agent 讨论，它是个有用的思考伙伴，但并没有真正替我解决这个问题，我也不指望它解决。我认为这本来就是人的职责：哪些事情值得投入资源？现在能做的事太多了，其中绝大多数恐怕是坏主意，所以筛选仍然极其重要。
我看到很多公司现在什么都发布，因为他们做得到；但我不觉得这样会带来真正优秀的产品。
第二，我们做的是一个让别人基于它继续开发的产品，错误决策很难撤回。如果我们发布一个 API，除非以后做一次破坏兼容性的大版本升级、惹得所有用户不满并承担后果，否则它就会一直存在。所以，每当我们要给新概念建模时，得特别谨慎。
举个例子：现在正在出现一种字幕称为「decision models」的模型类别，OpenCode 显然需要从产品层面理解它。我们已经有「模型」的概念，也有「提供商」的概念，这种新模型应该怎样放进体系？如果你直接叫 Agent 加上支持，它第一次给出的方案几乎肯定是错的。
因此我特别喜欢我们 Slack 里的机器人。我们团队称这种过程为「集体拷问」（gang grilling）：两个人甚至更多人一起追问机器人，直到大家找到一个很好的设计。我真的很享受这个过程。倒不是抱怨模型「为什么不能独自解决」；它虽然没有替我们直接给出答案，但团队两个人和它讨论，就能把几乎所有可能的实现路径都推演一遍，最后对方案的信心比过去高出很多。
以前没有足够时间思考所有可能性，往往只好选脑中冒出的第二个主意，然后直接往下做。
让模型进入软件内部，而不只是悬浮的聊天框
现在我们却可以把每个可能的版本都仔细想一遍。我以前写过一篇帖子，说「我宁愿做一个能试一千次的笨蛋，也不愿做一个只能试一次的天才」。LLM 让我们获得了反复尝试的能力，最后总能逐渐磨出好的结果。
既然提到这种新模型，我一定要问一个当下热门的话题。TypeSafe 稍后也会来，我还请 Diogo 上过播客。他们其实不喜欢「decision models」这个叫法，因为听起来像旧式机器学习概念；他们更愿意称之为「System 1 models」。但我觉得真正的方向是让软件本身变聪明。
你们两家现在做的 Agent，主要是帮人生产软件：无论是 SaaS、普通应用还是手机 App。Diogo 想做的则是把模型直接嵌入软件本身。我们现在还没看到太多这种形态，也就是超越网页应用旁边那个附带的聊天机器人。你们怎么看这个问题？怎样让模型成为软件运行循环的一部分，而不是浮在软件之上的一层？这是个很开放的问题。
我认为这完全是成本问题。当价格下降到一定水平，就会解锁现在根本无法预见的使用场景。我联合创始人前几天还举了个例子：「理论上，如果价格足够低，地球上每一个红绿灯都可以运行一个 LLM 来做某种判断」，或者用其他某类模型做判断。
听起来有点可怕。
是有点，但不冒险哪来回报？这些疯狂应用场景唯一的障碍，基本上就是经济性。为什么不能让一个 LLM 检查我系统产生的每一条日志？或者由某种模型逐条查看？所以这个领域有意思的地方，是价格可能低到难以置信，然后会冒出非常特别的应用。
每种新技术都这样。你预测不到它最后会被用在哪儿，但你知道应该努力让它更容易获得、更便宜，实际用途自然就会出现。
对，这让我很有共鸣。比如，计算机操作（computer use）如果变得非常便宜，就应该让它直接替你使用 SaaS 应用。很多消费产品利润率很薄，今天还无法负担让每个用户拥有一个能够随意操作整套界面的 Agent。但若成本降到原来的百分之一，也许就可以了。也许 Claude 或者其他 Agent harness 能代替你使用 SaaS。我们正在向这个方向走，我很期待它给 SaaS 的未来带来什么。
对。从经济学上，我们都看得到潜力。但工程上怎样真正做到也很有趣，因为毕竟有物理限制：这么多参数能提供多少能力？又需要多少能量和内存？各种成本会不断累积。
工程师招聘：从「按规格交付」转向产品判断力
所以一百倍的降本究竟从哪里来？过去三四年，能够挤出来的效率我们已经挤出很多了。这仍是一个很好的开放问题。最后一个部分，我想留给软件工程招聘、未来的工程师招聘。你们招了很多人，在座各位也几乎都与招聘有密切关系，每个人都有观点。你们的招聘标准是怎么变化的？
我们招聘最主要的变化是：在 AI 以前，有一种所谓的「10 倍工程师」。产品经理带着一份细致的规格说明来，告诉他具体要做什么，哪怕变更很棘手，这位工程师也能按时、高质量地完成。以前这几乎就是业界最理想的标准。
现在，至少在我们的产品工程团队里，我们更看重一个人有没有很强的产品品味（product taste）。他不需要别人把每个细节都写进需求规格书；他会主动多花时间接触客户，不只弄清楚客户要什么功能，还要理解他们为什么要这个功能、其他客户是否也有同样的需求、有没有能同时满足所有人的通用解决方案。
对很多工程师而言，这是比较新的能力。我们发现越来越多人开始学会这一点；随着 Claude 和其他模型在写代码方面越来越强，它也会越来越重要。如今我们团队花很多精力在回答你刚才提过的那个问题：「我们到底应该建造什么？」
这不应该只是产品经理的工作。团队里的每个人，包括设计师、工程师，都需要把更多心智资源投入到判断：基于我们对客户、用户和市场掌握的所有信息，真正最重要的产品是什么？每个人都必须培养商业意识和产品判断力。我们正在积极招聘拥有这些能力的人。
对。我们的情况有点特别，因为我们一直是小公司，到今天还是。我们从来没什么专业化分工的空间，没有特别细分的岗位，每个人什么都得做。这就是我们的现实。
另一点是，我们开发的产品恰好也是团队每个人每天都在用的，因此要求工程师懂产品很容易。我知道很多工程师写的软件，是给完全不同的用户群使用的；那种情况下同时兼顾开发和产品会有挑战，但我觉得仍然应该努力做到。
我是这样理解产品工作的：每天有无数人在对你喊：「我需要解决这个问题！还有这个问题！」现在给每条 issue 接一个 LLM，直接逐条解决，已经太容易了。但你真正的工作是看出来：「等等，这九个 issue，仔细看其实是同一个问题。」只要做一个东西，就能顺便把九个问题都解决。
我觉得这种思考特别有趣，而且多数工程师其实也会喜欢这种看问题、做产品的方式。只是以前，正如你说的，这可能并不被视为工程岗位最重要的能力。
我们还有另一项变化：简直想无限招聘设计师，因为我们的交付速度提高得太多了。传统那种主要在 Figma 里工作的设计师，至少在我们团队里，AI 并没有显著放大他们的产出，我们也没看到太多这方面的变化。结果设计团队总是追不上其他人的节奏。
所以我们开始寻找非常出色的设计工程师（design engineers）：他们的设计能力几乎可以和设计师相比，对产品要呈现什么样子有自己的主张。
设计工程师、招聘面试与开源贡献者筛选
他们有自己的审美判断，而且能亲手把设计做出来。很多这种人通过 AI 获得了巨大的能力提升。我们在想，能不能调整团队组织方式：让设计工程师主导设计，按需要再拉正式设计团队进来制作某些具体素材？因为我现在简直感觉自己在把设计师一铲铲往火炉里送，烧得飞快，却怎么都不够用。
你们刚讲了产品和设计方面看重的素质。那有没有哪些以前会做、现在不再做的事情？比如我猜已经不考 LeetCode 了吧。我想替大家了解一些可以直接复制的具体招聘实践。你们谈了很多人才特质，但我也想知道流程怎么变了；毕竟我们得尽快把这些招聘问题弄明白。
我们会请候选人走一遍他们曾参与过的产品战略、商业战略决策，重点是那些必须依靠自己的技术专业知识，才能给战略带来有价值判断的场景。
明白。
我们尤其关注他们有没有超越狭义工程师的岗位范围，主动提出：「我们的产品战略是不是应该换个方向？」过去做过这些事的人通常很有主动性，未来也更可能继续这样做。我们认为这是一个很强的信号，因此面试里专门安排机会，让人展示这样的过往工作。
很好。
我们是开源产品，因此有一条很独特的招聘渠道。现在的开源世界像战场，像地狱，简直是《疯狂的麦克斯》或者角斗竞技场。无数 PR 源源不断地涌来，一团混乱，尤其是我们这样规模的项目。
如果有人能从这种混乱里脱颖而出，那他一定非常厉害。有些人在海量低质量提交的轰炸之下，仍然能认真理解我们正在做什么，准确找到自己能帮上忙的地方，并作出真正有意义的贡献。现在要做到这些太难了，因此谁能做到，我们就认为他很出色。我们的一些最佳员工就是从这个渠道招来的。
但不能说我们只靠这一条路招聘。说实话，我们还没找到别的特别靠谱的方法；也在像其他公司一样不断尝试。
提高野心：一名工程师一个月，做过去全队半年的事
我一直觉得招聘本来就有很大的随机性。你可以设计一套流程，但最适合你的人可能根本就没申请这个职位。直到一个人跟你共事了一段时间，你还是不真正知道他有多合适。每次招到优秀同事，我都觉得自己运气很好：回想当初做决定时，我其实并没有那么确定，完全可能错过他。所以直到今天，我对招聘依然感到困惑，觉得它很随机。
是啊。我一直在等有人有一天站出来说：「其实我们准备停止招聘了，接下来交给 Agent 就行。」看来还没到那一步。这倒是我判断 AGI 的标准：公司什么时候开始不招人了。
好，最后一个问题。关于软件工程的整体未来，还有什么话想留给大家？希望大家关注什么？或者你们对未来有什么期待？谁先答都行。
我觉得每个人都应该提高自己的野心。你可能已经觉得自己这么做了，但我还是希望大家真正再往前推一把。我们团队新加入过一些人，他们完全重塑了整个团队做事的方式，也抬高了我们愿意承担的任务规模。
现在你能完成的事情真的多得多。记住，95% 的想法可能都很糟糕，所以也别什么都做。但过去完全不现实的任务，现在也许可以承担了。
举个很小的例子：我们产品里有个看似琐碎的 UX 问题，但我们很在意，也一直在琢磨。后来发现，我们可以训练一个小模型，按希望的方式把使用场景分类，从而解决这个用户体验问题。以前为了一个这么小的缺陷，根本不可能有人批准「专门训练整个模型」。现在却可以。
所以你手里有了非常多的新选择。未来的关键，是你对自己能做成什么事，应该怀有高得多的期待。
说得很好。我们最近经常讨论一个概念，叫「可能性的艺术」（the art of the possible）。
这个说法好。
我觉得我们的工作有一部分，就是不断发现今天究竟有什么已经成为可能，然后把它分享给全世界，启发更多人：原来只需要一名工程师、一个月时间，就能把这件事做成！而以前可能需要一整支团队忙六个月。
是。我也想说，虽然大家对 Twitter 爱恨交织，我确实从你们发的案例里学到很多新可能性。比如有人说 Opus 5.5 很擅长做视频，谁会想到呢？
我知道！
以前为了这种事情，我会给外部代理公司付几千美元。现在我至少能自己先做出一个原型，用它比单纯的语言描述更好地沟通需求。
嗯，甚至还可以做音乐。
完全可以。
我们的开发者关系（DevRel）团队现在就大量使用 Claude 来剪辑所有视频、处理帖子，然后分享给大家。
现在不断发生那种「四分钟跑完一英里」式的突破：只要有人率先做到，其他人就会突然意识到「原来这也能行」，然后类似的成果就会一下子大量涌现。这是个激动人心的时代。
是。时间到了。Cat Wu 在 Twitter 上叫 `_catwu`，欢迎向她提出各种需求——Claude Code 的功能需求……
对，还有模型功能需求。哪些做得好、哪些不好，都欢迎反馈。
没错。至于 Dax 的 Twitter 账号，字幕这里把用户名转写成了「PhD XR」，我不确定拼法。
别 @ 我了，我已经花太多时间刷 Twitter（笑）。
我就不打扰你们了。结尾还有一句关于 Claude Desktop 的玩笑，自动字幕无法可靠辨识原句。好，感谢两位拨冗参加，也祝在座各位大会愉快！
好的。