Đối tác YC chia sẻ cách sử dụng AI để bắt đầu xây dựng một công ty từ con số không, và các startup nên xem AI như một hệ điều hành chứ không phải một công cụ

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。