整理 & 编译：深潮 TechFlow

嘉宾：Mike Krieger，Instagram 创始人

主持人：Dan Shipper

播客源：Every

原标题：Mike Krieger Lets Fable 5 Code While He Sleeps

播出日期：2026 年 6 月 11 日

要点总结

Mike Krieger 曾作为 Instagram 的联合创始人，亲手缔造了过去二十年里人类世界最具影响力的消费级应用之一。而今天他正在“智能体原生（AI-native）”产品开发的最前沿，作为 Anthropic Labs 的掌舵人，他带领团队死磕一个终极命题：当把世界上最顶尖的 AI 模型交到真正的开发者手中时，技术的能力边界究竟能被推向何方？

在 Fable 正式发布前的五个月，当他在内部第一次拿到这款模型的体验权限时，那种震撼与失速感让他至今记忆犹新。“得，我觉得自己又成了一个彻头彻尾的新手，”他当时这样对团队自嘲。他突然发现，自己过去几十年沉淀下来的关于效能提升、研发战略乃至时间管理的经验法则，在这一瞬间全部宣告过时。模型的进化速度，已经彻底甩开了他原有的工作流。

在本期节目中，主持人与 Mike Krieger 展开了一场深度对谈，带大家一同窥探：与 Fable 这样跨时代的硬核模型并肩作战、共同构建软件，究竟是一种怎样的体验？在这场人机共生的新常态下，又催生出了哪些全新的研发律动、严峻挑战以及充满想象力的终极可能？

精彩观点摘要

Fable 如何彻底重塑了 Mike 的工作流

• “真正的认知升级来自几周高强度的持续使用，而绝非第一天的尝鲜体验。……随着相处时间变长，人们突然意识到：‘我之前对它的压榨还不够狠。我得再往前推一步，重新思考这一代模型的能力边界到底在哪。’”
• “现在的正确姿势是：向它传达更宏观、更充分的意图，然后彻底放手让它去跑。它不仅能一次性给出令人惊艳的成果，更可怕的是，它能理解这个功能后续的演进方向以及整个项目的全局上下文。”
• “最让我被折服的，是它自动闭环的能力。比如它会这样思考：‘Mike 让我今晚跑一个复杂任务。但我被卡住了，因为远程服务器挂了。那好，我先自己写个 mock 后端顶上去……’对我来说，能够把这种级别的任务委托出去，并且完全信任它的最终产出，这种体验极其震撼。”
• “过去我们总把这类模型比作‘助手’或‘伴侣’，但现在，它更像是一个真正可以背锅、可以交付大量核心工作的‘硬核队友’。”

什么时候用 Sonnet，什么时候用 Fable

• “那完全不是一个量级的体感。这甚至都跟每秒输出多少 Token 无关，而是这道题到底需要被塞进多少脑容量去思考的问题。有时候，一个简单的答案根本不需要那么多加戏的深度思考。”
• “绝大多数时候我扒拉 iOS App，大概率不是为了干那些需要惊动 Fable 的重活。……那种‘这问题根本配不上 Fable，我应该叫 Sonnet 出来答’的微妙心态，我最近确实深有体会。”
• “Fable 也是我遇到的第一个会让我主动去调节‘努力程度’（Reasoning Effort，推理力度）的模型。……以前用 Opus 的时候我基本不调这个，因为那时候模型能伸缩的弹性区间没这么大，但 Fable 的跨度真的可以拉得很宽。”

Fable 5 催生的 Agent-native 架构

• “所谓的 Agent-native 架构，它的第一阶段是：产品里的每一个核心组件和数据，都必须对 Agent 保持完全开放，并且都有对应的工具调用接口。这正在迅速变成软件行业的温饱线——虽然可悲的是，现在市面上绝大多数软件连这一点都做不到。”
• “在 App 里长按聊天按钮，就会唤醒我们的托管 Agent 来接收‘代码修改指令’……我带娃在外面玩的时候，发现‘这个悬浮按钮在 iOS 上的位置太靠下了’，我直接在 App 里对它说一句，它自己就跑去后台把代码修了。”
• “Claude 到底该如何嵌入软件？它不应该只停留在‘使用’层面，它更应该深度嵌进软件的‘构建’骨髓里。”

构建成本已经坍缩

• “回顾 Instagram 的 V1 版本——功能确实比我这周末做的媒体追踪器要多一些，但绝对没有数量级上的本质差异。而当年做出那个 V1，我和 Kevin 大概连着爆肝了五个通宵……而现在呢？构建时间确实被缩短到了令人发指的地步。”
• “从‘意图’到‘执行’之间的那条鸿沟，对于不懂代码的普通人来说，已经被拉平了。……这是我人生中第一次，感觉到自己脑子里想的东西，和现实世界里存在的东西之间，竟然可以毫无距离。我直接就能把它做出来。”
• “人类的创造力是无穷无尽的，而我们今天在做的最了不起的一件事，就是无限地扩大了‘有能力将心中所想变为现实’的群体边界。”

软件工程死了吗？

• “软件工程的内涵已经完全变了。它正在经历一场翻天覆地的剧变。……纯敲代码的匠人时代，大概率真的已经一去不复返了。”
• “高级工程师的角色依然不可替代：你需要靠多年的事故响应经验去保持绝对冷静、全量收集日志数据、实施紧急止血，然后再去推演根本性的长效修复方案。”
• “以前硅谷流行一句话叫‘用代码赢下争论’（Code wins arguments），我个人其实一直不太感冒，因为它潜台词在说谁会写代码谁就掌握了话语权。但现在，事情反过来演进得非常有意思：有时候我们对产品的某个走向相持不下，结果经常是某个不写代码的 PM 跑过来说：‘我刚才自己动手搓了一个 Demo……’这瞬间就开启了一个完全不同的高维对话。”
• “最明显的特征就是恐怖的开发并行度，以及团队对工作流进行高阶抽象的绝对刚需。但唯独有一件事从始至终没有变过，那就是人类对产品的‘所有权与责任感’。”

验证的机制与价格

• “现在的‘成本’已经进化成了一个多维度的概念——你要算的不仅是‘单次提问的成本’，更是‘彻底把一件事办妥的综合成本’。Fable 最让我惊艳的地方恰恰在于后者：它总是倾向于一次性把事做对，不需要我坐在电脑前跟它大战八九个回合。”
• “适应这种新常态，搞清楚怎么跟它共事，是我们所有人都需要学的。……每次我搭东西的时候，我怎么确保 Claude 的每一个 PR 都附带了照片或视频——不管是 iOS PR 还是 UI 层的改动。这帮你获得了很多信心。”
• “视频是给 Claude 的一个极度未被充分利用的工具。我最近在做一个原型：把 Claude 构建出来的东西做成视频录像交给它，配合 FFmpeg，看着它自己逐帧分析，然后说‘这个动画有卡顿，我去修’。截图永远不会捕捉到这个，因为截图错过了那个瞬间。”

动态工作流

• “在前几代模型的温饱线里，项目往往存在一个‘复杂度天花板’。一旦你的业务代码或者逻辑堆叠到了一定体量，大模型就会开始‘顾头不顾屁股’……但现在，这位不懂代码的女同事，在 Fable 这个级别的模型加持下，已经把她的系统在后台连着养了几个月。你能清晰地看到那个软件像一个活生生的有机体一样，在 AI 的灌溉下持续生长、生长、疯狂进化。”
• “工作流是一个好的中间地带，你用 chat 来编排它，但它是用代码表达的，然后在一个干净的 UI 里面执行，每一步都在展示发生了什么。我觉得我们以后会用类似的方式来把长视野的工作和 chat 连接起来。”

Fable 如何彻底重塑了 Mike 的工作流

主持人 Dan Shipper： 本期邀请到的嘉宾是 Mike Krieger，他既是 Anthropic Labs 的负责人，也是 Instagram 的联合创始人。Mike，我特别想听你聊聊深度使用这个模型后的真实体感。当一个如此强大的模型发布时，如果有一个每天都在重度使用它的人出来说："它在这些地方强得离谱、在哪些地方切实改变了工作流，而在另一些地方其实也就那么回事"——这能帮大家真正想明白，技术到底该怎么融入自己的日常生活。

Mike Krieger:

确实如此。这段经历本身就很有意思。在 Fable 正式发布前的几个月里，我们内部其实已经用上了几款 Mythos 级别的模型。当时我很期待看外部开发者会用它们做出什么，但正如你所说，真正的认知升级来自几周高强度的持续使用，而绝非第一天的尝鲜体验。

我们在之前的模型上也经历过这种认知重塑。去年十二月底到今年一月初，大家集中使用 Opus 4.5 和 4.6 的时候，随着相处时间变长，人们突然意识到："我之前对它的压榨还不够狠。我得再往前推一步，重新思考这一代模型的能力边界到底在哪。"

主持人 Dan Shipper： 我们 Every 团队内部其实已经有一些同事在用了。有人反馈说："我觉得自己需要一套全新的技能树才能驾驭这个模型"，尤其是那些非技术背景、偏知识工作型的同事，他们甚至有点无从下手；而那些做 Agent（智能体）编排的同学则感叹："要学的新东西实在太多了。"

Mike Krieger： 你提到"转换工作流"这一点切中了要害——这不仅是指具体的操作步骤，更指观念上的转变。说来也巧，这个模型的出现刚好赶上我工作变动的窗口期：我当时刚从 CPO（首席产品官）转到 Labs，重新切回了开发者模式。大概转过去一个半月到两个月的时候，内部第一次跑通了这类模型。我坐在电脑前心想："得，我又成新手了。"因为我发现自己以前写 Prompt 的习惯，甚至拆解任务的思维方式，在这个模型面前已经完全过时了。

你的时间尺度感和交互模式都得进化。换作以前，我可能会说："我有个功能想法，咱们先从第一步开始——"现在绝对不能这样了。现在的正确姿势是：向它传达更宏观、更充分的意图，然后彻底放手让它去跑。 我记得在三四月份的时候，它表现出的能力就已经很震撼了——它不仅能一次性给出令人惊艳的成果，更可怕的是，它能理解这个功能后续的演进方向以及整个项目的全局上下文。

而且这种进化完全没有停止。今天早上我还和人聊起工作——在飞机上时，我意识到"绝大部分工作我其实都可以远程搞定"。我甚至不再焦虑 Wi-Fi 会不会断，因为只要我在断网前给它设定好正确的上下文和指令（比如一个循环执行的命令），它自己就能把事情盯到底。

过去两个月里，我经常经历这样的高光时刻：睡前跟 Claude 道个晚安，甩给它一个复杂的任务，第二天醒来发现它已经全部搞定了——通常凌晨两点它就完成了主体，剩下的四小时全花在打磨细节上。

最让我被折服的，是它自动闭环的能力。比如它会这样思考："Mike 让我今晚跑一个复杂任务。但我被卡住了，因为远程服务器挂了。那好，我先自己写个 mock 后端顶上去，把这个问题记录在文档里，先把整个流程跑通、存盘，等明天服务恢复了再修好。"对我来说，能够把这种级别的任务委托出去，并且完全信任它的最终产出，这种体验极其震撼。

当然，你事后肯定还要去审查结果——这涉及到一个完整的验证机制，我们一会儿可以展开聊聊，因为那是闭环中至关重要的一环。但这确实逼着我重新思考：面对这样的模型，到底什么才叫"高效"？过去我们总把这类模型比作"助手"或"伴侣"，但现在，它更像是一个真正可以背锅、可以交付大量核心工作的"硬核队友"。

主持人 Dan Shipper： 那你现在的日常工作流到底长什么样？我注意到一个现象：如果你丢给它一个宏大任务，对着它长篇大论，然后让它自己跑几个小时甚至过夜——这时候它的表现是最强的。但日常面对一些琐碎的小任务时，它又显得太慢、太贵，让人不太想用。在实际工作中你是怎么权衡的？它在你的技术栈里处于什么位置？

Mike Krieger:

我现在更多把它用在前期的架构规划和方案对齐上。这是一个很有意思的转变，也是目前所有模型都需要继续啃的硬骨头。

在这方面，我很感激当年做 Instagram 的经历——从最初在一台洛杉矶服务器上草草搭起最简版本，到后来做海量并发、做规模化，再到最后整体并入 Facebook 的基础设施。这个过程会让你培养出一种直觉，即"在项目的哪个阶段，应该用什么级别的架构抽象和复杂度"。

所以，我仍然会和 Fable 保持频繁的来回切磋。有时候它丢出来一个看似完美的实现方案，我会点它一下："我确实计划近期就把这个推上线——我们得考虑单机以外的承载能力。"这种双向互动非常重要。但在做架构规划时，我通常会直接让它生成一个 HTML 页面来视觉化我们讨论的内容，以便我分享给团队。哪怕是一份 Markdown 文件也行，但我更喜欢带图表的形式。

这就形成了一个很有意思的范式：和它一起把事情想透、规划好，然后产出一份文档去对齐团队。 既然现在大家构建原型的速度被极大地压缩了，你就更需要前置的共识和对齐——即便你打算先"小步快跑"做个 Demo 出来，再反向推导出更严谨的系统架构，前期的沟通也至关重要。而这恰恰也是人类的思考与协作仍然深深嵌入整个流程的地方。

到了执行阶段，无论是利用夜间还是大块的白天时间，让它去分头攻克不同的任务模块，意味着我同时维持着比以前多得多的并发会话。我有时喜欢开着一个长时间挂着的 Claude Code 会话，让它把任务全部 fork（派生）给后台的子 Agent 去跑，这样主线程就能随时响应我的新指令；有时我干脆在浏览器里同时开着五六个 Tab 页，让它们各自处理长周期的复杂任务。

这种具备长线视野、有一种"别担心，交给我，需要花点时间"的运作模式，里面确实大有可为。我们目前也在产品层面琢磨怎么更好地支持这种体验——你肯定希望兼顾"即时响应"和"长线挂机"这两种状态，它们之间的交互方式非常有意思。我个人的偏好是：手头至少保留一个高上下文且响应极快的 Claude 窗口，有一种"我随时待命，你一句话我就能原地启动或派生子任务"的直觉。

什么时候用 Sonnet，什么时候用 Fable

主持人 Dan Shipper： 那比如你正走在路上，突然有个问题——你会去掏出 Fable 吗？这感觉会不会有点像"拿火箭筒打蚊子"？还是说你会频繁地在不同模型之间来回切？

Mike Krieger:

前阵子我确实是干什么都用 Fable，然后体验就跟你说的一模一样——你盯着屏幕，看着它在那儿死命地想啊想。

直到上周，我想查一个让我都有点不好意思的简单问题，是关于 NBA 总决赛的。当时我切到了手机移动端的 Sonnet，瞬间反应过来："噢对啊！我以前查这种快问题都是用 Sonnet 的。"那完全不是一个量级的体感。这甚至都跟每秒输出多少 Token 无关，而是这道题到底需要被塞进多少脑容量去思考的问题。有时候，一个简单的答案根本不需要那么多加戏的深度思考。

对我们的产品团队来说，这同样是一个非常值得玩味的问题。总的来说，你肯定不希望让用户每天在前端纠结该选哪个模型。理想情况下，从长远来看，我们可以把它们收拢到几个极其直观、开箱即用的场景桶里；或者干脆直接按交互界面来做分流——因为说实话，绝大多数时候我扒拉 iOS App，大概率不是为了干那些需要惊动 Fable 的重活。所以在界面端做一层无感的模型固定，可能会是个思路。我们接下来得好好探索这在产品层面上究竟意味着什么。但那种"这问题根本配不上 Fable，我应该叫 Sonnet 出来答"的微妙心态，我最近确实深有体会。

你说得没错，对于那些高频、细粒度的互动型任务，Fable 会习惯性地自己往深了想。实际上，Fable 也是我遇到的第一个会让我主动去调节"努力程度"（Reasoning Effort，推理力度）的模型——有时候我坐在那想："我只是想改个 UI 样式，把它的努力程度调成‘中等’看个效果就行。"以前用 Opus 的时候我基本不调这个，因为那时候模型能伸缩的弹性区间没这么大，但 Fable 的跨度真的可以拉得很宽。

Mike 周末做的媒体追踪器揭示了 agent-native 架构的什么

主持人 Dan Shipper： 你能给我们看看你用它做过的东西吗？

Mike Krieger:

这一轮新模型发布时我们做了一件事——鼓励团队全员在自己的个人账户上用它，尤其是利用周末时间。这还挺有意思的，因为 Anthropic 内部有很多定制的生产力工具，所以偶尔退一步，回到最纯粹的状态："我就用纯粹的 Claude Code，周末给自己做点好玩的小东西。"这种感觉棒极了。

主持人 Dan Shipper： 你是在终端 app 里还是桌面 app 里跑的？

Mike Krieger:

好问题。我大部分时间还是泡在终端里。但好玩的是我太太——她不是专业工程师，背景更偏 UX（用户体验）设计师和 PM（产品经理）——她反而是通过桌面 App 彻底爱上了 Claude Code。我觉得桌面 App 帮她屏蔽掉了不少底层高深的抽象概念。不过我自己做这个项目时，用的还是 Ghostty 和终端。

我当时就想要一个完美的"媒体进度追踪器"——我平时打游戏、追剧，还会收到朋友各种安利，我需要一个完全符合自己收纳习惯的工具。我的两个核心标准是：一、添加东西要特别容易，直接跟 Claude 语音或打字说一句，它自己去全网搜索、补全信息并分门别类放好；二、主动推送，比如有新一季或者游戏续作，它能自动去找。

大部分 UI 是 Fable 一次性完成的，这已经很厉害了。但我在 Labs 今年一直在死磕的一条线索是：你怎么能让软件团队——现在这个团队就是 Claude——和软件本身贴得更近？

那是周六的一个早晨，我整个周末其实排满了带娃的行程，所以开发基本上全是"断续式"的：带孩子去爬山，回来，写两句，再出门。有时候在爬山途中我也会忍不住瞄一眼进展——虽然陪孩子时不该看手机，但在手机上远程盯着它的任务跑到哪一步了，那种感觉真的很爽。

我当时冒出一个想法：能不能顺手做个激进的实验，让软件从它内部实现自我修改？

我让它同时做了移动端和网页端两个版本。我本来就做了一个聊天交互界面，可以直接对 Claude 说"帮我把这个 URL 塞进追踪列表"。但我希望所有的软件都能进化出这种能力——我再也不想去各种层级复杂的菜单里翻找功能了。

Dan，在很多层面上，我其实是在尝试把智能体原生的架构推向最极致的边界。

所谓的 Agent-native 架构，它的第一阶段是：产品里的每一个核心组件和数据，都必须对 Agent 保持完全开放，并且都有对应的工具调用接口。 这正在迅速变成软件行业的温饱线——虽然可悲的是，现在市面上绝大多数软件连这一点都做不到。

我有一个很好的正面例子：前阵子有人给我安利了一部巴西神剧，讲的是戈亚尼亚的放射性物质泄漏事件。那名字巨长巨难记，我当时就对系统含糊地提了一句，Claude 立马帮我搜出来并精准归类了。这体验比我自己凭直觉去 Google 瞎找好太多了。

但我真正痴迷的下一步是：在移动场景下，直接从软件内部去修改软件本身，这会演变成什么样？

我做的——准确地说是我指使 Claude 做的——是这样一种交互：在 App 里长按聊天按钮，就会唤醒我们的托管 Agent 来接收"代码修改指令"，然后利用 Vercel 的实时预览（Live Preview）功能直接看效果。整个功能模块几乎也是一次性跑通的，非常酷，我后来还陆陆续续加了一些新点子。如果你是硬核玩家，你也可以去拉它的 Diff（代码差异）视图，或者点进托管 Agent 的对话历史里看它底层到底改了啥——不过我几乎从来不看，反正对个人玩具项目来说，我根本不在乎它的长期可维护性（笑）。

这玩意儿用起来简直太上头了。我带娃在外面玩的时候，发现"这个悬浮按钮在 iOS 上的位置太靠下了"，我直接在 App 里对它说一句，它自己就跑去后台把代码修了。配合 Expo 的开发工具链，它甚至直接在我的手机上完成了热重载（Hot Reload），那一瞬间的体验简直绝了。

这个东西需要达到能抗住百万用户并发的生产级水平吗？完全不需要。但它带给我一种极佳的掌控感：你不需要在周末结束、合上电脑那一刻让项目停摆——你可以一边重度使用它，一边在用它的过程中随时改造它。这种端到端的实时闭环，让你可以无限地迭代下去。

这不仅是 Fable 硬核工程构建能力的一次绝佳秀肌肉，也是你我一直在探讨的那个终极命题的缩影：Claude 到底该如何嵌入软件？它不应该只停留在"使用"层面，它更应该深度嵌进软件的"构建"骨髓里。

构建成本已经坍缩

主持人 Dan Shipper：我特别想让大家意识到一件事：类似这样的工具，你在十年、二十年前可能也能折腾出来，但绝对不是用这种方式。软件的构建成本已经迎来了断崖式的坍缩。 想想在当年做 Instagram 的时代，要把一个项目推到这种完成度需要砸进多少资源？现在又需要多少？帮我们量化一下这种时代的剧变吧。

Mike Krieger:

我经常会回想起那段日子。在 Instagram 成立早期，我一直觉得自己是一个效率极高的工程师——对移动端开发充满激情，对产品方向有着极强的直觉。但即便如此，当年从脑海中的一个点子到最终把它完整实现出来，中间依然隔着至少四到五个通宵的死磕。那会儿熬夜就是我的家常便饭：修仙到凌晨四点，然后睡到中午——这种作息完全跟家庭生活绝缘，但那确实就是我当年的" Builder（构建）模式"。

回顾 Instagram 的 V1 版本——功能确实比我这周末做的媒体追踪器要多一些，但绝对没有数量级上的本质差异。而当年做出那个 V1，我和 Kevin 大概连着爆肝了五个通宵：我一个人扛下了所有的前端和后端，Kevin 负责搞定初期的图片滤镜。而且，这还是建立在我们俩都有着多年 iOS 开发经验的基础之上的。

更别提当年的迭代节奏有多憋屈了。产品上线一炮而红之后，我们脑子里攒了无数的新想法，但当时的所有精力都只能用来确保服务器别在大流量下挂掉，或者勉强挤出时间加一个微小的增量功能。就拿 Hashtag（标签）功能来说，当时光写完它就花了我整整一周，而你手里其实还有一万个其他想做的事情被死死卡在排期里。

所以，这不仅仅是时间被压缩了——虽然构建时间确实被缩短到了令人发指的地步——更重要的是硬币的另一面：你现在可以用一种极其丝滑、极具流动感的方式，去即时迭代你手里已经有的东西。

而且，这种红利已经开始外溢，远远超出了像我这样的专业软件工程师和创始人的圈子。在以前，如果你有一个绝佳的商业点子但自己不会写代码，你的选择只有两个：要么找外包——这中间会经历极其严重的信息失真和差强人意的交付；要么就得去疯狂融资。但现在，从"意图"到"执行"之间的那条鸿沟，对于不懂代码的普通人来说，已经被拉平了。

前几天我收到内部一位同事的 Ping（消息）。我们帮她配置了一个内部工具，把 Fable 的能力和我们内部一些 MCP（模型上下文协议）的访问权限打通了。她是做招聘（HR）的，她激动地对我说："这是我人生中第一次，感觉到自己脑子里想的东西，和现实世界里存在的东西之间，竟然可以毫无距离。我直接就能把它做出来。"

那一刻对她而言，绝对是一个具有里程碑意义的震撼瞬间。如果换在四五年前，她要是想用一个专属的业务工具，要么只能用各种现成的软件缝缝补补瞎凑合，要么就得去苦苦哀求内部工具团队的工程师——而对方的 Jira 需求池里可能还排着 50 个优先级更高的需求。但现在呢？她自己正乐在其中地在代码世界里开疆拓土。

这也是我觉得未来最值得期待的地方：人类的创造力是无穷无尽的，而我们今天在做的最了不起的一件事，就是无限地扩大了‘有能力将心中所想变为现实’的群体边界。

软件工程死了吗？

主持人 Dan Shipper： 我完全赞同你的看法。但我估计现在很多人心里都悬着一个终极疑问。听了你刚才描述的这一切：软件工程这门行当，是不是彻底完蛋了？

Mike Krieger:

应该说，软件工程的内涵已经完全变了。它正在经历一场翻天覆地的剧变。

如果你在做 Instagram 的那个年代问我："到底什么是软件工程？"我大概会告诉你：把那些棘手的设计难题想透、把系统架构搭好，然后把大把大把的时间消耗在 TextMate 或 Xcode 里。去死磕 Django ORM（对象关系映射）的底层细节，然后部署上线、苦哈哈地修 Bug。现在这套流程里的绝大部分环节都已经被颠覆了，并且正在加速向产品管理的边界靠拢。现在，产品经理和工程师之间的那条楚河汉界，已经变得极为模糊。 这一点在我们自己的研发团队里表现得非常明显。

但如果你能从"软件工程"这个过于死板的字面定义里跳出来，去审视更广义的"软件生产"或者"软件开发"——而不是只盯着纯程序员写代码的那一小块盘子——你会发现这个行业不仅活得好好的，而且正处于前所未有的核心地位。

Fable 的出现，真正让我把对 AI 模型的信任带到了一个新高度——我开始放手让它去"跑通全自动闭环，甚至做合理的系统架构设计"。在技术执行这一侧，AI 已经走得非常非常远了。但"把控软件这门手艺的灵魂"——比如你究竟是在满足用户的什么痛点、你做出来的东西体验到底够不够惊艳——这些顶层的判断力，依然是极其纯粹、无法被机器替代的人类特质。

当然，这种阵痛式的转型，对很多人来说并不是无痛的。

在这个世界上，有太多人曾深深痴迷于"纯手工编写代码"的匠人手艺。我自己当年就是这样。"这个 Bug 憋了我三天，我今天解得真漂亮！"那种爽感是无法替代的。以前你甚至会在梦里和代码纠缠——如果你有过那种经历，梦里全是正在死磕的逻辑，醒来的一瞬间突然福至心灵抓到了解法。这种纯粹的匠人时代，大概率真的已经一去不复返了。

我最近和一些我所认识的、业内最顶尖的硬核工程师聊天，他们都在向我表达一种强烈的复杂情绪：一边是眼睁睁看着传统手艺消亡的巨大失落感，另一边又是"天呐，我现在的并发生产力简直强到令人发指"的极度兴奋。

Anthropic 工程团队今天如何工作

主持人 Dan Shipper：既然这个命题成立——软件工程不仅活着，而且活得很好——那在 Anthropic 内部，你们自己的研发团队在日常实际中，到底是怎么开展工作的？

Mike Krieger:

这里面有几条非常清晰的线索，我可以结合完整的软件生命周期以及我每天看到的研发日常来聊聊。

首先，依然有大量的"人肉对齐"。大家会聚在会议室里，头脑风暴讨论 Cowork 下一步的演进方向，然后把蓝图拆解成不同成员的责任区。这一步依然至关重要，因为很多作为人类才能掌握的全局上下文，是目前的 Claude 无法隔空感知到的——比如这个产品的真实商业意图、目前的研发暗线，以及有哪些即将下线、或正准备以一种极其微妙的方式整合进来的其他产品线信息。

虽然我们团队里给每个人都配备了多尊 Claude 巨塔，但落实到管理上，每个人头上依然挂着 DRI（Directly Responsible Individual，直接负责人） 的头衔，各自对产品的某个具体模块负责。我认为这种机制在短期内绝不会消失，因为让团队"分布式协作，合力把产品打磨好"的宏观大局观，与"我今天该怎么让 Claude 跑通这个具体任务"的微观执行之间，存在着本质的鸿沟。我们虽然在极力推行极简会议制，但这类前置的脑暴和对齐会议依然必不可少。

其次，是大量的"异步委托"。我们这里的很多工程师都自己魔改出了一套个人仪表盘，用来监控自己的 Claude 军团都在干嘛："我的某个 Claude Code 跑到哪一步了？"、"有什么卡在队列里等我审批？"、"有哪些 PR 需要我介入修改——因为被其他同事或者某个大模型的代码审查给退回来了？"

现在，工程师们很大一部分精力花在了这种对工作的维护上。这里面的有些协同工具我们正在推进标准化，但大部分还是保留了浓厚的极客个人色彩——就像以前程序员喜欢个性化定制自己的桌面窗口一样，现在他们正在个性化定制自己的大模型工作流。

再者，是理解代码在生产环境下的真实运转状况。这是目前大模型极力攻克的另一个前沿阵地。Fable 在这方面已经展现出了长足的进步，但还有很长的路要走：比如去深度理解代码部署上线后，到底会发生什么。系统会发生崩溃，会出现各种无法预料的怪异故障——说实话，Instagram 丛 2012 年到 2016 年的那几年里，我大半条命都折在处理这些线上事故和做架构规模化上了。在应对线上突发时，高级工程师的角色依然不可替代：你需要靠多年的事故响应经验去保持绝对冷静、全量收集日志数据、实施紧急止血，然后再去推演根本性的长效修复方案。

最后我想强调的一点是："工程原型"在今天扮演的角色彻底变了。

你必须极其清醒地界定，手里这个东西到底是一个 Demo，还是一个准备上线的生产级代码。以前硅谷流行一句话叫"用代码赢下争论"（Code wins arguments），我个人其实一直不太感冒，因为它潜台词在说谁会写代码谁就掌握了话语权。但现在，事情反过来演进得非常有意思：有时候我们对产品的某个走向相持不下，结果经常是某个不写代码的 PM 跑过来说："我刚才自己动手搓了一个 Demo，虽然在 8 个细节上还糙得不忍直视——但你们看，这条路绝对能跑通！"这瞬间就开启了一个完全不同的高维对话。

回过头来看，我们现在的几乎所有研发姿势，跟六个月前相比都已经面目全非了。最明显的特征就是恐怖的开发并行度，以及团队对工作流进行高阶抽象的绝对刚需。

但唯独有一件事从始至终没有变过，那就是人类对产品的"所有权与责任感"。

验证的机制

主持人 Dan Shipper：Fable 也很贵。我在测试它的时候，觉得自己就像是进了一家糖果店的小孩，兴奋地喊着："我要这个、这个、还有这个！"但到了该结账的时候，我每次按回车前都会心里打鼓："这一下会不会直接烧掉我 100 刀甚至更多？"我觉得这种高昂的价格，实际上会给"谁能用它"以及"拿它来干什么"设下一道无形的门槛。你怎么看它的商业性价比？

Mike Krieger:

在专业的软件工程领域，这本账其实算得最清楚。关于定价，内部确实有很多维度的考量。它确实比 Opus 贵不少，但如果你去衡量它单次交付的那些令人惊叹的工作体量，在很多商业层面上，它又便宜得像是在送，当然每个人心里都有一本经济账。

从软件团队的角度看，如果第一阶段是公司让员工接受 AI 编程——模型还早，工具还不到位；第二阶段是搞排行榜看谁用得最多，这会产生不太理想的激励机制；那么第三阶段就是搞清楚谁用得最有效，让这些人尽可能多花，同时有一个清晰的流程不产生浪费。

Fable 这个段位的模型完美契合第三阶段的逻辑。如果你能持续拿出硬核的产出、在业务里真正用它创造出真金白银的价值，公司内部自然会形成一套正向的飞轮预算机制来无限支持你。

在个人使用这边，我自己做测试也是用个人信用卡自费掏钱买自家的服务。这时候你确实会变得抠抠搜搜、更加谨慎。但有意思的是，我周末搓出来的那个媒体追踪器，算下来其实也就比平时多花了一点点钱，做一个个人玩具项目完全没有到动辄烧掉几千刀的地步。

现在真正被价格卡住的，其实是那些不在大厂庇护下、对价格极度敏感的开源爱好者或独立开发者（Indie Hackers）。我给他们的建议是：放手去跑，去看看它在不经历无休止的"来回拉扯"下究竟能一次性交付多少东西。

现在的‘成本’已经进化成了一个多维度的概念——你要算的不仅是‘单次提问的成本’，更是‘彻底把一件事办妥的综合成本’。 Fable 最让我惊艳的地方恰恰在于后者：它总是倾向于一次性把事做对，不需要我坐在电脑前跟它大战八九个回合、绝望地喊着："不对！我不是这个意思！"

主持人 Dan Shipper：它最震撼我的一点就是，你甩给它一个宏观任务，它交卷的时候，你会发现它连每一个犄角旮旯的细节都帮你推演过了，这种窒息的细腻感是以前在任何模型上都没体验过的。你能透露一点训练上的内幕吗？到底是什么喂出了这么恐怖的洞察力？

Mike Krieger:

在很多层面上，它是团队大量工作的延续——我对我们的预训练和 RL 团队只有顶礼膜拜。对我来说最明显的进化是一种"对整个系统的感知"，而不仅是对当前这段工作的感知。

我经常被它的一些神仙操作震撼到。比如它刚写完一段代码，会突然主动弹出一句："大佬，我知道在真实的生产环境里，这里的配置可能会不太一样。你那个功能开关到底开了没？要是没开，我刚才写的这玩意儿上线可不生效。"

或者看它对代码审查的反馈做出反应——不管是来自人还是来自其他 Claude——它不简单地说"哦对，这是个问题，我去修"。它真的会去想在当前保真度下要不要接受一个风险，或者反驳另一个审查者——往往就是另一个 Fable 模型——说"我理解你的意思，但我要反驳，我认为不对"。

让模型有这种判断力极其重要。如果我要指出它进步最大的地方，就是它不立刻膝盖反射式地说"对对对，我去修"——它更像"让我想一想。我还是不同意。"这种能力非常有用。

有 Claude Code 这样的产品在市场里是极其宝贵的，因为你有活生生的东西，人们可以说"这是模型做得好的地方，这是模型做得不好的地方"。我们把 Every 的伙伴们在我们最高优先级信任的反馈来源里排在很靠前的位置，因为他们让模型经历反复的多日高强度任务，这对我们思考下一代需要改进什么非常关键。

主持人 Dan Shipper：Chat 是对这个模型来说最合适的交互界面吗？它不是那种回合式的，更像是把事委派给某个人。这会怎么影响你应该怎么用它、或者你怎么看这个界面？

Mike Krieger:

发送消息和接收消息这个基本模型不完全错，但我们需要在一些方向上进化。

第一：你的笔记本电脑是正确的地方吗？这就是之前我提到那个移动端对个人项目多么好用的地方。Claude Code 的创造者在这些模型怎么被使用上总是领先半步，大概九个月前我跟他聊天，他说："我把我大半的 Claude Code 的工作移到移动端了。"我当时持怀疑态度，但特别是到了 Fable 这个级别，因为它可以保持会话进行、我们在 Anthropic 有远程开发机，所以第一个点是：把工作发生的地方跟我在讨论工作的地方解耦。

第二点接着我之前说的：你怎么拿 Fable 所有讨论过、决定了、建议了的东西，让它变得可以理解？这是我们正在思考的领域。有一些 skill 可以让它画图表，但目前的聊天 UI 不足够，Fable 有时候会给你超大量的文本，你要出去散个步才能准备好去理解它。我开始做的一件事是："你在这个事上的上下文比我多得多。咱们能不能倒回去——做更多对复杂性的渐进式披露？"

第三个是多人模式，这块我们还在早期摸索。在某种程度上，因为我们有 DRI 和所有权区域结构，通常一个重要的活是流在一个人和几个 Claude 之间的。但有些情况下就不那么明显——也许是事故响应，多个人在同时思考；或者多个交叉领域汇合的项目。聊天分享能解决一部分，但我觉得未来会有这种需求：你有一个独立的 Claude，由一个人启动做了很多工作，但它能不能跟团队里所有其他正在做的工作保持同步？这是下一个有趣且发掘不足的前沿。令人兴奋的是，模型现在已经有能力成为真正的队友，而我们几乎是在因为没有正确的抽象而拖它们的后腿。

主持人 Dan Shipper：这让我想到我大部分时间用这个模型都是在搞自己的 vibe coding 项目，但当你在组织内使用它的时候有一个问题：我真的理解模型刚做的所有部分吗？我怎么把模型刚做完的东西的上下文转移到我的脑子里？这是一个大瓶颈。你怎么想划定"我到底需要知道多少"的那条线，以及怎么确保你有足够的上下文来感到安心？

Mike Krieger:

两大块。第一块是验证。我今年初彻底被验证说服了，这跟以前我全职写代码时的一件事相通：找到最紧的开发循环来围绕你的想法。在 Instagram 时代，有时候意味着在 Xcode 里做一个新的构建目标，只包含那个屏幕和合成数据，只对这个循环迭代。我会辅导新来的工程师说"如果我只教一样东西，就是为你的项目搞出这个来，事情会快得多"。

现在的情况是：每次我搭东西的时候，我怎么确保 Claude 的每一个 PR 都附带了照片或视频——不管是 iOS PR 还是 UI 层的改动。这帮你获得了很多信心。Fable 可能自己跑去工作几个小时，回来跟你说"我做完了"，然后你看到"这里是全部 UI 的截图画廊"，就非常有用了。你会说"截图八里那个错误状态——我其实从来没见过，但我能看出来如果用户碰到了会怎样。我们把这个改一下。"做全面的验证是我们内部一直在大力搞的事情。

第二块：你最终还是要为你做的工作负责的。很多人每天都在用 Claude，但仍然有种可问责性——"Claude 也许写了代码，但你需要理解做了哪些宏观决策"。我看到相当多的工程师开始了一种实践：Claude 做完了活，但紧接着有一场后续对话——"我能不能确保我透彻理解了你做的所有取舍？"不管产出的是什么小写的 artifact，只要能让它变得容易理解，就值得做。

开会的时候很有意思——有人会说"这个 PR 我准备好了"，另一个人说"你做了 X 还是 Y？"然后有那一瞬间的停顿："说实话，我不太确定——合入之前我去搞清楚。"适应这种新常态，搞清楚怎么跟它共事，是我们所有人都需要学的。

主持人 Dan Shipper：你刚才提到的这个"验证循环"太有想象空间了。除了自动化截图和屏幕分享，你们还在探索哪些更硬核的思路？

Mike Krieger:

我们的核心切入点是：你能不能做到让它跑真实的流程，而不是只注入一个静态数据？当系统越来越复杂，这变得越来越难。比如，我们必须要让 Fable 搓出来的 iOS 应用，能够一键登录到我们的模拟环境里，调用的全都是最真实的测试账号和高保真的真实流数据。但同时，我们又不希望它在测试一个区区按钮的微调时，每次都要苦哈哈地去跑一遍长达 8 步的繁琐新用户注册流程。所以，我们专门为 AI 开发了一套特殊的高级权限和加密共享密钥体系，让 AI 能够一键越过前置关卡，直接切入最核心的业务现场，让它的测试体感和真实用户在手里的体验做到近乎像素级的贴合。

第二块是已知路径和当前改动路径的组合——前者对于回归测试非常有价值。我们已经把一些理想化的工作流用文字表达出来，Claude 可以反复检查这些。而 Claude 在表达它当前在做的那部分改动的意图上也做得非常好，所以这部分会被深入演练。这两者的组合很重要。

视觉验证也很关键，而视频是给 Claude 的一个极度未被充分利用的工具。我最近在做一个原型：把 Claude 构建出来的东西做成视频录像交给它，配合 FFmpeg，看着它自己逐帧分析，然后说"这个动画有卡顿，我去修"。截图永远不会捕捉到这个，因为截图错过了那个瞬间。

对于那些不容易端到端测试的部分，让 Claude 构建一个可靠的模拟后端，或者用现成的，也非常有意思。在 Artifact 的时代，我们在预 LLM 时代就有非常全面的测试。每一块基础设施都有一个很好的内存实现，可以在单元测试里快速运行。现在把这件事延伸到 Claude 的领域：我在做一个有相当稳健后端的东西，在我的开发服务器上不好启动，它一次性就搞了一个很好的替代品。随着时间推移，这个替代品随着代码本身的演进也在演进。以前我会说"这要同步太费劲了"。现在我只是想"Claude 会读变更，适配替代品，保持两边同步。就行了。"

主持人 Dan Shipper：有一些非常有趣的架构：当你收到一个 bug，一个 agent 自动去修，修完给客户发消息说"修好了"。你注意到在 Fable 上这种流程有变化吗？

Mike Krieger:

几个方面。在人与 Claude 的层面上，有一件事我反复看到：如果有人在我们 Slack 的反馈频道里报告了一个 bug，这个线程被传入 Claude Code 的会话。因为有 Slack MCP，它可以真的拉取那个线程，然后以我的身份发回："这是 Mike 的 Claude，我修好了，这里是 PR 链接。"但然后他它会说："别急——还没上线。等上线后我会再通知你。"几个小时之后："这次部署发出去了。你应该去试试修好了吗？"这种闭环的跟进是相对新的。我有过好几个长期运行的 Claude Code 会话在以我的身份互动。我在里面也放了一些免责声明。

第二块回到了我们刚才聊的那个品味和判断。一个层面是"有 bug 反馈，所以我要去修"，另一个层面是有好的判断力。我周末遇到一个情况，我们有一个内部系统运行了好一阵子没重启，出现了内存泄漏。好的判断是："Mike，这是周末。你重启一下服务器，现在就能解决，我会异步开一个 PR 做长期修复。"如果你要 Claude 介入这种 bug 到修复的流程，你真的希望它理解任何好的 SRE 或工程师都会理解的东西：解决眼下的问题，至于要不要换平台重构那另说。理解这个平衡非常重要。

人们应该用这个模型来构建什么

主持人 Dan Shipper：这一代新模型最让人热血沸腾的地方在于，它们不仅仅是抬高了下限，让任何没有背景的普通人都能一键搓出属于自己的 App，更重要的是，它们同时掀翻了专家的天花板。如果你现在是一名职业工程师或者创业团队的创始人，你完全有能力去单枪匹马搞定以前连想都不敢想的硬核项目。在你看来有哪些可能大家目前还没缓过神来、但其实完全可以用这一代模型去闭眼冲的前沿领域？

Mike Krieger:

几个想法，也许可以先从好玩的说起。人们总有很多关于怎么把他们的世界的复杂性表达出来的创意想法，每个领域都有一个你特别了解的东西，而总会有些版本是"我怎么把它解释给别人？我能不能把别的地方的技术用到我这上面？"拿我太探来说，她最近正在跨界死磕环境工程——主攻地热能方向，那里面充斥着令人头秃的复杂数学模型和流体力学模拟。但随着 Fable 这一代推理模型的断代式升级，她居然成功地把原本完全不属于她专业范畴的硬核技术，完美地嫁接到了她自己的科研工作中。现在，她甚至能指使 Fable 去帮她搭建一套全量 PyTorch 的端到端深度学习模拟系统——这放在以前，对她一个非计算机专业的学者来说，简直是天方夜谭。

第二块是它组合软件来解决对你自己非常独特的问题的能力。内部我们做的大量工作是把我们尽可能多的内部系统 MCP 化，配合正确的权限结构和部署设置。外部也有很好的 PaaS 平台，你直接问 Claude 就行，它会帮你搭好。但我特别喜欢那种"做了一个你一直想要的东西"的感觉。

还有一件事是最近彻底震撼到我的。我们内部有一位商业化团队的同事，她并非技术出身，但她把 Claude 深度整合到了她日常业务流程的每一个毛细血管里。最可怕的是，她没有在完成了 V1 版本后就浅尝辄止——她就拿着这套工具，在后台默默跟大模型一起，连着高强度迭代了几个月。

这恰恰揭示了这一代推理模型最被严重低估、也最性感的一点：在前几代模型的温饱线里，项目往往存在一个"复杂度天花板"。一旦你的业务代码或者逻辑堆叠到了一定体量，大模型就会开始"顾头不顾屁股"，你再想塞进新功能，它就会疯狂报错，直接把你之前的已有架构给活生生改烂。

但现在，这位不懂代码的女同事，在 Fable 这个级别的模型加持下，已经把她的系统在后台连着养了几个月。你能清晰地看到那个软件像一个活生生的有机体一样，在 AI 的灌溉下持续生长、生长、疯狂进化。 如今，她已经开始把这套极其庞大、复杂的自建系统，向我们公司整个商业化部门进行全量部署了。

一个完全没有程序员背景的普通人，如今能够凭借一己之力，把一个长周期软件的复杂度天花板顶到这种令人窒息的高度——这在人类科技史上，是前所未有的神迹。

动态工作流

主持人 Dan Shipper：你说的另一个非常强大的东西是动态工作流，跟我展开说说吗？

Mike Krieger:

我们在内部经常会魔改出一些这类前沿工具，然后我就会在办公室里死命去"催更"那些写工具的工程师："这玩意儿到底什么时候能公开发布？"有时候确实是因为一些底层的硬核基建限制导致只能内部先跑，但我们正在竭尽全力把这些宝贝早点推向市场。对我来说，动态工作流绝对是属于惊艳全球的那一款。

Fable 这样的模型之所以特别强大有两个大原因。一是它能帮你为深度、有意义的工作创建脚手架。我用它干过的最疯狂的一件事，是直接甩给 Fable 一个挺复杂的内部 Python 项目，让它帮我把一整套核心业务完整地重构成 TypeScript 版本——当时我们有一个非常具体的线上部署考量。

当年在 Instagram 的时候，高层也曾极其严肃地讨论过："我们要不要把 IG 整个底层的代码用 Hack 语言全部重写一遍，从而无缝并入 Facebook 的基础设施里？"我们当时的结论是：打死也不干，这根本不具备现实可操作性。

但就在上周末，我面对一个同样盘根错节的核心代码库，我直接在后台丢给它一套动态工作流，然后我就拍拍屁股去过周末了。我给它设定的工作流是：深入理解现有代码，生成一份很像 spec 的文档说明一切怎么运作，然后逐个模块翻译，增量测试，做对抗性验证，检查遗漏项。等我周一收心回来拉开电脑一看，奇迹发生了——它已经是一套跑在 TypeScript 和 Bun 开发工具链上的崭新系统了，而且在某些架构层面上，它甚至比我的 Python 原版写得还要优雅、还要快。

另一个更性感的长远原因在于：随着动态工作流的普及，在不久的将来，我们可以把不同难度的子任务，无缝分发给对应复杂度的模型梯队去跑。

主持人 Dan Shipper：对于没用过的人，告诉我你是怎么做出那个工作流的。你是怎么设计的？怎么确保它是好的？

Mike Krieger:

整个调教过程其实充满了极客式的迭代趣味。我最开始只是打开 Claude Code，对它说："兄弟，我手里现在有个极其棘手的重构大活——来，我们先联手设计一套全自动的工作流方案。"

它给我展示了计划，我说"这很接近了，但我需要三到四个额外的验证层次来检查遗漏的功能"。然后它就回复："这是你的方案。准备好了吗？"工作流是代码表达的，我觉得这一点非常有价值，你能看到它到底准备怎么做。

在它做了完整移植之后，我有几个后续的小调整项，我就把它们作为迷你工作流，从上一个工作流的输出基础上继续。这回到了那个问题：chat 是不是正确的界面。工作流是一个好的中间地带，你用 chat 来编排它，但它是用代码表达的，然后在一个干净的 UI 里面执行，每一步都在展示发生了什么。我觉得我们以后会用类似的方式来把长视野的工作和 chat 连接起来。