设计未来：Brian Lovin 谈 AI、Notion 与角色融合

我认为这可能是当前设计师的一个好定位——真正理解什么是可能的，即使做得不好、卡住了，也要尝试推动边界。从那时起，它就彻底改变了你的工作方式。一旦你意识到这类东西有一半你没法在 Figma 里设计出来，你实际上在设计的，就是那个让智能体去执行更长期任务、并自我验证工作的“缰绳”。同样，如果一家做问题追踪或笔记的公司不照照镜子，认真思考自己未来的角色，那就太疯狂了。今天的设计师如果不做同样的事，也太疯狂了。我们对头衔的执念才会害死人。如果你在心里问：‘但我到底是设计师、产品经理还是工程师？’比如‘天哪，我该走哪条路？’不，不，不。这些东西正在消失。一切正在变得非常、非常模糊。在这些学科之间切换正变得非常容易。你要成为那种能在不同工作方式之间流畅切换的人，而不是纠结于‘那我在这家公司里属于什么框框？’对吧？

I think that's probably a good place to be right now as a designer—really understanding what's possible, trying to push the edges even if it sucks and you get stuck. From that moment on, it just changed the whole way you work. As soon as you realize you can't design half of this stuff in Figma, what you're really designing is the harness for the agent to do longer things and verify its own work. In the same way, it would be crazy for a company that did issue tracking or note taking to not take a hard look in the mirror and try to figure out their role in the future. It would be crazy for designers today to not be doing the same thing. Our obsession with titles is what will screw people over. If you're like, 'But am I a designer or a PM or an engineer?' Like, 'Oh my god, which path?' No, no, no. These things are going away. All of this stuff is getting very, very blurry. It's getting very, very easy to move between those disciplines. You want to be the kind of person that can move between those types of working very fluidly and not get caught up in, 'But what's my box? What's the box I'm in at this company?' Right?

欢迎收听 Dive Club。我是 Rid，这里的设计师永不停学。本期嘉宾是 Brian Lovin，他是我非常关注的对象——无论是他的工作方式，还是他使用的各种工具，我都会仔细留意。我们将深入探讨他的设计流程，以及他在“如何设计 AI”和“如何使用 AI 工具”这两个方面所做的各种迭代。但在聊这些之前，我想先了解一下 Brian 最初加入 Notion 设计团队时的经历。

Welcome to Dive Club. My name is Rid, and this is where designers never stop learning. Today's episode is with Brian Lovin, one of those people I pay very close attention to—both how he works and all of the tools he's using. We're about to do a deep dive into his design process and all of the ways he's iterating on both how he designs AI and how he uses AI tools. But before we get into all of that, I wanted to know what it was like when Brian first joined the design team at Notion.

有一个非常顺利的事情是，在我加入 Notion 之前，他们邀请我参加他们的设计聚会。当时我们正在谈加入的事，我觉得甚至还没正式敲定，或者说已经接近敲定了。他们在纽约举办了设计聚会，而我在纽约，所以我就去和团队待了一周。这很有帮助。对每个人来说可能都有点尴尬，因为他们会想：‘这个不在公司上班的家伙是谁？就突然出现了？我们能聊什么？’但大家也知道，‘嘿，Brian 要加入了。’所以我就直接融入了。大部分时间我坐在后面，吸收信息，看看每个人在做什么。那次聚会上我最喜欢的环节之一是在最后一天。他们租了一个共享办公空间，然后分成三到四人一组。每组抽两张纸条，每张纸条上写着一个功能名称。然后就像‘去设计一个结合这两个功能的东西。’你可能运气好，抽到 AI 加聊天；也可能运气差，抽到公式加权限。然后大家就各自去设计了，大概半小时到一小时。然后每个人展示自己的方案，质量让我震惊。我坐在那里，看到大家有高保真原型——非常出色的带动画的 Figma 可点击演示。每个人都很快地做出接近成品的素材，所以看起来特别真实。有些演示让大家都说‘哦，我们应该把这个做出来。’真的很棒。所以那是我对 Notion 设计团队的初印象。非常厉害，我非常兴奋。大家都很热情。整个氛围都很好。那是在 2024 年 10 月。然后我 2025 年 1 月加入。我一加入就被扔进了深水区。我的第一个项目内部叫‘App Builder’。我觉得这在业界已经不是秘密了。它非常复杂。就像‘Notion 已经拥有 AI 为你构建任何工作用工具所需的所有原语。我们有数据库、图表、视图、页面、AI 聊天。为什么不更进一步，让它写代码，生成你希望存在于 Notion 里的任何应用？’那是一个前四个月非常紧张的项目。有意思的是，我其实没有和太多人紧密合作——好吧，我和一位设计师紧密合作过，他后来在几个月后离开了。他知道我说的是谁。那是一段很棒的搭档关系。除此之外，我有点觉得和团队有些疏离。我们从来没有以那种形式发布过 App Builder，但我们将它拆开，分块发布了。所以后来我做的第一件大事是 Notion 智能体，那是其中一块。然后团队发布了自定义智能体，接着我们发布了 Workers，你可以写代码、部署并在 Notion 上托管 AI 智能体可以使用的代码。现在回头看那个最初的项目，看到所有部分都已经构建完成并在 Notion 内部运行，非常酷。我不知道这是否完全回答了你的问题，但我的入职真的很有趣。我觉得这里就是属于我的地方。头几个月非常紧张，最初的那个东西并没有真正成功。我不得不转向、调整，边做边学。现在一年过去了，一切都没有变——团队很棒，我对 Notion 的未来充满期待。这里的每个人都完全‘AI 中毒’了，这很有趣。

One thing that ended up working really well was that before I joined Notion, they invited me to their design offsite. When we were working on the deal, I don't think we'd even closed yet, or we were close to closing. They had their design offsite in New York, and I was in New York, so I just went and hung out with the team for a week. That was helpful. It was probably awkward for everyone, because they were like, 'Who the hell is this guy who doesn't work at this company and just shows up? What are we allowed to talk about?' But it was like, 'Hey, Brian's going to join.' So I just jammed. Mostly I sat back, absorbed, and saw what everyone was working on. One of my favorite sessions at the offsite was on the last day. They'd rented this co-working space, and they broke into teams of three or four people. Each team drew two pieces of paper, and each paper had the name of a feature. It was like, 'Go design something that combines these two features.' You might get lucky and draw AI plus chat, or you could get unlucky and draw formulas plus permissions. Everyone went off and designed for maybe half an hour or an hour. Then everyone presented their ideas, and the quality blew my mind. I'm sitting there, and people had high-fidelity prototypes—really impressive Figma click-throughs with animations. Everyone was very quick at pulling together production assets, so it felt very realistic. Some of the demos made everyone say, 'Oh yeah, we should ship that.' Really cool. So that was my first experience with the Notion design team. It was impressive, and I felt excited. Everyone was very welcoming. Good vibes all around. That was in October 2024. Then I joined in January 2025. I got thrown into the deep end. My first project was internally called 'App Builder.' I don't think there are any secrets here. It was very complicated. It was like, 'Notion has all the primitives we need for AI to build any kind of tool you might use at work. We have databases, charts, views, pages, AI chat. Why not take the next step and let it write code to generate any sort of app you might want to live inside Notion?' That was a really intense project for the first four months. It was funny because I actually didn't work that closely with anyone—well, I worked closely with one designer who ended up leaving a few months in. He'll know who he is. That was an awesome partnership. Otherwise, I felt a little isolated from the team. We never shipped App Builder in that exact form, but we did split it apart and ship it in chunks. The first big thing I worked on was Notion Agent, which was one slice of that. Then the team shipped custom agents, and then we shipped Workers, where you can write code, deploy, and host code on Notion that AI agents can use. It's cool now, looking back at that initial project, to see all the parts have been built and are working inside Notion. I don't know if that exactly answered your question, but I just had a really fun onboarding. I felt like this was the place for me. The first few months were intense, and the first thing didn't really work. I had to pivot, adjust, and learn on the fly. Here we are a year later, and nothing has changed—the team is awesome, and I'm very excited about Notion's place in the future. Everyone here is sufficiently 'AI-pilled,' and that's fun.

插播一条快讯，然后我们继续。Jitter 刚刚发布了图生视频功能，这相当重磅。你只需要上传一张素材，Jitter 就会借助 AI 立即生成一段短视频。这是一种给静态背景增加动感和层次感的简单方式，也许还能为品牌视觉制作小片段，或者只是让任何场景通过细微的运动显得更生动。它非常好玩，今天就可以使用了。只要访问 dive.club/jitter 就能体验。如果你和我一样，最近经常用代码做原型，那你会面临一个选择：要么用一个和你的实际代码库、设计系统没有连接的工具，要么用一个很难分享的本地主机原型。所以我非常喜欢 Dessen 正在做的事。一键点击，你和团队中的每个人都可以直接在代码库中制作原型，甚至不需要打开 IDE。Dessen 会提取你的设计语言，并给你一个完美的沙盒去探索，而没有任何技术障碍。

Real quick message, and then we can jump back into it. Jitter just released image to video, and it's a pretty big deal. All you have to do is upload an asset, and Jitter will instantly generate a short video clip from it with the help of AI. It's an easy way to add motion and depth to static backgrounds, maybe create little clips for brand visuals, or just in general make any scene feel more alive with subtle movement. It's super fun to play with and available today. Just head to dive.club/jitter to try it out. If you're like me, then you're prototyping a lot in code lately. But the problem is you kind of have this choice between a tool that isn't hooked up to your actual codebase and design system, or a localhost prototype that's super annoying to share. That's why I love what Dessen is doing. In one click, you and everyone on your team can prototype directly in your codebase without ever opening an IDE. Dessen extracts your design language and gives you the perfect sandbox to explore without any of the technical hurdles.

当你准备好之后，右上角有一个很好用的分享按钮，你可以把它发送给团队中的任何人。这真的很重要。你可以连接你的代码库并立即开始制作原型。只需访问 dive.club/dessen。拼写是 d e s s n。现在，进入本期节目。

And when you're ready, there's a nice little share button in the top right, and you can send it to anybody on your team. It's a pretty big deal. You can connect your codebase and start prototyping today. Just head to dive.club/dessen. That's d e s s n. Now on to the episode.

作为一名设计师，你的工作领域几乎完全围绕着把 AI 当作一种材料来塑造，这种感觉是怎样的？

What's it like being a designer whose surface area pretty much entirely revolves around working within shaping AI as a material?

我 1 月加入时，从来没有接触过 AI。事实上，当我加入 Notion 时，我对 AI 相当怀疑。我记得我们在收尾 Campsite——也就是之前的创业公司——的时候，光标补全已经变得不错了，这算是给你一个参照系。我们还没有编码智能体。我觉得那是在 Claude 3.5 模型之前。我当时觉得这一切都有点……我就想，‘它做出的东西没有什么是好的。’但那些真正关注的人并不在乎当前的质量。他们在乎的是轨迹，以及它变好的速度。所以我就在那年 1 月加入了。App Builder（应用构建器）之所以真的很难——可能我也犯了一百万个错误——其中一个原因是，我把它当作一个典型的设计项目来对待。比如说，‘好，我们要建一个界面，用户可以用 AI 来构建体验，我要打开 Figma 来设计这个。’我当时在设计聊天体验：‘好的，用户会要求一个做这个的应用。’然后智能体回应，并展示一个小预览，看起来会很完美。然后我们真的和那些构建它的工程师一起测试，结果根本不是那样。模型没有那么好。它非常慢。它们会出错。它们不得不问澄清性的问题。

When I joined in January, I had never touched AI. In fact, when I joined Notion, I was pretty skeptical of AI. I remember when we were finishing up Campsite — the startup before — cursor tab completion was getting good, just to put a frame of reference. We didn't have coding agents. I think this was pre-Claude 3.5 models. And I just thought it was all… I was like, “Nothing it makes is good.” But the people who were paying attention weren't concerned about the current quality. They were concerned about the trajectory and how fast it was getting better. So I joined that January. One of the reasons App Builder was actually hard — and probably I just made a million mistakes — was that I approached it like a typical design project. Like, “Cool, we're going to build this interface where users can construct experiences with AI, and I'm going to open Figma and design this.” I was designing chat experiences: “Okay, the user will ask for an app that does this.” Then the agent responds and shows a little preview of what it's making, and it's going to be perfect. Then we would test that with the engineers who actually build it, and it just doesn't work that way. The models weren't that good. It was very slow. They would make mistakes. They would have to ask clarifying questions.

于是，到了某个时刻——大概在 2 月，也许我刚加入一个月——感觉就是，‘这根本行不通。我不能继续做 Figma 模拟图，去试着想象使用 AI 来构建 AI 相关东西的真实体验。’所以那时我就说，‘好吧，我必须跳进这个媒介里。’那就是我开始做这个内部工具 prototype playground 的时候。那里的目标是：‘我只需要一个可以和 AI 对话的媒介，去理解它回应时的感觉。我要测试所有模型。有些 AI SDK，比如 Vercel 的，相当擅长帮你执行工具、返回结构化输出。你可以开始模拟拥有一个 Notion 形态的东西会是什么样，但完全是在一个隔离的代码库里。’从那一刻起，它彻底改变了你工作的方式。一旦你意识到有一半的东西无法在 Figma 里设计，你真正设计的就是让智能体去完成更长久任务并验证自身工作的那个“套件”（harness）。这在很大程度上意味着你在日常工作中使用 AI，去感受它。然后另一部分是和真正构建这个套件的工程师聊天，问他们：‘为什么这很慢？为什么这变差了？为什么这个模型比那个好？’幸运的是，我们有非常非常优秀的工程师在维护我们的套件，我就试着向他们学习，吸收他们的头脑。他们都真的在下一代模型上，我试着把那些吸收进我的设计流程。

And so, there was this moment — probably in February, maybe I'd been a month in — where it was like, “None of this is working. I can't keep making Figma mocks to try and simulate what it's actually going to be like to use AI to build AI things.” So that's when I said, “All right, I just have to jump into the medium.” That was when I started working on this internal tool, prototype playground. The goal there was: “I just need a medium where I can talk to AI and understand what it feels like to have it respond. I'm going to test all the models. Some of the AI SDKs, like from Vercel, were pretty good at helping you execute tools and return structured outputs. You could start to simulate what it would be like to have a Notion-shaped thing, but in a totally isolated code base.” From that moment on, it changed the whole way you work. As soon as you realize you can't design half of this stuff in Figma, what you're really designing is the harness for the agent to do longer things and verify its own work. A lot of that means using AI in your day-to-day work and getting a feel for it. And then the other part is talking to the engineers who are actually building the harness and asking, “Why is this slow? Why did this get worse? Why is this model better than the other model?” Luckily for us, we have really, really good engineers working on our harness, and I just try to learn from them and absorb their brains. They're all really on the next generation of models, and I try to absorb that into my design process.

我认为设计师现在需要在设计的地方，就是当前模型的边界上，期望下一个模型能解决它，对吧？我们都在发布糟糕的、用 vibe coding 搞出来的东西，只是希望，‘啊，下一个模型肯定会把这个收拾干净。’我觉得现在作为设计师，这大概是一个好位置：真正理解什么是可能的，即使很烂、卡住了也要尝试去推边界，然后尽可能和更多聪明人交流。显然，在 Notion 这样密度很高、还有线下交流日可以互相学习的地方工作，非常有利。

I think where designers need to be designing right now is right at the boundary of the current model, hoping that the next one solves it, right? We're all shipping shitty vibe-coded slop, just hoping, “Ah, the next model is definitely going to clean this up.” And I think that's probably a good place to be as a designer right now: really understanding what's possible, trying to push the edges even if it sucks and you get stuck, and then talking to as many smart people as you can. Obviously, working at a place like Notion is very advantageous just because there's a density of people and we have in-person days to learn from each other.

我们在做 Inflight 的声音模型时就是这么干的。我们花了整整一个月尝试各种不同的交互模式，来探索以近乎被采访的方式提供反馈是什么样子，而且很明显它有潜力。但它确实很不好。就像，‘好吧，我们先把这个搁置。那里有点东西，但我想我们只能等模型变得更好。’而且感觉这种思路目前几乎在所有方向上都有，尤其是当你在推进更前沿的工作时。

We did that with the voice models working on Inflight. We spent a good month trying all of these different interaction patterns for what it looks like to almost be interviewed as a way to give feedback, and it was clear that it could be good. But most definitely was not good. It was kind of like, “All right, we're going to put a pin in that. There's something there, but I guess we'll just wait until the models get better.” And it kind of feels like that line of thinking exists in almost every direction at the moment, especially if you're pushing more frontier work.

我认为真正在深度使用这些工具的人，从定义上讲，就是早期采用者。大众在用 ChatGPT 问一些相当基础的问题，但如果你现在真的想用 AI 来自动化知识工作、简化你的工作，或者在你公司里去掉某个流程，那你就是非常早期的采用者。而这些人对低于水准的体验的容忍度其实相当高。我觉得人们仍然愿意爬过碎玻璃去配一个 OpenClaw，对吧？那不是一件容易的事，但人们正在这么做。所以我觉得其实没关系。这有点奇怪，因为你必须重新调整自己心中质量标准。就像，‘我知道这个东西并不完美，但使用它的人对这些不完美非常包容，并且愿意一遍又一遍地试错他们自己的提示词。’

I think the people who are really engaging with these tools are, by definition, early adopters. There are the masses using ChatGPT to ask fairly basic questions, but if you're really trying to use AI right now to automate knowledge work, simplify your job, or remove a process at your company, you're a very early adopter. The tolerance for those people for sub-par experiences is actually quite high. I think people are still willing to crawl over glass to set up an OpenClaw. That is not an easy thing, and people are doing it. So I think that's actually okay. It has been weird because you have to readjust your expectations for your own quality bar. It's like, “I know this thing isn't perfect, but the people using it are very tolerant of those imperfections and are willing to trial-and-error their own prompts over and over again.”

我在 Notion 看到的重要事情之一——我想可能每家公司的每一位设计师现在都在经历——就是每 6 个月，我们之前做的一切或多或少都会过时。在 Notion，我觉得自从我加入以来，我们已经把智能体套件重写了 3 次，大约每 6 个月一次。每一次都是把过去所有旧假设剥掉。今天我们设计套件时，大致是这样的：给你的智能体写脚本和搜索的能力。现在要写出一个好套件，差不多就只需要这些。但我的假设是，6 个月后就不再是这样了。我不知道。技能（skills）在 6 个月后还会有用吗？我们还需要所有这些东西吗——‘你是一名提示词工程师，你是一名资深工程师，负责……’——是啊，就是这样。我不知道 6 个月后我们是否还需要这些。

One of the important things I got to see at Notion — and I think probably every designer at every company is experiencing this right now — is that every six months, everything we did before becomes more or less irrelevant. At Notion, we've rewritten the agent harness, I think, three times since I joined, roughly every six months. Each time, it's just stripping away all these old assumptions. Today we're designing around harnesses that are roughly like: give your agent the ability to write scripts and search for things. That's pretty much all you need to write a good harness right now. But I'm operating under the assumption that that won't be true in six months. I don't know. Are skills going to be useful in six months? Are we going to need all of this stuff — “You are a prompt engineer, you are a senior engineer at…” — yeah, exactly. I don't know if we need all of that stuff in six months.

所以，我已经有点习惯了它会不断变化这件事。我的工作是理解正在发生什么、为什么会发生、为什么它擅长写代码，以及这些意味着什么。好吧，它需要一个安全的空间来执行那些代码。于是你环顾四周，每个人都在启动沙盒。沙盒运行很慢，那就让它们变快，对吧？所有这些事情都是智能体执行框架变化的直接后果，过去几年里它每六个月就变一次，我估计这种节奏还会继续。

So, I've found a little bit of inner peace with the fact that it's just going to keep changing. My job is to understand what's happening, why it's happening, why it's good at writing code, and what the implications are. Okay, it needs a safe space to execute that code. So you look around, everyone's spinning up sandboxes. Sandboxes are slow, so let's make them faster, right? All these things are downstream consequences of the agent harness changing, and it's changed every six months for the last couple of years. I assume that will continue.

关于你搭建的原型试验场，我想问一个澄清性的问题。我见过一点，但请你帮我弄清楚它处于这个光谱的什么位置。一端是全新、可爱、没有任何上下文的构建，另一端是你在最近还在更新的代码库的完美复制。那么它到底在哪个位置？因为我觉得那种保真度并不常见。我猜它大概在中间某个位置。跟我聊聊这个吧。

Clarifying question on the prototyping playground you built. I've seen a little bit, but help me figure out where it exists on this spectrum. On one end, it's a fresh, lovable build with no context. On the other, it's a perfect copy of the code base that you're updating somewhat recently. Where does that exist? Because I think that level of fidelity is something I don't see that often. I'm assuming it's somewhere in the middle. Talk to me about that for a second.

这取决于原型。它就是一个很大的原型目录，我们有一套接近 Notion 的组件套件。如果我们多花点时间，它可以做到完美，但我们尝试的是二八原则——做到非常接近就行。我们有看起来像 Notion 侧边栏的侧边栏、看起来像 Notion 的按钮和下拉菜单。然后由每个设计师自己决定要把原型推到多深入，以证明他们的设计观点。所以我才说“看情况”。比如，我们有一位叫 Will Dawson 的设计师，他一直在做编辑器相关的工作，还有在 Notion 页面里可以用的一些内联 AI 功能。想要真切感受边输入、边选文本、边用键盘导航时与 AI 互动的体验，唯一的办法就是真正置身于一个编辑器里。所以在原型试验场里，他近乎重新打造了一个简化版的 Notion 编辑器，带有斜杠命令和内联 AI。AI 会做真实的事情——写回内容、实时更新页面、选中对象。保真度非常高，你要是盯着看，会以为“这就是 Notion”。但它其实不是。你必须推到那个程度，才能真正证明这个想法是好的。总之，回到你的问题，它是很宽泛的范围。我们尽量提供一些组件，让设计师能快速上手，但每个人都可以按照自己的意愿往深处推。以后会怎样我不知道，但我觉得会发生两件事。一是我们会继续改进原型试验场里的那些组件，让它们默认看起来越来越好；二是我也看到越来越多的设计师直接跳过原型试验场，直接在生产代码库里迭代和做设计。这对你做的事情来说不一定每次都合适，但在越来越多的情况下，直接启动 Notion 的代码库、把 Claude 扔到同样的问题上，反正你也要花差不多的时间，不如就直接得到一个真实的东西。

It depends on the prototype. It's a big directory of prototypes, and we have a component kit that's close to Notion. It could be perfect if we spent more time on it, but we've tried to do the 80/20 thing — get it pretty close. We have a sidebar that looks like the Notion sidebar, buttons and drop-downs that look like Notion's. Then it's up to each designer to push it as far as needed to prove the point of their prototypes. That's why I say it depends. For example, we have a designer named Will Dawson who's been working on the editor and some of the inline AI features you can use while working on a Notion page. The only way to really feel what it's like to interact with AI while typing, selecting text, and navigating with your keyboard is to actually be in an editor. So in the prototype playground, he more or less recreated a simplified version of the Notion editor with slash commands and inline AI. The AI does real things — writes back, updates the page in real time, selects stuff. It's very high fidelity. If you stare at it, you'd think, 'This is Notion.' And it's not. You have to push it that far to really prove the idea is good. Anyway, to answer your question, it's a wide range. We try to give components so people can get close enough, but each designer can push as far as they want. Over time, I don't know what will happen. I think two things will happen. One, we'll keep improving those components in the playground so they look better by default. Two, I've seen more and more designers just skip the playground and iterate directly in the production code base. It's not appropriate for every kind of thing you're working on, but there are an increasing number of cases where it works well to just boot up the Notion code base, throw Claude at the exact same problem, and you might as well get a real thing out of it if you're going to spend roughly the same amount of time anyway.

Notion 设计团队里有多少人真的在生产环境里写代码？主要还是用 Figma 工作，这还能接受吗？跟我们说说。

How much of the Notion design team is actually touching prod, working in code? Is it still acceptable to be doing predominantly Figma work? Talk to us.

我觉得完全没问题，具体要看你在做什么。但我想说，尝试用代码做点东西的门槛已经低到我觉得每个人都试过一下。

I think it's totally fine, depending on what you're working on. But I'd say the barrier to entry for trying something in code is so low that I think everybody has dabbled.

有多少比例的人会直接上生产环境？

What percentage of people go straight to prod?

我不确定。大概 10% 到 20%，而且这仍然要看具体任务。Figma 里仍然有大量工作。现在有很多人在纸上涂涂画画。我不知道。我觉得我周围都是同类人——我们都在折腾、尝试新东西。但我认为核心还是“为工作选对工具”。对某些设计工作来说，在 2D 画布上截个图，在上面勾勾画画，然后说“嗯，我觉得这个大致没问题”会更有帮助。而另一边则是“不行，我需要这个产品在生产环境里的最高保真版本”。我们推动 Notion 的工程团队让 Notion 的代码库对 AI 更易读。大量幕后的工作——我猜大多数公司都在做——就是如何让没有工程背景的人也能做这类事情，让他们用 AI 写出来的代码不辣鸡、不搞挂服务、测试正确、评审正确。那很大程度上就是代码库基础设施的工作，从技能文件到真正的 CI 流水线，确保那些小错误不会漏过去。随着公司把越来越多的精力投到那里，我觉得我们都会沿着这个梯度不断地爬，越来越倾向于直接在生产环境里做尝试。但永远都会有一些实验性的、让人困惑的点子，最好还是在餐巾纸、白板或者 Figma 上画几个方块就完了。实际上，现在很多人直接打开 TLDraw 画方块。

I'm not sure. Maybe 10 to 20%, and it's still task-specific. There's still a lot of work in Figma. A lot of people are playing with paper now. I don't know. I feel like I'm surrounded by my people — we're all tinkering and trying new things. But it's still about picking the right tool for the job. For some types of design work, it's more helpful to be on a 2D canvas, taking screenshots and masking over them, and saying, 'Ah, I think this looks roughly right.' On the other side, 'No, I need the highest fidelity version in a production environment.' We push the engineering team at Notion to make the Notion code base more legible to AI. A lot of under-the-hood work — and I assume this is happening at most companies — is about enabling this kind of work for people without engineering backgrounds, so the code they write with AI isn't shitty, doesn't break the service, is tested correctly, and gets reviewed correctly. That's largely code base infrastructure. Everything from skill files to the actual CI pipeline to make sure silly things don't slip through. As the company funnels more energy there, I feel we'll all keep climbing this gradient toward trying things in prod more often than not. But there will always be experimental, confusing ideas where it's better to sketch on a napkin, a whiteboard, or open Figma and draw rectangles. Actually, a lot of people now just open TLDraw and draw squares.

随着你们沿着这个梯度前进，这如何改变你们的协作和工作方式？原本作为设计流程主力的那些部分发生了哪些变化？媒介在多大程度上改变了 Notion 内部的协作？

As you move along this gradient, how does that change the way you collaborate and work together? What parts of the design process that were previously staples have changed? How much does the medium change collaboration at Notion?

我觉得就是从一个“嘿，看看这个 Figma 链接”变成“嘿，看看这个部署预览”。就这么简单。我们共同指向、一起尝试的那个东西从一类 URL 换到了另一类 URL。那是个很大的变化。原型试验场很棒，因为大家就是同一个代码库。你可以去翻别人的东西，从其他人的原型里偷学到一些很酷的交互，或者直接复制一份然后在此基础上即兴发挥。这种互动方式很值得一看。不过，我也说不好，我们仍然会开设计评审会。我们出现在会议室里，有人讲讲他想解决的问题，也许我们彼此分享的是另一个形态的 URL。

I think it just moves from 'Hey, check out this Figma URL' to 'Hey, check out this deploy preview.' It's that simple. The artifact we point at together and try together moves from one domain to another. That's a big change. The prototype playground has been cool because it's all one code base. You can browse other people's stuff, steal cool interactions from other prototypes, or duplicate theirs and riff on it. That kind of interaction has been great. But I don't know, we still have design crits. We show up in a meeting room, someone talks about the problem they're trying to solve, and maybe we share a different URL with each other.

这个问题其实有点钻牛角尖，但当我回想大约六个月前自己期待的工作流会是什么样——那种展望未来的心态——我本以为我会做大量快速的代码功能原型，然后在画布上死磕细节、微调所有视觉效果。结果我发现实际情况恰恰相反。

It's kind of an in-the-weeds question, but when I think about what I expected my workflow to be like six months ago — looking into the future — I assumed I'd be doing a bunch of quick functional prototyping in code and then really sweating the details on the canvas, fine-tuning all the visuals. And I found it's actually the complete opposite.

我在做大量横向探索的地方——就像你提到的 Paper——其实是借助 Paper 里的 Conductor。但当我想死磕细节时，我全都在代码里做。我好几个月没在画布上挪像素了——其实我很长时间没在 Figma 里挪过像素了。让人沮丧的是，AI 在最后一公里的打磨上依然很差。我觉得有两条路可以走。一条是你说的：直接进代码里去改 CSS，因为说到底那是你要上线的产物，那才是唯一重要的。而在这方面，我觉得 AI 很烂。哪怕是领先的模型，你让它们深度思考，它们在视觉交互设计上依然很糟。有些观众会说这是技艺问题，我可以接受，但说实话，我做了这么多年，我也没法让它做出好东西。所以在最后一公里，你还是得在编码工具、IDE 里做；或者如果你真的疯了、不在乎自己的时间，你也可以不断 prompt 去磨出一个成品。就有人会 prompt 说：“把那个元素往左挪 4 个像素。”我就想说：“别。你干嘛花钱在代码里挪东西？直接去改 class 不就行了。”别那么干。所以，这是一种做法。另一种做法，挺有意思的，是在 Figma 里建立更高保真的体系，然后祈祷 MCP 工具越来越好。Figma 的 MCP 我觉得确实在变好。我上次用的时候，Figma 里有个设计，图层都命名好了，所有组件的命名和代码库里的大致一致。我把 Figma 帧的 URL 粘到 Claude Code 里，它就能在另一端生成一个相当不错的结果。这点很酷。

Where I'm doing a lot of my go-wide explorations, like you mentioned Paper, is actually through Conductor in Paper. But when I want to sweat the details, I do it all in code. I haven't really nudged pixels on a canvas in months—I haven't nudged pixels in Figma in a long time. The frustrating thing is that AI is still terrible at last-mile fit and finish. I think there are two ways to go about it. One is what you're describing: you just get into code and touch the CSS, because at the end of the day that's what you're going to ship, and that's all that matters. And for that, I think AI sucks. Even the leading models, you can make them ultra-think, and they're just bad at visual interaction design. Some people watching will say skill issue, which I can accept, but I don't know. I've been doing this for a while, and I can't get it to do good things. So you do the last mile inside a coding tool, an IDE—or if you're really crazy and don't value your time, you prompt your way to a polished thing. There are people prompting, 'Nudge that element four pixels to the left.' I'm like, 'Don't. Why are you spending money to nudge something in code? Just go change the class.' Don't do that. So that's one way. The other way, funny enough, is to have a higher-fidelity system inside Figma and just cross your fingers that the MCP tools are getting better. Figma's MCP, I think, actually is getting better. Last time I used it, I had a design in Figma with named layers, and all the components were roughly named the same as they are in the codebase. I can paste a URL of a Figma frame into Claude Code, and it spits out a pretty damn good thing on the other side. That's cool.

所以我们现在绕了一大圈，进入了一个有趣的世界：事实证明，只要你把图层命名好，模型就能大概猜出你想做什么。我看到有的团队同时在这两头下功夫：投入资源完善 Figma 侧，投入资源设计命名规范，让你的设计对 AI 更可读。而另一头，这些东西最终显然还是得落到代码里。我觉得说白了，就是要深入进去，碰那些像素，把按钮的体验调好。一旦按钮的手感对了，AI 就知道怎么复用它。所以是的，我觉得这才是关键。因为人们说 AI 做设计很烂，我会说：你说得完全对。但如果你肯花时间——

And so we've gone full circle into this funny world where, yeah, it turns out if you name your layers, the model can kind of figure out what you're trying to do. I see teams approaching that from both sides: invest in the Figma side, invest in whatever naming scheme structure will make your designs more legible to AI. And then on the other side, obviously that has to end up in code at some point. And I think honestly that's just about getting in there and touching pixels and making buttons feel good. And once the button feels good, then the AI knows how to reuse it. So yeah, I think that's actually the key. Because people talk about how AI is really bad at design, and I'm like, you're totally right. But if you spend the time—

哎，这个点我没想到，老兄。就是说，如果你真的一次性在一套好的原组件上死磕细节，AI 不仅能很好地复用，还能做外推。我会说：“嘿，我很喜欢这个三级按钮，但我现在要用在这张卡片上，高度会大很多，不会产生太明显的效果。”那我就直接取那个大概的思路，然后外推。天哪，我这么做得到的成果真的非常好。

Yo, I missed that one, man. Like, if you spend the time really, really, really sweating the details on a good set of primitives once, AI is so good at not only reusing, but also extrapolating. I might say, 'Hey, I really like this tertiary button, but I'm using it on this card and the height is much bigger. It's not going to be a noticeable effect.' So I just take that general idea and extrapolate it. Oh man, I've been getting such good results from that.

还有一件事我很好奇：你到底用不用 Agentation？

The other thing I'm curious if you're using at all: do you use Agentation?

我试玩过。它就是我对付“挪像素”的解药。我觉得 Agentation 很厉害，但我用得还不多。我愿意说“把这个往左挪 4 个像素”，只要我能把这句话和另外六条类似的 prompt 打包起来，然后一次性执行。之后我就会在 Conductor 里开一个新标签页。所以做视觉打磨的时候，我可能会在 Conductor 里开五个标签页，同时跑四五条不同的 prompt。至少我说服自己这样更快。但也许我只是……我不知道。我大概已经不再打开 CSS 了。说不清。

I've played with it. That's my antidote to the nudging. I think Agentation is awesome, but I haven't used it very much. I'm okay saying 'nudge this four pixels to the left' if I can bundle that with like six other prompts like that and then do it all at once. Then I'll just spin up a new tab in Conductor. So I might have five tabs in Conductor all doing four or five different prompts simultaneously while I'm doing more visual refinements. At least I convince myself it's faster. But maybe I'm also just—I don't know. I don't open the CSS anymore, I guess. I don't know.

你知道，有些研究显示，人们自我报告说用 AI 后效率大幅提高，但从客观测量标准看，我们的效率其实更低了。对这种说法的反驳是：如果你在更短的时间里完成同样数量的任务，那没问题。可现实似乎是，更多人同时在相同时间里做更多任务，但质量更低。于是我们就处在这样一个奇怪的区间：对，你能做更多的事，但每件事都需要更多的后续跟进和修补。这让你总体上感觉自己更有产出。我不太确定。但 Agentation——我指的是它和那类工具的核心，对吧？Josh Puckett 做的另一个是什么来着？哦，Dial Kit。所有这些东西，对吧？我们只是需要把我们的意图变得对 AI 可读。而你的意图——或者说意图的保真度——如果你能说“这个在这个位置、带这个 ID 的 React 组件应该长这样”，那保真度要比非得在屏幕上视觉化描述某个东西高得多。当然，AI 知道事物的名字、底层组件或所在文件时，执行操作会更好。所以所有这些工具，核心就是让你的意图可读。而这类东西一直在变，对吧？Agentation 大概一个月前才出来，现在 Chrome 已经把类似能力内置进去了。现在任何智能体都能使用任何浏览器。这东西变化太快了，但全都为了同一个目标：智能体可读性。

You know, there are studies where people self-report being way more productive with AI, but objectively, on a measured basis, we're less productive. And the counter to that argument is: it's okay if you're accomplishing the same number of tasks in less time. But it seems like more people are accomplishing more tasks at a lower quality in the same time. So we're in this weird zone where it's like, 'Yeah, you can do more. Each thing needs more follow-up and fixes.' And that makes you feel more productive overall. I'm not totally sure. But Agentation—I mean, the whole point of that and tools like that, right? Like what's the other one that Josh Puckett's making? Oh, Dial Kit. All these things, right? We just need to make our intent legible to AI. And your intent—or the fidelity of that intent—is much higher if you can say, 'This React component in this position with this ID should look like this,' instead of having to describe visually something on the screen. Of course the AI will be better at performing operations when it knows the name of the thing, or the underlying component, or knows what file it's in. So all of those tools are about making your intent legible. And that's the kind of stuff that's changing all the time, right? Agentation came out like a month ago, and now Chrome has all that stuff built into Chrome. Any agent can use any browser now. This stuff is changing so fast, but all in the pursuit of agent legibility.

说到事情变化这么快，你能带我们回顾一下，过去 3 到 6 个月里，你的工具栈有哪些关键演变吗？

On the topic of things changing so fast, can you walk us through some of the key evolutions of your tool stack over the last three to six months?

我们正处在一个很有意思的时代：人们对自己用的工具非常有派系感。有人用 Claude Code，有人用 Codex，有人用 Cursor。每个人都觉得别人很蠢，或者试图证明自己的东西更好。然后还会陷入非常细枝末节的争论，比如“Claude 更擅长创意规划，Codex 更擅长执行具体指令”。这些说法可能都有道理。所以对我来说，这意味着我就是想把所有东西都试一遍，尽量不站队。我总体上更偏好 Claude 生态，但——好吧，回答你的问题：去年我用了很多 Cursor。后来我不用 Cursor 了，改用终端里的 Claude Code；再后来从终端里的 Claude Code 切换到 Conductor。对我来说，Conductor 是一个完美的中间地带：我既能看代码，又能多任务处理，而且大多数时候只是在聊天。但后来，你知道，Cursor 很快推出了 Composer 2。

We're in this really funny timeline where people are tribal about the tools they use. You have people who use Claude Code, people who use Codex, people who use Cursor. And everyone kind of thinks the other people are dumb, or they try to justify why their thing is better. Then you get into very, very niche arguments like, 'Well, Claude is better at creative planning and Codex is better at following specific instructions.' All these things might be true. So for me, that means I just want to try all the stuff and try not to be tribal. I generally prefer the Claude ecosystem, but—well, to answer your question, I was using Cursor a lot last year. I stopped using Cursor in favor of Claude Code in the terminal, then switched from Claude Code in the terminal to Conductor. Conductor to me was like the perfect middle ground: I can see the code, but I can multitask and I'm mostly just chatting. But then, you know, Cursor comes out with Composer 2 fast.

我当时就心想：‘好，那去试试吧。’你打开 Composer 2 Fast，它相当好用，速度也快，而且我能看到代码，还能同时调整。就像：‘哦，这就是我用来做前端像素级打磨的工具。’我不想坐在那儿干等 Opus 改圆角半径，然后又得从终端切到浏览器。这些我都不想要。Cursor 其实很适合干这个。所以现在我谁也不偏袒，就看哪个工具最适合当下的工作。如果是在公司，我能享受无限免费 token；如果是个人项目，我就尽量优化每秒 token 数，或者某种智能性价比，对吧？我还订了 Claude Max，200 美元那档。所以我就想：‘唉，我总得把这钱花出值来。’于是我就偏向在 Conductor 里用 Claude。

And I’m like, ‘Okay, let’s go try it out.’ And you open Composer 2 Fast, and it’s pretty good, and it’s fast, and I get to look at the code and I can tweak it at the same time. Like, ‘Oh, this is the perfect tool for me to do front-end pixel polishing type work.’ I don’t want to be sitting around waiting for Opus to change the corner radius of things and then have to switch from the terminal to a browser. I don’t want any of that. Cursor is actually a really good tool for that. So right now I have no allegiance. I just pick the best thing for the job. And if it’s at work, I get to benefit from unlimited free tokens. And if it’s personal, I just try to optimize for tokens per second or some ratio of intelligence, right? And I pay for the Claude Max subscription, the $200 one. So I’m like, ‘Ah, I kind of want to get my money out of that thing.’ So I bias towards Claude in Conductor.

除了速度之外，核心价值主张是什么？我明白 Cursor 的优势在速度，但你现在选择它，是因为你会亲自上手写代码，就像手写那种非常原始的 CSS 吗？

Is the primary value prop other than speed? Like, I get the speed thing with Cursor, but is that becoming your choice because you are actively getting in and writing, like handwriting caveman-style CSS?

过去两周我手写的代码比过去四个月还多。现在的潮流——如果你像我一样经常刷 Twitter 的话——是没人再写代码了。你在说什么？碰代码？那是 2025 年的事了。而我却还在写。我也会用智能体去 YOLO 式地合并 PR，尤其是在原型开发环境里。我经常不检查代码就直接 YOLO，也不需要去看代码。但我觉得这些模型的能力还不够强，如果你真的在乎最终交付物的质量，那你还是得看代码。我最近恰好在做一些事情，我真的非常在意最终的效果和打磨。所以没错，我正打开编辑器，像 2023、2024 年那样写代码，这种感觉挺好的。因为现在我可以顺手调用旁边那个很快或很聪明的模型，帮我把中间那些烦人的部分处理掉。我认为现在是一个不该偏袒某个工具、不该有工具信仰的时代。把所有的都试一遍。全都试试，看看哪个有效，然后试着理解大家说的‘Codex 更擅长遵循指令’、‘Cursor 更擅长创意规划’到底是什么意思。听到这句话是一回事：‘哦，好的。’但接着你亲自去试，真正去体会为什么不同类型的任务要选不同的模型。你越清楚哪个工具擅长哪类活儿，作为设计师或软件创作者就越是得心应手。因为这就好比——怎么说呢——知道什么时候该用 frame、什么时候用 group，什么时候用 auto layout、什么时候自由摆放元素。你就更清楚该用什么方式去完成心里想做的事情。

I’ve handwritten more code in the last 2 weeks than I did in the last 4 months. The current meta right now, if you’re on Twitter a lot like I am, is nobody’s writing code anymore. What are you talking about? Like, touching code? That’s so 2025. And I’m doing that. Like, I use agents to YOLO PRs, especially in prototype playgrounds. I YOLO stuff all the time and I don’t need to look at the code. But I think the models are still bad enough that if you really care about the final quality of the thing you’re shipping, you’ve got to look at code. And I just happen to be working on some stuff recently where I really care about that, where that part matters—the final fit and finish. So yeah, I’m opening an editor and writing code like it’s 2023/2024, and it feels pretty good. Because now I get to reach over to the side and grab this really fast or smart model to just take some of the annoying parts off my plate while I’m in the middle of that. I think it’s a good time to not have an allegiance and not get tribal about tools. Just try it all. Try it all, see what works, and try to understand when people say things like ‘Codex is better at following instructions’ and ‘Cursor is better at creative planning’—what that actually means. It’s one thing to hear that and be like, ‘Okay, cool.’ But then you go and try it, and you try to really understand why you would pick a different model for a different type of task. The better sense you get of which tool is good at which job, the better you can be as a designer or a software creator. Because it would be like—I don’t know—knowing when to reach for a frame versus a group, or auto layout versus free form moving of things. You just have a better mental model of what to reach for to accomplish the thing that’s on your mind.

有一个问题我一直忍不住问自己：如果反过来，是公司申请来跟你谈，而不是你去跟公司谈，会怎样？这个问题就是全新 Dive Talent Network 的基础。而且它真的有效。现在，我正在帮助我认识的最令人兴奋的许多初创公司，去招募收听这个节目的设计师和创造者。所以如果你好奇外面可能有什么机会，也许你想登上我的名单，或者你正在寻找下一位设计师，请访问 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. Right now, I’m helping many of the most exciting startups I know to hire the designers and builders who listen to this show. So if you’re curious about 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.

我已经开始在 Conductor 里做小测试，拿 Opus 和 Codex 5.4 在不同环境里做对比。比如，我会让 Opus 先制定一个计划，然后让 Codex 来审查这个计划，再让它们反复来回。我觉得这很有用。另外我还——你知道 Conductor 里有内置的 review 按钮吧？

I’ve started doing little tests in Conductor just to compare Opus and Codex 5.4 in different environments. And so, like, maybe I’ll have Opus create a plan and then I’ll have Codex review the plan, and then make them go back and forth. I’ve found that’s been really helpful. And then I’ve also just—you know how they have the built-in review button in Conductor?

嗯，知道。

Yeah, yeah.

我最近一直在点它。比如今天早上我就做了。我先用 Claude 点了一次，然后我去设置里换成 Codex，又点了一次。我当时就：‘什么……嗯。’

I’ve just been hitting it. Like, I literally did this this morning. I hit it with Claude, and then I went into the settings and changed it to Codex, and I hit it again. I was just like, 'What's... yeah.'

输出看起来怎么样？

What does the output look like?

我知道，我也这么干。嗯，我其实更喜欢用 Codex 来做 review。我现在有好几次都心想：‘它确实更好，能抓住问题。’

I know. I do the same thing. Yeah, I think I like Codex for reviews more, actually. I have a few instances now where I’m like, 'I think it’s actually better. It’s catching things.'

我也一样。因为它能抓住问题。我觉得这和做设计评审要找多个人的道理完全一样，对吧？每个人看问题的角度都会稍微不同。

I do the same thing. Because it catches things. I think it’s the exact same reason you would do a design review with more than one person, right? Everyone’s just going to have a slightly different perspective.

我觉得这段经历真正让我抓狂的地方在于，它非常不稳定。对，我也这么干。我会用 Opus 做计划，让 Codex 来审查，之后我其实并不在乎谁来写实现。再之后，我会让其中一个来审查实现。实际上，我得到的审查质量很不稳定。比如，我在做这个叫 Shiori 的副业项目，我当时想：‘我应该跑一个提示词，做一次安全检查。’然后我把它交给了 Opus 或 Codex——我记不清了——两者之一。它回复：‘我发现了 10 个安全问题。’然后我又把同样的事情给了另一个模型，结果另一个模型说：‘这是安全剧场。这些对你的用例或代码库来说根本无关紧要。它们就是在浪费你的时间。’然后你再给一次同样的提示词，它们又会说出相反的结论。我觉得现在使用 AI 最让人心累的一点就是这种不一致性——但又让你觉得自己能掌控，比如：‘如果我按正确的顺序使用技能，如果我用正确的流程做审查，让这个模型做这事……’我觉得这很大程度上是在自我安慰，因为模型确实仍然不一致。它们通常还是不擅长输出一致的代码。它们仍会写出一些非常蠢的东西。如果你不读代码，那么三个月后你会说：‘我不知道为什么我的应用不工作，或者它特别慢。’然后你会想：‘是啊，因为你一直在狂灌垃圾，还以为自己做了一件让两个模型互相审查的天才事情。’它们现在还不懂。谁知道呢？也许一年后这问题就解决了。但我认为现在还没解决。

The thing I find really frustrating about that experience is that it’s very inconsistent. Like, I do the same thing. I’ll plan with Opus, have Codex review, and then after that I don’t really care which one implements. And then after that I’ll have one of the two review the implementation. I actually get very inconsistent quality of the review. For example, I’m working on this side project, Shiori, and I was like, ‘I should run a prompt and do a security check.’ And I gave it to Opus or Codex—I can’t remember—one of the two. And it was like, ‘I found 10 security issues.’ And then I gave that thing to the other model, and the other model was like, ‘This is security theater. Literally none of these things matter for your use case or your codebase. They’re wasting your time.’ And then you could give the same prompt and they would say the opposite thing. I find that is the pretty exhausting part of using AI today—the inconsistency—but feeling like you have a grip on it, like, ‘Oh, if I just get my skills in the right order, if I just review things in the right flow and have this model do this…’ I think it’s a lot of cope for the fact that the models are still inconsistent. They’re still generally bad at outputting consistent code. They still write really stupid things. And if you’re not reading the code, then 3 months later you’re like, ‘I don’t know why my app doesn’t work or it’s really slow.’ And it’s like, yeah, because you’ve just been slop-cannoning, thinking that you’re doing this genius thing where two models review each other. They don’t know yet. Who knows? In a year it might be solved. It’s not right now, I don’t think.

先把工具放一边，深入到具体的提示词、文本、命令或问题——也就是你实际使用什么样的语言来跟模型交互。

Taking a step back from tools and getting super granular into literally the types of prompts, texts, commands, or questions—like what you are literally using language-wise to interface with the models.

你能看到在过去 6 个月里真正试用这些东西时，你这部分实践是如何演进、有明显变化或进步的吗？

Are you able to see clear changes or progressions in how that part of your practice has evolved over the last 6 months of really trialling all this stuff?

如果你想想 AI 在做什么，它实际上是接受你给它的一批上游上下文 token，然后尝试给出接下来内容的最佳预测，对吧？这意味着如果你有高质量的输入 token，你就会得到更高质量的输出 token，但这些输入 token 正是你可以用来引导方向的地方。举个例子，这听起来很基础，但如果你想让模型注意某件事，你就必须说出那件事。你实际上必须说出你希望它关注的东西。如果你只告诉模型‘嘿，我们漏掉了哪些边缘情况？’突然间，‘边缘情况’这些词就进入了上下文，模型会从那里开始解读，并进入寻找边缘情况的状态。一旦你理解了这一点，你就会开始写这些看起来几乎像占星术或星座运势的奇怪提示词：‘这怎么才能更简单？’‘我们可能漏掉了哪些边缘情况？’‘这是不是我们能做到的最优雅的方式？’‘我要把你的工作拿给我老板看，你能确保它真的很好吗？’这些都是很蠢的提示词，但它们确实有效，因为它们只是翻转了正确的位，让模型从那里进行外推。我最喜欢的一个来自 Notion 的联创 Simon。我有一个片段：‘让我们退一步，仔细想想。我们怎么能让这件事更简单、更笨，同时还能达成目标？’我觉得这是个好提示词，我大概每天跑 20 次。

If you think about what the AI is doing, it's taking some number of upstream context tokens that you give it and trying to come up with the best prediction of what follows, right? That means if you have really high quality input tokens, you're going to get higher quality output tokens, but those input tokens are where you get to steer the direction. So for example, this sounds so basic, but if you want it to pay attention to a certain thing, you have to say that thing. You actually have to say the thing you want it to focus on. If you just tell the model, 'Hey, what are some edge cases we've missed?' all of a sudden the words 'edge case' are in the context, and it's going to interpret from that forward and be in the mindset of looking for edge cases. Once you understand how that works, you start to write these weird prompts that almost feel like astrology or horoscopes: 'How could this be simpler?' 'What are edge cases we might have missed?' 'Is this the most elegant way we could have done this?' 'I'm going to show your work to my boss, can you make sure it's really good?' These are stupid prompts, but they work because they just flip the right bits so the model extrapolates from there. One of my favorites is from Simon, the co-founder of Notion. I have a snippet for it: 'Let's step back and think really hard. How can we make this simpler and dumber while still achieving our goals?' I think that's a good prompt, and I run it, I don't know, 20 times a day.

真的吗？哇。

Really? Wow.

是的，就像做完每件事之后。每个计划，都让它更简单、更笨。每次它修复了一个 bug，我就会问，有没有更简单、更笨的做法？每次它做了个新按钮，我都会想，有更简单的办法做那个按钮吗？我打赌你把它搞得太复杂了。所以在语言方面，这就是为什么在 AI 出现之前就会编程的人，比不会编程的人使用 AI 要顺利得多。因为猜怎么着？他们知道该说什么词。他们知道上游那串 token 里该放什么。他们知道怎么说‘持久化工作流’、‘后台任务’、‘队列并行化’这些词。我觉得如果你不会编程，你根本没有这些词汇。但如果你写程序有一段时间了，你就有了这些词汇，并且很自然地就能描述这类系统。那些人显然得到了更好的结果。所以我必须非常开放地看待自己不擅长的一切，认为那都是‘技能问题’，因为理论上，如果你能用正确的词汇更清晰地用英语描述你的意图，让模型能够从中外推，它理论上就会做对。对吧。所以很多时候当模型做错事，我必须自我反思：我觉得是我写了个糟糕的提示词，或者写了个懒散的提示词，或者我写的时候太累了。这正在改变我的行为方式。所以我已不再深夜写提示词。如果我累了，我就不应该让它做事情，因为我会以懒散、疲惫的 Brian 的方式去指示它。

Yeah, like after everything. Every plan, like make it simpler and dumber. Every time it fixes a bug, is there a simpler dumber way to do that? Every time it makes a new button, I'm like, is there a simpler way to make that button? I bet you made it way too complicated. So that on the language side is why anyone who knew how to code before AI is having a way better time using AI than someone who didn't know how to code, because guess what? They know the right words to say. They know what goes in that upstream sequence of tokens. They know how to say things like 'durable workflow' or 'background job' or 'queue parallelization.' These are things that I think if you don't know how to program, you just don't have the vocabulary for. But if you've been programming for a while, you have the vocabulary, and it feels very natural to describe those kinds of systems. Those people are obviously getting better outcomes. That's why I have to be very open-minded to the idea that everything I'm bad at is a skill issue, because in theory, if you can describe your intent more clearly in English with the right set of words that the model can extrapolate from, it will do the right thing. Right. So I think a lot of times when it does bad things, I have to self-reflect: I think I wrote a bad prompt, or I wrote a lazy prompt, or I was tired when I wrote that. That is changing how I relate. So I've stopped writing late night prompts. If I'm tired, I should not ask it to do a thing, because I'm going to ask it in a lazy, tired Brian sort of way.

我们来聊一点 Shuri。我看到一些推文，关于你正在做的东西。所以也许先给我们一些背景信息，但我特别感兴趣的视角是：至少对我自己来说，任何时候我从一张白纸开始做东西，没有约束，可以做任何事，这都是尝试新事物的机会。那么鉴于 Shuri 的情况，你这次是如何利用这张白纸的？

Let's talk about Shuri a little bit. I've been seeing some tweets, things you're building. So maybe give us a bit of context, but then the lens I'm particularly interested in using is this: for myself, anytime I'm doing something from a blank canvas, with no constraints, it's an opportunity to try new things or to tinker. So given the context of what it is, how are you taking advantage of the blank canvas this time around?

是啊，这很滑稽，也几乎有点尴尬，因为好像我们什么都能做。AI 什么都能做，而我说，‘我要做一个书签工具。’这就好比天气应用、股票走势图、待办清单，还有 Obsidian 替代品。是的。我大概是去年开始做 Shuri，就是为了解决我自己的一个问题：不管我用什么稍后读应用，我从来都不会回去读那些东西。我还没完全搞明白为什么，但也许和那种拥有感有关——自己做了这个东西，会让我觉得更亲近，或者想从中榨出点价值来。所以我做了个自己的稍后读应用，基本上它所做的就是把内容同步到 Notion，然后我把 Notion 当列表用。去年我基本上就在‘Notion 化’我的整个生活，比如怎么把我的一切都放进 Notion？那确实有用。它运行得挺好，但很难作为应用分发。它是一个 Notion 数据库，我在云上跑一些函数，但不知道怎么分发。把东西放在 Notion 里很好，只是它会在注意力上和 Notion 里的其他内容打架。Notion 里有我所有其他东西，但有时候我想周末坐下来读半小时书，我只想要一个非常简单、专注的体验，让我能看到阅读清单上有什么。所以那时候我开始做 Shuri，也就是那个功能的独立版本。AI 的酷之处在于，你可以在 2 秒内搭建一个像 Shuri 这样的产品。真的，最简单愚蠢的提示词就能做到，因为训练数据太多了——太多人做过书签和稍后读应用了。对我来说有趣的部分是弄清楚冰山有多深。表面上它只是一个链接列表，并不复杂，但在表面之下，尤其是当用户保存链接时，你会发现人们对书签做一些奇怪的事情。有人保存了重定向到 localhost 的链接。这怎么可能？某个地方有人为一个真实域名设置了一个重定向，跳转到 localhost 路由。通常那些人是在试图黑你，所以你必须考虑这一点。还有人导入过 10000 篇维基百科文章。

Yeah, it's very funny and almost embarrassing, because it's like, we can make anything. AI can make anything, and I'm like, I'm going to make a bookmarking tool. It's like weather apps, stock market charts, to-do lists, and Obsidian replacements. Yeah. I started working on Shuri, I guess a year ago, just to solve a problem I have: no matter what system I have for a read-it-later app, I never go back and read the things later. I haven't quite figured out why, but maybe it's this idea of ownership—having made the thing makes me feel more connected to it, or want to get juice out of it. So I made my own little read-it-later app, and basically all it did was sync stuff into Notion, and then I used my Notion as the list of stuff. I was basically Notion-maxing all of last year—like, how do I put my whole life on Notion? And that actually worked. It was working pretty well, but it's kind of hard to distribute that as an app. It's a Notion database, and I have some functions running in the cloud, but I don't know how to distribute that. Having things in Notion is great, except it's sort of fighting the rest of Notion for attention. Notion has all my other stuff, but sometimes when I want to sit down on the weekend and read for half an hour, I just want a very simple, focused experience that shows me what's on my reading list. So that's when I started working on Shuri, which is the standalone version of that. The cool thing about AI is you can stand up a product like Shuri in 2 seconds. Literally the dumbest prompt will get you there, because there's so much training data—so many people have made bookmarking and read-it-later apps. The interesting part for me has been figuring out how deep the iceberg goes. On its surface, it's a list of links. It's not complicated, but under the hood, especially when you have users saving links, you realize people do weird things with their bookmarks. People have saved links that redirect to localhost. How is this possible? Somebody somewhere set up a redirect for a live domain on the web that redirects to a localhost route. Usually those people are trying to hack you, so you have to consider that. I've had people import like 10,000 Wikipedia articles.

好，一万篇维基百科文章——我们该怎么同时处理这个一万篇文章的导入？我需要去学习分布式系统和并行化，还有如果其中一篇失败了会发生什么？我们要重试吗？如果其中一篇维基百科文章有三万字，放不进数据库的某一列怎么办？所以你会遇到所有这些边角情况。我现在做 Shuri 特别开心的地方，就是深入处理这些边界情况，并且在每一步写下测试、验证框架，或者加上必要的日志，让 AI 知道所有这些边界情况，将来可以绕开它们来设计。

Okay, 10,000 Wikipedia articles — how should we process a 10,000-article import happening simultaneously? I need to go learn about distributed systems and parallelization, and what happens if one of those fails? Do we retry it? What if one of those Wikipedia articles is 30,000 words long and doesn't fit into a database column? So you hit all these little edge cases. What I'm having a lot of fun doing with Shuri is going really deep handling all these edge cases, and at each step, writing the test or verification framework or adding the logging necessary so that AI knows about all these edge cases and can design around them in the future.

这很基础，但我有点自豪。现在的流程是：当有人在 Shuri 上报了一个 bug——对，bug 仍然会发生——我只需要把他们的邮箱地址或用户 ID 粘贴到 Claude 里。我把 Claude 接上了 Sentry 做错误上报，还接了 Supabase，这样它就能查到这个账号的信息。我用 Axiom 作为日志接收器。我只要贴上用户 ID 和邮件内容，它就会去重放失败那一刻之前发生的所有事情，因为每一个事件都被记录和追踪，包括所有异常。它知道用户用什么设备，诸如此类。所以 bug 上报和修复变得非常快。对我来说，这就是现在最有意思的部分。

So this is very basic, but I'm kind of proud of it. The flow now is: when someone reports a bug on Shuri — and yes, bugs still happen — all I have to do is take their email address or user ID and paste it into Claude. I have Claude hooked up to Sentry for error reporting and Supabase, so it can figure out information about their account. I use Axiom as a log drain. I can paste their user ID and the content of their email, and it will go and replay exactly what happened leading up to the moment of failure, because every single event is logged and tracked, including all the exceptions. It knows what device they're on, all that kind of thing. So bug reporting and bug fixing has become quite fast. To me, that's the fun part now.

我觉得 Shuri——你知道史蒂夫·乔布斯那个磨石头的比喻吗？你把粗糙的石头放进去，转动滚筒，如果转得足够久，出来的是一组抛光的石头。我现在玩得很开心的就是搞清楚那个滚筒是什么，能让我在另一端得到一块抛光的石头。它要能抵抗边界情况，但万一出现边界情况，我也能很快很轻松地找到它——或者让 AI 代替我很快找到——然后修复它，并把它加进知识库里。所以它是一个自愈、自增强的系统。现在还没完全自动化，事实上自动化的部分很少。但这就是长期目标：我能不能把更多的东西放到轨道上，这样我就能专注做酷炫、好玩的新功能，而那些基础设施、Scaling、边界情况处理、bug——所有这些都变成一个自愈的循环。

I feel like with Shuri — you know the rock tumbler analogy from Steve Jobs? You put rough rocks in, tumble them around, and if you tumble enough, what comes out is a set of polished stones. I'm having fun figuring out the tumbler that gets me a polished stone on the other side. Something that is resistant to edge cases, but if an edge case does come up, I'm able to find it quickly and easily — or the AI finds it on my behalf — and fixes it, then adds it to the knowledge. So it's a self-healing, self-reinforcing system. Not all of it is automated yet; in fact, very little is. But that's the long-term goal: can I put more of this on rails so I can focus on building cool, fun new features, while the infrastructure, the scaling, the edge-case handling, the bugs — all of that becomes a self-healing loop.

对我来说，现在和 AI 合作最酷的一点是，我能伸展到以前作为工程师写代码时不太敢碰的领域。我想给 Shuri 做一个 API。2024 年的我作为一个程序员会说：‘我真不知道从哪开始。’ 怎么做 CLI？怎么做 API？怎么做速率限制、滥用检测，所有这些？我完全没头绪。但突然之间，这类工作变得非常容易上手。我只要把智能体往那个方向引导就行。这对 Shuri 来说很酷——API、CLI、MCP——就是逼自己稍微走出舒适区一点。我可能走得还不够远。作为一个写了好一阵子代码的设计师，你很难摆脱‘哦，但这个我要怎么实现’的思维定式，进入这种新工作方式：我该怎么把最终愿景或目标描述得足够清楚，让 AI 能动手去做？

The cool part for me about working with AI now is that I get to stretch just beyond what I would have been comfortable doing as an engineer writing code before AI. I want to build an API for Shuri. The 2024 version of me as a programmer would have said, 'I don't really know where to even start.' How would I build a CLI? How would I build an API? How would I do rate limiting, abuse detection, all these kinds of things? I had no idea. And now, all of a sudden, that type of work is very accessible. I can just guide the agent in that direction. That has been cool for Shuri — API, CLI, MCP — just pushing a little bit beyond my comfort zone. And I'm probably not pushing enough. As a designer who has been writing code for a while, it's hard to shake the mindset of 'oh, but how would I build this?' and get into this new way of working: how do I describe my end vision or the end goal clearly enough that the AI can do it?

这真的让我回到你之前说的生产力和速度的话题。我觉得我其实同意。很奇怪。我们衡量 AI 的主要标尺往往是速度和效率。但我没那么在乎这个。那不是它对我的影响。不是效率。是它让我能在一堆邻近的领域里玩耍，而这些领域以前我连门都进不去。它更像是抬高天花板，增加我能带到桌面上的东西。我不一定是把事情做得更快，而是能做更多不同类型的事，而这些事以前根本不可能。

It honestly made me go back to what you were talking about earlier, in terms of productivity and speed. And I think I actually agree. It's weird. The dominant measuring stick we use for AI is so often speed and efficiency. But I don't really care about that that much. That's not the impact it's had for me. It's not efficiency. It's given me the ability to play in a set of adjacent ballparks that I previously had no business even walking into the door for. It's more about raising the ceiling and increasing what I can bring to the table. I'm not necessarily doing that much stuff faster, but I'm doing many more different types of things that were previously inaccessible.

Shuri 对我而言有点像一剂解药，因为我平时工作的一周里都在更快地做更多事，写更多代码，做更多原型。然后我坐下来弄 Shuri，会想：要让这个项目保持有趣、让我愿意接下来几年继续做下去，需要满足什么条件？其中一部分就是我必须理解代码库。我必须在乎谁在用这个产品，以及他们有没有被照顾好。我必须在乎好的基础设施。这些东西会逼你慢下来。我很享受这一点。AI 让我做到的是慢下来，专注于难点，让计算机来处理其余部分。

Shuri has become a bit of an antidote for me, because I spend my week at work doing more faster, writing more code, building more prototypes. Then I get to sit down with Shuri and think, what needs to be true for this to stay interesting and remain a project I'd work on for the next several years? Part of that is I have to understand the codebase. I have to care about who's using it and that they're being taken care of. I have to care about good infrastructure. Those things force you to slow down. I quite enjoy that. What AI is allowing me to do is slow down and focus on the hard parts, and let the computer take care of the rest.

比如，我现在的流程是：工作日做规划，周末去执行。一个典型的一天可能是：我醒来，看看有没有过夜的错误、bug 或用户反馈。我有一个简单的技能叫‘修问题’——我把它粘贴到 Claude 里，让它去修所有的 Sentry 问题或者去调试。好，这个从我盘子上拿掉了。然后我可以去跟 AI 聊：‘我想下一步做这个功能，但我不太确定它会怎么工作。这是大概的意图或用户目标。’提交。然后我去上班。晚上回来，读一下计划，和它聊一会儿，可能再做一个回合，提交，然后睡觉。这就是一天。到了周五或周六早上，你就有了一份相当不错的计划：‘好，这是我打算怎么处理这个东西。’然后周六，所有杂事都不在我盘子上了——没有一堆 bug 要担心。我只需要真正研究那份计划，然后动手构建。我觉得这对副业项目很有效。我也试着有意放慢节奏、掌控步调。为了把它推出去，我确实有些手忙脚乱，就像你必须做的那样，把所有功能都弄到位。但现在我想进入一个有节奏的状态：规划、发布、打磨石头、处理边界情况。然后随着时间推移，也许开始切出一些可以自动化的小块。那才是真正有意思的部分。

For example, my current workflow is: during the weeks I plan, and during the weekends I execute. A typical day might be: I wake up, check for any overnight errors, bugs, or user feedback. I have a simple skill called 'fix issues' — I paste it into Claude and let it go fix all the Sentry issues or debug things. Cool, that's off my plate. Then I can go talk to AI: 'I think I want to do this feature next, but I'm not quite sure how it's going to work. Here's roughly the intent or the user goal.' Submit. Then I go to work. I come back at night, read the plan, chat with it a little, maybe do one more round, submit, and go to bed. That's one day. By Friday or Saturday morning, I've got a pretty good plan: 'Okay, here's how I think I'm going to tackle this thing.' Then Saturday, all the bullshit is off my plate — there's no pile of bugs to worry about. I just get to study the plan and get to work building it. I think that works for a side project. I also try to be intentional about pacing myself. I scrambled a bit to get it out the door, as you have to, to get all the features in place. But now I want to get into a methodical rhythm: planning, shipping, polishing the stones, handling edge cases. And over time, maybe start slicing off little bits that can be automated. That's the interesting part.

时间快到了，我想来个急转弯，因为有几个可能不太相关的事，我确实想听你说说。其中一个就是：我希望你能治治我对东京设计大会的错失恐惧症，因为你在那儿做了演讲。

Coming up on time, I want to take a hard left because there are a few potentially unrelated things I honestly just want to hear about. One of them is: I'm hoping you can heal some of my FOMO from Tokyo Design Conference, because you gave a talk there.

显然我们没法讲完整个演讲，但当设计师们听完你的分享离开那个房间时，你最希望他们带走的是什么？

And obviously we can't go do the whole thing, but when designers left that room after you were done, what was the core thing that you were hoping they took away with them?

我希望人们从这次演讲中带走的，是 AI 不是魔法。底层系统非常复杂，我认为没有人敢说自己知道大语言模型在底层到底在做什么。但它确实在你的电脑上做事情，比如写文件、写脚本，调用 70 年代发明的 bash 命令。这些都是可以了解的东西。面对这个世界，有两条路：一是完全不注意 AI 在你电脑上做什么、写什么样的代码、怎么写代码、怎么浏览你的代码库，直接放手让模型接管；二是对它保持好奇，比如“那是什么意思？等等，什么是 grep？grep 是什么？grep 和 sed 有什么关系？sed 又是什么？”然后你会去查 awk，然后你会感叹：“什么？70 年代某个老哥随手发明的东西居然经久不衰。现在这三个小命令居然驱动着所有现代智能体式编程。”太疯狂了。我在 Notion 的经理叫 Max Stoening，他特别擅长用极客问题狙击我。他会用这些问题让我对计算机的工作原理更感兴趣。他让我去玩 Linux，让我去理解打开终端时会发生什么。他对 Notion 的其他人也这样做：如何让 AI 去神秘化，让你感到能掌控它、更有效地使用它，或者只是形成更好的观点，看到大势所趋。AI 使用的这些东西已经存在 50 年了，懂这些的人能获得巨大回报。他们会想：“哦，我懂计算机怎么工作，我可以把 AI 指向一个计算机形状的问题，然后得到很酷的结果。”所以这就是我希望人们从演讲中带走的。演讲本身，怎么说呢，我分享了一些我在演讲中给出的提示示例，其实讲的就是如何获得正确的上游 token，让 AI 能从中推断出更多。你如何用极客问题挑战自己，去理解点击提交提示词时发生了什么。我不知道是否成功，但我希望至少有一个听众在听完后变得更有好奇心。

The thing I wanted people to take away from that talk is that AI is not magic. The underlying systems are very complicated. I don't think anybody would claim they know what an LLM is doing under the hood. But it is doing things on your computer like writing files, writing scripts, and invoking bash commands that were invented in the 70s. And those are knowable things. There are two ways you can sort of navigate that world. One is you can not pay attention to what AI is doing on your computer, the kind of code it's writing, how it writes the code, how it navigates your code base. You can just not pay attention and let the model take the wheel. Or you can be curious about it. Like, what does that mean? Wait, what is grep? What's grep? And what's grep in relation to sed? Sed, what's that? And you're going to find out about awk. And you're going to be like, what? Some guy in the 70s just made this thing up and it has stood the test of time. And now these three little commands are what power all modern agentic coding. It's insane. My manager at Notion, his name's Max Stoening. He's very, very good at nerd sniping me. And he nerd snipes me to be more curious about how computers work. He's sent me on a journey to play with Linux. He's sent me on a journey to understand what's happening when you boot up a terminal. And he's doing the same for many other people at Notion. Like, how do you demystify AI so that hopefully you can feel in control and wield it more effectively? Or just have a better opinion, or kind of see where the puck is going. Like again, AI is using things that have been around for 50 years. And the people who know about these things are getting a lot of mileage. They're like, oh, I know how computers work. I can point AI at this computer-shaped problem and get cool things out the other side. So I think that's what I wanted people to take away from my talk. And the talk was really, I don't know, I shared some of the prompt examples I gave here, which is really about how do you just get the right upstream tokens that the AI can extrapolate from there. How can you nerd snipe yourself to understand what's happening when you hit submit on a prompt? I don't know if it was successful. But I hope at least one person became more curious after that.

关于 Max 和“极客狙击”的评论让我想深入另一个话题，因为 Max 是我一直远远仰慕的人，我从未见过他，也没和他共事过。我觉得这几乎代表了我对 Notion 整体的看法：显然那里有一群非常有才华的人在打造非常不可思议的软件。我以前从未待在过那样的环境里。所以你现在已经入职一年多了。你觉得那里的文化、同事或者工作方式，是如何在过去这一年多里塑造了你这个设计师的？

The comment about Max and nerd sniping makes me want to go down another little rabbit hole, because Max is someone who I've always looked up to from a distance. I've never met Max, never worked with him. And I think it's representative of almost the way I view Notion as a whole. There's obviously a bunch of really talented people there building really incredible software. I've never been in any environment like that before. So you're now over a year in. How do you think that culture, or the people, or the way of working, has shaped you as a designer over the last year plus?

现在 Notion 最酷的一点是，从上到下我们都非常愿意重新审视旧假设。Notion 真的必须长这样吗？它会永远是这种形态吗？我们开始去试探和挑战。团队里一些设计师刚刚重做了左侧边栏，让它更像聊天的体验。我们内部很多人基本上都是通过聊天或智能体来使用 Notion。这种拥抱变化、质疑所有假设的意愿非常酷。我觉得对于这个规模的公司来说，做这件事很难，因为这很吓人，对吧？事情进展顺利，但几年后世界会变得非常不同，我们必须做好准备。然后，第二点是 Max 擅长的，也是这里领导层擅长的：鼓励人们想得更大。OpenAI 和 Anthropic 现在更“YOLO”，会想“如果我们这么做会不会很疯狂？”而我觉得很多软件公司不太敢这样问自己，感觉这超出了他们的许可边界，也就是文化上允许他们在那片空间里玩的边界。所以，我觉得 Max 和其他人都很擅长推动人们去想：为什么不？为什么我们不能？这就是 Notion 的盒子，对吧？人们认为 Notion 是 wiki、笔记工具、文档协作工具。盒子外面有什么真正有趣的东西？我们去那边玩吧。那是个非常有趣的地方。我觉得我们距离 Linear 或 Karai 发表“问题追踪已死”的文章还有两天。我就想，全球有多少公司会做那种事？我确实认为 Notion 可能是其中之一。但现在 SaaS 正处于一个非常奇怪的时刻，就像你说的，纸面上一切顺利，但如果你不往前看几年，就会……有一点是确定的，我们知道两年后的变化会非常惊人。没人能百分百确定，但似乎每家公司现在都应该去理解如何让系统对 AI 可读，这样你将来才能进入那个生态。看起来这个生态不会消失。我们不知道智能体将来具体会做什么、想怎么工作，所以你需要把软件设计得有点灵活。这也是为什么我们回到 API 和 CLI：这些东西已经存在很久了，计算机知道怎么用它们，而且很长一段时间内不会消失。所以让我们投资这些，对吧？我们刚刚发布了 Notion CLI。Notion 历来不是开发者工具，我们有开发者平台，你可以构建集成，为团队构建东西。但嘿，Notion 有 CLI，这样你能通过 Notion API 做的一切现在对 AI 都是可读的。当然，我们很早就采用了 MCP 之类的东西。我认为你必须做这些事情去试探边界，确保当模型形态变化或新能力出现时，你能处于快速行动的位置。所以，是的，我要称赞 Karai、Linear 团队，以及任何没有这么做、而是认真审视自己当前业务的公司——在这个我们生活的新世界里。如果它们不这样做，我想它们会有麻烦。

The cool part about Notion right now is from top to bottom we are very comfortable revisiting old assumptions. Does Notion really need to look like this? Will it be this shape forever? And we're starting to poke and prod at that. Some of the designers on the team just redid the left sidebar, making it much more of a chat-forward experience. A lot of us internally pretty much have used Notion through chat or through agents. The willingness to embrace that and change and question all the assumptions is very cool. I think that is a hard thing for a company at this size to do because it's scary, right? Things are going well, but the world's going to look very different in a few years, and we need to be ready for it. And then I think the second part of that, and what Max is good at, and what the leadership here is good at doing, is encouraging people to think bigger. I think right now OpenAI and Anthropic, they're way more YOLO about, wouldn't it be crazy if we did this? And I think there's a lot of software companies that are a little bit scared to ask that of themselves. It feels outside of their permission boundary, like their cultural permission boundary of being able to play in that space. And so, yeah, I think Max and everyone else is good at pushing people to like, why not? Why can't we? Here's Notion's box, right? People think of Notion as a wiki, a note-taking tool, a document collaboration tool. What's right outside that box that's really interesting? Let's go play there. And that is a very fun place to be. Yeah, we're like two days from Linear or Karai publishing the article saying issue tracking is dead. Which I'm like, how many companies on the planet would do that type of thing? I do think Notion is potentially one of them. But it's such a weird moment in SaaS where, like you said, everything on paper could be going well, but if you're not looking I don't know how many years ahead, it's just like if there's one thing that's certain, we know that the amount of change in two years is going to be extraordinary. Nobody knows for certain, but it seems like a good idea for every company right now is to understand how to make your systems legible to AI so that you can participate in that ecosystem in the future. Seems like the ecosystem won't go away. We don't know exactly what the agents will be doing or how they'll want to work in the future. So you just need to design your software in somewhat of a flexible way. Which is why we come back to like APIs and CLIs. These things have existed for a long time. Computers know how to use them. They're not going to go away for a long time. So let's invest in those things, right? I think we just shipped a Notion CLI. Notion's not historically a developer tool. We have a developer platform you can build integrations and build stuff for your team. But hey, Notion has a CLI so that everything you can do through the Notion API is now legible to an AI. And of course we were very early with MCP and all that kind of stuff. These are the things that I think you have to be doing to poke at the edges and just make sure you're in a good position to move quickly as the models change shape or new capabilities come out. So yeah, I mean kudos to Karai and the Linear team and any company that's not doing that and really taking an honest look at their current business in this new world we're living in. If they're not doing that, they're in trouble, I think.

最后一个问题，也许我们可以从公司战略转到个人职业战略一会儿，因为……天哪。

Final question, maybe we could shift from company strategy to personal more career strategy for a second because... oh boy.

另一件在互联网上炸开锅的事，至少在我们这个 Twitter 小圈子里，是 Lenny 发的那条推文，说设计师是目前唯一没有在增长的角色。而且实际上，设计增长和 PM 增长之间的相关性，目前对我们并不有利。你对这一切对于设计师意味着什么有什么看法？另外，对于一个可能职业生涯还比较早期的设计师来说，怎样才算回应得当？也许他们并不在一家像 Notion 那样的公司工作，而且你知道，眼下我们头顶都笼罩着一大片不确定性的乌云。

The other thing that blew up the internet, at least in our little community of Twitter, was Lenny's tweet about designers being the only role that is not experiencing growth right now. And actually, the correlation between design growth and PM growth is not in our favor currently. Do you have any thoughts on what that all means for designers, and also what it looks like to respond well in this time as a designer who maybe is a little bit earlier in their career? Maybe they're not working at a company like Notion, and you know, there's a pretty hefty uncertainty cloud above us all at the moment.

同样地，如果一家做问题追踪或笔记的公司不照照镜子，认真想想自己在未来扮演什么角色，那会很疯狂。今天的设计师如果不这么做，也同样疯狂。我觉得我们对头衔的痴迷会把人坑惨。如果你心里想，“但我是设计师还是 PM 还是工程师？天啊，我到底走哪条路？”不不不，不是这样。这些东西正在消失。所有这些东西都变得非常非常模糊。在这些学科之间流动变得非常非常容易。你要成为那种能非常流畅地在不同类型的工作之间切换的人，而不是纠结于“我在这家公司里属于哪个盒子，对吧？”所以，你想要一个能交付代码来证明想法是好的设计师。你想要一个能围绕自己的规格做设计，看看这个规格能否经得起现实检验的 PM。你想要一个真正关心构建优秀视觉组件系统的工程师，这样他们就能在不需要设计师进来说“把东西挪一挪”的情况下，把漂亮的东西做出原型来——那种指点真的很烦人。你想要的是那些冲破我们围绕自己、自己的角色和头衔建起的这些人为壁垒的人，他们只专注于交付好的软件。

In the same way it would be crazy for a company that did issue tracking or note taking to not take a hard look at themselves in the mirror and try to figure out their role in the future, it would be crazy for designers today to not be doing the same thing. I think our obsession with titles is what will screw people over. If you're like, 'But am I a designer or a PM or an engineer? Oh my god, which path?' No, no, no, no, no. These things are going away. All of this stuff is getting very, very blurry. It's getting very, very easy to move between those disciplines. And you want to be the kind of person who can move between those types of working very fluidly and not get caught up in, 'What's the box I'm in at this company, right?' So you want a designer who can ship code to prove that an idea is good. You want a PM who can design around their spec to see if their spec holds up to reality. You want an engineer who really cares about building great visual component systems so that they can prototype beautiful things without needing a designer to come in and tell them to nudge stuff around, which is really annoying. You want people who break out of these made-up walls we've built around ourselves and our roles and our titles, and are just focused on shipping good software.

所以我不知道，这很难对一个新人说，因为有太多东西要学，太多事要做。我想说的是，如果你能专注于为真实的人做东西，解决一个真实的问题，快速迭代，尽力把东西做好，并且不再担心“但我不会写代码，我不会写 PRD”，那谁在乎呢？只管把东西做出来，把问题解决掉，然后学着怎么做得更快。你会没事的。

So I don't know, that's hard to say to someone who's new because there's just so much to learn and so much to do. I would say if you can just focus on making things for real people that solve a real problem, iterate quickly, try to make the thing as good as you can, and stop worrying about, 'But I don't know how to code, I don't know how to write a PRD.' Who cares? Just ship the thing and solve the problem, and learn how to do that faster. You'll be fine.

我不知道。我的意思是，我不知道。有时候我会想，我不知道自己还能工作多久。这一切会不会消失？而我唯一知道怎么做的，就是继续做我能做出的最好的软件，为真实的人解决真实的问题，关注那些工具、那些模式，努力理解那些实验室正在发布的东西，努力理解当前关于技能、上下文管理和提示工程的最新潮流。只管去理解它。这确实让人觉得极其嘈杂。我得说，这是我有史以来最分心的时候。这是我有史以来感觉最强烈的上下文切换疲劳。

I don't know. I mean, I don't know. Sometimes I'm like, I don't know how long I'm going to have a job. Is all this going away? And the only thing I know how to do is just keep making the best software I can make, solve real problems for real people, pay attention to the tools, the patterns, try to understand what's going on that the labs are shipping, try to understand the current meta of skills and context management and prompt engineering. Just try to understand it. And it does feel incredibly noisy. I would say this is the most distracted I've ever been. It is the most context-switch exhaustion I've ever felt.

另外，你得想办法让这件事可持续。我要说，这是我的预测。这个预测在未来三个月要么会很准，要么会打脸。去年 Opus 3.5 和 Sonnet 3.5 发布的时候，我记得大概是三四月份，我彻底沉迷了，一切 AI，AI 一切。我一天 24 小时在大规模写代码。我和我的未婚妻——她也是设计师——正在度假。我们却从手机上发提示词、发会话。我们很难断开连接、拔掉插头。我们就像，“天啊，如果我们不 24/7 地发提示词，我们就在浪费时间。我们在浪费宝贵的时间。”如果这听起来很熟悉，那是因为我们现在正处在完全相同的一刻，一年之后每个人也仍然有同样的感觉。我能告诉你的是，去年年中，天哪，我撞墙了。你会撞墙，因为你无法在一天中的每一个清醒时刻都保持这种接入状态、尝试每一个工具、拼命保持高效——那种状态你撑不过几个月。至少我的脑子受不了。所以我预测我们很快会有一次回落。我甚至可以说，它已经在发生了，但在未来一两个月里会更明显。而这个预测如果不成立、会打脸的唯一原因，就是未来一两个月内有什么大的模型能力发布。但我认为人们会感到精疲力竭。这意味着人们会回到这样的问题：“我怎么更有效地利用时间？我怎么在混乱中保持冷静，专注于当下？我怎么把 Twitter 关掉两个小时，真正把工作做完而不分心？”这些东西会是经久不衰的。我觉得现在每天能专注、不被干扰两个小时，本身就是一种有意义的竞争优势，这太疯狂了。

The other thing here is you got to figure out a way to make this sustainable. I'll say here's my prediction. This is going to age very well or very poorly in the next three months. When Opus 3.5 and Sonnet 3.5 came out last year, I think it was around March or April or something, I went on a real bender of AI pilled, everything AI. I was doing gigantic coding 24 hours a day. Me and my fiancée, who is also a designer, were taking a vacation. We were sending prompts and sessions from our phones. We had a hard time disconnecting, unplugging. We were just like, 'Oh my god, if we're not prompting 24/7, we're wasting time. We're wasting valuable time.' And if that sounds familiar, it's because we're in the exact same moment right now. Everyone's feeling the same way, a year later. And what I can tell you is that in the middle of last year, oh boy, I hit a wall. You hit a wall because you just can't sustain that level of being plugged in, trying every tool, and trying to be productive every waking hour of the day for more than a few months at a time. At least my brain can't handle it. And so I predict that we're going to have a come down really soon. I would argue it's already happening, but in the next month or two. And the only reason that wouldn't be true, and this will age poorly, is if there's some big model capability that drops in the next month or two. But I think people are going to get exhausted. What that means is people will come back to, 'How do I spend my time more effectively? How do I stay calm in all the chaos and just focus? How do I turn off Twitter for two hours a day and actually get work done without being distracted?' These things are going to be tried and true. I think the ability to focus and be undistractable for two hours a day is a meaningful competitive advantage right now, which is insane.

Brian，感谢你，兄弟。这总是很有趣。能请到你是一大乐事，你总能带来能量和笑声。这段时光很棒。所以谢谢你。

Brian, appreciate you, man. This is always fun. You're a joy to have on, and you always bring the energy and the laughs. This has been a great time. So thank you.

谢谢你的邀请。

Thanks for having me.