别画组织架构图，画信息流图——YC 合伙人 Diana Hu 的 AI 原生公司方法论
YC GP Diana Hu 发布 AI 原生公司完整方法论：让 AI 成为公司「操作系统」而非工具，通过建立闭环信息流、消除人工中间件、推行规格驱动开发，实现迭代周期减半、产出接近 10 倍。
2026 年 4 月 24 日，Y Combinator General Partner Diana Hu 在 YC Startup School 发布了一场约 12 分钟的演讲1，同期在 YC 官方库配发书面论述2。这不是一篇「用 AI 提效」的操作手册，她的论点更根本：创业公司现在面临的，是一次组织架构层面的重写机会，而不仅仅是生产力工具的升级。
她的观察起点是：当前几乎所有关于 AI 的讨论还停留在「生产力」框架里——AI 帮你写代码、AI 帮你处理邮件。这个框架成立，但它遮蔽了一个更大的变化：AI 正在改变「哪些岗位需要存在」本身。
"AI is not just going to change how quickly software gets built or what workflows get automated. It's going to fundamentally change the way startups should be run."——「AI 不只是会改变软件构建的速度、或哪些流程被自动化，它将从根本上改变创业公司应该如何运作。」1
Diana Hu 是谁
在谈她的方法论之前，有必要交代一下背景：Escher Reality（YC S17）联合创始人兼 CTO，后被 Niantic 收购；Carnegie Mellon 本硕。加入 YC 后已完成 5 个 batch 的辅导，累计 office hours 超过 1700 次，覆盖公司的合计估值达 17 亿美元1。
这个背景说明了一件事：她的观察是从数百个早期创业公司的一手经验里提炼出来的，不是理论推演。
核心框架：把公司变成闭环系统
Diana Hu 的中心论点，可以用一句话概括：
"AI should not be a tool your company just uses. It should be the operating system your company runs on."——「AI 不应只是你的公司所使用的工具，它应该是你的公司赖以运行的操作系统。」2
她用「开环 vs 闭环」来区分两种组织形态：传统公司是开环的——信息流经人，在每个层级被过滤和压缩，创始人最终拿到的是几轮传递后的失真版本。AI 原生公司则必须是闭环的——所有重要行动都产生制品（artifact），这些制品持续喂给一个会自我学习的智能层，公司因此获得自我修正的能力。
要实现闭环，前提是「让公司对 AI 可查询（queryable）」2：
"To build these closed loops, you will need to make your entire company queryable."——「要建立这些闭环，你需要让整个公司都变得可被查询。」
四个具体操作
从抽象原则到具体操作，她给出了几个落地方向2：
一、把信息从私信和会议室里解放出来。 减少私信和邮件沟通，因为这些信息路径不留痕迹，AI 无法读取。把讨论迁移到 Slack、Linear、GitHub、Notion 这类有结构化制品的平台，并在这些平台上嵌入 AI Agent。
二、会议全程录音，AI 生成摘要。 目的不是替代人类决策，而是让「决策发生时产生的信息」能被后续系统读取。少追进度，多看仪表盘。
三、搭建软件工厂（software factory）模式。 人写规格（spec）和测试用例定义「成功是什么」，AI Agent 生成实现并迭代到测试通过——从 TDD（测试驱动开发）进化到 SDD（规格驱动开发）。她援引了 StrongDM 的案例：整个 repo 里已经没有手写代码，只有 specs 和 test harnesses1。YC 公司中实践这一模式的团队，工程迭代周期缩短一半，产出接近原来的 10 倍1。
四、画信息流图，而非组织架构图。 传统的 org chart 描述的是汇报关系；她要创始人画的是：一条重要信息从产生到被决策者用上，中间经历了哪些节点、损耗在哪里。这张图画出来之后，AI 能接管哪些节点，通常就一目了然2。
组织重构：三种新角色与「中层消亡」
这套框架对组织结构的影响，Diana Hu 讲得相当直接：
"If your company is queryable, artifact rich, and legible to AI, you should have almost no human middleware."——「如果你的公司可被查询、制品丰富、对 AI 可读，你应该几乎不需要『人工信息路由中间件』。」2
「人工信息路由中间件」这个词，精确描述了传统中层管理者的核心职能之一：收集各方信息、加工后向上汇报，同时把高层指令拆解向下传达。这项职能，在一个闭环 AI 系统里确实没有存在的结构性理由。
- IC（Individual Contributor，即 Builder-Operator）：直接构建和运营的人，不限于工程师，产品、运营都可以是 IC。
- DRI（Directly Responsible Individual，直接负责人）：一个人对一个结果负全责，责任边界不允许模糊。她的原话是 "One person, one outcome, no hiding."（一人，一结果，无处推诿。）
- AI Founder Type：亲自动手构建系统、以此示范给团队看的创始人类型。
配套的核心理念是「Token Maxing，而非 Headcount Maxing」：
"The best companies will be the ones that are token maxing."——「最好的公司将是那些最大化 token 使用的公司。」1
竞争优势不再来自雇更多人，而来自更充分地调用 AI 算力。
适用场景：初创公司的窗口期
这套框架对早期创业公司的价值，远大于成熟大公司1：
"If you are an early stage founder, you have a huge advantage."——「如果你是早期创始人，你拥有巨大的优势。」
原因很具体：没有遗留系统需要迁移，没有几百名员工需要再培训，没有积累了十年的「信息私藏」文化。她的判断是，初创公司可以比大公司快上千倍：
"Startups can operate thousand times faster than the incumbents."——「创业公司的运转速度可以比现有大企业快上千倍。」1
相反，如果你的团队已经超过 50 人、有既成的汇报文化和私信习惯，这套方法论的迁移成本会显著上升——不是做不到，但需要先处理文化层面的阻力，这一部分她在演讲中没有展开。
最直接受益的团队画像：10 人以内的早期技术团队，已经在用 GitHub/Linear/Notion 做项目管理，创始人本身愿意亲自上手 coding agents，且团队内部没有强烈的「人头数等于能力」的招聘惯性。
围绕这条内容继续补充观点或上下文。