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 時期嘅遺留程式碼、將原型推到生產，都喺呢度完成，唔使等更多人頭到位。

三者底層係同一個 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 同記憶，創辦人可以將自己知道嘅一切（行業黑話、監管陷阱、邊緣情況、痛點、點解嗰啲顯而易見嘅答案並唔 work）放進結構化、可搜尋嘅上下文入面。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

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 時期的遺留代碼、把原型推到生產，都在這裏完成，不用等更多人頭到位。

三者底層是同一個 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