YC 的 AI 原生公司论：操作系统、递归循环与自我改进

看完 Anthropic 官方 AI native 手册后，冒出来一个问题：如果模型公司已经开始把"AI 原生"写成公司手册，那最懂创业公司的创投机构会怎么理解这件事？

于是找了 YC 最近两支视频重新看了一遍。表面上讲 AI 公司怎么少招人、怎么让工程师更快、怎么用更小团队做更大事情。但这个理解太浅。

真正有价值的地方：YC 把"公司"这件事重新定义了一遍。

不是工具清单，是公司操作系统

过去一年很多人谈 AI 还是生产力框架：给工程师加 Copilot，让客服快一点，让销售多写几封邮件。这当然有用，但这只是把更强的引擎装到旧车上。

YC 第一支视频的关键判断：AI 带来的变化不只是 productivity boost，而是 entirely new capabilities。合适的人加上 AI 工具，现在可以做过去一个团队才能做的事，甚至可以做过去根本做不了的事。

如果 AI 只是让员工快 20%，公司结构不用变。但如果 AI 带来的是新能力，那公司本身就要重做。工作流、决策方式、信息流动方式、管理层级，全部要重做。

所以 YC 说 AI 不应该只是公司使用的一个工具，它应该成为公司运行的 operating system。

旧公司的问题：信息太多，但不可查询

旧公司的问题不是没有信息。恰恰相反，旧公司信息太多了：客户反馈在邮件里，销售判断在电话里，产品计划在 Notion 里，工程状态在 Linear 里，技术细节在 GitHub 里，真实分歧在 Slack 私信里，最关键的上下文在某个人脑子里。

然后公司每周开会。大家把这些碎片搬到会议室里，人肉同步一遍，再人肉总结一遍，再人肉推进一遍。很多公司不是在运营，是在搬运信息。

四层操作系统架构

AI 原生公司的操作系统要解决的第一件事，就是把这些碎片放进同一个智能层里。

第一层：信息层 公司发生的事必须被记录下来。会议、客户反馈、销售电话、支持工单、代码变更、产品数据、招聘进度、收入变化，都要留下可读取的 artifact。

第二层：语义层 记录本身不够。十万小时录音不能直接塞进上下文窗口。需要被切分、聚合、总结、分类，变成 AI 能理解的公司上下文。

第三层：工具层 AI 不能只会回答。它要能查数据库、看工单、读代码、开 PR、生成 dashboard、调用内部 API。没有工具层，AI 只是公司旁边的顾问。有工具层，它才进入执行。

第四层：反馈层 执行结果要回到系统里。哪些计划准确，哪些失败，哪个客户反馈被解决，哪个功能上线后转化提升，都要被记录。否则公司还是开环。

开环系统的毛病是：做了很多事，但系统没有真的学到。闭环系统的价值是：每一次执行都会让下一次更准。

可查询组织

YC 第一支视频里有个关键词：queryable。要构建闭环，必须让整个公司都可查询。组织要对 AI 可读。

Root Access 讲得更直：如果事情被记录了，它就发生在 AI 面前；如果没有被记录，它对你的 intelligence 来说就没发生。

可查询组织不是"有一个知识库"。很多公司都有 Notion，一搜全是过期文档，三年前的 onboarding，夹着一个已经离职员工写的流程。那不叫组织记忆，那叫数字仓库。

真正的可查询组织，是公司发生的重要事情都自动变成 artifact：

会议不只是录音，而是决策、责任人、分歧、后续动作
客户反馈不只是客服记录，而是问题类型、影响范围、是否进入路线图
销售电话不只是 CRM 字段，而是阻力、承诺、竞品、购买信号
工程工单不只是状态，而是为什么做、怎么做、结果如何
产品数据不只是 dashboard，而是哪里卡住、哪个实验有效、下一步该试什么

递归循环：五层自我改进

可查询组织只是让公司能被 AI 看见。真正厉害的地方，是让公司能通过 AI 改进自己。这就是第二支视频讲的 recursive self-improving AI loops。

递归循环不是普通自动化。普通自动化只会重复执行一套流程，流程坏了它也照着坏流程跑。很勤奋，也很危险。

递归循环的区别在于：系统执行任务后，会观察自己哪里失败，并把失败转化成下一轮能力。

第一层：传感器层 从现实世界拿信号。客户邮件、支持工单、代码变更、用户取消订阅、产品 telemetry，都是传感器。

第二层：策略层 规定什么能做，什么需要人类批准，什么必须记录。没有策略层，agent 就会变成一个精力旺盛但边界感很差的实习生。

第三层：工具层 一组确定性 API。查数据库、看日历、读工单、改代码、开 PR、部署。模型负责判断，工具负责动作。

第四层：质量门 eval、安全过滤、权限检查、高风险操作的人类审核。没有质量门，自我改进很快会变成自我闯祸。

第五层：学习机制 系统失败后，自动诊断原因，然后补工具、补 skill、补索引、补数据库视图、补流程。

这五层合起来，才叫递归循环。

YC 自己的案例

YC 一开始做了一个 agent，可以查询 YC 数据库。比如"我上次什么时候给这家公司做 office hour？"

后来它聪明一点了。某个 partner 正在给一家创业公司做 office hour，这家公司需要石化行业的人脉介绍，agent 可以从数据库里找出五个相关创始人。

但这还只是 sidekick——"AI 让我这个人更强"。

真正的转折，是 YC 在这个 agent 上面加了一个 monitoring agent。这个监控 agent 会看每个 YC 员工的每个查询，判断哪些成功，哪些失败。

当一个查询失败时，系统不只是说"抱歉，我不知道"。它会继续问：

为什么失败？
是不是缺一个确定性工具？
是不是 skill 文件需要更新？
是不是需要新的数据库视图？
是不是需要新的索引？

然后更狠的一步：它可以写代码，向 YC codebase 提交 merge request，让另一个 agent review，合并，部署。

第二天，如果有人问同类问题，系统已经会了。

这才是自我改进。不是"AI 帮人查了一次资料"，而是"AI 发现自己查不到，补齐了自己下一次查到的能力"。

三类应用场景

产品：自优化产品循环 输入是 product analytics、funnel 数据、用户行为、转化下降点。agent 找到销售漏斗里摩擦最大的部分，研究最佳实践，生成 A/B 测试，跑一周，选择赢家，部署。然后继续做下一轮。

客服：用户反馈循环 用户建议不断进来，agent 先分类：哪些不做，哪些符合路线图，哪些可以立刻实现。对可以做的小功能，它可以写代码、部署、交付给客户，再把结果反馈进路线图。

知识库：活的公司大脑 YC 过去的手册很多内容是 5 到 10 年前写的，已经过时。后来有了过去 3 个月约 2000 小时 office hour 记录，可以把这些录音切分、聚合、总结、分类，按融资、招聘、联合创始人纠纷等主题重新生成手册。

结果是周末生成了一份 150 页的新手册，而且之后可以每月更新。每一条新建议都会和旧手册比较，决定纳入还是丢弃。

知识库不应该是静态文档。真正的公司知识应该像产品一样更新，像代码一样被维护，像模型一样持续吸收新样本。静态手册会过期，活手册会长大。

人的位置会变，但不是消失

被重估的不是"人"，而是"信息路由型管理"。

旧公司为什么需要那么多中层？因为信息必须靠人上传下达。人就变成组织里的路由器。人肉路由很贵，也很慢，还会丢包。

如果公司已经 queryable、artifact-rich、legible to AI，智能层就能承担大量信息路由。公司的速度取决于信息流动速度，每减少一层人工路由，就是直接的速度提升。

人的位置会变：

Builder / operator：所有人都要能直接做东西、跑流程、改系统。开会带 prototype，而不是 deck
DRRI（directly responsible individual）：不是传统管理者，而是对结果负责的人。一人一果，责任清楚
AI founder：创始人不能把 AI 战略外包。如果创始人自己不亲自坐下来和 coding agent、workflow agent、data agent 一起工作，他不会真正知道能力边界在哪里
Humans at the edge：处理模型还碰不到的现实。高风险判断、伦理问题、情绪强度高的创始人冲突、关键客户关系

burn tokens, not headcount

YC 看到 Demo Day 公司的人均收入比 18 个月前高出约 5 倍，判断未来公司可能更受 token 使用量限制，而不是 headcount。

但 token 使用量不能被做成愚蠢排行榜。一旦变成员工晋升或淘汰指标，大家一定会刷。真正要看的不是谁烧了更多 token，而是谁把 token 变成了系统能力。

同样花 100 美元 API，有人只是生成了 200 篇没人看的周报，有人让客服问题下次自动分类、让产品实验自动生成、让内部手册每月更新。差别很大。

起步：选一个最小闭环

别一上来就造"公司大脑"。这个词太大，容易让人三周后收获一堆架构图和一个不能用的 demo。

更好的做法：先选一个高频闭环（工程 sprint 计划、客服反馈、产品 funnel、销售 playbook、内部知识库），然后按九步走：

把闭环的输入全部记录下来
把记录变成结构化 artifact
定义闭环的成功标准
给 agent 可调用工具
设置策略和权限：什么能自动做，什么必须人审
设置质量门：eval、review、日志、回滚
加 monitoring agent，看每次成功和失败
让失败自动生成改进任务
每周只看一个问题：这个循环有没有让同类问题下次更快解决？

如果没有，它只是自动化。如果有，它才开始自我改进。

自检清单

真正的标准不是"有没有用 AI"，而是一个问题进入人手里之前，已经被系统处理到了哪一步。

如果每件事都还要人先读材料、找上下文、判断优先级、查历史、写方案、催执行，那你只是在用 AI 工具。真正 AI 原生的公司，人的输入应该已经被 AI 和 SOP 预处理过。

人看到的不是一团原始信息，而是一张已经加工好的任务卡：发生了什么、为什么重要、关联了哪些客户/数据/工单和历史决策、系统建议怎么处理、需要人类判断的点是什么、风险和回滚方案是什么、下一步动作是否已经能由工具层执行。

这才叫公司操作系统。