Anthropic 设计主管 Joel Lewenstein 谈模型持续进步下的产品设计与 Artifacts 由来

原创 Capihom 2026-09-13 21:02 北京  模型会继续进步，设计师要做什么？Joel Lewenstein 谈 Anthropic 的原型文化、Artifacts 的诞生，以及 AI 已经能做到、用户却还没想到的下一步。 每天挑选一期硅谷AI科技值得关注的播客，让你与前沿同频。如果你现在没空可以收藏进 晚点再听LaterCast，在通勤、走路或做家务时一篇篇轻松听完 "即使产品团队去度假，模型也会不断变得更好。" "先弄清楚什么是好的，再给我一个好的东西。" "问 Claude 之前，我们先猜一猜答案是什么。" Joel Lewenstein 在 Quora、Airtable 做过设计，加入 Anthropic 后，却发现过去积累的产品经验需要重新检视：模型会不断进步，团队刚定好的计划可能很快就得重来，做出来的原型多到连同事都难以跟上。在 South Park Commons 与 Soleio 的这场对谈里，这位 Anthropic 设计负责人谈了不少令人兴奋的尝试，也讲了他至今没能解决的麻烦。 ## 产品团队休假，模型还在进步 Joel 把早期的 Anthropic 比作一座有声望的研究实验室，自己的产品团队则像在后院搭帐篷的创业公司。他翻出一份两年多前的文档，标题竟然是“我们应该做移动应用吗”，当时这还是一个认真讨论的问题：既然公司的核心是模型研究，把平台开放给别人开发产品，也完全说得通。后来团队逐渐建立起做产品的能力，模型的新进展又一次打乱了熟悉的节奏。 "我们会让模型带着我们往前走。" 这种工作和他过去的经历很不一样。在传统软件公司，没人开发，软件就不会自己多出新用途；但在 Anthropic，只要研究继续，产品团队即使去度假，模型也可能变得更有用。于是，新同事带来的十八个月战略、市场规模分析和路线图，常常需要让位于一个更直接的问题：模型现在能做什么，我们怎样让用户用上它？ **Dario 反复强调，让产品跟着模型的能力往前走。**Joel 用一座巨大的风电场打比方：用户目前只是接上了烤面包机，已经觉得很好用，其实还有大量电力没有用起来。产品团队会围绕新的能力做相对轻量的尝试，打开更多入口，让用户能拿它去做自己的事情。  Joel Lewenstein 谈模型持续进步后，产品团队如何调整规划方式。 ## 做出原型以后，还要让别人用起来 新人进入 Anthropic，等着看的往往是路线图，迎面碰到的却是一堆没做完的原型。有些像奇怪的业余项目，有些已经在支撑内部的重要工作，同事每天打开的界面都可能不一样。Joel 说，看到最受认可的人都在主动做东西，其他人自然也会跟着尝试；某个工具逐渐在公司里被更多人用起来，才有了继续往外推的理由。 "内部使用情况大概是我们最好的信号。" 但做出一个能演示的东西，还不等于知道它好不好用。Joel 很怀念 Quora 早年的开发环境：每个人都有固定的开发地址，把链接发出去，别人就能亲手操作。他至今仍惊讶于团队多么依赖录屏来分享原型，明明已经做出来了，却常常只让对方看一段视频。**他看重的是带着一个问题做原型，再借自己和别人的使用，弄清原来的判断对不对。** 到了正式交付，很多工作仍然沿用成熟的软件开发方式。企业团队会和大型客户坐下来谈合规、管理等要求，写需求、开发、检查安全，再推出产品；那些上班打开电脑的员工，并没有主动报名参加 AI 实验。Joel 讲起一位朋友半开玩笑的感谢：Anthropic 的界面改得太勤，连朋友的客户都习惯了产品随时变化，这让他觉得实在不能算夸奖。 ## 内部工具的价值，来自它们知道什么 Anthropic 内部有部署工具的平台，员工可以把应用放到一个内部地址上，连到 MCP 和其他系统，供自己或同事使用。Joel 觉得，单看这些工具的界面，多半不会令人惊讶，真正有用的是它们能够读取公司的资料、调用其他工具，并且彼此连接。公司已经可以自己写出许多小应用，外部供应商就得提供一些内部不容易补上的东西。 "生产代码库是很多事情的事实依据。" 这也解释了为什么设计师常常用着别的工具，最后又回到 Claude Code。比如要把四个设置页合并进新的导航，正在运行的代码里就有现有功能、规则和设计系统，文档未必写全，更不一定及时更新。**直接面对代码，团队才容易确认眼前的产品到底是什么样。**Joel 也承认，更友好的设计工具应该补上这部分能力，或者让模型自动把代码里的变化同步到文档里。 不过，他并没有因此停用外部软件，Listen Labs 和 Figma 仍在团队里被频繁使用。前者能够找到外部受访者、组织研究，后者积累了大量关于怎样做好产品设计的经验；这些东西，很难完整写进一份功能规格，再照着复制出来。对他来说，一家工具公司能否带来对某项专业工作的理解，依然影响它是否值得购买。 ## 一个小小的界面改动，也能改变使用方式 Artifacts 是 Joel 回顾团队工作时，特别愿意提起的例子。最早的实现很简单：发现 Claude 回答里有 HTML，就把原本挤在聊天框里的内容，移到右侧一个更大的区域。代码层面只是很薄的一层界面调整，使用时的感觉却发生了变化，作品有了自己的位置，用户可以一边看它，一边在旁边讨论怎样修改。 "我正在用这个工具做出一个东西。" **把作品和关于作品的对话分开，让用户更容易觉得自己正在制作一个东西。**这件事也让 Joel 更确信，即使模型贡献了大部分能力，界面仍然能改变人们怎样使用它。Claude Design 后来也来自团队自己的使用需要，最初只是设计师写了技能来改善生成效果。随着使用增多，他们觉得命令行不够方便，才在 Claude Code 之上加出图形界面。 Joel 最喜欢的却是生成之前那组问题：做网页还是手机应用，最初的方案要多发散，前后两个要求究竟是什么关系。几乎每次回答，他都会发现自己漏想了什么，或两个念头之间还有一层联系。他期待有产品能把脑海里说不清的想法慢慢问出来，帮助自己探索、再向别人表达；至于由哪家公司做出来，他并不介意，也特意说明这不是在承诺路线图。 ## 团队越能做东西，越需要有人作出取舍 原型越多，团队也越难弄清彼此在做什么。Joel 很喜欢的一个内部工具会扫描 Slack，提醒他某个频道突然聚集了设计讨论，或者几位平时不合作的人正在一起做东西。这个工具帮助他发现动向，但问到 Claude 能不能进一步给出组织和管理建议时，他明显谨慎得多：它能反映复杂情况，还不太能替团队完成艰难的取舍。 "这仍然是一个非常依赖人的过程。" 组织结构本身也总在变化。Claude Code、API 平台、企业和消费者团队各有重点，做出来的东西又经常影响别人；Skills 和定制能力曾经归增长团队，后来桌面产品也越来越依赖它们，就得重新调整分工。Joel 不讳言，每次重组只是把复杂问题挪到了不同位置，过去几个月密集推出的产品，也还没有形成用户容易理解的整体。 **把信息整理出来之后，仍然需要有人决定哪些方向要做、哪些要放下。**Claude 可以列出几种战略选择，整理员工和管理者分别支持什么，甚至推荐一种方案；但决定公布后，人们要不要接受、怎样带着分歧继续合作，仍得由团队去完成。Soleio 问起共同认知和协作时，Joel 说这正是自己每天最头疼的事，他们的内部工具也还没追上问题。 ## 做得出来的功能，不必全都交给用户 如果每家公司都以 Anthropic 最近的速度更新产品，会发生什么？Joel 想象用户可能会烦到把手机扔进海里：一批又一批新功能不断出现，开发者自己还没想清楚如何取舍，就全部交给用户体验。代码生产得更快之后，设计师需要面对的，恰恰是这些东西究竟有没有人愿意用。 "先弄清楚什么是好的，再给我一个好的东西。" **什么值得占用一个人的注意力，是 Joel 认为设计需要回答的问题。**团队是否选对了问题，解决方式是否合适，用户花时间试过之后能得到什么，都不能因为做出来更容易就省略。他不希望每个还在探索中的想法，都像剪辑室里留下的素材一样，被原样搬到用户眼前。 他也想过另一种未来：人们不再集中使用少数几个大型应用，而是各自拥有几十上百个按需要生成的小工具。他自己已经在用一些通过提示词创建的手机小应用，解决那些过于琐碎、个性化，很难指望通用软件专门照顾的需求。如果这种使用方式发展起来，设计师的工作也会更多落在生成工具的平台上，而不只是设计某一个所有人共用的应用。 ## 她已经查完资料，却没想到让 Claude 写大纲 Joel 的妻子是一名律师，因为担心幻觉，最初对 AI 很谨慎。后来，她尝试让 Claude 帮忙研究一个感兴趣的法律领域，逐渐形成了一门课程的构想，想向法学院提议开课。Joel 问她打算什么时候提交，她却说还要做课程安排、写教学大纲，想到这些就不太愿意继续了。 他提醒妻子，资料明明都已经放进对话里，直接在输入框里写“做一份教学大纲”就好。她照做之后，结果相当不错，这件事却让 Joel 有些不安：**用户已经走到了离完成只差一步的地方，仍可能完全没想到下一步也能请模型帮忙。**他可以在妻子身旁提醒，却没法对所有用户都做这样的指导。 "我总不能和所有用户结婚。" 让 Claude 主动提出下一步，似乎很自然，但 Joel 担心这里有条很细的界线：主动帮人解决问题，不能变成不断催促人多发一条消息，也不能让用户觉得自己被指挥。Soleio 把助手比作副驾驶，可以提醒附近有家不错的餐厅，路线仍由驾驶者决定。Joel 认同这种差别，也认为帮助用户发现还能做什么、同时保留主动权，正是设计要继续解决的问题。  Joel（右）向 Soleio 讲述妻子的课程大纲经历：用户未必知道 AI 还能帮自己做下一步。 ## 孩子问问题时，先别急着让模型回答 聊到孩子时，Joel 承认自己也不知道未来应该读什么专业、会有哪些工作。他的三个孩子已经知道 Claude 有语音模式，遇到父亲答不上的问题，常常催他让开，直接去问模型。他于是借鉴 Mike Krieger 家里的规则，在提问之前，大家先猜一个答案，说清楚为什么这么想，再讨论其他可能，不能只等着听一句标准解释。 "问 Claude 之前，我们先猜一猜答案是什么。" **他仍然相信好奇心和探索很重要，尤其孩子本来就带着这样的兴趣。**获得答案更方便之后，怎样保留自己想一想的过程，成了他在家里认真练习的事情。对于更广泛的人机关系，他也把注意力放在模型什么时候应该建议、什么时候应该退后，以及它如何回应一个人。 这些问题需要模型研究和设计团队一起面对，而他自己的工作也没有因此远离具体体验：应用是否让人觉得安心，是否容易使用，手机上能不能快速打开。有人只是想在一天短暂的空隙里问个问题、理一理思绪，Joel 希望产品能在这些时候帮上忙；模型能做的事越来越多，这些普通的使用细节仍然值得认真做好。 ## 写在最后 Joel 给孩子定下的规则，也适合留在自己的工作里：先猜一猜，说清理由，再去问 Claude。面对一个新想法，可以先写下最想弄明白的问题，做个原型，交给别人试用，看实际反应和预想差在哪里。工具让尝试变得更容易，也给了我们更多机会，把那些原来只能凭经验判断的事亲自做一遍。 内容来源："Anthropic's Head of Design on AGI-Maximalist Product Design | Joel Lewenstein"丨South Park Commons（嘉宾：Joel Lewenstein（对谈：Soleio）） 原视频： 相关文章 * [《Claude Code是怎么设计出来的：下一代设计师负责什么丨Dive Club》](https://mp.weixin.qq.com/s?__biz=MzcxMDA5NTI0OA==&mid=2247488398&idx=1&sn=269a379548a31135451ba48c0676c5e0&chksm=f51d2b71c26aa26778b2ad2710f478e0575b41192a4f71cd1f62ad7674f0a967e683b6c96158&scene=21#wechat_redirect) * [《YC设计负责人：AI 正在重写设计师的工作流丨Y Combinator》](https://mp.weixin.qq.com/s?__biz=MzcxMDA5NTI0OA==&mid=2247488384&idx=1&sn=2b9655bc10a7254a72379d0df5a36e22&chksm=f51d2b7fc26aa269799b493cc4c1761228c6dad9e53dad478e5ec4907f4893170ea4c0396487&scene=21#wechat_redirect) * [《Anthropic 工程师：他们到底怎么用 Claude 工作丨How I AI》](https://mp.weixin.qq.com/s?__biz=MzcxMDA5NTI0OA==&mid=2247488265&idx=1&sn=2c8832cc0d4ebeef0227f1e6746d905d&chksm=f51d2bf6c26aa2e0d4bb95769f36797dbb9593d9e0a3f11ebfe33bf1812db2837514b61ec9e5&scene=21#wechat_redirect) 如果你现在没空，可以收藏进晚点再听，通勤、走路或做家务时一次性听完⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ [跳转微信打开](https://wechat2rss.bestblogs.dev/link-proxy/?k=7a133cb0&r=1&u=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzcxMDA5NTI0OA%3D%3D%26mid%3D2247488932%26idx%3D1%26sn%3D48cf8b0b65a117d84c30fb67a27a75e9)