Cowork 设计负责人的 Claude Cowork 教程(40 分钟)——Jenny Wen

• Jenny Wen 是 Anthropic 设计负责人（design lead），此前在 Figma（后文多次拿 Figma 经验作对照）。主持人 Peter Yang 自陈重度用户——「我这辈子都泡在 Claude 上，现在基本就活在 Claude 里」。开场定坐标系：本期演示 Jenny 如何用 Cowork 和 Claude Code 做设计、交付产品，并讲 Cowork 内幕与产品走向；关键事实是 Anthropic 现有三个独立产品——Claude（对话）、Cowork、Claude Code。→ 详细

• Jenny 反问「真的有所谓典型的一天吗？」——她大部分时间做的都是「为了把产品交付出去（get product out the door）」，很大一部分是以很不正式的方式跟工程师、产品的人「jam」（即兴合奏借喻，即凑一起碰撞想法）：一起盯原型、聊某个东西的「行为表现（behavior）」，有时自己亲手实现。她坦言方式有点「松散（loose）」，根本原因是很少只聚焦一个项目，而是同一时间像在为五六个不同项目做咨询（consulting on five or six different projects）——这是她对当下设计岗位最核心的自我描述。→ 详细
• Peter 复述流程时，Jenny 纠正一个关键细节：这些往往不算「原型」，而是能跑起来的实例（working prototypes）——内部构建版里真实的 Claude 或 Cowork，不是一次性 demo 假壳。她的流程是先去「压榨它、看它能做到什么」形成看法，再直接坐到工程师旁边说「这些是该改的地方」。她强调：待在设计工具里迭代、精修（polish and iteration）并没有消失，仍非常重要；只是同时运转项目更多，用很随意非正式的方式反而更高效。→ 详细

• 关于「还做不做 spec 和 Figma」：Jenny 说她还是会做 Figma，但 spec 写得没那么频繁了，写出来也「没那么详细（not as detailed）」（spec 指产品规格/需求文档）。优先级排序仍要做、仍以文档存在，但主要用途变了：它「其实对我们很有用，可以交接给安全团队、法务团队之类的，让他们了解这次发布里发生了什么」——从「指导开发的蓝图」退化成「让合规相关方知情的知会文档」。→ 详细
• 形态上也大幅瘦身，开场那句金句点得很透：一年前的 spec 还会郑重其事写「里程碑一（milestone one）、我们有这些 P0、有这些 P1」，现在通常就只剩几个要点（just a few bullet points），而不是那种「过度设计的、漂亮的表格（this beautiful table that's over-engineered）」。她明说 Figma 文件也是一样的道理。→ 详细

• Jenny 主动演示 Cowork，道出「小秘密」：现在除了非常细枝末节的生产代码（nitty-gritty production code），所有跟对话有关的场景她都完全用 Cowork 了，只在做打磨（polishing）时才用 Claude Code。她演示用的是干净的「外部账号」，但特意说明「我真正的 Cowork 里有很多不同会话，我经常并行地跑（running in parallel）」。她把强项概括成一句传神的话——「garbage in, treasure out（垃圾进、珍宝出）」，反转计算机老话「garbage in, garbage out」：Cowork 恰恰相反，「特别擅长把很多来源拿过来、挑出精华（picking the gems out）、变成真正有产出价值的东西」。→ 详细
• 销售场景印证三产品分工演化：做 Cowork 初期，团队找了几位内部销售当输入来源，其中几个是「铁杆 Claude Code 用户（die hard Claude Code users）」，居然用 Claude Code 生成线索清单（leads lists）、想打电话话术（scripts for calls）——Jenny 说「简直让我大开眼界，我当时甚至没想到 Claude Code 能做这些」。结论：这些人「基本上全都转到 Cowork 上了」，更多同事也跟着用。Peter 一句点破——「能看到一个 UI 其实挺好的」；Jenny 补一层：Cowork「跟他们正在做的其他工作贴得太近了」，从同一桌面应用还能照用 Claude Code，比「打开命令行」更贴合现有工作流。→ 详细

• 第一步——接数据源：她给 Cowork 接一个文件夹，里面是 UXR（User Experience Research，用户体验研究）团队做过的用户访谈记录。她诚实声明：演示里这些「不是真实用户访谈，是我让 Claude 生成的（拟真访谈）」，但请当成真实 UXR 访谈记录看。→ 详细
• 第二步——下指令汇集：指令原话大意——「看这个 UXR 访谈文件夹，再去社交媒体比如 X 和 Reddit、还有其他关于 Cowork 的评价里，告诉我主要的洞察是什么。」她预告这会花点时间，因为它「真的是在过一大堆数据、处理这些数据（going through so much data and processing it）」。→ 详细
• 执行机制（技术亮点）：Jenny 解释 Claude 有时会「派生出子 agent（spin off subagents）去并行处理」——subagent 就是主任务临时分出去的小助手，多个同时干活、最后汇总，比串着做快得多；它也会「上网搜索一阵子（search the web for a while）」。最终把结果做成一个 docx 文档，自动「存到我电脑上的一个文件夹里」。演示中这一跑直接产出 7 个不同的主题（themes），Jenny 特别点出「它们每周都不一样，这点很棒」——意味着这套流程能持续捕捉新鲜、动态变化的洞察，而不是每次给同样的陈词滥调。→ 详细

• Cowork 团队刻意「保持非常贴近一线（staying super close to the ground）」，反馈来自三类渠道并行：① 传统渠道——UXR 研究、直接跟人聊；② 内部试用（dogfooding，自己吃自家狗粮）——靠一个「一直在跑的 Slack 反馈频道」；③ 社交媒体上充满热情的用户。回答「有没有每周洞察报告」时，Jenny 确认真实工作里确实有（一位研究员发一份，另有一份「会在 Slack 里发提醒推送出来」），但抛出反直觉结论——「我们很依赖内部反馈，这可能有点反直觉」：内部人「特别愿意对你说实话」、「往往把能力边界推得最远（pushing the capabilities furthest）」、跟进最容易。她进一步区分内外是「两种完全不同高度的反馈（a very different altitude of feedback）」：内部人抠「交互设计、打磨细节（interaction design and polish）」，外部人更多反馈「这东西对他们的用户流程管不管用」。她强调这套 dogfooding 也是 Claude Code 成功的一大原因——「就是去倾听你的一线用户」，也是她在 Figma 时就常做的事。→ 详细 → 详细

• 拿到那份洞察文档后，Jenny 演示同时派生两个并行任务，这是「并行多会话」工作法的具体落地。→ 详细
• 线程 A（变功能清单）：指令是「这些洞察很棒，但我到底应该从这些里头做出哪些产品功能？」——它会「反推（backing）」，真正给出 P0 / P1 优先级（P0 = 最高优先级、必做项，P1 = 次高优先级）。这一步把零散洞察自动翻译成可执行的功能待办。→ 详细
• 线程 B（变演示文稿）：指令是「根据那份洞察文档，把它变成一份演示文稿，让我这周在启动会（kickoff）上分享给团队」。它做成一个 artifact（Claude 直接生成的可交付成品），可以「导进 Keynote 之类的工具里」。Jenny 诚实点出：演示里她「没让它用 Anthropic 的配色风格，所以看起来比较通用（generic）」，但可以让它套品牌风格。→ 详细
• 她对这套并行流的本质解读是「基本上就是开启设计流程（start the design process）」：一个线程做 artifact、另一个「真正去琢磨下一步该做什么」。从这里她可以让 Claude 进一步为指定功能「画一些线框图（wireframes）」——「是个很好的起点，因为它直接给我展示一大堆不同的选项」——然后「把这些带到 Figma 去真正充实，或者带到 Claude Code 里、用我们真正的设计系统组件（real design system components）做成真实的东西」。她还夸了一句：她很喜欢 Claude「会问我一些澄清性的问题（clarifying questions）」，而不是闷头猜。→ 详细

• 关键使用纪律：Jenny 说她其实不会在任务正跑的时候就去设定时——「我不想在它正干活的时候打断它（I don't want to disrupt while it's doing this thing）」；她会等任务跑完之后再说「好，帮我把这个定个时」。→ 详细
• 她会把任务排成「每周一早上十点左右（every Monday morning at 10:00 a.m.）做一次」。效果对应开场金句：「这样一来，我每周一早上十点开场时就有这份演示文稿，外加三个不同的产品点子（three different product ideas）可以用，用它们来开启这一周。」它的价值，用 Jenny 原话是把「从反馈到真正做出一个看得见摸得着的东西、或者一个团队能看的点子」之间的迭代循环「压得非常紧凑（squishes that time to be really tight）」。Peter 与她一唱一和反复强调「关键全在于迭代（It's all about the iteration）」。→ 详细
• 再加一层自动分发：回答「能不能不只给自己看、还分享给团队」时，Jenny 说可以「用我的 Slack MCP 来配置，让它直接把内容发出去」，比如「每周把内容发到某个特定的频道」。MCP（Model Context Protocol）是让 Claude 接入外部工具/服务的标准接口，Slack MCP 就是让 Claude 直接往 Slack 发消息的连接器。她也顺带又夸了一次它会主动问澄清性问题。→ 详细

• 选定方向后，Jenny 的指令很具体：「我喜欢这个分步进度（step-by-step progress）/任务进度的 UI 的点子，给我做一个交互式原型，做几个不同的选项，用那种潦草的线框图风格（scratchy wireframe style）来做。」wireframe（线框图）指只画框架结构、不上精细视觉的草图；「scratchy（潦草）」是刻意别做太精致，方便快速比选。→ 详细
• 关于上下文与品牌：Peter 问它有没有「Cowork 现在长什么样」的上下文，Jenny 说这个会话大概没有，「因为我没给它设置那个」；但它「会根据这里的上下文尽它所能去做，而且它也相当独立（pretty isolated）」，所以不一定非得喂它「Cowork 长什么样」。想更贴主题，可以「传一张图给它」，或挂上团队那个「Anthropic 品牌 skill」让风格更符合调性。→ 详细
• 这一步背后是 Jenny 鲜明的设计偏好：「我作为一个设计师，就是喜欢一次看到很多个方案，哪怕它们的精细度没那么高」——亲眼看到比「只在脑子里想象它们」更能帮她决定做什么，还省掉了自己动手画草模（mock them up）那一步。她明确说下一步：「从这些方向里挑一个，然后开始对它做细微的迭代（micro iterate），甚至把它拿过来、用代码做成一个原型，再从那里继续迭代。」→ 详细

• Anthropic 有「几个内部 skill」专门给文档、幻灯片「打上品牌烙印（brand them）」（skill 指可复用的预设能力包/指令模板）。Jenny 坦言她个人没有自建 skill 库，基本都是「借用内部已有的那些，用在不同用途上」。作为对照，Peter 分享自己有一个写作 skill，专门叫 AI「别去用那些 AI 味儿的废话词（AI slop）」——slop 直译「泔水」，这里指 AI 那种空洞、套路化的文风。→ 详细
• Jenny 抛出一个她自认「未必是最佳实践、也不是最高效」却很有启发的做法：靠 Cowork 加上她那些「放满个人笔记之类东西的文件夹」，让 Claude「从这些文件夹里去了解我」。这些笔记包括「一对一谈话里记的，还有随手冒出的想法」。效果是——她「已经有了这么一个关于我的知识库」，反而「觉得没那么需要 memory 和 skill 这些东西了」。Peter 猜「是不是因为它每天都会更新自己的 memory」，Jenny 给了更精准的说法：那「基本上相当于是一份由我自己来维护的 memory（a memory that I maintain of it），因为我一直在里面记笔记」——她用一个人工持续维护的笔记文件夹，手动扮演了「记忆」的角色。她仍认为 skill 有适用场景，只是「就我自己遇到的这些用例来说，需求没那么强了」。→ 详细 → 详细

• Peter 自嘲「我也变得特别懒了」：他现在「总是让 AI 先给所有事情打个初稿，然后我就负责对它做出反应（let AI take a first cut at everything and I just react to it）」；反过来让他「从零开始起草某种功能优先级的东西」，花的时间反而「比以前长得多」。这点出一个真实的能力迁移——人的工作正从「从零生产」转向「评判与反应」。→ 详细
• Jenny 用一个非常贴近本期录制的例子佐证：连这期播客她都用了这套方法——她保留一个文件夹装着「所有的个人笔记」（一对一记录、随手想法），Peter 把播客笔记发给她后，她直接对 Claude 说「读一下我的个人笔记，给这次播客想几个发言要点，帮我想想我在这里想说什么」。她澄清「我不会逐字逐句地照着念」，但它帮她「把脑子里的东西激活了（jog my mind）」、「发展了我的思路（develop my thinking）」，解决了那个经典的「对着空白页干瞪眼、卡在那儿（the blank page problem）」的难题。→ 详细
• 但她划出清晰的红线——人不会全权交给 Claude：「我们还是不会直接把它全权交给 Claude 去做所有事情……很大程度上还是要靠我们自己的判断力，以及我们去甄别、决定到底该构建和做什么的能力（our ability to curate and decide what to actually build）。」Peter 补一条务实分工：可以「把一半的任务交给 Claude 去做、让它提个 PR（Pull Request，代码合并请求），然后那些更复杂的，你可以试着手把手带着它做（hand hold it）」。→ 详细

• Peter 给出一个反「玄学」的观点：与其在网上空谈「品味（taste）、判断力（judgment）」，不如去承受那股从内外涌来的「产品反馈洪流（fire hose of product feedback）」——fire hose（消防水龙带）比喻反馈量大到像高压水枪喷你一脸；整天泡在里面「你慢慢就会培养出一种感觉：什么是坏的、什么需要被修」，Jenny 连声认同。关于团队怎么协作、交接点在哪：Jenny 说「至少我们团队是相当自下而上、相当民主（bottoms up and democratic）的」——「把洞察和目标交给大家，然后每个人各自去做原型、试东西，点子可以从任何人那里冒出来（ideas come from everywhere）」；不像是「我作为设计师要想出所有点子」，而是「这件事任何人都能做，不一定非得是设计师」。一个常被误解的细节：真实 UXR 用户访谈通常不是 Jenny 亲自做的——「要么是团队里的 PM 或研究员，要么是其他人」，她的角色更多是拿到 artifact 后「直接分享出去、把他们拉进来」，而这个 artifact「其实可以变成整个团队据以运转的那个东西」。→ 详细 → 详细

• Jenny 澄清「10 天做出来」是从别人某次访谈或媒体宣传（press tour）里的某句话被单独拎出来、「大家就都咬住这一点（anchored onto it）」。真实故事：Cowork 这个方向公司酝酿了近一年——「基本上从我大约一年前加入 Anthropic 起就是这样了」。初衷是为「所有的通用知识工作者（all general knowledge workers）」做一个「思考伙伴（thinking partner）」（写代码这块已基本有了 Claude Code）；纠结的核心难题是三个：「怎么落地？正确的架构（architecture）是什么？正确的 UX 是什么？」去年做过「很多不同原型」，围绕不同的 agent harness（智能体框架/运行骨架，即驱动 AI 自主干活的底层引擎+脚手架）做大量实验，「有几个最后没成」，原型「既来自 labs 部门（偏研究），也来自 product 侧（偏落地）」。她总结一条判断法则：「如果一个点子反复回来、而且每次都还有那股劲（energy each time），那剩下的就是执行了」，成败「往往就是时机和执行——就像闪电恰好劈得特别准那种感觉」。→ 详细
• 转折点是假期（the holiday break）：「大家终于有时间去试 Claude Code 了」，之前心态是「市面上这么多 AI 工具，我哪有时间试」，假期里「不知怎么大家都去试了」。更关键的是「很多带着非技术用例的人也试了」——有人「用它解析播客转录稿（parse podcast transcripts）」，有人「做各种复杂分析」。团队看到「连 Claude Code 这套 agent harness 在非技术人群里都已经有了早期 PMF（Product-Market Fit，产品市场契合）的苗头」，判断「就是这个时刻，我们必须抓住它（This is the moment. We need to meet it）」，哪怕「还没有完美产品」也要先放出去，于是有了「那极其忙乱的 10 天（hectic 10 days）」。一个反直觉副作用：时机压力「反而逼着我们把范围圈定得更现实一点」，并真正「投入精力、投入人手」。Peter 提炼一句：「research preview（研究预览）就像是新时代的 beta」——早期半成品发出去「能学得快太多了」。→ 详细

• 第一代（工作流式 / task-oriented）：Jenny 和另一位设计师合作的版本。当时他们「特别担心」用户不理解「用 Cowork 可以去做某些成果，比如做一个仪表盘（dashboard）、从一大堆不同地方汇集来源」，所以把界面「做得结构化多了，几乎像你做一个工作流工具（workflow tool）那样：把输入加进来、那些是输出」，聊天放次要。失败两条：一是「以当时的技术，Claude 还不太擅长严格照着工作流走」；二是「太结构化了」，得一项项填完、感觉不对劲。Peter 补刀「感觉太费劲了（too much work）」，Jenny 那句很有时代感的吐槽——「都 2025 年这个时代了，我们干嘛非得这么做？明明可以直接让 Claude 帮我们做个什么就好了」。→ 详细
• 第二代（聊天框 + 旋钮调参 / dials）：他们决定「那就做成一个聊天框吧」，但仍试图「引导用户走向更具体的成果，比如分析报告或文档」。做法是每个选项点进去几乎都带不同的「旋钮（dials）」，调「文档长度」「文档类型，比如备忘录（memo）、演示文稿」。结果同样翻车——「那同样让人感觉特别不知所措（really overwhelming）」。→ 详细
• 第三代（几周/几个月前真正发布的版本，向导式 / wizard-like）：这版「又有了一种几乎像『向导』一样的体验，你一步步点过去，它会说『创建一个文档，把它做成三到五页，等等』」，而且「把一大堆界面元素一上来就全摆出来了」，因为想跟聊天有强区分度（differentiated from chat）。问题是「这里有一大堆互相争夺注意力的视觉元素（competing visual elements）」。所以团队「随时间把这里大部分东西都精简掉了」，并「放弃了这种特别『有主见』的界面（really opinionated UI）」——「把所有这些都展示出来其实并没有帮助」。→ 详细
• 当前 UI（核心创新：Claude 的待办清单）：现在界面「很多东西都被剥得很简洁了」——「不再展示那些很重的侧边栏（heavy sidebars）」，「更像传统的那种聊天框」。但首页被重新设计成「感觉更像是 Claude 的一份待办清单（Claude's active to-do list）」：能看到「进行中的任务」（演示里 1 个，但真实工作里「我给了 Claude 一堆任务、过一阵再回来」时会有一堆条目提示「有一条新消息」或「这个我可以审一下」）、「已排程的任务」，并可「直接审批、分流（approve and triage）」（triage 是医疗「分诊」借喻，快速判断先处理哪个）。核心理念一句点透：让它「感觉更像是你和 Claude 之间共享的一份待办清单（a shared to-do list between you and Claude），而不是一个塞满一堆让人不知所措的建议、还有各种界面来教你怎么用的聊天框」。Peter 顺势畅想未来：「也许将来你有多个 agent，它们可以摆成一个 Trello 看板那样，任务拖来拖去」（Jenny 回「也许吧」）。→ 详细

• 贯穿上述所有探索的大问题，Jenny 概括得极清楚：「我们一直在努力平衡的一个大问题就是——我们对这些用例到底要规定得多死（how prescriptive of the use cases are we），还是说像聊天框那样保持完全自由的形式（free form like a chat box）。」prescriptive（规定性强）= 手把手告诉你每步该干嘛、限制多；free-form = 给你一个空对话框、想干嘛干嘛。工作流式（太规定、太费劲）、旋钮式（太 overwhelming）、向导式（视觉元素打架）三次失败，本质都是「规定」那一端用力过猛。她强调团队在同时学两件事：「一直在学什么有用、什么没用」，以及「同时也在不断摸索怎样把这项技术更好地呈现给用户（how to display this technology to people）」——模型本身强还不够，还得有对的「呈现方式」；UI「跟大概四五周前比已经长得太不一样了」。关于折中点：Peter 点出 Claude Code「对新手不友好……像一个游戏，得不断学才能精通」；Jenny 给 Cowork 的定位——它「同样是一个面向专业人士（for professionals）的工具」，已有一批 power user，理念是「很多人会有动力去学复杂得多的能力（创建自己的 skill、分享给团队、想要简写命令），但所有这些事，应该都能在不用去经历那番学习的情况下也做得到」；Cowork「仍可以用 slash command（斜杠命令）」，但那是「一种次要方式」，「你不应该非得知道所有命令才能用它」。→ 详细 → 详细 → 详细

• Jenny 先给总印象：规划方式「每次都不一样」、整体相当「松散（loose）」。月度规划的具体机制（数字关键）：她所在团队「按月做规划」，「就用一个表格」；至少在 Cowork 这块，「那个清单里最多也就 12 项左右，而且真的全是我们的 P0」（没有 P1 凑数）；「每一项都只配一个 DRI」——DRI（Directly Responsible Individual，唯一直接负责人）是硅谷常见做法，确保每件事都有一个明确担责的人；然后「每周回来看一下，看进度有没有掉队（are we on track or not）」。也会做「一些季度或半年度的规划」：通常「会有某位 lead 出来说『我觉得大方向大概往这边走』」，但「它没那么死板」，更像「给所有人一张图，让大家看到事情大概怎么拼在一起（a picture of how things might fit）」。Peter 提炼一个犀利观察：「Anthropic 是最具创新力的公司之一，但在最具创新力的公司里，重点反而不在搞『年度规划的形式主义（annual planning theater）』，而更多是快速迭代、从用户身上学习」（planning theater = 走流程、做样子但不解决实际问题的规划仪式）。→ 详细 → 详细

• Jenny 确认愿景仍有价值：她「去年大概也做过一份北极星愿景的 deck（North Star vision deck）」，认为它「能给大家指明一个方向，让我们对要做的事有清晰认知（create clarity）」。但 AI 时代彻底改写了愿景的「保质期」：在「技术时时刻刻在变，新模型层出不穷、出来的速度越来越快」的环境里，她断言「根本不存在所谓的『一年期愿景』，更别说两年、五年的，因为太多东西未知」；她现在理解的愿景「更多是三个月、最多六个月的尺度」。形式上也变了：愿景「可以是一份文档，但做成可视化的会更有用，甚至可以是一个原型（prototype），不一定非得是那种静态的 deck」。她由此点出设计在「谁都能造任何东西（anyone can build anything）」的当下为何仍有巨大力量：现实中「我们经常会有五个团队在做某件很类似的事，或者做的东西会撞车（collide）、感觉重复（duplicative）」，而 design 真正能做的，是去「策划、把这些想法整合出连贯性（curate and bring cohesion），指出一条把它做成『理想体验』（ideal experience）的路，而不是变成五个各自为政的版本（five disparate ones）」——设计的价值从「画图」转向「在混乱中收敛出一个连贯故事」。→ 详细

• Jenny 确认「我们还是有评审的」，但与某些公司不同——「我待过那种每一个功能都要评审的公司」，而 Anthropic 的评审只「针对那些比较大、优先级比较高的项目（bigger, higher priority projects）」。评审性质很轻：「它感觉不像是一件你得花大力气准备、花很多时间去搞的大事」，主要目的是两个——「为了让大家看见进展（visibility）」和「为了拿到反馈（feedback）」；只有当「有些事情跨度大、对全公司有重大影响（big company-wide implications）」时才做那种评审。→ 详细

• 面对「觉得脚下的地在松动的设计师该怎么办」，Jenny 给出全篇最金那句：「如果你感觉脚下的地面在移动，那是因为它确实在动（it's because it is）。」这个阶段「你只能去接受它、适应它，并且非常开放地去质疑我们已有的工作方式」。她解释设计师为何此刻感受尤其强烈：「这波冲击现在正冲着设计师来，而我们感受特别强烈，是因为周围很多岗位已经先变过了，我们是受它影响的『第二波』（the second tier effect）」——工程等岗位先被 AI 改造，连带改了设计师的协作方式；「但我们用的工具本身也在变」。难得的是她坦诚自己也会动摇：「有时候我会觉得受到威胁，心想『我的工作变化好大，大家不再像以前那样看重我了』。」破局方法是把工程师同事当范本和激励：「我会想起我那些做工程的同事，他们的工作已经变了多少，又是多么英勇地（valiantly）扛了过来，今天他们产出的东西更好、更多」；「如果这些我特别尊重的人都能做到，而且是以那么谦逊的姿态（humility）做到，那我也能。」→ 详细

• Peter 先给乐观的一面：AI 让人「摆脱了很多枯燥的杂活、那种搬来搬去挪框框的活儿（moving boxes around）」（对设计师「挪框框」就是机械调整图层位置的体力活），人就「能真正去专注更高层次的思考」。Jenny 补另一面：「或者说你也在产出更多的东西」，举工程师为例（呼应开场金句）：「我那些工程师现在能做到的事有多厉害……那太疯狂了（wild）。他们现在是用几天、而不是几周就造出一整个功能（creating entire features in days, not weeks）。」由此点出收尾悖论——Peter：「有意思的是，你其实并没有得到更多空闲时间，你反而工作得更拼了（you don't actually get more free time. You actually work harder）。」Jenny 给出心理解释：「那是因为我们都特别有野心，而且这就像一种快感（it's a high）。你会想『我现在能搞定这么多事，那些我以前不喜欢做的活儿也不用做了』，那我就多做一点呗（let me do more）。」——AI 没有把省下的时间还给人，而是被「更高的野心 + 干活的快感」立刻填满。→ 详细

本期无独立的闪电问答（lightning round）环节。收尾以「给设计师的建议」+「AI 时代工作悖论」两段对话作结（已并入主题段落第 19、20 节），核心金句如下：

• 「如果你感觉脚下的地面在移动，那是因为它真的在移动（if you feel that the ground is shifting beneath your feet, it's because it is）。」——接受它、适应它、敢于质疑既有工作方式；并把已先被 AI 改造的工程师同事当作范本与激励。→ 详细
• 「他们现在用几天、而不是几周就造出一整个功能（creating entire features in days, not weeks）。」——这股产能飞跃既来自摆脱杂活，也来自人主动选择「产出更多」。→ 详细
• 「garbage in, treasure out（垃圾进、珍宝出）」——Jenny 对 Cowork 价值的一句话概括：把一堆杂乱来源汇成精华产出。→ 详细
• AI 没带来更多空闲，反而让人更拼：「我现在能搞定这么多事，还不用做以前不喜欢的活，那我就多做一点呗。」→ 详细
• Peter 收尾感谢 Jenny，称两人「在线上聊了挺久，今天终于能当面聊上了」，还打趣「这让我的工作更有意思了」；Jenny 回「能有这次对话真的很棒（It's been great to have this conversation）」。→ 详细