二、Every公司的实践案例
2.1 令人震撼的数字
最近，Dan Shipper（Every公司创始人）在纽约AI工程师大会上分享的案例，为“一人公司”的可能性提供了极具说服力的注脚。首先，他展示了一系列令人印象深刻的数字：
- 团队规模：仅15人
- 产品数量：4款软件产品
- 用户规模：超过7,000付费用户，10万+免费用户
- 融资情况：仅约100万美元
- 增长速度：过去6个月每月实现两位数增长
“看到这么多人我有点意外，”Dan坦言，“因为推特上有人说大家都搬去旧金山了。”但他更想强调的是，纽约也有一群人在用AI做着不可思议的事情。
2.2 技术特点：99%代码由AI编写
然而，比上述数字更关键的是其背后的技术实践：
“我们99%的代码由AI代理编写，无人手写代码，完全由云端代码、Codex、Cursor等编码代理完成。”
更令人难以置信的是：每个应用均由一名开发者独立完成。
Dan现场展示了几款产品：
- Cora - AI邮箱管理助手，主要由一名工程师完成。
- Monologue - 功能复杂的语音转文字应用，同样由一个人服务数千用户。
- Spiral - 另一款复杂应用，同样由一名工程师完成。
他感慨道：“这在几年前不可能做到，一年前还难以实现，而如今的重大转变是，我们正逐渐跟上的变化。”
三、核心发现：90%到100%的巨大差异
Dan分享的第一个重大洞察极具启发性：
“90%工程师用AI的组织与100%使用的相比，效率相差十倍。工程师使用AI的比例从90%到100%，完全不一样。”
这不是简单的10%差异，而是质的飞跃。
为什么？
“关键是，哪怕只有10%的公司采用更传统的工程方式，你就不得不完全回归那种模式。因此，它阻碍了你去做一些原本可能做的事。”
这就像一个团队，如果所有人都用即时通讯工具，沟通效率会很高；但只要有一个人坚持只用邮件，整个团队就不得不降速适应他。
AI工程也是如此。当100%的人都用AI代理编程时，你可以采用全新的工作方式；但只要有人还在传统代码编辑器里一行行敲代码，你就无法真正释放AI的潜力。
Dan补充道：“这彻底改变了我们作为一家小公司的能力。我们更像一个小实验室，让我兴奋的是能与你们分享这些可能性。”
四、AI原生工程的新能力
4.1 并行处理能力：同时开四个窗口不是梗
Dan提到了一个有趣的网络梗：“推特上有种氛围程序员的梗——哦，他们开了四个窗口，但其实他们没在干活。”
但在AI时代，这不再是梗，而是现实：“实际上，你可以那样做。我知道工程师确实在高效工作，同时使用四个智能体窗口。”
这意味着什么？一个开发者可以：
- 窗口1：让AI代理A处理前端功能
- 窗口2：让AI代理B修复后端bug
- 窗口3：让AI代理C编写测试
- 窗口4：让AI代理D优化数据库查询
所有任务并行进行，开发者只需在各个窗口间切换，审查和指导AI的工作。Dan说：“这很疯狂，却极大提升了单个开发者构建并运行生产级应用的能力。”
4.2 低成本试错：代码便宜了，实验就多了
第二个关键能力是快速试错：“由于代码成本低廉，你可以快速试错，从而进行更多实验。尝试的启动成本低得多，因为只需说句‘去做这个，去查一下这个’。”
在传统开发中，大型重构往往让人望而却步：需要评估风险、预留时间、担心影响其他功能，而且一旦开始就很难回头。
但在AI辅助下：
“比如大型重构，我本想去做，结果你转头去干别的了，这真的很容易。”
启动成本的降低，意味着你可以尝试更多可能性，而不是困在“这样做值不值得”的犹豫中。
4.3 演示文化：Show, Don't Tell
Dan特别强调了一个文化转变：“组织内部正逐渐转向一种更注重演示的文化。”
过去的流程：
- 写备忘录
- 做演示文稿
- 说服一群人
- 获得批准
- 才能开始做
现在的流程：
- 直接做出来
- 展示给大家看
“因为能快速协同编码，几小时内就能展示出你所专注的东西。想做就去做，能向所有人展示。”
Dan认为这很棒：“这种演示文化让你能做一些更特别的事，前提是你要敢于尝试。” 这不是简单的效率提升，而是一套全新的工作方式。
五、复利工程（Compound Engineering）
Dan提出了一个核心概念：复利工程。
5.1 核心理念：让下一个功能更容易
什么是复利工程？
“在传统工程中，每个功能让下一个功能更难实现。在复利工程中，你的目标是确保每个功能都让下一个功能更易构建。”
这是一个根本性的思维转变：
- 传统工程：代码越来越复杂，技术债务累积，新功能开发越来越慢，维护成本指数级增长。
- 复利工程：每个功能都沉淀为知识，知识库越来越丰富，新功能开发越来越快，能力呈指数级增长。
Dan进一步阐释：“如果我们在技术栈上提升一层，从Python、JavaScript和脚本语言向上迈进，进入英语和自然语言编程。”
5.2 四步循环：Plan → Dispatch → Evaluate → Canonicalize
Dan详细解释了复利工程的四步循环：
第一步：规划（Plan）
“和代理合作时，详细的计划有多重要，大家应该都做到了。”
这一步需要：明确任务目标、拆解具体步骤、定义验收标准。
第二步：委派（Dispatch）
“直接让代理去执行，让代理去执行，大家也都这么做。”
这一步是：将任务分配给AI代理、提供必要的上下文、设定执行参数。
第三步：评估（Evaluate）
“评估代理工作质量的方法有很多，比如测试、尝试、让代理自行解决、代码审查，还有代理代码审查等各种方式。”
这一步包括：运行测试、人工审查、让另一个AI代理审查、实际使用验证。
第四步：规范化（Canonicalize）⭐
这是最关键的一步：
“我认为最有趣的是将代码规范化，这一步堪称关键。这一步能让你积累的所有经验产生复利效应。”
具体做法：
“从规划、委派、评估阶段，再转为提示，写入你的云端md文件，或你的子智能体、斜杠指令，并逐步构建这个知识库。”
这就是复利的来源：
“将所有工程师积累的隐性知识建成明确的库，在发现漏洞、制定修复方案、分配任务时，工程师们积累的经验都被转化为明确的、可推广至整个组织的提示集合。”
5.3 知识积累：从隐性到显性
传统软件开发中，很多知识是隐性的：老员工知道哪里容易出bug，有经验的开发者知道某个模块的坑，团队积累了很多“最佳实践”但没有文档化。
在复利工程中：所有这些隐性知识都被显性化为AI提示：
- 遇到某类问题的解决方案 → 写成提示
- 代码审查中发现的模式 → 写成提示
- 调试中总结的经验 → 写成提示
这些提示存储在：
.cursorrules 文件claude.md 文件- 项目文档
- 自定义的AI代理指令
结果是：每个新任务都能站在之前所有经验的肩膀上。
六、连锁效应与意外收益
Dan说：“当你做得出色时，会产生许多有趣的连锁效应，一些我认为尚未被充分理解的影响。”
6.1 隐性代码共享：跨技术栈的知识复用
传统代码共享的困境：“以前要共享代码，你得先抽象出来，把你的成果放入库中，然后让别人下载。很难实现，或需要额外说明。”
AI时代的新方式：
“用代理，只需指向你的云端代码实例，从旁边开发者那的代码仓库中学习他们所采用的方法，构建所需功能并自行实现，用自己的技术栈自行重新实现，用自己的框架，以自己的方式。”
举个例子：
- 场景：产品A（用React）需要实现OAuth登录，产品B（用Vue）已经实现过。
- 传统方式：抽象通用库或写详细文档，再由产品A的开发者手动实现。
- AI方式：告诉AI“参考产品B的OAuth实现”，AI读取并理解产品B的代码逻辑，然后用React重新实现。
Dan总结：“这真的很酷。开发者越多，参与的项目越多样，团队内共享越多，无需额外成本，因为AI可以直接读取并使用所有代码。” 这正是人工智能赋能协作的典型体现。
6.2 新员工即战力：第一天就能产出
“新员工入职首日就能高效工作，因为你已经掌握了所有要点——怎么搭建环境，好的提交是什么样的，以及诸如此类的内容。”
具体实现：
“第一天就完成了所有配置，在他们的claude.md或.cursorrules文件中，代理会自动配置本地环境，知道如何写好PR。”
想象一下：新员工克隆代码库，打开编辑器，AI代理读取项目配置并自动完成环境搭建与规范提示，新员工可能几小时内就能开始产出。从入职到产出，时间被极大压缩。
6.3 灵活的专家协作：像DJ一样随时接入
Dan用了一个形象的比喻：“如果你想雇佣像那样的专家级自由职业者，只要特别擅长这一件事，你就能用上他来一天，专门做那件事。我稍微觉得有点像DJ那样，随便进录音棚录几小节歌，可以随时加入，这非常方便。”
为什么以前做不到？“通常合作太难，因为启动成本太高。”专家需要熟悉代码库、了解团队规范、配置环境、理解业务逻辑。这些启动成本让短期协作变得不现实。
但在AI辅助下：专家克隆代码库，AI快速解释项目结构和配置环境，专家能立即专注于其擅长的部分，完成后由AI确保代码符合规范再提交PR。“但现在你可以做得好得多。”
6.4 跨产品贡献：打破产品边界
这是Dan特别喜欢的一点：“每个提交中都有其他产品的开发者。我们内部运行着四款产品，每个人都使用所有产品。”
实际场景：
“若遇到小问题或瑕疵，比如产品有轻微缺陷，他们想要的生活小事，往往就直接提交给应用的另一位管理员。” “他们很容易下载仓库并弄清楚，Claude或Codex能找出修复漏洞的方法，解决这个小问题，这真的很酷。”
举例：开发者A负责产品1，在使用产品2时发现一个小bug。他可以直接克隆产品2的代码库，告诉AI“修复这个bug”，AI分析并提出修复方案，A审查后即可提交PR给产品2的负责人。
这在传统开发中几乎不可能发生，因为开发者A不熟悉产品2的代码库和技术栈，需要花费大量时间理解。但AI让这一切变得简单。Dan甚至推测：“我猜你也能让客户在一定程度上可以这样做，比如遇到bug时，可让你的小助手修复它，提交为拉取请求。这是个奇怪的开源方式，不过确实很酷。”
6.5 技术栈自由：让开发者用最喜欢的工具
“我们尚未需要统一标准到某个特定的技术栈或语言。我们让每个开发不同产品的人选择他们最喜欢的方向。”
Every公司的四款产品可能分别使用React、Vue、Svelte、Next.js等不同框架，后端语言也可能各不相同。
这在传统公司是不可想象的，因为会导致团队成员难以互相支持、代码难以复用、维护成本飙升。
但Dan说：“因为人工智能让这一切变得更容易，在它们之间转换。这使得转换更加容易，轻松切入任何语言、框架与环境，高效产出。” 结果就是：“让我们更轻松地让人做喜欢的事，让AI来处理中间的翻译。”
6.6 管理者写代码：碎片化注意力也能产出
这是Dan最喜欢也是最具争议的一点：“技术出身的经理竟能直接提交代码。CEO不该写代码，我也不该，因为这本不是我的职责。”
但Dan的现实是：“我们有四款产品，15名员工，发展迅速，我做了大量还有大量其他事务，但我已在最近几个月编写并提交了大量可投入生产的代码。”
为什么可能？
“人工智能让工程师能以碎片化注意力工作。以前你可能需要连续三四个小时的专注时间。”
新的工作方式：
“但使用云代码，你可以先离开会议，说嘿，我想查这个漏洞，然后去忙别的，再回来时问题已解决，像一个计划或根本原因的修复，然后你就能提交PR。”
Dan坦言：“这并不简单，不是魔法，但确实可行。我认为这正是一种全新的思维方式，重新思考管理者如何以全新方式与所创产品互动。”
这意味着什么？ 技术管理者不会与代码脱节，可以在会议间隙处理技术问题，从而保持对产品的深度理解，并更好地指导团队。
七、总结：AI原生时代的一人公司
听完Dan的分享，其核心洞察对独立开发者与一人公司实践者极具启发性。
7.1 Dan的核心发现总结
Dan在演讲最后总结了几个关键点：
- “我认为当实现100%人工智能应用时，工作效率会有十倍之差。”
- “从我们观察到的情况看，单个工程师就能构建并维护复杂的生产级产品。”
- “我们称之为复合工程，在于让每个功能更易构建，从而产生这些看似不明显的间接效应，却让整个组织更易协作。”
7.2 对实践者的核心启示
作为一人公司或独立开发者，我们可以从中提炼出三个关键启示：
启示一：个体能力被重新定义
Every用15人做了过去需要50-100人的事，那么一个人能做什么？ 答案是：一个人可以维护一款复杂的SaaS产品，可以同时运营多个项目，可以在不同技术栈间自由切换。AI不是替代我们，而是放大我们。 关键是要100%拥抱AI，而不是90%。
启示二：复利思维是核心竞争力
Dan提出的“复利工程”对个体尤其重要。我们最宝贵的资源是时间和经验。传统方式下，经验只存在于大脑中。但通过将经验转化为AI提示、构建个人知识库、让每个项目都为下一个项目铺路，我们可以让自己的能力产生复利效应。这是一人公司对抗资源不对称的关键武器。
启示三：工作方式的根本转变
最重要的不是工具，而是思维方式的升级：
- 从“写代码”到“管理AI代理”：并行处理多个任务，用碎片化时间产出，快速试错与迭代。
- 从“做PPT”到“做原型”：拥抱“演示文化”，少说多做，用产品说话。
- 从“积累技术债”到“积累知识资产”：每个功能都沉淀为提示，隐性知识显性化，越做越快。
7.3 实践思考
这个演讲促使我们重新思考自己的工作方式：
- 不要害怕100%使用AI：这会带来质的飞跃，但需要你完全改变工作流。
- 建立自己的“复利循环”：每完成一个项目，都有意识地将经验沉淀为提示和文档，构建不断增值的个人知识库。
- 拥抱“演示文化”：减少无效讨论和包装，快速做出可交互的原型来验证想法。
- 重新思考“规模”：一人公司的天花板已被AI大幅推高，关键不在于团队大小，而在于方法论。
7.4 未来已来
Dan的演讲清晰地预示着一个未来：AI原生的一人公司时代正在到来。
在这个时代，个体可以拥有过去只有大公司才有的能力，创意与执行之间的距离被大幅缩短，小而美的产品会越来越多，专注和深度将比单纯规模更重要。
Every公司的实践证明：未来已来，只是分布不均。 而我们要做的，就是成为那些率先拥抱并实践这套新范式的开发者。
这不是关于是否会被AI替代的焦虑，而是关于如何利用AI将个人创造力与执行力放大十倍甚至百倍的机遇。作为探索者，我们的旅程才刚刚开始。
发表于 6 天前
|
查看: 24|
回复: 0
