夜雨聆风我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听晚点再听LaterCast
"烧 token，不要烧 headcount。"
"中层管理结束了。"
"被记录下来，才算发生在 AI 里。"
这期 Y Combinator 的 batch talk，由 YC General Partner Tom Blomfield 主讲。他没有把 AI 讲成一个提高效率的插件，而是把问题直接推到公司形态：如果 AI 能读取公司的知识、调用工具、观察结果、改写流程，一家公司还需要像过去那样靠层级、会议和中层管理来传递信息吗？这期对话最适合正在搭团队、管产品、做内部系统的人读。它谈的重点不在多装一个 Copilot，重点在公司如何把自己改造成一个会学习的系统。
公司还在像罗马军团传话
Tom 用罗马军团开场。古罗马需要从中心向边境投射力量，于是设计出层层嵌套的等级结构，每个人有明确的控制范围，命令向下传，情报向上传。他说，大多数现代公司仍在使用同一套结构：人是信息的管道，经理负责把现场翻译成上级能读懂的汇报，再把上级判断拆成团队能执行的任务。AI 进入公司后，被打破的正是这条人肉信息链。如果知识可以被系统读取，决策可以被工具执行，反馈可以自动回流，层级结构就不再是唯一的组织方式。
"今天大多数公司仍像罗马军团一样组织，人类负责让信息上下流动。"
他引用 Jack Dorsey 近期关于层级公司的思考，指向同一个假设：经济单位必须按金字塔组织。Tom 的判断更激进，AI 会让公司从“人传人”的结构，转向“系统读系统”的结构。老板、经理、员工之间的传声筒价值开始下降，能把业务变成上下文、工具和反馈循环的人，反而会变成新公司里的核心节点。
Copilot 只是旧机器的新引擎
一年前，很多人谈 AI，喜欢说工程师用了 Copilot 以后效率提升 20% 或 30%。Tom 认为这种想法太保守。它相当于把更强的引擎装到旧机器上：流程仍旧由人发起，任务仍旧由人分配，反馈仍旧靠会议和文档回传。AI 的大机会，不在于让原来的岗位快一点，而在于重新定义公司如何感知、判断和行动。
"把 AI 当成提高 20% 生产力的工具，是一种坏的思考方式。"
他举了一个很具体的标准：Garry Tan 现在可以生产出超过一个工程团队的代码量。若公司只是让每个工程师多写一点代码，得到的是线性收益；若公司把业务知识、权限边界、质量检查和部署动作连接起来，得到的会是循环收益。后者会持续改进，前者只是在旧流程里多踩一脚油门。
先把公司知识从人脑里拿出来
Tom 反复强调一个词：domain knowledge。公司的商业知识通常散落在创始人脑子里、Slack 消息里、邮件里、Notion 文档里、客服记录里。员工凭经验知道怎么处理客户、怎么判断优先级、怎么把一个需求变成代码。AI-native 公司的第一步，是把这些隐性的 know-how 提取出来，变成 AI 能读取的上下文、技能文件和工具说明。
"公司里的领域知识，藏在人、Slack、邮件和 Notion 里。"
这一步听起来像知识管理，实际更接近公司操作系统重写。传统知识库是给人查的，AI-native 的上下文是给系统执行的。比如“怎样给某个创始人介绍石化行业的人”，在旧流程里需要合伙人凭记忆和关系网搜索；在新流程里，AI 需要能查询数据库、读取历史 office hour、调用 RAG、筛出五个相关创始人，再把结果交给人确认。
放到普通公司里，同样可以从一个很小的流程开始。销售团队可以先把客户异议、CRM 字段、成交邮件和报价规则整理成上下文；产品团队可以先把用户访谈、路线图、客服反馈和埋点数据放到同一套可查询结构里；工程团队可以先把代码规范、故障记录、review 规则和部署权限写成 skills。业务知识一旦能被 AI 读懂，岗位经验才会变成系统能力。
AI loop 要能自己闭环
Tom 把一个可运行的 AI loop 拆成五层。第一层是 sensor，来自客户邮件、支持工单、代码变更、退订行为、产品 telemetry。第二层是 policy，规定哪些事可以直接做，哪些事必须请人批准，哪些动作必须记录。第三层是 tool，包含查询数据库、读取日历、调用内部 API 这类确定性能力。第四层是 quality gate，包括 eval、规则检查、安全过滤和高风险人工审核。第五层是 learning mechanism，系统观察执行结果，把失败重新喂回前面。
"系统接触真实世界，发现哪里失灵，再回到循环开头。"
判断一家公司是否 AI-native，不看它用了多少聊天框，而看它有多少业务环节能完成这种闭环。如果销售漏斗摩擦高，agent 能不能查产品数据、研究最佳实践、生成 A/B test、跑一周、选胜出版本并部署？如果客服建议涌入，agent 能不能像 CPO 和 CTO 一样判断哪些进路线图、哪些丢弃、哪些可以当晚写代码上线？这些场景才是 Tom 眼里的新公司形态。
很多团队的第一反应会是买一个更强的 agent 平台。Tom 的顺序更务实：先选一个边界清楚、数据充足、失败成本可控的循环。比如激活率优化、客服分类、内部知识问答、销售线索整理、代码库索引。系统能看见输入，能调用工具，能通过 eval 或人工审核过关，能把失败案例写回规则库，这个 loop 就可以持续变厚。
YC 的系统已经会夜里修自己
他讲了 YC 内部已经上线的一个例子。最早，他们有一个 agent，可以回答“我上次和这家公司 office hour 是什么时候”。后来它能根据正在辅导的公司需求，查询数据库，找出几个适合介绍的创始人。到这里，它仍只是 group partner 的 sidekick，让人提升 20% 或 30%。真正让 Tom 感到震动的是 monitoring agent。
"当人第二天再问同一个问题，它已经会成功。"
这个 monitoring agent 会看每个 YC 员工的查询，记录哪些成功、哪些失败。失败时，它会继续追问原因：缺少确定性工具吗？skills 文件要更新吗？数据库不够吗？需要新索引吗？Tom 说，现在这些事可以在夜里发生：写代码、提交到 YC codebase、让 agent review、合并、部署。第二天人类回来问同一个问题，系统已经变好了。这才是“自我改进公司”的含义。
烧 token，不要烧 headcount
Tom 给创业公司的第一条经营含义很直接：burn tokens, not headcount。YC 看到的现象是，最近的 Demo Day 公司，相比 18 个月前，每个员工带来的收入大约高了 5 倍。他判断，这个趋势会延续到 Series A 和 Series B。未来公司扩张时，约束项更可能是 token 使用量，而非员工数量。
"很快，你会被 token 使用量限制，而不是被 headcount 限制。"
他也提醒，粗暴衡量每个人的 token usage 会被游戏化，不能变成晋升或淘汰的单一排行榜。但在当前阶段，观察谁在组织里 token maxing，谁还没有用足这批新智能，仍能帮助管理者判断时间该花在哪里。重点不该落在考核上，应落在找出哪些员工已经开始把工作拆成 AI 能执行的循环。
这对招聘和预算也会产生影响。过去一个新需求出现，公司常见动作是加一个人、建一个小组、再安排一个 manager 协调。现在更合理的问题变成：这件事能否拆成传感器、规则、工具、质检和学习机制？如果可以，优先投入 token、上下文整理和自动化工具。人力预算不再是第一反应，组织设计会先问“能不能让系统跑起来”。
中层协调正在被系统吞掉
这期最锋利的判断，是 Tom 说 middle management is done。他并非说公司不再需要负责人，而是说中层管理过去承担的协调问题，正在被 AI 接管。信息收集、状态同步、任务拆解、跨团队跟进、汇报整理，这些工作原本需要很多经理在组织中间传递。AI loop 一旦能读取数据、调用工具、写代码、跑检查、部署结果，协调层会被大幅压缩。
"我不认为你还需要中层管理来解决协调问题。"
他留下的组织角色更少：IC、builder、operator，以及直接负责某件事的 named human。责任不交给委员会，也不交给一群模糊的人，而要落到一个清楚承担责任的人身上。新组织里，人不再靠占据层级来产生价值，而靠定义目标、设置边界、审查高风险动作，并在现实世界里承担责任。
这不等于公司不需要管理。管理会从“盯人和同步状态”，转成“设计系统边界”。谁能批准退款，谁能改生产数据库，哪个 agent 能开 merge request，哪些改动必须有人审，哪些客户场景需要真人介入，这些规则仍需要人来定。中层消失的部分，是靠人把信息搬来搬去的协调层；留下来的部分，是对目标、风险和责任的判断。
公司大脑要先记录一切
如果要建自我改进公司，Tom 的第一步非常朴素：make the entire organization legible to AI。YC 现在把 partner 邮件放进数据库，Slack 消息、DM、office hour 也开始记录。过去三四个月，他们已经积累了约 2000 小时 office hour 录音。原因很简单：AI 无法学习没有被记录的业务。
"如果没有被记录，就没有发生在你的智能里。"
记录还不够，100000 小时录音不能直接塞进上下文窗口。YC 的做法是先 diarize，再聚合、压缩、分类，把内容变成 AI 能追踪的 breadcrumbs。Harj 最近用 3 个月约 2000 小时 office hour 录音，重新生成了一份 150 页 YC user manual。旧手册写于 5 到 10 年前，很多地方已经过时；新手册可以每个月更新，把新的建议和旧内容比较后纳入或丢弃。公司知识开始变成 living brain。
记录一切也会带来治理问题。客户隐私、员工边界、敏感决策、高情绪场景都不能粗暴扔进一个数据湖。Tom 的意思很清楚：公司不该变成监控机器，关键业务过程要留下可用痕迹。会议纪要、客户需求、产品判断、代码修改、失败查询，都要能被检索、压缩、归档和更新。AI 能学到什么，取决于公司愿意把哪些经验沉淀成结构。
软件会变轻，业务上下文变重
Tom 还提到一个很反常识的变化：内部软件正在变成可抛弃品。他原本想说每个职能都该有 dashboard，后来改成 on-demand software。Codex 这类工具已经能 one-shot 很多简单内部软件和仪表盘。运营团队坐在公司知识层上，为当下的活动、流程、项目生成自己的工具，用完以后可以扔掉；模型一两个月后更强，再用原始指令重新生成一版。
"珍惜所有数据，把软件当成临时层。"
在这种结构里，贵的部分不在 dashboard，也不在某套内部系统代码，而在“我们如何跑 YC event”“我们如何处理 co-founder dispute”“我们如何判断 founder introduction”这类业务上下文和 skills。软件只是这些知识上方的一层临时界面。模型越强，公司越应该保存原始数据和业务语义，不要迷恋一套固定后台。
这也会改变产品经理和内部工具团队的工作方式。过去要排期、写 PRD、找工程师、等版本；未来更多内部软件会从一次明确的任务说明开始生成，服务某个活动或某个流程，完成后随时重建。人的工作会更多落在描述业务、定义约束、检查结果、沉淀 skills，而不是维护一堆越来越旧的后台页面。
写在最后
Tom 最后问创业者：如果今天重新建公司，你还会把它做成现在的形状吗？小团队反而更有机会从第一天把邮件、客户反馈、代码、会议和决策变成 AI 可读的公司大脑。先从一个业务 loop 开始，把感知、决策、工具、质检和学习机制接起来，公司会慢慢长出新的组织形态。
内容来源："How to Build a Self-Improving Company with AI"丨Y Combinator（嘉宾：Tom Blomfield）
原视频：https://www.youtube.com/watch?v=X_JsIHUfUjc
如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣
⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣
