Anthropic創始人行動手冊：打造一家AI-Native創業公司（附36頁中文PDF）

ANTHROPIC · 2026.05

創始人行動手冊

The Founder's Playbook

打造一家 AI-Native 創業公司

花叔 x Claude Code 譯

這本《創始人行動手冊》是 Anthropic上周發布的官方手冊，原版 36 頁。從Anthropic產品兩天一小版，每周一大版的更新節奏來說，我覺得他們是這個時代最AI Native的大公司了。這本手冊里融入了不少他們內部的經驗以及他們所服務的最先進的AI native初創公司的做法。看完之后覺得它把AI 時代怎么創業這件事講得還挺清楚的。

所以我燒了幾百萬 tokens，讓 Claude Code 替我把全本譯成中文，并按原版結構 1:1 重新排版。本文是面向公眾號閱讀的線性長文版，約 22000 字。如果你想要排版精美的橫版 PDF，文末有下載入口。

本譯本僅供個人學習與內部研究使用，不做商業發行。原版下載請到 claude.com/blog/the-founders-playbook。

目錄

01創業生命周期，為 2026 重新啟動

02「創始人」這件事正在改變

03想法階段

04MVP 階段

05發布階段

06規模化階段

07工作沒變，規則變了

08Resources

Chapter 1

創業生命周期，為 2026 重新啟動

創業生命周期，為 2026 重新啟動

AI 正在重塑創業公司的搭建方式。今天，從未寫過一行代碼的創始人正在把生產級應用交付給用戶，「10 人獨角獸」也從草根逆襲故事變成了一份可以認真執行的行動方案。

到 2026 年，AI 可以寫生產環境代碼、做市場調研、梳理競爭格局、起草投資人材料，并把運營流程自動化跑起來。過去那條很陡的學習曲線被它抹平了。即便是經驗豐富的技術創始人，以前也得花大量時間去整合工具、平臺和系統，才能把想法落地。AI 最大的貢獻，是把「誰能開一家創業公司、誰能做出一款產品」這件事拉到了同一條起跑線上。

2026 年，一個好想法能把創始人帶得比以往任何時候都更遠。Agentic 編程（agentic coding）把過去需要一整支工程團隊才能完成的活，壓縮成了創始人一個人就能交付的體量。

傳統的創業增長曲線，默認路徑是：驗證 → 融資 → 招人 → 搭建 → 再融資 → 增長 → 繼續招人 → 循環往復。現在，AI 已經打破了一個默認預期：創業生命周期里每進入一個新階段，就必須配上更大的團隊、不同的技能組合和新一輪融資。

這本手冊會按照這些新現實，重新畫出創業旅程的四個核心階段：想法、MVP、發布、規模化。我們會逐階段來看：當 AI 成為技術和組織發展的核心基礎設施時，每個階段長什么樣、該用哪些工具，以及走在前面的創始人如何用這些工具把時間線壓短。如果你想規劃從想法到 exit（退出，指被收購或上市）的最短路徑，請繼續往下讀。

Chapter 2

「創始人」這件事正在改變

「創始人」這件事正在改變

過去，創始人是被「能做什么」定義的：技術型創始人寫代碼，非技術型創始人跑業務、談合同。但 2026 年創始人手上的模型、系統和 AI agent，已經把「能造東西的人」和「有想法值得造的人」之間那堵墻拆掉了。

AI-Native 創業公司正在從根上改變「當創始人」這件事的含義。現在，一個完全沒有工程背景的人，能做出真正能跑起來的生產級軟件，把自己的想法落地；而一個技術很強但商業上經驗不多的創始人，也能輕松產出 GTM 策略、財務模型和高度打磨的 pitch deck（融資演示文稿）。

過去，創始人大部分時間都在執行模式里：寫代碼、管人、處理日常運營。在 AI-Native 創業公司里，創始人不再只是個人貢獻者，而更像是一群 agent 的編排者（orchestrator）。這些 agent 是專門化的 AI 助手，能讀文件、跑命令、執行代碼，甚至瀏覽網頁。創始人的注意力開始往上走，轉向更高階的工作：產生想法，然后指揮這些 AI agent、工具和小團隊把想法跑出來。

AI 作為核心基礎設施最革命性的影響，是把那些有領域專長但沒有工程背景的創始人也解鎖了出來。當創始人這個群體不再只來自工程背景，你會看到由完全不同人生經驗的人創辦的公司，去解決傳統技術創始人通道從未優先關注，甚至從未注意到的真實問題。

AI 為精益創業帶來的能力

傳統創業模型假定你必須招工程師來造、招銷售來賣、招運營來跑公司。「人頭數」被當作組織勢能和產品成熟度的信號。

2026 年的早期創業公司則完全不一樣。它們從設計上就極度精益，往往只有創始人一個人，或者再加上少數幾位伙伴。把技術和組織發展都建立在「AI 即基礎設施」之上，它們可以在擴張團隊之前，就跑通產品驗證、做出早期收入，甚至實現盈利。AI 在三個地方能讓一家創業公司像大得多的組織一樣運轉：研究、Agentic 編程，以及把關鍵業務運營做成工作流自動化。

對話式智能與研究

類比：任何領域隨叫隨到的專家

想一下，一個創始人在頭一年里幾乎肯定不懂但又必須搞清楚的那些事：工資系統怎么搭？產品開發的沖刺怎么排？一份緊湊的投資人備忘錄怎么寫？

早期創業的這類問題，過去答案幾乎都一樣：找個懂的人。對一個自籌資金或種子輪前的創始人來說，這意味著把本該用來搭東西的時間花在打聽上，或者把早期資金燒一截給顧問。現在，他們手里就有一個幾乎覆蓋所有領域、隨時在崗的專家：AI。

• 深度研究：

  競品分析、市場規模測算、財務建模

• 文檔起草：

  pitch deck、案例研究、投資人備忘錄、PRD（產品需求文檔）

• 戰略思考伙伴：

  反方代言人分析、事前剖析（pre-mortem）、情境推演、路線圖優化

Agentic 編程

類比：那位永遠在線、永不被卡住的工程師

過去要做出軟件，要么得有個技術合伙人，要么外包給開發公司，要么得有足夠長的跑道，先把一支工程團隊招齊，才能寫下第一行生產代碼。

Agentic 編程工具現在讓每一個有想法的創始人，都能用大白話描述自己想做什么，再指揮 AI 去生成、測試、調試、重構一份生產級代碼庫，速度和體量都不輸一支完整的工程團隊。

從「我有一個想法」到「我有一個產品」之間的時間線被壓短了。創始人現在聚焦的是「該做什么、為什么做」，而 AI 負責把面向真實用戶的那部分基礎設施真正搭起來。

工作流自動化

類比：一支隨叫隨到的自動化運營團隊

就算創始人能像顧問一樣做研究、像工程團隊一樣寫代碼，戰略規劃和產品開發之外還有一整類活必須有人來做：排期、更新 CRM、拉周報、維護文檔、發布內容、跟進合規要求、把公司賴以運轉的工具和系統之間的連接管起來。這些事一樣要發生。在精益創業公司里，這些活主要落在創始人自己頭上，會大量吃掉本該用于高階判斷的時間和注意力。

AI 工具的工作流自動化能把這筆稅卸掉。重復性的運營任務可以配置成自動跑：deal 狀態一變，CRM 就自動更新；周報自己匯總；產品文檔跟著產品改動同步更新。關鍵的一點是，Claude Cowork 能直接集成創業公司用的那一整套互聯系統，比如項目管理工具、溝通棧、數據源，不需要再有人專門去搭和維護這些集成。在第零天創業公司里，那個人幾乎總是創始人本人。

時機和編排，是一切

能把 AI 的研究、自動化和 agentic 編程能力真正用起來的創始人，可以用遠超團隊規模所暗示的杠桿來跑一家公司。他們也能把絕大部分時間和帶寬，留給那些真正重要的工作。

但這套東西不會自己跑。負責編排這些 AI 工具的創始人，得知道怎么用、什么時候用。本手冊接下來的部分，就是逐階段拆解 AI-Native 創業路徑上的目標和挑戰，以及在每個階段如何把 AI 工具用到位。

Chapter 3

想法階段

想法階段

每一位創始人都從同一個地方出發：一個讓你停不下來去想的問題。這是創業里想法撞上現實的階段。2026 年的創業成功，要求你具備一種紀律：證據不充分之前，不動手造。

這一階段的工作是研究、客戶發現、競品分析，以及對反證（disconfirming evidence）的誠實評估。所有這些都要發生在你讓 Claude Code 寫下第一行生產環境代碼之前。

想法階段·目標

在想法階段，創始人的核心目標是以研究為導向的驗證：在投入資源開始造之前，攢起扎實證據，證明一個真實問題確實存在，并且你提出的方案確實能解決它。

實務上，想法階段就是一系列問題，大致按這個順序回答：

• 這個問題真實、具體、足夠高頻，值得圍繞它做一家公司嗎？

• 到底誰有這個問題？這些人能構成一個市場嗎？

• 有沒有人在解決？如果有，他們怎么做的，做得多好？

• 一個真正解決這個問題的方案需要做到什么？我的想法做到了嗎？

這些問詢加起來，回答一個終極問題：這值不值得做？

所以說，先具體，再行動。「大家做報銷很頭痛」是觀察；「中型公司的財務經理每周要花 4 個小時以上核對報銷提交，因為現有工具不和會計軟件打通」才是一個可被測試的假設。

想法階段·退出標準

想法階段的退出條件，是找到問題-方案匹配（problem-solution fit）。你要在開始造解決方案之前，建立起質性證據，主要來自真實的人類對話，證明你正在為真實的人解決真實的問題。

當你能對以下三個問題都回答「是」，就可以離開想法階段了：

1. 這個問題真實且具體嗎？

   你必須能精確說出誰經歷這個問題、多頻繁、影響多嚴重、目前他們怎么處理。

2. 你的方案對應的是真實問題嗎？

   不是你最初假設的問題，而是驗證過程里浮現出來的那一個。兩者有時相同，但并不總是。

3. 你有足夠信號去開干嗎？

   這個階段你永遠不會有 100% 確定，而一味等待確定本身就是一種失敗模式。但你需要足夠多的質性證據，讓投入做 MVP 看起來是有理有據的決定，而不是一次信仰行動。

想法階段是創業旅程里最重要的工作發生的地方，因為最致命的錯誤就在這里釀成。現在搞錯一點，能很快把剛起步的事業帶偏。多數想法階段的挑戰，歸根到底都是前進速度超過了理解所能支撐的范圍。帶著思考和審慎前行的創始人，才能穩步推進。

把「造」誤當作「驗證」

挑戰：當技術障礙被移除，激情沖昏頭的創始人很可能跳過創業旅程里最重要的工作：驗證自己的想法是不是人們真正需要、也真正會用的方案。

即便在當下的 agentic 編程（agentic coding）時代之前，也有 42% 的創業公司失敗，是因為做了沒人想要的東西。如今像 Claude Code 這樣的 agentic 編程方案已經把「我有一個想法」到「我有一個產品」之間的距離大幅壓縮，這個失敗率只會繼續往上走。

現在確實是懷揣絕妙點子的創業者最好的時代。但一個看起來像產品的原型可以如此快速、輕松地搭起來，反直覺地，這恰恰給 AI-Native 創業公司帶來了真正危險的存在性風險。

直到不久前，造東西仍需要真金白銀的開發時間和預算，搭個最基本的原型通常都要幾個月。如今技術開發門檻基本消失，AI 讓創始人太容易直接跳進建造，完全跳過驗證它在真實世界里是否有用。

抵達問題-方案匹配，必須先驗證假設，再開始造。但許多首次創業者，甚至有經驗的創業者，都錯誤地以為 AI 能讓這一步短路，把流程改成：有想法 → 立刻造原型 → 把「原型存在」本身當作驗證。原型變成了「我的假設一開始就對」的理由，而那個假設到底是不是真的，從未被檢驗。

一個能跑的原型很容易被誤當作「我正在解決真實問題」的具體證據，但它不是。原型只是你和潛在用戶對話時一個有用的壓力測試道具。對話本身，才是真正的證據。

過早規模化

挑戰：當造東西既不費力又即時，你的執行速度可以遠遠超過業務真正需要的水平。

過早規模化的意思是：在還沒有真正驗證一條產品路徑值得投入之前，你就已經把自己鎖在這條路徑上。

這一直是創業殺手，但 AI 讓創始人更容易在毫無察覺時掉進這個陷阱。Agentic 編程助手太強大了，執行很容易跑在問題-方案匹配驗證之前，而你根本沒意識到自己已經偏航。

它會圍繞一個根本錯誤的前提，帶著同樣的熱情去生成、測試、調試、重構代碼庫。系統里的智能是你的。這一階段的最高指令是：讓你的判斷力始終走在建造之前，尤其是在建造如此快速、感覺如此輕松的時候。

客觀性喪失

挑戰：讓 AI 工具去找支持你既有看法的證據，它一定能找到。確認偏誤（confirmation bias）現在配上了一臺研究引擎。

確認偏誤一直是創業里的職業病：創始人天然對自己的想法充滿熱情。現在 AI 工具給確認偏誤加了很強的外掛。讓 AI 驗證你的創業想法，它能找出佐證；讓它估算潛在市場，它能找到讓 TAM（總市場/可服務市場/可獲得市場）看起來值得融資的數字。

AI 沿著你的方向走。這意味著一個不問難題的創始人，現在能比以往任何時候都更快構建出一套精致、看似研究充分的壞點子論據，自己還覺得是在做盡調。解藥還是同一個工具，只是方向反過來：AI 驗證一個想法有多徹底，壓力測試（pressure-test）一個想法就有多徹底。當研究和結構化對抗性思考浮現出反方證據、提示想法需要修正時，這就是 pivot（調整方向）的信號。

Claude 如何幫助想法階段的創始人

把你的 AI-Native 創業概念推過想法階段，常常讓人覺得漫長得沒頭。你是創始人，你只想動手造。但這個至關重要的啟動階段，本質上是一次研究和驗證練習，意思是先用那些幫你想得更嚴謹的工具，不要急著寫代碼。下面是如何跨 Claude 的三個產品面（Chat、Claude Cowork、Claude Code），盡快又盡職地走完想法階段。

Chat、Claude Cowork 還是 Claude Code：怎么選合適的 Claude 產品面

AI 讓創業者更快交付、自動化繁瑣工作流、在規模上運作。但你用哪一面，取決于手頭任務。

Chat適合無需離開當前 app 就能完成的快速交流：從一份密集的投資人備忘里抓一句話要點、在董事會前快速核查一個論斷、讀懂團隊一條很長的 Slack 串。

Claude Cowork適合真正需要時間的知識工作：從多個來源拉資料、整理之后產出完成品，比如文檔、deck 或電子表格。比如把一文件夾的客戶訪談紀要變成下次產品評審用的主題發現文檔；融資前把十幾家友商網站匯成一張競爭格局圖；或者一個周一早上的常駐任務，從你的工具里拉指標，把周度 KPI 簡報丟進共享文件夾。

Claude Code是給團隊工程師用的 agentic 編程環境：直接接入代碼庫、Plan Mode、git 集成、本地/IDE/沙盒云環境。精益團隊在不斷成長的代碼庫里交付功能、遷移 MVP 時期的遺留代碼、把原型推到生產，都在這里完成，不用等更多人頭到位。

如果你要做的是…

為什么這樣選

一個問題、一次改寫、一次快速頭腦風暴

Chat

快、對話式、無需配置

研究、分析，或基于你的文件和系統產出一份成型文檔

Claude Cowork

文件夾訪問、連接器、Skills、計劃任務

寫、測，或交付軟件

Claude Code

代碼庫訪問、diff、git、開發環境

三者底層是同一個 Claude；變的是它周圍的工作空間。

定義并壓力測試問題假設

你的領域專長和前期研究已經產生了一個假設。第一項工作，是把它打磨到真正可被測試。Claude 在這里特別有用，它會逼你具體：究竟誰有這個問題？多頻繁？多嚴重？他們目前怎么處理？任何不能精確回答這些問題的問題陳述，都還沒準備好被驗證。

練習：和 Claude 一起反復打磨你的問題陳述，直到它變成一個可被測試的假設。比如「合同審查耗時太長」沒什么意義；但「中型公司的法務團隊每個合同審查周期要花 3 天以上，因為修訂意見散落在郵件串里，而不是一份帶版本控制的文檔」就非常可測試。

下一步，讓 Claude 反過來論證你的想法，去找反證。這能浮現出負面市場信號、失敗的競品、用戶行為模式，以及那些被「支持性綜述」悄悄降權的結構性障礙。

目標是：在進入客戶發現之前，你已經拿最強的反方論據把自己的假設壓力測試過一遍。這樣，用戶訪談才會真正開放，而不是一次尋找確認的行動。

注：把 Claude 當作結構化的反方代言人來用，是 AI 創業生命周期每一個階段都成立的核心用法。

市場研究與競爭格局梳理 給競品大小定個位

創業公司有一種特有現象叫「競品忽視」（competitor neglect）：你太專注自己的愿景和執行，于是系統性低估了同一賽道里別人在做什么。所幸 AI 給了解藥：讓 Claude 為這個賽道里的某個競品寫出最有說服力的論證，說明為什么它會成功而你不會。

Claude 可以分析為什么對方的方法其實更好，為什么客戶會選他們，為什么你以為的差異化可能并沒有那么守得住。

練習：讓 Claude 按層級繪制你的競爭格局：直接競品、間接競品、潛在收購方，以及可能進入你所在賽道的相鄰玩家。然后讓它論證每一層為什么對你的成功構成真實威脅，而不是只列出最容易被你駁倒的那個版本。

市場研究

Claude Code 可以綜合公開可得的客戶反饋，浮現反復出現的抱怨和未滿足的需求。附加價值是：這等于在白嫖競品客戶的質性研究。

練習：讓 Claude Cowork 匯總關鍵來源里的競品評論，找出現有方案仍未解決的高頻抱怨。如果你的假設能解決其中一條或多條，這是問題-方案匹配的強信號；如果不能，也值得知道。

Claude Cowork 還能從密集的行業報告、分析師文檔和市場研究材料里提取相關信息和數字。這些干凈、合成后的輸入，會成為 Claude 后續分析工作的理想上下文。

練習：基于公開數據構建 TAM/SAM/SOM 模型，并壓力測試背后的假設。判斷市場是在擴張、整合還是成熟；這個背景會影響你對時機和差異化的判斷。再畫出買方格局：誰掌握預算，誰影響決策，他們是不是同一個人。

趨勢分析

最后，用 Claude 傾聽早期信號，判斷你是否在正確的時刻進入。追蹤那些已經在討論你這個問題的 subreddit 和 LinkedIn 群組，記下用戶描述問題時使用的原話。讓 Claude 找出曾經解決過類似問題的類比市場，提取哪些做法有效、哪些無效。浮現可能加速或威脅這個機會的監管、技術或人口趨勢。

練習：讓 Claude 找出三個可能在未來兩年顯著影響你市場的外部趨勢（監管、技術或人口都行），并判斷每一個分別是你具體假設的順風還是逆風。

注：本節的市場研究與競爭格局梳理不是一次性練習。你會在 MVP 和發布階段繼續發現、繼續演進思考，所以每當假設變化，都要重復這些練習。

規劃并設計客戶發現

你從潛在用戶對話里學到什么，取決于兩件事：你問的問題質量，以及你有沒有把這些問題問給對的人。Claude 特別適合幫你設計客戶發現，包括找誰聊、問什么，以及怎么理解聽到的內容。

找誰聊

一份精確的目標畫像，比一長串聯系人更有價值。畫像里要包括最可能強烈經歷這個問題的具體職位、公司類型、團隊結構和資歷層級。接著，識別這些人實際能在哪里被觸達：社區、活動、LinkedIn 群組、Slack 工作區。最后建立一個優先級框架，按他們離問題有多近，決定先觸達誰。

問什么

目標人群定義好之后，用 Claude 搭訪談框架：正確的問題、正確的順序，結構能浮現人們「實際做了什么」，而不是「以為自己會做什么」。新手創始人最常犯的錯，是問一個泛泛的未來式開放問題，比如「你會用這樣的東西嗎？」而不是追問相關的過去，比如「跟我講講你上一次處理這個問題的過程」。

Claude 也能指出你草稿里哪些問題在誘導受訪者、哪些太寬泛、哪些會產生噪音而非信號。它還能幫你設計追問，用來處理回避，或深入挖掘那些重要但含糊的答案。

如果你的假設涉及多個 persona（用戶畫像），Claude 也能為每一類設計不同的問題組。財務經理和 CFO 面對同一個問題的關系并不相同，單一訪談框架會把這種差異抹平。

練習：先手寫訪談問題，再讓 Claude 審。明確要它標出任何誘導性、面向未來、過寬，或容易引出「社會期許答案」而非真實答案的問題。然后讓它為訪談中最可能出現回避的兩三個時刻設計追問。

訪談后分析

每次對話后用 Claude 復盤：把筆記喂給它，讓它指出哪些確認了你的假設、哪些挑戰了它、哪些是真正出乎意料的。

收集一批訪談之后，把全部訪談筆記交給 Claude Cowork，讓它浮現反復出現的主題、矛盾，以及正反兩個方向最強的信號。再把合成結果帶回 Claude，讓它指出：你對數據的解讀，哪里可能是在把信息湊成你想聽到的樣子，而不是數據真正呈現的樣子。

練習：每完成五次訪談，就讓 Claude Cowork 綜合筆記并產出兩張清單：支持你假設的證據，挑戰你假設的證據。如果第一張清單明顯更長，讓 Claude 判斷這種不對稱是數據本身如此，還是你一開始就希望找到這些。

客戶觸達與排期

用 Claude Cowork 自動化「建立聯系人列表、跑觸達、安排用戶訪談」這些運營負擔。

Claude Cowork 可以基于你和 Claude 定義好的目標畫像（包括職位、公司類型、資歷層級），研究并整理出一份結構化的潛在客戶名單和已驗證的聯系方式。隨后批量起草個性化觸達郵件，讓每封都貼合對方的角色和處境。

回復進來之后，它通過 MCP 連接 Gmail 和 Google Calendar，管理郵件串、處理排期請求、把訪談放進日歷。流程繼續往后：Claude Cowork 按設定節奏生成跟進草稿（比如第七天跟進未回復聯系人），并在每一步完成時更新追蹤表，讓你始終知道每個潛在對象在 pipeline 里的位置。

練習：把驗證過的訪談目標畫像交給 Claude Cowork，請它建立潛在客戶列表、起草個性化觸達序列，并建好一張追蹤表（包含觸達狀態、跟進節奏、訪談完成情況）。然后讓它負責協調，你專注準備對話本身。

設計你的最終方案概念

你已經做完了驗證工作：問題真實存在，你知道誰有這個問題，也有一個被證據支持的方案概念。用 Claude 從各個角度去發展并挑戰這個方案概念：缺口在哪里？有哪些替代方案？這個方案要規模化成立，需要哪些條件？這是一個重要的現實檢查：這個設計真的對應了驗證過程揭示的那個問題，還是仍在對應你一開始以為的問題？

練習：把你的方案概念交給 Claude，讓它識別這個設計最依賴的三個假設。然后追問：每個假設要成立，必須哪些條件為真？如果任何一個假設不成立，后果是什么？

用 Claude Code 搭一個輕量原型

現在到好玩的部分：有了驗證過的假設和經過壓力測試的方案概念，你終于可以做點東西出來了。

這就是想法階段里 Claude Code 登場的時刻。哪怕你之前一直在小修小補，現在才是生成正式輕量原型的節點：用最小的產品面，把想法擺到真實的人面前，獲得真實反應。

你還不是在造一個真實世界產品，而是在做一份功能樣本，用于客戶和投資人對話。真實用戶觸碰到一個能實際操作的東西，會告訴你十幾次問題-方案訪談都告訴不了你的事。此前你是在證明這個問題真實存在；現在，你是在邀請潛在用戶來反應擬議中的方案本身。

練習：定義你的方案所依賴的那一個核心交互。讓 Claude Code 只做這一件事。做出來之后，把它放到五個來自已驗證目標畫像的人面前，請他們試用。這五次對話里學到的東西，將決定你是繼續往前造，還是回到畫板。

走到想法階段的盡頭，是 AI 創業賽跑里的一次大躍遷。因為你不再是在賭一個直覺，而是在對著證據執行。

接下來進入 MVP 階段。創始人的指導問題從「這值不值得做？」轉向「到底先造什么？」而 AI 的主要角色，也從研究伙伴切換為施工隊。

Chapter 4

MVP 階段

MVP 階段

不少創始人把 MVP 階段當成「開工建設」，但它本質上還是一次收集證據的過程。區別在于，這一階段你收集的是關于解決方案的證據，不再是問題本身：一群真實、可識別的人，是否覺得這個產品值得用、值得回頭再用、值得付費，甚至值得推薦給別人。

MVP 階段·目標

作為 AI-Native 創業公司的創始人，你的目標是把已經驗證過的問題，轉化成一款真實用戶愿意使用的可運行產品。它不是路線圖上所有功能都齊全的完整版，而是你想法里最小、最聚焦的那一次迭代：把真實方案擺到真實用戶面前，跑出 PMF（產品-市場匹配）的真實證據。

與此同時，你現在怎么做，決定了未來能做什么。所以 MVP 階段還有第二個同等重要的目標：跑得快，但不要背上那種會復利、等真實用戶大規模涌入時反過來纏住你的技術債（technical debt）。

第三，從第一天起就投入精力建設持久上下文，才能讓 AI 持續做你的放大器，而不是混亂的來源。在 AI-Native 創業公司里，你的代碼庫是你和 AI 一次次會話共同協作的對象，可讀性是地基。那些跳過規格文檔（spec）、架構決策和 CLAUDE.md 這類上下文文件的創始人，遲早會撞上一堵可預見的墻：每次新會話都要重新解釋一遍代碼庫，AI 生成的改動也會一點點偏離最初的愿景。

MVP 階段·退出標準

MVP 階段的退出條件，是 PMF 的真實證據出現：一個具體、可識別的用戶群體覺得產品有價值，愿意回頭再用（留存）、愿意付費（收入），或者愿意告訴別人（推薦）。

MVP 階段·挑戰

在 MVP 階段，創始人最關鍵的兩件事是速度和判斷力。挑戰在于：你能不能用對的方式做對的產品、做得足夠快，同時不抄那些日后會讓你付代價的近路。

Agentic 技術債（agentic technical debt）

挑戰：AI 幾乎抹平了過去那些控制代碼進入生產環境的天然瓶頸，速度因此被保證了。但當速度成為創始人在 MVP 階段唯一考慮的變量，他們就會積累起很難償還的技術債。

有些技術債在 MVP 階段是合理的，前提是規模化之前必須把它管住。這種債會逐步累積，可以慢慢還，也可以專門安排一個沖刺（sprint）清掉。但 Agentic 技術債不一樣，它會復利。

如果沒把規格和架構約束寫在 AI 能讀到的地方，每次會話都得從零推導一遍基礎決策，決策也會一次次發生架構漂移（architectural drift）。最后你會得到一個缺乏一致心智模型的代碼庫。不是因為某一塊代碼寫得糟糕，而是這些零件從一開始就沒被設計成能拼到一起。這是真問題，而且往往要等到很晚才暴露出來。

誤把假 PMF 當成真 PMF

挑戰：AI 工具能跑出亮眼的早期數據，但這些數字并不保證市場需要你的產品。

早期勢頭是創始人能經歷的最強心理體驗之一。經過數周甚至數月的驗證和克制開發之后，把產品發出去，會讓人覺得自己從一開始就是對的。

Agentic 編程工具能讓你比以往更快抵達這個時刻，但早期牽引（traction）不等于 PMF。發布期的熱度可能來自一些短暫因素：創始人的朋友、投資人其他被投公司的潛在買家，或者 Hacker News 上一個標題帶來的流量尖峰。可惜，這些都不能可靠預測第六周、第十二周，初始助推消退之后會發生什么。

零摩擦的范圍蔓延（scope creep）

挑戰：當開發幾乎不費力、近乎免費，總有一個很酷的功能可以加，或一個邊緣情況想處理。這種范圍蔓延弊大于利。

范圍蔓延一直是創業的風險。現在的區別是，過去抑制它的「強制函數」（也就是工程時間的真實成本），已經不再以同樣方式存在。加一個功能不再是一個沖刺，而是一個下午。

難點在于，每一項單獨的新增看起來都合理。產品當然應該處理那個邊緣情況，用戶當然會想要那個工作流。由于 agentic 編程讓每一項都很省力，當下并不像范圍蔓延。但當產品越過原始邊界開始攤大餅，你會失去方向和動量。

解藥是在動手前先寫下范圍定義：產品做什么、明確不做什么，以及來自真實用戶的哪種具體證據才足以證明應該加新東西。這樣，決策點就從「要不要做這個？」變成「是不是已經有足夠多用戶告訴我們：沒有它就拿不到價值？」

因經驗不足而不安全

挑戰：創始人用 AI 工具匆忙把應用推向市場，卻沒有先搞懂基本安全原則，最終會讓用戶暴露在本可避免的風險中。

硬道理是：agentic 編程工具生成的是能運行的代碼，不是天然安全的代碼。功能代碼很好判斷——要么能跑，要么不能。但安全漏洞在被利用之前是隱形的，沒有天然反饋環（feedback loop）會提醒首次創業者哪里出了問題。把上線的 MVP 交給真實用戶，意味著真實數據、真實暴露和真實后果。

輕視安全并不是 AI-Native 項目才有的新問題。每個時代的自籌資金創業公司都常常把安全考量拖到很晚，有時甚至拖到生產發布前夕。在任何用戶接觸你的 app 或方案之前先做一次安全審查，是把最小可行產品送到世界上所需的最低責任門檻。

Claude 如何幫助 MVP 階段創始人 動手之前先定架構

在 Claude Code 寫下第一行生產環境代碼之前，用 Claude 定義并記錄本階段所有開發都要遵守的架構決策：遵循哪些模式、避開哪些依賴、做了哪些取舍以及為什么。這份輸出會成為聚焦的架構上下文文檔，建立 Claude Code 要在其中運行的護欄。

沒有這份上下文，每次會話都從零開始，Claude Code 只能自行推斷結構性假設。讓 Claude Code 在沒有護欄的情況下開發，會產出功能可用但結構不一致的代碼庫。在這樣的代碼庫上迭代和擴張，本質是在浪費時間和 token。遲早有一天，代碼會不可避免地坍塌，迫使你從頭重建。

練習：打開 Claude Code 之前，先打開 Claude，描述你要做的事：它解決的核心問題、服務的用戶，以及未來六個月你現實預期的規模。讓它幫你定義 MVP 開發應遵守的架構原則、在你的約束下應避開的依賴，以及這個階段你有意識接受的取舍。

接著，把這份輸出保存為 CLAUDE.md 文件。這就是你的架構上下文文檔：開發過程的第一個產物，也是后續每次會話都依賴的對象。CLAUDE.md 是 Claude Code 的項目級指令，為特定代碼庫提供上下文和說明，Agent SDK 在該目錄運行時會自動讀取。功能上，它就是項目的持久記憶。

定義并執行 MVP 范圍

零摩擦的范圍蔓延，是 AI 時代 MVP 的典型失敗模式之一。就像你定義并記錄產品的應用架構一樣，在任何功能動工之前，也要先定義 MVP 的范圍。

Claude 可以幫你寫一份范圍文檔，描述 MVP 做什么、明確不做什么，以及功能修訂標準：來自真實用戶的哪種具體證據，才足以證明此刻應該加新東西。

當新的功能想法冒出來（它們一定會冒出來），用 Claude 做壓力測試：這是用戶的真實信號，還是披著產品思考外衣的創始人熱情？

用 Claude Code 做 MVP

架構和范圍定義清楚之后，Claude Code 就是主要的 MVP 開發工具。用它生成、測試、調試、迭代代碼庫，但要把每次會話當成對你已做出的產品決策的執行，而不是趁機塞進新想法的機會。

每次 Claude Code 會話開始時，先重讀范圍文檔，并給模型提供 CLAUDE.md 架構上下文文檔。每次會話結束時，把會話中浮現的決策更新進去。目標是一個你能解釋其結構的代碼庫，而不只是一個能跑起來的代碼庫。

練習：給 Claude Code 工作建一個簡單的會話模板，包含架構上下文文檔、本次具體任務，以及要遵守的約束或模式。每次會話結束時，在上下文文檔里加一條簡短日志，記錄做了什么、定了哪些決策、引入了哪些假設。每次五分鐘的文檔記錄，是防止架構漂移復利成無法管理的代碼庫的便宜保險。

任何用戶上手之前先做安全審查

作為 AI-Native 創業公司的創始人，你有責任知道代碼庫里有什么、理解潛在的暴露路徑，不要把明顯的漏洞交付給那些信任你處理他們數據的真實用戶。

Claude 可以對 AI 生成的代碼做一輪有用的初步安全審查，幫你識別常見漏洞。這是發布前應該養成的好習慣。但它不能替代安全工具，在更高風險的場景下也不能替代人類審查者。把它當成替代品的創始人，最后往往會出現在事故新聞里。

Claude Code Security 更進一步：它會掃描代碼庫里的安全漏洞，并為人類審查提出定向補丁建議，浮現傳統方法容易漏掉的問題。

注：截至本電子書出版時，Claude Code Security 還是受限 beta 版本。加入工作流之前請先確認當前可用狀態。

練習：部署給任何真實用戶之前，用一份明確的 brief 把核心應用代碼交給 Claude 審查：認證和會話處理、API 響應中的數據暴露、輸入校驗和注入風險，以及存在已知漏洞的依賴。認真對待每個發現，判斷是否需要修復；凡是涉及認證、密鑰或數據處理的部分，都要走人類審查。

發布前先把度量框架建好

那些把早期牽引誤判成 PMF 的創始人，通常也是發布之后才開始追蹤數據的人，而且挑選的指標往往是為了證明什么有效，而不是浮現什么無效。解藥是在第一個用戶出現之前，就建立度量框架。

用 Claude 定義你的具體產品應該看哪些指標、基準是多少、數據里哪些模式構成真 PMF、哪些只是好看的噪音。具體來說，發布 MVP 前先設定留存基準、激活標準，以及第 7 日和第 30 日目標。

接著，定義對你的產品而言什么是假陽性：有注冊但無激活、有收入但無留存、初始熱情但沒有重復使用等等。數據到來時，讓 Claude 替懷疑者發言：一個懷疑者會怎么解讀這些數字？

管理用戶發現和反饋的運營層

真實用戶進入產品之后，運營層會迅速膨脹。Claude Cowork 可以承接重要但瑣碎的工作：建立和維護用戶聯系人列表、跑觸達序列、安排反饋會、給 bug 報告做分診（triage）、追蹤迭代周期。想法階段那套管理用戶發現后勤的 MCP 集成，在這里同樣適用。

對細膩的用戶反饋探索，要讓真人留在收集環里。用戶說「這很好，但我希望它還能……」時，需要解釋：這是核心需求還是錦上添花？是這一個客戶特有的，還是代表某個細分人群？缺失功能才是真問題，還是新用戶引導（onboarding）上游出了問題？沒有工具能替你回答。

練習：配置 Claude Cowork 跑你的 MVP 階段反饋環：給早期用戶列表起草觸達、安排反饋會、為 bug 和功能請求設計結構化收集流程、每周寫一份綜合摘要。你先自己讀摘要；之后再讓 Claude 分析信息，捕捉你可能漏掉的重要點。

朝證據迭代，而不是朝「做完」迭代

MVP 階段結束的標志，是你拿到了 PMF 的真實證據，而不是產品看起來有多「完成」。宣布達到 PMF、準備從 MVP 階段進入發布階段，本質上是一項判斷練習，需要把創始人直覺和已收集的證據結合起來。不過，有幾個有用的試金石：

• Sean Ellis 測試：

  問你的活躍用戶：「如果再也不能用這個產品，你會有什么感覺？」如果超過 40% 的人回答「非常失望」，就是一個有意義的 PMF 指標。

• 努力測試（effort test）：

  PMF 之前，留存需要持續干預：頻繁觸達、激勵、個人跟進，加上創始人那種英雄式的精力維持用戶活躍。PMF 之后，產品開始自己承擔這項工作。當事情開始「被拉」而不是「被推」時，這種付出感的變化，是真東西發生的最清晰信號之一。

最終，沒有哪個單一數據點能確認 PMF，因為它必須在多個迭代周期里持續成立，你才能確認。

數據要求 pivot 時，就要 pivot

如果投入這么多工作之后，仍然摸不到 PMF 怎么辦？結果沒有印證你最初的方向，并不是失敗，而是系統在正常工作：MVP 階段的設計目的，就是在你對錯誤答案過度投入之前浮現這些信息。

當數據不支持當前產品時，用 Claude 梳理這些數據到底在告訴你什么。

• 探索替代客戶細分。

  也許那些沒轉化的用戶，從一開始就不是合適的目標。很多時候，對的受眾已經在你的數據里，只是權重被低估了。

• 調整產品的價值主張（value prop）。

  也許受眾是對的，但 MVP 沒有和用戶產生共鳴。調整新用戶引導、信息表達或核心功能側重，可能不用改你已經造好的東西就能修復問題。

同時也要保持開放：設計價值和體驗價值之間的脫節，可能深到需要一次更根本的改變。

練習：如果你已經完成三輪以上迭代周期，仍然沒有朝 PMF 基準的實質推進，讓 Claude 在你決定下一步之前先跑一次診斷。把留存數據、用戶反饋和最初的問題假設都交給它，問三個問題：

• 數據里是不是存在某一段用戶的反應方式和其他人不同？

• 設計價值與體驗價值之間的落差，是定位問題還是產品問題？

• 當前產品要找到真正的 PMF，需要哪些條件？以你觀察到的現象，那個情境現實嗎？

讓答案決定你是微調、pivot（調整方向），還是退回想法階段。

Chapter 5

發布階段

發布階段

如果說 MVP 階段是要證明你的產品值得存在，那么發布階段就是要證明你的生意值得長大。

發布階段·目標

在發布階段，創業者必須把早期勢頭轉化成一臺可重復、可持續的增長引擎。除了讓產品具備生產就緒狀態，你還得同時加固產品底下的基礎設施——也就是圍繞產品真正搭起一家公司。

創業公司在想法和 MVP 階段天然以創始人為中心，因為你需要完整的處境感知和緊密的反饋環。但到了發布階段，那些仍想把每一根線握在自己手里的創始人，會變成創始人瓶頸。目標不是把自己從公司里拿掉，而是搭建運營系統，把注意力釋放出來，去做那些只有創始人能做的決定。

發布階段·退出標準

發布階段的退出條件包含三項：

1. 增長是可重復、由渠道驅動的。

   你不只是在留住用戶，而是通過具體渠道、用清晰的單位經濟模型（unit economics）可預測地獲取用戶。CAC（獲客成本）、LTV（用戶生命周期價值）、回收周期，都是你心里有數、說得清楚的數字。

2. 產品扛得住生產工作負載。

   基礎設施已加固，安全與合規到位，可靠性在真實生產條件下也站得住，而不只是在你測試過的條件下。

3. 運營在沒有創始人瓶頸的情況下也能跑。

   流程已就位，自動化已部署。你不再是親自處理客服、分診、沖刺規劃或報表的人。

找到 PMF 是早期創業生命周期里最難的問題。現在，創始人的挑戰變成了把它保住。發布階段是這樣一個地方：那些已經找到真實產品牽引的公司，仍可能在包圍和支撐產品的組織跟不上時散掉。下面是要警惕的失敗模式。

技術債到期

挑戰：那個為速度和驗證而搭的 MVP 代碼庫，勉強夠證明產品能跑。但生產流量、新功能和持續增長的復雜度，正在把當初的捷徑一一暴露出來。

在 MVP 階段，積累一些技術債是用速度換來的合理代價。到了發布階段，那筆債開始算利息，拖得越久，修起來越貴。

解決方案是一次系統的架構審查（architectural audit）：找出結構性弱點，對最嚴重的幾處做定向重構（refactoring），并實質性地擴展測試覆蓋率，確保下一輪功能開發不會重新引入同樣的問題。

創始人成了瓶頸

挑戰：MVP 階段，創始人參與每個環節是一種資產。到了發布階段，隨著支持工單上漲、產品決策堆積、運營復雜度倍增，同樣的本能會變成約束。

從親自做事，到設計能把事情做完的系統，是創業生命周期里最難的轉變之一。因為很少有一個清晰時刻宣告它已經發生，風險就在于你完全錯過它，繼續停留在「建造者模式」里，而組織在你身邊停滯。明顯信號包括：本該一小時完成的決策，因為等你處理變成一周；支持請求越堆越多，因為只有你知道答案；運營任務只有在你親自想起來時才發生。

解藥是把你親自在做的事徹底審視一遍，從最小的任務到最關鍵的決策，識別哪些能系統化、哪些能委派出去、哪些確實仍值得創始人的時間和注意力。

安全與合規不能再往后拖

挑戰：MVP 階段，把安全與合規措施做得簡單還能接受。但現在，有真實用戶、真實數據，甚至桌上可能擺著企業合同，它會變成負債。

MVP 階段只有少量 beta 用戶、生產環境里沒有敏感數據時，安全漏洞還是理論風險。但產品一旦進入生產、有真實用戶依賴它，假設就會變成非常現實的暴露風險。再往前一步，那些原型期可以忽略的合規要求，會在你處理客戶數據、處理支付或賣給受監管行業的那一刻立刻適用。

解藥是在生產規模到來之前（不是之后），做一次系統的安全與合規審查。凡是浮現出來的問題，都要當成下一波用戶到來前必須修復的事項，而不是建議。

還沒準備好就擴張

挑戰：新市場和融資機會看起來都像增長機會。它們也可能是 PMF 死掉的地方。

你建立的初始牽引是真實的，但它也具體綁定在早期受眾上。過早擴張到一個跟原市場差異很大的市場，會引入新的用戶行為、合規要求、支付基礎設施和基線預期，而你的產品并不是圍繞這些設計的。一下子變量太多，你失去了清晰解讀自己數據的能力。你還可能一邊追逐新的、未經驗證的受眾，一邊把原始用戶群晾在一邊。

Claude 如何幫助發布階段創始人

發布階段會完整用到 Claude 的三種形式，它們彼此支持：每個工具的輸出都會變成另外兩個工具的輸入。結果會自然復利，一個同時使用三者的創始人，得到的不只是簡單相加的總和。

這也是超精益創業模型在結構上可行的原因。當 Claude Code 構建產品、Claude Cowork 構建產品周圍的公司、Claude 幫助把產品和組織知識運營化，一個小團隊就能像大得多的公司那樣運行。

在技術債復利之前清算

你的 MVP 代碼庫能跑，但它也需要一次系統化的修復掃描，找出任何可能變成結構性負債的技術債。

第一步，用 Claude Code 跑一次完整架構審查：識別代碼庫哪里脆弱、哪些捷徑會變得維護昂貴、測試覆蓋在哪里薄到下一輪功能開發會重新引入同樣的問題。

把 Claude Code 的審查發現喂回 Claude，讓它分診并排序修復工作：什么必須在下一次發布前修、什么可以等一個沖刺、什么在當前階段屬于可接受的持續債務。這也是把 MVP 階段那些只裝在你腦子里的架構決策寫下來的時機。把它們放進 CLAUDE.md，能確保未來每次 Claude Code 會話都從同一份理解開始。

練習：讓 Claude Code 審查 MVP 代碼庫，產出結構性弱點、測試覆蓋缺口和重構候選項的優先級清單。然后把清單交給 Claude，讓它把修復工作排進幾個沖刺：哪些重大問題要先處理、哪些可以和功能開發并行、哪些可以等等再說。

搭起替代創始人注意力的系統

要搭建能釋放你注意力的運營系統，讓你專注處理只有創始人能承擔的責任，第一步是搞清楚你的注意力到底花在哪里。用 Claude Cowork 對當前運營負荷做一次結構化審計，記錄每個重復任務、每個落到你桌上的決策、每個只因為你親自記得才會發生的工作流。然后讓 Claude Cowork 把清單分成三類：能完全自動化的、需要人但不一定需要你的、確實需要創始人判斷的。

審計完成后，用 Claude Cowork 設計自動化候選項的工作流邏輯：每個工作流由什么觸發、決策規則是什么、輸出長什么樣、完成后流向哪里。

把安全與合規做成一條產品工作流

用 Claude Code 浮現代碼層面的問題：那些常出現在 SOC 2、GDPR、HIPAA 審計以及目標市場要求標準中的問題。它會同時浮現漏洞和合規缺口。把發現交給 Claude，幫你排修復優先級，并設計企業買家簽約前會要求的控制項、審計日志和訪問管理。

注：AI 掃描是一種輔助，不能替代有資質的合規審查。

接下來，把合規工作流并入開發周期，而不是當成一次性項目。合規文檔需要持續維護和更新。對正在接近企業合同或國際市場的創始人來說，這也是 Claude Code 安全掃描幫你準備獨立安全評估的時機。

練習：用 Claude Code 跑一次代碼級安全審查，方向對準目標市場所需的框架。把輸出喂給 Claude，請它產出兩樣東西：優先級排序的安全修復序列，以及為了通過潛在企業買家的合規審查、你需要準備的文檔和控制清單。

把一直跳過的產品管理流程立起來

發布階段需要一套輕量、可重復的流程，不需要創始人介入觸發或維持也能運行。用 Claude 設計：產品時間線和工作周期如何組織，一份 spec 在 Claude Code 觸碰功能前必須包含什么，bug 報告如何分診和路由，每周指標簡報覆蓋什么、如何分發。

流程設計好之后，用 Claude Cowork 搭建并運行運營層：安排沖刺儀式、把新進 bug 報告路由到正確位置、從連接的數據源匯總每周指標、維護讓用戶信號持續流入產品決策的反饋環。

練習：請 Claude 設計一套輕量的產品管理操作系統：明確的沖刺節奏、最低規格文檔模板、bug 分診決策樹，以及從真實數據源拉取的每周指標簡報。然后讓 Claude Cowork 執行并運行系統里的重復運營環節（例如排期、路由和報告匯總），讓它們按計劃發生，而不需要你出手。

Chapter 6

規模化階段

規模化階段

在規模化階段，創始人的角色重新校準，從建造者轉向面向公眾的高管。產品仍然是核心，但你的日常工作越來越多地落在公司本身。你必須把注意力擴展到規模化階段的新活動，比如分析師溝通會和 IPO 路演，同時盡量守住那份以 AI 為中心的精益結構性優勢。

規模化階段·目標

擴張技術基礎設施的工作不會停，現在又加上一項：擴張組織本身，把它催熟為一門真正的生意。

到了規模化階段，你要從幾千用戶走向幾百萬，從單一市場走向多個市場。前面每個階段，增長都是你能摸著走的事：貼近用戶、依靠緊密反饋環的數據，再加上一點健康的創始人直覺調整方向。現在的目標，是搭建由成熟組織運營支撐的系統化增長。

對一家 AI-Native 創業公司來說，你的目標應該是用累積深度建出一條防御性護城河（defensible moat）。這種深度來自三塊：你已經構建進產品里的專業知識、產品與用戶所依賴的其他工具和平臺之間的深度整合，以及專有系統數據和工作流。那些一直朝同一方向、在同一基礎設施上持續構建的創始人，手里現在握著真正難以復制的東西。

到了這個階段，公開市場投資人、分析師、監管者、企業采購團隊和收購方都會施加更大壓力，也帶著更深的懷疑，因為賭注變高了。你的產品和組織都必須經得起外部審視：不只是已經造出來的能力，還有圍繞它的治理、合規姿態、財務控制和戰略敘事。

規模化階段·退出標準

規模化階段的退出條件不再是單一里程碑，而是一個閾值事件：即使創始人越來越少直接管日常運營，公司也能可持續運轉。你已經展示了系統化增長；建好了能滿足最苛刻外部審查者的組織治理和合規基礎設施；并且能扎實回答這個問題：「如果一個資金充足的在位者今天復制了你的產品，你的用戶會留下來嗎？」

實際中，這個閾值通常以三種形式之一出現：不再需要外部資本的規模化可持續盈利、IPO 就緒，或被收購。三者都要求你的增長系統化且可審計，產品護城河經得起推敲，組織在運營上成熟可持續。

當這些都成立時，恭喜你：你的創業公司已經從一場賭注，變成了一門生意。

規模化階段·挑戰 把運營層放手出去

挑戰：規模化階段的運營系統必須可靠、可持續地運行，不能靠人盯著。對一個從第一天起就親力親為的創始人來說，這種轉變既是結構挑戰，也是心理挑戰。

發布階段的工作是把系統創建出來；規模化階段的工作則是讓這些系統成熟到完全可信，然后真的信任它們。

這比聽起來更難。即使你是一個擅長授權的創始人，也未必每次都清楚什么該交出去、什么該留在自己手里。交得太多、太快（尤其是交給 AI 自動化系統），關鍵決策可能會在缺少創始人獨有上下文的情況下被做出來。但抓得太久，你又會變成瓶頸。

這里的根本挑戰，是識別那些只存在于創始人腦子里、或藏在未成文工作流里的機構知識，把它編碼進有文檔、可審計、可交接的系統中。

擴張技術運營

挑戰：客戶不再只評估你的產品，他們還想知道你的組織能不能成為可靠的基礎設施伙伴。

創業前三個階段的技術挑戰都圍繞代碼庫：構建對的方案而不積累技術債，再為真實用戶加固安全和合規。進入規模化階段，挑戰變成圍繞代碼庫的一切：搭建支持基礎設施、文檔和可靠性保證，向外界傳遞成熟信號。

簽多年合同的大客戶和機構買家，簽約前會要求看到這些，簽約后也會按這些標準約束你。好在帶你走到這里的同一套 AI 基礎設施，也能幫你建立專門的支持職能：明確的響應時間、新客戶工程團隊真正用得上的文檔。

擴張組織職能

挑戰：規模化階段的公司通常需要招聘、薪資、會計和法務運營等組織基礎設施，不管真正在跑公司的人有多少。

發布階段，系統化運營意味著把那些消耗創始人注意力的工作流自動化。規模化階段的創業公司現在需要擴展一組更廣、某些方面也更要緊的運營職能，比如財務報告、合規監控、合同管理和客戶支持。

搭一個 GTM 職能

挑戰：自然增長有天花板，多數規模化階段的創始人在真正搭過 GTM 職能之前，就會撞上它。

想法、MVP 和發布階段的增長，往往來自創始人親自賣：從一篇恰到好處的 Product Hunt 帖子，到與早期客戶的私人關系。這樣的自然增長只能走到某個點，多數創業公司會在規模化階段撞到這個上限。信號包括用戶曲線變平、獲客成本上升，以及銷售管道只有在創始人親自介入時才會推進。

規模化階段的增長，需要搭建一臺專門的增長引擎，讓產品觸達更新、更廣的人群。但多數創業公司創始人，可能從來沒真正運行過市場、銷售、分析師關系這類項目。一個像樣的 GTM 打法（motion）不只是建立新系統和流程，還要打造一種品牌聲音和產品故事，說明你想怎么談論自己的產品。因為在生命周期的這個階段，你需要觸達的不只是單個新用戶，還包括投資人、企業買家等完整目標人群。

好消息是，GTM 職能不必做得很大，也可以有效。構建產品的同一套 AI 基礎設施，也能幫你把產品帶向市場。

Claude 如何幫助規模化階段創始人

早期階段，Claude 是產品本身的基礎設施：驗證想法的研究伙伴、設計并構建原型的工程團隊，以及讓單人創業公司得以成立的 AI 運營層。走到規模化階段的 AI-Native 創始人，現在可以繼續用 Claude、Claude Code 和 Claude Cowork，沿著同樣的方式擴張。

把日常任務交給 Claude Cowork

用清醒的視角開啟規模化階段：你現在最需要把時間和注意力投在哪里？對第一次創業、從未真正搭過一門生意的創始人來說，這一步并不容易。Claude 可以幫你列出在這個階段只有你能做的事，比如產品敘事決策、董事會關系、企業大單、創始人之間的對話。清單之外的，都是可以委派或交給 Claude Cowork 自動化的候選項。

練習：用 Claude 繪制當前運營層的瓶頸地圖：所有目前經過你的工作流、決策和審批。然后讓 Claude 推演：如果你一周不在，每一項會發生什么？那些會停下來的工作流，就是你還抓得太緊、緊到足以阻礙進展的地方。

這些瓶頸和 Claude 幫你列出的創始人優先事項與責任清單怎么對應？

接下來，壓力測試一下你已經搭好的系統：它們真的能隨業務增長一起擴張嗎？

練習：用 Claude 繪制當前工作流，再追問：如果你一周不在，每一項會發生什么？那些會停滯的工作流，說明交接標準、升級路徑或異常處理還需要收緊。Claude 可以分析失敗點并提出修復建議，讓你按需更新或替換 Claude Cowork 自動化。

把技術運營升級為企業級基礎設施（enterprise-grade infrastructure）

擴張時，買家需要確信你的產品和組織可以被當作長期基礎設施來信任。代碼庫內部的技術工作照常繼續，但現在代碼庫周圍的技術工作也必須開始做。

第一步，是把機構知識轉換成能擴張的系統。用 Claude 起草并維護企業采購方期望看到的書面基礎設施，包括產品文檔、支持 playbook 和 SLA。

與此同時，讓 Claude Code 按企業合同要求的可靠性和安全標準對代碼庫做審查與加固，并構建那些 Discord 社區支持從來不需要提供的技術支持基礎設施：日志、監控、事故響應工具，以及讓 SLA 真正能被執行的可觀測性層。

接下來，Claude Cowork 運行企業支持本身的運營層：工單路由、升級工作流、由產品變更觸發的文檔更新、續約追蹤，以及企業客戶成功依賴的報告節奏。三者加在一起，讓一個小團隊擁有大組織級別的支持姿態，而這正是簽下多年期企業合同前你必須證明的能力。

練習：挑出最苛刻的三個潛在客戶，或者列出你最想簽下的三個理想客戶。讓 Claude 做一次差距分析：這些客戶的企業采購團隊在簽多年期合同前，會期待看到哪些文檔、SLA 和支持基礎設施？你目前哪里還不到位？把分析結果用來安排 Claude Code 和 Claude Cowork 的技術與文檔工作。

搭一個真正的 GTM 職能

創始人的 hustle 把你帶到了這里，但要把公司繼續擴張，你需要做出并執行一套真正的 GTM 策略。AI 可以幫你搭建、運行一整套 GTM 引擎。

Claude 可以從零搭起基礎 GTM 資源：市場細分、信息架構、分析師關系策略、銷售 playbook，以及當你開始面對公開市場投資人、企業買家和華爾街分析師時關鍵的投資人指標敘事。每類受眾都有自己的語言，并用自己的標準評估你；Claude 的工作，是把產品的價值主張翻譯成對每個受眾都成立的產品營銷方式。

這時候，Claude Cowork 可以成為你的戰術執行層：內容管線、外呼節奏、分析師溝通會后勤、新聞和 PR 節奏、CRM 維護、銷售管道報告，以及把 GTM 策略轉化成實際商業動作的大量重復性周期。

當 GTM 打法需要產品營銷基礎設施（比如交互式演示環境、集成文檔、沙盒租戶、API 參考、技術 one-pager），Claude Code 可以為你構建。買家期待從技術層面評估你的產品。在規模化階段，一段 Loom 視頻加一份銷售 deck 已經不夠看。這也是讓 GTM 打法能異步跑起來的基礎設施：一個做得到位的 demo 環境，可以在你開董事會的同時幫你成交。

把領域專長（subject matter expertise）和機構知識轉化為 AI 上下文

許多超精益的創業公司創始人，正在為某個自己親身經歷或一手觀察到的行業真實問題，構建高度具體的 app 或工具。Agentic AI 讓從未寫過一行代碼的創始人，也能用自己的領域專長做出解決復雜問題的產品。Claude、Claude Code 和 Claude Cowork 各自分工，把創始人知識轉化成會復利的產品具體性。

用 Claude 捕捉、整理并打磨創始人知識，就是把領域專長放到產品能夠觸達的地方。通過長對話、Projects 和記憶，創始人可以把自己知道的一切（行業黑話、監管坑、邊緣情況、痛點、為什么那些顯而易見的答案并不管用）放進結構化、可搜索的上下文里。Skills 可以把重復工作流編碼成可復用的例程（比如「我如何審查商業租約」「我如何分診一份患者入院表」），讓 Claude 每次都按同樣的方式運行。幾個月之后，這會沉淀成一層專有知識基底，通用 AI 無法匹敵。

把領域知識外化到 Claude 里，對于把行業特有的邊緣情況編碼進產品非常有價值。比如說，一個通用醫療計費工具可能會在 340B 藥品項目索賠上栽跟頭，而你的工具有專門的邏輯處理它。Claude Code 幫你把同行業其他專業人士的常見痛點，轉譯成驗證邏輯、prompt 優化，或者與某個競爭對手壓根沒聽過的小眾行業系統的 MCP 集成。結果是，你的 app 或工具在深度和廣度上持續復利，競爭對手沒法簡單復制。

練習：找出一個通用競品在你的垂直領域一定會做錯的邊緣情況。基于你真實見過的場景，讓 Claude Code 幫你為它寫一個專門的測試用例（不是單元測試）。每當類似的邊緣情況再次出現，就把它加進去。你的測試套件會逐漸長成一張護城河地圖。

讓累積的用戶數據復利成防御性優勢

用戶在與產品交互時，會生成行為信號（比如他們接受哪些輸出、拒絕哪些輸出），這些信號會反過來影響產品路線圖。時間一長，你會摸清自己用戶群的具體模式、偏好和邊緣情況。這就是復利價值（compounding value）：每一次改進都讓產品更有用，帶來更多使用，激發更多反饋，再推動下一輪改進。

這些數據帶著時間鎖定和具體上下文，沒辦法被抄襲者重建：你買不到數千名用戶在你產品里打磨工作流之后留下的行為指紋。

Claude 可以幫你審計已經收集到的用戶交互數據，識別其中信號最強的行為模式，并設計一條把持續使用轉化為系統性模型改進的反饋環。

練習：給 Claude 一份產品交互數據摘要：你收集了什么、收集了多久、你對用戶隨時間的使用方式了解多少。讓它識別三個信號最強的行為模式，并為每一個設計一條能轉化為系統性模型改進的反饋環。然后請它幫你起草一頁護城河敘事，用于產品營銷：你的數據飛輪（data flywheel）怎么運轉、轉了多久、為什么一個資源充足的競爭對手即使今天開干，也沒法在兩年內復制。

制造工作流鎖定（workflow lock-in）

數據網絡效應（network effects）的復利會讓產品更難被復制，而用戶工作流的鎖定（lock-in）會讓產品更難被拋棄。用戶在日常運營中跑你的產品越久，它就越深地嵌入他們真實工作的方式。他們在上面搭了自動化，訓練團隊使用它，把它接到數據源和其他工具。那些 prompt、被打磨過的工作流、被標準化的輸出，都是圍著你的產品「能做什么、怎么做」長出來的。到了這一步，切換就不再是一個產品決策，而是一項完整規模的運營工程。

制造工作流鎖定的第一步，是讓 Claude 按集成深度給當前客戶群畫一張圖。對每個客戶細分，識別他們在你產品上搭建了哪些工作流、依賴哪些集成。這張圖會告訴你產品在哪里真正粘住了，又在哪里還需要扎得更深。

你提供的集成越多，客戶就越有空間構建依賴你產品的工作流。Claude Code 可以幫你快速搭起目標用戶依賴的數據管線、項目管理工具和其他系統的原生集成。它還能構建 API、webhook 和 SDK，讓客戶不只是使用你的產品，而是在你的產品之上做開發，這才是最深一層的鎖定。

練習：讓 Claude 為你前十大客戶做一次工作流集成審計。對每個客戶，記錄他們搭建的自動化、依賴的集成、跑在你產品上的團隊工作流，以及你估算的切換成本。然后請 Claude 在這群客戶里識別共同模式：哪些類型的集成對你這款具體產品鎖定最深？你還能構建或開放什么，讓目前只停留在表層的客戶擁有更深的集成？

Chapter 7

工作沒變，規則變了

工作沒變，規則變了

在 AI 時代，創始人的工作并沒有變：找到一個真問題，做出能解決它的東西，把它擴張成一家有意義的公司。變的是通往那里的路。穿過想法、MVP、發布、規模化這四個階段，AI 把一個個季度壓縮成了一個個星期。

那些過去要花幾個月的驗證周期，現在一個下午就夠。一個能跑的原型，不再需要一位擁有合適技術棧的聯合創始人；它只需要一個清晰的問題，加上幾次專注的會話，再配上一個編程 agent。發布就緒從一段發布前的緊張沖刺，壓縮成一條持續工作流。到了規模化階段，過去把早期員工逼成救火隊員的那份運營重量，越來越多可以交給 AI，讓你的團隊把注意力放在那些會變成護城河的判斷決策上。

瓶頸不再是「你能造什么」，而是「你選擇造什么」。

Resources

Resources

用 Claude 構建

• Building AI Agents for Startups：

  講創業公司如何用 agent，讓自己在擴張過程中不再過度依賴創始人本人。

• Claude Code docs：

  帶構建者從初始安裝一路走到進階 agentic 工作流。小提示：先從「How Claude Code works」概覽開始。

• Claude Code best practices：

  覆蓋 Anthropic 內部和工程團隊驗證過的模式，包括上下文管理、權限、規劃和驗證工作流。

• Using CLAUDE.md files：

  講解如何為特定代碼庫配置 Claude Code。MVP 階段創始人搭建開發環境時的必讀材料。

• Claude Code power user tips：

  來自 Claude Code 團隊自己的工作流模式，包括并行會話和驗證環。

• Get started with Claude Cowork：

  講解團隊如何搭建 Claude Cowork，并開始落地 Skills、插件等能放大影響的功能。

• Tutorials：

  claude.com/resources/tutorials 提供一份可搜索的、面向具體任務的實操教程清單。

• How three YC startups built their companies with Claude Code：

  看 HumanLayer (F24)、Ambral (W25)、Vulcan Technologies (S25) 如何用 Claude 讓原型快速上市，并用 agentic 編程工作流擴張 AI 驅動平臺。

• GC AI：

  創始人用領域專長打造了一個由 Claude 驅動的法律平臺，貼合企業內部法務團隊真實的工作方式：公司專屬 playbook、跨職能利益相關者、可變的風險容忍閾值。

• Carta Healthcare：

  用 Claude 驅動其臨床抽象平臺，每年處理 22,000 例手術，數據抽象時間減少 66%。

• Anything：

  基于 Claude 和 Agent SDK 構建，已經幫助 150 萬用戶在不寫代碼的情況下把想法變成可運行的軟件產品，其中包括一位非技術背景的創始人做出并已經在賣的完整招聘平臺。Anything 的 AI agent 負責完整構建，讓單干創業者（solopreneur）可以把精力 all in 在自己的領域專長上。

• Cogent：

  一家應用 AI 實驗室，構建 agent 來自動化企業關鍵安全任務。Claude 是其 agent 的推理層，覆蓋漏洞全生命周期的調查、優先級排序和修復。

• Airtree：

  把 Claude Cowork 當作運營基礎設施的中心，統一過去散落在十幾個工具和團隊里的數據。現在，只要一個人用 Skills 搭出一個工作流自動化，組織里所有人都能用它完成那些長期沒空做的事。

• Duvo：

  構建 AI agent，跨 ERP、供應商門戶、電子表格、郵件甚至電話，運行采購、供應鏈和品類管理流程。Duvo 完全構建在 Claude 之上，并用 Agent SDK 跨工作流做編排。

• Zingage：

  面向居家護理機構（home-care agencies）的 24/7 自動化運營 AI agent 平臺。它用 Claude 的結構化工具調用在 EMR 和多條溝通渠道之間編排，再用 Claude 的上下文推理，做出能因患者而異、有細膩判斷的結果，而不是只對最常見的情況做模式匹配。

• Kindora：

  由一位非營利組織高管打造的 AI 驅動平臺，用 Claude Sonnet 做出了一個急需的工具：智能匹配慈善組織與資助方。在把數千個匹配篩成少數值得追進的對象之后，Kindora 的 MCP 連接器讓非營利機構可以直接在 Claude 里使用它的潛在資助方挖掘工具。

• Wordsmith：

  由一位轉行做 CTO 的律師創辦，為企業內部法務團隊提供可靠的 AI 法律技術。Claude 是 Wordsmith 合同審查、協議起草和文檔審閱能力背后的推理引擎，公司的工程團隊則用 Claude Code 來構建并演進平臺本身。

• Anthropic Startups Program：

  面向與 Anthropic 的 VC 合作伙伴有合作關系的創業公司，提供免費 API credits、公開可得的最高一檔 rate limits，并邀請參加專屬創始人活動和工作坊。

• Claude community：

  面向構建者的論壇和社區空間。

• Live learning resources：

  大會、網絡研討會、直播和回看錄播。

完整 PDF / 微信讀書

想要原版橫版排版的 PDF？

本文是線性手機版。如果你想要保留 Anthropic 原版雙欄+插畫排版的 PDF（36 頁橫版，2.4MB），可以在我官網下載。

huasheng.ai · 公眾號回復「創始人手冊」

譯者后記｜花叔

這是我用 Claude Code 翻譯并排版的第一本 Anthropic 官方手冊。整套流程：英文 PDF → Claude Code 拆頁 → 多 agent 并行翻譯 → 獨立 agent 三審三校 → Playwright 排版成 PDF。我自己一行代碼、一行譯文都沒動。

如果你也在用 AI 做產品、做公司，歡迎在這些地方找到我：

B 站花叔v · space.bilibili.com/14097567

公眾號花叔

X / Twitter@AlchainHust

??YouTube@Alchain

小紅書花叔（只工作不上班版

官網huasheng.ai

花叔 · 2026.05 · huasheng.ai