How Anthropic Uses Claude Fable 5 With Mike Krieger

Mike，欢迎来到节目。很高兴来到这里，Dan。见到你真好。

那么，对于不认识你的人，你是 Anthropic Labs 的负责人，也是 Instagram 的联合创始人。今天我想和你聊的是 Fable five。Fable five 明天就要发布了。我们录制这期内容是在前一天。节目会在它发布之后上线。

但我真正想做的，是请你上节目，告诉我在第一天之后继续使用这个 model（模型）到底是什么感觉。我觉得，当一个这么强大的 model 发布时，如果能有一个日复一日都在使用它的人来告诉你：它在哪些地方很强，它实际改变了什么，它没有改变什么——这会非常有用。这样你某种程度上就不会陷入那种 AI psychosis 式的状态。

你就能真正去思考，好吧，它是怎样融入我的生活的。

对，完全同意。而且这也一直很有意思。你知道，在 Fable 发布前的这几个月里，我们已经有一些属于这个 mythos class 的 model 了。我觉得，看到外部的人会如何基于它来构建东西，会非常令人兴奋。

但我也觉得你说得对，第一天的印象终究有限，真正的判断还是来自连续几周的使用。我想我们在之前的 model 上也看到过这一点，比如从 12 月到 1 月那段时间的使用——不管是 OPUS four five 还是 OPUS four six——都非常重要，因为人们会在这个 model 上投入更长时间，然后才意识到：哦，原来我之前还没有把它逼到极限，我得再往前走一步，我得重新思考这一代到底什么才是可能的。

完全是这样。我的意思是，我也说不好，但我感觉内部到处都有人在用它，而且他们会有一种“天啊，我好像需要一套新的技能来使用这个 model”的感觉。我觉得这一点在那些内部相对更非技术、更加偏 knowledge work（知识工作）的人身上尤其明显；他们会想，我甚至都不知道我能拿它来做什么。而那些在编排 agent（智能体）的人则会觉得，holy shit，我好像有太多新东西需要学习了。

所以我很好奇，跟我们讲讲你第一次试用它时的印象，和现在相比有什么不同。

是的。我觉得你关于适配 workflows（工作流）的观点非常好。真的是字面意义上的 workflows——我等下会讲这个——但也包括更根本的一点，比如，我该如何思考这个 model（模型）的使用方式？因为，你知道，一开始那个时间点很有意思，它差不多正好和我从 CPO 转到 labs、重新回到 builder mode（构建者模式）的阶段重合。我记得大概是在那之后一个半月到两个月，我们第一次在内部拿到了这类 models 之一可用。

然后我坐在那里，我就在想，我感觉自己又成了一个彻头彻尾的新手，因为我觉得我 prompting（写提示）的方式，甚至我思考如何拆解任务的方式，面对这个 model 都已经很过时了。比如，它已经不再是那样了；甚至连时间跨度，或者说那种 interactivity model（交互模式），我觉得也必须跟着演进。就像，早期可能会是这样：我有个关于这个 feature（功能）的想法。我们能不能先从——完全不是这样了，对吧？

而是变成了：太好了，让我更多地表达我的 intent（意图）。然后你就会发现——我记得大概在三四月的时候——会觉得，哇，光是 one shot（单次直接生成）就已经强得惊人了。但与此同时，它还理解我们接下来要如何演进这件事背后的 intent，也理解整体的 global context（全局上下文）。

所以我觉得直到现在，这一直是个非常有意思的演变。今天早上我还在和别人聊这个，挺有意思的：我现在思考做工作的方式，已经变了。比如我之前要坐飞机，我就想，行，这里面大部分工作我都可以远程完成。我甚至都不担心 Wi Fi 会断，因为我知道，只要我把正确的 context instructions（上下文指令）设好，比如 flash loop，它就会把事情一路做到底。

而且我觉得，我过去两个月里有很多次都是这样：我会祝 Claude 晚安，然后把一个相当复杂的任务交给它，比如某种这种 monoclast，然后等我醒来——其实通常凌晨两点左右它就已经做完了，我猜接下来四个小时它大概就是在干等——但它那种把整套动作完整做完的能力真的很惊人；它还能自己从这种局面里脱困：好吧，Mike 让我 overnight（隔夜）做这个复杂任务，结果我卡住了，因为某个 remote service（远程服务）挂了。

那我现在就先给它写一个 scaffolded（脚手架式的）back end（后端）顶上。所以我会把这件事记录下来，我会把整个流程继续推进到底。我对这样做大概能把我带到哪一步，有一个很好的 mental model（心智模型）。然后等那个服务恢复上线，我再把它修好。

我会把这个事实持续追踪下去。对我来说，最令人印象深刻的其实就是：你真的能够把这种级别的任务委托出去，并且相信到最后事情会以正确的方式完成。当然，你还是会 review（审查）结果；这里仍然有一整套 verification（验证）的问题，我们可以也应该谈，因为我觉得那仍然是把整套动作真正完成的重要一环。但这的确迫使我重新思考：和这类 models 一起工作时，所谓高生产力到底是什么样子？而且它现在已经越来越像——我们之前聊过很久——这些 models 到底更像一个 companion（陪伴者）还是 coworker（同事）？

而现在它真的更像是一个 teammate（队友），我可以把大量工作直接委托给它。

你现在日常的工作流到底是什么样的？因为我注意到的一件事是，如果你直接给它一个大任务，然后一路对它口述，把想法全都灌进去，再让它自己跑上几个小时甚至一整夜，那它是我用过最令人印象深刻的模型。但你也知道，它太慢了，而且太贵了，所以我觉得我并不想把它用于日常任务。所以你实际每天是怎么用它的？和其他模型相比，它在你的工作流里是怎么嵌进去的？

对，我现在也会在前期和它进行更多关于架构规划的讨论。所以这是另一个挺有意思的变化。我觉得这也是所有模型都还需要继续提升的一个领域。我也非常感激我在 Instagram 的那段经历：从最初那个像是用 duct tape 勉强拼起来、跑在 LA 一台服务器上的初版，一路做到能够扩展规模，最后还能接入整个 Facebook 的基础设施（infrastructure）。因为这样你会逐渐形成一种判断，知道在每个阶段里，什么样的 infra abstraction（基础设施抽象）和复杂度才是合适的。而我现在和 Fable 来回讨论时，也不总是会停在“哦，这个实现不错”这一层。

我会说，嗯，我确实打算比较快就把这个发出去。所以我觉得我们可能应该考虑不止一台服务器，类似这样的来回讨论，嗯，是很重要的。不过，很多这类规划我现在都会直接问它。我意识到的一点是，Fable 在这方面的思考可以非常完整——也就是当你和它一起做规划时，它往往能把事情考虑得相当周全。

比如，很多时候我只要说一句：你能不能直接做一个 HTML 页面，把我们刚刚讨论的内容表现出来，这样我可以分享给团队？这其实就很有价值。甚至一个 markdown 文档也行，不过我个人喜欢带图示的东西。所以这是一个很有意思的用法：拿它来做规划，和它一起把事情想清楚，然后产出某种文档，让团队可以围绕它达成一致。因为我在 labs 里、也在 Anthropic 之外的团队里看到过一个共同的动态：你现在可以非常快地构建很多东西，所以更早地强制做这种对齐非常重要。哪怕你先做一个初始 prototype（原型），然后再往回抽象成更偏规划和架构的东西，这也行。我觉得这一点真的、真的、真的非常关键。

这样一来，人和人之间的互动依然会非常明确地保留在流程中。然后从那之后，我觉得无论是隔夜还是白天，让它去执行那些拆分好的任务块都非常重要。这也意味着我现在会同时开比以前更多的并发会话（concurrent sessions），因为我经常会想，好，有这两块工作。我会在两种方式之间来回摇摆：一种是我喜欢保留一个运行时间非常长的 Cloud Code 会话，真的让它去处理所有事情，并在后台分叉出 sub agents（子 agent），这样主线程还能保持响应；另一种则是干脆接受现实：今天就是那种我们要开五六个 tab（标签页），分别去处理那种耗时很长、覆盖面很全的大工作的一天。

但我确实觉得，这种“长时程”的模式很有意思——就是那种“别担心，我在处理了，只是会花一点时间”的感觉，以及更多这种来回协作。我觉得这种 modality（交互模式）也是我们接下来必须在产品里想清楚的东西。我认为你会希望把这两种模式都保留下来，而且它们之间会以一些很有意思的方式相互作用。

而且，我自己的偏好通常是：我总希望至少有一个 clod，既拥有很高的上下文（high context），同时响应又非常、非常快。它的本能是：很好，我先回答你；如果有需要，我会顺手启动一些事情；如果不需要，我就先待命，等下一轮循环。我确实觉得你说得对，对于那种“我只是想修一下这个交互问题”或者某些特别细、特别具体的问题来说，情况会不一样。

比如 Fable 就会自己跑去，对这些事情进行非常深入的思考。我觉得也正因为这个原因，Fable 是第一个让我真正更多去调 effort levels（思考强度等级）的模型。我会想，好，这次我其实只是想微调一下 UI，那我就把它调到 medium 之类的，看看效果怎么样。用 Opus 的时候我倒没有这么常做，也许是因为它的范围感没有那么宽；但在 Fable 上，这种差异真的会感觉相当明显。

比如说，一个很快的小问题呢？比如你人在外面、正在移动中时，你会不会想到什么零碎问题就拿去问 Fable？因为那感觉有点像“用火箭筒打蚊子”之类的，还是说你会在不同模型之间来回切换？

你这么问太有意思了，因为我之前其实没有这么做。而且你会觉得，它在思考。它真的在非常努力地思考这个问题。后来从上周开始，我就想，不对。我当时是在问它一些那种，确实……

老实说，我甚至会觉得拿这种问题去问 Fable 有点不好意思。大概是某个和 NBA finals 有关的事情吧。我就想，行吧。我把我的 iOS app 切到 SADA 了。我当时就觉得，哦，对。

你其实会一直用这个来处理快问快答。这在量级上、在使用感受上都完全不一样；而且差别其实甚至不只是那种 tokens per second（每秒 token 数），更可能是在于一个答案到底投入了多少“思考”。而有时候，答案并不需要被彻底想透。所以，是的，我自己也还在梳理这个问题。我觉得这对我们来说也是个很好的 product 问题：总的来说，你不希望用户为了这些选择而想太多。所以理想情况下，从长期来看，我们能逐渐收敛到一些更容易归类的 use case（使用场景），而且这些场景对用户来说是非常容易理解、很 grokable 的；或者也可能要按不同 surface（交互界面）来区分——因为很可能在大多数时候，当我在用 iOS app 时，我做的并不是 Fable 类型的任务，而按 surface 保持一个 sticky 的 model selection（固定模型选择）也许会是更合适的做法。

我们还得继续探索这从 product 的角度到底意味着什么。但我确实有过那种感觉：这个问题不值得动用 stable，我应该去问 Sonnet。

你能给我们展示一下你用它做过的东西吗？

可以。我们这一轮做的一件事，是鼓励大家更多做一些个人账号层面的使用，尤其是在周末，这其实很有意思，因为你也能想象，我们内部有很多 Nthropics 特有的 tooling（工具链）之类的东西。但退后一步、单纯地想“就用纯粹的 Cloud Code，周末来做点东西吧”，这种感觉其实特别好。

那你是在 terminal app 里，还是在 desktop app 里？

这是个很好的问题。我现在大多数时候还是在 terminal app 里。挺有意思的是，我看着我妻子——她不是专业工程师，更偏 UX designer 和 PM——真的通过 desktop app 爱上了 Cloud Code；我觉得对她来说，这种方式某种程度上简化了其中一些抽象层。不过做这个的时候，我还是在用，是叫 ghosty 还是 ghost t t y？Ghosty，以及 terminal app。

但让我给你看看。这类事情属于那种——每个人在这方面都会有一些很个人化、很 bespoke（定制化）的需求。比如我想要一个比较好的 media tracker 体验，我就想，我会玩游戏，也会看电视剧，我会收到各种推荐，所以我只是想做一个属于我自己的东西，能贴合我自己的一些 use case（使用场景）。

而且，我一开始最重要的两个标准大概是：第一，添加内容一定要非常容易。比如你可以直接和 Claude 对话，Claude 会对所有内容做 Gentic search，然后把正确的条目放进去。另一个是它还能更主动一些，比如说，出了新一季，或者某个游戏出了新的 sequel，它可以自己去研究这些东西。至于大部分 UI，基本上就是 Fable one shot 做出来的，这本身已经很让人印象深刻了。

但接着，我今年在 labs 里一直在反复推进的一条线索是：怎样把 software team——如今很多时候其实就在 cloud 上——拉得更靠近软件本身。所以这个项目大概是，比如某个周六早上开始的。我那个周末其实被孩子的事情排满了，所以很多时候都是那种：先开个工，然后带孩子去 hike，回来再继续做；有时候甚至在 hike 的时候还会 check-in 一下进展。我可能不该这么做，但你知道，能切进 remote mode 看看那边发生了什么，感觉还是挺不错的。

我尽量不那么做太多。但我当时有个想法：我们能不能做一个 spike（快速试验）？我在这些 model（模型）上很常说 spike。我想的是，我们能不能试试看：如果你真的可以从软件内部去修改软件本身，会怎么样？这个东西其实我两个版本都做了：一个 React Native 版本，还有这个版本，也就是纯 web 版本。所以我本来就已经有一个类似 chat 的东西，你可以让 Claude 通过 URL 去添加内容；说真的，我希望所有软件都这样，我再也不想为了做任何事情还得去层层点菜单了。

而这在很多方面，Dan，算是我在尝试把所谓的 agent native architectures（agent 原生架构）提炼到最彻底的一种程度，也就是——

对，没错。

还要让 agent 能够修改这个 app。本质上可以说，agent native architecture 的第一阶段就是：这个产品里的每一项功能，都能被 agent 访问到，而且都有 tool calls（工具调用）之类的接口。这个东西，怎么说呢，希望以后能变成一种 cable fix。可惜的是，现在很多软件里还没有做到这一点。不过它真的很棒，因为我当时就在想：那到底会是什么感觉？

因为有人推荐过一个 Brazilian 节目，内容是关于 Goiania 的 radioactive stuff（放射性事件）。我不记得它叫什么了，而 Claude 能把它找出来。这比我自己凭直觉硬猜要好太多了。但接下来我更感兴趣的是：如果软件能够在运行过程中从自身内部被修改，这到底意味着什么？所以，如果你长按这个小小的聊天按钮，实际上我做的——或者说 Claude 做的——是这样一种方式：它会使用我们的 managed agents（托管 agent）来基本上接收这类编辑请求，然后你还可以预览这些修改。

我这里还用了 Vercel 的 live preview 功能。整个这个功能基本也是 one shot（一把做成）的，真的很酷。哦，对。然后我只是随着时间不断往上加东西。不过，你知道，它其实还会提供一个小小的 diff view（差异视图），如果你想看的话。

你可以进入 managed agent 的对话里，看看它具体做了什么。虽然我几乎从来不这么做，因为再说一次，我并不是特别在意这份软件的 code quality（代码质量），或者它长期的 maintainability（可维护性）。你还能看到它在这里也有一个 session（会话）。但整个过程真的很好玩。所以我会在路上直接用它，然后说，比如前几天我提了个功能请求：哦，这个 floating action button（悬浮操作按钮）在原生 iOS 上位置太低了，但在别的平台上是正常的。

就像，你能不能去把它改掉？它真的改了。配合现在的一些 expo tooling（Expo 工具链）用起来特别有意思，它甚至真的会在我手机上 live reload（实时重载），那种感觉也非常酷。但问题就在于，这东西真的需要成为一个 production level（生产级）的产品，然后面向一百万用户发布吗？

不需要。但那种感觉真的很好：我拥有了一个不必在周末结束时就停下来的东西，我只要继续使用它，并且拥有这样一种端到端、闭环式的体验，就能持续开发它。所以我觉得这很好地体现了 Fable 的构建能力；同时，我想，这也呼应了你我两个人一直都在思考的事：Claude 到底该如何把自己嵌入到软件之中，而不只是停留在使用层面之上——

——在

——各种事物里。

这真的很酷。我希望大家理解，已经被构建出来的东西，其实你在十年前、二十年前左右也能做出一个类似的版本。也许做不到“自我修改”那部分，但你确实可以做出类似的东西。只是如今的构建成本已经大幅降低了。所以你想想，在 Instagram 时代做这件事要花多少钱，再对比一下现在。

你能帮我们理解一下，这件事是怎么变化的吗？

对。我经常会想到这个，回头看那段时间时尤其如此。因为你知道，在 Instagram 早期，我一直觉得自己是个效率很高的 programmer（程序员）。那时候我非常投入 mobile development（移动开发），而且我们对要做的事情有很清晰的认识。我觉得，从一个想法到某个完整产品的 fully realized version（完全实现版本）之间的差距，当时大概仍然意味着四天左右——基本就是我连续通宵干活。那其实也是我的自然状态：熬到凌晨四点，睡到中午。这显然不利于家庭生活，所以我后来不得不调整。但那就是我当时的构建方式。

对，我把它叫作 Instagram v one。它的功能可能甚至比现在这个东西还多一点，但也没有多到一个数量级的程度。那基本就是五天通宵：我负责做前端和后端，Kevin 负责最初的 filters（滤镜），然后把它发布出去。而且这也是建立在我此前多年一直在做 iOS 相关工作的基础之上。再往后就是 iteration（迭代）了。我经常会想，发布之后进展顺利时，真正限制我们的是什么——我们脑子里其实有很多接下来可以发展的想法，但我们当时只是在努力让网站别挂掉，或者只是试着加上一个小的增量功能。比如 hashtags（话题标签）要花一周来做，但与此同时你还想继续推进很多别的东西。所以我觉得这有两个方面：一方面，时间确实在缩短；当然，构思 idea（想法）、concept（概念）和做 iteration（迭代）本身仍然需要时间。另一方面是，你随后可以基于已有成果继续迭代，而这件事我觉得真的很有趣，同时也有一种很“flow（心流）”式的感觉。

然后，如果说现在这是我作为一个专业 software engineer（软件工程师）兼 startup founder（创业公司创始人）的视角。再往外说，如果你有一个那样的想法——而且我看过很多人经历这个过程——通常会是这样：好吧，我去找一家 consultancy（咨询/外包公司）看看能不能接这个项目。但现在的问题是，这会是一个信息损耗非常大的过程，很难准确传达“我到底想要什么”。对吧。又或者他们得为这个去融资。我觉得，最令人兴奋的一点是，这些 models（模型）不仅变得更 autonomous（自主），而且再次在缩小 intent（意图）和 execution（执行）之间的差距；而我看到的结果是，它极大提升了那些本来并不是“builder（构建者）”的人去创造东西的能力。

这些 models（模型）的发展轨迹一直是这样的：如果某个具备这类能力、属于这种大致 mythos class 的东西已经进入了这一类模型的水平，那么最终，那些更便宜、也更容易被其他人获得的模型也会陆续出现。随着这个过程发生，我真的觉得，它正在打开非常多的可能性。前几天我收到一条 ping（消息），如果你还没看出来的话，我对这些东西真的很兴奋。消息来自公司内部的人。我们给她做了一个内部工具，大致是把 Fable 和一些内部 MCPs 的访问能力结合在一起。她说，这是她人生中第一次——而她是做 recruiting（招聘）的。

她说，这是她人生中第一次让我觉得，我脑子里的那个东西，和现实世界里真正存在的那个东西，现在几乎就是挨在一起的。就好像，我可以直接把它做出来。这对她来说是一个非常有意义的时刻，因为在那之前——我是说，我还记得那种日子，其实也就是五年前或四年前——像她这样的人，如果想要一个工具，要么只能将就着用，要么就得去找一个做 internal tools（内部工具）的 engineer（工程师），而那个人大概率已经被另外 50 个需求压得喘不过气来。但现在，他们却能尽情享受构建东西的过程。我觉得，这是一件非常值得抱有希望的事。

我不认为人类在创造力上的能力、以及“什么是可能的”这件事，是狭小有限的；恰恰相反，它是巨大的。我觉得，在我们状态最好的时候，我们本质上是在扩大这样一群人的数量：让更多人能够真正把脑海中的东西落实成某种感觉真实存在的东西。

我完全同意，但我确实觉得，我心里一直有个问题，而且我想这大概也是一些听众心里的问题。所以我想问你：结合你刚才说的这一切，software engineering（软件工程）是不是要结束了？

对。我觉得 software engineering 确实不一样了。它就像发生了巨大变化。如果你在 Instagram 那个时期问我，什么是 software engineering，我大概会说，好吧。

就是要去思考那些难题，思考 architecture（架构），然后花很多时间待在，比如 TextMate 里。我也不知道现在那到底该算什么。就是，你知道，text editor（文本编辑器），你要在里面改这些东西，或者用 Xcode，还要看 Rails casts。对吧？是的。

没错。对，完全是这样。还要理解 Django 的 ORM layer（ORM 层）里的各种细节，然后部署之后再冒出 15 个 bug。这里面有太多东西已经彻底不同了，并且正在并入 product management（产品管理）的其他部分。

而且我觉得那种 PM 端与工程端的分野，我想你们甚至在我们的团队里也能看到，它已经变得模糊得多了。这变化非常大。不过我认为，从 software engineering 稍微拉远一点看，去想 software production（软件生产）或者 software development（软件开发）——但不只是那种纯 developer（开发者）视角——我觉得这件事依然生机勃勃，而且仍然非常必要。所以我觉得，这就是我们当下所处的时刻。

我觉得 Fable 是朝这个方向迈出的又一步，我不会说它就是最后一步。当然，后面还会发生很多事。但我认为，就 trust（信任）而言，至少对我来说，我会放在 model（模型）身上的信任——相信它有能力把事情做到底，甚至能相当合理地做 architecture（架构）——已经相当高了。所以那一部分给我的感觉是，它永远不会真正“完成”，但也已经完成得相当相当多了。对吧？

就像，它已经走得非常远了。但我觉得，整体上那种 craft（技艺）——你到底有什么需求？你到底在产出什么？它实际上够不够好？——我认为仍然是一项非常 human（人类）的事业。

但我也能看出来，这种转变并不是一种毫无痛感的过渡。因为我觉得，有很多人真心热爱那种“亲手把东西做出来”的 craft（技艺）。我自己以前就很喜欢那种感觉：这个问题我解得太优雅了。你会梦到代码；如果你也有过那种经历——你会梦到自己正在做的东西，然后早上醒来时想，我想到了一个特别优雅的解法——那种体验我觉得确实已经过去了。我想，在一些我交谈过的、更优秀的工程师身上，确实能感到一种失落；但与此同时，也有一种“天哪，我现在居然能同时完成海量工作”的感觉。所以我猜，我们现在是在脑子里同时容纳这两种想法。

而我觉得，这才是这里面最重要的部分。为这种事情既感到难过、又感到兴奋，是很正常的。不过我很好奇，我们就先接受“software engineering 依然活得很好”这个论点：那在 Anthropic 内部，这具体意味着什么样子？

对，我觉得这里有几个 thesis（核心判断）。我想还是有那种对——嗯——整个 software development cycle（软件开发周期）的梳理，或者说，也可以从我每天实际看到的情况来讲，也许我会两者都说一点。不过我觉得，仍然有很多事情是这样的：大家会聚在一起，讨论我们下一步想要如何演进 co work（协作）方式。

现在我们已经把它大致拆分成了不同的 ownership（负责）领域。我觉得这最终仍然相当重要，因为作为一个人，你所掌握的 context（上下文）仍然有一部分是 Claude 无法替代的。对吧？这个产品真正的 intent（意图）是什么？它的进展怎么样？

我们还需要了解哪些正在 pipeline（流程管线）中推进、并且未来会以某种有趣方式整合进来的其他产品？所以我觉得，这一部分仍然非常重要。因此，虽然现在几乎是每个人类都配有很多个 clods，但至少按照我们目前的工作方式，每个人还是会——我们称之为 DRI，directly responsible individuals（直接责任人）——仍然会对产品的某一部分或某个领域保有某种 DRI 责任。我觉得这种情况还会持续一段时间，因为我认为价值并不只在于那种分散式的“大家一起把它做得更好”，而更在于“好，我正在具体思考 cohort 应该如何完成这个特定任务”。而且仍然有很多——我们会尽量把 meeting（会议）压到最少，但它们还是会出现，你还是会有这类 alignment（对齐）讨论。

另外，还有很多这种 asynchronous（异步）的委派工作。我觉得这里很多 engineer（工程师）现在都发现，他们各自都搭建了某种版本的工具：好，我现在要创建一个 dashboard（仪表盘），看我所有 clods 都在做什么、哪些在等我处理、哪些 pull requests（拉取请求）需要我关注，因为无论是人类还是 clod coder reviewer（代码审查者）都可能已经给了我反馈。所以，这里面有很多对工作的 meta maintenance（元维护）工作。我想，还是那句话，其中一部分我们之后会标准化，但另一部分可能永远都会有些 bespoke（定制化），取决于每个人喜欢怎样工作，就像人们整理窗口的方式不同，现在他们整理工作的方式也不同。

还有一点，我觉得也很重要，就是理解系统在 production（生产环境）里是如何运作的。我认为这也是 models（模型）接下来的几个 frontier（前沿）之一。Fable 在这方面确实已经取得了显著进展，但我觉得这里仍然需要更多工作，那就是理解代码在 deployment（部署）之后会发生什么。因为会有 incident（故障事件）。也会有这种情况：一切本来都运行得很好，但某条 network link（网络链路）断了，而这并不属于你通常设想的 failure mode（故障模式）。

而且，像 Instagram 在 2012 到 2016 年间，很大一部分工作其实都在处理这类问题，以及如何把系统 scale up（扩展）起来。所以，engineer（工程师）的这个角色依然非常关键。我认为，围绕 incident response（故障响应）去积累 reps（实战训练），学会如何保持冷静、收集数据、先修复眼前最紧急的问题，然后再抽身去做更长期的修复，这些仍然都是必不可少的一部分。然后我想想，还有没有其他值得一提的点。我觉得最后也许还可以说的一点是：我现在非常喜欢 engineering prototype（工程原型）所扮演的角色。

你必须明确什么时候它是 prototype（原型），什么时候不是。不过，以前有句老话叫“code wins arguments（代码赢得争论）”，我一直不算特别喜欢这句话，因为它某种程度上意味着：那个会写代码的人就可以直接去做，但为什么他就一定该默认赢下这场争论呢？不过现在很有意思的是，有时候我们会对产品该往哪里走产生分歧或争论，而经常是 PM（产品经理）会说：好，我刚刚试了一下，它在这八个地方都很 jank（粗糙/别扭）。