YC合伙人：如何利用AI打造一家自我进化的公司丨Y Combinator

YC合伙人：如何利用AI打造一家自我进化的公司丨Y Combinator YC合伙人：如何利用AI打造一家自我进化的公司丨Y Combinator Modified June 23 🔗 原文链接： https://mp.weixin.qq.com/s/vHdcnz6c... 原创 Capihom Capihom 晚点再听LaterCast2026年6月22日 22:00 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "烧 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 No access 5cbb6261de844849957e522be75631ef 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ https://mp.weixin.qq.com/s/vHdcnz6c... 🔗 原文链接： https://mp.weixin.qq.com/s/vHdcnz6c... https://mp.weixin.qq.com/s/vHdcnz6c... 原创 Capihom Capihom 晚点再听LaterCast2026年6月22日 22:00 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "烧 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 No access 5cbb6261de844849957e522be75631ef 00:00 No access 5cbb6261de844849957e522be75631ef 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣