AI 时代，设计师在做什么？Cowork 设计负责人的第一手视角
上一篇文章《AI 时代，为什么产品经理反而更吃香了？》中提到 Lenny Rachitsky 最新的就业市场报告的一组数字：2023 年中期以来，PM 岗位需求超过了设计师并持续拉大，目前 PM 需求是设计师的 1.27 倍。设计师的全球开放岗位约 5,700 个，自 2023 年初以来几乎没有增长。
对此，Lenny 的猜测是：”因为 AI 让工程师可以更快地推进产品，传统设计流程被卷入的机会变少了。”这个解释合理，但还是外部视角。我一直想找到一个来自内部、正在亲历变化的设计师声音。
正好最近 Peter Yang 采访了 Anthropic Cowork 产品的设计负责人 Jenny Wen。40 分钟的对话里，她几乎回答了所有我想问的问题。这篇文章是对那次访谈的编译解读，夹带一些我的观察。
原始访谈：Claude Cowork Tutorial from Cowork’s Design Lead (40 Min) | Jenny Wen，Peter Yang 频道
设计师的日常变了：从”一个项目做到底”到”同时顾问五六个”
Peter 问了一个最朴素的问题：你现在一天都在干嘛？
她没有说”做高保真设计稿”或者”画原型图”，而是用了一个词：jamming（即兴协作）。
“我花大量时间做的事就是把产品推出去……很多时候就是和工程师、产品经理用很不正式的方式即兴协作。通常是一起看一个原型，然后讨论它可以怎么演化。”
她说自己不再是一个人埋头做一个项目，而是同时在五六个项目上当”顾问”。工作方式变得更随意，更多是坐下来和工程师一起看原型、提反馈、讨论交互行为。
这个描述让我想到 Cat Wu（Claude Code 的 PM 负责人）在她那篇文章中说的一句话：”设计师直接提交代码，工程师做产品决策，产品经理构建原型和评估。”角色的边界在模糊化，而 Jenny 的日常正好是这句话的设计师版本。
Jenny 说的”prototype”（原型）不是 Figma 里的那种，而是”可运行的原型，跑在我们内部构建版本和 Claude/Cowork 实例里的东西”。她看的是真实运行的产品，不是静态原型。这意味着设计师的反馈环节从”看 mockup → 提修改意见 → 等工程师实现 → 再看”变成了”直接在跑着的产品上聊”。
Spec 已死（几乎）
Peter 追问：你们还做 spec 和 Figma 吗？
Jenny 坦率得有点惊人：
“我们不再那么频繁地写 spec 了……通常也没那么详细。就几个要点。不会再做那种精心过度设计的漂亮表格了。”
Spec 没有完全消失，但退化成了给安全团队和法务团队看的几个要点列表，用来说明”这次发布会做什么”。至于 Figma，Jenny 说还在用，但文件也没以前那么精细了。
这和 Anthropic 的工程文化有关。上一篇文章中提到，Cat Wu 描述的 Claude Code 团队工作方式是”用短冲刺替代长路线图”，鼓励每个人（包括设计师）用一个下午去验证一个想法。在这种节奏下，花两周写一份漂亮的 spec 是不经济的。
不过这里有一个容易误读的地方：spec 变少不代表设计思考变少了。Jenny 后面展示的工作流说明，设计师的思考密度可能反而更高了，只是不再以文档的形式固化下来。
“Garbage in, treasure out”：AI 帮设计师做了什么
Jenny 现场演示了她怎么用 Cowork 工作。她给自己的工作方式起了个名字：**”garbage in, treasure out”**（垃圾进，宝藏出）。
具体的流程是这样的：她把一堆用户访谈记录扔给 Cowork，同时让它去 Reddit 和社交媒体上搜集用户反馈，然后让 Cowork 从这些混乱的输入中提炼关键洞察。Cowork 会启动多个子 agent 并行处理，最终输出一份结构化的洞察报告。
然后她会进一步要求 Cowork：基于这些洞察，给我推荐应该做什么功能。Cowork 会分析优先级，列出 P0 和 P1。如果她对某个方向感兴趣，还可以直接让 Cowork 生成线框图选项。
最让我印象深刻的是她设置的一个定时任务：每周一早上 10 点，Cowork 自动运行一次完整的反馈收集和分析流程，生成一份包含三个产品创意的演示文稿，发到团队 Slack 频道。
“我每周一早上 10 点都会收到这份演示文稿，里面有三个不同的产品创意……它把从反馈到产出实际成果的迭代周期压缩得很紧。”
设计师把 AI 变成了自己的”产品研究助手”和”灵感生成器”，自己则专注在更高层的判断上：哪些方向值得投入，哪些该砍掉。
判断力和品味才是核心，不是产出量
Jenny 在访谈中反复强调一个概念，虽然她没有直接用这个词，但本质就是 taste（品味/判断力）。
Peter 问到是不是可以把任务直接交给 Claude 去提 PR。Jenny 没接这个茬：
“我们不会把所有事情直接交给 Claude 做。我们依赖自己的判断力，以及筛选和决定真正该做什么的能力。”
她说建立这种判断力的方式很朴素：一直泡在用户反馈里，内部的、外部的，听多了你自然就知道什么该修、什么该做。
上一篇文章的核心论点放在这里同样成立：”决定做什么”和”判断做得好不好”比”把东西做出来”更有价值。Jenny 的日常产出不是像素和设计稿，而是”从一千条反馈中识别出三个值得做的方向”。
内部 dogfooding（吃自己的狗粮）的力量
一个让我意外的细节是 Anthropic 对内部反馈的依赖程度。Jenny 说 Cowork 团队有一个持续运行的内部 Slack 频道专门收集反馈，而且他们非常倚重内部用户：
“我们非常依赖内部的重度用户……内部的人愿意对你坦诚，而且他们往往是把产品能力推到极限的那群人。”
她还做了一个有意思的区分：内部用户和外部用户给的反馈类型不一样。外部用户关注的是”这个功能能不能跑通我的工作流程”，而内部用户会深入到交互细节和打磨层面。这两种不同高度的反馈结合起来，比单独依赖任何一种都更有效。
Jenny 之前在 Figma 工作过，她说那里也是同样重视 dogfooding 的文化。Claude Code 的成功也是同理：” Claude Code 成功的很大一部分原因就是倾听一线用户。”
Cowork 的真实起源：不是 10 天，是一年
媒体报道中经常说 Cowork 是”10 天做出来的”。Jenny 纠正了这个叙事：
“那是某次采访中被摘出来的一句话……真实的故事是，Cowork 这个方向基本上从我一年前加入 Anthropic 起，公司就一直想做了。”
实际情况是：一整年里，团队做了很多不同的原型，有些来自产品侧，有些来自 labs 那边。尝试了不同的 agent 架构和 UX 方案，好几个都没跑通。
真正的转折点是去年假期期间。很多非技术人员终于有时间试用 Claude Code，结果发现它不只是编程工具——有人用它解析播客字幕，有人做复杂的数据分析。团队看到了”Claude Code 的 agent 架构 + 非技术用户”的早期 PMF 信号。
“我们开始看到 Claude Code 的 agent 架构在非技术用户群体中出现了早期的产品市场匹配信号。”
于是他们决定：虽然原计划几周后再发布，但现在就是时机。加上之前一年积累的原型和技术基础，最终执行阶段确实只用了 10 天。
这个故事的价值在于：表面的”10 天奇迹”背后是一年的探索和积累。这对任何做产品的人都是一个提醒：别只看到最后冲刺的速度，而忽略了让冲刺成为可能的所有前置工作。
这也和我之前写的那篇《当编程被”解决”之后，会发生什么？》互相印证。Anthropic 工程副总裁 Boris 在办公室看到数据科学家自己装 Node.js 跑 Claude Code 做 SQL 查询，然后设计师跟进，然后财务团队跟进。这些非技术人员费了很大劲安装终端工具，就为了用 Claude Code 的能力。Boris 意识到这就是产品信号，于是有了 Cowork。
被砍掉的原型：过度设计的教训
Jenny 展示了几个没有上线的早期原型，每一个都比最终版本复杂得多：
第一版：workflow 工具型 UI。 左侧是结构化的输入面板（添加数据源、设定输出格式），chat 被放在次要位置。结果是：Claude 在当时的技术条件下跟不上这么结构化的流程，而且用户觉得”填表”太累。Jenny 的原话很直接：”都 2025 年了，我们为什么还要这么做？直接让 Claude 帮我们干不就行了？”
第二版：引导式 chat。 在对话入口提供预设选项（分析、文档、演示等），每个选项下有滑块可以调节细节。问题是视觉元素太多，用户进来就被信息淹没了。
第三版（初次发布版）： 有一个类似向导的流程引导你选择任务类型和参数。上线后团队发现这些引导并不比直接输入提示词更好用。
最终他们把 UI 大幅简化，回归到”Claude 的活跃待办清单”这个概念：你可以看到 Claude 正在执行的任务、等你审批的结果、定时任务的状态。
“在所有这些探索中，我们一直在平衡一个大问题：我们要多大程度上预设使用场景，还是让用户像聊天一样自由发挥。”
从过度结构化到极简 chat，这个演化路径本身就是一个设计教训：当底层模型能力足够强时，最好的 UI 就是最少的 UI。
Anthropic 的规划方式
Peter 问了关于 Anthropic 内部规划的问题。Jenny 的描述刷新了我对大公司产品管理的想象：
月度规划，不做年度。 Cowork 团队用一个电子表格管理优先级，最多 12 个条目，每个指定一个 DRI（Directly Responsible Individual），每周回顾进度。没有精心编排的年度规划仪式。
视觉化替代文档化。 Jenny 说她去年做过一次 Northstar vision deck，但觉得传统意义上的一年愿景在这个领域没什么意义，因为技术在不断变化，新模型的发布节奏越来越快。现在她做的是 3-6 个月的短期愿景，而且倾向于用可交互的原型而不是静态文档来传达。
设计的独特价值：把五个方向拧成一个故事。 这可能是 Jenny 在整个访谈中对”设计师还能做什么”最清晰的回答：
“我们经常有五个团队在做非常相似的东西，相互碰撞，看起来像是重复劳动。设计真正能做的是策展和整合这些想法，指出一条通往理想体验的路，而不是五个各自为政的体验。”
在一个人人都能写代码、人人都能提产品想法的环境里，设计师的价值不在于画图，而在于把散落的碎片拼成一个连贯的故事。
“脚下的规则确实在改写”
访谈结尾，Peter 问 Jenny 对其他设计师有什么建议。她的回答很真实：
“If you feel like the ground is shifting beneath your feet, it’s because it is.”
如果你觉得脚下的规则正在被改写，那是因为它确实在被改写。
她没有粉饰现状。她说设计师正在经历工程师已经经历过的那一轮冲击：
“这一轮变革现在轮到设计师了。我们感受特别强烈，因为我们周围的角色已经变了，而我们是第二波冲击。”
但她也给出了一个积极的参照：
“我会看看身边的工程师同事，看他们已经适应了多少……他们经历了多大的变化，却依然在产出更多、更好的工作。他们是我的榜样。”
工程师已经走过了这条路。他们的工作方式被 AI 彻底改变了，但优秀的工程师反而产出了更多、更好的工作。设计师现在面临同样的转型，而工程师的经验可以作为参照。
Jenny 最后补了一句：现在工程师们几天就能做出一整个功能，过去这得花好几周。整个产品开发的节奏在加快，能跟上这个速度的设计师，影响力只会更大。
回到开头的数据
写完 PM 那篇和设计师这篇，两个访谈放在一起看，有一个共同的信号：区别不在于你的 title 是什么，而在于你在哪个环节做出了关键判断。 Cat Wu 说 designers ship code，Jenny 说自己在 implementing stuff，Peter Yang 让 AI 先打所有东西的草稿。当所有人都能借 AI 做出东西时，”做出来”本身就不再是稀缺能力。
回到那个 5,700 的数字。设计师岗位数停滞，但设计的需求未必在减少。更可能的解释是：设计工作正在被重新分配。低保真原型、线框图、重复性的 UI 变体被 AI 吸收了；PM 直接做原型、工程师直接调交互，承担了一部分设计师过去的活。而留下来的那部分——从一千条反馈中提炼三个方向、把五个团队的想法拧成一个连贯体验、用可交互的原型给团队指明三个月后的方向——反而变得更稀缺了。
Jenny 说得对：脚下的规则确实在被改写。但改写的方向不是淘汰，是重组。
本文是”AI 时代角色系列”的第二篇。第一篇《AI 时代，为什么产品经理反而更吃香了？》聚焦 PM 角色，本篇从设计师视角补充。后续可能还会写工程师篇。
原始访谈来源：Claude Cowork Tutorial from Cowork’s Design Lead (40 Min) | Jenny Wen，Peter Yang 频道