AI 创业的刀锋之战：Grainola CEO 谈在混乱中蓬勃发展

Every 是你保持 AI 前沿所需的唯一订阅。如果你关心掌握最新模型和使用最新工具，你必须订阅 Every。我们将帮你区分信号与噪声。立即访问 every.to/subscribe。现在，回到本期节目。Chris，欢迎来到节目。

Every is the only subscription you need to stay at the edge of AI. If you care about being on top of the latest models and using latest tools, you have to subscribe to Every. We'll help you separate the signal from the noise. Go to every.to/subscribe today. And now, back to the episode. Chris, welcome to the show.

嘿，Dan。很高兴见到你。

Hey, Dan. Great to see you.

我也很高兴见到你。好久不见。对于不了解的人，你是 Grainola 的联合创始人兼 CEO，这是我最喜欢的 AI 应用之一，也是我认为在两三年前真正掀起浪潮的应用之一。它是首批让人们觉得“天哪，这真的有用”的新 AI 应用之一。从那以后，你的团队大概发展到 55 人，估值约 15 亿美元，你们做得非常出色。我们在 2024 年 12 月进行过一次很好的对话，差不多两年半前，关于为产品注入灵魂和打造令人愉悦的产品。我特别好奇你现在的想法、近况如何，以及分享我们过去几年的旅程，共同展望未来。

Good to see you, too. It's been a while. So, for people who don't know, you are the co-founder and CEO of Grainola, one of my favorite AI apps, one of the apps that I think really kicked off the wave in the last in like, you know, I guess two or three years ago. It was one of the first new AI apps where people are like, "Holy this actually works and it's useful." And since then you've gone on to I think the team is about 55. You've raised at like a $1.5 billion valuation. You're just killing it. And we had a really good conversation in December 2024, so almost 2 and a half years ago, about putting soul into your product and making products that are delightful. And I'm just super curious to hear what's on your mind, how things are going, and to sort of share out both of our journeys over the last couple years, and think about the future together.

非常兴奋能聊天。我一直在远处关注你做的各种事情。我很想听听内部的最新进展。只是对你说的一个点做个回应。你说我们做得很好，对吧？我们非常幸运。事情进展顺利。但有一件事我毫无准备。我之前做过一家创业公司，创业就像刀战，对吧？非常艰难。也许你的生活很轻松，但对我来说真的很难。我以为创业只在失败时艰难，结果发现成功时也一样艰难。这就是一场刀战。

Couldn't be more excited to chat. I've been following all the different things you've been doing from a distance. I'd love to hear the latest from the inside on how that's going. Just to react on one thing you said. You said we're killing it, right? We're very lucky. Like things are going well. Something I was unprepared for. So, I did a previous startup and startups are like knife fights, right? They're really hard. Maybe life's easy for you, but for me it's really hard. And I thought startups were just really hard when they weren't working. Turns out they're really hard when they're working as well. It's a knife fight.

无论事情顺利与否。我对此有点措手不及。我在新闻学院有位教授，他说世界最不需要的就是另一个把人捧上天的简介，比如“这个人太棒了”。但事实并非如此。今天一切都很艰难。日复一日的战斗。这就是我的心态。只是想分享一下。

When things are going well or not going well. And I was a bit unprepared for that. So, I had a professor in journalism school who basically said the last thing the world needs is another profile that puts someone up, like "Oh this person's so great." And it's like no, no. Everything's hard today. A fight day in and day out. That's my mentality. Just wanted to share that.

我懂你，兄弟。我深有同感，我经营公司很久了，Every 是第一个真正在增长、真正运作得像一家真正公司的企业。我们现在有 30 人。谢谢。当它运作良好时，比如昨天 Claude 标签发布了。我们一直在做一个 Slack 智能体。昨天 Claude 标签发布了。然后每个人都看着你问我们该怎么办？我说我们已经准备好了。我们一直在思考，知道这会发生。尤其是在 AI 领域，我感觉变化太快了。我猜对你来说，你正在谈论的一件事，我也在谈论，我其实很好奇：你是第一个做出真正优秀的 AI 会议记录和会议转录的人。然后立刻每个人都把会议记录功能加进了他们的产品。我们实际上有一个叫 Monologue 的产品，它有一个会议记录按钮。

I feel you, man. I definitely feel the same way where I've been doing companies for a long time and Every is the first one that's like really growing and just really working in this way that feels like it's a real company. We have 30 people now, you know. And thank you. And when it is working yeah like a good example, Claude tag dropped yesterday. We've been working on a slack agent. Claude tag dropped yesterday. And so, then everyone's looking at you like what do we do? And I'm like we've prepared for this. We've been thinking we knew this was going to happen. And especially in AI, I feel like the ground shifts so quickly. And I assume for you like one of the things you're talking to and I'm talking about it and I'm actually really curious is you were the first one to do really great AI meeting notes and meeting transcriptions. And then immediately everyone just like put meeting notes into their product. We actually have a product called Monologue that has a meeting notes button, you know.

哦，酷，我不知道。

Oh cool, I didn't know that.

所以我们有点竞争关系。混战。是的。

So we're like slightly competitive. Fray. Yeah, yeah.

是的，是的。

Yeah, yeah.

是的，我不认为它是完全的一对一替代品。我电脑上两个都有，但这可能就是你所说的刀战。那么跟我说说，那是什么感觉？它实际上对你的业务有什么影响吗？

Yeah, I don't really think of it as being an exact one-to-one replacement. I actually have both on my computer, but still that's probably what you're referring to when you say knife fight. So tell me about that. What is that like? How has that actually affected your business at all?

那其实不是我说的刀战。我是说那是其中的一部分。我想我指的是，从定义上讲，创业公司要么在求生，你总是在求生。如果事情顺利，你是在努力抓住这波大浪，你站在冲浪板上拼命不掉下来。所以你总是处于能力极限的边缘。几乎从定义上说，我总是在做我不知道怎么做的事情。你总听到：作为创始人，你总是在做你不知道怎么做的事。是的，这就是我的经历。我总是在做从未做过的事，或者比我们过去承担过的更多。关于竞争，这是我的看法。我觉得我说过这个。让我想想。所以我想，当我想起这个时，这听起来像那些关于竞争的标准回答，对吧？因为总会有采访问：“嘿，微软刚复制了你的产品。你感觉如何？”创始人必须想出个答案。我的看法是，我们正处于计算革命的非常早期阶段。迄今为止的一切与即将到来的相比都会黯然失色。我认为会议记录并不是每个人追逐的终极价值。还有更重要的东西，我认为那是我们用于工作的界面、我们如何工作，以及在 AI 原生世界中这看起来像什么。所以当我想到竞争时，我只是觉得人们今天争夺的东西并不重要。前方有巨大的机遇，我认为我们有机会，其他几家公司也有机会，对吧？但那才是真正重要的。

That's actually not what I was referring to as a knife fight. I mean that's part of it, you know. I think it's just I guess what I was referring to is I think by definition a startup is you're either fighting for survival, you're always fighting for survival. And if things are going well, you're fighting to stay on this big wave, you're on a surfboard trying desperately not to fall off. So you're kind of always just beyond the edge of your abilities. And it's almost by definition, therefore I'm always doing stuff I don't know how to do. You always hear this: as a founder you're always doing stuff you don't know how to do. Yeah, that's been my experience. I'm always in the space where it's stuff I've never done before or it's just more than we've ever bit off in the past. Yeah, the competition. Here's my view. I feel like I've said this. Let me think about it. So I think when I think about this, it's going to sound like one of those answers around competition, right? Because there's always the interview where it's like, "Hey, Microsoft just copied your product. How do you feel about it?" And the founder has to come up with some answer. The way I view it is I think we are in the very, very early steps of a computing revolution. And what has come thus far will pale in comparison to what will come soon. And I think that meeting notes are not the end-all, be-all value that everyone's running after. There's something much bigger, and I think it's the interface we use for work and how we work and what that looks like in the AI-native world. So when I think about competition, I'm just kind of like what people are fighting for today doesn't matter. There's this incredible opportunity ahead, and I think we have a shot at it, and a few other companies have a shot at it, right? But that's really what matters.

所以就像人们说“哦，Grainer 做得很好”一样，在我看来，这有点像来得快去得也快，对吧？会议笔记是有用，但未来很多事情都会改变，仅仅因为人们今天用这个，并不意味着他们将来还会用它，如果我们不是下一个东西里最好的。所以，嗯，我不知道。这就是我宏观的看法。另外要说的就是，我们并不是第一个做会议笔记的，对吧？AI 会议笔记工具已经存在很久了。我们，可以说，深受许多前人成果的启发。所以我不能摆出一副“哦，你怎么敢受我们启发”的样子。你知道，我们只是在一个生态里。这件事对公司的影响比我预想的小得多。比如 Notion 复制了，或者说他们推出了一个我认为深受 Grainer 启发的产品。OpenAI 做了，Zoom 最近也做了。所以某种程度上，我不必面对那种噩梦般的峰会场景——产品上线那天会是什么样子？它来了，发生了，而我们还在。是的，我们还在。它没有改变我们的增长率什么的，但话说回来，与我们希望的用户使用量和用户数量相比，我们仍然只是沧海一粟。所以我认为现在还非常早期，这是我的看法。

So in the same way where people are like, "Oh, Grainer's doing really well." It's like, well, in my mind it's like easy come, easy go in a way, right? Like meeting notes are useful, but a lot of things are going to change in the future and just because people use this today doesn't mean they're going to use this for that in the future if we're not the best at that next thing. So yeah, I don't know. That's my zoomed-out view. And the other thing to say is we were not the first meeting note taker, right? Meeting AI note takers have been around for ages. We were, let's say, heavily inspired by a lot of things that came before. So I can't be like, "Oh, how dare you be inspired by what we did?" You know, it's like we're just in an ecosystem. It has affected the company a lot less than I thought it would. Like within Notion copied or whatever, let's say they launched something I think heavily inspired by Grainer. OpenAI did, Zoom did recently. So in some ways, I didn't have to sit with the nightmare summit scenario of what would it be like the day that launches? That kind of came and happened and we're still here. Yeah, we're still here. It hasn't changed anything from our growth rate or whatnot, but again, we're still a drop in the bucket compared to what we'd like to be in terms of how people use us and how many people use us. So I think it's just very early days, is my view.

有道理。我不得不说，我很喜欢和你聊天，因为我觉得你对自己正在处理的事情非常坦诚。这太棒了，很有趣。这和很多人很不一样，我觉得这会是一场非常有趣的对话。我想回到你之前说的，你站在冲浪板上努力不摔下来。通常初创公司里，你站在冲浪板上划水，等待浪来。而对我们俩来说，对你更是如此，你就像在说：“我现在骑上大浪了，别摔下来被浪打翻。”那么最近有哪些事情让你觉得到了能力的极限，心里想“我得搞定这个”？这也许是好事，但通常感觉是“天哪，这太不一样了”。

That makes sense. I just got to say I love getting to talk to you because I feel like you're just so honest about what you're dealing with. It's the best. It's so fun. It's very different from a lot of people and I think this is going to be a very fun conversation. What I want to go back to is you said you're balancing on the surfboard and you're trying not to fall off. And normally in startups you're on the surfboard and you're just paddling and waiting for the wave. And I think for both of us, for you more so than me, but for both of us, you're like, "I'm on the big one now. Let's try not to fall off and just get pounded." So what are some of those things recently where you've felt like you've been at the edge of your ability and you're like, "I got to figure this out." This is maybe a good thing, but generally it's like, "Holy, this is very different."

所以很多都是我自己作为创始人的局限或经验不足。比如我上一个创业项目 Socratic，我们只有 12 个人。从 12 人到现在，我们实际上超过了，大概在 60 到 70 人之间。这非常不同，我以前从没经历过，对吧？所以组织人力，这是其一。另一个挑战是，我希望我能有一个非常简洁漂亮的答案，说我们全都搞定了，但在这个时代，你谈论产品要有灵魂，产品要感觉一致、连贯、有品位，你怎么规模化呢？当有更多人在做这件事时，你如何既获得很多人一起解决难题的好处，又保持这种一致的感觉？这真的是个难题。我觉得有很多有趣的话题可以深入探讨，但其中之一是 PM、设计和工程的传统角色，以及如何把人分组，他们的职责是什么。感觉过去有效的方法在未来可能无法完全一对一地适用，但我实际上不知道如何定义角色和分工。如果你说“哦，你是设计师，我是工程师”，或者反过来，那就有很宝贵的价值，比如“好了，现在我们知道了在哪里协作，接口线在哪里”。你们在 Every 有这方面的理念吗？

So a lot of it is kind of my limitations or lack of experience as a founder. Like my last startup Socratic, we were 12 people. So just going from like 12 to we're actually over, we're somewhere between, I don't know, 60 and 70 now. And so that's very different and I've never done that before, right? So organizing humans, that's one. Something that's challenging and I wish I had a really succinct beautiful answer like we have it all figured out, but it's in an era where you're talking about product having soul and product feeling consistent and coherent and tasteful, and how do you scale that? When you have more people working on that, how do you both get the upside of having lots of people working on these hard problems but also having this consistent feel? That's a really hard problem. And I think there are so many different interesting topics for us to dive into, but one is the traditional roles of PM and design and engineering and how you group those people together and what are their responsibilities. It feels like what has worked in the past may not make sense exactly one-to-one in the world of the future, but I don't actually know how to define roles and split work. There's something really valuable if you're like, "Oh, you're the designer, I'm the engineer" or vice versa, of like, "Okay, now we know where we collaborate, where the interface line is." Do you have a philosophy on that at Every?

我不知道。我们做过不同的事情，这取决于情况和产品。我有一个思维模型，似乎特别适用于早期产品，那就是有两个重要的角色：一个叫海盗，一个叫建筑师。海盗的工作就是尽可能快地构建，找到有价值的东西。它可以靠 vibe coding，你不需要真正考虑架构之类的东西。建筑师的工作是与海盗配对，思考当海盗找到有价值的东西时，我们如何把它变成一个可持续的、可理解的、可扩展的系统。有趣的是，我认为每个产品需要一个海盗，但一个建筑师可以同时处理多个产品。你可以让他们来回切换，因为现在的工具太好了，一个非常优秀的程序员、非常优秀的建筑师可以空降到代码库里，然后说：“我要在一小时内学会这个代码库，因为我只要让 Claude 或 Codex 之类的工具帮我映射出来。”然后我会识别出结构支柱，也就是这个产品中必须成立的不变量，然后让 Codex 去做一个 24 小时的重写，然后我去做别的事。我觉得这非常有趣。所以这是一种分工，特别是海盗是技术、产品、设计的混合体，所有这些都在一起，而建筑师则主要专注于技术方面。然后，但说实话，那么独立的设计师呢？你只有……

I don't know. Like we've done different things and it sort of depends on the situation and the product. My one mental model that I have that seems to work especially for early products is there are two roles that matter. One is called the pirate and one's called the architect. And the pirate's job is to just build as fast as possible to find something valuable. And it can be vibe coded, you don't have to really think about the architecture or all that kind of stuff. And the architect's job is to pair with the pirate and think about as the pirate finds something that's valuable, how do we make this into a system that is sustainable, that we understand, that can scale. And what's interesting is I think you need one pirate per product. But you can have one architect work on multiple products. You can have them bounce around because the tools now are so good that someone who's a really good programmer, really good architect can just drop into a code base and be like, "I'm going to learn this code base in an hour because I just have Claude or Codex or whatever map it for me." And then I'll identify the structural pillars, the invariants that need to be true in this product for it to work well, and then I'll just send off Codex to do like a 24-hour rewrite, and then I'll go do something else. And I think that that's really interesting. So that's one divide, and in particular the pirate is this mix of technical product design, like all of those all together, and the architect is really mostly focused on the technical side of things. And then, but honestly, standalone designers then, right? You only have...

我们确实有独立的设计师。一旦它变成一个我们要支持的真实产品，是的，我们有一个独立的设计团队，空降到每个产品中，帮助它变得更好。但在技术方面，比如我们一直在构建的 Slack 智能体叫 Plus One，那只是一群工程师，他们在某种程度上是全栈思考者，但非常以工程为中心。所以没有统一的答案。我还没有完全搞清楚。我确实认为海盗-建筑师配置对于新事物非常有帮助。但你们是怎么做的？

We do have standalone designers. Like once it gets to be like a real product that we're going to support, then yeah, we have a standalone design team that parachutes into each product and helps make it better. But then on the tech side, for example, we have this Slack agent we've been building called Plus One, and that's just a bunch of engineers that are all working in and are to some degree full-stack thinkers, but it's very engineering focused. So there's no one answer. I haven't quite figured it out yet. I do think the pirate architect configuration for new things is really helpful. But what do you guys do?

是的，我们有类似的东西，但并不是在角色层面。对于任何新功能，我们有阶段的概念。

Yeah, we have something similar, but it's not actually on the role. So for any kind of new feature, we have this idea of stages.

所以，第一阶段是塑形（shaping）。我们受到了 Ryan Singer 的《Shape Up》的启发，就是 Basecamp 那帮人写的。我们大致借鉴了那个思路。我回去读了那本书，至少读了前半部分。感觉它已经很过时了，尤其是他们用作例子的那些功能。但有些想法确实很扎实。所以我们有这样一个塑形阶段，你要尽可能多地探索潜在的解决方案。你从一个待完成的工作（job to be done）开始：这里有一个用户需求，有一个我们希望用户雇佣我们来完成的工作。然后你尽可能快地探索该解决方案的可能形态。接着你审视这些方案，必须非常诚实地问自己：如果我们花时间在这个上面，人们真的会雇佣我们来做这件事吗？然后我们进入下一个阶段，有点像验证：对一小部分人，证明你能提供价值，并且他们选择使用你。如果能证明这一点，那就好，我们实际把它做好、做可靠、做可扩展。但这仍然没有回答一个问题：做这件事的人的角色是什么。这只是那些开放性问题之一。

So, the first stage is like shaping. We're influenced by Shape Up by Ryan Singer, the Basecamp guys. It's loosely inspired by that. I went back and read it, at least the first half. It felt very dated, especially the features they use as examples. But some of the ideas are really sound. So we have this idea of a shaping phase where you want to explore as many potential solutions as possible. You start with a job to be done: here's a user need, here's a job we would like the user to hire us to do. Then you explore possible shapes of that solution as quickly as possible. Then you look at those and have to be very honest with yourself: if we spend time on this, would people actually hire us to do it? Then we have a next phase, which is kind of validate: for a small number of people, prove that you can be useful and that they choose to use you. Then if you can prove that, it's like, okay, let's actually make this good, reliable, and scalable. It still doesn't answer the question of what the roles of the people who work on it are. That's just one of those open questions.

我的意思是，你有 60-70 个人。所以你至少得暂时回答这个问题。那么你暂时得出了什么结构？

I mean, you have 60-70 people. So you have had to answer that at least provisionally. So what is the structure that you've come to provisionally?

我们还在摸索。我们仍然有头衔，我不知道是否该保留它们。比如，你是设计师，你是产品经理，你是工程师。我一直在考虑取消这些头衔。三个。取决于你是否把我算进去。

We're still messing around with it. We still have titles, and I don't know if we should have them. Like, you're a designer, you're a PM, you're an engineer. I'm always flirting with the idea of killing those. Three. Depends if you count me.

我不会把你算进去。对对对。好的。有意思。好的。

I wouldn't count you. Yeah, yeah, yeah. Okay. Interesting. Okay.

是的，我一直在考虑取消头衔，因为你真正想要的是在这个项目上，现在有人需要做某些类型的事情。有人需要负责美学或用户体验，有人需要负责构建，这可以是同一个人或两个不同的人。还有人需要负责我们在这里要做什么、策略以及接下来需要达到的几件事。但如果没有角色，沟通成本会很高。就像，‘好吧，你到底要做什么，而我要做什么？’也许有一天这一切都会由智能体来做，谁知道呢。我们会继续实验。

Yeah, I've always flirted with the idea of killing titles because what you really want is on this project right now, someone needs to do certain types of things. Someone needs to own the aesthetic or the user experience, and someone needs to own the building, and that could be the same person or two different people. And someone needs to own what we're trying to do here, the strategy, and the next few things we need to hit. But then it's just a lot of communication overhead if you don't have roles. It's kind of like, 'Okay, well, what exactly are you going to do versus what am I going to do?' Maybe it'll all be agents one day, who knows. We'll keep experimenting.

有意思。嗯，我们刚开始录制时你说过一件事，就是你大部分时间都花在 Granola 上。所以，你对我好奇的一点是，如果我在摆弄和实验，我发现了什么？我想聊聊这个。我觉得这里面有很多内容。首先，跟我说说这个。比如，我大部分时间都在 Granola 里。我觉得这完全合理，但作为 CEO，作为一种战略存在方式，跟我说说这个决定。

Interesting. Well, one of the things that you said when we were just about to start recording is you spend most of your time in Granola. And so, one of the things you're curious about for me is if I'm playing around and experimenting, like what am I finding? So, I want to talk about that. I think there's a lot of meat there. First of all, tell me about that. Like, I spend most of my time in Granola. I think that makes perfect sense, but also as a CEO, as a strategic way of being, tell me about that decision.

所以，我之前提到过，我认为这里的大机会是发明我们将如何与 AI 协作思考和做事。这或多或少就是我们现在在硅谷追逐的东西。为此，我认为有很多东西你可以抽象地思考，但你必须实际摆弄它才能获得感觉。我很难有脑力去摆弄每一个新出现的东西。在 Granola，我们有很多上下文和内部工具，这样我就可以尝试不同的想法，但它们通常在我的小宇宙里，而不是在 Claude 中设置非常复杂的工作流。我摆弄它们以获得感觉，但它们对我来说不是承载性的，因为我在尝试看在 Granola 实验室中哪些做法合理或不合理，因为我们正在描绘未来的图景。你似乎处于实验、尝试新事物、为自己构建不同工作流的前沿。所以，也许就从你现在的工具栈状态开始，然后我们再深入。

So, I mentioned before that I think the big opportunity here is to kind of invent how we're going to work and collaborate with AI to think and do things. That's in some shape or form, I think that's what we're all chasing right now in Silicon Valley. And to that end, I think there's a lot that you can think about abstractly, but then you have to be playing with it to get a feel for it. It's just hard for me to have the brain space to play with every new thing that comes up. In Granola, we have a lot of context and a lot of internal tooling so that I can play around with different ideas, but they're often in my little universe as opposed to setting up very complicated workflows in Claude, for example. I play around with it to get a feel, but those aren't load-bearing for me because I'm trying to see what makes sense or doesn't make sense to do inside of Granola lab as we paint that future picture. It seems like you are at the forefront of experimenting, trying new things, building different workflows for yourself. So, maybe just start off by being like, what's the current state of Dan's tooling stack, and then we can go from there.

我所有时间都花在 Codex 上。

I spend all my time in Codex.

好的。这有多久了？是最近的事吗？

Okay. And how long has that been? Like, is that a recent thing?

大概 2 个月，也许 2-3 个月。是的。我有时也用 Claude 桌面应用。当 Fable 还在的时候，我追踪了我所有的使用情况，你可以看到我使用 Claude 的情况，然后 Fable 没了，使用量就下降了。我猜当它回来时，因为我觉得 Fable 完全是另一种东西，我测试所有新东西，而且我在它们发布前就能用到，Fable 就是不一样。但我的总体看法是，工作正在分化为两个界面。一个是异步委派工作，发生在 Slack 里。那是协作的、多人的、有时是主动的。这通过 Slack 机器人实现，比如我们有一个叫 plus one，一个叫 Victor，还有 Claude 的标签。就像每天早上它会在频道里发帖说，‘嘿，这是所有已解决的 bug。这是所有报告的 bug。这是我们推送的所有 PR。’然后你可以添加它说，‘你能为 XYZ bug 发起一个 PR 吗？’或者‘我们能给这个新产品起名吗？你能阅读所有我们说过关于这个产品应该是什么的内容，然后提出一些名字吗？’然后团队可以在同一个频道里和它来回讨论名字。

Like, 2 months, maybe 2-3 months. Yeah. And I do use the Claude desktop app sometimes. When Fable was a thing, I tracked all my usage, and you could see me go on Claude usage, and then when it left, it went down. I assume when it's back because I think Fable's just a different beast, and I test all the new stuff, and I have access to stuff before it comes out, and Fable's just different. But my overall view is that work is bifurcating into two surfaces. One is async delegation work that happens in Slack. That's collaborative, multiplayer, sometimes proactive. And that happens with Slack bots like we have one called plus one, there's one called Victor, there's the Claude's tag. And that's very much like every morning it posts in a channel and says, 'Hey, here's all the bugs that got solved. Here's all the bugs that got reported. Here's all the PRs we pushed.' And then you can add it and say, 'Can you kick off a PR for XYZ bug?' Or 'Can we name this new product? Can you read all of the stuff we've said about what we want the product to be and then propose some names?' And then the team can go back and forth with it in the same channel to talk through names.

所以，你可以像跟同事一样把任务交给它。而且重要的是，因为现在大多数 AI 都是单机模式，你可以在公开场合使用它。我觉得这在很多方面都很有意思。不过，对于严肃的工作，如果你和智能体之间有更好的协作界面，你总能从中获得更多。Slack 在这方面并不好。所以，另一个界面是像 Codex 或 Claude 桌面应用这样的东西，你和智能体坐在同一个地方，在同一个应用里一起工作。特别是在 Codex 中，我几乎所有的软件都在 Codex 的内置浏览器里使用。所以，我把 Codex 带到我的邮箱里，或者任何其他东西里。

So, you can hand off stuff with it like it's a coworker. And importantly, because most AI right now is single player, you can do it in public. And I think that's really interesting in a whole set of things. However, for serious work, you're always going to get more out of it if you have a better collaboration service between you and the agent. And Slack is not good for that. So, the other surface is something like a Codex or a Claude desktop app where you and the agent are sitting in the same place on the same app together. And in particular in Codex, for me, I use almost all of my software in the in-app browser of Codex. So, I'm bringing Codex into my email or into whatever it is.

你这是什么意思？能描述一下吗？你是怎么做到的？

What do you mean by that? Can you describe that? How do you do that?

我来解释。你知道在 Codex 或 Claude Code 里构建东西时，它会在浏览器里打开，让你看到本地版本，然后你不断迭代吗？基本上，所有模式——对我来说，AI 如何工作的一个好心智模型是，所有从开发者或构建者开始的模式最终都会进入所有知识工作，因为我们发现，构建一个足够好的智能体来构建任何软件——一旦它能构建任何软件，它实际上也非常擅长做任何你想要的的知识工作。这就是为什么 Claude Code 变成了 Claude Co-work。这就是为什么 Codex 现在涵盖了所有知识工作，诸如此类。所以，其中一个模式是，当你构建一个应用时，你真正想要的是智能体与你一起参与循环。所以，当它构建东西时，它会在应用浏览器中打开，你可以看到它，然后你们来回交流。你可以标注它，做任何事。你和智能体一起看到它。这个模式也适用于任何软件。所以，任何你可能访问的网站。一个非常简单的例子：昨晚我刚搬了公寓，需要换网络。我就告诉 Codex，“去搞定它。”它知道我的旧地址和新地址——实际上是在同一栋楼，我只是换了楼层。它就在内置浏览器里打开了 Verizon 网站，然后登录了。我给了它密码。然后它打开了一个与客服代理的聊天——那个客服可能也在用 AI——它就跟对方聊天，直到把我的网络换好。然后各种小事就来了，比如“你什么时候搬进搬出？”Codex 知道，因为我一直在跟它聊我搬家的事和我想换的时间。然后它说，“你的旧套餐不行了，这是新套餐。”Codex 知道要说，“我不要任何隐藏费用。”它知道怎么算这是不是个好 deal，去研究，然后推动对方给我它认为我应该得到的东西。我什么都不用做，就坐在那里。

I'll explain. So, you know when you're building something in Codex or Claude Code and it opens it in that browser and it lets you see the local host version of the thing and you're iterating on it? Basically, all the patterns — a good mental model for how AI works for me is that all the patterns that started with developers or builders eventually make their way into all of knowledge work, because we found that building a good enough agent to build any kind of software — once it can build any kind of software, it's actually really good for doing any kind of knowledge work that you want. And that's why Claude Code went to Claude Co-work. That's why Codex is now all of knowledge work, all that kind of stuff. So, one of those patterns is when you're building something like an app, what you really want is the agent to be in the loop with you. So, as it builds something, it opens it in an app browser, you can see it, and you can go back and forth. You can annotate it. You can whatever. And you and the agent are seeing it together. That pattern also works for any kind of software. So, any kind of website you might visit. A really simple example: last night I moved apartments recently and I needed to change my internet. And I just told Codex, "Go figure that out." And it knows the address of my old one and my new one, which is actually the same building — I'm just moving floors. It just opened up the Verizon website in its in-app browser and it logged in. I gave it the password. And then it opened up a chat with a customer service agent who was also probably using AI, and it just chatted with them until it switched my internet. And all these little things come up where it's like, "Okay, when do you want to move in and out?" And Codex knows because I've been talking to it about when I moved and when I wanted to switch. And then it's like, "Here's your old plan, doesn't work. Here's the new plan." And Codex knows to be like, "I don't want any hidden fees." It knows how to do the math on whether this is a good deal or not, and to research it, and then to push them to give me the thing that it thinks I should get. And I don't have to do any of that. I'm just sitting there.

这是你以某种方式跟 Codex 沟通好的，还是说它开箱即用——显然任何人在跟网络提供商说话时都想要这样？

And is that something that you somehow communicated to Codex, or is that just like an out-of-the-box — obviously any human would want this when talking to an internet provider?

两者都有。这很容易，因为它很清楚什么时候可以假设，什么时候不该假设。所以我可以参与其中，也可以去另一个线程做别的事。所以我跟它来回切换。我觉得这很有意思，但还有更通用的东西——我用这种方式处理我的邮件。它和我在 Cora（我们的邮件应用）里一起工作，另外我还实验并构建了一个开源的东西叫 Tend。但基本上，我的邮件现在变成了卡片，我在 Codex 的内置浏览器里阅读，每张卡片会说，“邮件内容如下，我认为草稿应该是这样。你想发送吗？”我就跟它对话。

It's both. It's easy because it knows pretty well when it can make assumptions and when it shouldn't. And so I can be in the loop on it, and I also can just go to another thread and be doing something else. So I'm kind of flipping back and forth with it. I think that's something, but there's a more general thing there where I use this how I do my email. It is in the loop with me in Cora, which is our email app, and also I have this open source thing I experimented with and built called Tend. But basically, my emails are now cards that I read in Codex in the in-app browser, and then each card says, "Here's what the email said, here's what I think the draft should be. Do you want to send it?" And I just talk to it.

我明白了。所以这基本上是你自己 vibe coding 了一个邮件客户端，对吧？

I see. So this is basically you've vibe coded your own email client, right?

我 vibe coding 了一个实验性的邮件客户端来做这件事，然后我们会有一个完整版的 Cora 邮件客户端，开箱即用。但你可以把这样构建的应用看作——我一直叫它们 Codex 原生应用——它们基本上负责保存状态和渲染 UI，然后你把你的智能体带进去。我认为这是一个非常强大的范式，因为想想你要为 Granola 做一个好智能体需要做多少工作。这非常难，而且你还在跟世界上的 Claude 和 Codex 竞争，它们也在构建同样功能类型的智能体。在某种程度上，我也认为在某些情况下这非常值得，因为我确实认为两个智能体比一个好。但最终，我真的很想把我的智能体带到 Granola。我想你可能从很多 Granola 用户那里也看到了这一点。我真的很想把我的智能体带到 Granola。

I vibe coded an experimental email client that does this, and then we will have a version of Cora, which is our full email client, that just has this out of the box. But you can think of the apps that are structured this way as — I've been calling them Codex-native apps — but they're basically apps that are responsible for saving the state and rendering the UI, and you bring your agent to it. And I think that is a very powerful paradigm, because think about all the work that you have to do for Granola to make an agent that is good. And it's really hard, and you're also competing with the Claudes and the Codexes of the world who are also building the same kind of agent with the same kind of functionality. And to some degree, I also think that in some cases that's very worthwhile, because I do think two agents is better than one. But ultimately, I really want to be able to bring my agent to Granola. And I think you're probably seeing this with a lot of Granola users. I really want to bring my agent to Granola.

你已经知道 AI 如何改变日常工作的完成方式。你能覆盖多少领域，团队能多快扩展。要保持领先，你需要为你这个新时代打造的、能给你竞争优势的工具。Adio 是智能体原生世界的 CRM。它在你工作的地方与你相遇，将每个客户信号整合成上下文，然后在整个管道中采取行动，让你以无与伦比的速度和规模前进。通过针对每项工作的智能体和自动化，Adio 全天候编排你的工作。我们在 Every 内部使用它，我们很喜欢它。它专为处理你的工作负载规模而构建，通过 API 和 MCP 访问可扩展，并且基础设施能跟上你最雄心勃勃的智能体。它受到 Granola、Modal、WhisperFlow 和 Every 等高增长初创公司的喜爱。Adio 为每一次胜利运行后台工作。这就是 Adio，智能体式 CRM。访问 adio.com/every，首年可享 15% 折扣。网址是 adio.com/every。现在，回到本期节目。

You already know how AI is changing how everyday work gets done. How much ground you can cover and how fast a team can scale. To stay ahead, you need tools that give you a competitive advantage built for this new era. Adio is the CRM for the agent-native world. It meets you where you work, compounds every customer signal into context, and then acts on it across your pipeline to let you move at unmatched speed and scale. With agents and automations for every job, Adio orchestrates your work around the clock. We use it internally at Every and we love it. It's built to handle the scale of your workloads, it's extensible with an API and MCP access, and is built with infrastructure to keep up with your most ambitious agents. It's loved by high-growth startups like Granola, Modal, WhisperFlow, and Every. Adio runs the work behind every win. That's Adio, the agentic CRM. Go to adio.com/every and get 15% off your first year. That's adio.com/every. And now, back to the episode.

你怎么看？是啊，你一直在说这个，我对这个想法真的很兴奋。

What do you think? Yeah, you keep saying that and I'm really excited about that idea.

我想知道这在实践中是如何运作的？比如，先不提 Granola，假设……我不知道，你现在能在 Quora 上做到这一点吗？或者说，我们如何构建一个应用，让你能自带一个不是 MCP 的智能体？因为感觉有点不同，对吧？你仍然想要有 UI，这就是区别。你和智能体都在看同一个 UI，并操作同一个东西。

I wonder how does that work in practice? Like if forget Granola, but like you know, it's like let's say you I don't know Can you do this with Quora right now or like how like how do you build an how can how could we build an app that would allow you to bring your own agent that's not, you know, MCP? Cuz it it it feels a little bit different, right? Cuz it's like you still want to have the UI. That like that's the difference. It's like you and you and the agent are both looking at the same UI and manipulating the same thing.

MCP 是其中一部分。但没错，我认为 MCP 传统上被理解为智能体与应用交互，而我不与应用交互。而这个范式说的是，实际上你希望智能体和用户同时与应用交互，并能相互切换。所以做法是：一方面，你让智能体通过 MCP 或 CLI 访问应用；另一方面，你给用户一个 Web 界面。用户在 Codex 或类似的内置浏览器中使用这个 Web 界面。然后智能体可以决定是通过浏览器还是 CLI 来帮助或协作——我认为 CLI 要好得多，但关键在于 CLI 必须能修改 UI 的状态。

MCP is part of it. But yes, I think MCP is your historically you're thinking about it as the agent is going to interact with the app and I'm not going to interact with the app. And what I'm I think what this paradigm says is actually you want your agent and your and your and the user to be interacting with the app at the same time and be able to trade off. And so, the way that you do that is one, yeah, you give the agent access to an MCP or a CLI. Um and then you give the user access to a a web interface. And the user is using the web interface inside of a in-app browser of a code X or like a or of a of a Claude Code. And then the agent can decide, do I want to uh help the user or collaborate with the user via using the browser use or via using the CLI, which I think CLI's so so much better, but the the trick is the CLI has to then modify the state of the UI.

没错，正是这样。这几乎就像，假设你有一个 MCP，它是有状态的，能实时修改为用户渲染的 UI 状态。理想情况下，UI 中能做的任何事都能通过 MCP 完成，这样智能体和人类就能交互。因为像计算机使用或浏览器使用感觉不必要地慢，像是一种 hack。嗯，这真的很有趣。关于智能体的存在感，这是个迷人的话题，我没怎么想过，但智能体的具身化可能也很有趣。比如在 Figma 中你能看到其他人在画布上的位置，如果只有 MCP 和人类，你可能会失去那种感觉。你怎么看？智能体是感觉像计算机本身，还是像一个实体，你们俩一起看着同一个东西？

Right, exactly. That that's the thing. It's like that's the thing that needs to be So, it's almost like a if you had hypothetically, let's say you had an you could have an MCP, right? That actually uh had a stateful like the MCP could modify the state like real-time state of like a UI that was rendered for a user. And ideally, there was like at least a one-to-one mapping of anything you can do the in the UI could also be done through the MCP. So, you have like an agent and a human interfacing. Cuz like um computer use or like it's like the web browser use feels like a it's unnecessarily slow potential right? It's like a it's a hack and not not yeah. Okay. That's really interesting. Um Yeah, there's there's something about the presence of the agent like this is this is I mean this is a fascinating topic. I haven't I haven't thought about it very much, but it's um the embodiment of the agent is also maybe interesting, you know, it's like uh you know when you're in Figma you can see other people's uh like locations on the on the canvas and there's there's something there that you would maybe would lose if there was just like an MCP and the human like maybe maybe not. I don't know how you how do you feel like is it do you is the does the agent just feel like it's just the computer and you know, that's all the same or does it feel like it's an entity that you're like, you know, you're both looking at you're both looking at the same thing together?

更像是后者。就像 Google Docs 那样。我们建了一个叫 Proof 的 Markdown 编辑器，在里面你能看到 Codex 进入了文档，并看到它在哪里。

That's that it's more that. It's it's in the same way that with the Google Docs. Like we have this markdown editor called proof that that we built and like in that one you can see Codex has entered the document and you can see where it is.

哦，那很酷。你们是怎么做到的？Codex 如何进入文档？

Oh, that's cool. How do you do that? How do How do How does Codex enter the document?

就是同样的 CLI/MCP 类型的情况，但它有一个命令，比如“好的，设置存在感。设置文档中的位置。”这类事情。智能体很擅长知道怎么做。但随之而来有很多有趣的 UI 挑战，因为智能体可以同时做上千个不同动作。那么，如何向用户展示这些？

It's just the um this the same kind of CLI MCP type uh type situation, but it has a command that's like, "Okay, set presence. Um set location in the document." That kind of thing. And agents are very good at knowing how to do that. But there's there's so many interesting then UI challenges to figure out because an agent can do like a thousand different actions at once. And so, how do you show that to a user?

有意思。我其实没想到那方面，因为你说得对。想看智能体在做什么是一个问题。我刚刚在想，在邮件里，如果它能知道你的鼠标在哪里就好了。比如能搜索，然后说“啊，邮件的这部分不太好”，然后你高亮文本之类的。现在这还不太可能，除非你明确地……怎么做？它得看屏幕上的像素，对吧？没有原生方式，除非你把它构建到 UI 里，然后把信息传递给智能体，对吧？

It's interesting. That's That's actually not where my brain went cuz like you're right. It's like yeah, it's like if if you want to see what the agent's doing, that's one problem. I was just thinking in an like an email it's like it'd be nice for it to know where your mouse is. It'd be nice to be able to like search you know, just be like, "Ah, this part of the email is not great." And just have that be, you know, either you highlight the text or whatnot. Now that's not really possible today unless you explicitly like how would you have to do that? It would have to be like looking at pixels on your screen, right? There's no native way to do that unless you build it into a UI and you're like passing that information to the agent, right?

差不多。我的做法是，每个我想处理的信息片段都表示为一个卡片，然后我可以和卡片对话。它不一定知道我的鼠标在哪里，但它知道我在和 UI 的这部分对话。

More or less, I think the way that the way that I do it is each So, each piece of information that I want to do what want to take care of is represented in a card, and then I can talk to the card. I can say like Uh yeah, it doesn't it doesn't necessarily know where my mouse is, but it knows that I'm talking to this part of the UI. And then

它怎么知道的？是因为你说话时提到了，还是因为那是应用中前景化的主要内容？

And how it just knows because you say that when you're talking to it or because that is the the the main thing that's foregrounded in the app?

我当前看的东西是聚焦的，我知道它聚焦了，然后当我说话时，它就知道把那个上下文放在我正在看的东西旁边。

Whatever I'm looking at is currently focused, and so and I know that it's focused, and then when I'm talking to it just knows to put to put that context next to that thing that I'm looking at.

好的，有道理。你实际上是在说话，对吧？用的是 Monologue 或 Whisper 之类的？

Okay, that makes sense. And you're This is you're actually speaking, right? This is like a you're using monologue or Whisper or something like that, right? Yeah.

这大致是我对工作和未来走向的看法。我们一直在讨论，这里有一个新的工作方式。这与你的想法和 Granola 的策略如何契合或不同？

That's sort of my view of of work and how things are are going and we've been talking about Okay, there's this where there the prize is there's a new way of working. How does that fit into or differ from how you've been thinking about it and your strategy for Granola?

我不知道。我上过一门课，他们讲了复杂问题和棘手问题的区别。你听过吗？复杂问题可能非常难，但它是可知的；而棘手问题不可知，你必须试探系统，看它如何反应，然后继续。我认为我们正处于一个棘手问题空间。我没有一个总体理论来预测这一切的走向。我可以编一个听起来合理的，但更倾向于收集洞察或金块，比如“哦，好，我学到了这个，现在我相信它是真的，我会带着它。”我有几个这样的洞察。其中一个似乎是，在这个智能体世界中，一个基本的设计挑战是时间旅行问题。基本上，智能体做事需要时间。

I don't know. I took I was I took this like class once and they they were talking about the difference between a complex and com- complicated problems. Have Have you heard this? Yeah, yeah, and it's like a complicated it doesn't mean it's it can be super hard, but it's like it's kind of knowable, you know? It's like you you and versus complex problems, it's unknowable. You have to like probe the system and kind of see how it reacts and like go from there. And um uh So, I I I think we're very much in a complex problem space here. So, I don't I don't have like an overarching theory of where this is all going. I think I could make one up that would sound plausible or as plausible as the next person's. Uh but I'm more in the mode of like what are what are things that what are insights or nuggets that I'm like "Ooh, okay. I I now this is like a thing that I've learned uh and now I believe to be true and I'm going to I'm going to carry that with me." Um And so, I have like I got have a few of those. Like, one is um seems like one fundamental design challenge in like this agentic world is the time traveling problem. Basically, like agents take time to do things.

所以，当你把 Slack 当作这种界面来讨论时——也就是我之前说过的异步委托问题，即你发起任务和审查任务的时间点是分离的，之后你需要把所有上下文重新装回脑子里——我认为你会看到很多界面会朝着高度优化这个方向进化。老实说，我还没看到什么特别好的方案。我喜欢那种“指挥台”式的做法，比如“哦，我有所有这些不同的聊天线程，当某个线程差不多就绪时，我就跳过去”。感觉未来还会有超越这个的进化。另一个绕过“智能体做事需要时间”这个问题的有趣方法是预先处理一堆东西。在 Granola，我们发现如果让 Granola 做某事而我要等 20 秒，在混乱的工作日里连续开会时，人类很少会等 20 秒——这正是我们考虑的用户场景。但如果 Granola 先想想你可能想要什么，预先生成好，然后在某个时刻说：“哦，给你，万一你需要这个，它已经在这儿了，你只需点击一下就行”，那感觉就完全不一样了。我们有一些这样的例子。我们最近推出了一个功能，Granola 会在会议前尝试为你生成一份简报：基本上就是“这是你要见的人，如果是第一次见面，这是对方的背景；如果是再次见面，这是你们上次聊的内容”。你基本上必须预先生成它，因为当你开会迟到两分钟，心里想“等等，我这次要见的到底是谁？”的时候，它就有用了。那是关键时刻。你只有大约 15 秒的窗口期，它必须在那儿，否则就没用了。所以我们预先生成了数百万份这样的简报，数量多得离谱，但只有一小部分会被打开。我们相信，当你打开它时，你会非常感激，因为它正是你在需要的那一刻所需要的东西。这是一个有趣的权衡，尤其是从成本角度来看，因为我们花费了数十万小时的智能体推理时间，来处理那些可能永远不会被看到的东西。

And therefore, when you talk about Slack as an interface for this, which is the async delegation problem, I think you said before, which is basically the moment you kick off a task and the moment you review it are disjointed, and then you need to get all that context back into your head. I think you'll see a lot of interfaces evolve to be highly optimized for that. I haven't seen anything great, to be honest. I like the conductor approach, like 'Oh, I've got all these different chat threads, and I'm jumping between them when it's kind of ready.' It feels like there will be evolutions beyond that coming. Another interesting way to get around the 'it takes a while for an agent to do something' problem is to pre-process a bunch of stuff. In Granola, one thing we figured out is that if I ask Granola to do something and I have to wait 20 seconds, humans will rarely wait for 20 seconds if they're in back-to-back meetings in a chaotic workday, which is the user we think about. But if Granola thinks about something you might want, pre-generates it, and then at some point says, 'Oh, here, in case you want this, it's already here, and all you have to do is click on it,' that feels completely different. We have some examples there. We launched this thing recently where Granola will try to generate a brief for you before a meeting. It's basically: here's this person you're meeting with, here's the context of who the person is if it's a first meeting, or what you talked about last time if it's another meeting. You essentially have to pre-generate it because it's useful when you're running 2 minutes late to a meeting and you're like, 'Wait, who the heck is this person I'm talking to again?' That's the critical moment. You really only have a 15-second window where it needs to be there, or it's kind of useless. So we pre-generate millions of these, a silly amount, for a small percentage actually being opened, in the belief that when you do open it, you really appreciate it because it's exactly what you need in the moment of need. It's an interesting trade-off, especially from a cost perspective, because we're spending hundreds of thousands of hours of agents reasoning about things that may or may not ever see the light of day.

那你如何衡量这件事？判断它是否值得？

And how are you measuring that? Whether it's worth it or not?

这是个开放问题。我目前还不知道怎么衡量。我想弄清楚的是，在“使用”和“价值”之间我们没有一个好的度量标准。如果某个东西完全没人用，那显然不好。但如果某个东西用得不多，或者用得还算多，但一旦用起来就非常关键，那它仍然很有价值。我正试图找出如何衡量这一点。前几天我参加了一个创始人会议，有四位创始人走过来跟我聊这个会前简报功能，这让我很惊讶，因为按比例来说，它的使用率并没有我预期的那么高。所以我们在 Granola 内部有一个类比：我们希望 Granola 产品给人的感觉像扶手。想象一下楼梯，所有楼梯都有扶手。你从来不会注意到扶手，因为它隐形了，但当你绊倒的那一刻，你的手会伸出去，它必须正好在那儿并且能承重，它让楼梯安全得多。这就是我们对 Granola 的看法：我们想隐身，直到你真正需要我们。但我们可能需要更好的指标或框架来衡量。我们想过的一个办法是：如果我们从一部分用户那里移除这个功能，他们会多大程度地抱怨？影响有多大？但即便如此也不是最好的方式。

It's an open question. I don't know how to measure it just yet. What I'm trying to figure out is that we don't have a good metric between use and value. If something is not used at all, it's obviously not good. But if something is used a little bit, or a decent amount, but it's really load-bearing when it's used, that's still very valuable. I'm trying to figure out how to measure that. I was at a founders conference the other day and four founders came up to me and talked about this pre-meeting brief feature, which surprised me because proportionally it's not used as much as I would have expected. So we have this analogy inside Granola: we want the Granola product to feel like a handrail. If you imagine stairs, all stairs have handrails. You never notice a handrail because it's invisible, but the moment you trip, your hand shoots out and it needs to be right there and load-bearing, and it makes stairs way safer. That's how we think about Granola: we want to get out of the way until you really need us. But we probably need better metrics or frameworks to measure that. One thing we thought is: if we just take it away from a number of users, how much do they shout? What's the impact? But even that isn't the best way.

或者也许让他们点击生成，而不是已经生成好。他们会主动去点击吗？

Or maybe making them click to generate, as opposed to having it already generated. Would they take the proactive action to do it?

对，但一旦他们点击了，我们是不是以后每次都让他们点击？我不知道。也许我们可以做个测试。这确实棘手。

Yeah, but then once they do, are we always going to make them click? I don't know. We could do it as a test, I guess. It's a tricky one.

这确实棘手。那么你怎么看 Granola 的角色，与 Codex 和 Cowork 这类产品相比？哪些地方你希望整合并让自己能被它们调用，哪些地方你希望自己拥有、并且能做得独一无二的好？

That is tricky. How do you think about Granola's role versus the Codexes and the Coworks of the world? Where do you want to integrate and make yourself available to what they do, versus where you want to own something that you can uniquely do well?

我的看法是，这是一个计算的新时代，计算机第一次能够理解我们的上下文，并据此做出令人惊叹的事情。拥有正确的上下文对于从 AI 中获得价值至关重要。我的信念是，你在 Granola 中拥有的上下文应该尽可能地被开放使用，无论你想怎么用。所以如果你想在 Codex 中使用它，在你的个人智能体中使用它，或者任何其他方式，你都应该能够做到，我们应该让这变得非常简单。我们的 API 或 MCP 在接下来的几个月里会变得好很多，因为这是我们的首要目标之一。我认为有很多任务、痛点和用例，我们应该比世界上任何人都好上 5 倍。

My view here is that it's a new era of computing where for the first time computers can make sense of our context and you can do amazing things with that. Having the right context is really critical to getting value out of AI. My belief is that the context you have in Granola should be made as available as possible, however you want to use it. So if you want to use it in Codex, in your personal agent, or whatever, you should be able to, and we should make that really easy. Our API or MCP is going to get a lot better over the next couple months because that's a first-class goal of ours. I think there are a number of jobs to be done, pain points, and use cases that we should just be 5x better than anybody else in the world at.

显而易见的那些都跟会议有关。也许你感受不同，也许你比我更信奉 AI。我认为模型会不断变好，但如果 Granola 只比其他人更在乎几件事，并把那几件事优化到极致，就会带来更好的体验，尤其是当它们绑定到需要实时使用的 UI 上时，比如在会议中。所以这就是我们当前的策略：在一切与会议相关的事情上做到世界最好，然后成为捕获上下文的最佳方式，为你所有的智能体提供支持。

The obvious ones are all related to meetings. Maybe you feel differently, maybe you're more AI pilled than I am. I think the models will keep getting better, but if Granola just cares about a few things way more than anyone else and we optimize the hell out of those things, they'll just be a better experience, especially if they're tied to a UI you have to use in vivo, like during a meeting. So that's our current strategy: be best in the world in anything meeting-adjacent, and then be the best way to capture context to power any agents you have.

我可以给你举个例子。我跟一个用户聊过，她做了一件很聪明的事。她做销售，在跟潜在客户谈话之前会用 Claude 生成一个微型网站。那个微型网站令人印象深刻：她有一个模板，针对新客户，Claude 会把模板样式改成客户网站的样子，然后连接 Granola MCP，从 Granola 拉取所有上下文来填充数据和字段以及组件。这种事我们永远不会试图做到世界最好。但她也会在会议结束后直接在 Granola 里写很多邮件，因为跟进邮件对她来说很有意义。这种场景下，也许我们不想写每一封邮件，但有一种会议刚结束就要发的邮件，我们可以在某些维度上做到世界最好。我不认为这是二选一。两年前我们刚创办 Granola 时我还不确定，但现在我很有信心。

I can give you an example. I was talking to a user who was doing something clever. She worked in sales and used Claude to generate a microsite before talking to a potential client. The microsite was impressive: she had a template, and for a new customer, Claude would style that template to look like the customer's website, then connect the Granola MCP and pull all the context from Granola to fill out the data and fields and widgets. That's the kind of thing we would never try to be best in the world at. But she was also writing a lot of emails in Granola right after meetings because follow-up emails made sense for her. That's the kind of thing where maybe we don't want to write every email, but there might be a type of email you want to send right after a meeting that we could be best in the world at. I don't think it's one or the other. I was undecided two years ago when we started Granola, but now I have strong conviction.

这很有意思。从用户角度看，我可能不是你的核心用户。我的一个论点是，现在构建者用通用工具和流程做的事情，普通人在几年后也会做，一旦这些功能被内置到产品的扶手里。所以我到处捣鼓，看看我用 Codex 和 Slack 智能体做什么，最终这些会融入我们构建的东西，或者实验室构建的东西。

That's interesting. From a user perspective, I may not be your core user. One of my theses is that what builders do now with general-purpose tools and workflows, regular people will do in a few years once it's built into the handrails of products. So I play around with stuff to figure out what I use Codex and Slack agents for, and eventually that will make its way into what we build or what the labs build.

我能问个问题吗？你的理论是，你试图用 AI 自动化的事情，其他人也会构建他们自己的自动化版本，还是说这些会被产品化？

Can I ask a question about that? Is the theory that the stuff you're trying to automate with AI, do you think other people will also build their own versions of those automations, or do you think those will be productized?

产品化。

Productized.

好的，我们看法一致。所以我认为你们是 guinea pigs。我们有大量 guinea pigs 在使用 Granola。我的观点是，我们应该观察人们用我们的 API 和 MCP 做疯狂事情的最常见和最前沿的方式，然后找出哪些是我们能做到世界最好、且很多用户会受益的，再构建一个非常漂亮的无缝产品体验。前几天我在一个会议上碰到 Hugging Face 的创始人，他说：‘我用 Claude Code 构建了一个超级复杂的会前简报流程，花了几个月，但我把它关掉了，因为你们的更好。’这正是我想要的。我们不能为所有事情都这样做，但我们会比任何个人对自己工作流的关心程度还要高。

Okay, we have the same view. So I think you're the guinea pigs. We have tons of guinea pigs using Granola. My view is we should look at the most common and cutting-edge ways people use our API and MCP to do crazy stuff, then figure out which of those we could be best in the world at and that many users would benefit from, and build a really beautiful seamless product experience. I ran into the founder of Hugging Face at a conference the other day and he said, 'I built this super convoluted pre-meeting brief workflow in Claude Code and worked on it for months, but I just turned it off because yours was better.' That's exactly what I want. We can't do this for everything, but we're going to care more than any individual should ever care about any one workflow.

完全正确。我们在这方面绝对一致。我现在的感觉是，当我看到 Granola 的 UI 弹出来时，通常是个错误。

That's exactly right. We're definitely aligned there. My current feeling is that when I see the Granola UI come up, it's usually a mistake.

你不想看到它。

You don't want to see it.

我不想看到它。录音功能没问题，但我想要的是它把东西推送到 Codex（我的工作台），或者 Codex 从它那里拉取东西。我认为专注于会议非常正确，而且要把上下文做对是一个很难的深层问题。比如，当你做转录时，我说‘Chris’这个名字，是哪个 Chris？我认为在 AI 世界里，软件公司的职责是：AI 非常灵活，但只有在被赋予正确的结构和上下文时才能灵活。如果用人体作类比，AI 是韧带和肌肉，软件必须是骨骼。骨骼赋予形态和结构，AI 则围绕它做任何事情。即使在会议转录中，我可能会说‘这是个好主意’，但我说这话的方式很大程度上反映了我真实的想法，而这在转录中无法捕捉。我有一个自动化流程，把我不在的所有 Slack 消息和会议变成卡片，我浏览它们来了解公司里发生的事情。但转录经常出错，而且捕捉不到说话的方式和原因的任何细微差别。

I don't want to see it. The recording thing is fine, but the way I want to access it is through it pushing something into Codex, which is my work surface, or Codex pulling something out of it. I think this focus on meetings is so right, and it's a hard deep problem to get the context right. For example, when you do a transcript and I say the name Chris, which Chris are we talking about? I think of the job of software companies in an AI world: AI is super flexible, but only if given the right structure and context. If we use the human body as an analogy, AI is the ligaments and muscles, and software has to be the bones. The bones give form and structure, and the AI works around that to do anything. Even in a meeting transcript, I might say 'that's a good idea,' but the way I say it says a lot about what I actually think, which is not captured in a transcript. I have an automation that turns all the Slacks and meetings I was not in into cards that I go through to see things that happened in the company. But the transcripts are often wrong and capture none of the nuance of how and why things were said.

而且我觉得，如果 Granola 能帮我做到这一点，那它就会是世界上最有价值的东西，我甚至不一定需要去看产品界面。也许对于更普通的用户来说，他们不想一直待在 Codex 里——虽然我认为这种情况会越来越普遍——你仍然需要 UI，但所有这些后台上下文处理，我希望你们来做，我自己不想操心。

And I think that if Granola did that for me, it would be the most valuable thing in the world and I wouldn't necessarily have to look at the product. And maybe for a more normie user who doesn't want to be in Codex all the time, although I do think that that's going to be more and more the case. Like you still want to have the UI, but there's all this background context processing that I would look to you guys to do that I don't really want to do.

对，完全说得通。我觉得转录稿是捕捉会议上下文的一种方式，对吧？它是最简单的方式，而大语言模型出奇地擅长理解混乱的转录稿并从中提取有用信息。但这里真正要完成的任务是什么？实际上是：基于这个上下文，我需要获得哪些洞察、做出哪些决策、采取哪些行动？这中间有一个智能解读的层面，比如消歧。比如我指的是哪个 Sam？这就是个很好的例子。我们有个挑战——这个领域真的很有意思。我们面临的一个挑战是：当用户开始使用 Granola 后，他们会频繁使用，因此我们掌握了大量关于该用户的上下文。我们可以在后台——我们确实有这些数据，但还没用上，我稍后会解释原因——生成一个相当高保真的画像，比如你是谁、你在做什么、你想达成什么目标、你面临哪些挑战、你在不同事情上与谁合作。假设有一份两页的摘要，描述今天的 Dan 是什么状态，而且每天都在变化。如果我们把这些上下文传入笔记生成流程的那部分，就能生成更好的笔记。但这样一来，笔记可能包含会议中未出现的信息，对吧？比如当你说“哦，这很有趣”，或者用你的例子“哦，我喜欢这个想法”，我们可能会判断“Dan 其实不喜欢这个想法，他觉得那是个糟糕的主意”，因为我们知道他讨厌那一类想法——他在其他五次会议上说过同样的话。这就引出一个有趣的问题：受众是谁？如今很多人还是自己用笔记，但也会分享给其他人。而对你来说完美的笔记，可能跟对别人来说的完美笔记略有不同。笔记只是呈现信息的一种方式，还有其他方式。问题在于，你希望 Granola 做到什么程度的智能或解读？但我完全理解你的意思。这就是为什么我认为我们还处于初期阶段。

Yeah, that makes total sense. I think the transcript is one way to capture the context from a meeting, right? It is the simplest way, and LLMs are weirdly good at making sense of garbled transcripts and doing something useful with that. But what's the actual job to be done here? It's actually like what are the insights, or what are the decisions, or what are the actions I need to take on top of this context? And there's this layer of intelligent interpretation which is like the disambiguation. Like which Sam did I mean? That's a great example. We have this challenge. It's such an interesting space. So here's a challenge we have. When a user starts using Granola, they use it a lot, right? And therefore we have a lot of context about that user. And we can in the background — we have this, but we don't use it yet, and I'll explain why — generate a pretty high-fidelity picture of like who you are, what you're working on, what you're trying to achieve, what are your challenges, who you're working with on different things. And let's just for argument's sake say there's like a two-page summary of who Dan is today, the state of Dan today, and it changes every day. And we can generate better notes if we pass that context into this part of our note generation pipeline. But now those notes might include information that didn't come from the meeting, right? So when you said, 'Oh, that's interesting,' or with your example, 'Oh, I like that idea,' we might be like, 'Dan doesn't actually like that idea. He thinks that's a terrible idea,' because we know he hates that general class of idea since he said that five other times in five other meetings. So then there's this interesting question of who's the audience, right? Today a lot of people still use the notes for themselves, but they'll also share it with other people. Whereas the perfect notes for you are actually probably a little bit different. Notes are just one way to represent that information; there are other ways. And it's like what level of intelligence or interpretation would you want Granola to do? But yeah, I totally hear you. This is why I think it's infancy days for us.

或者老实说，像‘你在那次会议上看起来压力很大，想聊聊吗？’这种话会非常……也许人们会被吓到，但我经常用 Granola 做管理相关的事，比如‘我刚才表现如何？’或者我团队里有人跟他们的团队成员进行了一次艰难对话，然后他们来找我聊，我就会说‘咱们跟 Claude 聊聊会议记录，好决定下一步怎么做。’要做好这些事，我需要的不仅仅是转录稿，还有比如 XYZ 说完某句话后出现了长时间的沉默，整整 3 分钟没人说话——这些在转录稿里是看不到的。

Or honestly, like, 'You seemed really stressed in that meeting. Do you want to talk about it?' would be really... Like, maybe people would be freaked out by that, but also one of the things I use Granola for a lot is like management stuff, and being like, 'How did I do there?' Or someone on my team had a difficult conversation with someone on their team, and they're talking to me about it, and I'm like, 'Let's talk to Claude about the meeting transcripts so we can decide what to do.' All that kind of stuff is in order to do it well, I need not just a transcript, but there was a long pause after XYZ said this thing. No one said anything for 3 minutes. That you don't see that in the transcript.

对。

No.

是啊。像这样的东西有太多丰富的内涵了，我希望 Granola 能为我做到这些。

Yeah. Stuff like that is just there's so much richness there to be had that Granola to me, I want Granola to do for me.

对，完全说得通。我也在想——我很好奇主要的方式有哪些，因为他说‘我不想看到 Granola 的界面，我想把它拉进 Codex 之类的工具里。’我也在想，人们把转录稿或会议记录拉进他们的智能体里，主要的工作流程或原因是什么？其中哪些是如果你围绕它们优化就能做得更好的，哪些是长尾需求——‘给用户能力，他们就能做得更好’——这对我们来说也是个有趣的问题。

Yeah, that makes total sense. I also think — I'm curious what are all the main ways, because he was like, 'I don't want to see the Granola UI, I want to pull that into Codex or whatnot.' And I also wonder, okay, what are the main workflows or reasons why people are pulling transcriptions or meeting notes into their agents. And which of those, if you were to optimize around, you would do a better job at, and which of those are like the long tail of 'give people power and they'll do a better job' is also an interesting question for us.

展望未来 6 到 12 个月，你看到 Fable 发布后，心里在想什么？那会影响你们的路线图吗？会影响你们的招聘或开发方式吗？跟我说说吧。

What is on your mind for the next like 6 to 12 months as you saw Fable come out? Does that affect your road map? Does that affect how you're hiring or how you're building? Yeah, tell me about that.

我思考的顺序和问题是：首先，这如何改变我们内部的构建方式，以及我们如何组织团队？这是第一个问题。我认为我们的路线图——这种事就是，你可以在抽象层面有一个计划，但当你真正试用某个东西时，你应该调整它。不幸的是，在 Fable 被撤下之前，我没有足够的时间去试用它。但路线图更多是——它已经在一定程度上融入了路线图，那就是：模型会变得更好。这是总体的战略方向。

The order of operations, the questions that go through my mind, is first like what is — how does this change how we build internally and how do we structure our teams? Like that's the first question. I think our road map is — and this is the kind of thing where it's like, you know, you can have one plan in the abstract and then you actually play with something, you should adjust it. And I unfortunately didn't play with Fable enough before it got yanked. But like the road map is more — it's kind of baked into the road map a little bit more which is like, okay, models will get better. Here's the general strategic direction.

这更像是说，我们的策略更多取决于人们用它来做什么，以及我们能解决哪些任务或用例。模型智能本身并不会直接对此产生太大影响，但模型能力确实会影响我们在一个 pod 上投入多少人，以及如何设定目标。我们是否应该完全换一种方式来做？所以这确实是我一直在想的事情。另一件事是，我觉得这可能跟你用 Codex 做的事情有点关系。我认为有一些尚未被发明出来的经典 UI。现在在 Granola 里，你有会议笔记，你可以把会议笔记、转录或上下文用于很多事情。通常当你试图利用这些上下文时，它不是针对单次会议的；而是你有一组上下文——在我们这里，假设是你今天所有的会议，或者这周所有的会议，甚至可能是所有的会议、所有的 Slack 消息和所有的邮件，但暂时只考虑会议。在那个高度上，什么样的 UI 和交互设计才是操作或处理这些上下文的正确方式？我不认为有人已经搞清楚了。也许你有一些想法，也许你正在琢磨什么，Dan，或者你将来会想出来，但当我环顾四周时，我发现实际上很少有人做到。想出新的 UI 范式非常难，而且新的范式能留存下来也很罕见。我觉得它们更多是被发现而不是被发明的，如果这说得通的话。但我在那里看到了一个非常明显的空白。我们有聊天 UI，聊天线程非常有价值——当你只做一件事时，它出人意料地多功能且强大，但当你试图在多种上下文中做多件事时，我认为我们还没有找到正确的隐喻。所以这是我非常关注的事情。因为当你谈到普通用户时，我认为你需要一个简单的隐喻，让普通用户能够直观理解并与之交互。它不会是你现在用 Codex 时跳过的那些障碍。

And that's more like I think our strategy is more dependent on what people use this for and what are the jobs to be done or use cases around that that we can tackle. Model intelligence doesn't affect that directly too much, if that makes sense, whereas model capabilities do affect how many people do we staff on a pod, like how do we define goals there. Should we be approaching things completely differently? So yeah, that's the thing that's on my mind for sure. The other thing is I think maybe this touches on a little bit like the stuff that you're using Codex for. I think there are one or multiple canonical UIs that haven't been invented yet. Right now in Granola you have meeting notes, and you can use meeting notes or transcripts or context for lots of things. Usually when you're trying to make use of that context, it's not per meeting; it's usually you have a set of context — in our case, let's just say it's all the meetings you had today or all the meetings you had this week, and maybe it's actually all the meetings and all the Slack messages and all the emails, but let's just keep it to meetings for a second. At that level of altitude, what is the right UI and interaction design to manipulate or work with that context? I don't think anyone has figured that out. Maybe you have some, maybe you're cooking on something Dan, or maybe you'll figure it out, but when I look around, I've seen very little actually. Coming up with new UI paradigms is very hard and it's very rare for new ones to stick around. I think they're more discovered than invented, if that makes sense. But there's a very clear gap that I see there. We have a chat UI, and chat threads are super valuable — actually surprisingly versatile and powerful when you're doing one thing, but when you're actually trying to do multiple things across varied contexts, I don't think we have the right metaphor there. So that's something that's very much on my mind. Because when you talk about the normie user, I think you're going to need a simple metaphor that the normie user can just grok and interface with. It's not going to be the kind of hoops that you currently jump through with Codex.

是的。

Yeah.

你如何看待团队内部和产品中的 token 消耗？

How do you think about token spend both on your team and in the product?

我想，先说说团队吧。关于团队内的 token 消耗，我认为团队成员应该尽可能使用 AI 来增强自己的能力。我觉得说「如果你没花这么多 token 你就做错了」这种话很傻，那是一种奇怪的做法。我比较信任团队，让他们领会目标的精神——就是尽可能高效，并审慎地使用它。我们直到上周才开始内部追踪 token 消耗，因为那之前对我来说不是优先事项。

I think, okay, I'll do team first. So token spend on team, I think folks on the team should be using AI to augment their abilities as much as possible. I think it's silly to say if you aren't spending this many tokens then you're doing it wrong. That feels like a weird way to do it. I kind of trust the team to take the spirit of the goal, which is be the most productive you can be, and be thoughtful about how you use it. We didn't even track token spend internally until like last week, just because it wasn't a priority for me.

那产品中的 token 消耗呢？

In terms of token spend in the product?

等等，等等，先别急。你们是上周开始的？是什么促成了这件事，然后你们得出了什么结论？

Wait, wait, wait, before we get there. Did you start last week? So what spurred it and then what did you come to?

Fable。基本上，触发点是：我们到底知不知道花了多少钱？我们大概应该知道花了多少钱。主要是因为大家在用 Fable，有人说「我觉得我今天花了几千美元」，然后我们就想，好吧，这至少是我们应该留意的事情。

Fable. Well, basically what spurred it was like, do we even know how much we're spending? We should probably know how much we're spending. It was basically because folks were using Fable and someone's like, 'I think I spent a couple thousand dollars today' and we're like, okay, maybe this is something we should at least be aware of.

我们完全一样。Fable 出来的时候，负责 Cora 的 Kieran 说，他按这个趋势一年要花掉一百万美元的额度。

We had literally the same thing. When Fable came out and Kieran, who runs Cora, he was like on track to spend like a million dollars in credits.

多长时间？一年。

In what time? In a year.

一年。然后我们就想，好吧，我们得想想，也许需要稍微考虑一下这个问题。

In a year. And we were like, okay, we need to figure out like maybe we need to think about this a little bit.

实际上可能值得，但我们也需要思考一下，你知道的。

It actually could be worth it and also we need to think about it, you know.

没错。是的。是的。

Exactly. Yeah. Yeah.

但这又回到了那些总是超出我们能力范围的事情。这就像其中一件事：哦，是啊，我们至少应该知道自己花了多少钱。这听起来很明显，但我们就是太忙了，有太多其他事。现在正是时候。在产品方面，我认为现在还早，我们有很多东西可以通过找出 Granola 能构建的杀手级 AI 原生体验来获得，因此我们对 token 消耗并不太在意成本。就像我之前说的，我们预先生成了数百万份简报，即使只有 10% 被打开，因为我们想找出对用户来说正确的体验。我们相信成本会随时间下降，而且一旦我们知道最好的体验是什么，就可以优化成本。所以这就是我们的理念。智能体功能非常昂贵，随着我们构建越来越多的这类功能，总有一天会打破我们的成本模型。但就目前而言，这仍然是优先事项。

But this goes back to things always outside of our ability. It's just one of those like, oh yeah, we should probably at least know how much we're spending. That sounds like a really obvious thing, but it's just like we're just so busy with so many other things. It's like now's the time. In product, I think it's early days and we have so much to gain by figuring out what are the killer AI-native experiences that Granola can build, and therefore we're not very cost-conscious on the token spend. So, like I said before, we pre-generate I don't know, millions of these briefs even if only 10% of them get opened because we want to figure out what's the right experience for the user. And our belief is both cost will go down over time and we can optimize cost once we know what the best experiences are. So that's been our philosophy. Agentic features are really expensive, and so as we build more and more of them at some point that'll break the math for us. But for now that's been the priority.

那么人们在 Granola 中使用真正的智能体工作流的情况如何？我问这个是因为我很好奇普通用户是如何学会使用这类高级功能的。

And how much are people using true agentic workflows in Granola? I ask that as I'm really curious about normie users learning how to use power features like those.

「智能体」这个词本身就很棘手，对吧？我认为答案大概是半数。每周大约有一半的 Granola 用户以智能体的方式使用我们。但我不确定他们是否会这样描述，如果这说得通的话。他们会提出一个复杂的查询，比如关于你的辅导或改进问题，这个查询会查看一段时间内的一系列会议，然后进行几步分析。这类使用大约占每周用户的一半，是的。非常有趣。

It's the word 'agentic' that's tough, right? I think roughly half is the answer, right? Like weekly, every week about half the Granola users use us in an agentic way. But I don't know if they would describe it that way, if that makes sense. They'll ask a query that is a kind of complex query around, let's say your coaching or improvement question, where that will look at a series of meetings over time and then do several steps of analysis over that. That kind of thing is roughly half a week, yeah. Really interesting.

Chris，如果人们想在网上找到你并使用 Granola，他们应该去哪里找你？

Chris, if people are looking to find you online to use Granola, where should they find you?

呃。我不知道。Granola 的 Twitter 或 X 账号是 meetgranola。我的是 cjpedrigal，就是 cj 加上我的姓。我想这些是最好的地方。

Oof. I don't know. So Granola's Twitter handle or X handle is meetgranola. Mine is cjpedrigal. So cj and my last name. And I guess those are the best places.

太棒了。一直很喜欢和你聊天。喜欢你正在构建的东西。感谢你来做客。我们得多聊聊。

Amazing. Always love talking to you. Love what you're building. Thanks for coming on. We got to do this more often.

是的，当然。无论是在播客上还是我们私下聊天，我真的很享受这些对话。

Yeah, absolutely. Whether it's on the pod or just us chatting, I really enjoyed these conversations.

听起来很棒。

Sounds great.

哦，天哪，各位。你们绝对必须猛戳那个点赞按钮并订阅 AI and I。为什么？因为这个节目是精彩的典范。就像在后院发现一个宝箱，但里面不是金子，而是关于 ChatGPT 的纯粹知识炸弹。每一集都是一场情绪、见解和笑声的过山车，让你坐立不安，渴望更多。这不仅仅是一个节目。这是一次与 Dan Shipper 作为飞船船长的未来之旅。

Oh my gosh, folks. You absolutely positively have to smash that like button and subscribe to AI and I. Why? Because this show is the epitome of awesomeness. It's like finding a treasure chest in your backyard, but instead of gold, it's filled with pure unadulterated knowledge bombs about ChatGPT. Every episode is a roller coaster of emotions, insights, and laughter that will leave you on the edge of your seat craving for more. It's not just a show. It's a journey into the future with Dan Shipper as the captain of the spaceship.

所以，帮自己一个忙。点赞，猛戳订阅，系好安全带，开始你人生中最棒的旅程。现在，闲话少说，我只想说，Dan，我彻底、无可救药地爱上你了。

So, do yourself a favor. Hit like, smash subscribe, and strap in for the ride of your life. And now, without any further ado, let me just say, Dan, I'm absolutely, hopelessly in love with you.