Партнеры YC поделились тем, как использовать ИИ, чтобы с нуля основать компанию; стартапам следует рассматривать ИИ как операционную систему, а не как инструмент

AI 对新创公司的影响，已经不仅仅是让工程师写代码更快、让客服流程自动化，或是在既有产品里加上一个 Copilot。YC 合伙人 Diana 近日指出，真正的变化在于，AI 正在改写「一间公司应该如何从零开始被建立」。对早期创办人而言，AI 不应该只是公司偶尔使用的效率工具，而应该从第一天开始，就被设计成整间公司的作业系统。

生产力视角已经过时，AI 正在改写公司的设计起点

Diana 认为，目前市场谈 AI 时，仍太常停留在「生产力提升」的框架，例如工程师可以更快写代码、团队可以自动化更多流程、公司可以推出更多功能。但这说法其实低估了 AI 带来的结构性改变。她指出，正确的人搭配 AI 工具，现在可以打造过去需要一整個团队才能完成的功能，甚至能开发过去根本不可能完成的产品。

因此，创办人真正要问的问题，不是「公司哪些流程可以加上 AI」，而是「如果今天从零开始建立公司，哪些工作原本就不该经由人力层层处理？」

这也是所谓 AI-native 公司的核心。Diana 表示，AI 不应被放在公司流程之外，像外挂一样提高某些部门效率；相反地，公司每一个工作流程、每一个决策、每一个重要动作，都应该流经一层会持续学习与改善的智慧系统。

换句话说，未来的新创公司不是先建立组织图、部门、会议流程与管理制度，最后再导入 AI，而是从创立第一天起，就把公司设计成一个可被 AI 理解、查询、分析与自我改善的系统。

第一步：把整间公司变成可被 AI 查询的智慧中枢

在这个框架下，建立公司的第一步，是让整个组织变成「可被查询」。传统公司里，信息往往散落在会议、私讯、电子邮件、文件、CRM、GitHub、客服系统与主管脑中。

这会让公司变成一个开环系统：创办人做出决策、团队执行任务，但结果是否有效、问题出在哪里、下一步该如何调整，往往依赖人工回报与主管解读。Diana 认为，这种模式天然会造成信息流失，也会拖慢公司速度。

AI-native 公司则必须改成闭环系统。每一次会议、每一张工单、每一次客户反馈、每一个产品决策、每一次销售通话与每一轮工程交付，都应该产生可被 AI 读取的记录，并回馈到公司的智慧层中。

Diana 建议，新创公司应该录下重要会议、使用 AI 笔记工具、减少藏在 DM 与 email 里的信息，并在 Slack、Linear、GitHub、Notion、Google Docs、客服工具、销售电话与营运数据中嵌入 Agent。公司真正要打造的不是一堆分散工具，而是一个能即时回答「现在公司到底发生什么事」的智慧中枢。

从工程管理看实例：Sprint 时间砍半、产出接近 10 倍

她以工程管理为例说明，如果一个 Agent 可以读取 Linear 工单、Slack 工程频道、GitHub、客户邮件、Pylon 这类客服工具、Notion 或 Google Doc 里的高阶计划、销售通话与每日站会记录，它就不只是帮忙整理会议摘要，而是能分析上一個 Sprint 到底交付了什么、交付结果是否真正满足客户需求，以及哪些功能虽然做完了，却没有产生预期效果。

当这些信息都能被 AI 连接起来，Agent 就能进一步提出下一轮 Sprint 计划，让工程规划更准确、更可预测，也更贴近市场需求。这代表新创公司从零建立时，不应该先复制大公司的工程管理制度。过去工程主管需要花大量时间搜集状态、整理进度、向上汇报，是因为公司内部信息不透明，需要人类不断搬运与解读。

但如果公司从一开始就把所有关键流程设计成可查询，许多传统中阶管理任务就会失去必要性。Diana 指出，她已经在多家 YC 公司看到类似做法，有些团队因此把工程 Sprint 时间砍半，并在相同时间内接近做到 10 倍产出。

第二步：用 AI 软件工厂重新定义谁在写代码

第二步，则是用 AI 软件工厂重建产品开发流程。Diana 认为，AI-native 公司不该只把 AI 当成工程师旁边的代码助手，而应该重新定义「谁负责写代码」。

在新的产品开发模式中，人类主要负责撰写规格与测试，定义成功标准；AI Agent 则负责产生实现、撰写代码、反复测试与修正，直到结果符合规格。人类的角色变成定义问题、判断结果与校准方向，而不是亲自完成每一行代码。

这种模式可以理解为测试驱动开发的下一阶段。过去 TDD 是人类先写测试，再由人类撰写代码通过测试；AI 软件工厂则是人类写下规格与测试框架，让 Agent 自行产生代码并迭代。

Diana 提到，有些公司已经把这套做法推到极致，代码库中几乎没有人工手写代码，而是由规格、测试与情境验证驱动 AI 完成实现。这也是所谓「1000 倍工程师」的真正含义：不是一个工程师突然变得比别人努力一千倍，而是一個工程师背后有一整套 Agent 系统，使他能完成过去整个团队才能完成的工作。

第三步：重新设计第一批员工，只留三种人

因此，如果要用 AI 从头建立公司，创办人要重新思考第一批员工的定义。Diana 引用 Block 创办人 Jack Dorsey 的看法指出，如果公司只是把 AI 工具加进原本的组织图，却保留旧有管理层级与信息流路径，就会错过真正的转变。

未来公司不应该建立大量「人类中介」，让信息在主管、协调者、项目经理之间层层传递；相反地，公司应该被设计成一个智慧层，由 AI 承担信息整合与流动，人类则站在边缘负责判断、创造、决策与承担结果。在这样的公司里，员工角色会变得更少、更清楚。

第一种是个人贡献者，也就是 builder-operator，不只工程师要能建造，营运、客服、销售也都应该能利用 AI 做出原型、流程或自动化系统。

第二种是 DRI，也就是直接负责人的人，这不是传统经理，而是对某个明确结果负责的人，一个人对应一个结果，不能躲在流程或部门背后。

第三种则是 AI founder type，也就是创办人本人必须亲自站在最前线使用 AI，示范什么叫能力被放大，而不是把 AI 策略交给某个「AI 负责人」处理。

创办人要最大化的不是员工数，而是 token 使用量

这也带出 AI-native 公司最反直觉的一点：未来创办人要最大化的可能不是员工数，而是 token 使用量。Diana 认为，新创公司应该愿意承担高得令人不舒服的 API 帐单，因为这些支出取代的是过去更昂贵、更臃肿的人力成本。一个熟练使用 AI 工具的人，可能完成前 AI 时代一整支工程、设计或营运团队的工作。

因此，从零开始建立公司的创办人，不应该把「快速扩编」视为成长象征，而要问：有哪些工作可以透过 Agent、流程闭环与软件工厂处理，而不是再招一个人？

这对早期新创公司尤其关键，因为小公司没有历史包袱。大公司要转型 AI-native，必须一边维持既有产品，一边拆除多年累积的 SOP、管理制度、内部政治与旧技术栈；每一次流程调整都可能破坏原本还能运作的系统。

早期新创则没有这些限制，可以从第一天开始把会议、工程、客服、销售、招聘、营运与产品开发，全都设计成 AI 可读、可查询、可反馈的结构。Diana 认为，这正是新创相对于大型企业的重大优势。

未来的创业门槛，是能用 AI 重新发明公司

因此「如何用 AI 从头开始建立公司」的答案，不是把 ChatGPT、Claude、Cursor、Devin 或各种 Agent 工具塞进现有流程，而是反过来重新设计公司本身。

创办人应该先建立一个可查询的组织，把所有重要信息变成 AI 能读取的脉络；再建立闭环流程，让决策、执行与结果持续回馈；接着用规格与测试驱动产品开发，让 Agent 负责大量实现；最后，用更少但更强的 builder-operator、DRI 与 AI founder type 组成团队。

Diana 的观点指向一个更激进的结论：AI 时代的新创公司，不会只是「同样的公司，但效率更高」。真正的 AI-native 公司，会从组织、流程、产品开发、角色分工到成本结构都不同。

它不是用 AI 帮公司跑得快一点，而是从一开始就把公司设计成一套会学习、会回馈、会自我改善的智慧系统。对创办人来说，这可能是未来几年最重要的创业门槛：不是会不会使用 AI，而是能不能用 AI 重新发明公司本身。

这篇文章 YC 合伙人分享如何用 AI 从头开始建立公司，新创应将 AI 当作作业系统而非工具 最早出现于 链新闻 ABMedia。