YC 合夥人分享如何用 AI 從頭開始建立公司，新創應將 AI 當作業系統而非工具

Neo

2 小時前

AI 對新創公司的影響，已經不只是讓工程師寫程式更快、讓客服流程自動化，或是在既有產品裡加上一個 Copilot。YC 合夥人 Diana 近日指出，真正的變化在於，AI 正在改寫「一間公司應該如何從零開始被建立」。對早期創辦人而言，AI 不該只是公司偶爾使用的效率工具，而應該從第一天開始，就被設計成整間公司的作業系統。

Table of Contents

生產力視角已經過時，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 認為，這正是新創相對於大型企業的重大優勢。