AI 原生公司：从组织图到智能层

别只把 AI 当成生产力工具

大多数公司谈 AI，最后都会落到“提效”上：工程师交付更快，现有流程接一个 copilot，每周多关掉几个工单。

这个说法很舒服，因为它默认公司原来的形状不用变，只是跑得更快。但它错过了真正的变化。AI 带来的不只是速度，而是能力边界的变化：一个合适的人，配上合适的 AI 工具，现在可以做出过去需要一整个团队才能做的东西，甚至做出一年前根本做不出来的东西。

一旦认真看待这件事，问题就不再是“我们怎么更快一点”，而是“如果 AI 不是外挂工具，而是公司运行的底层系统，这家公司应该长什么样？”

我最认同的一句话是：AI 不应该只是公司使用的工具，而应该成为公司运行的操作系统。工作流、决策、流程，都应该经过一层不断学习、不断改进的智能系统。

这句话听起来像口号。但真正的分水岭，恰恰在于你是否愿意把它当真。

重要流程都应该变成 closed loop

如果你接触过控制系统，就会知道 open loop 和 closed loop 的区别。

Open loop 只执行，不检查结果。Closed loop 会持续观察输出，再根据结果调整自己，让系统不断接近目标。

过去很多公司的运行方式，本质上都是 open loop。有人做一个决策，团队执行下去，最后结果有没有被系统性记录、有没有反过来改变下一次流程，往往说不清楚。信息在一次次交接里丢失，等大家意识到问题时，代价已经很高。

有了能自我改进的 Agent，公司就可以按 closed loop 的方式运行。具体来说，每一个重要流程都应该做到三件事：记录发生了什么，把结果反馈给系统，再让系统基于这些反馈改进下一次流程。

状态、决策和结果被持续捕捉，回到中心那层智能系统里。这样，公司手里始终有一份接近实时的全局视图，而不是靠人临时整理出来、很快就过期的状态汇总。

让公司变得可查询

Closed loop 能成立，有一个前提：中心那层智能真的看得见公司。

这意味着你要让整个组织对 AI 可读、可查询。每一个重要动作，都应该留下某种 artifact，让系统能从中学习。

落到实践里，这些事并不华丽：用 AI note taker 记录会议，减少私聊和邮件里的关键决策，把 Agent 放进工作本来发生的沟通渠道里，再把营收、销售、工程、招聘、运营等关键数据做成 dashboard。

拿 sprint planning 举例。假设一个 Agent 能看到你的 Linear 工单、工程 Slack 频道、邮件和支持工具里的客户反馈、Notion 或 Google Docs 里的高层计划，以及站会和销售电话录音。

它就可以分析上一个 sprint 到底交付了什么，这些交付和真实客户需求匹配得怎么样。进一步，它还能基于这些信息提出下一轮 sprint 计划，而且往往比经理一层层汇总出来的计划更准确。

传统的 status roll-up 很容易丢细节。信息每往上传一层，就会被压缩一次。等传到决策者手里，很多关键上下文已经没了。

Diana 提到，她看到一些团队把这套系统接起来以后，sprint 时间砍半，同时在同样时间里接近做出 10 倍的量。底层原则其实很简单：想让模型发挥完整能力，就要给它足够多的上下文，就像你会认真给一个新员工交代背景一样。

不给上下文，你得到的是一个迷糊的实习生。把全貌给它，过去耗掉大量时间的协调工作，就会自然减少。

Software factory 会改变写代码的方式

最快的团队，连构建产品的方式也在变。

如果你熟悉 TDD，AI software factory 可以理解成它的下一步。人写 spec，写一组定义“什么算成功”的测试；Agent 生成实现，不断迭代，直到测试通过。

人的职责变成两件事：决定要造什么，以及判断结果好不好。真正写代码的部分，交给 Agent。

有些团队已经把这件事推进到一个很极端的程度：代码仓库里几乎没有手写代码，只有 spec 和 test harness。StrongDM 的 AI 团队就是一个例子。他们用 spec 和基于场景的校验驱动 Agent 写代码、测试、重写，直到结果达到一个概率意义上的“足够好”。

这背后，才是 Steve Yegge 说的 “1000x engineer” 的真正机制。不是你招到了一个超人，而是你给一个很强的工程师配上了一整套 Agent 系统，让他能做出过去单靠自己做不出来的东西。

真正会被重写的是组织结构

当 closed loop、可查询的公司、software factory 这些东西放在一起，传统管理层级就开始失去意义。

过去，公司需要中层经理和协调者，把信息在组织里向上传、向下传。某种意义上，他们是在做人工信息路由：把一个地方的上下文搬到另一个地方。

但如果公司本身已经可查询，工作过程留下了足够多 artifact，AI 能读懂这些信息，那么这层“人工路由”就不应该再占据组织的中心位置。信息流动越快，公司速度越快；每少一层人工传递，都是直接提速。

Jack Dorsey 在 Block 的判断也是类似的：如果你只是保留原来的组织架构和管理方式，再往里面加 AI 工具，那就错过了真正的变化。公司本身应该被重建成一层 intelligence layer。人站在边缘负责判断、引导和承担结果，而不是坐在中间转发信息。

未来留下来的角色，大致会收敛成三类。

第一类是 IC，也就是 builder-operator。这个人直接造东西，也直接运行它。在 AI 原生公司里，这不只限于工程师。销售、运营、支持，也应该带着能跑的 prototype 来开会，而不是只带 slide deck。

第二类是 DRI，directly responsible individual。它不是传统经理，而是对一项策略或一个客户结果端到端负责的人。一个人，一个结果，责任清楚。

第三类是 AI founder。创始人仍然亲自上手，仍然通过行动带团队，而不是把 AI strategy 外包给别人。如果你是创始人，你自己就必须站在最前面，让团队看到能力边界到底被推开了多少。

在这种结构里，小团队可以做出过去大团队才能做出的结果。真正重要的指标也会翻转：你要最大化的不是 headcount，而是 token usage。愿意承受一张看起来有点夸张的 API 账单，因为它替代的是更贵、更慢、更臃肿的人力结构。

这就是 Diana 说的 token maxing。

早期公司有真正的结构性优势

这件事不能只靠听别人讲。你没法把信念外包出去。

真正建立信念的办法，是自己坐下来用 coding agents，用到它们开始打破你对“现在到底能做什么”的原有判断。读文章的时候，你可能只是点头；亲手用一周，很多东西会突然变得不再抽象。

如果你还在早期，这里有一个很大的结构性优势：你没有遗留系统，没有根深蒂固的组织架构，没有几千个人要重新培训。你足够小，可以从第一天起就按 AI 原生的方式设计公司。

既有公司正好相反。它们要一边维持现有产品增长，一边拆掉多年形成的 SOP 和关于软件开发的基本假设。少数公司可以通过内部 skunkworks 做到这一点：拉出一支小团队，和核心业务隔离，从零开始搭 AI 原生系统。Mutiny 就是一个例子。

但对大多数大公司来说，每动一次核心流程，都可能破坏一个已经能运转的系统。所以它们转向 AI 原生会更慢，也更痛。

初创公司没有这份包袱。你可以从一开始就围绕 AI 设计系统、工作流和文化。这样建出来的公司，才有机会跑出既有公司在结构上追不上的速度。

本文整理自 Diana Hu 在 YC Startup School 关于构建 AI 原生公司的分享。核心论点来自原分享。

相关阅读

• 智能体需要 Harness，不只是更强的模型 —— 本文假设你造得出来的那层智能，底下的工程是什么样。
• 如何构建一家 AI 原生服务公司 —— 把同一个论点，用到万亿级的服务市场上。