What happens now that AI can design? | OpenAI, Head of Design (Ian Silber)

OpenAI 设计负责人 Ian Silber 说，AI 设计师能做出好方案，但“理解用户”和“创新体验”还得靠人类。

---

source_name: "Lenny's Podcast"

youtube_url: "https://www.youtube.com/watch?v=BV0hy6NET-U"

---

AI会设计后，设计师反而更稀缺

Ian Silber 是 OpenAI 产品设计负责人，已在这个岗位任职三年；在 AI 公司里，三年几乎算一个时代。他此前参与过新闻应用 Artifact，也在 Instagram 工作了八年，既见过成熟消费产品如何靠细节取胜，也正在参与把前沿模型变成大众产品的过程。这次访谈把问题翻了过来：当制作界面越来越便宜，什么样的判断反而更贵？

这期回答了 7 个问题：

1. 当 AI 已经是“出色的产品设计师”，人类设计师还凭什么不可替代？
2. 为什么工程师生产力能涨到 10 倍甚至 100 倍，设计流程却没有被同等压缩？
3. 哪些功能值得试 100 次再发布，哪些应该在 4 小时内上线？
4. 面对从晚餐食谱到日本农场自动化的需求，AI 产品界面该如何不失控？
5. PM、设计、工程的边界会消失吗，还是只是每个人都要多戴几顶帽子？
6. OpenAI 招设计师时，为什么不要求 AI 履历，却格外看重好奇心？
7. 在技术每月都变的环境里，怎样判断一个体验是否值得投入慢工？

被问到 AI 会不会成为极其优秀的产品设计师、人类还剩什么价值时，Ian 没有绕开最刺耳的答案。他认为这已在发生："I think it already is an incredible um product designer."（我认为它已经是一名出色的产品设计师。） 这句话的分量在于，说话的人正是 OpenAI 的产品设计负责人，不是站在外面预测趋势的人。

但他说的“产品设计师”，不等于 AI 已经拿下设计中的全部子能力。Ian 特意划了边界：它未必是最好的视觉设计师，也未必最擅长信息层级、排版、用户体验和交互设计。AI 可以迅速给出十个页面方案，却不天然知道用户打开页面前处于什么情绪；可以模仿既有产品的组件，却不一定能看见一个还没有被命名的需求。

Ian 把人的价值放在四件更难被压缩的事上：观察人们实际怎样使用产品，理解他们真正需要什么，发明新的交互方式，以及让产品带上“谁做了它、他有什么观点”的表达。iPhone 的多点触控、Instagram 对手机拍照与分享的理解、Snapchat 对即时沟通方式的重写，起点都是有人先判断：这里有一种新行为值得被设计。

这意味着，设计师的竞争重心会从“我能产出多少张页面”移到“我发现了什么、我拒绝了什么、我为什么认为这件事值得做”。当所有人都能让 AI 生成界面时，页面本身像印刷品一样变得廉价；能决定下一本书该写什么的人，反而更稀缺。边界也很清楚：AI 正在变快，没人能保证它永远不擅长视觉或交互。但在当下，人的判断仍是把模型能力变成具体产品的那道窄门。

被问到为什么设计师和研究员在科技从业者调查中最焦虑时，Ian 给出了一个很具体的内部落差：工程师的生产力已经达到 10 倍，有时甚至 100 倍；设计团队却没有出现同等增幅。原因并不神秘。写代码时，coding agent 往往能把一个明确指令相对直接地执行出来；设计工作却常常是先觉得自己想到一个好主意，做出来发现很差，再改一次还是不对，拿给用户或内部同事看，反馈又证明方向错了。

他用一句话概括这种状态："The design process is really still very messy and fluid."（设计过程仍然非常混乱且流动。） 这里的“混乱”来自产品问题本身不服从直线推进。用户到底看不懂什么？一个功能是没价值，还是入口不对？团队争论的是方案细节，还是根本没对齐问题？生成一张更漂亮的图，解决不了这些问题。

AI 确实压缩了发散和制作：设计师能更快做出更多想法，迅速把坏点子丢掉。但验证并没有消失。设计仍需要用户反馈、内部评审和跨团队对齐，尤其在大公司里，多个团队对资源、目标和风险的协调仍有明显开销。一个原型可以十分钟做完，让组织对它达成共识却未必只要十分钟。

这意味着，设计组织不能生搬硬套工程团队的“产出倍数”。如果只看页面数、原型数或上线功能数，AI 会制造一种虚假的繁荣：东西越来越多，真正学到的东西未必更多。衡量设计提速，要看一个假设被验证或推翻得多快。反面也要看到：不能因为流程天然 messy，就把混乱当借口。AI 没有替设计师完成学习闭环，但它让每一轮学习可以更密集、更便宜。

被问到传统“原型、测试、研究、迭代”的流程是不是已经来不及执行时，Ian 拒绝二选一。OpenAI 接受公开试验和快速学习，也会对某些体验近乎执拗地打磨。ChatGPT 中有些功能，团队会尝试 100 个方案，扔掉 99 个，最后只发一个："We try 100 things we throw out 99. We finally ship one."（我们试 100 个方案，扔掉 99 个，最后发布一个。）

他举了 composer，也就是用户在 ChatGPT 中输入和组织请求的核心区域。这个区域几乎每天都在变化，团队不断尝试、不断抛弃。对需要深度打磨的部分，他们仍会做测试、A/B 测试和用户研究。A/B 测试就是把不同版本同时给不同用户使用，用实际行为而非会议里的偏好判断哪个更有效。

这和“AI 时代没有时间做研究”的说法不一样。更准确的变化是，设计不再用一套同样昂贵的流程对待所有功能。某个模型能力下个月可能就被替换，围绕它做三周精雕细刻，可能是在给会移动的地基贴瓷砖。相反，用户每天都要接触、会影响长期使用习惯、且技术变化不太会推翻的体验，值得投入更长的验证周期。

这意味着，设计团队要学会分层下注：把快，留给高不确定、低沉没成本的探索；把慢，留给会沉淀为产品骨架的部分。不是每一项功能都配 100 次尝试，也不是每一项功能都该四小时上线。Ian 也强调，投入取决于产品所处阶段和成熟度。最危险的做法，是把“快速”误认为不思考，或者把“严谨”误认为所有地方都要走完整流程。速度不是统一标准，耐久性才是。

谈到 ChatGPT 怎样同时服务极广泛的用户时，Ian 描述了一组几乎荒诞的跨度：有人只想问晚餐食谱，或者下一次该剪什么发型；也有人正用它帮助自动化日本的农场。Instagram 的用户很多，但产品的主要使用方式相对有限；ChatGPT 的难题不同，它面对的是从生活琐事到专业生产活动的极宽任务带。

Ian 用“capability overhang”解释这个问题：模型真实能提供的能力，绝大多数用户只拿到了很小一部分价值。这不表示产品失败，用户仍可能从一个简单问题中得到帮助；但它要求界面同时完成两件互相拉扯的事：让大众用户一眼就能开始，又不能把前沿能力藏到只有专家才找得到。

所以要问的是："how do you design something that can kind of shapeshift into anything?"（你要如何设计一种能够变形成任何东西的产品？） OpenAI 已经在做一些方向性的尝试。开放问题可以收到可点选的追问，用户不必从头组织完美提示词；让 AI 写邮件或信件时，结果会进入可直接修改的 writing blocks，不会停留在一段不可操作的文本里；图像生成又有不同的专用工具。

这意味着，AI 产品的设计中心会从导航栏、功能入口转向意图和上下文。同一个输入框，面对写作、图像、数据分析或个人事务，应该长出不同的“可操作性”。但“会变形”不等于首页塞满模式、开关和模型名称。Ian 认为，真正走向大众时，体验应该被蒸馏到用户不需要思考该选哪个模型、开哪个模式。难点正在这里：能力摆得太早，用户不理解；能力藏得太深，产品又只剩一个空白框。

被问到 PM、设计师和工程师会不会最终都变成一个“builder”时，Ian 的答案既承认变化，也给这种想象泼了一盆冷水。他认为角色边界原本就有重叠：有些设计师很像产品经理，擅长定义问题和取舍；有些设计师又像追求完成度的工程师，对实现和细节很敏感。AI 只是让这种交叠更明显，因为设计师更容易做原型，工程师也更容易参与产品和界面判断。

如果今天创业，Ian 会优先找能在不同工作之间流动的优秀通才。这是早期团队的现实：人少、问题多、每个人都要补位。但他并不相信大公司里一个人能同时设计产品、协调多个团队、分配资源、确保系统可靠运行，还把每件事都做好。正如他说的："there are different sort of hats that you need to wear to build great software"（要构建出色的软件，你仍需要戴上不同种类的帽子。）

PM 的帽子，是把多个团队拉到同一个问题空间，帮助聚焦、协调资源和推进决策；工程师的帽子，是确保输出能在更大的系统中可靠运行；设计师的帽子，则是把需求、能力和人的实际使用方式编织成体验。帽子可以多戴，但不能因此假装它们不存在。

这意味着，未来的职能筒仓不会彻底坍塌，能力组合会更流动。设计师要懂一点产品和实现，PM 要理解体验与技术约束，工程师也会更直接参与产品表达。但组织仍需要有人对关键责任负责。创业早期，通才的价值很高；公司规模变大后，把设计、对齐、运营和工程可靠性压给一个“全能 builder”，往往是在寻找几乎不存在的完美人选。跨界会减少专业之间交接时的失真。

被追问 OpenAI 如何决定哪些功能快速公开试验、哪些功能长期打磨时，Ian 给出一个很极端的速度差：有些想法从出现到上线大约只要 4 小时。但当问题变成“ChatGPT 深度进入一个人的生活后，应用该呈现什么感觉”，团队不会隔夜设计、第二天就发布。更长期的项目会先在白板和 Figma 中探索，制作原型，再让内部员工先用起来测试。这就是 dogfood，团队自己先当用户，并比较多个方案。

乍看之下，这像一道简单的管理题：变化快的就快做，稳定的就慢做。但 Ian 点出真正困难的部分："And it's hard to know what that is."（而难的是，你很难知道那到底是什么。） 你以为稳定的东西，可能被一个新模型、一种更低的延迟，或一个新能力在一个月后推翻；你以为只是临时补丁的交互，也可能意外成为用户每天依赖的习惯。

因此，设计领导者的新判断力要给体验分配“耐久性预期”。所谓耐久性，指的是判断它是否大概率会在未来一段时间继续存在，是否会深刻影响用户体验，是否值得被做成可复用的系统。对低耐久性的部分，目标是尽快得到反馈；对高耐久性的部分，目标是建立可信赖、一致且能持续演化的体验。

这意味着，团队不能用“技术变化太快”来逃避设计，也不能用“要做长期体验”拖慢所有实验。前者会让产品永远停在临时状态，后者会让团队错过学习窗口。Ian 的坦诚也提醒了一个边界：这里没有可靠公式。技术能力、模型智能、等待时间和交互需求都可能快速变化。判断会错，所以要保留回头修正的空间，而不是把一次决策铸成永久结构。

被问到 OpenAI 招什么样的设计师、焦虑中的设计师如何重新进入状态时，Ian 的标准不是“你是否已经有 AI 履历”。OpenAI 不要求候选人有 AI 背景，但会明确期待两件事：对 AI 保持高度好奇，并愿意跳进去学习怎样用它工作、怎样让更多人也能用上它。原型能力也很受重视，因为它让一个想法更快从语言变成可以讨论的东西。

他讲了自己的一个小经历。休陪产假期间，他尝试用早期 coding agent 做个人项目，工具不是完全不能用，却总会卡在各种小问题上。一个月后 Codex 发布，他又回来试了一次，感受变成“它就这么能用了”。这个时间差很短，却足以改变一种工作方式。Ian 用一句话总结这种环境："What didn't work yesterday might work today."（昨天不奏效的东西，今天可能就奏效了。）

这意味着，职业优势越来越取决于“重试频率”，不只取决于资历或某款工具的熟练度。有人一次失败就把某个工具归类为玩具；有人在能力跨过临界点后迅速回来再试，先获得了新的杠杆。后者会在快速变化中持续校准自己的判断。

这并不要求设计师假装不焦虑。岗位期待不清楚，工具也不停变化，焦虑是理性的。Ian 的建议是把不确定性转换成可操作的探索：用 AI 帮助思考，用它做一个粗糙原型，看看它在哪一步真的能省力，再在下一个模型或新功能出现后回头验证。对刚入行的人，这甚至可能是机会：所有人都仍处在早期，旧工作流的惯性有时比零基础更难摆脱。

“AI已能做产品设计，人类的稀缺性变成知道该做什么”和“提前识别哪些体验值得做成耐用品”，指向的是同一件事：制作与试验正在变廉价，但产品判断没有因此自动化。反而因为能做的东西骤然变多，判断什么不该做、什么该先试、什么值得沉下去做，变成更昂贵的能力。

“万能AI的最佳界面，需要一个会变形的入口”也不是单纯的 UI 难题。它要求团队理解不同用户的意图，知道何时该把复杂能力露出来，何时该替用户把复杂性藏起来。这个工作无法只靠增加功能完成；它需要设计、产品和工程分别戴好自己的帽子，又能一起看见完整系统。

放到读者自己的处境里，可以先问：你手头正在做的体验，究竟是该用四小时做出来获得反馈，还是该花更多时间把它做成用户会反复依赖的东西？你是否还在把“交付页面”当成主要产出，还是已经开始用更快的制作能力，换取更多观察、验证和取舍的时间？AI 把方向盘变得更灵敏，但车该开向哪里，仍然需要人决定。