设计师们一直被教导的这种设计流程，我们几乎把它奉为圭臬。但它基本上已经死了。作为设计师，你实际上已经没有时间去制作那些精美的设计稿了。现在，设计师角色的很大一部分是帮助工程师和团队去执行，而不仅仅是把设计稿丢给他们。几年前，百分之六七十的工作都花在画稿和做原型上。但现在我觉得画稿这部分只占百分之三四十了。你最好不要去阻拦他们，让他们放手去做。不只是设计师会觉得「哎呀，我们得跟上工程师的节奏」，我觉得连工程师自己都在想：我们要怎么跟上自己的节奏？要怎么跟上我们这些 agents 的进度？有七个 agents 在持续运行。工程领域发生了大量变化，其结果是设计也被迫跟着改变。我们以前会去做两年、五年、甚至十年的愿景规划；现在变成了只看未来三到六个月，而且不一定非要产出一份精美的 deck。有时候只要做一个 prototype，把大家引向正确的方向就够了。
Boris 最近在播客里说，Claude Code 现在会帮他想点子。我们会在品味、判断力和设计方面变得更好，但我们可能有点过于执着于这些了。人脑在哪些地方仍然有价值？归根结底，总得有人决定到底要做什么、什么才是真正重要的。总得有人对这个决定负责。你现在招设计师的时候看重什么？目前大概有三类人让我觉得特别有意思。今天的嘉宾是 Jenny Wen。Jenny 曾是 Claude 的设计负责人，现在负责 Claude Co-work 的设计工作。在此之前，她是 Figma 的设计总监，领导了 Fig Jam 和 Slides 的设计团队。她还曾在 Dropbox、Square 和 Shopify 担任设计师。我很喜欢这次对谈的一点是，Jenny 正身处设计这一职业的未来发展方向之中。她来为我们描绘这会是怎样的一番景象，以及设计师们将面临多大的变化。这一切都非常疯狂，也极其有趣。非常感谢 no 111 和 Emily Lin Hasham 为本次对谈提供的话题和问题建议。别忘了访问 lennisproass.com，那里有一系列专为 Lenny 通讯订户提供的超值优惠。在我们精彩的赞助商寄语之后，让我们正式开始。本集节目由 Mercury 赞助呈现。Mercury 是一家与众不同的银行，深受超过 30 万名创业者的喜爱，也包括我。一年多前，我从 Chase 转到了 Mercury，体验提升了太多。这就好像是一个真正懂产品的人做了一家银行，而不是一个懂银行的人做了一款产品。它速度快，体验优雅。设置电汇、追踪支出、设置账户余额过低时自动转账的触发器，都超级简单。我们把所有开票流程都搬到了 Mercury 上，体验比我们试过的其他任何产品都流畅得多。给团队成员分配恰到好处的权限、帮你分担工作，也非常方便。开户免费，无需线下拜访，也没有最低余额要求。这款产品适用于从初创公司到大型企业的各种规模。只需访问 mercury.com 了解更多信息，几分钟即可在线申请。Mercury 是一家金融科技公司，并非 FDIC 承保的银行，银行服务由 Choice Financial Group 和 Column NA 提供，二者均为 FDIC 成员。本集节目由 Orcus 赞助呈现。Orcus 是开源项目 Conductor 背后的公司，Conductor 是一个为现代企业应用提供支持的编排平台。现代系统建立在 microservices、API 和事件驱动架构之上，但老旧的自动化工具已经跟不上。孤立的 low code 平台、过时的流程管理，以及割裂的 API 工具，在真实世界的规模和持续变化下都会崩溃。Orcus Conductor 提供了生产级的编排层，用于协调 microservices、API、数据管道、人工任务和 agentic 工作流，具备确定性的 control flow、retries、observability 和 governance。为企业级规模而构建，Orcus 支持可视化开发和 code first 开发，通过内置的 MCP gateway 实现合规性和可靠性。AI agents 负责推理和决策，同时以 MCP tools 的形式安全地访问现有 API 和内部系统。这使得 agents 能够跨企业环境运行，并从 demo 规模化到生产环境，将系统、agents 和人类编排在一起，更快地交付更智能的结果。详情请访问 orcus.io/lenny，也就是 o-r-k-e-s.io/lenny。
Jenny，非常感谢你来参加我们的节目，欢迎来到播客。是啊，很高兴来这儿。我一直很期待这次对谈，因为我在播客里花了很多时间讨论软件工程的未来、这个角色发生了多大的变化，还有产品经理的角色发生了多大的变化。但我没怎么聊过设计正在发生的变化。显然它也正在经历非常巨大的变化，而你正坐在趋势最前沿的位置。而且我知道你对未来的走向有很多非常鲜明的观点。所以我想聊的东西很多。我想先从一个宏观的问题开始：随着 AI 的兴起，设计流程正在发生怎样的变化？变化非常大。嗯，我觉得就变化的程度而言，还有很长的路要走。其实我们过去这段时间看到工程领域发生的变化要比设计多得多。但工程发生大量变化的结果是，设计也被迫跟着改变。嗯，关于这一点，我想提供一些背景：几个月前，也就是九月份，我在柏林的一个会议上做了一次演讲，题目大概是「不要相信设计流程」。我当时基本上就是说，嘿，你知道设计师一直被教导的那种流程吗？就是你先去做一堆研究和探索，然后发散、收敛、再发散、再收敛。这个流程我们几乎奉为圭臬，拼命想要维护它，还说「要相信流程」。那基本上已经死了。嗯，我觉得在 AI 时代之前它就已经在衰亡了，但鉴于现在工程师可以去捣鼓他们的七个 Claude 了， 我觉得作为设计师，我们真的必须放下那个流程。我认为这是正在发生的最大变化。但即使在我做完那次演讲之后的三四个月里，那次演讲本身已经开始让我感觉——有点过时了，这还挺让人不好意思的。但尤其是随着 Opus 46 这样的重大转变，以及很多人在假期里真正开始发现和使用 Claude Code，嗯，我觉得我们看到这种被迫改变流程的压力变得更大了。我现在对它的理解是，基本上有两种设计工作，而且在这个新世界里，设计工作正变得高度分层。嗯，第一种其实更多是支持实施和执行。也就是说，工程师在用他们的七个 Claude 去创造各种功能，任何人都可以抛出一个想法，你可以只是聊聊一个想法，然后通常由某个人——其实是工程师，因为他们仍然比我们更擅长实现这些东西——去做出来。工程师会直接做出一个粗糙的版本，你可以试用。而作为设计师，你其实已经没有时间再去制作那些精美的 mock，或者以这种方式来主导项目了。然后我觉得还有第二类同样重要的工作，那就是为事物创造愿景或方向。这类工作最难以抽出时间来做，而且我们以前确实也会做，但我认为它的形态正在发生很大变化。以前我们会说，我们要去做这个设计愿景，要去制定两年、五年甚至十年的愿景，为我们指明方向。但现在技术变化太快，我们其实根本不知道两年后会发生什么。变化太多了，愿景通常变成了三到六个月的短期规划，而且不一定是要做一个故事讲得极为精美的 deck。有时候只是做一个 prototype，把大家引向正确的方向。我认为这类工作在这个世界里仍然非常重要，因为当人人都能快速搭建自己的工具、随心所欲地朝任何方向实现各种功能时，你需要给他们指明方向。为了确保我们大家做出来的东西在逻辑上是自洽的，而且是高效的——对吧，如果我们都朝着一个更大的共同目标努力，那会比各自随机做事要高效得多。这就是我看到的一个巨大转变。当然我现在有这些看法，但三个月后再问我，可能又变了。所以你的意思是，并不是说设计领域本身觉得我们需要改变，而是工程端的变化——你能如此快速地构建——迫使设计师的角色发生改变。正如你所说，工程师可以不停地 ship，你会发现与其去阻挡他们，不如让他们放手去做，然后在他们交付的过程中提供一种辅助模式，帮他们把东西整合起来，确保彼此关联，并稍加引导。是的，我想是这样。我不认为存在一个统一的声音在说“设计师们，我们现在必须改变”，但这确实是工程工具发生巨变所带来的连锁反应。我想我们在明年左右大概也会看到设计工具的变化。但目前很多设计工具还是处于落后状态。不过这对我们来说也是非常赋能的，因为作为设计师，我们现在也能使用很多这类编程工具，可以以更深层的方式参与流程——去实现一些东西。我现在会做很多“最后一公里”的工作，去打磨所有的细节，和工程师紧密合作把功能推上线，而且我也会用真实的代码去做 prototype，而不是再次依赖工程师来做这些。你认为这在所有公司都适用吗？比如在 AI 公司、非 AI 公司。可能有人听到会觉得，Anthropic、Claude 他们确实处于 bleeding edge，一来产品本身也带点开发者工具属性，二来……但我猜有些人可能会觉得，这在 Salesforce 不会发生，在 ServiceNow 或其他地方也不会。所以你觉得这是所有团队的方向吗？还是主要局限于 AI 前沿公司？你认为设计流程的转变会有多广泛？其实我去年做的那场演讲意外地成了我所有演讲中最引起共鸣的一场。所以我觉得整个行业的人开始有了这种感觉，就是“我们不能再按旧有的设计流程来了”。大家都在用 Claude Code、v0 之类的工具来快速搭建 prototype，PM 也开始自己搭 prototype 了。所以我觉得某种新的东西正在涌现。但有趣的是，那场演讲也遭到了不少反弹。显然有些人投入了整个职业生涯去学习、教授和使用这套非常稳定的设计流程，所以出现了很多质疑的声音，比如“我们不能不做 discovery”、“我们不能没有这些流程环节”。因此，我认为行业中仍有一部分人还没有完全接受这种新的工作方式。是啊。这背后一个很核心的问题是：什么才能造就最成功的产品和公司？你可以说是花时间做 discovery、用户研究、mock、迭代、Beta 测试；也可以说是工程师快速交付，东西还行、不算惊艳但足够好，我们边学边迭代、边建边迭代。你觉得这第二条路径不仅是大势所趋，而且确实能造就更好的产品吗？我觉得你得自行斟酌什么时候该 ship 东西。但我认为，能够执行、能够快速试错，并且用真实的数据和真实的产品用户心态去验证，这确实能造就更好的产品。尤其是现在大家都在使用这些不断演进的、non-deterministic 的 AI 模型时，你不可能把所有状态都 mock 出来，你没法光靠理论推演，甚至没法做一个可点击的 clickable prototype。你必须使用底层的真实模型，必须看到人们用自己的 use case 去试用它。因为对于这些模型，你可以针对不同 use case 去设计，但你也必须在观察人们使用的过程中去发现 use case。所以是的。另外，我经常听到的一点——接着你刚才说的——就是你不知道人们会拿 AI 做什么，你不知道它在某些事情上能做得多好，这就是它的 non-deterministic 特性。所以你可以做出非常精美的 mock，展示它可能的样子，但人们却会以一种完全不同的方式使用它。co-work 就是这么来的，可能一开始连 Claude Code 也是如此。那么在 Anthropic 做设计师是什么感觉？给我们讲讲，在风暴中心工作的日常是怎样的。在 Anthropic，很多时间其实花在了解公司正在发生什么上。我也曾在其他规模相仿的公司工作过，但在这家公司，信息量和正在进行的事情特别多，而我却觉得必须跟上。比如研究端有模型研发的进展，而任何时候都有很多不同的团队在搭建 prototype、尝试各种想法，还有各种代号项目。很多时候我都在梳理和弄清这些项目到底是什么，因为我想提前发现接下来我可能会接到什么工作——这既来自研究团队，也来自一些更贴近研究的 labs 团队，他们一直在尝试和验证各种东西。另外就是我自己也想尝试很多东西，我们内部有一堆可以使用的 prototype 和产品，我出于好奇也想去试用它们。而且我觉得公司内部也有很多人对行业走向有很多见解和观点，其中一些读起来真的很有意思，因为很多都属于哲学层面的争论，或者是关于公司方向之类的。我觉得自己就是很想跟上这些动态，而在普通公司里，我的态度可能是“无所谓，这些事离我太远，没那么关心”。但在这里，无论是信息量还是事情的性质，都让我非常有兴趣去跟进。当然，这种“跟进”并不是我工作的主要部分，但我认为是非常有趣的一部分。嗯，这和你之前提到的观点有关。现在设计角色的很大一部分是帮助工程师和团队执行。不只是告诉他们“这是设计稿，这是设计”，而是帮助他们保持正轨，帮助他们串联想法，在过程中创造连贯的体验。所以这是说得通的。对对对。我觉得一部分原因是好奇心，感觉就像我坐在了前排，能近距离目睹行业里发生的很多事情。所以很多时候，我们的 Slack 简直就是一座金矿，我很兴奋地去看大家在做什么、在说什么。我从来没想过，作为一个普通人要跟上 AI 新闻已经够多的了，而真正能看到一个实验室内部在发生什么，这又是全新的一套信息流要去关注。对对。我觉得如果你在这样的公司工作，最好的 AI 新闻可能就在内部，就在 Slack 里。天哪。是啊。只是要跟上正在发生的事情，这个问题变得越来越难了。好吧，那就是工作的一部分。还有什么呢？还有一些比较传统的部分，比如思考未来会发生什么，然后为此做一些设计。比如这周我就专门留出了一些时间来做这件事，因为这段时间我们一直在高强度执行 co-work 的相关工作，现在我想抽时间想想：接下来三个月会是什么样？考虑到当前市场和模型的发展水平，这件事可能发展到什么程度？因为我觉得把这些东西可视化出来，展示给团队看，让大家朝着同一个方向努力，仍然非常有帮助。另外，我每天也会花很多时间和工程师一起头脑风暴，很多时候就是聊聊天、在白板上写写画画，或者看看他们做的东西，给他们反馈，以类似咨询的方式发挥设计师的作用。然后我每天还会花一部分时间写代码，做一些打磨和实现工作。有时候我和工程师一起把某个功能理清楚了，他们做出了第一版，我就进去和他们一起打磨。这是我工作中非常有趣的一部分，而在几个月前，这部分工作还没有这么多。你还在做传统设计流程中的那些环节吗？比如原型设计、用户研究、专家小组之类的，就是像你说的那种整套流程。对，我觉得我们在一定程度上还在做所有这些事。我们团队里有专门的用户研究员，在做传统的研究项目，也有问卷调查，整个团队都会看这些研究和反馈。我们还在做原型，我也还在画设计稿。只是现在我的工具箱更丰富了，做每件事的时间比例发生了变化。明白了。这是个很有意思的收获。以前这部分占了很大比重。我想知道，如果画个饼图的话，以前你的生活是什么样的？就是传统意义上的思考、规划、原型、设计稿、研究，然后是反馈和执行，那现在呢？对。我想几年前作为设计师，可能有 60% 到 70% 的时间都在画设计稿和做原型，剩下 20% 左右用来和工程师头脑风暴、做咨询，最后 10% 可能是开协调会之类的。但现在，画设计稿的部分大概只占 30% 到 40%，另外有 30% 到 40% 是在和工程师直接协作、结对编程，还有一块时间，我不知道具体占比多少，是用来做代码实现的。嗯。就是真正地去构建和发布。对。太厉害了。顺着这个话题，你的 AI 工具栈里都有什么？作为设计师，我知道你也做管理。我想聊聊你实际在用的工具，也就是你的 AI 工具栈。你在工作中使用什么工具？我的 AI 工具栈？嗯，我们在做 Topics 相关的工作，所以深度使用的是 Claude 工具栈。显然我在用 Claude Chat，而且越来越多地在用 Claude Co-work。我基本上把所有原本用 chat 的场景都迁移到 Co-work 上了，因为我发现它更擅长处理那些需要长时间推进的任务，而我问 Claude 的大部分事情都属于这类任务。然后就是 Claude Code，当然，我主要是在 VS Code IDE 里用它，因为我经常调整前端代码，能直接看到代码再和 Claude 对话，这很有帮助。我最近也在尝试更多地通过移动端和 Slack 远程使用 Claude Code。有时候有人说“这个图标好像有点不对”，你只需 @ 一下 Claude，Claude 就帮你改了，然后你去收 PR 就行了，这真的很有意思。总之，我觉得我们这儿完全就是一个 Claude 之家。所以这就是我的基本工具栈。作为设计师你还在用 Figma 吗？我还在用，是的，是的。好。我就等着听这个呢。所以 Figma 仍然是你工作的一部分。你之前是 Figmate，是这么叫的吗？对，Figmates，对。对。我知道推特上有个很大的争论，就是说代码是不是设计的未来。我们还需要 Figma 吗？还需要设计吗？你怎么看？Figma 仍然很重要。作为前 Figmate，我在这方面可能还有偏见，但我确实觉得，当我用 Figma 的时候，我会觉得“对，这就是我该用的工具”，它仍然很好地填补了我的需求空白。我觉得很重要的一点在于，一是它能让你探索大量不同的方案。在设计流程中，能够去想某件事有八九种甚至十种不同的做法，这是非常重要的。我觉得最棒的设计往往发生在你能把一堆想法抛出来，然后进行筛选，逼迫自己想出大量不同方向的时候。而现在写代码，或者说用这些编程工具，并不太适合这种做法，因为它非常线性。你会深度投入到一个方向里，然后就在这个方向上和 Claude 反复迭代。所以 Figma 在探索各种可能性方面一直非常出色，我觉得它在某种程度上仍会以这种方式存在。然后我觉得还有很多非常精细的视觉和交互细节，在 Figma 里直接尝试也非常棒。同样，这涉及很多不同的方向，但都是微观层面的方向。去思考不同的字体排印或风格，把这些都放在画布上专门探索，仍然非常有帮助，而且我并不总是想直接写代码。有意思的是你还在用 IDE，因为工程领域显然正在向命令行、agent 转移，IDE 好像已经不那么酷了。这也说得通，你只不过想改一些 CSS、一些颜色之类的东西。所以我能理解，干嘛不直接跟 agent 说“嘿，来把这个 hex 值改一下”，直接改多简单。是啊，明明可以直接进去改成另一个 class，却要说“你能把这个改成这个 class 吗”，真的很烦。所以这挺有意思的。我在想，是不是现在 IDE 反而对设计师和 PM 有用了，而工程师已经转向别的工具了。是啊，也许吧。好的。你花很多时间和工程师合作，给他们反馈，引导他们往正确的方向走。我感觉你的建议里有一种“放手”的意味——别觉得自己必须当守门人，但另一方面，又要帮助他们朝着协调一致、能做出让我们骄傲的产品方向前进。我觉得现在很多设计师都处于这种境地：“天哪，我跟不上工程师们整天发版的速度了。”关于如何帮助工程师提升设计水平从而让最终成果更好，或者如何跟上节奏而不至于崩溃，你学到了什么？每次我在项目中以咨询的方式和工程师合作时，我都会尽量解释我这样思考的原因，帮助他们提炼原则，而不是只说“不，我觉得这个不该放这儿”。而是说“不，我觉得这儿应该有个按钮，因为不是所有人都知道可以这样提示”，然后给出源于研究之类的例子。所以我也尽量把工程师引导到我们的 design system 和相关代码上，因为现在 Claude 写了很多代码，但它并不总是能自动调用 design system 里的东西。所以只要我能给他们配备未来不需要我也能用的工具，这就有帮助。至于你说的如何不崩溃，我觉得很难，现在真的挺难的。其实我见到很多工程师和设计师都是这样，既然我们现在有能力做这么多，就想做更多。所以我觉得不只是设计师觉得“得跟上工程师”，连工程师自己也在想“我们现在要怎么跟上自己？”这是我经常听到的。太对了。天哪，要怎么跟上我们那些 agent 啊。我们同时开着七个 agent 在跑。好的。作为设计师，在这个职业里，工艺、卓越体验、品质和信任都是核心，要将其注入产品中，因为理论上这会成就成功的产品和公司。当你们的产品一天发布一千次，你根本顾不过来，也没有设计师参与时，你如何看待保持工艺品质和信任？并不是说没有设计师参与。更像是，一个设计师要处理的事情太多了。不过关于这一点，我会看功能或产品处于什么阶段，是已经被广泛采用，还是早期预览。比如我们有时候会发布一些东西，然后说“嘿，这是 research preview，还很早期，会有很多缺陷”，我们会大量做出免责声明。我觉得 Quad Co-work 就是个好例子，我们把它标为 research preview 放出去，心里清楚这就像我们的模型一样——这是它最糟糕的状态，但还是要放出来，因为我们内部试了很多次，觉得这里面有很强大的东西，有些人会从中受益。它可能还不是最容易上手的，品质可能也不是最高的，可能还有一些问题，但我们会放出来，因为我们相信收益大于弊端。我觉得这样做是可以的，尤其是当产品本身已经有真正有价值的东西，值得放出来的时候。但我认为你必须向用户做出的承诺是：“嘿，我们把它放出来了，但我们会迭代。我们会采纳你们的反馈，不断改进。”你必须做出这样的承诺，向世界展示这一点。你必须回应人们的反馈，展示你在持续发布、持续改进，因为我觉得，过早发布而丧失品质信任的真正方式是：你提前发布了，然后什么都没发生。这会损害品牌。但只要你在提前发布的同时维护公司品牌，这是可以做到的。我觉得我们这方面做得不错，如果听众想从中带走什么，那就是：是的，我们会继续做下去。而且作为设计师，这对我来说其实很有趣，因为你把东西放出去，真的能立刻学到东西、得到反馈，也知道下一步该做什么。我听你描述过这种方式，叫“通过速度建立信任”。是的，当然。这确实是通过速度建立信任，但也要让人们感到自己被倾听了，我们在根据他们实际使用的场景修复问题，他们的反馈真的被重视和采纳了。是啊，实验室发布东西的时候很明显，你们这方面做得很好。团队里每个人都在发推，回复推文和评论，然后发版说“嘿，我们昨天修了这个，正在推进”。所以明显能感觉到，这就是当下的情况，我们知道这里有问题，会修好的，而且因为 cloud code 写代码非常快，修复也来得很快。好的。那么另一个很多人问、我也在这档播客里常问的问题是，什么技能会变得有价值，或者换个方式想，Lex 最近是这样说的：随着 AI 越来越聪明，人类大脑在哪些方面仍然有价值。我们经历了这样一个过程：从 tab 补全代码片段，到现在 100% 的代码都由 AI 编写，这已经很疯狂了，现在连 AI 都在审查自己的代码。Boris 最近在播客里说，cloud code 现在帮他想点子、决定做什么产品，就像——哇，看吧，整个产品工作流、产品开发流程正慢慢被 AI 蚕食。所以问题是，至少在达到超级智能之前，人类大脑在哪些方面仍然有用？你觉得 AI 会在品味、判断力、设计方面变得非常出色吗？我觉得它在品味、判断力和设计方面会变得更好。是的。我觉得我们可能有点过于执着于这一点了，总说什么“没错，设计师或某些人永远知道该发布什么、哪个版本最好”之类的。但我认为，AI 的品味最终会变得更好。归根结底，总得有人来决定到底要做什么、什么才是真正重要的。当人们说“AI 会帮我们把这些软件都做出来的”的时候，我觉得软件开发中很多困难的部分其实根本不在于“开发”本身。你想想你在工作中最艰难的时刻，亲爱的，很可能是什么“你和另一个人争论这个功能该包含什么、不该包含什么”之类的事。而这些问题给我的感觉是，没错，AI 可以发表意见，但它不一定能解决你和其他人之间的分歧。所以，决定我们做出来的东西里到底该放什么，这里面有某种我猜测也算“品味”的东西，但可能不是我们通常理解的那种审美品味之类的。更像是某种判断——关于下一步该做什么的判断。眼看着 AI 这么快就接管了编程，要知道一年前、尤其是两年前，大多数人还都说“我不信，我不觉得 AI 能变得这么厉害”。而现在世界上最优秀的工程师都如此信任它，甚至连代码都不看了。这让我重新审视了自己之前所有的假设——我曾以为 AI 永远比不上真正优秀的 PM 和设计师去判断什么是好的、决定该做什么。但我现在开始觉得，我觉得它会达到那个水平。就像你举的例子，它甚至可以给那两个试图做决定的人提供：“这是你做决定需要的所有数据，这就是为什么这是正确答案，你按‘是’就行。按个 1，我就直接去 把它做了。”
是的。所以，我觉得我们就是……没错。顺着你的话说，我觉得我们低估了它在这方面会变得有多强。好的。所以你的感觉是它会变得更好，但你觉得我们仍然需要优秀的设计师参与进来，优秀的 PM 来帮忙做这些决定，当然还有工程师。是的，是的。我觉得总得有人来做决定，比如“我们要做这类产品”，或者面对 AI 展示给我们的东西，总得有人对决策负责。就像即使今天 Claude 能帮你写所有这些代码，最终对“这段代码到底能不能用、在产品里到底合不合理”负责的，仍然得是工程师。所以我觉得存在这样一个决策/判断层，也许有一天我们不再需要亲自做这件事，但现在，呃，责任还是落在我们身上。是的，这说得通。这让我想到放射学的例子，人们一直觉得 AI 会接管放射学领域，然后告诉你到底发生了什么。但人类其实主要也就是来签字批准这个决定的，因为万一错了，总得有人承担责任。嗯，这算不上是世界上最好的工作。但呃，但那是另一回事了，医疗和代码不一样。是的。好的。另一个 AI 与设计领域中持续存在的问题是，感觉聊天机器人和终端就好像……我觉得没人预料到这会成为 AI 持久性的用户界面，比如聊天机器人。本来大家都觉得“不不不，这只是旅途中的一个临时驿站”，结果现在却更进一步，只剩下终端了。嗯，你对此有什么看法？我不知道，你觉得我们与 AI 交互的方式会有下一步演进吗？还是说你认为聊天机器人和终端基本上就是我们最终的归宿？未来很可能是两者的结合，既有你与之交互、点击的 UI 和界面，也有那种更具触感的交互方式。我们已经在 Claude 里看到并尝试这些了，就是那个聊天机器人。嗯，我们最近发布了一堆 widgets，让 Claude 能够引导你、向你提问，还能以交互方式展示一些东西，比如天气、股票什么的。我觉得这些反响很好，因为人们还是喜欢看到 UI、去触碰它们、点击它们，而且比起给 Claude 打字输入，这样效率高多了。但与此同时，当我们真正深入这个聊天机器人范式时，我觉得它给了我们一整套灵活性，这是那些固化 UI 所无法提供的。所以我的理解是，我觉得聊天不会消失，因为它开辟了一种全新的方式，让我们能以无穷无尽的方式与模型协作，能与电脑对话，这是我们以前从未有过的体验。但我认为，对于非常具体的事情来说，直接通过 UI 来完成仍然是最直接的。而且我觉得接下来很可能发生的是，很多这类 UI 会越来越频繁地由模型生成，而不是我们手动去编码每一个实例。但我觉得我们……是的，我们正处于这样一个阶段，我不觉得聊天——甚至是在终端里对话——会消失。有意思的是，像 OpenClaw、Claude、MBot 这些名字，其中一大创新就是可以通过 WhatsApp、Telegram 和 SMS 用另一种方式跟它聊天。就像是聊天机器人的另一种形式，但这一点恰恰是一个巨大的突破——“哦，我原来可以直接通过 WhatsApp 跟它聊天”。是的。而且聊天、跟人交谈，这本来就是……你知道，我们人类一直在做的事。所以这是我们进行丰富交互的一种方式，而现在我们基本上只是多了一种与电脑交互的媒介。是的。嗯，Kevin Wheel，他在另一家我不便提及的 AI 实验室工作。他在一期播客里提到一个很棒的观点：对话是一种如此美妙的方式，可以应对各种层次的智力。我们可以和非常聪明的人交谈，也可以和没那么聪明的人交谈，用的都是对话，而且它在整个光谱上都扩展得非常好。我们可以和智商 200、300 的人对话，对话依然有效。这就是为什么它成为了一种如此美妙的方式，来应对模型不断增长的能力，而且至今仍然有效。是的，这完全说得通。是的。本期节目由 Omni 赞助播出。如今许多产品团队都在讨论如何交付 AI 数据分析。难点显而易见：让 LLM 在生产环境里猜测 SQL 是一场灾难，而且是个糟糕的主意。Omni 采取了不同的方法。他们内置了语义层，所以当你嵌入他们的分析功能时，AI 真正理解的是你的业务定义，而不仅仅是原始数据表。你可以测试查询、验证推理逻辑，并在正式上线前锁定权限。如果你想在产品中集成 AI 数据分析，又不想从零开始搭建整个技术栈，请访问 omni.co/lenny，免费试用 3 周。Perplexity、DBT 和 Buzzfeed 等公司都在使用 Omni 来交付客户可以信赖的数据分析功能。网址是 omni.co/lenny。好的。我想回到管理和 IC 这个话题。那么，你在很多方面重新把自己放回了 IC 的角色。聊聊这件事吧，以及你觉得这是否就是设计管理者需要去做的事。是的，我对此有些看法。嗯，是的。过去这一年在 Anthropic，我一开始是以 IC 身份加入的。然后因为组织架构上的某种需要，我管理团队管了几个月。而现在我实际上又回来全职做 IC 的工作了。我加入 Anthropic 时是作为一名 IC，因为我对在这里以 IC 身份要做的工作感到非常兴奋，同时也因为我当时觉得，自己某种程度上还是想贴近实际工作的，而且我认为在往公司高层晋升之前，现在正是一个非常重要的时机。我当时一直有这些疑问和顾虑：中层管理这个岗位未来还安全吗？我们现在的工作方式，这份职业真的会延续到未来吗？还是说我应该尝试点别的，去亲力亲为？公平地说，我其实两面都喜欢。我喜欢带人，喜欢组建团队，喜欢处于那个层级，但我也真的很喜欢 IC 的工作。我之前做管理的时候，其实算是有点不情愿的，当时想着“好吧，那我就做吧”。所以这两面我都差不多同样喜欢。但过去一年做 IC 的经历教会了我一点，它其实给了我很多技能，我觉得如果这一年我都在做管理的话，这些技能我是学不到的。比如设计，就像我说的，过去这一年设计流程发生了翻天覆地的变化，我感觉自己学到了很多硬技能，而如果我只是带团队的话，未必有时间去掌握这些。所以这其实是这段经历带给我最大的收获。而且我觉得，如果我未来任何时候再回去带团队，这会让我对设计流程的变化拥有共情和理解。我觉得这一点现在非常重要，因为团队的工作方式已经大不相同了。如果你没有以那种方式实际工作，或者没有一直在测试各种工具、尝试新东西，其实是很难产生共情的。但没错，现在对设计师来说是一个很有意思的时代。如果我没有在这样的环境里工作过，我不确定自己是否能完全理解这些变化，或者知道该怎么做、该怎么指导我的团队。所以这就是过去一年真正给我的东西。所以你之前在 Figma 担任设计总监，对吧？你的团队规模有多大？就是给大家一个参考。最多的时候大概有 12 到 15 名设计师左右吧，而且我手下还有几位经理。酷。那……
好吧，所以你当时觉得中层管理可能干不长久。你现在怎么想？你觉得设计管理这个职能长期会存在吗？还是说所有人最终都会变成 IC？我觉得，只要还有一群人组成的团队，有一个人在管理这个团队就是有价值的。管理者确实有其存在的意义，但这取决于管理者是什么类型、实际在做什么。我认为如今一个有价值的管理者，不应该只是纯粹做人员管理——就是那种帮你规划职业发展、进行一对一沟通、确保你工作开心的人——我觉得这种角色已经不像以前那么重要了。反而，一个人如果能真正给团队指明方向，同时也兼顾一部分人员管理的工作，把这二者结合起来，我认为这才是管理至少在当下和可预见的未来的样子。就是能在工作层面真正和团队一起投入、给出方向，同时为他们创造能发挥出最佳水平的环境。你觉得自己长期会回到管理岗位吗？应该会。应该会。我觉得我真的很喜欢帮助一个团队打造出尽可能最好的产品。我的座右铭是“不惜一切代价”。如果团队需要有人给方向、搭建团队架构之类的，我可以上。如果团队只是需要有人去执行，我也可以上。所以，我理解你给设计领域人士、尤其是管理者的建议是：你几乎需要回到 IC 岗位，才能真正理解正在发生什么、变化有多大，这样你才能成为一个更好的管理者。我觉得是的。而且传统上，至少在我看到的很多工程领域，当他们招聘 EM，甚至有时招聘总监时，他们其实会让这位 EM 先轮岗几个月，接手一些任务，真正理解技术是怎么运作的，然后再转成全职管理者。我觉得设计可能也需要做类似的事情。过去设计领域可能更偏向人员管理。当你回到 IC 设计师的角色时，你觉得自己在哪方面最生疏？其实是做设计评审，还有就是接受批评。对，接受批评。你会想，“哦，对。” 接受批评性的反馈并去倾听它是很难的，而且要如此频繁地接受。因为作为设计师，你必须分享作品、在团队面前展示，这是一个需要把自己完全敞开、很考验心理承受力的过程，然后你还要接受大量批评性的反馈，并且一直承受这些。对。所以现在你正在主导 co-work 的设计工作，对吗？是的。太棒了。Boris 最近也上了这档播客，他谈到关于 co-work 应该做成什么样有很多争论，有各种宏大的想法，最后他说干脆就把它做成产品里的一个终端，基本上就是一个花哨一点的终端。关于 co-work 最终确定成现在这种体验的过程，你能分享些什么吗？顺便说一下，我现在就在显示器上开着它。具体来说，关于 co-work，我们内部做过很多不同的原型，探索它可能的样子。这种事就是我们尝试了很多方向，然后其实我们不太确定到底什么时候能准备好发布，结果突然有一天就万事俱备了。我们就想，“好吧，那我们很快就要发布了。”
只用了 10 天。10 天就搭出来了。其实肯定不止 10 天。总的来说，我们花了大约 10 天时间，把它从内部已有的版本打磨成可以对外发布的状态。所以我们其实已经开发了一段时间，但不太确定它最终会以什么形态呈现。而它最终成型，是因为我们内部在围绕不同的 agent harness 等方面做过很多其他探索。我们只是把最终融入 co-work 的各种交互里的一些小组件做了原型。比如 Claude 给你待办清单的时候，我们试过好几种不同的形式。在它向你展示多选题等不同方式时，我们也试过多种形式。我们还试过各种不同的方法来告诉用户有哪些使用场景等等。我不知道我们是不是找到了最完美的形式，但本质上就是一些在内部已经跑通、大家比较喜欢的东西，我们觉得发布出去能获得更多反馈信号。所以我觉得，强迫自己在那 10 天内发布，其实就是“不管现在有什么，先放出去，然后再去迭代”，而我们目前就是这么做的。你们发布的时候简直引爆了互联网，所以结果是好的。是啊。今天 Co-work 的功能里，有没有哪个是你最自豪的，或者特别想尽快修复和改进的？说实话，我最自豪的就是我们真正把它发布了出来。目前还没有某个特别具体的功能，因为当你长时间投入在一个项目上，尤其是作为设计师，你只会看到里面的缺陷。不过有很多让我兴奋的地方。比如我们一直在迭代主页，让它更像是在说"这些是你能交给 Claude 的任务"，以及"这些是 Claude 正在处理的任务"。这个版本实际上应该快推出了。对，我看到那个小随机生成器，点击一下就会给出各种不同的点子。是的。然后当你真正开始和 Claude 协作时，感觉会更像一个待办清单。更像是这些是 Claude 正在处理的事，这些是需要你关注的事。我觉得这里有机会让它感觉更像你和 Claude 之间共享的待办清单。所以很期待继续迭代这个方向。另外我也很期待进一步思考，这个产品真正的形态到底是什么？它是永远被困在屏幕里，还是能以某种方式延伸到它正在操作的不同界面和设备上？我很喜欢你提到的一点，就是这东西不是只用 10 天做出来的。人们总是抛出这种数字，说我们 10 天就做出来了。但你的意思是，其实之前花了很多时间思考方向、做原型、模拟、尝试各种东西。然后到了某个时刻，好了，我们知道想要它变成什么样了，那就把它做出来并发布。对。不知道为什么，关于 Co-work 的发布， viral 传开来的信息就是它只花了 10 天。但其实有过非常多的探索，很多人参与过 Co-work 不同部分的开发，它绝不只是 10 天，而且有非常多的人参与其中。这种事往往是想法一直反复出现，但要么时机不对，要么有不同的变体，然后突然有一天时机对了，感觉好像从头到尾都很明显，但实际上经历了很长很长的旅程才到达这里。顺便说一下，对于那些不太了解 Co-work 的人，我对它的理解是，它就像长了手的 Claude，可以在你的电脑上执行操作。这是你的描述吗？如果用一两句话，你会怎么描述它？这个描述很好。我其实没听过这种说法，但我很喜欢。以后我可能会经常用"长了手的 Claude"这种说法。我还可以把它理解为，它就像 Claude，但特别擅长把你所有乱七八糟的东西整理成漂亮的成果。我最喜欢的 Co-work 用例之一就是，丢给它一个装着我各种资料的文件夹，里面具体是什么并不重要，但我总能从中提炼出有价值的东西。我做过很多次了。好了，回到管理、作为管理者以及设计师角色的话题。我想稍微聊聊招聘。看到设计师的角色发生了这么大的变化，你现在会看重哪些新的特质？你觉得在这个新时代招聘设计师时，什么能力对他们的成功至关重要？我觉得特别是在我所处的那种工作环境中，有一种韧性和顺势而变的适应能力非常重要。因为我们周围的一切变化太快了，你必须非常愿意去适应，尝试新方法、新工具，学习新事物，而不是固守旧的流程和方式。不过我想到了三种类型的人，目前对我来说特别有意思。其实以前他们也让我感兴趣，但在这个时代感觉尤其重要。第一种我称之为"强通才"。不是那种普通的通才，样样都懂一点，而是在 T-shaped framework 里几乎呈"块型"的人——他们在几项核心技能上都非常强，大概能排到前 20% 的水平。说实话，这种人很罕见，也很难招。但我喜欢这类人，因为我们已经看到设计师的角色在不断延展和扩展，对吧？我们都变得更像 PM 型，也更像工程型。所以如果你已经在几个不同领域都有很强的技能，你就很容易灵活地扩展自己的角色。这让我很兴奋，就是那种在很多方面都很强的人。当然，这个要求很高。第二种让我兴奋的人，在 T-shaped framework 里属于"深专家"，T 的那一竖比大多数人都要深。可能是行业内前 10% 的人。同样超级难找。我觉得自己很幸运，在有些公司工作，能够请得起这样的人，真正把她们招进来。第三种可能是我们大家都忽略的，我称之为"craft newrad"。就是职业生涯早期的人，感觉比实际年龄更成熟、更有经验，但又非常谦逊，非常渴望学习。我觉得这种人现在特别有意思，因为大多数公司都在招聘资深人才，那些做过很多事、经验丰富的人。但考虑到角色变化如此之大，我们对设计师的期望也在改变，我认为拥有一个几乎像白纸一样、学习速度极快、非常渴望学习新方法和技巧、脑子里没有固化流程和仪式的人，这非常宝贵。我觉得这类人是我们很多人正在忽略的，但我非常看好。这太棒了。说到很深的 T 型，能否举个例子，设计师在哪项技能上特别强？有些设计师技术能力很强，在某种程度上他们几乎 50% 是软件工程师。这特别有意思，因为目前至少对我们来说，很多时候是直接跟 model 打交道，所以有深厚的工程背景会很有帮助。但另一种深 T 型专家可能是，他们在视觉设计或图标设计这类事情上特别强。既然现在任何人都能做出任何东西，拥有这种深度专业倾向的人能真正帮助我们做出差异化。太棒了。那这个"块型"，我们之前播客请过 Mark Andreessen。我们有点把它叫做 F 型或 E 型，就是多个 T 组合在一起。横过来的 F，横过来的 E，我猜。你描述的是不是那种在很多方面都非常非常擅长的人？对，对。基本上，如果你把他们所有的技能集合放在一起，看起来会像一整块，你知道，就像技能太多了，那个 T 都被铺开了。好的。好的。那什么是顶尖应届生？就是那种很有热情、思想开放、有韧性、非常聪明的人，我觉得这是很重要的部分吧？是的。太棒了。是的，是的。如果是一个刚入行的年轻设计师，想闯出一片天，想取得成功，你会给他们什么建议，让他们有机会最终加入 Anthropic 这样的公司？我会说，多动手做东西，多尝试，做出实际的作品。我不知道现在的设计教育或者整体教育是什么状况，但至少在我上学的时候，一切都非常理论化，教的都是一些方法论之类的东西。但我认识的最优秀的那类应届生，都是那种会利用技术做出实际东西的人，不会因为自己经验少就感到受限。我觉得有时候他们反而没有这种负担，因为我们在行业里待久了，对自己会有各种预期，但他们没有，他们觉得自己无所不能。所以就是多动手做东西，和别人分享，找到一个也这样做的社群。对了，我毕业的那所学校在我毕业很久以后，发起了一个叫 Socratica 的项目，他们的核心理念就是动手做东西并展示出来，就像科学展览项目一样。我觉得那里形成了一股很酷的风气，大家就是动手做东西、做事情。比如，有人做了一个 Claude 机器人项目，也是几年前的事了，他们组装了用 Claude 驱动的机器人；还有另一个人，她就是想在波士顿的公交车上贴几个活动眼睛之类的东西。这既体现了一种能动性，就是觉得我们可以直接动手做事，同时也形成了一个社群，大家互相尝试、动手制作、分享成果。所以，不管一个人来自哪所学校或即将从哪所学校毕业，做这类事情才是真正能让人脱颖而出的。对于那些职业生涯发展得非常资深的设计师，你认为他们需要懂技术、学编程、至少能动手搭建东西吗？还是说，不往这个方向发展，把其他能力提升到极致，也同样能非常成功？我觉得这肯定有帮助，但不是说非要学到能从零开始写代码的程度。不过确实感觉现在设计师的工作语境里，越来越多地涉及到落地实现一些东西。我在想，随着模型和产品都变得更好，我们大概率会继续向上抽象，你可能不需要真的搞懂每一行代码是怎么运作的。但我想说，不妨开始把编程工具纳入你的 toolkit，不管你是不是真的要变得特别技术化。我觉得任何设计师都应该对这些工具保持敏感，知道怎么使用手头的工具，而不是非要跑去学 React 之类的。你觉得 Claude 或者说 Claude Code 作为设计师水平怎么样？你会雇佣 Claude 做设计师吗？还是说还没到那个程度？我觉得 Claude 还没到那个水平。从可以雇佣的设计师这个标准来看，Claude 还不够格。它现在还不是一个强大的通才，也不是一个深耕某领域的专才，更不是那种顶尖的应届生。我觉得它在初稿和呈现各种不同想法方面已经挺不错了，但还没有什么让人觉得特别出色、值得雇佣的东西。这对设计师来说暂时是个好消息（笑），它现在这方面还很烂。但我非常好奇它未来能进步到什么程度。这是一个很大的开放性问题：它能产出惊人的、新颖的、独特的创意体验吗？还是说在这方面它永远不可能达到人类设计师的水平？我的意思是，光是过去一年左右，它就已经进步很多了。所以，是的。我跟你的一些同事聊过，说你管理上有些习惯或观点，我想聊聊。其中一个很犀利的观点是，你认为对管理者来说，所谓“低杠杆”的事情根本不存在，很多被认为是低杠杆的事情其实能带来很大收益。能展开讲讲吗？可以。我记得刚当上管理者的时候，无论是从课程还是书本里学到的建议，都说你现在当了管理者，必须好好规划时间，给工作分类。有一个 2x2 矩阵，我记不清具体内容了，但大意是：这些事只有我能做，这些事谁都能做，而后者就是低杠杆的，你不要再做了。很多所谓低杠杆的事，就是那些非常细碎、深入细节的，或者说确实可以让别人来做的事。但当我回想那些我最尊敬的领导和管理者时，我觉得他们最好的特质之一，就是主动选择那些看似低杠杆的任务自己去做，而因为是他亲自去做，最终反而变成了非常高杠杆的事。比如说，有些高层领导会拼命测试产品，对产品状态极其敏感。他们亲自 dogfood，复现 bug，花很多时间和工程师一起查看日志、抠细节。我觉得这其实是非常高杠杆的，尽管花了很多时间在细枝末节上，因为这会建立对产品的熟悉度，这很重要。同时也营造了一种氛围：这位高层领导非常在乎产品，他真的了解产品的里里外外，愿意卷起袖子干活，给团队反馈，和团队一起解决问题。类似地，我还见过高层领导直接去修 bug，比如我想我之前甚至见过 Mike Krieger 自己提 PR。这种感觉特别好，就像在说：没问题，我们都是同一个团队的，没有什么事是这个人不能做的。还有一件我特别喜欢、更偏文化层面的事：有人特别用心地给同事做周年纪念卡，或者用 vibe coding 做出非常精美的卡片。因为这表明，虽然助理或其他人也可以拼凑一张卡片，但这位领导是真心在乎团队，愿意为此花心思。所以我一直努力践行的就是：选择那些看似低杠杆、但值得我花时间的事情。嗯，这太有意思了。就像你说的，从某种意义上讲，那些低杠杆的事务反而往往影响最大，因为你的下属不会料到你会在这些事情上花时间，而正是这种低杠杆最终变成了高杠杆。是的。我认为这正是你的领导风格能够脱颖而出，或者在某些人看来显得特别的原因。太棒了。还有一件事——我不知道该算是仪式还是团队管理方式——我听说你会鼓励团队成员互相调侃（roasting），这表面上听起来不像是什么美好的环境，但另一方面，我却不断听说你搭建的团队是最快乐、表现最出色的。聊聊这个吧，谈谈你对调侃的看法、为什么鼓励这种做法，以及你对打造优秀团队的心得。其实并不是说我会像“嘿，你们应该互相调侃”那样，我不是在强迫大家这么做。但当我想到团队中的心理安全感，以及那些彼此相处融洽的人，就像你对待朋友一样，你总是会愿意稍微突破一点界限，开开玩笑。你可能会经常调侃朋友，但实际上不太会这样调侃同事，因为这完全取决于舒适感和安全感，对吧？所以，并不是说“哦，我希望我的团队互相调侃”。但我认为，当你的团队成员能够自在地稍微开开玩笑时，这是一个非常好的信号。而且，当大家对你作为领导也有同样的感觉时，这也是个好信号——就是说，他们没那么害怕你，他们有一种安全感，知道自己说了什么也不会被开除。举个例子，在我之前的团队里，我觉得他们有时会拿我在设计评审（crits）上说的话开玩笑，比如我常说的某些口头禅。能举个例子吗？我——哦，我以前总是说：“好的，下一步是什么？”还有“这个我们怎么跟进？”然后他们就会学我：“好的，下一步是什么？”他们会用这种方式模仿我。是的。我只是觉得这说明了一点：“好吧，这些人不一定怕我，他们知道可以信任我，他们能够信任我。而且他们对彼此，以及对我个人生活中的了解，足以让他们知道界限在哪里。”
但与此同时，我认为进入这个领域后你会遇到的问题是：作为管理者，你和你的下属是不是朋友？我觉得这是人们告诉你不应该做的事情。所以我认为平衡这一点的方法是：你必须建立一种心理安全的基线，让人们在彼此之间以及在你面前都感到自在，但你也必须确保他们知道你有非常高的标准。我认为这两件事看起来似乎存在张力，但实际上它们配合得非常好，因为一旦你建立了这种心理安全感，人们彼此信任，你施加高标准实际上可能会变得更容易，因为大家可以毫无恐惧地接受。我想，我大概是从类似“严父”的角度来思考这个问题的，你知道吗？就是说，对于我的团队，我和他们共事的方式让他们知道，我永远都在。我不会一时兴起就解雇他们，但同时，他们也知道我是为他们好，我有很高的标准，而且我正在和他们一起努力做出最好的作品。所以，我需要把握的平衡就是：你能否创造这样一种环境——你的团队觉得可以自在地调侃你，但同时他们也知道必须把工作做好，而且他们会和你一起做出色的工作。这真是很棒的建议。有趣的是，这种管理风格——或者说优秀的管理——总是会回到这一点上，这让我想起了那本书叫什么来着，《彻底的坦率》（Radical Candor），就是那种深切关怀与直接挑战的结合。是的。我想这里听到的就是这个道理：确保人们知道你很在乎他们，但同时也要非常直接，并保持高标准。是的，是的。很有意思。好，也许是最后一个问题。我一直在寻找人们发现在工作中有用的有趣框架、方法和流程，我听说你非常推崇一个叫“可辨识度框架”（legibility framework）的东西。聊聊这个吧。谈谈你怎么用它，为什么它这么有价值。是的，这个框架我想是去年左右在 Twitter 上看到的，出自 Evan Tana，他是 SPC 的合伙人，也是位 VC。基本上这是一个 2x2 矩阵，我觉得它没受到太多关注，但一旦我开始看到它，就忍不住一直思考。在这个矩阵里，创始人可以是 illegible（不可辨识的）或 legible（可辨识的），而想法也可以是 illegible 或 legible。基本上他的观点是，如果创始人和想法都非常 legible（可辨识），那这个想法可能就没那么新颖，已经有人要去实现或执行了，你实际上并没有发现什么新东西。但真正有趣的地方在于想法本身是 illegible（不可辨识）的时候。他说的 illegible 是指，它处于前沿地带，人们可能还没理解，或者讲述它的方式还没有用人们最能理解的方式表达出来。我认为这显然是一种很适合 VC 的运作方式，因为你在寻找别人没看到的机会，并把它们推向世界。但我也认为，至少在前沿实验室——比如在 Anthropic——设计师的一部分职责就是发现那些 illegible（不可辨识）的想法，试图理解其中蕴含的东西，以及如何把它转化出来，无论是通过讲故事，还是通过实际的 UX 和 form factor，然后把它推向世界。而且我觉得，就像我之前提到的，去 Slack 上看大家做的所有东西，我做的就是这个。我试图发现那些确实有一些能量在涌动，但可能还没讲清楚、值得我在工作中进一步思考的想法。其实有一个很好的例子，和工作相关，就是我们内部有一个叫 Claude Studio 的原型，我想是去年年中有人做出来的。它本质上是一个非常密集且强大的界面，搭建在某个 agentic harness 之上。我想那时候可能用的也是 Claude Code。它有很多显示界面，展示各种知识、技能，以及 Claude 正在做的事情，还能预览它的输出。作为设计师，我一看就觉得，这怎么回事？我不太明白。但后来我看到研究团队、搭建它的人，还有公司内部的其他人，大家对它都充满热情，我就觉得，挺酷的。
Jenny：我觉得这里面确实有点东西，但我还没完全理解。我认为这正是一个难以解读的构思（illegible idea）的例子。最终从中诞生的是技能框架，以及那些用来指导 Claude 如何执行任务的 markdown 文件。这些来自那个特定的原型，虽然我没有直接参与，更多是负责这个原型的同事们从中提炼出来的。但后来我在做 Claude co-work 的时候，思考这些功能应该是什么形态，回想那个原型，以及人们觉得真正有用的信息——比如看到 Claude 的计划和待办事项，看到 Claude 正在处理的上下文和文件——这类东西最终被我借鉴到了 Claude co-work 里。所以我会想，设计师在内部审视原型时，如何更像 VC 那样思考。
Lenny：这太有意思了。我最近和一位叫 Terrence Rohan 的 VC 做了一个研究项目，我们分析了那些早期加入后来大获成功的公司——比如 Palantir、Stripe、Linear、Notion 这些公司——的人，他们在寻找什么。其中一个规律是，那个想法要疯狂到所有人都在嘲笑它，觉得“这不可能，你们永远做不到，这太疯狂了，你怎么会想……”比如 OpenAI 早期也是，大家就觉得是个做研究的小实验室。所以有意思的是，这并不意味着每次都能成，也不是每个听起来毫无道理的疯狂想法都会成功，但我想你说的重点是，要关注那些让你觉得有意思、但又还没完全看清楚的东西。也许你可以成为那个帮助把它整合起来的人。
Jenny：对，对。但还有一点，如果某个东西周围有一种能量，但我并不总能理解那能量是什么，那就要去深入挖掘，试着理解它。对，对。因为我觉得那些往往被早期想法吸引的人，他们并不总能说清楚为什么。
Lenny：这就得靠你去深入挖掘、理解它。这是我们发现的三个规律之一。另外一个是，即使你自己没 get 到，也要关注那些对此极度兴奋的人。
Jenny：嗯，而且听起来很疯狂。这太有意思了。好，那第三个是什么？哦，创始人属于顶尖 1% 是另一个规律，而这一点你在 Anthropic 已经有了，所以你符合这一条。
Lenny：天啊，Jenny，我们正生活在一个多么疯狂的时代啊，变化太大了。好了，在我们进入激动人心的快问快答环节之前，还有什么我应该问但没问到的问题吗？或者你想让听众记住的、想特别强调的？
Jenny：嗯，我想特别提一下 Anthropic 的设计团队，为他们打 call。这个团队非常谦逊，他们在社交媒体上并不常发声，但做了很多非常棒的工作。尤其是在当下，我们的工作内容正在发生巨大变化，这个团队展现了极强的韧性。他们的技能跨度很大，从非常技术化、擅长原型制作的人，到工艺水平极高、负责把最终产品打磨好并推出市场的人都有。而且我们全年都在招聘。所以我想特别提一下，如果我没有把我们内部的工作方式吓到你们的话——如果这听起来更令人兴奋而不是可怕——那我很乐意和你们交流。
Lenny：听起来令人兴奋的是能访问这些 Slack 频道，或者所有正在开发的功能吗？
Jenny：对，这是核心福利。
Lenny：让我们现在就问问超级智能，我该把钱投到哪里。开个玩笑。那说到招聘，如果人们想申请，有什么具体需要考虑的？
Jenny：想想我提到的那些原型，尤其是强通才和深专家。我们非常期待这类人，不过一般来说，那些属于……
Lenny：广度和深度的 T 型？
Jenny：对，广度和深度的 T 型。不然我们还能说什么呢？对，那些觉得这些原型和自己有共鸣的人，同时也包括那些对技术非常兴奋、一直在做大量构建工作、并且想要身处前沿的人。
Lenny：太棒了。那么，我们进入了激动人心的快问快答环节，有五个问题要问你。Jenny，准备好了吗？
Jenny：好了，我准备好了。
Lenny：来吧。你向别人推荐得最多的两三本书是什么？
Jenny：第一本是我极力推荐的 *The Power Broker*，作者是 Robert Caro。这个推荐力度很大，因为这本书有 1100 多页。但我认为在这个注意力如此短暂的时代，它确实值得从头到尾读完。因为很少有传记或回忆录能跨越一个人的整个一生，让你看到一个人在这几十年间的变化。而且这个人——Robert Moses——本身也极具争议，能读到对他如此细致入微的视角是很好的。我觉得我们现在太关注当下，反而失去了这种长线思考的能力。所以，这本书提醒了我们职业生涯很长，同时也有助于理解一个人是如何把事情真正做好的。所以推荐 *Power Broker*。第二本我经常推荐的书叫 *Insomniac City*，作者是 Bill Hayes，他在科学家 Oliver Sacks 临终前是他的伴侣。这是一本非常美丽、空灵的书，记录了 Oliver Sacks 生命的最后时光，以及他们的爱情故事。我觉得这本书和 Lenny 你播客上的内容关系不大，但我就是非常喜欢它。它会让你思考死亡，也会思考爱、生活等等。这是我最喜欢的书之一。
Lenny：我的目标不是说……我们在努力培养文艺复兴式的人才。所以这些其他方面的内容都非常棒。有意思，我最近看到著名设计领袖 Julie Zhuo 也在读 *The Power Broker*。不知道这是怎么回事，在设计圈传开了。好。你最近有特别喜欢的电影或电视剧吗？
Jenny：嗯，我最近看了 *A Sentimental Value*，在飞机上看的，你知道，这就是导演希望观众看他们的电影的方式。这是那位拍了 *The Worst Person in the World* 的导演拍的挪威电影。我觉得它的节奏、剧本、人物之间的关系都非常细腻、非常美。基本上讲的是一个家庭，算是家庭剧，但也讲了一栋他们住了一辈子的房子。这很美，因为房子本身就像是一个角色。我不知道还能说什么，但就是一部非常好的电影。另外我当然也要推荐 *The Pit* 第二季。你知道，我们都在追。我觉得大家都喜欢看着那些非常精通自己工作的人做事。嗯，是啊，想象一下在那部剧里当演员，你得学多少东西、背多少术语啊。是啊。而且感觉节奏也特别快。他们一个镜头里就要做那么多事，还有很多走位之类的。当演员看起来真的太难了。我也是最近才意识到 Noah Wy 年轻时演过 ER，现在他居然成了这部剧的主心骨。是啊，是啊。天哪。好了，你最近发现的最喜欢、最爱不释手的产品是什么？不能是 Co-work。其实不算最近才发现的。不过 Retro 我从它发布到现在已经用了大概两年了。而且我觉得我最近才体会到它新的好处。这么说吧，不熟悉 Retro 的朋友，它有点像一个小型的社区照片分享应用，你只能分享某一周的照片，而不是随时发所有照片。它基本上没有任何社交媒体那套东西。你看不到点赞数，没有广告，等等。但有个很棒的点在于，因为我已经用了两年，现在我可以回溯每一年，看到，哦，原来两年前的这周我在做这个。它已经成为一种很特别的方式，让我基本上能重新经历生命中的每一周。哇。而且如果你想培养自己在设计方面的品味，它也是一个制作得非常精美的应用。是啊，设计师都喜欢 Retro。我能理解。好了，你有没有特别喜欢的人生座右铭，在工作或生活中经常想起的？有。虽然不确定这是不是我最喜欢的人生座右铭，但我确实经常发现自己会说一句话：It is what it is。我爸一直这么说。我特别喜欢。是啊。听起来特别宿命论，但我保证不是。我觉得，鉴于现在世界上发生了这么多事，尤其是行业内的各种状况，你不可能控制一切，所以有时候“It is what it is”反而能带来你继续向前所需要的轻松感。前段时间我去参加了一个为期十天的冥想静修，回来之后就感觉：爸，你一直都是对的。这就是一切的答案。It is what it is。不要执着，不要试图改变。就这样，It is what it is。
It is what it is。这句话里其实有很多深意。我当时就想：“好吧，我爸比我想象的还要睿智。”
好了，最后一个问题。回到 Co-work，有没有什么让你大开眼界的用法，就是那种“哇，Co-work 居然能做这个”的时刻？不管是你自己在用，还是听别人说的。我很喜欢的一点是自我反思。我基本上有一个文件夹，里面是用 IIA writer 写的本地笔记，我基本上什么都写，这些年攒了很多不同的笔记，涵盖各种内容，比如一对一沟通的记录、随机的想法、小备忘录、面试笔记等等。我最喜欢、觉得最酷的是用 Co-work 来分析这些笔记，从中获得洞察，并基于它们创作东西。就是说，只要能让我对自己有新的认识，我就很喜欢。但我前几天做了一个特别实用的事，是关于招聘的。当时我想：“我得说清楚我在设计功底方面到底看重什么，因为我觉得很多人其实很难表达清楚这一点。”我就让它通读了我所有的笔记，包括面试笔记、其他我关心的内容，以及我以前写的备忘录之类的东西，然后它给我做了一个评估这方面的评分标准。所以，这种自我反思——“天哪，我甚至没意识到我自己在潜移默化中已经表达了这些观点”——对我来说真的非常酷。这也太酷了。这么说吧，为了让大家听明白，你有一个文件夹，里面放了你写的所有东西，有一对一沟通的记录、会议记录，你还可以放……我不知道你们能不能用 granola 之类的工具做的会议转录，然后去问它。我本来还想问你用了什么提示词，但其实就是你让它读你写的所有东西，然后帮你理解你自己对“设计是什么”的看法。对，基本上就是，“嘿，我这个文件夹里有一堆面试笔记，还有一堆和设计功底相关的笔记。你读一下，然后帮我起草一个备忘录式的评分标准，用来在面试中评估设计功底。”
太酷了。是啊。
Jenny，这次访谈太棒了。真是生逢其时啊。生逢其时。最后两个问题。如果人们想联系你，在网上哪里能找到你？听众可以怎么帮到你？嗯，我现在在 Twitter/X——我们现在都这么叫。账号是 jenny_wen。这可能是找到我的最好方式。我不太用 LinkedIn。所以这就是最好的地方。至于大家能怎么帮到我？给我们发产品反馈吧。你知道，我们在做 Co-work，其实任何跟云相关的产品都可以。只要给我们反馈就好，我们很乐意把它做得更好。
Jenny，非常感谢你来做客。嗯，当然。和 Lenny 聊得很开心。聊得很愉快。Jenny，谢谢你。各位，再见。非常感谢你的收听。如果你觉得这期节目有价值，可以在 Apple Podcast、Spotify 或你喜欢的播客应用上订阅。另外，请考虑给我们打分或留下评论，这真的很能帮助其他听众找到这档播客。你可以在 lennispodcast.com 找到所有往期节目或了解更多信息。下期再见。