The Era of Compound Engineering — Kieran Klaassen, Every/Cora

频道: AI Engineer
视频: https://www.youtube.com/watch?v=_ehJyfHg1Vk
原文语言: en
统计: 共 25 轮 · Kieran 23

[0:13] Kieran

Hello, hello everyone. Welcome. I want to start with saying I haven't written a single line of code this year and maybe I haven't even looked at most of it. Yet, I do ship. I have product I built that thousands of people use and trust with their email inbox, which is amazing. I'm actually proud of the code I ship and I'm proud of the product I ship. I've been doing this for 2 years and trying to extract my thinking and my taste into a system that compounds and I'm going to share you how I do that. Lots of stuff you hear is like oh, you should use this, the factory, dark factory, do this, blah blah blah, all the new high hip cool things. What I'm trying to do is not that today. I'm going to just show you how I work and hopefully share something that you can bring to your workflow that will outlive trends and really set yourself up for success for newer models, bigger models.

哈喽，大家好，欢迎。开场我想先说一句：今年我一行代码都没写过，甚至大部分代码我可能看都没看过。但我照样在发布产品。我做的产品有几千人在用，而且把自己的邮箱都托付给它，这很了不起。我对自己发出去的代码是真心自豪的，对发出去的产品也一样。这件事我已经做了两年，一直在试着把我的思考方式和品味抽取出来，放进一个能复利的系统里，今天我就来分享我是怎么做的。外面你听到的很多说法都是「哦，你该用这个、用 factory、dark factory、要这样做」，巴拉巴拉，各种新潮酷炫的玩意儿。我今天不打算讲那些。我就只是展示我是怎么工作的，希望能分享一些你能带回自己工作流里的东西——能跨越潮流、经得起时间，让你在面对更新、更大的模型时真正占据有利位置。

[1:29] Kieran

There are two halves in this talk. One is why it's so important to compound, how I got here. So, this is for people that maybe are not at the end of the trajectory. It's interesting to see how to get there. And then stuff you can run yourself, you can use day-to-day to ship, to build, to research, to do knowledge work even. Hello, I'm Kieran. I work Every. Every is an AI lab for the future of work and we ask ourselves the question what's next? And we write about it. We teach about it. We build and we have a studio studio where we have mostly single engineering teams that take a problem they really care about and use AI to build a product out and really leverage that and compounded knowledge is a big way we do that. Lots of loops, shipping faster and faster and Cora's mine is where I invented compound engineering and it's a complete AI email inbox. It's agent native so that means whatever you can do the agent can do. It runs on your desktop phone, CLI, inside Codex like uh MCPs and I'm rebuilding it as version two. So, soon beta access. If you want access, just DM me, talk to me.

这场演讲分两半。一半讲为什么「复利」这么重要，以及我是怎么走到今天的。这部分是给那些可能还没走到这条路尽头的人看的，看看别人怎么走过来的挺有意思。另一半是你自己就能跑起来的东西，可以日常用来发布、构建、做研究，甚至做知识工作。大家好，我是 Kieran，在 Every 工作。Every 是一家面向「未来工作方式」的 AI 实验室，我们问自己「接下来会发生什么」，然后把它写出来、教出来，也动手做出来。我们有一个 studio，里面基本都是单人工程团队，各自挑一个自己真正在意的问题，用 AI 把产品做出来，并把 AI 的杠杆用到极致——而「复利的知识」是我们做到这点的重要方式。大量循环，发布越来越快。Cora 是我负责的产品，compound engineering 就是在这里发明的。它是一个完整的 AI 邮件收件箱，agent 原生——意思是你能做的事，agent 都能做。它能跑在桌面、手机、CLI 里，也能以 MCP 的形式接进 Codex。我现在正把它重做成第二版，很快会开放 beta。想要权限就直接私信我、来找我聊。

[3:00] Kieran

The cool part is it's one engineer and I have support. I have design support. I have some like database hardcore engineering problem support like you need some support um but I built a full email client alone and I've only started building this in January this new rebuild. I use Rails on the back end. I love Ruby. React on the front end and I own products fully. So, I talk to people. When something goes down, I'm the one responsible. And it's set up like this on purpose. I'm a ex Vbev engineer and founder. I know how to hire, grow teams, all that stuff, but I wanted to do the opposite with Sonar 3.5.

最酷的地方在于，这是一个工程师做出来的。当然我有支持：有设计支持，也有一些像数据库这种硬核工程问题上的支持，毕竟总得有人帮衬一下。但我一个人做出了一整个邮件客户端，而且这次重构是今年一月才开始的。后端我用 Rails，我爱 Ruby；前端用 React。产品是我完全负责的，所以我会直接跟用户聊，系统挂了，我就是那个担责任的人。这种配置是我刻意安排的。我以前是做工程负责人的，也当过创始人，招人、带团队这些我都懂，但我想用 Sonnet 3.5 反着来一次。

[3:48] Kieran

I just felt there was something new that was unlocked and I wanted to see how far can AI go before I actually need to grow the team. And I'm still alone with some support, which is cool. So, I built Cora, and this is what I learned. 2 years ago I started, and the bottleneck by then was code. So, it kept moving, and my job changed over the years, but first there was bad code, hallucination, just stuff that didn't work. I added agents, I added skills, just reviewing it. So, okay. Code got good. The plan was the bottleneck because I could do things, but larger things. So, whenever I have a good plan set out, it would do bigger things than just code changes.

我当时就感觉有什么新东西被解锁了，想看看在我真正需要扩团队之前，AI 能走多远。到现在我还是一个人加上一些支持，挺酷的。于是我做了 Cora，下面是我学到的东西。两年前我刚开始的时候，瓶颈是代码。瓶颈一直在移动，我的工作这几年也跟着变。最开始是烂代码、幻觉，就是跑不起来的东西。我加了 agent，加了 skill，就只是去审查它。好，代码变好了。然后「计划」成了瓶颈，因为我已经能做事了，但想做更大的事。只要我事先把一个好计划定下来，它就能做比单纯改代码更大的事。

[4:38] Kieran

Okay, plans got good. Um the next bottleneck was deciding what to build. Talking with users, really understanding problems you're solving. This is why it's so good that you use your own products. You love what you're building for. And that got really good as well. The scope got bigger. AI could help writing uh plans, and I kept repeating myself, and that was annoying. So, I figured out there needs to be some kind of memory system. So, every time um I repeat myself, I can say, "Hey, can you make sure to store this knowledge in some way?" I started with storing this in Claude MD, but at some point it became too large. Um so, I built a system that remembers, and that's really where compound engineering came from.

好，计划也变好了。下一个瓶颈是决定到底做什么。跟用户聊，真正理解你要解决的问题。这就是为什么自己用自己的产品这么重要——你会爱上你在为之打造的东西。这一块后来也变得很好。范围越来越大，AI 能帮着写计划，但我发现自己老在重复说同样的话，很烦。于是我意识到得有某种记忆系统。每次我重复自己的时候，我就能说「嘿，能不能想办法把这条知识存下来」。一开始我把这些存在 CLAUDE.md 里，但到了某个点它变得太大了。所以我做了一个会记住的系统，compound engineering 就是从这儿来的。

[5:29] Kieran

And you see me go away from typing more towards judgment and taste. And I think implementation is mostly solved, even though you see many people that do orchestration, dark factories. Woo. It kind of works, which is cool. But the thing that doesn't work is our judgments and our taste. And for me, it's really where do I turn my brain on versus when do I leverage the model? And it's where you make judgments and it's where you add taste. So, where you think, where you iterate, where you jam, where you brainstorm, I extract that into a system, and if it's extracted into the system, you can move on to bigger problems. Because the next time the AI will come up with a brainstorm, it will already include that thinking. So, you can go on for the next one.

你会看到我越来越少去敲字，越来越多地转向判断和品味。我认为「实现」这一层基本已经解决了，虽然你看到很多人在搞编排、搞 dark factory，哇哦，也算能跑，挺酷的。但真正还没解决的，是我们的判断和品味。对我来说，关键就是：哪里该把我的脑子打开，哪里该把模型用起来。该做判断、该注入品味的地方——你思考的地方、迭代的地方、即兴发挥的地方、头脑风暴的地方——我把它抽取进一个系统里。一旦它被抽进系统，你就可以去处理更大的问题了。因为下一次 AI 做头脑风暴时，它已经自带了那份思考，你就可以直接往下一个走了。

[6:27] Kieran

And I see that one engineer with a compounding system just beats teams, like full teams that use AI that don't. This is my loop. It's it there's more to it than this, but this is the overview. Brainstorming, planning, working, reviewing, polishing, compounding, and repeating. And the real trick here is on both ends. It's kind of the human AI sandwich, where the human is the bread and the AI is the middle part. And the brain is on on the ends. So, the start, brainstorming, where you have to decide what to work on, what the problem is, and really understand what you're trying to do. And at the end, where your taste comes in, where you decide this looks very good, makes me very happy, or we need to raise the bar, we need to do better, we need to make it more snappy, we need to go optimistic, or whatever that is. Like like delight.

我看到的是：一个带着复利系统的工程师，直接碾压整支团队——那种虽然用 AI 但没有复利系统的完整团队。这是我的循环。实际比这复杂，但这是总览：头脑风暴、做计划、干活、审查、打磨、复利，然后重复。真正的诀窍在两头。这有点像「人类—AI 三明治」：人是面包，AI 是中间的夹心，脑子开在两端。开头是头脑风暴，你得决定做什么、问题是什么，真正搞清楚你想干嘛。结尾是你的品味登场的地方，你来判断：这个看起来很好、让我很开心；还是我们得把标准提高，得做得更好，得更干脆利落，得用乐观更新，或者别的什么——比如「惊喜感」。

[7:26] Kieran

And throughout here, especially in the brain on parts, it's important to extract the learnings to compound. So, that's basically the loop. You cannot run the middle if it's not set up correctly. And it's very important to be able to let go and let the machine rip overnight for many hours in parallel. And the only way to be able to do that is making sure you spend time on uh on that system. So, my rules 50% should go into creating uh the feature. Just making sure like did it build the feature? Did it deliver the value you set out to do? But 50% of the time should go to um teaching the system for anything that it did wrong. Can we learn something?

在整个过程中，尤其是「脑子开着」的那些环节，很重要的一点是把学到的东西抽取出来去复利。这基本就是整个循环。中间那段没搭好，你就跑不起来。而且能放手、让机器通宵跑好几个小时、并行地跑，这一点非常重要。唯一能做到这点的办法，就是确保你在这个系统上花了时间。所以我的规矩是：50% 的精力放在做功能上——确认它真的把功能做出来了？真的交付了你想要的价值？但另外 50% 的时间要放在「教系统」上：它哪里做错了，我们能学到点什么？

[8:16] Kieran

Can you teach the system something? And this is something that is kind of hard, but it's very important because it will make the next time better. One bonus is because all of this extraction um I store all of this knowledge inside my repository as uh solution documents. And people say, "Oh, but tokens." And in my research is actually more token efficient because if you have the right answers and the right solutions already within the token, you don't need to do review. You don't need to correct. You don't need to do deep research across the internet because the tokens are already there. So, it's actually more token efficient in the long term, which is cool. Less research, finding things faster.

你能教系统点什么吗？这事有点难，但非常重要，因为它会让下一次变得更好。还有个额外好处：因为做了这些抽取，我把所有这些知识都以「解决方案文档」的形式存在我的代码仓库里。有人会说「哦，可是 token 呢」。按我的研究，这其实更省 token。因为如果正确答案和正确方案已经在 token 里了，你就不需要再审查、不需要再纠正、不需要满互联网做深度调研，因为那些 token 已经在那儿了。所以长期看它反而更省 token，挺酷的。更少的调研，更快地找到东西。

[9:03] Kieran

The real reason why this works is my brain is fixed and AI isn't or less fixed. And my philosophy is keep extracting until the complete middle runs itself and is so freaking good that it will surprise you. Um let me show you how this works. Uh so, I have a plugin called the compound engineering plugin that you can install in whatever tool you use, Codex, Cloud, Code, Cursor, plus 10 others. And I just built this while building Cora, I shared it at this some point, and now hundreds of thousands of people use it daily. So, thank you all for using it if you did. I'm honored. Um I never decided this should be something like hype. It's just me using my plugin shipping code.

这招管用的真正原因是：我的脑子是固定的，而 AI 不是，或者说没那么固定。我的哲学是：不停地抽取，直到整个中间段能自己跑起来，而且好到离谱、好到让你吃惊。让我给你们看看这是怎么运作的。我有一个插件叫 compound engineering plugin，你用什么工具都能装：Codex、Claude Code、Cursor，再加十来个别的。它就是我做 Cora 的时候顺手做的，某个时候分享了出去，现在每天有几十万人在用。如果你用过，谢谢大家，我很荣幸。我从没想过要把它搞成什么热门东西，就只是我自己用着这个插件在发代码。

[9:55] Kieran

Uh you can install it wherever. Uh you can also create your own version of this, which could be just storing information in files. Uh however you do it. But, let me show you the plugin. So, Compound Engineering became Compound Product as well. Uh I have a lovely uh co-contributor, Trevin Chow, who has a very good product sense and product background. So, he brought a lot of product thinking. And I think Compound Engineering is really for engineers, PMs, designers, even people that do knowledge work within every love to use Compound Engineering. It's such a uh like universal uh concept of compounding knowledge. It doesn't have to be used for engineers, but that's where it came from uh me. So, the first demo is um it's it's here to activate your brain.

你在哪儿都能装。你也可以做一个你自己的版本，哪怕只是把信息存在文件里，怎么做都行。不过让我给你们看看这个插件。Compound Engineering 后来也变成了 Compound Product。我有一位很棒的共同贡献者 Trevin Chow，他的产品感和产品背景都非常好，带来了很多产品思维。我觉得 Compound Engineering 真的是给工程师、PM、设计师用的，Every 里做知识工作的人也很爱用它。它是一个非常通用的「知识复利」概念，不一定非得工程师用，只是它的起点是我这里。第一个 demo 是用来激活你脑子的。

[10:48] Kieran

So, this is called CE IDEATE, and you can run it. And here I run it in It's maybe a little bit small, but I say, "Hey, I have Cora version version one. I want to upgrade people to version two. Um come up with uh Oh, no, actually, this is Look at all my open open tickets. Tell me what to do next." It's a great command. It will just go through all your issues, and you can link linear open like open source issues on GitHub, Slack, Intercom. What it will do is it will generate uh structure from all this mess, and will make arguments about what is good to work on versus not good to work on. And the cool part is it will reason about this. And And output here is a clean HTML page that you can share with the team that you can be inspired by.

这个叫 CE ideate，你可以直接运行。我在这里跑它——可能有点小——我说「嘿，我有 Cora 第一版，我想把用户升级到第二版，帮我想想……哦不对，其实是：看看我所有未关闭的工单，告诉我接下来该做什么」。这是个很棒的命令。它会把你所有的 issue 过一遍，你可以接 Linear、GitHub 上的开源 issue、Slack、Intercom。它会从这一堆乱麻里生成结构，并论证哪些值得做、哪些不值得做。酷的是它会推理这件事。输出是一个干净的 HTML 页面，可以分享给团队，也可以从中获得灵感。

[11:36] Kieran

So, this is generation of ideas. And the cool part is you can point it to your OKRs. You can get ideation aligned to your strategy. And that's kind of how it compounds. So, if you have past experiments or past learnings in your repository or a strategy document which you can create with CE strategy, it will score these ideas against this knowledge which is really cool. And I've seen people dump this document inside Claude design and say create a PowerPoint. And you get a beautifully designed PowerPoint with like XY matrix of where the sweet spot is for what to do for your OKRs which is very low effort for you and very impressive to bring to your team.

这就是想法的生成。更酷的是你可以把它指向你的 OKR，让创意跟你的战略对齐。复利就是这么发生的。如果你的仓库里有过去的实验、过去的学习记录，或者一份战略文档（可以用 CE strategy 生成），它会拿这些知识给想法打分，非常酷。我还见过有人把这份文档扔进 Claude Design，说「做成 PowerPoint」，你就能拿到一份设计精美的 PPT，带一个 XY 矩阵，标出你 OKR 的「最佳击球点」在哪——你几乎不费力，拿去给团队看却非常有说服力。

[12:23] Kieran

Uh next one is a very simple one. It's called CE doc review, but it's very useful. If someone hands you a PRD or some kind of document, run doc review on it and it comes back with very sharp questions. I always like the questions and like, "Oh, that's a good question. I did not think about it." So, either you relate this to your colleague or you ask them to answer. You can then compound that knowledge after answering with CE compound so that the next time um this answer is already baked in and it wouldn't ask you. It would already know the answer because it's already embedded in the system. You can share this with people. You can say, "Oh, you can actually run this yourself as well."

下一个很简单，叫 CE doc review，但非常有用。如果有人递给你一份 PRD 或者别的什么文档，对它跑一下 doc review，它会回你一串很尖锐的问题。我总是很喜欢这些问题，会想「哦，好问题，我没想到」。然后你要么把它转给同事，要么让他们来回答。回答完之后，你可以用 CE compound 把这份知识复利进去，这样下一次这个答案已经内置了，它就不会再问你——它已经知道答案，因为答案已经嵌进系统里了。你可以把这个分享给别人，说「其实你自己也能跑」。

[13:07] Kieran

This runs anywhere so you can do it in co-work as well. It doesn't need to be in Claude code. Um it's a very simple thing that we spend a lot of effort in to make very good and it's part of our flow. This my most used one. Um it's when the idea is too big to describe. So, this was the example of Cora version one to version two. I say, "C brainstorm." This is a brain on command. Uh I know I need to get into into the zone. I block off time. I'm not going to multitask or anything like that. Um and I run this. So, it pulls in compound knowledge. It looks at the difference between Cora one and two, and uh looks at the personas I have set up.

它到哪儿都能跑，所以在 Cowork 里也能用，不一定非得在 Claude Code 里。这是一个很简单的东西，但我们花了很多精力把它做得很好，它是我们流程的一部分。这个是我用得最多的：当一个想法大到没法描述清楚的时候。就是刚才 Cora 第一版到第二版那个例子。我说「CE brainstorm」。这是一个「脑子开着」的命令。我知道我得进入状态，所以我会把时间空出来，不多任务、不干别的，然后跑它。它会拉进复利知识，看 Cora 一代和二代的差异，再看看我设好的用户画像。

[13:51] Kieran

So, it will see, "Hey, like certain people need certain things." And it will ask me questions. And it doesn't ask me a lot of questions. It's dialed in to ask you just the right amount of questions it needs to do the work. It's very easy to get 30 questions and feel, "Wow, I did so much." But in the end, the goal is not to answer questions. In the end, it's to get the absolute best work out of it. And I think other libraries might over question. Uh I think there is a balance uh to be found there. So, outcomes a plan, a brainstorm document stored and compounded. And then my favorite is just {slash} LFG, which is basically the loop, the the automation loop. And if you like vibe coding, {slash} LFG something is great, as well.

它会发现「嘿，某些人需要某些东西」，然后向我提问。而且它问得不多，被调得刚好只问完成工作所需的那些问题。很容易被问 30 个问题然后觉得「哇，我做了好多」，但说到底，目标不是回答问题，目标是让它产出最好的工作成果。我觉得有些别的库可能问得太多了，这里面有个平衡要找。结果就是一份计划，一份头脑风暴文档，存下来并复利进去。然后我最喜欢的就是 /LFG，它基本就是那个循环——自动化循环。如果你喜欢 vibe coding，/LFG 加个什么也很棒。

[14:42] Kieran

It will run for hours. It will do planning work, review, testing, opens a PR. It will dog food. It will try fix fix things. It will then do a before and after video screenshot in the pull request. Makes it super easy for you to then see what happened. Last, if it comes back. So, this is overnight. You can do parallel. There's polish. This is the brain on again. See polish, you give it the pull request. And what it will do is it will show you so I like to run it in cursor. And on the left side, I like to run this, and it will tell me, "Hey, this was introduced with this LFG flow." And on the right it will show the product. This is important. Sometimes I don't even know what was built because I also have video recordings that I dump into LFG that it will then process and analyze and see what went wrong. So, sometimes I don't even know what it was solving for.

它会跑好几个小时。它会做计划、审查、测试，然后开一个 PR。它会自己 dogfood，会试着修东西，然后在 pull request 里放一段前后对比的视频截图，让你一眼就能看到发生了什么。最后，等它回来——这通常是通宵跑的，可以并行——就到了打磨环节。这又是「脑子开着」的部分。CE polish，你把 pull request 给它。它会给你展示——我喜欢在 Cursor 里跑——左边跑它，它会告诉我「嘿，这是这轮 LFG 流程引入的」，右边展示产品。这很重要。有时候我甚至不知道做了什么，因为我还会把视频录屏扔进 LFG，它会去处理、分析，看出了什么问题。所以有时候我都不知道它在解决什么。

[15:41] Kieran

So, it's a good primer to know, "Okay, this is what we are where we are. This is what it's solving. This is how I solved it, and you tell me. What do you think?" And this is not QA. This is raising the bar. Like, it should work. If it doesn't work here, your LFG flow failed. Um but you can see here, like this works. Only in this example, there is a mark of uh a logo mark twice, which is not technically wrong, but I don't want two marks on one page. So, in this case, I can say, "Hey, there are marks two marks here. Can we just make sure we only ever have one?" And run C compound, so it will extract that knowledge, make sure next time when I do design work, it's tagged correctly.

所以这是一个很好的引子，让我知道「好，我们现在在这儿，这是它要解决的问题，这是我的解法，你告诉我，你怎么看」。这不是 QA，这是提高标准。它本来就该能跑，如果到这一步还跑不起来，说明你的 LFG 流程失败了。你能看到这里是能跑的。只不过在这个例子里，有一个 logo 标记出现了两次，技术上不算错，但我不想一个页面上有两个标记。这种情况下我可以说「嘿，这里有两个标记，能不能确保永远只有一个」，然后跑 CE compound，它就会把这条知识抽取出来，确保下次我做设计工作时它被正确标记。

[16:22] Kieran

It will find that file and uh know not to do that. So, that's closing the loop. You merge it, and you learn something. So, why does compound engineering resonate with people? I think it's not a very new concept. It's just something how we do software engineering. It's just now instead of working with teams, we use with AI we use AI, and we leverage that and AI is very good at specific things, especially with large amounts of knowledge and doing the right thing, especially with latest models. So, uh if you want to do this yourself, if you don't want to use my plugin, uh make sure to extract. Never repeat. If you see yourself repeating yourself, make sure to extract that somehow, make sure it doesn't happen again.

它会找到那个文件，然后就知道不该那么做了。这就是把循环闭合起来：你合并了 PR，同时也学到了东西。那为什么 compound engineering 会让这么多人产生共鸣？我觉得它其实不是什么新概念，本来就是我们做软件工程的方式。只不过现在不再是跟团队协作，而是跟 AI 协作，我们把它用起来、放大它的杠杆——AI 在特定的事情上非常擅长，尤其是处理大量知识、做出正确的事，最新的模型更是如此。所以，如果你想自己做这套东西、不想用我的插件，那一定要记住：把东西提炼出来，永远不要重复。一旦发现自己在重复，就想办法把它提炼出来，确保它不会再发生第二次。

[17:11] Kieran

Make sure that there is a middle that can run without you, that does the planning, working, reviewing, and it should be boring. It should just work. You should not be needed. If you're still needed in the loop, spend time on the middle, do it manually, feel where it's off and like iterate until you can actually let it go. And if if you are at a point where you just run something and runs for 3 hours and it's always good, you know you're there.

要确保有一个「中间层」，它不需要你也能跑起来，负责做计划、干活、审查，而且它应该是无聊的——就是默默正常工作，不需要你。如果你还得待在循环里，那就把时间花在这个中间层上：先手动做，去感受哪里不对劲，不断迭代，直到你真的可以放手。等到你到了这样一个阶段——随便跑个任务，它跑三个小时，结果总是没问题——那你就知道自己做到了。

[17:36]

[sighs]

（叹气）

[17:36] Kieran

It's important to document the thinking, not the code. This is also very anti developery. It's like, "Yeah, but documentation should mean the code and like the code is the artifact itself." But I am of the opinion to generalize, you need reasoning behind why you did something. And all these traces, even though they're bad, could lead to things like, "Hey, something happened. Write a postmortem. What decision was made by whom or what agent that led to this? Can we then turn that into a learning so we change that behavior for the next time?" And I've seen it work very well, especially with postmortems.

重要的是把思考过程记录下来，而不是记录代码。这一点也很「反开发者直觉」，大家会说：「可文档不就应该是代码本身吗，代码才是产物啊。」但我的看法是，要想做到泛化，你得有「为什么这么做」的推理过程。这些痕迹哪怕不完美，也能带来这样的事：「嘿，出问题了，写一份 postmortem。是谁、或者哪个 agent 做了什么决定导致了这个结果？我们能不能把它变成一条经验，让下次的行为有所改变？」我见过它运转得非常好，尤其是在 postmortem 这件事上。

[18:17] Kieran

And again, every interaction spend 50% of your time to make it better the next time. So make sure to build the system that will remember instead of was this good, make the system better and make the system know. And I know it's hard, like it's just hard to do for myself. And we all know we need to do it, but it's kind of awkward and it's like, "Eh, it's it works. It's great. Let's just move on." But it's very important and you can see the system really go if you do that a lot. So the bet is implementation is only getting cheaper and judgment is not. And the future models and systems need to be set up so they have access to this judgment that we have, our taste, to have more leverage. So that is the bottleneck. And remember brain at the ends, really activate your brain, make sure you really understand what you're doing in the start. Don't offload the thinking to the AI. Make sure you truly feel understand what you're doing, the problem.

再强调一遍：每一次交互，都拿出 50% 的时间让下一次变得更好。所以要去搭建那个「会记住」的系统——不是问「这次做得好吗」，而是把系统本身做得更好，让系统「知道」。我知道这很难，对我自己来说也很难。我们都清楚该这么做，但总觉得有点别扭，心里想：「呃，反正能用，挺好的，赶紧往下走吧。」但这件事非常重要，你坚持多做，就能看到系统真的跑起来了。所以我的赌注是：实现只会越来越便宜，而判断力不会。未来的模型和系统需要被设计成能接触到我们的这份判断力、我们的品味，才能获得更大的杠杆。这才是瓶颈所在。还有，记住「两头用脑」——真的要把脑子调动起来，确保一开始你就真正理解自己在做什么。别把思考外包给 AI，确保你真切地理解自己在做的事、理解那个问题。

[19:24] Kieran

Uh let the AI go and at the end raise the bar. Make sure you don't fix things. It should be very good at the end, but make sure to raise the bar because we're not shipping shitty code. And your standard should be the next feature should be easier because you shipped this one. If the next feature is harder because you added complexity, which is normally how engineer works, we're flipping that. The next feature should be easier to build because you shipped this one. I'm Kieran. Uh check out the plugin. It's open source. Please um contribute. PRs welcome. I love PRs from everyone. Go build your orchestration system. Go build your personal uh knowledge base that compounds. And thank you. I will be hanging around if you have questions and enjoy the rest of your day.

然后让 AI 去干，到最后再抬高标准。别自己去修修补补——最终结果本来就该非常好，但一定要抬高标准，因为我们不交付垃圾代码。你的标准应该是：因为交付了这个功能，下一个功能会更容易做。如果因为你增加了复杂度而让下一个功能变得更难——这通常就是工程的常态——那我们要把它反过来：因为你交付了这个功能，下一个功能应该更容易构建。我是 Kieran。去看看这个插件吧，它是开源的，欢迎贡献，欢迎提 PR，我喜欢每个人发来的 PR。去搭建你自己的编排系统，去搭建你自己的、能够复利的个人知识库。谢谢大家，我会在附近待一会儿，有问题可以来找我，祝大家今天过得愉快。

[20:16]

[applause]

（掌声）