设计 Claude Code：Anthropic 设计师的旅程

有没有想过，作为像 Claude Code 这样的划时代产品的第一位设计师，是什么感觉？

Ever wonder what it's like as the first designer working on a generational product like Claude Code?

我给经理发了私信，说我觉得这会很了不起，我想为它设计 Moon with Light。

I DM'd my manager. I was like, I think this is going to be big. I want to design Moon with Light for this.

设计这类 AI 体验需要什么？

What does it take to design these types of AI experiences?

有一种主流观点认为，设计就是掌控一切的质量和打磨。我觉得这很重要，但不必占据你所有时间。知道何时用这些工具来执行和分担，何时需要深入思考，这是一种技能，而我认为很多人在这方面做得不对。

There's a huge school of thought that design is all around owning the quality and polish of everything. I think it's really important to have that, but it doesn't have to be all of your time. Knowing when to use these tools for execution and offload and knowing when you need to go deep and do the thinky work is a skill set and I think that's one that I see people doing wrong.

Anthropic 的新产品如何改变我们对构建软件的思考方式？

How are Anthropic's new products changing the way that we think about building software?

就像说服非工程师下载 CLI 工具并让终端正常工作需要很大努力，但我们已经看到很多人做到了。我认为这是一种类似的飞跃。看待它的方式是，这是与 Claude 协作方式的整个范式转变。

In the same way that it takes a lot to convince a non-engineer to download a CLI tool and need the terminal to be working and yet we've seen a lot of people do it now. I think has a similar kind of leap. The way to look at it is it's an entire paradigm shift in how you work with Claude.

欢迎来到 Dive Club。我是 Rid，这里是设计师永不停歇学习的地方。本周的嘉宾是 Meaghan Choi，她是 Claude Code 的设计负责人，也很快成为我在行业内最喜欢交谈的人之一。而且感觉 Anthropic 的设计运作方式总是领先行业几个月。所以这次对话有很多值得学习的地方，也有一些让我惊讶的点。我们将深入探讨她的设计流程、Meaghan 如何使用 artifacts，以及设计师现代形态的演变。但在那之前，让我们从 Meaghan 在 Anthropic 的起点开始。

Welcome to Dive Club. My name is Rid and this is where designers never stop learning. This week's episode is with Meaghan Choi, who's the design lead for Claude Code and is pretty quickly becoming one of my favorite people in the industry to talk to. And it also kind of feels like the way that design operates at Anthropic is consistently a few months ahead of the rest of the industry. So, there's a lot to learn from in this conversation and a few things that surprised me as well. So, we're going to dig into her design process, the way that Meaghan uses artifacts, and all of the ways that the modern shape of designer is evolving. But before we get into that, let's start at the beginning of Meaghan's Anthropic journey.

我是在 2024 年底加入的。那时候，除了核心科技行业，几乎没人知道 Anthropic 是什么。每个人都只关注 ChatGPT 和 OpenAI。Anthropic 主要是一个 API 业务，没有真正的消费者部门。虽然有一个 Claude 应用，但还没有迎来它的爆发时刻。所以我加入时，记得人们问我“你去哪了？”我说“哦，我去 Anthropic。”他们就说“那是什么？从没听说过。”我其实很兴奋，因为我职业生涯大部分时间都在做开发者平台和新兴技术。我觉得在技术研究领域或新技术中构建东西时，开发者是最具创新性、也最挑剔的。所以你能亲眼看到你发明的真实用例。大概入职三四个月后，有人演示了一个奇怪的 CLI 流程，让 Claude 直接编辑你的代码。花了 45 分钟，非常慢，需要极其复杂的设置，比如配置远程工作区、下载所有脚本、做大量繁重的本地开发，然后它有时能写出不错的代码。但我看到时想，“天哪，太酷了，我得试试。”于是我试了，并联系了演示的人，包括 Boris、Adam、Cat 和其他几位内部同事。他们是以实验小组的形式在做，没有设计师，因为他们觉得“CLI 不需要设计”。我给经理发了私信，说“我觉得这会很了不起，我想为它设计 Moonlight。”经理说“当然，去做吧。”就这样开始了，然后就没停过。

So, I joined late 2024. This is back when no one even knew outside of like probably the core tech industry what Anthropic was. Like, everyone was so focused on ChatGPT and OpenAI at the time. And Anthropic was primarily an API business. It didn't really have a consumer arm. There was like a Claude app, but it just hadn't had its takeoff moment yet. And so when I joined, I remember people ask me, "Where are you going?" I'm like, "Oh, I'm going to Anthropic." They're like, "What's that? Never heard of it." I was really excited because I spent a lot of my career working on developer platforms and in emerging tech specifically. And I just feel like when you are building in like the tech research area or like new tech, developers are the most innovative and the most critical of everything that you'll ever build. So you get to see like the real use cases live of what you're inventing. Maybe about 3 or 4 months into my time at Anthropic, someone had like demoed this like weird CLI pipeline of having Claude edit your code directly. Took like 45 minutes. It was so slow. It required this extraordinarily complex setup of like setting up remote workspace, downloading all these scripts, like doing all this like local dev that was extremely heavy. and then it could kind of sometimes write good code sort of. But I remember seeing I was like, "Holy crap, that's so cool. I gotta try it." So I did and I got in touch with the people who were demoing it, which was Boris and Adam and Cat and a few other folks internally. They were doing it as an experimental pod. They didn't have a designer because they're like, "We don't need a design on the CLI." I DM'd my manager. I was like, "I think this is going to be big. I want to design Moonlight for this." My manager's like, "Sure, go ahead. Go do it." And that's kind of how I got started. and it never stopped.

我喜欢这种预期：“我们甚至不需要设计师，它只是个 CLI。”我想就算是一年半前，我可能也会这么反应。对我来说，设计师能插足哪里并不明显。那么，你插足在哪里？在终端内设计有哪些独特的挑战或机会，你当时在寻找什么？

I love that the expectation would be like, "Well, we don't even need a designer. It's a CLI." Which I think actually probably would have been my reaction even like a year and a half ago. It wouldn't have been obvious to me where a designer would slot in. So, where did you slot in? Like what were some of the things that you even were looking for in terms of like the challenges or opportunities that were unique to designing within the terminal.

我认为终端设计中有很多是构建产品背后的隐形思考。这正是我在 Anthropic 期望并招聘的，也是产品设计师长期被忽视的英雄之处：心理模型、交互模型、构成你思考交互对象的基础原语。所以有很多这方面的工作。而让 CLI 可用的最终形态是聊天。所以在聊天的来回交互中有很多需要设计，让它感觉更温暖、更愉悦，传达其状态性。我以前其实设计过 CLI，这不是第一次。所以我知道它需要帮助，而且我觉得这会很有趣。为 CLI 设计的挑战和约束实际上让它成为一个非常创新的发挥空间。

I think there's actually a lot of design of the terminal that's like the invisible thinking that goes behind building a product. That's one that I think I expect and hire for at Anthropic and I think has been the long unsung hero of product designers everywhere is like the mental model, the interaction model, like the base primitives that compose how you think about what you're interacting with. So there's a lot of that that goes into it. And then the ultimate form factor of the CLI that made it usable was a chat. So there was so much to design in that back and forth in between the chats that made it feel more warm, more delightful that communicated the statefulness of it. I have actually designed for CLI before. This wasn't my first time doing it. That's why I knew that it would need the help and I was like wow this is going to be fun. Like the challenges and constraints of designing for CLI make it a very innovative space to play actually.

好的，那我们来谈谈这个。我相信随着你内部使用和测试，发生了很多演变。所以帮我们理解 CLI 层面的设计是什么样的。你做了哪些迭代，设计扮演了什么角色？

Okay, let's talk about that then because I'm sure there were a ton of evolutions that were happening as you're getting usage and playing with internally. So help us understand what design looks like at a CLI level. Like what were some of those iterations that you were doing and the role that design played?

我会说其中一些就是如何传达工具调用和状态。这和你在 UI 上的设计思维完全一样，只是消息流的垂直化不同。你不能像在 GUI 中那样滚动或跳回，CLI 中所有内容一起滚动。所以当内容渲染时，你必须仔细考虑加载位置和显示多少信息。因为服务的是开发者，他们对 CLI 有非常具体的期望：信息密度要极高。你在 CLI 中显示的内容可能比在 GUI 中多得多，因为没有渐进式披露，所以就是直接披露。尤其是在早期模型不够好时，我们觉得“得让人们看到它在做什么，因为我们不确定它会不会跑偏”。另外键盘快捷键非常重要。像 Figma 这样的工具也考虑键盘操作，但终端的主要交互方式就是键盘快捷键。我清楚地记得，我和一些工程师就模式的快捷键争论了很长时间。

So I would say some of them are just like how you communicate the tool calling and statuses. Like it's the exact same kind of design thinking that you would have on a UI except the verticalization of how messages stream. You can't scroll or jump back in the same way. Like everything scrolls together in a CLI. So as things render in, you have to really think about where it's loading, how much information that you're showing. Because you're serving developers, they have very specific expectations with the CLI actually that you want it to be extraordinarily information dense. Like you would show more in a CLI than you would ever probably show in like a GUI, like a graphical interface, because there's no such thing as progressive disclosure. So it's just disclosed, especially in the early days when the models weren't as good. We're like, "Oh, we got to show people what it's doing because we're not sure if it's going to go off the rails a little bit." And then keyboard shortcuts are massive. I would say like there are power tools like Figma and other places where they do consider keyboard heavier but like the primary way you interact with a terminal is keyboard shortcuts. I distinctly remember we had this huge debate for a very very long time between myself and some of the engineers about what the shortcut should be for modes.

你正在一个既有大量肌肉记忆、但 Claude Code 的核心概念又根本上是全新的领域里构建产品。可能一开始甚至让一些工程师感到吃力。早期你在设计时有没有针对一些思维转变？比如你怎么让人们习惯 CLI 能做什么？

You're building in a space where there's simultaneously so much muscle memory, but then the core concept of what Claude Code was was fundamentally novel. Probably even stretched some engineers in the beginning. Like were there mindset shifts that you were designing for in those early days? Like how do you even get people comfortable with what a CLI could do?

我认为最大的障碍是让它感觉像是一个可以来回对话的聊天。CLI 本身就有那种模式：你打印，然后发送命令，它给出输出，再发送命令，再给出输出。所以我们很大程度上利用了这一点来锚定范式。但我觉得根本性的转变其实是它读取你的整个文件库，然后还能写入文件。这两个机械上的差异是让 Claude Code 高效的关键。我认为人们使用 Claude Code 时最神奇的时刻，就是它在你已有的工作上下文中直接为你做出编辑。你要知道，那还是大家把文件片段复制粘贴到聊天里、再把输出复制回文件里的时代。我们都深知那种痛苦。所以当你亲眼看到这一切自动发生，那就是人们意识到“天哪，这太棒了”的时刻——这将会改变我们的工作方式。所以我们很大程度上在优化那种初次体验。

I think the biggest hurdle to overcome was making it feel like a chat you could go back and forth with. CLI kind of have that where you like print and then it like you send a command, it gives an output, sends a command and gives an output. And so we leaned into that a lot to like anchor the paradigm. But I think the fundamental shift was actually it reading your entire file base and then writing to it as well. And those are like the two big mechanical differences that helped make Claude Code effective. Like I think the most magical moment that you always see people have with Claude Code is when it actually makes an edit for you with the context of everything that it knows about where you're working already. And you have to remember this is back in the era where everyone was like copying and pasting parts of their files into like a chat and then copying and pasting the output back into their files. And we all knew the pain of that. So seeing it happen in front of you without having to do that is like the moment that people realize like holy crap this is something amazing. Like this is going to change how we work. And so we were optimizing a lot for that first feeling.

实际上，我第一次的感受是记得我在看 Dan Hollik 使用 Claude Code，是他介绍给我的。我甚至不记得具体时间了，大概是去年秋天吧。你输入 Claude，然后出现全屏，还有一个巨大的橙色框。那让我有点懵，因为我完全没有 CLI 经验，看到那个界面我立刻想“哇，发生了什么？我在哪？这太不一样了。”

Actually, the first feeling for me was I remember I was watching Dan Hollik use Claude Code and he was the one who introduced me to it. I don't even remember when this been maybe last fall or something like that and you you type Claude and then you get that full screen and you have the giant orange box. That broke my brain a little bit cuz I I had never even my I had no CLI experience at all and seeing that or I'm like immediately whoa what's happening like where am I? This is very different.

我认为那可能是我在 Claude 体验中设计过的最有趣的东西。Claude 的吉祥物，可爱、有趣、不可思议，实际上是由 Claude 生成的，我觉得这是一个很好的点缀。我认为让用户从这些工具中感受到一点温暖非常重要。你不想和它们过于疏离。而且，我觉得 Claude 本身就有非常独特的个性，让与它合作变得愉快。所以我希望从视觉上真正体现这一点。我喜欢 AI 艺术，我觉得它很有趣。在软件开发时代，有一段深刻的 NFO 文件或信息文件时期，如果你还记得的话——那时你需要用脚本下载很多应用，其中许多都包含令人难以置信的艺术性 ASCII 艺术，你甚至无法想象。当时我就想，是的，我想把这个带入我们的应用。我觉得这会非常非常有趣。我们和品牌团队做了大量探索，才有了你现在看到的所有背景和动画，真正营造出一种你与 Claude 一起在电脑里的世界感。我觉得那就是我们想要传达的氛围。

I think that was actually probably the most fun thing I ever designed in the Claude experience. The Claude mascot, beloved, fun, incredible, generated by Claude actually, which I think is a really nice touch. I think it's really important that you feel a little bit of warmth from these tools. You don't want to be super super detached from them. And also, I think like Claude on its own has a very unique personality that makes it delightful to work with in my opinion. And so, I wanted to really represent that visually. I love AI art. I think it's so fun. There was this deep period of NFO files or info files if you remember back in the era of software development where like you would have to download all these you would have to script to download a lot of apps and a lot of them would include these like incredibly artistically drawn ascii arts like things that you couldn't even imagine. And at the time I was like yeah I want to bring this into our app. Like I think this would be really really fun. And we did a ton of exploration with the brand team actually on like all the backgrounds that you see now, like all the animations that you see now to really like make a world that feels like you're in the computer with Claude. And I think that's the vibe that we were trying to go for.

这让我想起了老式的 AIM 离开消息。你做过那种吗？我会用方块做出滚动的小图案和艺术画。所以那就像我的小家园，就是 AIM 离开消息上的小点。

It reminded me of the old AIM away messages. Did you ever do those where I would do the same thing? I would take the blocks and I would make little scrolling patterns and like art drawings. So it was like this was my little home was just my little dots on my aim away message.

好的，我想继续深入探讨你的现实——作为一个设计师，但不像我在职业生涯早期那样大量摆弄像素。另一个让我印象深刻的发布是 Artifacts，你仔细分析就会发现，输入可以是任何东西，而输出完全是非确定性的。在这样的功能流程和发布中，设计的角色是什么？给我们讲讲 Artifacts 的幕后故事吧。

Okay, I want to keep drilling into your reality as someone who is designing but isn't slinging pixels around nearly as much as I have, at least in in previous roles in my career. And another release that stood out to me was this artifacts release where you kind of break it down and you realize, well, okay, the inputs can be anything and the outputs are like completely non-deterministic. What is the role of design in a feature process and and release like that? So give us a little bit of a behind the scenes for Artifacts and what that was like.

我认为有一种非常强烈的新兴文化，人们想要的不仅仅是文本输出，而是可分享的、视觉化的东西。多年来我们学到，人们想要的不仅仅是文字，还有仪式感的视觉。你知道，我们都是设计师，所以我们理解这一点。Claude 非常擅长编码，极其擅长。随着这种趋势出现，有一种模式——我自己以前的工作流程中也经常这样做——就是不断让 Claude 生成 HTML 文件，因为它快速、敏捷，能快速拼凑出东西。Claude 很擅长制作，而且在此基础上迭代也非常快。如果做得好，你还可以分享它，这是很重要的一部分。我们早期就开始截取这些文件的截图，然后互相发送 HTML 文件以便审查。

I think there was a really strong kind of emerging culture of people wanting more than just a transcript as an output, like something sharable, something visual. We've like learned a lot over the years that it's not just like text that people want, but there's like a ritual visual. You know, we're all designers, so we understand that. And Claude is really good at coding, like excellent at coding. And so as that is emerging, there was a pattern of folks and I used to do this in my workflow as well of constantly asking Claude to generate HTML files for them because it's fast, it's snappy, it gets something like put together. Claude's really good at making it and then it's really quick to iterate on top of actually. And if done right, you can also share it which was a big part of it. We would start earlier starting to take screenshots of these files afterwards just like send a HTML file to each other so you could review it.

我发 HTML 文件发得太多了，这太疯狂了。我们互相发送 HTML 文件，这简直疯了。

I text HTML files way too much which is crazy. Like it's crazy that we're sending each other HTML files. It's actually insanity.

我甚至不知道还能这样。

I didn't even know you could.

我当时就说，我直接问 Claude，我说我有个 HTML 文件。我压根没想过 iMessage 还支持这个。就像，你在说什么？把它拖进 iMessage。我都没按回车。我说，不会吧。我经常这么干。

I was like, I literally asked Claude, I was like, I have this HTML file. I was like, I just didn't even think that iMessage supported it. Just like, what are you talking about? Drag it into iMessage. And I didn't hit enter. I'm like, no way. I do it all the time.

没错，没错。但如果你给别人发一个 HTML 文件，就好像，我们不是发明了互联网吗？为什么我们现在还要这么干？也许这正好凸显了工作流的问题。就像，哇，很多人都在这么做。我也在这么做。我们能不能让它变得更好用？你不用去问 Claude 怎么做。所以 Claude 自动就做了。哦，之后我们用它来做什么？实际上是想把它发给别人或分享给别人。我希望它是实时且可迭代的。所以当我们使用它、构建它的时候，我们开始发现我们想要的功能，然后把它做成产品。我们想，我最常用这些来做原型，以及迭代设计。我们的数据科学家最常用它来做仪表盘。我们的工程师用它来写技术规格、可视化 PR、做研究或为代码库写设计文档。然后你想把它发给别人。所以让我们托管这些。让它们可分享，这样任何人都能访问。哦，我其实还想能发送旧版本，但同时继续工作。哦，让我们为这些加上版本控制，这样你可以分享并固定某个特定版本，或者分享最新版本，这样就是实时的。所以，我们迭代这些东西的方式很大程度上是：我们先为自己构建。我们测试更广泛的采用，然后添加我们认为有用的功能，结果它对很多人都有用；或者我们从其他人那里得到反馈，了解什么对他们有用，然后我们把它构建进去，最终得到一个产品。有趣的是，有些人可能不认为这是传统意义上的设计，但我确实喜欢这个东西的形态。它一开始并不叫 artifacts。我们甚至不确定它会是什么。就像我们只是在发送 HTML 东西。我们一开始并不关心名字或包装。我们关心的是工作流。而随着我们深入，我们越来越觉得，我们如何把它融入别人的心智模型？这样它就不是他们需要学习的东西。它只是他们得到或拥有的东西，或者让人们了解它是什么以便知道如何使用它是否重要？而这些工作流才是设计真正发挥作用的地方。UI 部分本身极其简单，因为我的目标是，我们尽量不发明新的 UI。我们希望它感觉如此自然，以至于它成为你工作流中固有的一部分。Claude Code 团队有位设计师，他的 manure 非常棒。他说，我们在设计工具让人们完成工作。你注意到工具的那一刻，就是我们失败的时候。它应该完全不妨碍你。

Right. Right. But if you're sending someone an HTML file, it's like, didn't we invent the internet? Like, why are we doing this right now? And maybe this kind of highlights the workflow. It's like, wow, a lot of people were doing it. I was doing it. Can we make this something that's easier to use? You don't have to ask Claude to do it. So Claude does it automatically. Oh, what are we doing with it afterwards? Actually want to send it to someone or share it with someone. I want it to be live and iterable. So as we were using it, as we build it out, we start to uncover the features that we want out of we're using it and we build it into a product. We're like, I most commonly use these for prototypes and when I'm iterating on design. Our data scientists most commonly use it to make dashboards. Our engineers use it to make text specs or to visualize PRs or do research or design docs for the code bases. And then you want to send it to someone. So let's host these. Let's make them sharable so that anyone can access them. Oh, I actually want to be able to send an older version but keep working on it. Oh, let's add version control for these so that you can share and pin a specific version or you can share the latest version so they're live. So, a lot of the way that we kind of iterate on these is we build for ourselves. We test for the broader adoption and then we add features that we find useful and it ends up being useful for a lot of people or we get feedback from other folks on what is useful to them and we build it in and we end up with a product. And the interesting part of that is some people might not consider it traditionally design, but I do like what is the shape of this. It wasn't called artifacts to begin with. We weren't even sure what it would be. Like we were just sending HTML things. We didn't really care about the name or the packaging at the beginning. We cared about the workflow. And the deeper we went into it, the deeper we're like, how do we fit this into someone's mental model? So it's not something that they have to learn. It's just something they get or have or is it important for people to learn what it is so they know how to use it? And those workflows are really where the design comes in. The UI part of itself is extremely simple because in my goal, we're trying not to invent new UI. We want it to feel so natural that it just becomes intrinsically part of your workflow. There's a designer here on the Claude Code team whose manure is excellent. He's like, we're designing tools for people to get work done. The moment you notice the tool is the moment we failed. Like it should be totally out of your way.

我认为这是设计生产力工具的好方法。

And I think that's a great way to design productivity tools.

我们来帮助人们想象他们如何使用 artifacts。那么，你能谈谈你提到的分享原型吗？你的工作流是什么样的？你想达成什么目标？我想说，我使用 artifacts 的一个标准方式是，我会从团队那里收到一个功能请求，需要一些设计支持。与其我自己做设计，我直接让 Claude 生成一个 artifact，或者我让他们生成一个他们想要的东西的 artifact，有时我直接告诉他们用 Claude 设计来生成，然后发给我，我审查一下，然后我让我的 Claude 在那个 artifact 上迭代，如果需要反馈，或者我直接私信给他们反馈。然后我们就有了一个实时版本，显示我们从哪里开始，要往哪里去。然后 Claude 实际上可以发布最终版本。因为它已经嵌入到你的代码库中，一旦感觉达到中等保真度，我实际上会让 Claude 基于我们的实际组件来构建它。这样它就不再只是一个 HTML artifact，而是一个可分享的原型，我们也会把它检入仓库。所以它随着我们功能的成熟而成长，最终变成一个 pull request。有没有一个保真度上限？比如，它是对你要构建的东西的近似吗？那是天花板吗？它在早期阶段更有用？还是说我在试图弄清楚它如何适应我实际要发布的东西？我认为它作为 HTML artifact 的好处是迭代非常快，在早期阶段，你确实想要那些迭代循环。一旦你有了正确的形态，我认为从 artifact 切换到 PR 很容易，因为 Claude 知道它。这就是我采用的过渡方式。所以我们从早期的构思和反馈，到做出决定。把它做成 PR，这样当你觉得准备好了就可以直接发布。

Let's help people imagine how they could use artifacts. So, can you talk a little bit about you mentioned sharing prototypes, what's that workflow look like for you? what are you trying to accomplish? So, I'd say like a standard way I would use artifacts is I'll get a feature request from a team for like some design support and as opposed to me doing any design work, I'll just get Claude to generate an artifact or I'll ask them to generate an artifact of what they should be or sometimes I'll just tell them to use Claude design to generate that as well and then to send it to me and I'll review it and then I will get my Claude to iterate on that artifact if it needs any feedback or I'll DM them the feedback directly and then we kind of have a live version of like where we started. and where we're trying to go. And then Claude can actually ship that final version. And because it's baked into your codebase, once it feels mid-fidelity, I actually ask Claude to build it based off of our actual components. And so it no longer becomes just an HTML artifact, but a sharable prototype that then we check into the repository as well. And so it like grows as we get more sophisticated in a feature that then eventually becomes a pull request. Is there like a fidelity cap on what like you know is it an approximation of what you're trying to build? Is that like the ceiling where it's more useful early stage or like I'm trying to figure out exactly how that would fit into I'm actually trying to ship something. I think the benefit of it being in an HTML artifact is that it's so fast to iterate on and when you're in the early stages, you really want to get those iteration loops in. And then once you have the right shape of it, I think it's easy to switch from an artifact because Claude is aware of it into a PR. That's kind of the transition I go for. So we're going from like early ideation and feedback to a decision. Make it a PR so that you can just ship it when you feel like it's ready.

我以前发送 Figma 文件的方式，根本行不通。比如我想发给一个高管，我永远没法让他们进入画布或类似的东西。但现在我想，我本可以创建它，它甚至不是一个原型。它几乎像一个包含原型的交互式报告。

The way that I would send Figma files, like it just didn't really work. like if I'm trying to send it to like an exec member, I could never get them to go into the canvas or anything like that. But now I'm like I could have created it's not even a prototype. It's almost like an interactive report that includes a prototype.

正是如此。

Exactly.

我就想，天哪，你甚至能不能为他们构建不同的方式来表达他们喜欢什么或不同的意图片段，然后捕捉所有这些？这有点颠覆了我对这个工作流的看法，从设计师的工作——可视化想法、从团队其他成员那里收集意见和想法，然后尽可能收紧这个循环。我能看到这会是一个非常重要的工具。

I'm like, man, could you even build different ways for them to like express what they like or different intent pieces and then capture all of that? like it's kind of exploding what I think about this workflow in terms of the designer's job of visualizing ideas, sourcing opinions and and uh ideas from the rest of the team and then like tightening that loop as much as possible. I can see how this would be a big big tool.

它本身几乎就像一个微型站点和决策日志。我经常会让 Claude 实际拉取数据，或者拉取我已有的任何研究，比如来自我们的 bitquery、Slack、任何相关文档，然后在顶部总结，再放上我们要达成的目标。生成三到四个版本的设计。如果更复杂，我会让它分解出我们需要处理的不同工作流，然后给出提案。然后我会要求它……有趣的是，我经常在一个这样的东西里有多个 artifacts。比如我会有一个概览 artifact，然后旁边有一些用于概览上我想做的所有迭代的 artifact，然后我告诉它把所有内容发回主 artifact，那个主 artifact……

It's almost like a mini micro site and decision log in itself. Like often I will ask Claude to actually pull the data or pull any research I have from like our bitquery, Slack, any docs that we have on this and like summarize it at the top and then put a goal that we're trying to accomplish. Turn out like three to four versions of the design. If it's more complex, I'll ask it to break out actually the different work streams that we need to work on and then proposals for there. And then I will ask it for it. The interesting thing is I often have multiple artifacts in one of these. Like I'll have an overview one and then I'll have side ones for all the iterations on the overview one I want to do and then I tell it to send it all back to the main artifact and that main art.

它们是单独的链接，还是几乎像目录一样？

Are they separate links or is it like a table of contents almost?

它们是单独的链接，但如果你要求，Claude 可以让它们互相链接。所以我会问 Claude：“嘿，我想深入探讨一下入口点。比如说，我们原型设计五个不同的入口点。”

They're separate links but they can link to each other if you ask Claude. And so I'll ask Claude like, "Hey, like I want to do a deep dive on like the entry point. Let's say let's like prototype five different entry points."

我喜欢选项 A。标记我选择了选项 A，并在那里留下一个指向旧 Artifact 的链接。这样如果有人好奇我做了探索，他们就能看到这个决策。

I like option A. Mark that I chose option A and leave a link there to the old artifact. So if anyone's curious that I did the exploration, they can like see the decision.

哇，这太疯狂了。这本身就是一整套设计挑战，光是思考你想为人们创造的 Artifact 旅程就已经很复杂了。我认为 Artifact 的美妙之处，可能也是它的挑战之处，在于它非常开放——因为它真的可以是任何东西。它可以是你想要的任何东西。

Wow, that's crazy. This is like a whole set of design challenges in itself in terms of just thinking about the artifact journey that you want to create for people. And I think the beautiful thing about artifacts and probably the challenging part of it is that it's so open-ended like because it's truly anything. It can be anything that you want it to be.

我现在脑子转得飞快。我大概 80% 在聊这个，20% 在想接下来要做什么，因为我昨晚就在做一件事——我在 GitHub API 上构建东西，我知道我能从中获取不少元数据，但也有很多我不知道的。所以我直接给 Claude 发消息，让它去做一份研究报告，针对这组目标，列出所有我应该考虑使用的相关元数据，但我不想要一大段文字。所以我让它做成 HTML，然后把每条元数据做成多选按钮，这样我就可以点击选择，然后得到我选中的七项，再把这些作为上下文反馈给 Claude。我真正想做的是把它发给另外两个人，让他们过一遍，告诉我哪些元数据对他们有吸引力，比如他们最想在用户资料上看到什么。然后能够比较结果，并且有版本历史记录。

My brain's racing right now. I'm like I'm like I'm like 80% having this conversation and then 20% thinking about what I'm going to do right afterwards because something I was doing literally last night was I am building on top of the GitHub API and it's little I know maybe a good chunk of the metadata that I would be able to have available from that but there's so much that I don't know too. So I just sent Claude I was like go do a research report effectively and given this set of goals what is all of the relevant metadata that I should consider using but I didn't want that as a block of text. So I had it make it into HTML and then I had it build like each piece of metadata as a multi select so I could just click and then get like um okay like you know these are the seven things that I've selected and can feed that back as context into Claude. What I really wanted to do was to send that to two other people and be like, go through and let me know which pieces of metadata speak to you, like what would be the most compelling thing that you would want to see on a user profile. And then to be able to like compare the results and then have like a version history within that.

而且，做独立的 HTML 非常受限，但我做错了。我本应该用 Artifact 来做这个。

And yeah, very limiting when you're doing like the standalone HTML, but I did that wrong. Like I should have been using artifacts for this.

是的。这让它们变得无限强大且易于分享。我认为分享是重点，我们还会在上面叠加更多功能。我们在这条路上还非常早期，还有很多东西要来。所以你可以想象所有你真正想做的事情，我们也同样想做，而且它就在那里。我们正在考虑。

Yeah. And it makes them just like infinitely more capable and sharable. I think the sharing is really the big part and like we're going to layer more on top of it. We're like so early in this journey and a lot more is coming. So you can just imagine all the things that you really feel like you want to do, we also feel like we want to do and it's kind of there. Like we're thinking about it.

这是那种已经建好了下一个版本，但肯定还不能说的人露出的得意笑容。

That's the smirk of somebody who already has the next version built, but definitely cannot talk about it yet.

是的，很令人兴奋。我真的很喜欢。你知道，我从没想过我们会回到 HTML 作为代码的主要形式和主要框架，但它确实很强大。非常棒。速度很重要。

Yeah, it's exciting. I really like it. You know, I never thought we'd go back to HTML as like the main form factor for code and the main framework we use, but it's pretty powerful. It's pretty great. Speed means a lot.

有一个问题我一直在问自己：如果公司主动申请与你交谈，而不是反过来呢？这个问题就是全新 Dive 人才网络的基础，而且它正在发挥作用。就像现在，我正在帮助许多我知道的最令人兴奋的初创公司，招聘收听这个节目的设计师和构建者。所以，如果你好奇外面有什么机会，或者你想加入我的名单，甚至你正在寻找下一个设计人才，请访问 dive.club/talent 立即加入。

There's one question that I can't stop asking myself. What if companies applied to talk to you rather than the other way around? And that question is the foundation for the all-new dive talent network and it's working. Like right now, I'm helping many of the most exciting startups that I know to hire the designers and builders who listen to this show. So, if you're curious what might be out there, and maybe you want to get on my list, or maybe you're even looking for your next design hire, head to dive.club/talent to join today.

好了。我们聊了一点 Artifact 的社交层面，但我猜在具体如何与模型协作方面，还有更多内容。你已经在 Anthropic 一年半了。我们之前开玩笑说感觉像在狗年一样变老。所以，一年半与 Claude 反复头脑风暴，到现在几乎是永恒了。那么，当你在处理早期、更模糊、有深度的难题时，你与模型协作的方式有哪些演变？

Okay. So, we talked about like the social layer of artifacts a little bit, but I'm assuming there's more on the bone in terms of how you work specifically in the ways that you're collaborating with the models. You've been there, I mean like a year and a half. We were joking before this about how it feels like we're aging in dog years. So, like a year and a half worth of reps brainstorming with Claude is almost an eternity at this point. And so when you're working on maybe early stage more ambiguous meaty problem spaces, what are some of the ways that you've evolved how you collaborate with the models?

天哪，我一直在和我的 Claude 进行既存在主义又个人化的大脑思考讨论，同时也有非常战术性的执行工作。我们现在在这里工作的美妙之处在于，这一切都融为一体。所以我基本上不需要在两者之间切换语言，我认为这是我们旧的工作方式。所有东西都整合在一起，我在 Slack 里有一个 Claude 频道，就像我大脑的吐纳。我实际上全在 Slack 里做。这很疯狂。这可能是个疯狂的工作流，但我大部分工作都在 Slack 里。

Man, I am like constantly having both existential personal kind of big brain thinky discussions with my Claude and then also very tactical execution work. And the beauty of how we now work here is that it's all together. So I don't really have to code switch in between those two which is I think our old way of working. It's all kind of built in together and I have like one Claude channel that's like my regurgitated brain in Slack. I actually do it all in Slack. It's crazy. It might be like a crazy workflow but most of my work is in Slack.

我没想到会是这样。

I didn't see that coming.

是的。如果你看到 Claude Tag 的发布，我认为这是一个我们可以多聊一点的大话题。我的很多思考和执行工作都在那里完成，我产生了很多想法，并与 Claude 在高层次和低层次的执行上来回交流。

Yeah. If you see the Claude tag launch and I think this is like a big one that we can chat about a little bit more. A lot of my both thinking and execution work is all done there and I'm generating so much ideas and I'm going back and forth with Claude at a high level and a lower level of execution.

好的，暂停一下。那我们来聊聊 Claude Tag 吧，因为我没想到你主要是在 Slack 里交互。所以给我们一点背景，这到底是什么？我记得在 Twitter 上看到过，但当时并不清楚它干掉了一堆初创公司，也不清楚它解锁了什么。为什么它这么重要？为什么你认为设计师会更常用它？

Okay, pause. Let's talk about Claude tag then because I did not expect you to be interfacing predominantly in Slack. So give us a little bit of context for what the heck that is. I remember seeing it on Twitter, but it didn't immediately like it was clear that it killed a bunch of startups, but it wasn't immediately clear what it unlocked. So why is that a big deal? and why do you think that designers are going to be using that more?

是的。我认为 Claude Tag 是一个很难让人透彻理解的概念。我们在内部遇到了很多挑战，而且我们仍在努力弄清楚如何向人们解释它，因为它有点像 Claude Code 那样的产品，我认为你必须使用它才能真正感受到，但要达到让它有用的地步需要一点门槛。就像说服非工程师下载 CLI 工具并在终端中工作一样困难，然而我们现在已经看到很多人这么做了。我认为 Claude Tag 也有类似的飞跃。看待它的方式是，它与你使用 Claude 的方式完全是一个范式转变。今天，你把 Claude 当作一个工具。你给它指令，然后它遵循指令给你反馈。就像进进出出，进进出出。而且完全是单人模式，只有你一个人，非常基于会话。你启动一个 Claude，再启动另一个 Claude，它们彼此分离。是的，有空的文件，但感觉一切还是相当分离。正如你提到的，分享是个问题。Claude Tag 引入的是，你不是在和一堆不同的 Claude 工作。你在和 Claude 工作，实际上是一个单一的 Claude。而且不只是你一个人和这个单一的 Claude 工作，你组织中的每个人都在和那个 Claude 工作。天哪，我该怎么描述呢？我认为这很难，因为人类思维受限于我们能理解的东西，但这是一个工作方式与人类不同的 Claude。你有点需要让自己迈出那一步，意识到哦，Claude 可以同时进行数千次对话，而作为人类你可能只能进行四五次。

Yeah. So, I think Claude Tag is a really hard concept to wrap your head around transparently. Like, we had a lot of challenges internally and we're still trying to work through exactly how to explain it to people because it's one of those products somewhat similarly to Claude Code that I think you have to use in order to really feel, but it takes a little bit of hurdle to get to a point of making it useful. In the same way that it takes a lot to convince a non-engineer to download a CLI tool and being in the terminal to be working and yet we've seen a lot of people do it now. I think Claude Tag has a similar kind of leap. The way to look at it is it's an entire paradigm shift in how you work with Claude. So today you're working with Claude as a tool. You're giving it direction and then it's following that direction giving you a feedback. It's like in and out in and out in and out. And it's all single player. It's all just you and it's all very session based. Like you spin up one Claude, you spin up another Claude, they're kind of separate from each other. Yes, there is like empty files, but it's a little bit like it still feels like everything's quite separated. And as you mentioned, sharing is a problem. What Claude Tag introduces is you're not working with a bunch of different Claudes. You're working with Claude, a single Claude actually. And not just you working with a single Claude, but everyone in your organization is working with that Claude. Man, how do I describe this? I think it's hard because like the human mind is limited to like what we can comprehend, but this is like a Claude that works differently than a human. Like you kind of got to let yourself take that leap and realize like oh Claude can have thousands of simultaneous conversations while you as a human can probably have four or five.

它同时进行着数千场对话，所有这些都运行在一个共享的知识和记忆层上。它还可以访问自己的一套工具，而不是局限于你自己的用户 MCP。你的组织可以给 Claude 自己的凭证，这样它就可以有自己的 GitHub 访问权限、自己的 Google 访问权限、自己的 Asana 访问权限，因此它可以按需采取行动，就像你组织中的一名成员一样。所以，这看起来就像是我在和 Claude 一起处理一个功能时，它会拉取所有工程师在不同频道、不同文档或不同代码库中处理该功能的知识。所有负责上市的产品经理，以及组织内发生的其他所有事情，它都知道，但它也知道我正在负责设计方面。所以，当我们一起 brainstorming 时，它会给我反馈和方向，告诉我设计可能是什么样子，以及它如何与组织中正在发生的其他所有事情相关联，而我完全不需要参加 30 个不同的会议。就像 Claude 帮我把所有信息都记在脑子里一样。而且它非常主动，比我们现有的 Claude 都主动。它为大家无限运行。所以，当其他频道有更新时，有时我正在说话，它会说：“哦，嘿，某某人刚刚就你问过的事情做了一个决定。你可以这样更新你的想法，或者你应该和他们谈谈，因为这和你的看法略有不同。”

And so it's having those thousands of simultaneous conversations and it's all operating on a shared knowledge and a shared memory layer. It also has access to its own set of tools as opposed to being limited to your own user MCPs. Your organization can give Claude its own credentials so that it can have its own GitHub access, its own Google access, its own Asana access, and so it can take actions as it needs to be configured as a member of your organization. And so what that looks like is as I'm working with Claude on one feature, it will pull in all the knowledge of all the engineers working on it in a different channel or in a different documentation or in a different codebase. All the PMs that go to market, like all the other pieces that are organizationally happening, it knows about, but it also knows that I'm working on the design side of it. So, when we're riffing together, it's giving me feedback and direction on what design could look like and how it relates to all the other pieces that are going on in the organization as well without me needing to be in like 30 different meetings for it to happen. I just like hold all this in my head like Claude's holding it in my head for me. And it's so proactive as well in a way that our existing Claudes are. It runs infinitely for everyone. And so as updates are happening in other channels, sometimes I'm talking and it's like, "Oh, hey, so and so just made a decision here about something you were asking about. This is how you can update your thinking or this is something that you should talk to them about because it's slightly different from how you see it."

所以它让这些大型讨论变得快得多。然后在交付方面，因为它如此主动，如此集成，我现在很多 PR 实际上都是通过 Slack 写的。这么说是不是很疯狂？

And so it just makes it so much faster to have these big discussions. And then on the ship side of things, because it's so proactive, because it's so integrated, a lot of my PRs are written actually through Slack right now. Is that a crazy thing to say?

这太疯狂了。是啊。我本来没觉得这么说很疯狂。

That's crazy. Yeah. I didn't think it was a crazy thing to say.

我实际上可以分享一些截图，展示它的样子，一些我复制粘贴并稍作编辑的例子，展示我和 Tag 的一些对话。

I can actually share I put together some screenshots of what it looks like, some examples that I copied and pasted with a little bit of redacting into what some of my conversations with Tag look like.

我们对此进行了很多讨论，因为这是一种新的心智模型。我们不希望你认为这个按用户分割的 Claude 和这个组织级的 Claude 是一样的，因为它非常开放。这里有点微妙。我们希望人们转变他们与这个 Claude 合作的方式。最疯狂的部分是我们用 Claude Tag 来构建 Claude Tag，所以这非常元。比如，我用 Claude Tag 来更新 Claude Tag，而它知道自己是 Claude Tag。我和 Claude 有过一些疯狂的对话，我说：“你知道你是 Claude 吗？你觉得这应该是什么，因为你就是 Claude Tag？”

We had a lot of discussion on this because it is a new mental model. We don't want you to think that this Claude, which is user segmented, is the same as this organizational Claude because it's so open. There's a little bit there. Like we want people to shift how they're thinking about how they work with this Claude. The crazy part is we use Claude Tag to build Claude Tag, so it's very meta. Like I was using Claude Tag to update Claude Tag and it was aware that it's Claude Tag. I've had some crazy conversations with Claude where I'm like, "Do you know you're Claude? Like what do you think this should be because you are Claude Tag?"

然后它会经历那些疯狂的事情，它会浏览它自己的转录，比如 Anthropic 或 ants（我们这样称呼自己）使用 Claude Tag 的转录，然后说：“哦，这就是我认为它应该的样子，因为这是我在反馈频道中收到的关于我自己的所有反馈，而它正在管理这些反馈。”

And then it'll go through the crazy, it'll go through its transcripts of like Anthropic or ants, that's what we call ourselves, using Claude Tag and be like, "Oh, this is what I think it should be because this is all the feedback I'm getting in the feedback channel about myself that it's managing."

哇，这太迷幻了。太疯狂了。但这是我的一个例子。我有一个 Meaghan Claude 频道。我一直开着它，因为这样做的一个美妙之处在于，你可以从观察其他人如何与我们的 Claude 合作中学到很多东西。有时我会说：“嘿，Claude，你看到 Boris 在他的频道里做什么了吗？我想要那个。给我完全一样的东西，所有东西都这样。”所以，它在社交方面非常强大。我知道分享技能和工作流程有很多挑战。但在这里，你基本上可以直接说，你看到别人的工作流程，然后说：“我想要它。”因为 Claude 在那里做了那个工作流程，它已经知道了。它就会直接给你带来。你只需要让它做就行了。

Dang, that's trippy. It's so crazy. But this is an example of me. I have a Meaghan Claude channel. I keep it open because one really beautiful thing about this is actually you learn a lot from seeing how other people are working with our Claudes. Sometimes I'll say like, "Hey Claude, did you see what Boris was doing in his channel? I want that. Give me the exact same thing for everything." So, it's very social in that way. I know there's a lot of challenges of sharing skills and workflows. This is one where you can literally just say you can see someone else's workflow and be like, "I want it." And because Claude did that workflow there, it already knows it. It'll just bring it to you. You just have to ask it to do it.

是啊。你甚至不需要粘贴截图或任何东西。你基本上可以直接引用任何其他对话。

Yeah. You're not even pasting a screenshot or anything. You can literally just reference any other conversation.

是的，我会复制粘贴私信链接或公开链接。它就会说：“我想要这个。你能帮我做这个吗？”

Yeah, I'll copy and paste the DM link or the open link. It'll be like, "I want this. Can you do this for me, please?"

哇，太酷了。

Dang, that's cool.

所以，这是我发给 Claude 的一条消息。这是一个例子，展示了一些我想修复的细枝末节的 UI 细节，现在我都让 Claude 来做。我说：“嘿，那里有一个投影，本不该有的。把它去掉。”对吧。超级简单的修复。Claude 马上行动，因为它可以访问我们的仓库。它找到了页面和样式。它帮我移除了投影，推送了一个新分支，打开了一个 PR，并在 PR 中贴了一张截图。这是我偏好的做法。所以我让 Claude，每当它做 UI 更改时，在 PR 里放一张截图，这样我就能看到。我还做了一件事，这是 Claude Tag 特别的地方：它会随着时间了解你。所以你现在看到的实际上是我与 Claude 合作以及我偏好的迭代结果，那就是总是创建一个草稿 PR，而不是一个公开 PR，这样就不会触发 CI。然后在 PR 描述中总是放一张前后对比的截图，这样我在打开 PR 之前就能看到效果。所以 Claude 为我生成了这个 PR。我点击了链接。我说：“嗯，看起来不错。现在打开 PR 并合并它。”然后最疯狂的部分是，它确保 CI 通过了。它在 stamp 频道里发帖，让我的工程师们来审查。然后它告诉我什么时候合并了。所以在我发送私信、审查输出之后，我什么都没做。它就完成了。所有事情都为我做完了。

So, this is a message I sent to Claude. This is an example of some of the nitty-gritty UI details that I want fixed that I now just have Claude do. So, I was like, "Hey, there was a drop shadow there. There wasn't meant to be one. Remove it." Right. Super easy fix. Claude is on it, finding because it has access to our repositories. It's finding the page and the styling. It removed it for me, pushed a new branch, opened a PR, posted a screenshot to the PR. That's something that I have a preference for. So I ask Claude, whenever you're making UI changes, put a screenshot in the PR so I can see it. One thing I also did, this is something special about Claude Tag, is it also learns about you over time. So what you're seeing in here is actually an iteration of me working with Claude and the preferences I have, which is always draft a PR, but make it a draft PR, not an open PR, so it doesn't trigger CI. And then always put a screenshot of the before and after in the PR description so that I can see what it looks like before I open it. So Claude generated this PR for me. I clicked the link. I was like, "Yeah, it looks good. Now open the PR and merge it." And then the crazy part is it made sure CI was passing. It posted in the stamp channel to get a review from my engineers. And then it told me when it was merged. So after me sending the DM, reviewing the output, I didn't do anything else. It was done. It was all done for me.

什么鬼？

What the heck?

太疯狂了。

It's crazy.

你现在交付的代码中有多大比例是这样完成的？有没有一个趋势？这显然是一个非常底层的视觉变化。这对我来说是合理的。给我大致介绍一下，这在你的工作流程中占多大比重。

What percentage of code that you are shipping is just happening like this right now? And is there a trend? This is obviously a very low-level visual change. That makes sense to me. Give me a lay of the land a little bit in terms of just how big a part of your workflow this is.

我会说现在超过一半的代码都是这样完成的。

I would say more than half of my code is done like this now.

什么鬼？

What the heck?

而且这还不是最简单的例子。有时我在做全面的重构。比如我有一个任务，是我在指导它。还有一些任务现在正在自动运行。例如，我有一个清理任务，每周一它会给我展示清理内容，然后它会为我生成一堆 PR，我只需要审查前后对比，然后尝试合并它们。像这个例子，我认为它甚至不算前瞻性，因为我必须要求 Claude 做设计更改，但很多时候 Claude 会根据过去为我合并的工作，或者前瞻性的工作，或者 Anthropic 的人在 Slack 上关于 UX 应该是什么的讨论来主动提出建议。

And it's not like this is the simplest example of it. Sometimes I'm doing full overhauls. Like I have one and this is me directing it. I have some that are just automatically running right now. So, for example, I have a job that does cleanup that every Monday it'll just show me cleanup and then it'll spin up a bunch of PRs for me like that and I'll just review the before and afters and then I'll just try and merge them. Like this example, I think it's even not as forward-looking because I had to ask Claude to do the design change, but very often Claude is proposing based off of work that has merged in the past for me or work that is forward-looking or discussions that are happening in Slack between people at Anthropic about what the UX should be.

我会让 Claude 把那些信号发给我，然后我查看一下，接着 Claude 通常会生成一个 PR，提出可能的方案。而且不仅仅是 PR，我还能展示其他工作流程。比如这个例子，它需要一次比较大的改版，所以我就说：“哦，我们需要清理一下这个页面。”这里有很多不同的状态。我们有一个高级设置区域，我不确定它应该是什么样子。我有个 Figma 链接，里面是我们 brainstorm 的不同架构方案，所以我就直接把它链接到了 Figma。

I'll have Claude signal those to me and then I'll look into them and then Claude will typically generate a PR for like proposals for what it could be. And it's not just PRs. I can show some other workflows. So this is another one where it needed a little bit bigger of an overhaul and so I was like, "Oh, like you need let's clean up this page." There's a bunch of different states here. We had an advanced section. I wasn't sure what it should be. I had a Figma link of what we were brainstorming different architects of it. So I just linked it to Figma.

快，给我们讲讲那个 Figma 链接的背景。你现在在 Figma 里做到什么程度了？

Quick, give us a little bit of context on that Figma link. How far are you actually going in Figma right now?

嗯，这个主要是关于排列顺序的。我试了四五种不同的顺序，比如这些配置应该按什么顺序排列。对我来说，在 Figma 里做会更快。我觉得我们内部的设计师有时候也会争论这个问题，因为有些人还在用 Figma，而且我们在不同阶段使用它的程度也不同，有些人根本不用。对我来说，当我知道自己用 Figma 更快的时候，比如我知道要做的迭代用 Figma 的自动布局等功能会更快，我就会用它。这对我来说是个速度问题。

Um, this one was mostly around like ordering stuff around. I went through like four or five different orders of like should these configs be in this order and it's faster for me personally to do it in Figma. I think the designers internally actually we debate about this sometimes because some people still use Figma and we all use it at different stages, some people don't use it at all. For me, I use it when I know I'm faster like when the iteration I know I want to do, I'll be faster doing it with like auto layout and stuff in Figma. That's a speed thing for me.

那你什么时候在 Figma 里更快？能再深入讲讲吗？

When now are you faster in Figma? Like go a little bit deeper there.

嗯，具体到这个例子，我们有大约 30 个不同的设置，我想知道把它们折叠起来会不会更好看，以及它们的顺序和层级应该怎么安排。用自动布局的话，我自己移动东西其实非常容易。所以我实际上做了三个版本的 Figma 链接，其中一个我标为推荐。我之所以用 Figma 做这个，部分原因是我们之前没有类似“高级”这样的模式，所以我想给 Claude 一个参考，让它知道这个新引入的高级模式应该长什么样。

Uh well, for this one specifically, there's like we had like 30 different settings and I wanted to know if it would look better collapsed and what order they should all be and what hierarchy they should be. And with auto layout, it's really easy to move things around actually myself. And so I put up three versions of this Figma link actually. And I had one that highlighted as like recommended. Part of the reason I also was in Figma for this one is because we didn't have anything like advanced and so I wanted to have a reference for Claude to know what the advanced pattern would look like because it's a new one that we're introducing.

明白。

Sure.

不过其实很简单。它添加了一个可折叠的高级区域，对整体工作方式做了这些改动，然后提交了一个 PR 草稿。我现在真的很信任 Claude，我基本上会等它完成。它给我展示了改前和改后的对比。我点进去一看，最有趣也让我喜欢的一点是，我的设计里有些空白，它自己做了判断——它自己做了设计决策。它说：“嘿，我做了一个决定，因为你的设计里没有包含这个，而且我觉得这样更好。”实际上它说的是：“如果你希望我完全匹配你的 mockup，我可以照做，但我认为我的判断更好。”而且它是对的，非常对。我当时就想：“哦，哇。”

Very simple though. So it added a collapsible advanced section. It's making all these changes on how everything works. It's putting up a draft PR. I like really trust Claude at this point. I actually kind of wait until it's done. It put up a before and after for me. So, I clicked into it and then the really interesting part that I love is that there was some gaps in my design. So, it made a call. Like, it made a design call on its own. It's like, "Hey, I made a decision because your designs didn't include it. And I think it's better." Actually, it says like, "If you want me to match the mockup, I'll do it, but I think my call was better." And it was right. It was like so right. I was like, "Oh, wow."

过去一周我也遇到过几次这种情况，它说：“我做了一个判断。我看到了这个不一致。感觉你在把我往这个方向推，但如果我们走这条路，我觉得会更好，因为 XYZ 原因。”我读完就忍不住说：“靠。”

That's happened to me a few times in the last week where it says, "One call I made. I saw this discrepancy. It felt like you were pushing me this way, but if we went this way, I think it'd be better for XYZ reasons." and I read it and I'm just like damn.

对。

Right.

它说得对。

It's right.

所以想象一下，Claude 不仅能根据你的设计模式做判断，还能对所有架构决策、产品决策和上市决策都这样做。比如有一次，团队决定重命名一个功能，它就说：“哦对了，大家决定重命名这个，所以提醒你一下，我也会更新这里的文案。”我当时就想：“哇，谢谢。”

So imagine Claude doing that not just with the knowledge of your design patterns but with all the decisions that are making on the architecture of how things work and all the product and go to market decisions that happening. For example, I was doing this at one point and the team had decided to rename a feature and it just like, "Oh by the way, everyone decided to rename this so just as a heads up I'm going to update the copy here as well." I was like, "Wow, thank you."

哦，天哪，太酷了。太酷了。

Oh man, that's so cool. That's so cool.

然后我看了看，说：“嘿，我们是不是应该把这个特定设置单独拿出来？因为我觉得它可能很重要。”这就是我和 Claude 之间的那种讨论，比如：“你觉得我该这么做吗？”我其实不知道，我问它来搞清楚，而它给了我一个答案，因为这是用户最常操作的控件之一。它从我们的数据中提取信息，说：“嘿，我觉得你应该把它保留在这里，因为根据使用模式，这是一个人们经常使用的配置。”它能做到这一点，是因为它可以访问我们所有的数据日志。它给我做了一个原型，让我可以点击进去。我查看了 Porter 原型，打开了 PR，确认 CI 通过了，一切就绪，然后合并了。

And then I looked at it I was like, "Hey, like should we pull out this specific setting because I think it might be important to pull out." So these are like the kind of discussions I have with Claude like, "Do you think I should do this?" I actually don't know. I'm asking to figure it out and it has an answer for me why because it's one of the most touched controls. So it's pulling from our data and it's saying, "Hey, actually I think it's important that you keep it in here because it's a config that people use based off of usage patterns" and it has that because it has its own access to all of our like data logging. Put together a prototype for me so I could click into it. Looked into the Porter prototype, opened the PR, made sure it's CI pass, all good to go, merged.

好的，我有问题。第一个问题是，我知道肯定有人在看这个，他们会说：“她只是把思考外包给了模型。我们甚至都不再思考了，就让模型为所欲为。这根本不是设计。”你会对那个人说什么？

Okay, I have questions. I think the first one is actually I know that there is somebody somewhere that is looking at this and they're like, "She's just outsourcing her thinking to the models. We don't even think anymore. We just let the models do whatever we want. That's not design." What would you say to that person?

现在有太多设计工作需要做了，你看到的这些是我认为可以外包的部分，因为模型已经足够有能力，这样我就能把时间花在那些真正棘手、需要深度设计思考的问题上。我觉得我们正处于一个时代，尤其是如果你在那些采用快速迭代节奏的实验室或公司工作，你很难跟上所有正在发生的事情。所以你看到的这几个例子，实际上是我如何跟上节奏的方式，也是 Anthropic 的员工如何跟上节奏的方式——我们正在寻找方法来自动化那些可以自动化的部分。这样我们就能花大量时间在那些真正困难的设计思考问题上。比如，一个非常难的思考问题是：如何向人们解释这是“组织的 Claude”？它是一个整个组织共同使用的 Claude，而不仅仅是你个人的 Claude。人们是否希望在特定渠道拥有独立的访问权限？我们如何让他们配置这些权限，既能发挥 Claude 了解组织其他所有信息的强大能力，又不会违反组织中可能明确设定的安全限制？我们如何让你区分：给 Claude 作为组织实体的访问权限，与仅仅通过 MCP 使用你自己的用户权限——而 MCP 本身已经很难理解了——这两者之间的区别？这些才是我们花大量时间思考的重要部分，我们不会外包它们，因为它们涉及用户与模型的关系和行为。而那些设计打磨或更新之类的工作，则是很容易外包的。

There is so much design work to happen that needs to happen right now that what you're seeing is everything that I believe I can offload because the models are capable enough right now so that I can spend my time on like the really really hard gnarly problems that need deep design thinking. I think we're all in an era right now, especially if you're working at one of the labs or one of the companies that have really adopted this fast-paced shipping where you're just it's hard to keep up with everything that's going out right now. And so these few examples you see are the examples of how I keep up actually and how people at Anthropic are keeping up because we're finding ways to automate the parts that can be automated. So we can spend a lot of time on like the really hard design thinking problems that we're working with. Like for example, a really hard thinking problem that's part of it is like how do we explain to people that this is an organization's Claude? It's one Claude that your entire organization works with. It's not just your Claude. Will people want separate access in a specific channel and how do we let them configure that so that you still have the power of Claude knowing everything about the rest of the organization but it's not breaching any security restrictions that you might explicitly have in your organization. How do we let you know the difference between giving Claude access as an entity in your organization versus just using your own user off MCPs which MCPs are already kind of hard to understand like how do we make that distinction between you. Those are the really important pieces that we spend a lot of time thinking on that we won't offload because it's about the user model relationship and behavior and like these design polish pieces or some of these updated ones are like really easy ones to offload.

但你还是通过和模型来回交流，做了很多设计工作，甚至包括你自己的内部头脑风暴，对吧？

But you're still doing a lot of that design work and even your own internal brainstorming by having back and forth with the models, right?

嗯，绝对是的。

Mhm. Absolutely.

那我们来聊聊这部分。你提到了那些棘手的问题，也提到了存在性对话。在我看来，你刚才展示的更多是执行驱动的工作，比如大规模地清除所有 P3 级别的事情。

Let's talk about that piece then. Like you talked about like the gnarly problems. You also said like the existential conversations. So like what you just showed in my opinion would be like very execution-driven work. Let's just get rid of all the P3 things at scale.

我相信有很多听众对 AI 的使用还停留在那个层面，还没有真正迈出下一步，去思考如何让 Claude 加速我对宏观问题的思考。我知道这种来回对话听起来有点模糊，但对于那些完全没有朝这个方向前进的人，请帮我们理解一下，当你与 Claude 合作解决这些真正模糊棘手的问题时，你的实践是什么样的。

And I'm sure there's a lot of people listening who that's kind of their usage of AI and they haven't really taken steps toward more of the how do I get Claude to accelerate my thinking on like the big picture stuff. So, like I know it's a little bit wishy-washy what these back and forths look like, but for people who are not moving in that direction at all, like help us understand what your practice looks like when you are collaborating with Claude on some of these really, you know, the the the ambiguous gnarly problems.

我认为这有两个方面。首先，从战术层面来说，设计师正在学习发展一套技能。有些人已经掌握了，有些人还没有。这与历史上对设计角色的看法有些相反——过去有一种主流观点认为，设计就是掌控一切的质量和打磨，所有东西都必须精致完美。我认为这很重要，但你不必把所有时间都花在这上面。所以，知道何时使用这些工具来执行和外包，以及何时需要深入思考，是一项技能。我认为我看到很多人在这方面做错了。比如，你可能让 Claude 去执行，但实际上你应该让 Claude 做早期的思考。执行是错误的，执行的形态不正确。而 Claude 目前并不擅长告诉你你的想法是否错误，它只会执行你要求它做的事情。因此，作为设计师，你有责任——我认为这是一项非常重要的技能——去判断这是否是产品的正确形态，还是我应该与 Claude 讨论形态本身，而不是执行细节，比如心智模型和原始概念，而不是它看起来怎么样。这是设计中非常重要的一部分，我认为人们经常忽视。首先，你需要能够自己认识到这一点。一旦你认识到这一点，我认为当你与 Claude 合作处理更初期的事情时，我的探索往往会更加模糊。比如，我并没有试图从 Claude 那里得到特定的输出，我只是在进行讨论。我会说：“嘿，我在考虑一个想法，但不确定它应该往哪个方向走。让我们保持开放。”我几乎像与产品合作伙伴一样与 Claude 合作，希望它能与我一起拓宽探索过程，同时我也要求它调动已有的所有知识，来自研究和数据，这样我们就能做出明智的决策。这样的过程可能看起来像这样：比如，我想做一个——随便说——一个我和我丈夫用的每周膳食计划应用。膳食计划应用需要什么？膳食计划工作流程的所有部分是什么？你需要下单，你需要有食材，你需要知道你想在家做什么菜，你需要知道什么时候想出去吃。它会为我提出整个工作流程，不是从设计角度，而是几乎从功能产品的角度。然后有些人会问，嘿，膳食计划应用到底是什么？我会进行这些存在主义式的讨论：它是一个应用吗？它实际上只是一个工作流程吗？我甚至需要为它设计 UI 吗？还是它可以什么都不做，我就让你去做？然后有时 Claude 会说，我觉得你喜欢应用，所以你应该有一个，但你丈夫不喜欢应用，你可以在最后给他发短信告诉他结果。就是这类讨论——你作为设计师通常会自我提问的讨论——现在你可以与 Claude 一起进行，把它当作一个头脑风暴伙伴。这就是很多工作的方向。而且这种思考并不像你想象的那么视觉化，虽然有时我会用 Claude 做思维导图或表格，但我认为大部分只是概念化各个部分。

I think there's two pieces to this. The first one I would say is that tactically there's a skill set that designers are learning to develop. Some already have and some don't. That is kind of an inverse of how you see the design role have been historically where there's a huge school of thought that design is all around owning the quality and polish of everything and everything has to be quality and polished and I think it's really important to have that but it doesn't have to be all of your time. And so knowing when to use these tools for execution and offload and knowing when you need to go deep and do the thinky work is a skill set. And I think that's one that I see people doing wrong. Like you might be asking Claude to do execution when you you should actually be asking Claude to do the early thinking. The execution is wrong. Like the shape of the execution is incorrect. And Claude is not good today at telling you if your idea is wrong, it'll just execute on the thing that you ask it to do. And so there's a responsibility on you as a designer, which I think is a really important skill set to have to know is this the right shape of product or should I be discussing with Claude the shape of it and not the execution of it like the mental model and the primitive rather than how it looks to someone and that's a really big part of design that I think people often overlook. First, you need to be able to recognize that as an individual. Once you recognize that, I think when you are working with Claude on the more initial side of things, I tend to have my explorations be a lot more amorphous. Like there's not a specific output I'm trying to get with Claude. I'm like only having a discussion. I say like, "Hey, I'm thinking about an idea and I'm not sure where it should go. Let's keep it open-ended." Like I'm working with Claude as if I would be working with like a product partner almost that I want to go wide with me in like our exploration process, but I'm also asking it to pull in all the knowledge that it has already from research, from data so that we can make informed decisions forward. And then a process like that might look like, hey, like I'm trying to make, I don't know, dummy like a weekly meal planning app with me and my husband. What does a meal planning app need? Like what are all the parts of the meal planning workflow? You need to order, you need to like have the ingredients, you need to like know what food you want to cook at home, you need to know when you want to go out. Like it'll propose the entire workflow for me, not from a design perspective, but from almost like a functional product perspective. And then some people are like, hey, like what is a meal planning app actually? And like I'll have these existential like is it an app? Is it just actually like a workflow? Like do I even need a UI for this or can it just be nothing? and I just ask you to do this and then sometimes Col be like I think you like apps so you should have one but your husband doesn't like apps you can just text him what happens at the very end it's like those kind of discussions that you have that you would typically prompt yourself as a designer that you can prompt with Claude now and have like a that brainstorming partner with you so that's where a lot of it goes and then that thinking isn't as visual as you think it is though like sometimes I'm making mind maps with Claude or like tables with Claude but I think a lot of it is just like conceptualizing the pieces

还有一件事我想谈谈，你之前已经提到过几次。你提到很多人有一种观点，认为设计必须经过我们才能出门，我们是维护工艺和质量标准的人。我理解，以你工作的节奏，这实际上可能是不可能的，但这也感觉像是大方向——随着谁拥有什么的界限变得模糊，Claude 在某种程度上帮助每个人做所有事情。所以，上次我们谈话时你提到的一件事是，你认为设计师需要更 comfortable 放手设计。我想我们已经看到了几个例子，但为什么这甚至是必要的？有没有什么时候连你也会感到不舒服？

There's another thing I want to talk about that is you've kind of talked around it a couple times where you mentioned how a lot of people like there's this school of thought where design is like things have to pass through us to go out the door and we're the ones that uphold the the bar for craft and quality and I get how working at like the tempo that you're working at maybe that is actually impossible but it also does feel like it is directionally where a lot of this stuff is headed as lines get a little bit more blurry in terms of who owns what and Claude helps everybody do everything to an extent. So, one of the things that you mentioned last time we talked was how you thought designers needed to be more comfortable letting go of design. And I think we've seen like a couple examples here of what that kind of looks like, but why is that even necessary? And are there times even where that has felt uncomfortable for you?

哦，绝对如此。我认为在 Anthropic，我们非常实验性，而且我们对产品形态的探索还处于非常早期的阶段。我经常说，我们在这段旅程中只走了 1%，关于 AI 应该是什么形态。有时知道什么时候需要工艺和打磨，或者什么时候你实际上只是在测试形态本身，这非常重要。所以你可能会发布或测试一些看起来很糟糕的东西，但你实际测试的是产品形态背后的心智模型。我认为打磨那个东西其实不值得，因为它可能根本说不通。你可能必须重写，因为它实际上不是正确的形态。在这些时候，我认为花大量迭代在打磨上不是好的时间利用。我希望我团队的设计师知道什么时候需要打磨，什么时候不需要。心智模型的实验不需要那么高的工艺，最好以速度、开放和迭代的方式进行，而不是花大量时间打磨一个实际上完全错误的产品形态。关于放手，第二部分是，我发现我们越能分享对产品质量的看法，而不是充当守门人，而是教育并委派给周围的人，这样我们的工程师和产品合作伙伴也会觉得质量是他们拥有和推动的东西。你想要降低门槛，提高天花板，让每个人都成为一点设计牧羊人或质量牧羊人。

Oh, absolutely. I think in the ease of of anthropic, we're very experimental and we're so early in this exploration of like the shape of the product. Like I say this all the time, we're 1% in this journey of like what the shape of AI should be. And sometimes knowing when it needs that craft and polish or knowing when just the shape of it is actually what you're trying to test is really important. And so you might launch something or test something that looks terrible, but what you're actually testing is the underlying mental model of the shape of product. And I don't think it's worth polishing that thing actually because it might not even make sense. You might have to rewrite it because it's actually not the right shape of what it needs to be. And those are the times where I think actually spending a lot of iteration on that polish isn't a good use of time. And I expect the designers on my team to know when something needs to be polished and when it doesn't. that experimentation of mental models doesn't require that high of craft and it's better done actually in speed in the open in iteration as opposed to spending a lot of time polishing something that's actually the wrong full wrong shape of what the product should be. The second part about handing it off is I tend to find the more we can share responsibility of what we think quality looks like in our product and not be the gatekeepers but educate and kind of delegate around us so that both our engineers and product partners feel that quality is something that they own and drive too. You want to like lower the floor and raise the ceiling for everyone to be design shepherds a little bit or quality shepherds.

降低门槛意味着让任何人都能自信地说“我觉得这个质量是对的”，并且你教他们为什么对或不对——或者如果你有好的自动化和设计系统文件，Claude 实际上会教他们什么是好的。然后一起提高上限，我认为历史上质量从来不只是设计的责任。最成功的组织感觉质量是每个人都拥有的。所以我们需要确保不是自己单打独斗，而是和周围所有人一起推动标准。你通过让人们共同拥有对质量的定义来做到这一点。

And so lowering the floor looks like making it so that anyone can feel empowered to say I think this is the right quality and you teach them why it is or not or Claude actually teaches them if you have good automations in place and good design system files in place to teach you what good looks like. And then raising the ceiling together means I don't think it has ever been historically only design's responsibility to mean quality. The most successful organizations feel like it's owned by everybody. So we need to make sure that we're not pushing the bar on our own but we're pushing the bar with everyone around us. And you do that by giving people that shared sense of ownership over what quality looks like.

听众中的设计师可以采取哪些实际步骤？也许是某种工作流程或策略，来降低门槛并让组织中的其他人能够在设计和更精致的输出方面做出更高水平的贡献。

What are some practical next steps that designers listening could put in place? Maybe it's like a workflow or a tactic to raise the floor and empower other people on their org to contribute at a higher level when it comes to design and more polished output.

我做过一个比较有效的方法：在我工程师的 PR 之上堆叠更漂亮的 PR，就像你刚才看到的工作流程那样。我其实不是手动做的，而是自动化完成的。一旦 Claude 学会了这是我的习惯，它就会自动开始做，这很疯狂，因为它非常主动。这是一种方式，因为它不会拖慢进度，也不会抹掉工程师的工作。它相当于给他们一个替代方案或迭代版本。通常当他们看到时，有时我会基于自己的 PR 进行堆叠或迭代，这样既保留了他们的原始意图，又符合产品的正确形态。我还尝试了一些工作流程，让 Claude 理解我思考的事情：我们为谁服务？我们想向他们传达什么？你知道，基本问题：我们在传达什么？这符合我们的设计系统吗？这经过我们过去的内容自动化了吗？这如何融入我们产品的更广泛生态系统？这应该是一个产品还是一个功能？这需要命名还是可以隐形？这些都是我经常问工程师的问题，Claude 随着时间的推移学会了这些。然后我慢慢构建一个自动审查器，它替我完成这些工作并提交 PR。或者，与 Slack 集成的有趣之处在于，它不再只是提交 PR。有时它会直接给某人发消息说：“嘿，Meaghan 对此有想法。你觉得呢？这里有一个原型，你可以玩玩看，看看她在想什么。”所以调整这种语言就像和人一起工作一样，这很有帮助。所以我建议投资于你如何定义质量以及如何提升它，然后将其作为工作流程分享给团队中的任何人。不要用它来阻止他们。虽然知道何时停止并守住标准很重要，但要尽量以建设性的方式去做，是教导和引导，而不是阻止。

One that I do which has somewhat worked is I'll stack nicer PRs on top of my engineers' PRs in the workflow that you just saw. I actually don't do them manually. I do them pretty automated. Like once Claude learned that that was a habit I did, it just started doing it on its own, which is crazy because it's very proactive. That's one way because it doesn't slow down the progress and it doesn't erase the work that the engineer does. It kind of gives them an alternative or an iteration on what they did. And typically when they see that, sometimes I actually stack or iterate off of my PR so that it still has the right idea of what they wanted to do, but it is in the right shape of product as well. And then I have been experimenting with some workflows where I have Claude understand the things that I think about. Who are we serving this for and what are we trying to communicate to them? You know, like the basic question: what are we communicating to them? Does this align with our design systems? Has this gone through the past with like our content automation? How does this fit into the broader ecosystems of our product? Should this be a product or should it be a feature? Does this need to be named or can it be invisible? There are all these things that I'm constantly asking my engineers that Claude has learned over time that I like to ask. And then I'm slowly putting together like an automated reviewer that kind of does this for me and will put up PRs. Or the interesting thing about being integrated in Slack is it's not always about putting up PRs anymore. Sometimes it'll just send a message to someone and be like, 'Hey, Meaghan thought this about this. What do you think? Here's a prototype that you could play around with to see what she was thinking about.' And so massaging that language is very similar to just working with people. And that's really helped. So I would say invest in how you define your quality and how you uplevel it, and then share that as a workflow that anyone on your team can use. And don't do it to stop them. Although it is important to know when to stop and hold the bar, but try and do it in a way that is additive and is teaching and guiding rather than stopping.

我们今天讨论的很多内容都超出了像素的范畴。我觉得这让对话变得非常有趣。但我猜绝大多数听众仍然在设计界面，对吧？比如传统的 B2B 产品。即使对我自己来说，在过去一年半里，我越来越感觉到我所做的产品的价值主张正在转向：如何通过 MCP 获取上下文、回到 Claude、闭环、加速迭代等等。老实说，这让我有点不安，实际上相当不安。我在想：我们是不是正在加速走向一个无界面的世界？我想知道你对此有多少思考，以及当感觉几乎可以在聊天中直接做任何事情时，界面在哪里具有持久价值和更强的防御性？

So much of what we've talked about today exists outside of pixels. And I think it's kind of what's made the conversation really enjoyable to me. But I got to imagine still the vast majority of people that are listening are designing interfaces, right? Like historical B2B products. And even for myself in the last year and a half, I felt more and more of the value props around the products that I'm making shift towards like what's the best model to get context through an MCP and back to Claude and close these loops and speed up iteration and that kind of thing. It feels a little bit uncomfortable to me to be totally honest, like actually quite uncomfortable. I'm like, are we just accelerating toward this interfaceless world? And I'm wondering how much you think about that and if you have any ideas around where does the interface have lasting value and more defensibility when it does kind of feel like you can almost do anything directly inside of a chat.

我最近一直在琢磨这个想法，并且逐渐形成一种更强的信念：我们仍然需要大量固定界面。现在 UI 可以分为两个概念：固定界面和自适应或非确定性界面。我认为有很多东西需要可靠地稳定，你不希望重新学习，也不希望它们动态变化，比如登录界面、账单设置。保持稳定其实很重要，我认为 UI 将非常重要。知道什么应该固定、什么应该自适应或动态，是你在设计这些功能时需要做出的非常重要的决定，因为我认为人们常常会假设一切都可以定制，所以就应该定制。我非常认为很多人并不希望一切都被定制。正确的事情才应该被定制和自适应。而在自适应方面，我认为问题在于：什么是自适应的容器层？你如何在视觉系统中表达某物是自适应的还是固定的？你如何让用户以他们理解的方式定制他们正在使用的工具或正在生成的输出？这些都是非常关键的工作流程，需要做对。所以我给人们的建议是：是的，会有很多非确定性的东西，但仍然有很多应该是固定的，而你的工作就是弄清楚这一点。然后在非确定性的东西中，你如何让人们觉得简单明了。

I've been really toying around with this idea recently and it's something that I'm slowly developing a stronger conviction that we're still going to need a lot of fixed interfaces. So there's two concepts now that UI can fall into. There's fixed and then there's adaptive or non-deterministic. And I think there's just so much that needs to be reliably stable that you don't want to relearn and you don't want to be dynamic, like a login screen, billing settings. There's a lot that actually feels important to keep stable, and I think that UI will be really important. Knowing what should be fixed and what should be adaptive or dynamic is a really important decision for you as a designer to make as you're designing these features, because I think often people will assume that everything should be customized because it can. I'm very much of the opinion that a lot of people don't want everything to be customized. The right things should be customized and adaptive. And then on the adaptive piece, I think it's like what's that container layer from what is adaptive? How do you express in a visual system that something's adaptive versus something's fixed? How do you let users customize it in a way that they understand that they're customizing the tool that they're using or they're customizing the output that they're generating? These are all like really critical workflows to get right. And so I think what I would guide people towards is: yes, there's going to be a lot that's non-deterministic, but there is still a lot that should be fixed, and it's your job to figure that out. And then in the things that are non-deterministic, how do you make that easy and clear to people.

是的，有道理。说实话，所有关于 artifacts 的东西都很有挑战性，我一直在思考如何划定界限。比如我有好几次在设计一个简单的例子，比如搜索结果，但搜索结果是基于自然语言的。它基本上可以返回任何东西，其形状完全取决于查询。我就想：好吧，我不想要一个完全动态的界面。我可能想要一组组件，也许将其映射到一个系统提示中，这样我们就能得到可重复的形状，有一点熟悉感，但 Claude 可以用它做任何你想做的事。我想我们正在快速奔向一个世界，在那里我未来的 Claude 交互就是这样的：一堆不同的组件组合，可能给我提供除了打字之外表达意图的不同方式。

Yeah, makes sense. Honestly all of the stuff with artifacts is even challenging where I've been drawing the lines thinking about it. Like I've had multiple instances now where I'm designing for a simplistic example maybe like a search results but the search results is natural language based. It can basically return anything and the shape of that is totally tied to the query where it's like okay I don't want to have an entirely dynamic interface. I want to probably have like a set of components and maybe map that to a system prompt where we're getting repeatable shapes where there's a little bit of familiarity but Claude can kind of do anything you want with it. And I guess I thought that we were speedrunning toward a world where that was how my future Claude interactions would look where you're having like a bunch of different component combos that are maybe giving me different ways of expressing intent outside of just typing it.

现在我觉得，也许 Artifacts 已经完全取代了那种方式，我甚至都不在聊天界面里和 Claude 交互了。这让我对未来界面的形态更加怀疑了。我不知道。这是我一直在思考的有趣问题——我们到底要走向何方？

And now I'm like, man, maybe Artifacts has swallowed that entirely from me where it's like I'm actually just not even interfacing with Claude inside of the chat. It made me almost even more skeptical about the level of interfaces that are going to exist in the future. I don't know. It's the interesting thing that I'm thinking a lot about. It's like where are we going here?

我大致把自己的思路分成两类：一类是我在生成一个需要查看的东西，另一类是我只是在完成一项需要做好的工作。并非所有事情都有视觉输出。所以我认为，对于那些只是完成工作的事情，它们只需要无限可配置并且为你服务就行，但归根结底，还是需要一个起点，这个起点仍然需要设计，这样你才能知道它能做什么。这里面有很多关于教导他人的内容。而在动态方面，我确实认为，让这些东西具有动态性正是它们如此强大的原因。它们应该如此，我们也应该拥抱它并感到自在。你定制的可能在于它的视觉语言，或者你之后用来编辑它的工具。

I kind of separate my school of thought in between I'm generating a thing that I need to look at and I'm just doing a job that needs to get done. Like not everything has a visual output to it. And so I think for the things that are just doing jobs that get done they just need to be infinitely configurable and work for you but at the end of the day there's a starting point and that still needs to be designed so you can know what it can do. Like there's a lot around like teaching people. And then on the dynamic side of things, I do think yeah, like having these be dynamic is what makes them so powerful. They should be and we should lean into it and be comfortable with it. And where you customize might be on like its visual language or the tool you use to edit it afterwards.

你认为在接下来的几个月里，我们整个行业还会面临哪些尚未被探索的设计挑战？随着我们与这些模型交互方式的改变，AI 又带来了哪些不同类型的问题？

Are there other unmapped design challenges that you think that we as an industry are going to be staring in the face in the coming months and like different types of problems that AI is kind of bringing to the forefront as the way that we interface with these models changes.

我认为一个很大的问题是：当你能构建一切时，是否一切都需要被构建？仅仅因为能构建、能成为一个功能，并不意味着它必须存在。这会带来很多产品臃肿，让产品变得非常复杂。极简设计有其地位，我不认为那就是解决方案。但就完整功能而言，事情可以比现在更简单一些。并非每个想法都是好的或必要的。有时候添加功能反而更糟。但因为现在构建起来感觉太容易了，每个人都在构建一切。所以这是一个需要认真对待的大问题——要有辨别力去决定是否值得构建。甚至不是值不值得构建（因为你可以直接构建），而是值不值得添加到你的产品中并发布。

I think a really big one that we're going to have to reckon with is when you can build everything should everything be built. Just because it can build and just because it can be a function doesn't mean it needs to be. It adds a lot of product bloat. It makes it very complex. Minimalist design had its place and I don't necessarily think that's the solution. But I think in terms of like full functionality, things can be a little bit simpler than they are right now. And not every idea is good or necessary. Sometimes adding it is worse. But because it feels so easy to build now. Everyone's building everything. So that's a big one that's reckoning through. Like having the discernment to decide if it's worth building or not. Not even worth building because you can just build it, but if it's worth adding to your product, I guess, and launching it.

好的。我想给这一切做个总结。我们聊了很多。这一切都是全新的，对吧？这场对话中有太多新东西，让我以最好的方式被拉伸。我认为这确实引发了很多存在主义问题，比如我未来的角色到底是什么？所以我很好奇，你对未来能够蓬勃发展的设计师的新形态有什么看法？我们谈到了能够辨别自己应该处于执行模式还是塑造模式的技能。你认为还有哪些其他因素会让最优秀的设计师在未来几年脱颖而出？

Okay. I kind of want to tie a bow on all this. Like we've covered a ton. It's just new, right? Like there's so much new in this conversation that it stretches me in all of the best ways. And I think it does produce a lot of these existential questions of like what the heck is my role moving forward, right? And so I'm curious if you have any thoughts around like what's the new shape of designer look like that's going to thrive in the future. We talked about this skill around being able to decipher between whether I should be in execution mode versus shaping mode. Are there other things that you think are going to separate the best of the best designers in the years to come?

我认为第一个技能组合是，在未来几年我们仍处于这项技术的涌现阶段时，保持非常开放的心态和好奇心非常有用。持有你的观点，发展它们，然后愿意放手并更新你对事物的看法。无论是你的角色还是你的产品，这一点都极其有帮助，因为一切都在动态变化。所以，其中之一就是让自己具备流动性，能够拥抱模糊性，保持好奇并享受其中，在混乱中找到起点并向前推进。我认为这是一个非常重要的技能，会对人们大有裨益。这很难，因为设计曾经非常结构化和流程化，你会很想紧紧抓住那些不放。但我鼓励人们做相反的事——拥抱混乱，开发新的工作方式，并持续更新。我认为这会对你有很大帮助。所以这是我们需要练习的一大技能组合。有点像放下你熟悉的僵化流程和角色，专注于构建好产品，你会找到自己的路。第二个技能，也许辨别力就是品味的另一种说法，我以后可能会打自己的脸。但我认为，辨别什么应该被构建、如何以最适合你的产品和表达意图的方式来构建、你在构建中应该扮演什么角色、工艺应该落在哪里，这些都是大问题。这实际上是当前核心的构建过程。比如，如果你识别出应该构建的东西或一个想法，你如何塑造它，让它从你的想象落地成为产品，然后知道何时放弃并说“这其实不好，别做了”。看到别人的东西，能说“这不太好，原因如下”，或者识别出真正有价值的东西，说“是的，这很棒，我们继续深入探讨吧。我们大概还需要两次大的塑造迭代，或者一次大的执行迭代就能达到目标”。这种对事物所处位置、如何契合以及是否值得追求的辨别力非常重要。第三个技能，我认为是对完成交付拥有完全的 ownership（主人翁意识），因为这个时代需要——第二个技能需要知道塑造和执行之间的区别，以及何时投入、什么才是好的。有时执行和打磨会在之后进行，有时在之前，有时在中间。拥有这个循环，教会你周围的同事如何做。提升整个组织，不仅仅是设计，还有你周围的每个人，这是设计的一个非常重要的角色。你需要感受到你对产品的责任，并且也要付诸行动。所以这三个技能组合、生活方式、观点，实际上正是我在团队招聘时所看重的，也是我亲眼看到人们真正成功的地方。

I'd say the first skill set is just in the next few years where we're still in the emergent phase of this technology. Being very open-minded and curious, I think is really useful. Like hold your opinions, develop them, and then be willing to let go and update how you think about things. Both what your role is, but also your product is extremely helpful because everything's very dynamic. So, one of them is just like having fluidity built into you and being able to lean into that ambiguity and be curious and enjoy it and like find a place to start and move forward in spite of the fact that it's chaotic. That's a really big one that I think will serve people extremely well. I think it's a hard one because design used to be so structured and processed that it feels like you really want to cling to that. But I'm urging people to do the opposite which is like lean into the chaos, develop new ways of working and like continuously update. And I think that will really serve you well. So that's a big skill set that I think we need to practice. Kind of like let go of the rigid processes and roles as you know it and just lean into building good products and you'll find your way. The second one I think is just maybe discernment is just another word for taste and I'm just going to like kick myself in the future. But I think discernment on what should be built, how to best build it in a way that suits your product and what you're trying to express and what role you should play in building it and where that craft should fall is like a big one. Like that's the core builder process right now. It's like if you identify a thing that should be built or an idea, how do you shape it in a way that it will land into your imagination from your imagination into a product and then knowing when to call it quits and be like that was actually bad. Let's not do it. Looking at someone else's and being like that's not great and these are the reasons why or identifying something that's really gold and be like yeah that's great. Let's keep riffing on it. We're like two big shape iterations away or like one big execution riff away from getting there. Like that discernment on where something is and how it fits in and whether or not to go after it is really important. And then the third one I think is like feeling full ownership over finishing the ship because this era requires like the second skill requires knowing the difference between the shaping and the execution and like when to lean in and what's good. Sometimes that execution and polish will come after, sometimes it'll come before, sometimes in between. And owning that loop, teaching your peers around you how to do it. Elevating your entire organization, not just design, but everyone around you is a really important role for design. And you need to feel your responsibility for that in the product. And you need to act on it as well. And so those three kind of skill sets, ways of life, outlooks are like specifically actually what I hire for on the team and specifically where I've seen people really succeed.

这很有趣。我觉得在我参与的很多对话中，都有一种拉力，好像我们不能只停留在多年来为自己画的那个传统设计框框里，对吧？所以你可能会被拉向更前端、更技术的方向，或者更偏向产品。表面上看，你在 Anthropic 工作，你在做模型，你甚至在设计一个 CLI（命令行界面），对吧？你会以为这种拉力是朝向所谓的“工程”方向。但你整场对话所说的每一句话，都像是一个产品策略专家，这就是你现在带来的价值。

It's interesting. I feel like in a lot of the conversations that I'm having each one there's like a pull like we can't just stay in like the traditional design box that we've drawn for ourselves over the years, right? So you're kind of pulled maybe more into front end and more technical or maybe more toward product and on the surface like you look at Anthropic and it's like well you're working on the models, you're designing a freaking CLI, right? Like you would expect the pull to be toward like quote unquote engineering, you know, but everything that you've said this entire conversation, like you were a product strategy expert, you know, like that's kind of what you're bringing to the table right now.

有时候，对于交付什么、打磨什么、摆弄像素这些事，会有点放手不管的感觉。就像你说的，我们建什么、不建什么，以及为什么？这几乎成了推动你职业生涯的核心技能锚点。我不知道你是否认同，但这确实是我过去一小时里听到的。

There's a slight at times hands-offness in terms of what is going out the door, the craft, the slinging pixels around, like it's very much so, like you said, what do we build, what do we not build, and why? And that kind of being almost like the anchor of the core set of skills that is propelling you in your career. I don't know if that resonates or not, but that's definitely like kind of what I've been hearing over the last hour.

完全同意。我觉得这可能是业内一些人开始讨论的：当我们都成为建造者时，我们实际上只是倾向于某些原型，拥有独特的技能尖峰，但我们的独特角色并没有改变。因为你刚才提到的技能，适用于那些非常侧重前端、追求高度精致的人。他们讨论的更多是在功能层面，或者非常垂直深入，而不是横向宽广。所以我仍然认为这些特质很重要。这取决于你处于产品的生命周期哪个阶段，以及你选择锚定什么。但我认为我希望所有设计师都能灵活应对高水平和低水平的工作。我认为这就是职业发展的方向。以前你只能专精其中一项，现在我认为你要均衡发展它们。我们扩展了希望你能够做好的技能集。

It absolutely does. And I think maybe this is something that a few folks in the industry have started talking about a little bit is like maybe as we all become builders, we actually just have archetypes that we lean into and like unique spikes of skill sets that we have, but our unique role doesn't change. Because I think the skill sets that you just mentioned, they apply to people who like lean really heavily into front end and have a high degree of polish. It's just like what they're talking about is more at a feature level or more like very vertically deep as opposed to horizontally broad. So I still think those characteristics are important. It just depends where you are in the life cycle of a product and what you choose to anchor on. But I think I would expect all designers to be able to flex into the higher and lower level. I think that's where the career is going. Before you could specialize only in one of these. Now I think the idea is that you're developing them equally. Like we've expanded the skill set that we want you to be able to do well.

说到好奇心是这个节目上反复出现的定义性特质，你确实给我和很多听众抛出了几个非常有趣的线索。所以，非常感谢你来做客，Meaghan。你正在迅速成为我在业内最喜欢的学习对象之一。我已经想说我们得再聊一次，不知道是什么时候，因为变化太快了。但是，呃，我真的很感谢你今天来分享你的想法和你正在构建的东西。

In terms of curiosity being the defining characteristic that comes up on this show, you've definitely dangled a few very interesting threads to pull on for me and I'm sure a bunch of people listening. So, I very much so appreciate you coming on, Meaghan. You were quickly becoming one of my favorite people in the industry to learn from. And I'm already going to say we're going to have to run this back on I don't know what the timeline is because things change too quickly. But, uh, I really appreciate you coming on today and sharing what you're thinking about and what you're building.

我很高兴。谢谢。我想补充一点，如果现在设计行业有一件事让我特别兴奋，并激励我出来与人交流、与你进行这些对话，那就是鼓励大家知道我们还在早期。我们现在都能塑造我们想要的东西。这就是令人兴奋的部分。所以参与这场讨论，尝试这些事情，形成自己的观点，就是现在的乐趣所在。我们应该一起做这件事。

I'm glad. I'm glad. Thanks. And I would add like if there's one thing that really excites me about the design industry right now and what motivates me to come out and speak with folks and to have these conversations with you is like to really encourage folks to know we're early. We are all able to shape what we want right now. Like that's the exciting part of it. So participating in this discourse, trying these things out, developing your own opinion is the fun part right now. We should all be doing it together.