内容概要
Every 的经营者 Dan Shipper 分享了他关于打造 AI 原生（AI-native）公司的见解。在 Every，99% 的代码都是由 AI 智能体（Agents）编写的。他讨论了从传统工程向“复利工程”（Compounding Engineering）的转变，强调了全员采用 AI 如何解锁并行工作流、快速原型设计以及独特的演示文化。Shipper 还探讨了这种转型的二阶效应，例如更轻松的代码共享、更快的入职流程，以及管理者甚至 CEO 能够贡献生产级代码的能力。
目录
-
引言与 AI 剧本的现状
-
在 Every 使用 AI 智能体构建软件
-
并行工作与高风险创意的原型设计
-
向演示文化的转变
-
复利工程循环
-
隐性代码共享与入职
-
跨产品协作与工具
-
管理者提交代码
-
总结与结语
引言与 AI 剧本的现状
我是今天的最后一位演讲者，也是挡在大家和晚餐或美酒之间的最后一道关卡。所以我会尽量让这次分享有趣一点，希望能短一点。
首先，很高兴见到大家。其实看到这么多人我有点惊讶，因为虽然我住在这里，但我上周在葡萄牙旅行时，看到推特上有人说所有人都搬去旧金山了。但很高兴大家还在这里，因为我真他妈爱死纽约了。来吧，嗨起来。
今天我要讲的是构建 AI 原生公司的剧本（Playbook）。遗憾的是，我其实并没有现成的剧本。原因在于，我认为这个剧本目前正在被发明之中。我们在 Every 这家公司正在实践，而在座的各位今天也都在实践。所以我不想摆出一副“我有所有答案”的姿态来告诉大家框架或剧本。
我认为，在我们学习如何利用 AI 进行工程设计和公司建设的起步阶段，分享我们公司内部的亲身经历，并共同探索出这个剧本，是非常有帮助的。所以我能提供的最好内容，其实就是来自未来的简报——关于我已经搞清楚的事情，以及我们在 Every 内部所做工作的笔记。
我注意到的第一件大事是，在一个 90% 的工程师使用 AI 的组织，和一个 100% 的工程师使用 AI 的组织之间，绝对存在 10 倍的差距。这完全是两码事。我认为关键在于，哪怕只有 10% 的人还在使用传统的工程方法，你就会被迫倒退回那个世界。这会阻碍你去做那些“如果所有人都不用一直敲代码”时能做的事情。
我深知这一点，因为这就是我们在 Every（我经营的公司）所做的事情，它彻底改变了我们作为一家小公司所能做到的事。所以我把我们看作是一个展示可能性的实验室，很兴奋能与大家分享。
在 Every 使用 AI 智能体构建软件
给不了解的人介绍一下，我经营着 Every。在 Every 内部，我们有六个业务单元。我们仅用 15 个人就运营着四款软件产品，这挺疯狂的。
这些软件产品并非玩具。Every 在过去 6 个月里，月经常性收入（MRR）每月都在以两位数增长。我们拥有超过 7,000 名付费订阅者和超过 100,000 名免费订阅者。而且我们是以一种非常轻资本的方式做到的，总共只筹集了大约 100 万美元。
对于本次讨论非常重要的一点是，我们 99% 的代码都是由 AI 智能体（Agents）编写的。没有人手写代码，根本没有人写代码。所有工作都是通过 Cloud Code、Codec、Droid 或者你选择的任何编码智能体完成的。
另外，考虑到我们的团队规模，极其重要的一点是：我们的每一个应用程序都是由一名开发者独立构建的，这很疯狂。而且这些应用不是那种小打小闹的 App。
举个例子，这是 Kora，一款 AI 邮件管理应用。它是你邮件的助手。左边这里，它总结了所有进来的邮件，你可以通过这种方式阅读邮件。这是我的收件箱现在的样子。右边是一个邮件助手，你可以问它问题，比如我问“我今天的 AI 工程师演讲是什么时候？”，它直接给了我答案。这主要由一名工程师构建，虽然有一两个承包商在某些方面提供过帮助，但几乎所有东西都是这一个人完成的。
另一个应用叫 Monologue，是一款语音转文字应用，有点像 Super Whisper 或 Whisper Flow。同样，一个人开发，拥有数千名用户。我很喜欢它，做得非常精美，而且并不简单，里面有很多复杂的东西。这个叫 Spiral 的应用也一样，你可以看到它规模很大，同样也是一名工程师完成的。
显然，这在几年前是不可能的，甚至在一年前也是不可能的。我认为发生的巨大变化，也就是我们要迎头赶上的趋势，始于 Cloud Code——这种摆脱了代码编辑器的终端用户界面（Terminal UI）。它真正把我们推向了一个新阶段：我们将任务委派给这些智能体，这让我们能够并行工作，完成比平时多得多的任务。
并行工作与高风险创意的原型设计
我注意到我们能做得更快的原因是，我们可以并行处理多个功能和 Bug。推特上有一种“氛围编码者”（Vibe Coder）的梗，说他们开了四个窗口但实际上没干活。其实你确实可以那样做。但我知道肯定有工程师（因为 Every 里就有这样的人）正在高效地同时使用四个智能体窗口。这很疯狂，这也是为什么单个开发者能够构建并运行一个生产级应用的重要原因。
另一个非常重要的解锁是：因为代码变得廉价，你可以对高风险的想法进行原型设计。这让你能进行比平时更多的实验，进而取得更多进展。因为尝试某件事的启动能耗变得非常低，你只需要说“噢，去把这个做了，去研究一下我想做的这个大型重构”，然后你就可以去忙别的事了。这真的很重要。
向演示文化的转变
还有一点我也非常喜欢，我们在组织内部正逐渐转向一种“演示文化”（Demo Culture）。以前如果你想做什么东西，可能需要写备忘录、做 PPT，或者说服很多人这值得花时间。现在，因为你可以在几个小时内“凭感觉写出代码”（Vibe Code），把你想做的东西展示出来，你可以直接展示给所有人看。我认为拥有一种演示文化能让你做出更古怪的东西，那些只有你亲手感觉过才能体会到的东西。这真的太棒了。
复利工程循环
除了基本的生产力提升，AI 以及我们使用它的方式促使我们要发明一套全新的工程原语和流程。我相信在座的各位肯定已经开始这么做了。如果我们要向技术栈的上层移动，从 Python 和 JavaScript 脚本语言转向英语，那么新的编程方式是什么？我们给这个过程起的名字叫“复利工程”（Compounding Engineering）。
我对复利工程的定义是：在传统工程中，每开发一个功能，下一个功能就会变得更难构建；而在复利工程中，你的目标是确保每一个功能都让下一个功能更容易构建。
我们通过一个循环来实现这一点。循环有四个步骤：
-
计划（Plan）：如果你今天在场并专心听讲了，你就会知道在与智能体协作时，制定非常详细的计划有多重要。我想大家都在做这一步。
-
委派（Delegate）：直接告诉智能体去做。这一步大家也都在做。
-
评估（Assess）：我们有无数种方法来评估智能体的工作是否合格。测试、试运行、让智能体自己检查、代码审查、智能体代码审查等等。
-
固化（Codify）：最后一步，我认为这是最有趣的一步，也是“产生价值”的一步。你需要把你从计划、委派、评估阶段学到的所有东西，通过提示词（Prompts）固化回到你的 Cloud MD 文件、子智能体（Sub-agents）或斜杠命令中。
你开始建立一个库。你收集所有工程师在发现 Bug、修正计划、委派工作时获得的隐性知识，将其转化为显性的提示词集合，并在整个组织内传播。当你把这一点做得很好时，会出现许多有趣的二阶效应。这些效应还没被很好地理解或讨论，但我认为值得在这里提一下，这可能是一个让更多人接受 100% 使用这些工具的有趣切入点。
隐性代码共享与入职
如果你建立了这个流程并完全投入到复利工程中，你会注意到的第一件事是：隐性代码共享变得容易多了。
Every 有多个产品，很多时候需要实现类似的东西，比如 Teams 功能或某种类型的 OAuth，即使使用的技术不同。以前为了共享代码，你得把它抽象成一个库，让别人下载，这很难。或者你得口头讨论。
有了智能体，你只需要把你的 Cloud Code 实例指向坐在你旁边的开发者的代码库，让它学习构建该功能的过程，然后在你自己的技术栈、框架里，用你自己的方式重新实现一遍。这非常酷。在这个组织里开发不同东西的人越多，你可以零成本共享的东西就越多，因为 AI 可以直接去读取所有代码并加以利用。
另一个很酷的点是，新员工在第一天就能产出。因为你把你学到的关于“如何设置环境”、“好的代码提交（Commit）长什么样”等所有知识，都放进了他们的 CloudMD 文件或 Cursor 文件里。智能体可以直接设置好本地环境，并且知道如何写出高质量的 PR。这真的很酷。
这也有助于雇佣专家级自由职业者。如果有人非常擅长某件具体的事，你可以让他们来一天把事情搞定。我把它想象成 DJ，可以在歌曲的某几小节切入进来。这非常有用，以前因为启动成本太高而难以协作，但现在你可以做得更好。
跨产品协作与工具
我注意到的另一件事是，Every 内部的开发者会向其他产品提交代码。我们内部运行着四个产品，每个人都在用。如果有人遇到 Bug 或一些像被纸划伤一样微小但恼人的体验问题，他们经常会直接向该应用的负责人提交一个 PR。
因为这很容易，只要下载代码库，让 Claude 或 Codec 搞清楚怎么修就行了。这真的很酷，因为这种跨应用协作变得容易多了。我想象在未来几年，你甚至可以在某种程度上让客户这么做。如果你遇到一个 Bug，你可以让你的私人智能体修复它并提交 PR。这有点像怪异的开源模式，但这真的很酷，而且在我们公司内部确实经常发生。
还有一点，我们目前还没有被迫标准化特定的技术栈或语言（随着规模扩大可能会变）。相反，我们让构建不同产品的人选择他们最喜欢的工具。原因在于，AI 让不同技术栈之间的翻译变得容易多了，让你能轻松跳进任何语言、框架和环境中并保持高效。所以对我们来说，让人做他们喜欢的事，让 AI 负责中间的翻译工作反而更简单。
管理者提交代码
最后一点，这是我的最爱，但可能是一些开发者的噩梦，某种程度上也是我团队的噩梦——那就是管理者可以提交代码，只要你是懂技术的。甚至 CEO 也可以。
对我来说，我本来没时间提交代码，因为我们有四个产品，15 个人，增长很快，我有无数其他事要做。但我可以，而且在过去几个月里我也确实提交了生产级代码。原因是 AI 允许工程师在“碎片化注意力”下工作。
以前你需要 3 到 4 小时的专注时间才能把事做完。但有了 Cloud Code，你可以刚开完会就说：“嘿，我要你调查一下这个 Bug”，然后去忙别的。回来时，你已经有了一个计划或根本原因分析，然后你可以提交 PR。这不容易，也不是魔法，但确实可行。我认为这彻底改变了管理者与他们创造的产品之间的互动方式。
总结与结语
总结一下，我真的认为当 AI 采用率达到 100% 时，工作方式会有 10 倍的差异。根据我们的观察，单个工程师应该能够构建并维护一个复杂的生产级产品。
这就是我们所说的复利工程。我想我们大家都在指向同一个方向，它确实能让每一个功能都更容易构建，并创造出所有这些非显而易见的二阶效应，让整个组织的协作变得更简单。很重要的一点是，旧金山的很多人还不知道这一点。你们是第一批听到的。这就是我的演讲。
如果你对我们做的事情感兴趣，我经营着 Every。Every 是你保持在 AI 前沿所需的唯一订阅。你可以在 every.to 找到我们。我们有关于 AI 的每日通讯，涵盖创意、应用和培训。在创意方面，我们会在新模型和新产品发布时进行评测。应用方面你们已经见过了，我们提供这些应用的打包服务。然后我们还为大公司提供培训和咨询，帮助他们使用 AI。所有这些都打包在一个订阅里，一份价格，全部拥有。就是这样，非常感谢。
