“垃圾进，珍宝出”：Anthropic 首席设计师谈 Cowork 的产品哲学与 10 天上线的真相

整理 & 编译：深潮TechFlow

嘉宾：Jenny Wen，Cowork 设计负责人

主持人：Peter Yang

播客源：Peter Yang

原标题：Claude Cowork Tutorial from Cowork s Design Lead (40 Min) | Jenny Wen

播出日期：2026年3月29日

要点总结

Jenny 是 Cowork 的设计负责人。她带我深入了解了 Anthropic 的内部运作，包括她如何使用 Cowork 设计和开发产品，以及 Cowork 诞生背后的真实故事。Anthropic 几乎每天都在推出新功能，看到他们的工作方式让我感到非常震撼。

精彩观点摘要

关于日常工作方式

• 我花时间做的大部分事情，就是把产品推出去。不过我觉得这可能和一两年前看起来不太一样了，其中很大一部分，其实就是和工程师、产品人员之类的以一种不太正式的方式一起 jam （即兴协作）。通常是大家一起看一个原型，然后指出并思考它可以如何演进。

关于”垃圾进、珍宝出”的使用哲学

• 我觉得 Cowork 最让我感到惊艳的一点，就是它在信息整理上的能力。我喜欢把它称为“垃圾进、珍宝出”。它能够从各种不同的来源中收集信息，然后快速找到其中的关键点，提炼出有价值的内容，并将其转化为具有实际生产力的成果。

关于 Cowork 与 Claude Code 的区别

• 除了非常细致的生产代码工作 (production code) 之外，我现在几乎所有的事情都用 Cowork 来完成。如果是需要专注于某些代码细节的场景，我还是会用 Claude Code。但对于日常的沟通和协作，我现在完全依赖 Cowork。

关于 Cowork 的诞生故事

• 那句“他们 10 天就做出来了”的说法，其实是从某次访谈或媒体报道中被截取出来的。但真实的情况是，关于 Cowork 这个方向，我们其实从我一年前加入 Anthropic 时就已经开始构思了，我们一直在思考如何打造一种能够帮助所有通用知识工作者的“思维伙伴” (thinking partner)。
• 虽然 Claude Code 已经能够很好地处理代码相关的任务，但我们的目标是覆盖所有知识工作场景。我觉得真正的挑战在于：我们该如何执行这个想法？什么样的架构是最合适的？什么样的用户体验 (UX) 才是正确的？

关于设计流程的演变

• 我还是会做 Figma。但我们现在不经常做规格文档了，而且通常也没那么详细。我们依然会做优先级排序，它还是作为一个文档存在，但通常就只是几个 bullet points，不是那种过度设计的漂亮表格。

关于规划与愿景

• 我们所处的技术领域变化极快，新的模型不断涌现，更新速度也越来越快。因此，对于我们来说，制定一年的愿景都不太现实，更不用说两到五年的愿景了，因为存在太多未知因素。

关于设计师的未来

• 如果你觉得脚下的地面在移动，那是因为它确实在变化。我们必须承认这一点，并学会适应，同时也要以开放的心态重新审视我们现有的工作方式。
• 每当我感到自己的职业受到挑战时，但这种时候，我会想到我的工程师同事们。他们的工作早就经历了巨大的变革，但他们不仅适应了这些变化，还以极大的勇气和谦逊迎接挑战，最终实现了更高效、更出色的工作成果。他们是我的灵感来源——我会告诉自己，如果这些我非常尊重的同事可以做到，我也一定可以。他们是我适应变化的榜样。

开场

Peter Yang：大家好，今天我非常兴奋地欢迎 Anthropic 的设计负责人 Jenny。Jenny 将向我们展示她如何使用 Claude Cowork 和 Claude Code 来设计和发布产品，同时给我们分享 Cowork 的内部故事，或许还会聊聊她产品的下一步发展。

Jenny，你工作中典型的一天是什么样的？哪些任务会占用你大部分时间？

Jenny：

我不知道是不是有典型的典型一天，但我花时间做的大部分事情，就是把产品推出去。不过我觉得这可能和一两年前看起来不太一样了，其中很大一部分，其实就是和工程师、产品人员之类的以一种不太正式的方式一起 jam （即兴协作）。通常是大家一起看一个原型，然后指出并思考它可以如何演进。有时候只是讨论功能的表现，有时候是我自己去实现一些东西。我觉得仍然有很大一部分时间是我自己在设计、做原型之类的，但现在设计工作的方式感觉很松散。

Peter Yang：基本上你会通过 Claude 之类的生成一堆原型，然后就和工程师一起 jam，给一些反馈，然后用提示词让 AI 去改进它，对吗？

Jenny：

其实它们往往甚至不是原型，而是已经在我们内部构建和 Claude 或 Cowork 实例中运行的工作原型。我通常会花时间使用这个功能、推动这个功能、看看它的能力、形成意见，而下一步迭代通常就是我坐下来和工程师说： 嘿，我是这么想的。这些是我觉得应该改的地方。 我觉得还是有时间让我觉得在设计工具里迭代、打磨和精炼仍然非常非常重要。所以那部分并没有消失。只是因为我同时在处理更多项目，所以感觉更有效的方式就是非常随意、非常非正式地去做。

Peter Yang：我觉得那一直是我作为产品经理或设计师最享受的部分，就是把设计师和工程师拉到一起，看着产品一起迭代。所以你们现在不太做那种规格文档、Figma 文件之类的规划文档了吗？还是说就直接在代码里迭代原型？

Jenny：

我还是会做 Figma。但我们现在不经常做规格文档了，而且通常也没那么详细。是的。我们依然会做优先级排序，它还是作为一个文档存在。其实这对我们交给安全或法务团队很有帮助，这样他们能了解发布内容是什么，但通常就只是几个 bullet points。不是那种过度设计的漂亮表格。我觉得我们的 Figma 文件也是一样。

Cowork 实操演示

Peter Yang：你能不能给我们展示一下你如何使用这些产品，或者每个产品你分别用来做什么？

Jenny：

当然可以。我来讲讲我是如何使用 Cowork 的。其实我有一个小秘密，除了非常细致的生产代码工作 (production code) 之外，我现在几乎所有的事情都用 Cowork 来完成。如果是需要专注于某些代码细节的场景，我还是会用 Claude Code。但对于日常的沟通和协作，我现在完全依赖 Cowork。

我觉得 Cowork 最让我感到惊艳的一点，就是它在信息整理上的能力。我喜欢把它称为“垃圾进、珍宝出”。它能够从各种不同的来源中收集信息，然后快速找到其中的关键点，提炼出有价值的内容，并将其转化为具有实际生产力的成果。

举个例子，现在我连接了一个文件夹，里面存放着一些用户访谈记录。我们 Cowork 团队非常注重与用户的紧密联系，这也是我们取得一定成功的关键之一。我们通过传统的用户体验研究 (UXR)，直接与用户对话，同时也通过内部自用的方式，比如我们有一个专门用来收集反馈的 Slack 频道。此外，我们还会关注社交媒体上的讨论，并倾听那些热情用户的意见。正是因为我们始终保持与用户的紧密联系，并且能够快速迭代产品，我们才能不断改进并取得今天的成果。

所以我现在要做的就是，我会告诉 Claude：嘿，我有这个访谈文件夹，但我也会让 Claude 去社交媒体、Reddit 和其他 Cowork 的客户评价里看看，告诉我最大的洞见是什么。它可能需要一点时间，因为它真的要处理这么多数据并进行加工。但它会做一些事情，比如有时会派生出子代理并行处理，还会花时间在网上搜索。

Peter Yang：在你的实际工作中，你们有那种每周洞见报告之类的吗？就是自动汇总所有内容然后发给你和团队的？

Jenny：

其实我们现在就可以通过 Cowork 直接做出来，我觉得我们的研究人员有一个会发出来的，我们还有一个会在 Slack 里 ping 我们的版本。我们也会直接听内部 Slack 频道，我们非常依赖内部和最强大的用户来给我们提供那种前沿反馈，因为内部人员真的愿意对你诚实，他们往往会把功能推到最远，而且也最容易跟进。

Peter Yang：我觉得这才是应该发生的，而且我感觉大多数公司里团队之间都太割裂了，但 Anthropic 感觉完全不是这样。

Jenny：

我觉得这也是 Claude Code 成功的重要部分——就是倾听一线用户。而且这也是我们在 Figma 时大量做的事情，大量内部 dogfooding。因为尤其是涉及到交互设计和打磨这些方面时，内部人员真的会去戳那些细节，而外部用户往往给的反馈更多是 它是否适合他们的用户流程 ，所以它能提供一种完全不同层级的反馈。

Cowork vs Claude Code 的用户边界

Peter Yang：我知道 Anthropic 的营销、产品经理现在基本上都在用 Claude Code 做事，尤其是在 Cowork 内部可用之后。你怎么看待不同类型的使用场景？或者大家是怎么用 Cowork 和 Claude Code 的？

Jenny：

我们注意到，Cowork 的整体应用范围正在逐步扩大，并且开始被用于一些类似于之前 Claude Code 的前沿用户所尝试的场景中。还记得我们刚开始开发 Cowork 的时候，内部销售团队是我们主要的信息来源。他们当中有几位是 Claude Code 的深度用户，利用它生成潜在客户名单、编写电话脚本等。当我第一次看到这些用例时，感到非常吃惊，因为当时我甚至没有想到 Claude Code 能够被用来完成这些任务。而现在，这些用户几乎已经全面转向了 Cowork，甚至连他们的同事也开始频繁使用 Cowork 了。

就是因为现在有一个好看的 UI，所以我认为这就是它真正需要的。而且还有一部分原因是，它和他们正在做的其他工作离得非常近——他们本来就在用聊天功能，而且从这个桌面应用里也能继续用 Claude Code，所以我觉得它比打开命令行更贴合他们现有的工作流。

从洞见到可执行 Artifact 的完整流程

Jenny：

这里有七个不同的主题，而且每个星期都不一样，我基本上可以直接告诉它： 帮我创建这个文档 X ，而且已经自动存在我电脑上的一个文件夹里。我还可以同时启动两个并行任务。比如我可以说：这些洞见很棒，但根据这些我应该实际构建哪些产品功能？ 然后我还可以并行做另一件事——根据你刚才帮我做的洞见文档，把这些内容转成一份我这周 kickoff 时可以跟团队分享的演示文稿。

但最终我从这里就可以开始设计流程了——它会给我各种功能选项。从那里我甚至可以让 Claude 帮我为这些功能创建一些 wireframe。它可能会给我一大堆不同的选项，我可以把它们带到 Figma 里真正去细化，或者带到 Claude Code 里，用我们真正的设计系统组件把它们做成真实的东西，然后从那里开始。

另外我还能做的是，把这两个都变成定时任务。所以我大概会让它帮我把这个任务安排成每个周一早上 10 点自动执行。这样我每周一早上 10 点就会带着这份演示文稿、带着三四个不同的产品想法开始工作，用来 kick off 这一周。它把从反馈到做出 tangible 东西或团队能看的 idea 这个迭代周期压缩得非常紧，帮助我们快速迭代产品，并且快速把它做得更好。

Peter Yang：一切都是关于迭代，一切都是关于迭代。我现在也变懒了，我总是让 AI 先做第一版，然后我再去反应。

Jenny：

是的。所以如果你真的想让我从零开始把这些洞见整理成某种功能优先级，它现在花的时间会比以前长很多。

我也是这么操作的。比如你发给我的这个播客笔记，我有一个个人笔记文件夹，里面有 1:1 会议的内容、随机的想法之类的，然后我就直接说： 读一下我的个人笔记，帮我想一下这个播客的发言要点，并帮我想想在这里我想说什么。 我当然不会一字不差地照着念，但它真的帮我打开了思路，帮助我进化了我的思考，而不是卡在那里。

Skills 与个人知识库

Peter Yang：你会用哪些 skills？或者你有没有个人专用的 skills 来做这些文档和幻灯片？

Jenny：

我们内部有几个 skill 专门用来做文档和幻灯片，因为它能帮我们保持品牌一致性。我其实没有个人 skill 库，大部分时候都是借用内部已有的 skill，然后用在不同用途上。

Peter Yang：比如我有一个 writing skill，它会告诉 AI 不要用那些 AI slop 词汇。

Jenny：

但其实我发现，现在用 Cowork 的文件夹——我里面放了所有个人笔记之类的——它通过这些文件夹了解我的方式，但对我来说已经非常有用了。我反而觉得越来越不需要 memory 和 skills 了，因为它已经有一个关于我的知识库了。当然我还是认为 skills 有它的适用场景，但就我目前的用例来说，我个人感觉需求没那么大了。

Peter Yang：是因为它每天根据你的对话自动更新记忆吗？

Jenny：

是的，它基本上就是我自己维护的一个 memory，因为我一直在里面记笔记。

团队协作节点

Peter Yang：所以你在整个流程中什么时候把团队拉进来？或者说你和 AI 迭代，然后再和团队迭代来回切换，还是怎么做的？

Jenny：

我的意思是，像真正的 UXR 访谈这些东西，其实是我不会自己做的——要么是产品经理，要么是团队里的研究员，或者团队里的其他人会去做。然后通过这个，你就直接分享 artifact，把他们拉进来，然后这个实际上就能成为团队运作的依据。

我们团队至少是相当 bottom-up 而且很民主的，所以我们的运作方式就是，我们把洞见和目标给大家，然后每个人就去做出原型、尝试东西，想法来自四面八方。它不是作为设计师我来想出所有方案，而是 “嘿，这里有洞见。这是我们这个月要努力达成的目标，我们大家怎么一起达到？ ”

我觉得有了这个，我们还是不会直接把所有东西都交给 Claude 去做。我们还是依赖我们自己来做很多判断，以及我们去管理和决定真正要构建和做什么的能力。

Peter Yang：人们在网上谈论品味和判断力时，我觉得这些能力的培养方法，其实就是通过从内部和外部持续获取大量的产品反馈。在这个过程中，你会逐渐形成一种直觉，能够察觉到哪些地方出了问题、需要修复。因为你每天都在倾听和处理这些反馈，久而久之，你就会对问题有一种敏锐的判断力。

Jenny：

至于设计，Claude 的一个功能是，它能够生成类似线框图 (wireframe) 的草图，并给出多种设计选项。作为设计师，我非常喜欢这种方式。即使这些草图的精细度不是很高，但它们能让我直观地看到不同的可能性，而不必完全依赖自己的想象力。这种方式能帮助我更快地决定接下来的设计方向。

所以，我认为让 Claude 来直接生成这些初步的选项，可以省去我手动制作草图的时间和精力。从这些选项中，我会选择一个方向，开始进行小范围的迭代。接下来，我可能会用代码将这个方向制作成一个初步的原型，然后在这个基础上继续优化和完善设计。

Cowork 诞生的真实故事

Peter Yang：我们来聊聊 Cowork 是怎么诞生的吧。外面有很多关于它 10 天就做出来的故事，但其实在那之前已经有很多迭代了吧？

Jenny：

那句“他们 10 天就做出来了”的说法，其实是从某次访谈或媒体报道中被截取出来的，大家就一直围绕这个点讨论。但真实的情况是，关于 Cowork 这个方向，我们其实从我一年前加入 Anthropic 时就已经开始构思了，我们一直在思考如何打造一种能够帮助所有通用知识工作者的“思维伙伴” (thinking partner)。虽然 Claude Code 已经能够很好地处理代码相关的任务，但我们的目标是覆盖所有知识工作场景。我觉得真正的挑战在于：我们该如何执行这个想法？什么样的架构是最合适的？什么样的用户体验 (UX) 才是正确的？

过去一年里，我们尝试了很多不同的原型设计，其中有些想法甚至比现在的目标更加宏大。我们也进行了许多技术实验，测试了各种 AI 智能体框架，但其中一些尝试并没有成功。最终，我们才逐步确定了现在的方向。我们不仅参考了实验室团队开发的原型，也研究了我们产品团队自己构建的原型。最终，时机和执行力成为了关键，就像闪电正好击中了目标一样。

当我们决定要发布这个产品时，整个过程非常迅速——从“我们该发布了”到“产品已经上线”，只用了 10 天。这主要是因为我们在 Claude Code 假期期间看到了它的潜力。在假期里，很多人终于有时间去试用 Claude Code，甚至一些非技术用户也开始使用它，比如用它解析播客的转录稿，或者进行复杂的数据分析等。我们发现 Claude Code 的智能体框架 在非技术用户中也开始展现出早期的产品市场契合度。其实当时我们内部已经有一个可以工作的原型，原本计划稍晚一些再发布，但这些反馈让我们意识到“现在就是最佳时机”。于是，我们决定抓住这个机会，最终有了那疯狂的 10 天。

Peter Yang：如果我没理解错的话，过去一年你们在内部的 Slack 里分享了很多原型，收集了大量反馈，最终确定了一个可行的原型。然后因为看到市场对它的需求，你们就快速完成了一次冲刺，把产品推了出来。

Jenny：

没错，大致就是这样的，我们本来计划再过几周才上线，但当时我们感到“现在就是最佳时机”。这也促使我们在时间紧迫的情况下，将产品的范围缩小到一个更现实可行的程度，并投入了全部的精力和资源，最终成功完成了发布。

早期设计迭代：从 workflow 工具到极简 Chat

Peter Yang：你能分享一些关于早期迭代的经验，或者展示一些正在开发中的内容吗？

Jenny：

当然可以。我特地整理了一些早期的屏幕截图，可以展示我们当时的设计思路和迭代过程。

今年早些时候，我们有了一个早期原型，这是我和另一位设计师合作完成的。当时，我们尝试让这个工具更偏向任务导向 (task-oriented) 或工作流导向 (workflow-oriented)。因为我们很担心用户是否能够理解，使用 Cowork 这样的产品，他们是否能够完成某些具体的任务，或者实现一些明确的成果 (outcome)，比如创建一个仪表盘 (dashboard)，或者整合来自不同来源的数据。所以，当时我们把用户界面设计得非常结构化，几乎像一个工作流工具——比如“添加这些内容，这是输入 (inputs)，这是输出 (outputs)”。而聊天功能被放到了次要的位置。

但是感觉要做很多步骤才能完成，在 2025 年这个时代，为什么我们还要这么复杂？直接让 Claude 来处理这些不就行了吗？

这是我们早期的一个设计方向，但后来我们决定改变思路，让它更简单，像一个聊天框 (chat box)。我们尝试通过这种方式引导用户实现更具体的目标，比如分析或文档生成。我们还设计了一个功能性的原型——用户点击后，可以看到各种选项，每个选项都有按钮可以调整，比如文档的长度，或者选择文档类型，比如备忘录或演示文稿，但这个设计最终让用户感觉过于复杂和压迫。

所以在多次探索和尝试中，我们一直在努力寻找一个平衡点：我们到底是应该更明确地定义使用场景，还是保持像聊天框一样的自由形式。

最终，我们几周前发布的版本就是现在的样子。我们曾经尝试过一种几乎像“向导模式” (wizard-like) 的用户体验，用户点击后会看到提示，比如“创建一个文档，长度为三到五页”等等。

当时我们还在界面中加入了很多元素，希望让它看起来与普通的聊天框有所不同。但后来发现，这种设计让界面显得过于复杂，视觉元素之间的竞争太激烈。于是，我们决定简化设计，去掉了大部分不必要的元素。

现在你看到的用户界面，已经大幅度简化了。我们移除了繁重的侧边栏 (sidebars)，让它更接近传统的聊天框，但在首页做了一些改动，使它看起来更像是一个由我和 Claude 共同分享的“待办事项清单” (to-do list)，而不是一个充满复杂建议和指导的聊天工具。

Peter Yang：也许未来它可以支持多个智能体 (agent)，可以在上面拖动任务来管理工作流。

Jenny：：

也许未来会有这样的可能性。但我想强调的是，UI 设计在大约四五周前还完全不同，我们一直在不断学习，探索什么样的设计最有效，什么样的设计不太奏效，同时努力寻找最好的方式将这项技术呈现给用户。

Cowork 与 Claude Code 的差异定位

Peter Yang：在使用 Claude Code 的过程中，我经常在推特上分享一些反馈。它内置了很多斜杠命令 (slash commands)，需要用户一点点去学习。这个体验有点像去 Costco 购物时的“寻宝” (treasure hunt)，你永远不知道会发现什么新功能。

但对于新手来说，这种方式并不算友好。它更像是一款游戏，随着使用时间的增加，你会逐渐熟悉和掌握它。我感觉 Cowork 可能是在尝试探索普通聊天工具和 Claude Code 之间的中间地带。它不会把所有功能都隐藏起来，同时又能够通过某种方式引导用户更好地使用它。

Jenny：

是的。Cowork 中依然支持使用斜杠命令 (slash commands)，但它们并不是主要的交互方式。我个人觉得，Cowork 至少是一个面向专业人士的工具。我们观察到，很多用户已经以非常高阶用户的方式在使用它，而且社区中已经涌现出一些高阶用户。这些用户通常愿意花时间学习更复杂的功能，比如自己创建技能 (skills)、与团队共享，或者使用简写命令 (shorthand commands)。

不过，我们的目标是让这些功能成为次要的交互方式，而不是强制性的学习内容。也就是说即使用户不了解所有的命令，依然可以轻松使用 Cowork。我们希望用户与 Claude 的交互是自然且直观的，而不是必须通过记住一系列命令才能完成操作。

规划流程与愿景

Peter Yang：Anthropic 的规划流程是怎样的？你们会进行年度规划和目标设定吗？还是更多地依赖原型开发和不断尝试？

Jenny：

我们的规划方式每次都有所不同。在我所在的团队，我们进行的是月度计划。我们有一个电子表格，至少在 Cowork 部分，最多列出大约 12 个任务，这些都是我们的最高优先级 (P0)。每个任务都有一个直接负责的人 (DRI)，我们每周都会检查：我们是否仍在正确的轨道上？我们也会进行一些季度或半年规划，通常由一位负责人指出：“我认为我们应该朝这个方向发展，这些是我们需要关注的事项。”但这些规划并不严格到必须执行特定项目。更多的是为团队提供一个整体的方向，所以相对比较灵活。

Peter Yang：相对灵活，是吧？有趣的是，我发现最具创新的公司往往较少进行年度规划，而是更多地通过不断迭代和从用户中学习。你在职业生涯中是否做过类似 North Star 愿景 deck 的东西？你觉得这些有用吗？

Jenny：

我确实做过，去年我做过一个 North Star 愿景 deck。我认为愿景确实有其价值，它们为团队指明方向，并帮助我们在即将开展的工作中保持清晰。不过，由于我们所处的技术领域变化极快，新的模型不断涌现，更新速度也越来越快。因此，对于我们来说，制定一年的愿景都不太现实，更不用说两到五年的愿景了，因为存在太多未知因素。

然而，愿景的真正作用在于引导大家朝着同一方向前进，特别是在每个人都可以自由构建各种项目的环境中。所以我现在认为愿景的时间跨度最多是三到六个月，并且可以以文档的形式呈现。我觉得当愿景是可视化的时候，它更具影响力。这也是设计的巨大价值所在——能够将各种元素整合在一起，在特定时间段内讲述一个连贯的故事。当然，愿景也可以是一个原型，而不仅仅是一个静态的 deck。它可以帮助我们协调团队之间的工作，尤其是在我们有五个团队在处理非常相似或可能冲突的项目时。设计可以通过策展来帮助这些想法达成一致，并为我们展示一条通向理想用户体验的路径，而不是分散的体验。

Peter Yang：那么，你们会有产品经理的评审，或者针对相关人员的评审吗？这些评审是正式的，还是他们也参与到原型设计中？

Jenny：

我们确实有评审，但不像我以前在一些公司那样，每个功能都需要评审，我们的评审主要针对那些较大且优先级较高的项目。评审的目的不是为了耗费大量时间准备，而是为了提高项目的可见性并获得反馈。如果有跨团队的、影响公司的重要项目，我们就会进行这些评审。

给设计师的建议：如何在 AI 时代找到位置

Peter Yang：那么，对于那些感到自己的职业环境正在快速变化的设计师们，你有什么建议吗？他们是否应该开始学习提交代码 (PR)？还是说设计师应该采取其他方式来适应？

Jenny：

如果你觉得脚下的地面在移动，那是因为它确实在变化。我们必须承认这一点，并学会适应，同时也要以开放的心态重新审视我们现有的工作方式。我觉得现在的变化对设计师的影响特别大，尤其是因为我们正处于这场浪潮的第二波。其他一些职业角色已经经历了类似的转型，而如今轮到我们了。与此同时，我们的设计工具也在不断进化。

每当我感到自己的职业受到挑战时，我会感到一丝不安，比如“天哪，我的工作正在发生巨大的变化，人们可能不再像以前那样看重我的工作了。”但这种时候，我会想到我的工程师同事们。他们的工作早就经历了巨大的变革，但他们不仅适应了这些变化，还以极大的勇气和谦逊迎接挑战，最终实现了更高效、更出色的工作成果。他们是我的灵感来源——我会告诉自己，如果这些我非常尊重的同事可以做到，我也一定可以。他们是我适应变化的榜样。

Peter Yang：从某种程度上来说，这些变化让设计师摆脱了很多繁琐的重复劳动，比如不用再花时间在调整各种框框上，对吧？这样你就能把更多精力投入到更高层次的思考和创造性工作中。

Jenny：

没错，或者说这些变化让我们能够完成更多的工作。比如，当我看到我的工程师同事们现在能够在短短几天内完成一个完整的功能，而以前可能需要几周时间时，我真的觉得非常震撼。所以，是的，这种变化也带来了更多的可能性。