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