夜雨聆风
Diana Hu 在这期 Startup School 里讲的重点可以概括成：
AI 带来的变化，不只是团队更高效，而是公司本身应该被重新设计。
她的判断是：AI 不应该只是公司里某个工具，而应该变成公司运行的底层系统。
公司里的会议、需求、销售、客户反馈、研发排期、招聘、运营数据，都应该被记录下来、结构化起来，并且持续被 AI 读取、分析和反馈。
Diana Hu 讨论的是如何让公司变得“可查询”，让智能体能在各个职能里持续改进，以及为什么传统管理层级会被新的智能层替代。
这句话听起来又是个宏大话题，但如果拆开看，其实还挺具体的。
过去公司管理靠人传信息：
员工汇报给主管，主管汇总给负责人，负责人再同步给老板。信息一层层往上传，一层层往下分。
这个过程慢，而且一定会丢失信息。
现在 AI 可以做另一件事：把公司每天产生的工作痕迹直接“吃”进去。
不是等人开会汇报，而是让系统自己知道：
这个需求为什么排期、客户反馈了什么、销售承诺了什么、工程师实际交付了什么、哪些事情卡住了、下一步应该怎么调整。
这才是她说的 AI 原生公司：
不是每个人都用一个 AI 助手，是公司有了一个可以持续理解业务、持续更新状态、持续推动决策的中枢系统。
AI 真正改变的，是公司怎么运转
现在很多公司用 AI，还是在给原来的工作流打补丁：
写文档慢，就用 AI 写文档；代码写得慢，就用代码助手。
客服回复慢，就上客服机器人；会议纪要没人整理，就开个 AI 会议记录。
这些都有用，但都还停留在工具层。
原来的组织结构、工作方式、决策链路没有变，只是每个环节稍微快了一点。
Diana Hu 认为，这个理解太浅了。
她在播客里说，AI 的重点不是让已有流程快一点，而是带来新的能力。
一个会用 AI 的人，现在可以做过去一个小团队才能完成的事情，甚至可以做以前根本做不了的事情。
这会改变公司最底层的设计逻辑。
过去公司要做一件事，通常靠加人。研发不够就招工程师，销售不够就招销售，管理跟不上就加主管，信息太乱就加项目经理。
AI 之后，公司不一定要先加人，而是要先问：
这件事能不能被系统记录？能不能被 AI 理解？能不能形成反馈？能不能越跑越准？
这也是她说的 AI 要成为公司的操作系统。
这个说法可以说得更直白一点：
厉害的 AI 公司，不只是产品里有 AI，而是公司自己也是用 AI 跑起来的。
公司要从“开环”变成“闭环”
Diana Hu 用了一个很重要的概念：闭环。
开环的意思是，公司做了一个决定，执行完了，但结果没有被系统性记录，也没有反过来改进流程。
很多公司其实都是这样运转的。
开会讨论一个需求，产品写文档，研发排期，销售去跟客户沟通，客户反馈散落在邮件、微信群、Slack、飞书、CRM、会议纪要里。
最后项目做完了，大家可能复盘一下，也可能根本没复盘。
下一次再做类似事情，又重新来一遍。
问题不是大家不努力，而是信息没有真正沉淀下来。公司每天都在产生经验，但这些经验没有变成系统能力。
闭环公司不一样。
每一次沟通、每一个需求、每一次客户反馈、每一轮开发、每一个结果，都应该变成系统可以读取的材料。
AI 能看到输入，也能看到输出，还能看到中间过程。这样它才知道什么做对了，什么做错了，下一次该怎么调整。
这件事听起来像管理方法，实际上是公司能力的差别。
一个开环公司，靠人传递经验；一个闭环公司，靠系统沉淀经验。
人会离职，会忘记，会理解偏差；系统如果设计得好，会持续积累，而且越用越完整。
所以 Diana Hu 提到，AI 原生公司要让每一个重要流程都形成闭环：
信息被捕捉，结果被反馈，流程被改进。
公司要变得“可查询”
播客里反复提到一个关键词：queryable，我觉得中文可以理解成：公司要变得可查询。
这不是说公司要多做几个数据库，也不是简单地把文件放到知识库里。
它的意思是，公司每天发生的重要事情，都要让 AI 能看懂、能调用、能分析。
比如会议不要只靠人记脑子里，要有记录。
重要讨论不要散落在私聊里，要尽量进入公开频道或可检索系统。
客户反馈不要只停留在销售的个人理解里，要进入系统。
研发排期、需求变更、产品规划、上线结果、客户投诉，都要变成 AI 可以读取的材料。
Diana Hu 举了一个研发管理的例子。
如果一个智能体能看到 Linear 里的任务、Slack 里的工程讨论、客户邮件里的反馈、GitHub 里的代码变化、Notion 或 Google Doc 里的规划、销售电话记录、每日站会内容，它就可以分析上一轮迭代到底交付了什么，是否真的满足了客户需求。
下一步，它还可以帮团队提出更准确的研发计划。
这件事对创业公司很重要。
过去研发管理很依赖中间层：项目经理追进度，主管开会问状态，负责人再向上汇报。
每一层都在做信息压缩，信息压缩一定会失真。
客户原本表达的是“这个功能影响采购决策”，传到产品那里可能就变成“客户想要这个功能”；
再传到研发那里，可能只剩一个任务标题；做到最后，大家以为交付了，客户并不觉得问题解决了。
如果公司是可查询的，AI 可以直接看到更多上下文。
它不只看任务，也看客户原话、销售场景、需求来源、历史承诺、实际交付结果。
这样，管理就不再只是“问进度”，而是系统能更早发现问题。
谁卡住了，哪里偏了，客户真实需求有没有被误读，下一轮排期是否合理，这些都可以提前浮出来。
Diana Hu 说，她看到一些团队用这种方式把工程迭代周期缩短一半，在同样时间里完成接近 10 倍的工作量。
这个数字来自她在播客里的观察表述，更适合理解为 YC 视角下的创业公司案例经验，不宜当成严格行业统计。
也就是说：信息越完整，AI 越有用；公司越可查询，执行越快。
“软件工厂”会改变产品开发方式
Diana Hu 还提到一个正在出现的新模式：AI 软件工厂。
这个概念可以说得简单一点：
人负责定义要做什么，AI 负责把代码写出来、跑测试、反复修改，直到结果符合要求。
过去写软件，核心动作是工程师写代码。
现在更高效的方式可能是：人先写清楚需求规格和测试标准，告诉系统什么叫成功，然后让 AI 智能体生成实现方案、写代码、跑测试、修 bug。
人主要负责判断方向和验收结果。
这和测试驱动开发有点像：
以前是工程师先写测试，再写代码让测试通过；现在是人写规格和测试，AI 写代码和迭代。
这会让工程师的工作也发生变化。
以前厉害的工程师，是自己能写很多高质量代码。
以后厉害的工程师，更像是能设计好问题、拆清楚系统、写出准确测试、调动一组 AI 智能体完成开发。
代码本身的重要性还在，但人的价值会更多前移到“定义目标”和“判断质量”。
这也是为什么她提到“1000 倍工程师”。
这个说法听起来夸张，但它想表达的不是某个人突然变成超人，而是一个工程师身边有了一整套智能体系统：
一个写代码，一个跑测试，一个查文档，一个改接口，一个做验证，一个持续迭代。
人不再是单独写代码，而是在指挥一条自动化生产线。
这样一来，一个人能做的事就变多了。
这对创业公司尤其关键。以前一个早期团队可能因为工程人手不够，很多想法只能排队。
现在，如果团队能把规格、测试、反馈和部署流程组织好，产品试错速度会快很多。
但这里也有一个前提：公司本身得有足够清楚的流程和足够好的上下文。
AI 不是凭空变强的。
你给它一堆模糊需求，它只能产出一堆看似能跑、实际不一定好用的东西。
你给它明确目标、真实客户反馈、清晰测试标准、完整上下文，它才可能像一个可靠的生产系统。
所以软件工厂的本质，不是 AI 自动写代码这么简单，它要求公司先把产品开发过程变得更清楚。
中层管理最先被重新定义
我认为这期播客里最有冲击力的部分，是她对组织结构的判断。
Diana Hu 认为，如果公司已经足够可查询，信息都能被 AI 读取和分析，那传统中层管理的很多价值会下降。
更准确地说，是很多管理动作会被系统拿走。
过去中层管理做什么？
收集信息，整理信息，开会同步，判断优先级，向上汇报，向下分配，协调资源，提醒进度。
这些动作的核心，其实是信息路由。
公司越大，信息越复杂，就越需要人站在中间转发、压缩和解释。
但如果 AI 能持续看到公司里的真实工作状态，很多信息路由就不需要靠人一层层传了。
传统层级组织本质上是为了解决信息协调问题。
现在 AI 第一次有机会维护一套持续更新的公司运行模型，并承担过去由管理层级完成的信息协调功能。
也就是说，AI 不只是提高效率的工具，而是一个能理解公司运转、协调工作流的系统。
以后公司里可能会更强调三类人：
第一类是直接做事的人。
不只是研发，销售、运营、客服、市场都要能直接使用 AI 工具，把想法做成东西。
以后开会不应该只带 PPT，而是带原型、带数据、带已经跑起来的方案。
第二类是对结果负责的人。
这个人不是传统主管，不是每天盯大家进度的人，而是对一个明确结果负责。比如某个客户增长指标、某条产品线、某个交付结果。
责任要清楚，结果要可衡量，不能藏在层级后面。
第三类是 AI 原生的创始人或负责人。
这类人不能只在嘴上说重视 AI，然后把 AI 战略丢给下面的人。
他自己要用，要试，要知道工具能做到什么程度，也要让团队看到新的工作方式到底长什么样。
这对创始人要求很高，因为 AI 原生公司不是买几个工具就能建成的。
它需要创始人亲自改变公司怎么开会、怎么写需求、怎么记录信息、怎么评估结果、怎么招人、怎么设岗位。
如果老板自己还按旧方式工作，公司很难真的变成 AI 原生。
未来拼的可能不是人头，而是 token
Diana Hu 在播客里有一个说法很有意思：公司应该最大化 token 使用，而不是最大化员工人数。
这句话换成更直白的话，就是：
以后公司要敢于把钱花在模型调用和自动化系统上，而不是一有事情就加人。
过去公司 API 账单太高，老板会紧张。
但如果这些调用替代的是一个更大的工程团队、设计团队、运营团队、行政团队，那高 API 账单未必是坏事。
它可能说明公司正在用系统能力替代一部分组织膨胀。
这对早期公司尤其重要。
创业公司最怕的不是人少，而是人多以后动作变慢。
人一多，会议变多，沟通变多，管理变重，很多精力消耗在同步和协调上。
AI 原生公司的理想状态，是用更小的团队完成更大的产出。
这不是简单地压缩人力成本，而是改变资源配置方式。
以前你要做一个功能，可能要产品、设计、前端、后端、测试、项目经理一起排期。
现在一个会用 AI 的人，可能先做出可运行原型，再让系统补代码、跑测试、生成文档、整理反馈。
团队当然还需要人，但人的数量和结构会变。
少一些纯传话、纯协调、纯整理的人；
多一些能定义问题、调动工具、判断结果、直接推进业务的人。
这件事对很多公司会很难，因为它不只是工具升级，而是岗位价值重估。
大公司很难，小公司反而有机会
Diana Hu 最后讲到一个很重要的判断：早期创业公司在这件事上有天然优势。
原因很简单，大公司有历史系统，有组织惯性，有几千几万人要培训，有已经跑了很多年的流程。
任何一个核心流程改动，都可能影响现有业务。
所以大公司即使用 AI，也经常只能先从局部开始：某个团队试点，某个流程自动化，某个部门上工具。
但早期公司没有这些包袱。
一家公司刚开始，就可以把所有工作流按 AI 原生方式设计：
会议怎么记录，客户反馈怎么进入系统，研发任务怎么和销售信息打通，所有结果怎么沉淀，AI 智能体怎么参与日常工作。
这件事越早做，越容易。
如果公司已经有 500 人，再想让大家少用私聊、多留记录、所有流程可查询、所有决策有反馈，难度会非常高。
如果公司只有 5 个人、10 个人，从第一天就这么干，反而很自然。
所以 AI 原生公司最早出现的地方，很可能不是大公司的转型部门，而是新一代创业公司。
它们没有老系统要维护，没有复杂层级要安抚，也没有太多“以前我们都是这么做的”。
它们可以直接用新的方式搭公司。
这件事对普通公司也有启发
这篇内容虽然讲的是创业公司，但对很多普通公司也有参考价值。
不管你是不是 AI 公司，接下来都要面对一个问题：
公司的经验，到底沉淀在人身上，还是沉淀在系统里？
如果一个客户为什么成交，只有销售知道；
如果一个产品为什么延期，只有项目经理知道；
如果一个需求为什么被砍，只有老板记得；
如果一次失败为什么发生，没人记录，也没人复盘；
那这家公司再买多少 AI 工具都没用。
因为 AI 没有上下文。
它不知道公司发生过什么，也不知道过去哪些判断对、哪些判断错，更不知道下一次应该怎么改。
真正要做的是把公司变成一个能被理解的系统：
重要事情尽量留下记录；
关键过程尽量形成结构；
客户反馈尽量进入统一系统；
决策和结果尽量能对应起来；
让 AI 不只是帮你写东西，而是能读懂你的业务。
这一步很基础，但也很难，因为它要求公司改变很多习惯：
少一点口头同步，少一点私聊决策，少一点只靠人脑记忆，多一点过程记录，多一点结果反馈，多一点系统沉淀。
AI 原生公司，听起来像一个很新的概念，但落到执行上，其实就是一件事：
公司每天产生的经验，不能再白白流失。
AI 原生公司的核心，是重新分配人的位置
AI 对公司的影响不只是写代码、写文案、做客服。
它会影响公司怎么流动信息，怎么做决策，怎么分配责任，怎么定义岗位，怎么判断一个人有没有价值。
过去，公司靠层级组织人。
以后，公司可能靠智能系统组织信息，再让人站在更靠近业务和客户的位置上。
这会带来一个很明显的变化：
公司不再奖励“我知道很多信息，所以我有价值”。
公司会更奖励“我能定义问题、推动结果、判断质量，所以我有价值”。
这对很多人是不舒服的。
因为过去很多岗位的安全感，来自信息差、流程控制和协调位置。
AI 把信息打平以后，这些位置会变薄。
但对真正能做事的人，这是机会。
一个销售可以带着 AI 做客户研究、生成方案、跟进线索、复盘成交。
一个运营可以搭自动化流程、监控数据、发现异常、推动改进。
一个产品经理可以直接做原型、写规格、跑测试、整理反馈。
一个工程师可以同时调动多个智能体写代码、查问题、补测试、做验证。
每个人的边界都被打开了。
但前提是，公司要允许这种变化发生。
如果公司还是老流程、老汇报、老审批、老层级，AI 只能变成一个更快的文档工具。
如果公司愿意从底层重做，AI 才可能真的变成新的组织能力。
这也是 Diana Hu 这期播客真正想说的事：
AI 原生公司，不是把 AI 加进公司，是用 AI 重新搭一家公司。
