用AI构建一家能自我进化的公司

哈喽，大家好，我是刘小排。

我今天花了很多时间，反复学习了两个 YC 的创业课程，越看越觉得有意思，越看越激动。

第一个是 Y Combinator 的《How To Build A Company With AI From The Ground Up》，主讲人是 YC 合伙人 Diana Hu。她讲的是怎么从第一天开始搭一家 AI 原生公司。

第二个是 YC Root Access 的《How to Build a Self-Improving Company with AI》，主讲人是 YC General Partner Tom Blomfield。他讲得更进一步：公司不但要 AI 原生，还要能自我改进。（文末有原始视频链接）

硅谷创业者似乎比我们对AI的理解要前沿和激进很多。

YC作为世界最牛的创业黄埔军校，竟然敢在自己课程里说「 1个人 + AI = 1000个谷歌工程师 」。 这就很尴尬了，毕竟，国内的博眼球型自媒体博主还只停留在“1个人=10个人”、都还生怕自己吹牛吹大了的阶段。

我想，这里面有一个很核心的、思维方式上代差：

国内很多创业者还在强调Productivty(效率)，他们琢磨的是「如何用AI提效20%、提效100%」。他们头脑里的隐含假设是「我比AI厉害，AI就是来帮我打杂的，打杂的时候帮我提高效率20%就很不错了，如果能提高100%，那也是因为我领导有方」

而更前沿的创业者更强调Capability(能力），他们琢磨的是如何最大化发挥AI的全部能力。他们头脑里的隐含假设是「AI在很多能力都远比我厉害，我不能因为我的笨拙而影响它的发挥。爱上一匹野马，我要给它草原」

如果你想只带走一句话，我想，应该是这一句：

Not Productivity, rather Capability.

以下是我（在 AI 的帮助下）整理的学习笔记，分享给你，希望对同样正在构建 AI 原生公司的你有所帮助。

这两个教程放在一起看，很有冲击力。它们讲的不是“AI 工具推荐”，而是一整套关于未来公司怎么运转的判断。

我们平时说 AI，往往还是把它当成一个提高效率的工具。工程师能不能写代码快一点？客服能不能少招两个人？销售邮件能不能自动写？这些问题当然有价值，但在 YC 这两场分享里，它们都不是重点。

硅谷创业圈的狂，有时候不是情绪上的狂，而是推理上的狂。他们会把一个假设一路推到底。比如他们现在真敢在 slide 上写：

1 person with AI tools = 1000x Google engineer

翻译一下就是：

1 个人 + AI = 1000 个谷歌工程师。

这不是一个财务模型，也不是一个严格等式。它真正表达的是一种判断：AI 带来的不是“员工效率提升 20%”，而是公司能力边界的重画。

如果这个判断哪怕只有一部分成立，那我们就不能再只问“怎么给旧公司加 AI”。我们应该换一个更根本的问题：

如果今天从零开始建一家公司，它应该一开始就按 AI 原生的方式来设计吗？

下面，我会把这两个 YC 教程融合起来，整理成一套中文语境下更容易使用的框架。它尤其写给那些正在构建 AI 原生创业公司的人：你也许不需要马上照搬 YC 的所有做法，但你需要理解他们正在押注的公司形态。

这个形态可以用一句话概括：

AI 不是旧公司的一台新发动机。AI 是新公司的操作系统。

如果这句话成立，那么问题就不是“怎么让公司效率提高 20%”，而是公司这套机器本身要不要重新设计。

YC 给出的答案，有点激进：

公司不再应该是一层层人类管理者传递信息的金字塔，而应该是一组递归、自我改进的 AI 闭环。信息被捕获，进入公司大脑，被 Agent 理解、调用、修复、更新。

一个好的 AI 原生公司，甚至应该在创始人睡觉时继续变好。

这就叫自我进化公司。

PART 01

一、旧公司像罗马军团

Tom Blomfield 一开场用了一个很有意思的比喻：公司像罗马军团。

罗马帝国要从罗马城中心，把权力投射到遥远边疆，比如苏格兰的哈德良长城，就需要一套层级组织。谁管谁，命令怎么下达，情报怎么回传，每一级都有明确的管理幅度。

这套结构的核心，不是创造力，而是信息传递。

今天大多数公司也差不多。创始人做决策，高管拆目标，中层做协调，基层执行。信息从下往上汇总，命令从上往下分发。

很多中层管理岗位，本质上不是在创造新东西，而是在做人肉路由器。这个说法不好听，但很准确。

他们收集信息，压缩信息，翻译信息，转发信息。会议、周报、状态同步、OKR check-in、项目管理，很多都是这个系统的一部分。

在 AI 之前，这样做是合理的。因为公司太大以后，创始人不可能知道每个客户反馈、每个工程进展、每个销售线索、每个运营异常。

所以你需要层级。

但 Tom 说，AI 正在打破这个前提。

如果公司里的信息本身能被 AI 读取、理解、检索、总结、调用，那么公司就不再需要那么多人类节点来转发信息。

所以这不是一个效率问题。

这是组织形态问题。

PART 02

二、Copilot 是错误的心智模型

过去一年，很多人把 AI 理解成 Copilot。这是一个容易接受、但可能会误导你的比喻。

给工程师一个 AI 助手，让他写代码快 20%。给客服一个 AI 助手，让他回复客户快一点。给销售一个 AI 助手，让他写邮件快一点。

这当然有价值。但 Diana 和 Tom 都认为，如果你只看到这一层，就等于只看到了蒸汽机可以帮马车跑快一点，却没看到铁路要来了。

Diana 的说法是：

AI 带来的不是 productivity，而是 capability。

生产率提升，是旧工作方式变快。能力提升，是过去一个人根本做不了的事，现在一个人能做了。

YC 的那张 slide 上写得非常狠：

1 person with AI tools = 1000x Google engineer

这句话当然不是严格数学等式。它的意思是，一个会用 AI 的人，身边如果有一整套 Agent 系统，他的有效产出可能不再对应一个人，而对应过去一个团队，甚至一个大团队。

所以真正的问题不是“工程师能不能多写点代码”。

真正的问题是：

如果一个人可以调用一群 Agent，如果公司所有知识都能被 Agent 读取，如果软件可以被随时生成和重生成，那么公司还需要按照过去那套方式组织吗？

YC 的答案非常清楚：不需要。

PART 03

三、第一步：把公司变成 AI 可读的对象

要做到这一点，第一件事不是买工具，而是改信息结构。

Diana Hu 用了一个词：queryable company。

Tom Blomfield 用了另一个词：legible to AI。

两个词意思差不多：公司必须对 AI 可查询、可理解、可调用。

这听起来像一句漂亮话，其实是个非常残酷的标准。

一家公司的知识，通常散落在这些地方：

• 创始人和员工脑子里的 know-how
• Slack 和飞书里的消息
• 邮件和私信
• Notion、Google Docs、Linear、GitHub
• 客户电话、销售录音、客服工单
• 产品数据、取消订阅、用户行为
• 各种会议纪要、站会、周报

这些东西合在一起，才定义了“这家公司到底是怎么工作的”。

如果它们只存在人脑里，AI 就用不了。 如果它们散落在私聊里，AI 也用不了。 如果它们没有结构化，没有总结，没有索引，AI 还是用不了。

所以 Tom 说了一句非常硬的话：

如果没有被记录，它对你的 intelligence 来说就没有发生。

也就是说，在 AI 原生公司里，一次重要会议如果没记录，就等于没有进入公司大脑。一个客户需求如果只停留在某个人微信里，就等于不存在于系统里。一次关键销售对话如果没有被沉淀，它就不能训练下一次销售。

这就是为什么 YC 开始记录 office hours，保存 partner 邮件，把 Slack、DM、客户沟通尽可能纳入系统。

不是为了监控员工。

而是为了让公司有一个能学习的“大脑”。公司大脑不是比喻，它首先是一个信息工程问题。

PART 04

四、开环公司会丢信息，闭环公司会进化

这里要引入一个控制论概念：open loop 和 closed loop。

开环系统没有反馈。

你做一个决策，执行它，结果怎么样，往往不会被系统化地测量、总结、反馈到下一次行动里。

很多传统公司就是开环系统。开会时大家拍板，项目做完以后没人真正复盘。客户流失了，销售知道一点，客服知道一点，产品知道一点，但没有一个系统把它们合起来，让下一次决策变得更好。

开环系统最大的问题是：它会不断丢信息。

闭环系统不一样。

闭环系统会持续监测输出，把结果反馈回系统，然后自动调整下一步。

它不只是执行，它会学习。

Diana 说，AI 原生公司必须是闭环公司。

Tom 往前推了一步：公司不是一个闭环，而应该是一组递归、自我改进的 AI loops。

一个完整的 AI loop，大概有五层。

第一层是sensor layer。它负责感知外部世界。客户邮件、客服工单、代码变更、取消订阅、产品 telemetry，都是传感器数据。

第二层是policy / decision layer。它决定什么能自动做，什么必须问人，什么必须记录，哪些动作有风险。

第三层是tool layer。这是 AI 能调用的确定性工具，比如查数据库、读日历、跑测试、调用内部 API、提交代码。

第四层是quality gate。包括 eval、测试、安全过滤、高风险事项的人类复核。

第五层是learning mechanism。系统和真实世界交互后，发现哪里失败，再把失败反馈回循环顶部。

如果这五层能跑起来，AI 就不只是一个“帮你干活的助手”。

它变成了一个能发现问题、修复系统、让下一次表现更好的机制。

这就是自我进化。注意，这已经不是“自动化”了，这是把公司局部变成一个会学习的系统。

PART 05

五、YC 的 aha moment：AI 开始修复自己

Tom 在分享里讲了 YC 内部的一个例子，这是整套逻辑的高潮，也是我认为最值得中国创业者认真看的部分。

一开始，YC 做了一个 Agent，可以查询内部数据库。

比如你问：“我上次和这家公司 office hours 是什么时候？”它能查出来。

后来它变聪明了。比如某家公司需要 petrochemicals 领域的人脉介绍，它可以查 YC 数据库，用 RAG 找出几个相关创始人。

这已经不错了，但 Tom 说，这仍然只是 sidekick。

它让 YC 合伙人效率提高 20% 或 30%。这还是 Copilot 模式。

真正的 aha moment，是他们在这个 Agent 上面又放了一个 monitoring agent。

这个监控 Agent 会看所有 YC 员工发出的查询。哪些成功了，哪些失败了。失败以后，它会追问：

• 为什么失败？
• 是不是缺一个 deterministic tool？
• 是不是 skills 文件要更新？
• 是不是数据库需要一个新 view？
• 是不是需要一个新 index？

然后最关键的事情发生了：

系统会在夜里写代码，提交 merge request，让另一个 Agent review，再合并、部署。

于是第二天，员工再问同一个问题，它就能成功。

Tom 说，这就是他的 holy shit moment。我们可以翻译得文雅一点：这是他真正意识到范式变了的瞬间。

因为这时 AI 不只是让人更强。

AI 开始让系统本身更强。

这就是“公司在你睡觉时变好”的意思。

过去，公司进步靠人开会、复盘、排计划、写需求、排 sprint。现在，至少在某些局部，公司可以自动发现失败、自动补工具、自动改代码、自动部署。

这才叫闭环。不是 AI 帮你多做一点事，而是 AI 帮公司减少下一次失败的概率。

PART 06

六、产品、客服、销售都可以变成自优化系统

这个思路不只适用于内部查询。

Tom 举了产品优化的例子。

一个 Agent 可以持续看产品分析，找出销售漏斗里摩擦最大的地方。然后它研究最佳实践，提出 A/B test，跑一周，选择效果更好的版本，部署。

然后再来一遍。

客服也类似。

客户建议不断进来，Agent 先 triage。这里需要一个类似 CPO + CTO 的判断层：哪些建议不符合路线图，应该丢掉；哪些建议符合路线图，可以实现。

如果判断通过，系统可以夜里写代码、部署，并告诉客户“这个问题已经修了”。

这里有个关键区别：这和普通自动化不是一回事。

普通自动化是：人定义规则，机器执行规则。

自我进化系统是：机器执行任务，同时发现规则哪里不够、工具哪里不够、知识哪里不够，然后改进下一次执行。

它不是一条流水线。

它是一个会学习的循环。

PART 07

七、三种角色：builder、DRI、AI founder

如果公司变成一组 AI loops，那组织里的人会变少，但责任会变重。人少不是因为公司不需要人，而是因为它不需要那么多“传话的人”。

Diana 给出过三种角色，我觉得这比 Tom 的两种角色更适合创业公司理解。

第一种是builder-operator。

不只是工程师，所有人都要能直接造东西、直接跑业务。销售、客服、运营、HR，都不应该只写文档、开会、提需求。

未来的会议里，最好不要只带 PPT。

要带能跑的原型。

第二种是DRI，directly responsible individual。

每件重要的事，都要有一个明确命名的人负责。不是委员会，不是一群人，不是“我们团队”。而是一个人，一个结果，无处可躲。

AI 可以帮你协调，可以帮你执行，可以帮你分析。但责任不能被摊薄。

第三种是AI founder。

这一点特别重要。

创始人不能把 AI 战略外包给某个“AI 负责人”。创始人必须亲自使用 Agent，亲自打破自己对“现在能做什么”的旧判断，亲自示范什么叫能力跃迁。

因为公司文化不是靠 PPT 建立的，是靠创始人每天怎么工作建立的。

如果创始人自己还在用旧方式工作，公司不可能真的 AI native。

PART 08

八、Burn tokens, not headcount

Tom 有一句话很适合做墙上的标语：

Burn tokens, not headcount.

YC 看到的趋势是，最近这些公司到 Demo Day 时，每个员工对应的收入比 18 个月前高了大约 5 倍。

也就是说，公司越来越不受“人头”限制，而是受“智能调用量”限制。

Diana 也说，未来公司比拼的不是 headcount，而是 token usage。最好的公司会 token maxing。

这个观点听起来有点反直觉。

过去，一个快速增长的公司，往往意味着招聘越来越多。更多工程师，更多设计师，更多销售，更多客服，更多中层。

但 AI 原生公司的逻辑可能相反：

一个会用 AI 的人，加上一套 Agent 系统，就能完成过去一个团队才能完成的事。那你就应该愿意承担一个让你有点不舒服的 API 账单，因为它替代的是更贵、更慢、更臃肿的人力结构。

当然，Tom 也提醒，粗暴统计每个人用了多少 token 很容易被游戏化，不适合直接作为升职裁员指标。

但方向是对的。

现在最重要的不是省 token，而是搞清楚新智能到底能做到什么。

在这个阶段，如果一个人完全不使用 token，可能不是节俭，而是还没进入新范式。

PART 09

九、软件是一次性的，context 才值钱

这可能是整套观点里最容易被低估的一点。

Tom 说，过去他会说每个 function 都应该有 dashboard。现在他觉得不止 dashboard，而是 on-demand software。

现代 coding agent 已经强到可以 one-shot 很多内部软件。运营团队、销售团队、活动团队，都可以基于自己的业务理解，临时生成 dashboard、workflow、小工具。

但这些软件本身不应该被当成宝贝。

真正值钱的是：

• 数据
• 业务上下文
• 公司 know-how
• skills
• 决策原则
• 对流程的理解

软件只是这些 context 上面长出来的一层壳。

今天你为一场 YC 活动生成一个内部工具，用完就可以扔。两个月后模型更强，你把原始指令和上下文再喂进去，重新生成一版更好的。

所以 Tom 的结论是：

Business context and skills are valuable. Software on top is ephemeral.

这句话很关键。

过去公司沉淀资产，往往沉淀成代码库、SOP、文档和流程。

未来更重要的资产，可能是“公司大脑”里的 context：我们如何判断客户需求，如何办活动，如何做销售，如何处理联合创始人冲突，如何招聘，如何做产品取舍。

只要 context 在，软件可以不断重生成。

PART 10

十、YC User Manual：一个活的公司大脑

Tom 讲了 YC 用户手册的例子。

YC 原来的 user manual，大多写于 5 到 10 年前，已经有点过时。

现在 YC 最近三个月录下了大约 2000 小时 office hours。于是他们尝试把这些录音归纳、分类、合成，按 fundraising、hiring、co-founder disputes 等主题整理，再生成一本新的 user manual。

一个周末之后，他们得到了一份 150 页的新手册，而且比旧版明显更好。

更重要的是，它现在可以每个月更新。

每一条新的建议，都会被拿来和现有 user manual 比较。有价值就纳入，没价值就丢掉。

于是 user manual 不再是一个文档。

它变成了一个 self-improving living brain。

这就是公司大脑的一个雏形。

而且它还可以反过来作为 AI Agent 的上下文。创始人提问时，回答的不再是某个单一模型的泛泛知识，而是 16 位 YC 合伙人长期给创始人建议之后沉淀出的综合智慧。

前提只有一个：

这些知识必须被记录，必须被压缩，必须对 AI 可读。

PART 11

十一、人类并没有消失，只是换了位置

如果公司中间是 company brain，那人在哪里？

Tom 的答案是：人在边缘。

人类站在公司大脑和真实世界接触的地方。

哪些地方还需要人？

新奇场景。伦理判断。高风险时刻。高情绪密度时刻。比如创始人要不要和联合创始人分手。比如关键销售对话。比如需要建立信任、安抚焦虑、判断复杂人性的时刻。

AI 会接管大量信息处理和协调工作，但它不会立刻替代所有现实接触。

这其实给人类提出了更高要求。

过去很多人的价值，是知道信息在哪里、帮别人传递信息、协调信息。

未来这些价值会快速贬值。

人的价值会更靠近判断、责任、信任、品味、现实接触和高风险决策。

也就是说，人不是被拿掉。

人是从公司信息管道的中间，移动到公司智能系统的边缘。

PART 12

十二、为什么创业公司更容易赢

这件事对创业公司尤其重要。

大公司当然也会用 AI。但大公司有三个包袱：

第一，旧系统。 第二，旧流程。 第三，旧组织。

它们一边要维护现有产品，一边要拆掉多年积累的 SOP，还要推翻关于“软件怎么被建造”“组织怎么协作”的底层假设。

每动一下核心流程，都可能破坏已经能跑的东西。

所以成熟公司很难彻底 AI native。

创业公司刚好相反。

没有遗留系统，没有沉重组织，没有几千人要重新培训。小公司可以从第一天开始就围绕 AI 设计自己的工作流、文化和组织结构。

这就是窗口期。

如果你现在开始创业，你不应该先建一个传统公司，再往里面加 AI。

你应该一开始就问：

如果公司本身是一组会自我改进的 AI loops，我们今天应该怎么设计它？

PART 13

结尾：别再把 AI 当工具了结尾：别再把 AI 当工具了

把两场 YC 分享合起来，核心其实只有一句话：

AI 原生公司，不是更会使用 AI 工具的公司，而是把公司本身改造成 AI 可以理解、可以查询、可以反馈、可以自我改进的系统。

这句话有几个推论。

第一，别只盯着“效率提升 20%”。那是 Copilot 心智模型。真正重要的是 capability，是一个人能不能拿到过去一个团队的能力。

第二，让公司对 AI 可读。没记录，就等于没发生。会议、工单、客户反馈、销售电话、站会、产品数据，都应该成为公司大脑的上下文。

第三，把开环改成闭环。公司不是做一次决策、执行完就结束，而是持续感知、判断、执行、检查、学习。

第四，组织会变薄。中层管理作为信息路由器的价值会下降，builder-operator、DRI、AI founder 会变得更重要。

第五，烧 token，不要烧 headcount。高 API bill 可能比高人力成本更健康。

第六，context 比 software 更值钱。软件可以重生成，公司真正的资产是业务知识、数据、skills 和判断原则。

最后，创始人不能旁观。

你不能让别人替你建立对 AI 的信念。你必须自己坐下来，用 coding agent，用内部 Agent，用这些工具一直工作，直到你对“一个人能做什么”的旧判断被打碎。

这就是 Tom 说的 aha moment。

不是“AI 帮我快了一点”。

而是某一天你发现：

公司开始自己变好了。

PART 14

原始视频链接

• Y Combinator《How To Build A Company With AI From The Ground Up》：https://www.youtube.com/watch?v=EN7frwQIbKc
• YC Root Access《How to Build a Self-Improving Company with AI》：https://www.youtube.com/watch?v=t-G67yKAHBQ

文章来自于"刘小排r"，作者 "刘小排"。