从 Figma 到定制原型：Patrick Morgan 的内部工具之旅

去年 12 月，我大概 95% 的时间都还在 Figma 里，现在几乎不用 Figma 了。我觉得一旦你开始看到这种环境里能做什么，给自己留出足够距离的好处就会变得更清晰。即使是我那些非常发散性的探索，可能也不想离网络安全公司的实际生产代码太近，因为它是一个独立的空间。你可以真正让它以你需要的方式服务于你独特的工作流程。

I was very much still just like in Figma 95% of the time in December and now I'm almost never in Figma. I think once you start to look at like what's possible in this environment, it starts to become more clear the benefits of giving yourself just enough distance. Even most of my very divergent explorations like probably don't want those like too close to the actual production code in a cyber security company because it is its own dedicated space. You can really allow it to serve your unique workflow in the way that you need it to.

欢迎收听 Dive Club。我是 Rid，这里是设计师永不止步的学习之地。本周的嘉宾是 Patrick Morgan，我们将深入探讨他为 Sublime Security 构建的原型设计环境，因为我认为这是一个很好的例子，展示了设计师如何通过构建周到的内部工具来提升组织能力。Patrick 构建了一个画布，让人们可以组织和标注原型，一种创建和共享文档的新方式，甚至为品牌团队正在构建的内部工具提供了一个新家。那么话不多说，让我们开始吧。

Welcome to Dive Club. My name is Rid and this is where designers never stop learning. This week's episode is with Patrick Morgan and we're going to do a deep dive into the prototyping environment that he built for Sublime Security because I think it's a really good example of how designers can level up their orgs by building thoughtful internal tools. Patrick built a canvas for people to organize and annotate prototypes, a new way to create and share documents, and even a new home for these internal tools that the brand team is building. So without further ado, let's dive in.

我觉得和许多产品设计师一样，在去年年初的时候，我做了很多原型设计，主要是用 Claude 制作一些工件。那些东西很棒，很有用，但也有一些根本性的问题。最主要的是它们很快，但与实际产品中的任何东西都脱节了。它们没有持久化到任何地方。我没法随着时间推移在它们基础上继续构建。我们团队的其他设计师也是如此。他们同样从中获得了一些价值，但这些原型没有存在于一个我们可以共同从中获益的地方。另一方面，我也研究过是否应该更多地在生产环境中进行原型设计。这也是一个热门话题。但结合我们这种特定类型的产品——我们是一个大型企业网络安全应用——我越深入研究，就越发现约束太多了，即使我能在那里做原型，也会非常费力，会大大拖慢我的速度，而且不能真正以我需要的方式促进我的设计工作流程。所以我试图找到一个中间的最佳点，比如我能否集中管理这些原型，这样我们团队就能共同构建，并随着时间推移获得那种复利效应。同时保留我从开放式原型设计能力中想要的所有灵活性。

I think like many product designers, at the turn of this past year, I was doing a lot of prototyping primarily just like making artifacts with Claude. And those are great. They were useful, but they had some fundamental problems. Most of which being they were fast, but they disconnected from anything that was kind of in our actual product. They didn't persist anywhere. They weren't like I couldn't build on them over time. And the same was to be said for the other designers on my team. They were likewise getting some value from doing them, but they didn't live anywhere that we could collectively get more benefit from them. And then on the flip side, I had also looked into like should I be prototyping more in production? That's also a hot button topic. And the more I looked into that with our particular type of product, we're a big enterprise cyber security app. And there just too many constraints for me that got in the way of even if I could prototype there. It was just going to be very laborious to be able to do it there and it would slow me down too much and not really facilitate my design workflow in the way that I needed it to work. So I tried to aim for something as a sweet spot in the middle which is like could I centralize these prototypes so that we could build on them collectively as a team and kind of get that compounding benefit over time. But while preserving all of that flexibility that I wanted from just like the open-ended prototyping ability.

快速插播一条消息，然后我们继续。自从 Paper 通过他们的 MCP 推出 tokens 以来，我能够用智能体设计和探索的质量绝对飙升。画布上呈现的一切看起来都与生产环境无异。现在你可以在 Paper 内部直接创建和编辑 tokens。他们真的把用户体验做到了极致。比如，你甚至可以在文件之间复制粘贴 tokens。这只是 Paper 成为我首选设计工具的又一个原因，我强烈推荐它。前往 dive.com/club/paper 立即开始设计吧。另外，Framer 刚刚发布了自我开始使用以来最大的一次产品更新，叫做 Framer AI Agents，自发布以来他们做了大量改进。我个人最兴奋的是它现在消耗的 tokens 少了很多，尤其是在大型多步骤构建中。这给了你更多空间，在同样的预算内创建和完善你的工作，我已经从中获益良多，同时我在为即将到来的 Dive 网站探索很多大胆的想法。用 Framer 构建专业网站比以往任何时候都更有趣、更高效。我完全沉迷于他们的最新版本。如果你前往 dive.club/framer，可以享受 Framer Pro 七折优惠，和我一起开始构建吧。现在，回到正题。我想了解开发的不同阶段，以及你实际上是如何把这个东西变成现实的。但也许先让观众了解一下你做了什么，它是如何工作的。你能快速演示一下，并描述一下这套工具实际上如何帮助你作为设计师实现目标吗？

Real quick message and then we can jump back into it. Ever since Paper launched tokens via their MCP, the quality of what I'm able to design and explore with agents has absolutely skyrocketed. Everything that lands on the canvas looks indistinguishable from production. And now you can create and edit tokens directly inside of Paper. And they kind of nailed the UX. Like, you can even copy and paste tokens between files. It's just another reason why Paper has become my go-to design tool, and I cannot recommend it enough. Head to dive.com/club/paper to start designing today. So, Framer just had its largest product release since I started using it. It's called Framer AI Agents, and they've been making a ton of improvements since launch. The one that I'm personally the most excited about is it uses way less tokens now, especially on larger multi-step builds. So, this gives you more room to create and refine your work within the same budget, which I'm already getting a ton of benefits from while I explore a lot of out there ideas for the upcoming Dive website. Building pro websites with Framer is more fun and more efficient than it has ever been. I'm completely obsessed with their latest version. And if you head to dive.club/framer, you can get 30% off Framer Pro to join me and start building today. Now, on to the episode. I want to get into the different phases of development and how you actually brought this thing to life. But maybe just to give people watching an idea of what you made, how it works. Can you just run us through a quick demo and kind of paint the picture of what does this set of tools actually help you accomplish as a designer?

好的，我们开始吧。作为产品设计师，我们经常是从产品中已有的界面分支出来的。所以，简单介绍一下背景，我在一家叫 Sublime Security 的公司工作。我们是一家邮件安全公司。我们应用的主视图是邮件列表，这些邮件来自你的组织，我们标记为潜在恶意邮件。所以，我整理了我称之为“蓝图”的东西，这些只是忠实于生产的参考界面，你可以从这些界面开始设计流程。这里有一个例子，我们马上就会用到。我启动新项目的方式就是直接和这里的 Cursor 对话。我们开始吧。嘿，我想创建一个新的原型。这个原型将基于消息列表视图蓝图，具体来说是“需要修复”视图。这将用于 Dive Club 演示原型。我们只需要用那个视图设置原型，然后从那里迭代。

Yeah, let's do it. So as a product designer, very often we are branching off of a surface that already exists in the product. So for context, I work for a company called Sublime Security. We're an email security company. The main view in our app is this list of emails that are coming through your organization that we've highlighted for you as being potentially malicious. So, I've curated these what I call blueprints, which are just these production faithful reference screens that you can jump off of for a design process. Here's the example of that view that we'll end up using here in a second. And the way that I would start a new project is I just talk to Cursor here. And let's do it. So, hey, I want to create a new prototype. This prototype is going to be based on the messages list view blueprint, specifically the needs remediation view. This will be for a Dive Club demo prototype. And all we need to do is just set up the prototype with that view and then we'll iterate from there.

好的。那么，在加载这些蓝图的时候，你是否在单独的沙盒环境中重新创建了完整的前端？这些就是那些吗？所以，它们只是某种起点，人们可以拿来用。

Okay. So, while that's loading these blueprints, have you recreated like the full front end in a separate sandbox environment? Is that what those are? So, they're just kind of starting points that someone can reach for.

它们是起点。我经历了一个过程，不是完全精确地重新创建它们，而是能够从生产环境中将它们作为我想要的特定视图的快照移植过来。所以，智能体会处理。我们完成了。它在这里设置了我们的新原型，Dive Club 演示。点击这里。这是我们原型的详情页面，我们的视图会随着时间推移收集在这里。它只是把消息列表视图拉到这里，让我们开始，这很棒。现在，我要做的是，我会让它——实际上，我直接说出来。好的，太好了。那么，既然我们有了那个视图，我想让你设置一个画布，这样我们就可以直观地看到这些新的迭代。然后我还想让你对消息列表视图进行设计评审，特别关注过滤器。我们想通过设计原则的视角来审视它们，了解哪些地方可以改进。我们继续。所以，现在是时候看看设计原则了。这些是我们团队自己写的。它们相当轻量级，在具体执行方面不是特别具体。它们是更高层次的原则。

They are starting points. I've gone through a process of not fully recreating them exactly, but being able to port them over from production as these kind of snapshots of specific views that I want. So, the agent will work. We got this done. It's set up our new prototype here, Dive Club demo. Click in here. This is just our detail page for our prototype where our views will collect over time. And it's just pulled this one messages list view in here for us to begin from, which is great. Now, what I'm going to do is I'm going to have it I'll just speak it out actually. Okay, great. So, now that we have that view, I want you to set up a canvas so we can start to view these new iterations visually. And then I also want you to run a design critique on this messages list view, specifically focusing on the filters. We want to kind of put those through the lens of our design principles and understand where there might be areas for improvement that we can work on. We'll get it going again. So, it's a good time to maybe bop over to the design principles. So, these are written by us by our team. They're pretty lightweight. They're not super specific in terms of like exact execution or anything. They're higher level principles.

但由于这些和原型一起放在仓库里，智能体就能这样引用它们，把它们当作设计工具来用。所以它做了一些工作，为我们搭好了这个画布。这就是我们的画布，哇哦。我们把评审文档放在这里，还拉进来一个视图，那只是现有视图的直接分支。那我们来看看它对评审说了什么，看看我们是否同意。

But because these live in the repo here alongside the prototypes, the agent can reference them in this way to be able to use them as a tool for design. So it did some work. It set up this canvas for us. So here's our canvas. Woohoo. We've got our critique doc laid out here and we've got our one view that we've pulled in. That was just a direct fork of the existing view. So, let's take a look at what it said for its critique and see if we agree with it at all.

好的，一句话结论：筛选器给了分析师真正的控制权，但它们把任务形态的收窄埋在了系统形态的菜单后面，还把问题定义重述成好像是用户自己选择的东西。然后它逐条原则分析，拆解哪些有效、哪里出问题，并给出评分。比如，在“让用户掌控”上给了个中等评价；在“只显示所需内容”上指出重大问题，这点我同意。这个领域长期资源不足。在“以价值为先”上表现也不太好；“有层次地加深细节”方面我们还能做得更好，等等。所以它给了我这样一张小记分卡。我还让它写了一些“我们如何能”的提示，来推动下一步，也就是做一些发散性探索。

All right, oneline verdict. Filters give analysts real control, but they bury the taskshaped narrowing behind a system-shaped menu and restate the Q definition as if it were something the user chose. So, it goes principle by principle, kind of breaks down what's working, where it's breaking, and it gives it a rating. So, like, all right, mixed rating on keeping users in charge. Major issue with showing only what's needed, which I think I would agree with. This is an area that has been sorely underresourced for quite a while. Leading with value, also not doing so great. Layering depth intentionally, we could be a little bit better, and so on and so forth. So, give me this little scorecard. And I have it write out some how might we prompts to kind of spur our next step, which is to do some divergent exploration.

所以，现在我想让你做的是，针对评审中得出的那些“我们如何能”的陈述，创造一些变体。我们想用低保真度来做。我觉得我想要三到五个不同的变体，来解决其中一些问题。开始前如果需要更多澄清，可以问任何后续问题。

So, now what I want you to do is I want you to create some variance on how we might address the how might we statements that came out of that audit. We want to do this in low fidelity. And I think I'm looking for, you know, between three to five different variants that might address some of those issues. Ask any follow-up questions if you need more clarity before beginning.

我的提示词也总是这样。就像隔了三秒，然后我说，其实，再多问些后续问题。

That's always what my prompts look like, too. It's like a 3-second gap, and I'm like, actually, ask more follow-up questions, too.

是啊，你永远感觉没被理解。

Yeah, you never feel seen.

在我构建之前——哦，好吧。它想让我选一个具体的数字，我不能只说三到五个。好吧，那就五个变体。为了覆盖面，每个都应该是不同的结构赌注。是的。至于优先级，“我们如何能”就交给你了。你可以选择每个框架的范围。保持聚焦，但我也想看到表格结果，不只是筛选器，这样我才能那样理解上下文。还有，请在画布上添加一个探索区，这样我就能在那个屏幕上比较它们。

Before I build— Oh, okay. It wants me to pick an actual number. I can't just say three to five. Okay, let's do five variants. For coverage, they should each be a different structural bet. Yes. Uh, for the priority, how might we? I leave it up to you. You can pick scope of each frame. Keep it focused, but I do want to see table results as well, not just the filters, so that I can contextualize in that way. And yes, please add an exploration section on the canvas so that I can compare these on that screen.

你有没有过这样的时刻，退后一步，惊叹于你的设计实践每天都在变化多少？哦，光是看你工作就很好笑。两年前我们会觉得这太好笑了。

Do you ever have a moment where you just step back and you're in awe of how much your design practice has changed on a daily basis? Oh, like just watching you work is hilarious. We would have found this hilarious two years ago.

绝对会。去年十二月我都会觉得这很好笑。

Absolutely. I would have found it hilarious in this December of last year.

是啊，可能吧。嗯。

Yeah, probably. Yeah. Yeah.

呃，去年十二月我大概 95% 的时间都还在 Figma 里，现在几乎从来不用 Figma 了。所以变化非常快，以至于我终于到了这样一个点：我已经构建了足够多的东西，可以退后一步喘口气，真正思考一下，而不是全速冲进这片未知领域。

Uh, I was very much still just like in Figma 95% of the time in December, and now I'm almost never in Figma. So, it has been a very fast shift, to the extent where like I'm finally at the point where I have like enough built where I feel like I can kind of step back and take a breather and like actually think about it rather than just forging full steam ahead into this unknown territory.

你觉得这对你工作的质量和数量有什么影响？

How do you think it's impacting both the quality and the quantity of your work?

质量和数量。质量方面，我觉得影响相当大，但有些方式可能出乎意料。比如企业网络安全，这些工具永远不会是最性感、能在 Twitter 上获得很多赞的那种，不幸的是。但构建这类工具确实需要大量系统设计类的东西，尤其是在我们运营的那种规模下。所以，在脱离代码的静态环境中做这类工作，总是比实际需要的难得多，因为你得思考大量状态组合，这些组合很难真正理解，直到你以某种代码形式拿到东西，才能明白你的想法到底有没有意义。所以从那个角度看，它让我能做的系统思考和探索，对我的工作来说是一个巨大的改进。而且，在我能在这里做出所有这些高保真屏幕之前，这个的初始迭代只是非常粗略、低保真外观的原型，它们帮我们团队想清楚了这个应用需要覆盖的状态。

Quality and quantity. So quality, I think it's impacting quite a bit, but in some ways that people might not expect. Like enterprise cyber security, the tools are never going to be like the sexiest looking thing that are going to get a lot of likes on Twitter, unfortunately. But there's really a lot of like systems design type of stuff that needs to go into building that type of tool, especially at the kind of scale that we operate at. And so doing that kind of work in like a static environment detached from the code was always way harder than it probably needed to be, because you're trying to think through like a ton of different combinations of states that are just hard to grok until you actually get something in some form of code to be able to understand whether your idea even makes any sense at all. So there's just from that lens, like the kind of systems thinking that it's enabled me to do and the exploration has been like a huge improvement for my work. Uh, and before I could make all these like high-fidelity screens in here, the initial iteration of this was only like really sketchy low-fi looking prototypes that helped our team a lot just think through the states that we needed to cover for this kind of app.

这其实引出了另一个快速问题。你是怎么设置数据的？是仅仅根据数据库中的模式生成一堆 UI 吗？这些都没有连接到实际的生产数据，对吧？

That actually brings up another quick question. How are you setting up the data? Like is it just generating a bunch of UI based off of like the patterns in the database? None of this is hooked into actual production data, is it?

没有，完全没有连接到生产数据。都是模拟数据，只存在于原型的上下文中。它最初是基于这个视图，比如说，这是我们在原型环境中的重建。所以有一个关联的数据对象，和这个屏幕一起存在，驱动着体验，并且是基于我们前端使用的实际数据模型建模的。所以来回转换非常容易，但都是本地模拟数据，形状符合生产环境预期。

No, not hooked into production data at all. It's all mock data that just lives in the context of the prototype. It is based originally, like with this view, let's say. This is kind of our recreation in the prototype environment. And so there is an associated data object that lives kind of along with this screen that powers the experience and is modeled on, you know, the actual data model that our front end uses. So it translates back and forth very easily, but it is all just local mock data in the shape that production expects.

我完全以为这些会是截图。这些不是有悬停状态的截图。

I totally assumed that these would be screenshots. These aren't screenshots that had a hover state to it.

这些不是截图。这其实是这个工作流中非常重要的一部分，所有这些都是可交互的。这对我的工作流很重要的原因是，你现在可以看到它创建了五个变体。它创建了一个“定义在外”的，不管那是什么意思；还有“任务优先工具栏”、“持久应用状态”、“侧边栏”，非常不同，以及某种带建议筛选器的队列，我猜。但通常我把它当作一个表面，来看智能体在做什么，然后我用注释工具，这里用的是 Cursor，但如果你想，也可以在 Claude Code 或 Codex 里做同样的事，你可以直接在这些上面注释，因为它们渲染的是实际代码本身。所以我不需要跳进这个视图来给它反馈，但你可以。

These are not screenshots. And that's actually a very important part of this workflow, uh, is that all of these are interactive. The reason that that's really important for my workflow here is like you can now see that I have my five variants that it created. It created one with definition outside, whatever that means. Task first toolbar, persistent applied state, side panel, very different, and some kind of queue with suggested filters. I guess. But often I'm using this as a surface to kind of see what the agent is doing, and then I'm using the annotation tool, in this case in Cursor, but you could do the same in Claude Code or Codex if you wanted, and you can just annotate directly on these because they are rendering the actual code itself. So I don't have to like jump into this view to give it feedback, but you can.

是啊，很酷。所以它做了一些简化，移除了一些我们做的额外快速筛选器。这个有一些额外的设置。不太喜欢那个。我敢说这可能会被我们的工程团队直接否决，把筛选器完全移到左侧面板。那比如说，假设我们喜欢这个“任务优先工具栏”，但也许我们想做更多迭代。我们就给它一些反馈。所以这个方向看起来很有成效，但我对视图的命名有点困惑，也对在应用这些额外筛选器之前、生成这个视图的顶层筛选器的理解有点困惑。

Yeah, it's cool. So, it's done some simplification of removing some of the additional kind of quick filters that we do. This has some kind of additional setup. Not really loving that. I'm going to say that this is probably going to be a hard pass from our engineering team, entirely shifting the filters to a left panel. So let's just say for instance that we like this one, this task first toolbar, but maybe we wanted to do a little more iteration. We'll just give it some feedback. So this direction is looking fruitful, but I'm a little bit confused about the naming of the view and sort of the understanding of the filters that are applied at the top level that generate this view before we apply these additional filters.

那么，你能再试一次，针对这些问题迭代这个变体吗？

So, can you take another stab at iterating on this variant to address those issues?

你能看到自己在个人流程中迭代出的清晰方法吗？就是那种用 AI 生成三到五个不同选项的做法。因为感觉这已经成为如今 AI 辅助设计师工作的关键部分。然而，也有可能一直得到毫无意义的结果。所以我想知道，你是否调整了思考提示词或结构的方式？或者说，你是如何锻炼这种让 AI 替你探索的能力的？

Are you able to see clear ways that you've iterated on your personal process of just seeing the three to five different options with AI? Because it feels like that's become such a key part of how AI enabled designers are operating today. And yet, it is possible to just consistently get nonsense. And so I'm wondering like have you tweaked the way that you think about prompts or structure or like how have you grown this muscle of having AI explore on your behalf?

如果这是在真实工作中，我会在前期花更多时间做这种批判性思考，并设定好我真正希望它探索的方向。你知道，我们这里有点随性而为，只是为了快速得到一些结果，但我会真正聚焦于我希望它关注的具体点。然后，在它真正生成任何 UI 之前，我可能会让它先用文字向我描述这些潜在的方法，然后我会以这种方式审查，因为这样我能更快地理解，比如这个方向看起来对，那个方向看起来不对。我会先以这种方式迭代，一旦我们稍微缩小范围，并且我对每个概念做了初步筛选，然后我才会让它生成我们要看的 UI。

If I'd be doing this in real life, I would have spent more time up front here on sort of like this critique and setting up what I really wanted it to explore. You know, we kind of just yoloed this here to get some results quick, but I would be really dialing in like specifically where I wanted it to focus. And then I would be probably having it before it actually generates any UI here at all. I would just have it describe these potential approaches to me in text and I would review it that way because it would be quicker for me to grok like that seems directionally right, that seems directionally wrong. And I would have iterate that way first and then once we've narrowed it a little bit and I've sort of vetted each concept slightly then I would have it generate the UI that we would look at.

所以它在这里做了一些更新。再说一次，在真实工作中我会采用这个吗？可能不会。但要点是，你能够以这种低保真度进行发散性探索，这仍然在底层使用我们实际的生产保真度 UI，然后只是用我们的手写字体覆盖它，并使其变成灰度，以便更清楚地表明我们在设计过程中所处的阶段。

So it made some updates here. Again, would I roll with this in real life? Probably not. But the gist is, you know, you're able to kind of do this divergent exploration in this low fidelity, which is still using our actual production fidelity UI under the hood and then just sort of overwriting it with our handwritten font and making it grayscale to make it more obvious where we're at in the design process.

有趣的是，现在我们使用这些工具时，几乎不得不重新引入保真度的概念。这真是个迷人的概念。比如，这是你添加的东西吗？你的起点是低保真度吗？因为我几乎不再做低保真度的工作了，因为那更难做。所以，你是故意把它作为一等公民吗？你是如何考虑保真度在这个产品中扮演的角色的？

It's so interesting that we almost have to like retrofit the fidelity now that we're doing these using these tools. It's such a fascinating concept. Like is that something that you added like is was that your starting point was doing things at low fidelity? Like I just don't really do much at low fidelity at all anymore almost cuz it's just it's more difficult to do. So like did you make that a first class citizen intentionally? Like how did you think about the role that you wanted Fidelity to play in this product?

嗯，我一开始使用低保真度，仅仅是因为，回到你之前关于项目初始范围的问题，我知道我肯定没有时间或资源让它快速或立即达到我们的生产保真度。所以，我不想通过创建接近生产保真度但实际上并非生产保真度的东西来误导人们。然后我最终会面临巨大的沟通差距，比如人们看到非常高保真度的东西，但它并不完全正确，所以他们误解了。所以我完全想避免这种情况，我只是选择只使用低保真度开始，然后从那里出发。

Well, I started out in low fidelity simply because to your question earlier about the initial scope of this project, I knew that I definitely didn't have time or the resources to get it to match our production fidelity fast enough or right away. So, I didn't want to mislead people by creating something that was like almost production fidelity but not actually production fidelity. And then I end up with this big communication gap of like people looking at something very high fidelity but it's not quite right and so they misinterpret. So I wanted to avoid that entirely and I just opted to be like I'm only going to use low fidelity to begin with and go from there.

所以这些是我最早的探索。这些东西是在 Claude 中用 artifacts 完成的，在所有这些功能存在之前，我只是把它们拉到这里，现在可以在画布上为你可视化它们。但我让它帮助我思考我们的产品如何处理电子邮件，并展示一些我们可能进行配置的不同方式。比如在这个实例中，我们做了多少种不同的变体，这个类型有八种，这个有五种。我当时在利用这些。我截图，把它们拉回 Figma，利用那个功能获取人们的看法。那是一个非常缓慢、费力的循环，即使只是能够把这些屏幕放到这里，在我对画布或任何其他东西有概念之前，把东西集中在一个地方，以便随着时间的推移进行构建，也是很有帮助的。

So these are my earliest explorations. These things were done in Claude with artifacts before any of this existed and I just pulled them in here and now can kind of visualize them on the canvas for you. But like I was having it kind of help me think through how our product processes emails and just expose some different ways we might do the configuration. So like in this instance we did how many different like eight different variants on this kind, five different variants on this one. And I was using those. I was screenshotting them, pulling them back into Figma, getting you know people's takes on them using that functionality. And that was just such a slow, laborious loop to kind of go through that even just being able to get these screens in here before I had any sense of like the canvas or any of this other stuff was helpful to just have it centralized somewhere uh to be able to build on stuff over time.

你能跟我谈谈这如何融入你们设计团队的协作方式吗？如果你到了想要分享某些东西或让其他人参与反馈的地步，你实际上会指向哪里？画布上有什么？你是如何考虑这部分流程的？

Can you talk to me a little bit about how this fits into the way that you collaborate as a design team? If you get to the point where you want to share something or loop people into feedback, where are you actually pointing them? What is on that canvas? How are you thinking about that part of the process?

好问题。坦率地说，这是一个持续的挑战，首先我需要弄清楚如何以安全的方式进行部署，因为我们毕竟是一家安全公司。所以我们对内部工具的安全标准相当高。这是用 Vercel 部署的版本。在底层，这一切的结构是使用 Vite 构建的。Vite 或多或少充当静态站点编译器，将所有 React 视图聚合到一个我们可以部署的静态站点中。所以从安全角度来看，他们一开始对此更开放，因为没有后端，没有用户系统。基本上没有什么可被黑客攻击的。它只是一个网站。所以这是我绕过一些潜在组织障碍的一种方式，比如“哦，设计师要求部署代码，我们对此不了解”。

Good question. This was an ongoing challenge frankly is that first I needed to figure out how to do deployment of this in a safe way because we are a security company after all. So we have a pretty high standard for security for our own internal tools. This is the deployed version that is deployed with Vercel. So the way that this all is structured under the hood is that it's built with Vite. Vite sort of acts as a static site compiler more or less that aggregates all of these React views into a static site that we can deploy. So from a just a security standpoint, they were more open to this to begin with because there's no backend. There's no user system. There's like not really anything to be hacked about it. It's just kind of a website. So that was one way that I got around some of the potential organizational hurdles of like oh designers are like asking to deploy code like where we don't know about that.

在收集反馈方面，那是一个持续的缺口。所以即使我可以分享这些原型之一的链接，让人们通过 URL 查看并与之交互，我也无法以人们最习惯的方式收集反馈，比如 Figma 评论，对吧？所以直到最近我才意识到 Vercel 实际上有一个工具，你可以用它直接在部署上添加评论。它叫做 Vercel 工具栏。你可以使用他们的评论工具，我可以打开一个原型，或者在这种情况下，在这个表面的任何地方，我可以像“嘿，添加一个评论”，然后这就会出现在设计上。假设这些是一些探索，所以在这里评论什么都不重要，但比如“把按钮做大一点”。这个工具栏的工作方式是，即使在画布上，它也会遵循这一点。所以通过这种方式，它涵盖了很多我觉得在收集反馈方面缺失的基础。

In terms of gathering the feedback that was an ongoing gap. So even though I could share a link to one of these prototypes and get someone to look at it and like interact with it using just via the URL, I couldn't collect feedback on it in the way that people were most comfortable with, which is like Figma comments, right? And so only recently did I realize that Vercel actually has a tool that you can use to put comments directly on your deployments. So it's called the Vercel toolbar. And so you can just they have a commenting tool and I can you know open a prototype or in this case really anywhere on this surface I can be like hey rid it's a comment and like this will now appear and it lives on the design. Let's say these are some explorations so it doesn't really matter if I comment on anything here but like make the button bigger. The way that this toolbar works is like it'll still even adhere to that even on the canvas. So in this way it's covered a lot of the bases that I felt were missing from the just collecting feedback aspect of.

是的，我也感觉到了，对于这个特定的工作流程，即使感觉我们被 AI 赋予了超能力，我们的构建能力增强了，但所有的协作基础设施似乎都回到了石器时代。

Yeah, I felt that too for this specific workflow even where it feels like we have been given superpowers by AI and our ability to build things but then it feels like all of the collaboration infrastructure has just went back to the stone age.

完全同意。是的，我如何分享我的东西？比如我有三个不同的想法，我希望你选一个。我该怎么做呢？你知道，所以看到你完全回到了那些早期的基于画布的原语，这很有趣。

Totally. Yeah, how do I share my stuff? And like I have three different ideas. Like I want you to pick one. How do I even do that? You know, so it's interesting to see that you went full loop back to some of those early canvas-based primitives.

是的。几乎立刻，人们就开始要求评论系统了。

Yeah. And pretty much right away, people were asking for a commenting system.

我确信。

I'm sure.

我当时想，对不起，但我不能构建评论系统。

And I was like, I'm sorry, but I can't build a commenting system.

那对我来说太复杂了，构建起来太难了。光是搭建所有这些其他基础设施就已经够难的了，然后你一旦开始在这上面叠加一整套额外的表面，而且评论还需要某种真正的后端来持久化存储等等。所以让我们结束这个小探索的循环吧。正如我们提到的，这些只是实际内容上的低保真覆盖。所以让我们让它把其中一个带到高保真，然后我们就能结束这个循环。好的，这个看起来很不错。我希望你现在把它带到高保真，并放在画布的一个新分区里，这样我们就能清楚地看到这是高保真版本。

That's like way too complex for me to build. It's been hard enough to build all this other infrastructure, and then as soon as you start to layer on this whole extra surface on top of everything else, and the comments need an actual backend of some kind to be able to persist them and stuff like that. So let's just close the loop on this little exploration. As we mentioned, these are just low-fidelity sort of overwrites on the actual thing. So let's just ask it to bring one of these into hi-fi and we can kind of close that loop. All right, this one is looking pretty good to me. I want you to now bring this into high fidelity and put it in a new section on the canvas so that we can clearly see that this is the hi-fi version.

说实话，自从智能体式编码工具发布了直接对元素给出具体反馈的能力之后，我的工作流程都发生了巨大变化。那是一个巨大的解锁。

Honestly, even my workflow has changed so much just since the agentic coding harnesses released this ability to directly give specific feedback on elements. That was a huge unlock.

那很快就成了行业模式。

That became the industry pattern so quickly.

我看到了你和 Anthropic 的 Nate 一起的那个片段，他在演示那个指向东西的功能。

I saw your clip with Nate from Anthropic where he's showing that one where he's pointing at things.

是的，那是你接下来要构建的东西。

Yeah, that's your next thing to build.

我觉得那可能不会排在最前面，但那个功能的精神是在的。

I feel like somehow that won't make the top of the list, but the spirit of the feature is there.

我的意思是，很有趣的是，即使你在做评论时，你仍然在口述。这有点像我的经历。最初评论来了，它就变成了肌肉记忆，就像我就直接打字，你知道，这就是我做的。现在我就想，不，我就指着说，伙计。这就是我作为设计师做的。我指着说。我看到东西。我更多地指着说。而你围绕它构建了一个完整的工具，这很酷。

I mean, it's interesting to see that even when you were doing the comments, you're still dictating. That's kind of been my experience, too. Originally the comments came and it just became muscle memory, like I'm just going to type, you know, this is what I do. And now I was like, no, I just point and talk, man. That's what I do as a designer. I point and talk. I see things. I point and talk more. And you kind of built an entire tool around it, which is cool.

而且我从一开始就诚实地、有意地这样做了。我们看到的这个 UI 实际上只是一个渲染表面。用户不会通过这个 UI 采取任何操作。它被有意设计为在这些智能体式编码工具的上下文中使用，其中主要且唯一的交互就是与智能体沟通。所以它做了一个高保真版本。所以你可以看到它采用了相同的结构。它只是把它提升到了“我们的过滤器可能看起来像这样”等等。所以你可以看到那个一般的循环：从某物分支出来，能够做一些低保真探索，然后把它提升回高保真。

And I did that honestly intentionally from the start. The UI that we're looking at is really just a rendering surface. There are no actions that the user takes through this UI. It's designed intentionally to be used in the context of these agentic coding harnesses where the primary and exclusive interaction is communicating to the agent. So it made a high-fidelity version. So you can see it took that same structure. It just kind of lifted it into here's how our filters might actually look and so on. So you can kind of see that general loop of branching off of something, being able to do some low-fi exploration and sort of level it back up into hi-fi.

我觉得在工具层面存在着一整个设计和工程层次。就像这个工具到底是做什么的？有趣的是它把它放在了自己的行里。所以你显然给出了一些指导，比如“嘿，这里大致是我想要如何组织工作的思路”。你能谈谈那个层面的设计吗？比如，是什么让这样的东西开箱即用就很好，而不是你从 Claude 那里得到的默认功能？

There's like a whole level of design and engineering that exists, I guess, kind of at the harness level. It's like what does this tool even do? It's interesting that it put it in its own row. So you've obviously given some guidance around, hey, here's generally how I want to think about organizing work. Can you talk about that level of design? Like what went into making something like this good out of the box versus what you would get as just default functionality from Claude?

完全同意。这整个环境最大的挑战之一就是它是一个开发环境，但却是为非开发者构建的。所以我从一开始就必须假设，我构建的任何功能，我都不能假设人类用户会做任何事。总是智能体代表他们做事。所以我需要从一开始就设置很多护栏，甚至只是帮助设计师做那种 git 工作流。所以这是我们的工具文档，针对你提到的这些概念。所以就像我们看到的画布，这是一个官方功能，它有我定义的数据结构，我和智能体一起构建的，我定义了这些术语。我相当没有原创性。我把它叫做画布、帧、行中的分区。所以，抱歉 Figma，我在这方面只是在抄袭你。但是是的，所以我定义了系统中这个对象是什么。我定义了结构应该如何工作，并为智能体布置了它，让它理解这个东西是什么，如何使用它，如何构建这些分区并在其中组织帧。这一切都来自我个人的工作流程。

Totally. That's been one of the biggest challenges of this whole environment is that it is a dev environment but it's built for non-developers. So I kind of have to assume from the start that any feature that I'm building, I cannot assume that the human user will be doing any of it. It's always the agent doing stuff on their behalf. And so I needed to set up a lot of guardrails from the start to just even help designers do the kind of git workflow. So this is our documentation for the tool, to your point about some of these concepts. So like what we're looking at as a canvas, this is like an official feature that has its own data structure that I defined and I built with the agent, and I defined these terms. I was pretty unoriginal. I called it a canvas, a frame, a section in a row. So, sorry Figma, I'm just copying you in that regard. But yeah, so I defined what this object is in the system. I define how the structure should work and sort of lay it out for the agent in terms of understanding what this thing is, how to use it, how to structure these sections and organize frames within it. This is all opinionated from my personal workflow.

是的。

Yeah.

即使我在 Figma 中工作时，我也会以这种方式组织我的交接。我想这是一种非常故事板风格的组织。所以在这里你可以看到画布数据结构。它只是一个 JSON 文件，用来组织帧。它不会把任何帧拉进画布的上下文中。它只是指向你构建的所有其他 React 视图，或者在这种情况下是文档。这就是我一直在工作的层面，有点像代码架构师、平台架构师。

Even when I'm working in Figma, I would structure my handoffs in this kind of way. It was very storyboard-style organization, I suppose. So here you can see here's the canvas data structure. It's just a JSON file that sort of organizes the frames. It's not pulling any of the frames into the context of the canvas. It's sort of just pointing at all of your other React views that you've built or the documents in this case. That's kind of the level that I've been working at, sort of like code architect, platform architect.

想出这些对象，定义它们，与智能体合作确保它理解它是什么以及如何使用它，然后让人类用户尽可能自然地只需请求一个画布，然后智能体就知道那是什么以及如何设置它。这很酷，因为这有点像系统思维的终极练习。

Coming up with these objects, defining them, working with the agent to make sure it understands what it is and how to use it, and then making it as natural as possible for the human user to just ask for a canvas and then the agent knows what that is and how to set it up. It's cool because it's kind of the ultimate exercise in systems thinking.

完全同意。

Totally.

你构建的这个工具有很多版本，对你的团队来说非常笨重和混乱。你唯一能让它被高度采用的方法就是让它变得极其简单。

There were many versions of this tool that you built that were very cumbersome and confusing for your team to use. The only way that you were going to get this adopted at a high level is if it was just stupid simple.

100%。这是很早的一个选择。所以，我有整个关于护栏的部分。就像这是一堆不同的功能，它们一起工作，确保当另一个设计师使用 Design Studio 并说“我想创建一个关于 XYZ 的原型”时，智能体不仅知道原型是什么以及如何一致地制作一个，还知道这个人是谁，他们被允许在哪里构建，批准他们构建的范围是什么，等等。所以那是各种东西的组合，坦率地说，基本上 100% 是 DevOps，就在后台确保事情按人们期望的方式工作。我在那方面做出的一个主要选择是，你会注意到每个贡献者实际上都有自己的文件夹。

100%. One of the very early choices. So, I've got this whole section about guardrails. It's like this is a bunch of different features that work together to make sure that when another designer is using Design Studio and they say I want to create a prototype about XYZ, the agent knows not only what a prototype is and how to make one consistently, but also who the person is, where they're allowed to build, what scope is approved for them to build in, all that kind of stuff. So that's a combination of stuff that is frankly just 100% DevOps basically, that is just there in the background making sure that things work the way that people expect. One major choice that I made on that front is that you'll notice that every contributor has their own folder effectively.

所以那是智能体界定工作范围的主要方式之一。

And so that's one of the main ways that the agent scopes the work.

所以我想为人们提供的是，我想给你一个安全的空间来制作原型，并且可以尽情发挥，你在你的文件夹里做的任何事情都是开放范围。我给了你很多工具来调整某些类型的工作，但你也可以完全从头开始设计一个原型。但是如果你正在做的事情会影响其他人的工作，那就需要更高级别的审查和更典型的开发工作流程，我们要确保你推送的内容不会破坏其他人的东西。所以我的规则是，你可以破坏自己的东西，但不能破坏别人的东西。

So what I wanted to facilitate for people is like I want to give you a safe space to prototype in and kind of just go wild and like whatever you do in your folder it's kind of open range. I've given you a lot of tools to dial in certain types of work but you can just design totally from scratch in a prototype as well. But if you are working on something that is going to impact other people's work, that requires a higher level of review and more of a typical kind of dev workflow where we want to make sure that what you push isn't going to break stuff for other people. So my rule is you can break your own stuff, but you can't break other people's stuff.

有一个问题我一直忍不住问自己。

There's one question that I can't stop asking myself.

如果公司主动申请与你交谈，而不是你去找他们，会怎样？这个问题正是全新 dive 人才网络的基础。而且它正在奏效。比如现在，我正在帮助我认识的最令人兴奋的初创公司，去雇佣那些收听本节目的设计师和开发者。所以，如果你好奇外面有什么机会，也许你想加入我的名单，或者你正在寻找下一位设计人才，请访问 dive.club/talent 立即加入。

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.

你能谈谈交接这部分吗？比如说你拿到了那个高保真原型，已经调好了，然后呢？

Can you talk a little bit about the handoff piece? Like let's say you get that high fidelity prototype, it's dialed in, then what?

所以我们团队目前正在集体摸索这件事。大部分情况下，我现在推荐的做法是：这只是一个公司内部的另一个代码仓库，工程师可以拉取那个仓库，在本地机器上拿到代码，然后让他们的智能体指向它。所以我在这个演示原型里可能做的最后一件事——哦，我想我不需要在这里特别标注什么。我就说，嘿，这个原型看起来不错。我们想为设计交接做准备。所以我希望你总结一下这个文件里工程师和他们的智能体需要注意的最重要的事情。这也是我一直在思考的新方式：我不再只是把设计交给工程师，而是在准备让工程师的智能体重新诠释这个设计。

So we are, you know, in the process of figuring this out collectively as a team. For the most part, what I'm recommending now is that this is just another internal repo within the company, and the engineers can pull that repo and they can have the code locally on their machine and they can point their agent at it. So the last thing that I might do in here in this, you know, demo prototype that we're working on—oh, I guess I don't have to annotate anywhere specific for this. I'll just say, hey, this prototype is looking pretty good. We want to prepare it to do a design handoff. So I just want you to kind of summarize the most important things to pay attention to in this file for the engineer and their agent. That's been a new way that I've been thinking about it too, is that I'm no longer really handing off designs just to an engineer. I am pretty much preparing the design to be reinterpreted by the engineer's agent.

嗯。

Yeah.

然后工程师会从那里接手引导。

And then the engineer will steer it from there.

是的。这是个很好的思考方式。我觉得我自己最近也刚刚经历了这个转变。我在想，做这件事的最佳方式是什么？我最近一直在做 Supercut 视频，因为我觉得，你甚至不需要看这个，直接把它喂给你的智能体就行。你知道，在这种情况下，它生成了一份非常简单的设计交接文档，虽然我们这里只有一个屏幕，但就像说：嘿，看看这个。这就是你要构建的基础。别错过这几件事。如果需要，这里还有一些额外的上下文。这里有一些要忽略的东西。所以，从很高的层面来说，这是我正在积极尝试解决的问题。我们最近才达到这个程度：这个工具里能达到的保真度，已经非常接近我们生产环境想要的效果，所以来回转换就变得有意义了。

Yeah. It's a great way to think about it. I feel like I've just been making that shift recently for myself, too. I'm like, what's the best way to even do this? Like I've been rambling on Supercut videos more recently, just cuz I'm like, you don't even have to watch this. Just feed it to your agent. You know, in this case, it makes this very simple design handoff doc, which, you know, we only have one screen in here, but it's like, hey, take a look at this. This is like what you want to build from. And don't miss these couple things. Here's a little bit extra context if you need it. Here's some things to ignore. So, very high level. This is something I'm actively working on trying to figure out. We've only recently reached this point where like the level of fidelity that we can get in this tool is so close to what we want in production that it makes sense to kind of just translate back and forth.

我想说，即使是现在，当我在产品中已有的界面上审查高保真屏幕时，我也经常问：这和生产环境匹配吗？因为我把生产代码库作为这个仓库的兄弟仓库拉下来了，智能体知道去哪里找。它会去生产环境里查看，检查是否真的匹配，如果不匹配就更新。所以我一直在交叉引用，比如：我们去看看生产环境，看看它做了什么，然后把它带回原型里。我猜工程师也可以朝相反的方向做同样的事情。

I would say that my process even these days for when I'm reviewing high-fidelity screens in a surface that already exists in the product, I'm very often asking, does this match production? And because I have the production codebase pulled as a sibling repo to this repo, the agent knows where to look. It'll go look in production. It'll check if it actually matches production, and then it'll update if not. So like I just am constantly cross-referencing of like, let's go look at production and see what production does, and then bring it back into the prototype. And I imagine that engineers can do the same in the opposite direction.

实际上，我自己上周也开始这么做了，因为出于相似但又不完全相同的原因，我在生产环境中快速制作原型遇到了困难，所以我想，干脆做一套重复的组件吧，我正在尝试找出最好的方法，确保它能持续地移植——你知道，它必须完美，必须字面意义上的完美。

I've actually started doing that down to the last week myself, because I for similar but also different reasons, I'm having difficulty prototyping quickly in prod, and so I was like, man, let's just make a duplicate set of components and I'm trying to figure out what are the best ways to make sure that it can consistently port at a—you know, it has to be perfect, it has to literally be perfect.

到目前为止，效果相当不错，非常好。过去我对重复代码非常恐惧，但现在我突然觉得，我其实不在乎了。我愿意复制所有东西，就在前端领域里玩，因为智能体基本上能够执行并把结果带回生产环境的文件夹系统。完美。

And so far it's been pretty good, quite good, where I've had so much fear around duplication in the past, where all of a sudden now I'm like, I don't actually care. I'm down to duplicate literally everything and just play in frontend land, cuz the agents are basically able to execute and bring it back over to the production folder system. Perfect.

完全同意。这正是我的状态。我觉得如果过去你告诉我，我也会有和你一样的反应。我会说，什么？你想让我维护这一整套独立的东西？你知道，那工作量太疯狂了。如果是一个真正的人来做的话。但对智能体来说，它做得到。它不在乎。它们是非常出色的翻译者。所以如果你把生产环境看作一种代码语言，它有一套自己的约束和语义，对于大规模的生产应用来说是必要的，它们理应如此。应该这样。但那些约定中有很多并不服务于设计过程，因为它们做的事情是故意让应用难以崩溃，这在生产环境中是你想要的，但在原型环境中你未必想要。

Totally. That's 100% where I'm at. I feel like in the past if you would have told me I would have had the same reaction as you. I'm like, what, you want me to maintain this whole separate thing? It was just, you know, the scope of that is insane. If you're an actual human that's doing it. But for the agent, the agent can do it. It doesn't care. They're incredibly good translators. So if you just think of like production as one language of code that has its own set of constraints and semantics that are necessary for like a production app at scale, they deserve to be that way. It should be that way. But those many of those conventions don't serve the design process because they do things that intentionally make it hard for like the app to break, which you want in production, but you don't necessarily want in prototype land.

嗯，反之亦然。我希望代码能专注于它最擅长的事情。原型环境应该最擅长做原型，并在某些方面做出权衡，这些权衡可能是你在生产环境中想要的，反之亦然。你现在看到的，就是我经历的过程，也就是你提到的组件移植。我写了一个实际上就是智能体循环的东西，我知道这很时髦，循环。我让它经历这个过程，一个接一个地处理所有这些组件，查看生产代码库，分析组件，然后在原型环境中重建它。在很多情况下，它不需要做太多改动，非常接近，但比如表单控件这类东西，生产环境中需要一大堆表单逻辑，你在原型环境中根本不在乎，而且只会碍事。所以我让它把这些东西去掉。另外，我第一次尝试让它移植东西时，没有给它足够具体的指示，它基本上是在试图修补生产组件，而不是改变它们以使其真正适合原型制作，只是对每件事都做了一些粗糙的变通。它陷入了一个疯狂的死胡同，制造了一大堆我根本无法使用的垃圾。所以我让它改变方法，从头开始构建。

Um, and vice versa. I want the code to be sort of like focused on what it needs to be best at. The prototype environment should be best at prototyping and make some trade-offs in terms of things that you might want in production, and vice versa. What you're looking at here, this is the process that I went through to your point with porting components. I wrote what is effectively an agent loop, I guess, technically. I know that's very trendy, loops. And I had it go through this process where it went one by one through all of these components and it looked at the production codebase. It analyzed the component and it sort of reconstructed it in the prototype environment. In many cases, like it didn't need to change much, like it's very close, but for instance, stuff like form controls, let's say there's a whole bunch of form logic type of stuff that you need in production that you just do not care about and just get in the way in a prototype environment. So I had it rip out that stuff. I also, the first attempt that I made at getting it to port things over, I didn't give it specific enough direction, and it was basically trying to like shim the production components and not change them to like make them really solid for prototyping, but like just kind of do these hacky workarounds around literally everything. And it went on this crazy rabbit hole and made just a ton of slop that I couldn't use at all. So I had it like change its approach and go back to building from the start.

看到这个我真的很受鼓舞。真的。比如我今天早上起草了一条推文，基本上在解释我在做什么，试图让网上的某个人告诉我这是个坏主意，因为我内心深处有个声音说：不要复制东西，但感觉这似乎是个好举措。所以看到你取得的成功，以及你在这个基础上构建了整个系统，这对我来说真的很有验证意义，也很及时。不过你肯定又往前走了好几步。所以我想问的是，我们能帮助人们理解起点是什么吗？你展示了这么多东西。

I feel so encouraged seeing this. I really do. Like I drafted a tweet this morning basically explaining what I was doing and trying to get somebody on the internet to tell me it was a bad idea, cuz I have this little thing that's in me that's like, don't duplicate stuff, but it kind of feels like it's a good move. So seeing the success that you've had and the fact that you've built this whole system on top of it is actually very validating and timely for me, and you've definitely taken it multiple steps further though. So I guess a question I have is, can we help people understand what the starting point was? You're showing so much stuff.

我觉得你在这个项目上已经投入了大概六个月甚至更久，对吧？而且你已经做得非常深入了。所以，在某个时候，我确实想帮助那些受到启发、想要在内部做类似事情的听众，让他们了解最初几步可能是什么样的，以及你是如何划定界限的，比如“这是一个可发布的工具，能为我的团队创造价值”这样的标准。

You've been working on this I think for like six plus months maybe, right? And you're super far. So at some point I do want to help a listener who is inspired and wants to do this internally understand what those first few steps might look like and where you drew the line in terms of like yeah this is a releasable utility that will create value for my team.

我准备好了来分享这段旅程，因为如果我在今年一月或二月看到自己现在的样子，我肯定会觉得这太荒谬了。我怎么可能在完成公司为客户交付设计这一日常工作的同时，还能做到这一切？另外，这个项目只是一个代码仓库，所以很酷的一点是，我可以回顾实际的代码历史，看看这个项目的主要里程碑。你可以看到，我的第一次提交，也就是这个项目的起源，是在 1 月 27 日。但基本上我所做的只是搭建了初始脚手架，以便能够引入我提到的那些低保真原型，也就是 HTML 原型。仅此而已。当时只有我和另一位产品设计师。我就想，我们能不能把我们的工作放在同一个地方？仅此而已。

I come prepared to share the journey because it was definitely—if I even showed myself this January or February, I would have been like, that seems ridiculous. There's no way I can do all that on top of my regular job of actually just making the designs that the company needs to ship for our customers. So another cool thing about the fact that this is just a code repository is that I'm able to just look back in the actual code history of what were the major milestones of this project. So you can see that my first commit, the genesis of this project, was January 27th. But basically all I did was I set up the initial scaffold just to be able to pull in those couple low-fidelity prototypes, HTML prototypes that I mentioned. And that was it. It was literally me, one other product designer. I was like, can we get our work to live in one place together? And that was it.

然后我继续沿着这条路走，当时我们所有的工作都在 Figma 中进行。所以我仍然可以制作这些原型，但我还不知道如何分享它们。回到你之前的问题，我确实没有办法获得反馈。所以我试图为自己解决的的下一个问题就是，好吧，我如何闭环这个流程？我可以在这里制作原型，我可以部署它，但我如何获得反馈？所以我在一个下午的时间里构建了一个 Figma 插件。

Then I kind of went along this journey where all of our work was happening in Figma. And so I could still make these prototypes, but I didn't really know how to share them yet. To your question earlier, I definitely didn't have a way to get feedback on them. So the next problem I was trying to solve for myself was like, okay, well, how do I close that loop of like I can make the prototype over here? I can kind of deploy it, but how do I get feedback? So I ended up building a Figma plugin in an afternoon

它会把我的原型截图并拉回到 Figma 画布上，这样人们就可以在图片上评论，这还不错。

where it would just screenshot my prototypes and pull it back into the Figma canvas so that people could comment on that image, which is fine.

它当时确实帮了我一些忙。我现在不再用了，但整个过程就是这样：“哦，好吧，我感受到了工作流程中的这种紧张感。我能做些什么来解决它？”然后迈出下一步。然后你可以看到，随着我在这里工作得更多，我开始意识到设置原型意味着什么、需要哪些组成部分，这些都有可重复的模式，我能够为智能体制作一个规范版本，让它们能够通过一条命令完成。所以现在每当我要求智能体制作原型时，都会有一条智能体规则提供指导，但底层还有一个脚本，该规则会引用它。这样就确保了每次创建原型的方式都是一致的。它会运行脚本，然后以那种方式生成原型。

It sort of served me at the time. I don't use it anymore, but like this whole process has just been like, "Oh, well, I'm feeling this tension about our workflow. What can I do to solve that?" And kind of taking the next step. Then you can see I started as I started working in here a little bit more, I started to realize these repeatable patterns about what setting up a prototype meant, what pieces went into that, and I was able to kind of make a canonical version for the agent to have them be able to do it in one command. So now whenever I ask an agent to make a prototype, there is an agent rule that gives it some guidance, but there's also just a script under the hood that that rule references. So it makes sure that the creation of the prototype is the same every time. Like it runs the script and it generates it that way.

其他事情，比如在智能体规则过时之前捕获它们。随着我不断演进环境、编写规则，然后进一步演进环境，我意识到：“天哪，我的文档过时了。”我一推送它们，规则就错了，然后智能体就不会以正确的方式使用环境，所以我必须编写一条规则，让智能体能够更新自己的规则。然后我需要引入设计系统，当我开始思考不仅要构建这个环境，还要支持产品设计原型制作时，当时最大的推动力是如何让这个工具对我们的品牌团队也有用，这样他们也能进行原型制作并发布一些工具。我必须非常清楚，在这个环境中，从设计系统的角度来看，我到底有什么可用的。所以我必须解决这个问题。我做了应用的整个设计系统部分，只是为了能够浏览可用的内容，并确保我理解代码中的内容。所以我们可以继续往下看列表。嗯，但这真的是一步一步来的，从最初的那个版本开始。

Other things like catching agent rules before they go stale. That was something that as I was evolving the environment and writing the rules and then evolving the environment some more, I'm like, "Oh god, my docs are out of date." like as soon as I push them and then the rules are wrong and then the agent doesn't use the environment in the right way and so I had to write a rule so that the agent could update its own rules. Then I needed to bring in the design systems and as soon as I started to try to think about not only building this environment but also enabling product design prototyping and then at the time the big push was how can I make this tool useful for our brand team too so they can prototype and ship some tools. I had to get really clear on like what do I even have from a design systems perspective in this environment to work with. And so I had to work through that problem. So I made that whole design systems section of the app just so I could browse what was available and make sure I understood what was in the code. So we can kind of go on down the list. Um, but it was really just one step at a time, like from that very earliest version of

把几个 HTML 原型放在同一个地方，一直到你今天看到的这个样子。

get a couple HTML prototypes in the same place all the way to what you see today.

快进到今天，就这个项目可以如何成长和扩展而言，你目前在脑海中圈定了哪些机会？

Fast forward to today, like what are some of the opportunities that you kind of have circled in your mind right now in terms of where this could grow and expand?

我认为我一直在关注的主要事情是所有的文档相关的东西，就是你刚才看到的那些，那是最近才做的，我试图实现闭环，比如从文档开始，能够捕获智能体需要的上下文，然后经历探索性的低保真阶段，再提升到高保真阶段。我已经有了这些部分，但真正把它们缝合在一起对我来说是新的领域，而且还在快速演进。我也在寻找其他工具，让人们能够捕捉和表达他们的设计意图。比如，我很想在这里面加入一些功能，让人们能够更多地手绘草图。我非常喜欢“草图到代码”的想法。那是我职业生涯初期作为设计技术专家时的工作方式。我们会作为一个团队坐在一起，在纸上进行草图绘制。我知道这是一门失传的艺术。然后我会直接进入浏览器，用代码制作原型，因为那是我开始所需的全部。所以我很想做些事情来支持更多这样的工作流程。

I think the main things that I've been focusing on all the document stuff that you're that we were showing that's very recent and trying to do that closed loop of like this process of starting from a document being able to capture the context the agent needs sort of going through the exploratory lowfi phase leveling it up into the high-fi phase like I've had those pieces but like really stitching them together is new territory for me and and continuing to evolve pretty quickly. I'm also looking at other tools that I can give for people to like capture and express their design intent. Like I would love to have something in here that enables people to sketch a little bit more. Like I really love the idea of like sketch to code. Like that's how I used to work when I was a design technologist at the start of my career. We would sit down together as a team. We would do a sketching session on paper. I know long lost art. and then I would go straight into the browser and I would prototype the code because that's all I really needed to get started. So I'd love to do stuff to enable more of that type of workflow.

然后我认为还有一些事情，比如继续提供关于设计原则的高层指导。我们正在开发一个新页面，内容是关于我们的用户画像、我们的用户是谁等等，这些提供了基础的设计背景，可以与你的原型共存，并以这种方式为原型提供信息。我认为那里也有未开发的潜力。

And then I think some of the things like continuing to provide this high-level guidance around design principles. We have a new page that we're working on that's just like context on our personas, who our users are, stuff like that that like provides that foundational design context that can live together with your prototypes and inform them in this way. I think there's untapped potential there as well.

即使只是技能方面，你知道，即使在我们的团队里，我还没有解决如何以有用的方式展示技能，让人们真正看到它，你知道，

Even just for skills, you know, like I still haven't solved even in our small team like how do I surface skills in a way that is helpful and people actually see it, you know,

对吧？是的。

right? Yeah.

目前，我把它们称为“方法”而不是“技能”，因为我还没有按照官方技能文档所规定的方式来结构化它们，但它们本质上就是技能。嗯，所以我有我们看过的那些：设计评审、如何进行探索、如何进行交接。这里是更广泛的智能体规则系统。我们有几种不同的入口点进入我们的智能体规则系统。我们当然有 CLAUDE.md，但它主要指向 AGENTS.md。同样，Cursor 规则和 GitHub Copilot 指令也是如此。它们都只是指向 AGENTS.md。然后它提供了关于哪些规则应该随每个任务始终加载的背景信息。实际上只有四条。所以我通过这个系统运行它，它首先查看这一条，关于我们已有的不同系统。

At the moment, I'm calling them methods, not skills, because I haven't technically structured them the way that the official skills documentation says to do it, but they are basically skills. Uh, so I have the ones that we looked at, the design critique, how to do explorations, how to do a handoff. Here's kind of the broader agent rules system. We have these couple different entry points into sort of like the agent rule system that we have. We've got the CLAUDE.md of course, but that mostly points at the agents MD. And then same with the cursor rules and the GitHub copilot instructions. They're all kind of just pointing at agents MD. And then that gives this context on what are the rules that should always load with every task. And there's really just four. So I run it through this system where it looks at this one first, which is about the different systems that we have in place.

它是生产原型、品牌原型，还是我们只是在处理环境本身？根据你选择哪条路径，它会路由到不同的指令。所以它会根据那条路径查看约定。如果你走产品原型路线，它会进一步深入那个工作流是什么、它应该做什么。然后它总是加载关于贡献者范围的部分。这完全是为了确保智能体在我们告诉它的边界内工作，这样你就不会遇到冲突之类的问题。然后所有这些其他规则都是按需加载的。就像我们展示的那些方法一样，那是按需的。所以当我要求时，它会去找。这就是总体结构。

Is it a production prototype? Is it a brand prototype? Or are we just working on the environment itself? And depending on which of those pathways you want to go down, it routes to different instructions. So it'll look at the conventions based on that route. If you're going down the product prototyping route, it'll go further into what that workflow is, what it should do. And then it always loads this bit about the contributor's scope. And that's all about just making sure the agent works in the bounds that we've told it to work in so you don't get conflicts and things like that. And then all of these other rules are just on demand. So like those ones that we showcased with the methods, that's just on demand. So when I ask for it, it'll go look for it. So that's the general structure.

即使在高层面上，我从这次对话中得到的一个收获是，将文档原语交织在我们的创意工具中的价值，因为它几乎是人类意图与智能体需要看到并采取行动之间的标准化层。它非常适合交接。这完全说得通。我觉得你可以朝着很多不同的方向去发展智能体支持的交接文档，以及如何扩展它并使其真正高效。这里有些东西。我觉得即使对我自己的实践来说，我建立的很多上下文文档都藏在某个嵌套文件夹里，我实际上看不到它们，我想能够找回它们。

Even at a high level, one of my takeaways from this conversation is the value of having doc primitives interwoven inside of our creative tools because it is almost the standardizing layer between human intent and then what the agent needs to be able to see and act on. It's perfect for handoff. That makes total sense. I feel like you can run in a lot of different directions with what an agent-enabled handoff doc looks like and how you can scale that and make it really efficient. There's something here. I feel like even for my own practice, a lot of the context docs that I'm establishing, they're all hidden in nested folders somewhere and I don't actually see them and I want to be able to get back to them.

或者就像不，不，这实际上是过程的关键部分，现在是对齐文档、分享该文档、获取对该文档的反馈。我们在这里看到的整个图表。它就像这个影子应用，只是用 Markdown 写的，它就存在于应用中，这就是让智能体在很大程度上进行编排的东西，然而它甚至不一定需要在这个环境中暴露，但它都在幕后。

Or it's like no no this is actually like a key part of the process now is aligning on the doc, sharing said doc, getting feedback on said doc. This whole diagram that we're looking at in here. It's like this shadow application that's just written in markdown, it just lives in the app and like this is what allows the agent to orchestrate for the most part and yet it doesn't really deserve to be even in this environment like exposed necessarily, but it's all there under the hood.

人们越了解它，就越好。

The more that the people know about it as well, the better.

我认为困难的是，为什么我真的需要开始写这种级别的文档，甚至是因为我知道如何从这个工具中获得最佳结果，因为我为自己构建了它。所以我几乎知道所有可能的事情。好吧，不是所有可能的事情。它仍然让我惊讶，但我知道我可以要求它做的大部分事情。在这个 UI 中没有任何真正的可供性来理解原型的概念以及其中包含什么。蓝图的概念以及我可以要求它做什么。从这个角度来看，文档对用户也很重要，因为它成为他们的指南，比如我可以使用什么语言来正确与智能体沟通，让它做我想让它做的事情。这甚至与智能体规则本身分开，这些规则非常核心，实际上代表人类编排体验。

I think is the hard thing is like why I really needed to start to get into like writing this level of documentation even is like I know how to get the best results out of this tool because I built it for myself. So like I literally know every possible thing. Well, not every possible thing. It still surprises me, but I know most of the things that I can ask it to do. And there are no real affordances in this UI to understand like the concept of a prototype and what goes into it. The concept of a blueprint and what I can ask of it. The documents even from that perspective are important for the users because it becomes their guide of like what language can I use to communicate correctly to the agent that it will do what I want it to do. And that's even separate from the agent rules themselves which are so core and actually sort of orchestrate the experience on behalf of the human.

在我们完全拉远之前，我想再次对那个受到启发、想在公司里构建某种内部系统的人说几句。你在这段旅程中遇到的其他建议、技巧或可能要避免的陷阱，你认为其他人可以从中受益的？

Before we zoom all the way out, I kind of want to speak again to that person who's inspired to do something and build some kind of an internal system in their company. Any other piece of advice, tips, or maybe gotchas to avoid that you've encountered through this journey that you think other people could benefit from?

关于从哪里开始，我只想说，从原型制作中获得价值的方式有很多种。我认为当人们听到原型制作时，他们会立即跳到高保真原型。这绝对不是我的思考或处理方式。在我作为设计师和前端开发者的早期，那是响应式网页时代。所以我们有一个手机库，需要针对它测试设计。在我们甚至在真实设计保真度中测试或做任何事情之前，我们有一个小木制手机，你可以把一张纸放进去。所以你可以在我们预期的手机形态因子上在纸上素描。那是一个非常好的原型，因为它只是将情境化到足以让人们理解我们的目标。在这个项目的几个月里，原型只是低保真的，看起来像草图，但它仍然增加了大量价值。所以我认为对于很多团队来说，即使只是从那里开始，或者只是集中你的原型制作工作，这样你就可以开始作为集体在团队的工作基础上构建，这是一个巨大的好处。所以我可能会从那里开始。它的酷之处在于它 100% 针对你的团队和工作流定制。这是对我有效的，也是对我 Sublime 团队集体有效的，但你的团队可能看起来非常不同，你的过程，当你发现你的小紧张时，你只需解决它们。这是一个产品设计问题要解决，你知道吗？所以那很棒。我想那可能是我会怎么做。

In terms of where to start, I want to just say that there's so many different ways to get value from prototyping. I think when people hear prototyping, they jump immediately to high-fidelity prototyping. And that's definitely not the way that I think about it or approach it. In my earliest days as a designer and front-end dev, like it was the responsive web days. And so we actually had this library of phones that we needed to test against, test the designs against. And before we would even test or do anything in like actual design fidelity, we had this little wooden phone that you could slot like a piece of paper into. So you could sketch on paper in the form factor that we expected the phone to be. And that was a really good prototype because it would just contextualize it just enough that people could understand what we were going for. With this project for months, the prototypes were low fidelity only, like only sketch looking, and it still added a ton of value. So I would think for a lot of teams even just starting there or just getting your sort of centralizing your prototyping efforts so that you can start to build on your team's work like as a collective is a huge benefit. So I would probably start there. What's cool about it is that it is 100% custom to your team and your workflow. This is what works for me and collectively like my team here at Sublime, but your team might look very different and your process as you sort of discover your little tensions, you just work through them. It's a product design problem to solve, you know? So that's been great. I think that's probably how I'd go about it.

是的。就像你说的，这是一个产品设计问题要解决。我觉得最近内部工具被赋予了很大的重量，以前感觉像是一个你可以稍微推后的事情，但现在就像不，不，不，作为设计师，我们是最有能力去发现问题、发现我们构建方式中的低效之处的人，然后弄清楚，好吧，鉴于我可以构建几乎任何东西，我们会在这里创造什么，看到你最终的结果真的很有趣。我觉得这在很多方面是更多团队将要使用的系统类型的蓝图。

Yeah. Like you said, it's a product design problem to solve. I feel like there's so much weight placed on internal tools as of late where it kind of felt like a thing that you could punt a little bit but now it's like no no no as designers we kind of are the best equipped people to go find the problems, find the inefficiencies in how we are building and then just figure out okay given the fact that I can build almost anything what would we create here and it's really interesting to see where you landed. I feel like this in many ways is the blueprint for the types of systems that more teams are going to be using.

那么让我们谈谈你吧。所以，你在这个窗口期间做的另一件事是重新设计你的个人网站，我一直觉得这是一个有趣的机会来反思，你知道，你想如何定位自己？我是谁之类的事情？你之前说过你的日常工作今年的变化相当于过去 10 年的总和。那么那次练习教会了你如何在未来几年定位自己？特别是作为一个，你知道，你在做这件惊人的事情，在内部创造如此多的价值，但它不会出现在，你知道，性感的小作品集或你期望的不同类型工作的整洁模板案例研究中。

Let's talk about you then for a second. So, one of the other things that you've done in the midst of this window is redesign your personal site too, which I always find is a fun opportunity to kind of reflect on, you know, how do you want to position yourself? Who am I kind of thing? And there's you had this line earlier about how your day-to-day has changed as much this year as it has in like the last 10 years combined. And so what did that exercise teach you about how you want to position yourself in the years ahead? Especially as somebody who, you know, you're doing this amazing thing that's creating so much value internally, but it doesn't show up in, you know, the sexy little portfolio or the neat templated case study that you'd expect of different types of work.

这是一个好问题，也是我一直在纠结的问题。我自己的职业生涯相当跨学科。我在科技行业起步，正如我提到的，作为一名前端开发者，然后我转向产品设计。从那时起，出于某种原因，我有点陷入了网络安全这个细分领域。那些与我保持联系的工作恰好在这个领域，我今天仍然在这个领域工作。

It's a good question and one I continue to wrangle with. My own career has been pretty multi-disciplinary. I started in tech as I mentioned as a front-end developer and then I shifted into product design. I sort of fell into this niche of cyber security from then on for whatever reason. The jobs that kept connecting with me happened to be in that space and I continue to work in that space today.

这些天，我仍然想把重点放在——如果你看我的新网站，我的标题是“Patrick 是一位会动手搭建的设计师”。差不多就是这样。我不想夸大我的工程能力。我并不是想把自己重新定位成工程师。我甚至不一定想称自己为设计工程师。我只是觉得，代码是我这些年来一直在为之设计的媒介。不管我是怎么做的——无论是自己写代码，还是在 Figma 里设计稿子然后别人来编码，或者现在处于某种混乱的中间状态，我比以往任何时候都更多地把代码当作媒介——这就是我试图思考设计师、工程师、设计工程师的方式。我觉得我就是个设计师，但我的媒介是代码。我喜欢这样，我就喜欢动手搭建。

And these days, I still want to put the emphasis on—if you look at my new site, my headline is 'Patrick is a designer who builds.' That's pretty much it. I don't want to overstate my engineering skill at this point. I'm not trying to reposition myself as an engineer. I don't even want to call myself a design engineer necessarily. I just think that code is the medium that I've been designing for all these years. Regardless of how I've been doing it—whether I'm the one writing the code, or if I'm designing the mocks in Figma and then someone else is coding it, or if now I'm in some sort of messy middle where I'm still using code as the medium more than ever—that's kind of how I'm trying to think about it in terms of designer, engineer, design engineer. I think I'm just a designer, but my medium is code. I like that way, and I just like to build.

从你所有的实验和我四处翻看的东西就能看出来。很酷。你知道，你在……之间取得了很好的平衡。没错。就像这种东西。我当时想，这是个有趣的细节，而且我敢肯定，如果你不能只依赖像 Claude 或 Soul 那样随创意扩展的能力，你大概永远不会花时间去搞这个。

As evidenced by all your experiments and everything that I was poking around. It's cool. You know, you have the nice balance between the... Exactly. Like this kind of stuff. I was like, that's a fun detail, you know, and it would have been something I'm sure you probably never would have taken the time to work on if you couldn't only rely on like the creativity scaled with Claude or Soul.

这个网站的第一版我主要用的是 Claude Code，后来随着我继续完善，我主要用 Codex。但有一些东西正是因为这种工作方式才出现的，换任何其他方式都不可能发生。比如，我写很多东西，你也知道，我想把我的文章搬到网站上，但我不想费劲去给每篇文章配题图，因为那太麻烦了。所以在搭建网站展示文章的过程中，我最后干脆做了一个生成艺术工具，自动为我的文章生成某种题图。在过去，我根本不可能做到这个，甚至想都不会想。而且实际上——因为这个构建方式——这个工具就嵌在我网站代码库里。然后我做了这个工具，是为了了解它能做什么。然后因为它就在网站里，我就可以把它开放出来，让其他人想试就试，然后从那里继续。这真是一个很有意思的工作流：为了设计我最终想要的东西，我需要先设计这个工具，然后这个工具又反过来推动了工作。我注意到越来越多的设计师工作流都是这样。

I mostly used Claude Code on the first iteration of this site, and then as I've continued to work on it, I've mostly been using Codex. But there are things that emerged as a result of this way of working that just would not have happened any other way. So, for instance, I do a lot of writing, as you are aware, and I wanted to be able to bring over my articles to my website, but I also didn't really want to have to manage bringing over feature images for all of them, because that's just kind of a pain in the butt. And so in this process of building out the way that I can show my writing on my website, I ended up just building a tool to do this generative art that would automatically create some kind of feature image for my article. In the past, there's no way I would have been able to do this or even thought to do it. And you can actually—just because of the way that this is built—the tool is a part of the codebase of my website. And then I built this so that I could get a sense of what the tool was capable of doing. And then because it's in the site, I can just expose it so others can try it if they want, and kind of go from there. And that's just a really interesting workflow where, in order to design the end thing that I'm aiming at, I needed to design this tool, and then that tool facilitated the work. And I'm noticing that more and more with more designers' workflow.

是啊。而这种膝跳反应变得如此重要，对吧？就像，我想达到这个最终状态。我能构建什么工具来加速这个过程，或者让我走得更远？从某种意义上说，这差不多就是整期节目的 TLDR，挺有意思的。

Yeah. And that being the knee-jerk reaction is becoming so important, right? It's like, I want to get to this end state. What tool can I build to just accelerate that process or get me further than I would have been able to do otherwise? Like that's kind of the TLDR of this entire episode in a way, which is fun.

而且我觉得，虽然我在个人工作流里这么做了，但实际上这也是我们品牌和创意团队使用我内部设计的工具的主要方式。所以如果我们回到那个话题，我们这里有第二个区域，叫做工具。这些工具，在很大程度上，你可以把它们看作是从原型毕业的。它们仍然是原型——底层结构是一样的——但这些现在是我们组织内部人员可以使用的工具。这些大多是营销工具，他们来这里用这些工具获取符合品牌规范的素材。所以如果我们拿这个举例，为 Open Graph 生成或创建图片，我觉得基本上没有哪个品牌设计师会特别乐意例行公事地做这个。所以，好吧，我们做个工具。这个不是我做的——这是我们一位很棒的品牌设计师做的。她设计了那些我们想要重新混音的基础素材，然后把它开放成一个工具，让团队能够自助服务。她已经这么做了好几次了。我们现在有六个这样的工具。每当有需求时，我们现在就有了这个出口，可以这样扩展我们自己，尤其是在营销方面，这是工作中如此常规的一部分。

And I think while I've done that in my personal workflow there, that's actually been the primary way that our brand and creative team has used the tool that I've designed internally. So if we return to that for a second, we have this whole second area here called tools. And these, for the most part, you can think of them as prototypes that graduated. They are still prototypes—they're structured the same under the hood—but these are now tools that are available to people within our org. Mostly these are marketing tools, and they come here and use these tools to get brand-aligned assets. So if we take this one as an example, generating or creating images for Open Graph, I would say that there's basically no brand designer out there who's super stoked to have to do that on a routine basis. So, okay, let's make a tool. This was built not by me—this was built by one of our great brand designers. And she designed sort of these baseline assets that we would want to remix, and just exposed this as a tool for the team to be able to self-serve. And she's done this a number of times. We have six of them at the moment. And whenever there's a need, we now have this outlet to be able to kind of scale ourselves that way, especially on the marketing side where that is such a routine part of the job.

我喜欢这个。所以你为人们搭建了更容易探索的环境。大概这些都是一次性的东西，然后如果一个想法足够热门，就会说，好吧，我们把它产品化。把它融入实际环境本身。你展示的基本上就是这个。

I love it. So you've built the environment for people to explore more easily. Presumably, these all kind of start off as one-off things, and then if there's enough heat around an idea, it's like, okay, let's productize this. Let's bake this into the actual environment itself. That's basically what you're showing here.

是的。没错。目前，我们也没有理由不能在这里放产品设计工具。只是产品设计这边还没有那么多需要以那种方式交接的工作流。但没有理由不能这样做。

Yep. Exactly. At the moment, there's no reason that we couldn't have product design tools in here, too. It's just that we haven't had as much need on the product design side to sort of hand off workflows in that way. But there's no reason it couldn't be.

我觉得这又回到了系统思维的部分。几乎任何人都能轻松扩展。就像回到交接的部分，大概有人会说，你知道吗，我要建一个小助手，也许能以我们开箱即用时没有的方式为智能体视觉化地标注我的工作，然后他们可以做到，再把它反馈回系统的其他部分。

I think it comes back to the systems thinking piece. It's easy for almost anybody to extend. Like even going back to the handoff piece, somebody presumably could be like, you know what, I'm going to build a little helper that's going to maybe visually annotate my work for the agents in a way that we weren't getting out of the box, and then they could do that and then feed it back into the rest of the system.

为了回应“我们是否应该在生产环境中做原型”这类问题。我觉得一旦你开始看看在这个环境里能做什么，就会越来越清楚——给自己留出足够距离的好处。这永远不会进入我们的生产环境，甚至接近我们生产产品代码库都不可能，对吧？就是不会发生。我们得用其他方式做。甚至我大多数非常发散性的探索，可能也不想让它们离网络安全公司的实际生产代码太近，因为它是一个专门的独立空间。你真的可以让它按照你需要的方式服务于你独特的工作流。

To address the 'should we prototype in production' sort of question. I think once you start to look at what's possible in this environment, it starts to become more clear—the benefits of giving yourself just enough distance. This would never go into our production, like even close to our production product codebase, right? It just wouldn't happen. We'd have to do it some other way. Even most of my very divergent explorations probably don't want those too close to the actual production code in a cyber security company, because it is its own dedicated space. You can really allow it to serve your unique workflow in the way that you need it to.

我受到启发了，兄弟。我觉得就在过去一周里，我已经迈出了几步，至少给自己打下了基础——这种分割，对吧，生产环境和这个游乐场环境之间的接缝。但即使今天，我在一个电话会议上展示一个概念，我想展示三天前在同一个分支上做的旧概念，但我记不住那个 slug 是什么了。

I'm inspired, man. I feel like I've taken a couple baby steps just in the last week to giving myself at least the foundation—this split, right, that seam between production and this playground environment. But already even today I was on a call where I was presenting a concept, and I wanted to show an older concept that I made like three days previously on that same branch, and I couldn't remember what the slug was.

然后我就想，哎呀，你知道，但现在我就想，我应该有某种画布原语，能够——哪怕只是在分支内——能够说，这几乎就是我在做的事情的目录。你给了我很多可以继续的想法。

And it's like, ah man, you know, but now I'm like, I should just have some kind of a canvas primitive and be able to—even if it's just within a branch—to be able to say, here's my table of contents almost for what I'm working on. You give me a lot of ideas to run with.

所以，感谢你揭开帷幕，展示了你的工作成果。而且，就像我之前说过的，我还要再说一遍，这在很多方面都像是许多团队的蓝图。感谢你抽出时间。

So, I appreciate you kind of pulling back the curtain and showing what you've worked on. And again, like I said it before, I'll say it again. It just feels like a blueprint for a lot of teams in a lot of ways. So, appreciate you taking the time.