如何打造一家 AI 原生公司

编者按 / 读前导读

本文编译自 YC 合伙人 Diana 的一期分享。如果你还在把 AI 当成「给现有流程加个 copilot、多发几个功能」的提效工具，这篇文章可能会让你有点不舒服——因为它要说的，恰恰是「提效」这个框架本身就错了。

Diana 抛出了一个相当激进的判断：AI 不是来帮你把活干得更快的，它是来重新定义你这家公司该长什么样的——哪些岗位还存在、组织怎么搭、产品的边界在哪里，全都要变。

全文约 5 分钟读完，建议你读的时候拿自己的公司对号入座：你现在跑的，是「开环」还是「闭环」？

嗨，我是 Diana，YC 的合伙人。

过去几个月里，有一件事在我看来越来越清楚：AI 改变的不只是软件被构建的速度、或者哪些工作流能被自动化。它会从根本上改变一家创业公司的运作方式——从会存在哪些岗位，到能做出什么样的产品。这一期，我想聊聊创始人该如何思考「打造一家 AI 原生公司」，团队里该有哪些角色，以及他们现在就能落地、用来大幅提速的具体内部做法。

别只盯着「提效」，要看到「全新能力」

现在大多数人谈 AI，谈的都是「生产力」。他们会大段大段地讲 AI 怎么让工程师更高效，或者说「我们得给现有工作流加个 copilot，多发几个功能」。这种框架错过了我们正在经历的真正转变——这件事的核心不在于效率提升，而在于全新的能力。一个合适的人，配上 AI 工具，现在能做出过去需要一整个团队、甚至根本不可能做出来的功能。

从「全新能力」这个角度看 AI，会对创始人怎么运营公司产生一连串影响。

往高了说，思考 AI 的正确方式是：它不该只是公司「用的一个工具」，而应该是公司「赖以运行的操作系统」。每一条工作流、每一个决策、每一道流程，都应该流经一个持续学习、持续改进的智能层。

把每个流程都做成「闭环」

具体来说，公司里每一个重要流程，都应该被一个智能的闭环（closed loop）捕获。闭环会采集信息、把信息反馈进智能系统，并随时间不断改进这个流程。

如果你学过控制系统，应该熟悉开环（open loop）和闭环的区别。开环是没有反馈回路的受控系统。在旧世界里，公司基本上是按开环运转的：你做个决定、执行下去，却不一定会系统性地度量结果、再回头调整流程。开环天然是「有损」的。

而闭环是自我调节的。它持续监测自己的输出，不断调整流程，以便更好地达成既定目标。闭环在保证正确性和稳定性上极其强大。借助会自我改进的 agent，你的公司就应该按闭环来运转。

让整家公司「可被查询」

要搭建这些闭环，你得让整家公司都可被查询（queryable）——换句话说，整个组织对 AI 来说都是「可读的」。每一个重要动作都应产出一份制品（artifact），让位于公司中心的那个智能体能从中学习、用来自我改进。

这意味着：用 AI 记录会议、尽量减少私信和邮件、在所有沟通渠道里都嵌入 agent；也意味着为公司里的一切搭建自定义看板——营收、销售、工程、招聘、运营，通通在内。

举个具体例子，拿工程管理和迭代（sprint）规划来说。假设你有一个 agent，它能访问你的 Linear 工单、所有 Slack 工程频道、来自邮件或 Pylon、GitHub 的全部客户反馈、放在 Notion 或 Google 文档里的高层规划，销售通话录音，以及每日站会录音——那么这个 agent 就能分析：上个 sprint 到底交付了什么、它们究竟在多大程度上真正满足了客户需求。

在此基础上还能更进一步。当你对「交付了什么、什么奏效了、什么没奏效」拥有完整的可见度，agent 就能开始向前看：它能为工程师提出更可预测、更准确、更不容易脱轨的 sprint 计划。那种焦头烂额的经理层层汇报、信息高度失真的日子，一去不复返了。

我自己带过工程团队，如今又在多家 YC 公司里看到这一幕——这是个颠覆性的变化。过去需要持续协调才能搞定的事，现在默认就是可读、可查询的。我见过这样做的团队把工程 sprint 的时间砍掉一半，还在同样的时间里多干出近 10 倍的活。

这里的总原则是：要榨出模型的全部能力，你就得像给一名员工提供背景信息那样，给模型提供同样充分的上下文。做到这一点，你的公司就不再是那种信息碎片化、靠人工解读的开环系统，而会变成一个闭环系统：状态、决策、结果被持续捕获，再反馈进这一智能层。结果就是，这套系统始终对「真实正在发生什么」保有一份最新的全局视图。

软件工厂：TDD 的下一次进化

对于速度最快的那批公司，还有一种全新的产品构建范式正在浮现——AI 软件工厂（software factory）。

如果你熟悉测试驱动开发（TDD），这就是它的下一次进化。在软件工厂里，人类写下一份规格（spec）和一组定义「成功」的测试，然后 AI agent 生成实现代码、不断迭代，直到测试通过。人类定义「要造什么」并评判产出，实际写代码则是 agent 的活。

有些公司已经把这一点推到极致：他们的代码库里没有一行手写代码，只有规格和测试框架。StrongDM 的 AI 团队就是个好例子。他们的最终目标是一套基本上不再需要人来写代码或评审代码的系统；于是他们打造了自己的软件工厂——用规格和基于场景的校验，驱动 agent 写测试、迭代代码，直到达到某个概率性的「满意阈值」、并且确实跑通为止。

这正是 Steve Yegge 所说的「千倍工程师」的实现方式：用一整套 agent 系统把一名工程师包围起来，让他能造出过去根本造不出来的东西。千倍、甚至万倍工程师的时代，已经到来。

管理层级正在失效，只剩三种角色

按这种方式建公司——到处是 AI 闭环、组织可查询、还有软件工厂——会带来一个推论：经典的管理层级不再说得通了。

旧世界里，你需要中层经理和协调者，把信息低效地在组织里上下传递。新世界里，这个活由智能层来干。如果你的公司是可查询的、制品丰富的、对 AI 可读的，你就几乎不该再有任何「人肉中间件」。

这很关键，因为公司的速度只取决于它的信息流转速度。你每去掉一层人工传递，就是一次直接的提速。

一个很好的例子是 Block 的 Jack Dorsey 的做法。深入用过这些工具之后，他得出了和许多人相同的结论：这件事远不只是渐进式的效率提升。他的看法是，如果你保留原来的组织架构和管理结构，那你就彻底错过了这场转变。公司本身必须被重建为一个智能层，人站在边缘去引导它，而不是充当信息流转的中转站。

放眼未来，Jack 认为每家公司都会有三种员工原型。

第一种是一线贡献者（IC），基本上就是「建造者兼操盘手」。在 AI 原生公司里，这是亲手做东西、亲手把东西跑起来的人。这不限于工程师——人人都在建造、在运营，支持也好、销售也好。每个人开会时带的是能跑的原型，而不是 pitch deck。

第二种是 DRI（直接责任人），聚焦于战略和客户成果。这不是传统意义上的经理，而是对结果负有明确责任的那个人。一人，一个结果，无处可躲。

第三种是「AI 创始人」型。这种人依然在亲手建造、依然在带教、以身作则地领导。如果你是创始人，这个人必须就是你，站在最前线，向团队展示「能力跃升」到底长什么样——而不是把你的 AI 战略外包给别人。

有了这种结构，公司就能用小得多的团队拿到超额的成果。关键转变是最大化 token 用量，而不是最大化人头（token maxing，而非 headcount）。最优秀的公司，会是那些把 token 拉满的公司。

这样理解这笔账：一个配上 AI 工具的人，可以顶上 AI 时代之前一整个大型工程团队的产出。这意味着工程、设计、HR、行政团队都能极度精简。所以，你应该乐意承担一笔高到让你不太舒服的 API 账单——因为它替代的，是一份本会昂贵得多、也臃肿得多的人头开销。

信念，是无法外包的

但这一切，别光听我说。你对这些工具威力的信念，是无法外包的。你得自己去建立它：真正坐下来，和编程 agent 一起干活，一直用到你开始打破自己原有的成见、重新认识「现在到底能造出什么」为止。

如果你是早期阶段的创始人，你在抢跑这件事上有巨大优势。你没有遗留系统、没有积重难返的旧架构、也没有成千上万人要重新培训。你足够小，可以从第一天起就把公司建对。

对现有公司而言情况恰恰相反。它们必须一边维护并增长一个活着的产品，一边拆解多年积累的标准作业流程、以及关于「软件该怎么造」的种种核心假设。有些公司能靠组建小型内部「臭鼬工厂（skunkworks）」团队来做到这一点——这些团队脱离核心业务，从零搭建 AI 原生系统。Mutiny 就是个很好的例子。但对大多数公司来说，对核心流程的每一次改动，都有可能弄坏某个本来运转良好的东西。所以从本质上讲，这些大公司转向 AI 原生会困难得多。

创业公司没有这个束缚——这是一个值得好好利用的重大优势。你可以从一开始就围绕 AI 来设计你的系统、工作流和文化，结果就是：比在位的巨头们快上一千倍。