對話式智能
隨叫隨到的專家競爭分析、市場規模、財務建模、唱反調的思辨——所有過去得四處打聽「該怎麼辦？」的問題，現在都有答案。
Anthropic 出版 · 2026 年 5 月
創辦人的行動手冊
從一個構想到一家持久的公司——AI 原生新創一路上的階段地圖。
這是精華導讀版。 想看逐節完整內容、所有練習與創辦人案例? 閱讀完整版
新創公司的生命週期：2026 重啟版
AI 不只是加速了工作——它重新繪製了從構想到退場之間的整張地圖。
2026 年的創辦人可以在沒有工程背景的情況下寫出正式上線的程式碼，不用顧問也能完成市場研究，沒有團隊也能讓產品問世。AI 已經消解了「開公司」這件事過去所有的門檻——連帶讓那條曾經定義整個世代新創的線性路徑：驗證 → 募資 → 招聘 → 開發 → 再募資，徹底失效。
「精實的十人獨角獸」不再只是口號，而是一份可以被執行的計畫。本手冊將為一個全新的時代重新描繪這段旅程的四個階段——構想、MVP、上線、規模化——在這個時代，瓶頸不再是你能蓋出什麼，而是你選擇蓋什麼。
AI 抹去了一個過去理所當然的預設：每進入一個新階段，就需要更大的團隊、更不一樣的技能組合、以及全新一輪的資金。 — 創辦人的行動手冊，第 1 章
「創辦人」這份工作，定義正在改變
從一名實作者，蛻變為調度多個代理的指揮者。
「會寫東西的人」與「擁有值得做的想法的人」之間那道牆，已經被拆掉了。非技術背景的創辦人可以寫出正式上線的軟體；技術背景的創辦人也能產出財務模型與募資簡報。創辦人的注意力，正在從執行層往上挪——挪向方向感與判斷力。
三項 AI 能力，足以讓一家精實新創運轉得像一家規模大上許多的組織：
代理式編碼
永遠不會被卡住的工程師用自然語言描述你想要的東西，AI 就能以一整支工程團隊的速度生成、測試、除錯並重構出可上線的程式碼。
工作流自動化
隨時待命的營運團隊CRM 更新、每週報表、文件同步、法遵追蹤——把一家公司運轉起來的所有結締組織，全部設定為自動發生。
這些工作不會自動駕駛地完成。指揮這些工具的創辦人，必須知道怎麼用，以及何時該用哪一項。本手冊接下來的章節，將一階段一階段地走過這套指揮藝術。
構想階段
這個階段最重要的紀律，是還不要動手蓋——直到證據足以支持這麼做。
每一家新創都從同一個起點出發：一個讓創辦人念念不忘的問題。這個階段的工作是研究、客戶探索，以及誠實面對所有反向證據——這一切都應該發生在請 Claude Code 生成任何一行正式程式碼之前。
目標
以研究為導向的驗證
在投入資源開發之前，先收集到扎實的證據：一個真實的問題確實存在，而你提出的解法確實對應到這個問題。
離開條件
問題—解法契合度
- 問題真實且具體——你能說出誰會遇到、多常遇到、嚴重到什麼程度。
- 你的解法回應的是驗證過程中浮現的問題，而不是你最初假設的那個問題。
- 你已有足夠訊號支撐後續開發——這些質性證據讓「投入做 MVP」是一個理性判斷，而不是一場信仰之躍。
需留意的挑戰
AI 原生構想階段特有的三種失敗模式
01
把「開發」誤當成「驗證」
當打造原型變得毫不費力，創辦人最容易跳過最重要的工作：確認真的有人需要你即將打造的東西。原型本身不是證據，圍繞著原型展開的對話才是。
02
過早規模化
代理式編碼可以讓執行能力遠遠超前於「已被驗證的問題—解法契合度」。系統裡的智慧，本質上仍是你自己的判斷。請確保「理解」走在「動工」之前。
03
失去客觀性
你請 AI 為你的點子背書，它就會找出支持的證據。確認偏誤從此擁有一台研究引擎。解方是：把同樣的工具反過來指向自己——讓它替你的反方辯護。
Claude 如何協助
把假設磨利，再對它施加壓力測試
- 用足夠的具體性定義問題。「合約審查很耗時」沒辦法被檢驗。「中型企業的法務團隊每份合約要花 3 天以上，因為紅線修訂都散落在 email 串裡」才可以。
- 分層描繪競爭對手。直接競品、間接競品、潛在收購方、鄰近領域玩家——接著請 Claude 為每一個對手辯護，說明它為什麼會贏過你。
- 設計訪談架構。問的是相關的「過去」，而不是想像中的「未來」。把「你會用這個嗎？」換成「上一次你遇到這個問題的時候，是怎麼處理的？」
- 建立 5 場訪談的綜整迴圈。每進行完五場對話，讓 Claude Cowork 整理出兩份清單——支持的證據、反對的證據。如果第一份明顯比較長，反問自己：這個落差反映的是真實的資料，還是你內心的期待？
- 只蓋一個核心互動。當你終於打開 Claude Code，請只完成你的解法所仰賴的那一個關鍵互動。把它放到五位已被驗證過的目標使用者面前。他們的反應，決定你接下來該不該繼續往下蓋。
MVP 階段
把已被驗證的問題，轉化為一個真實使用者願意用的可運作產品。
MVP 階段仍然是一場蒐集證據的演練——只是這次的證據改聚焦在解法上：一群可被指認的使用者，是否覺得這個產品有價值到願意回訪、願意付費、或願意推薦給其他人。而你現在如何蓋出這個產品，也決定了後續還能不能繼續往上長。
目標
抵達真實證據的最短路徑
用最小、最聚焦的迭代版本，產出真正能反映產品市場契合度（PMF）的證據——同時避免累積那種會持續複利的技術債。
離開條件
真實訊號，而不是討喜的雜訊
有一群明確、可被指認的使用者，覺得產品有價值到願意回訪（留存）、願意付費（營收）、或願意推薦給其他人（口碑）。Sean Ellis 的「如果失去這個產品我會非常失望」測試超過 40%，是一個實用的判準。
需留意的挑戰
當速度變得免費以後，新出現的失敗模式
01
代理式技術債
如果沒有把規格與架構約束寫在某個 AI 可以讀到的地方，每一次對話都會把底層決策重新推導一次。每個元件單獨看都能跑——但它們從一開始就不是為了被湊在一起而設計的。
02
假 PMF
朋友的捧場、Hacker News 的一日熱度、靠關係帶來的客戶——這些都不是 PMF。它們之中沒有一項能可靠地預測第六週還會剩下什麼。
03
零阻力下的範疇擴張
每一個新加的功能，單獨看都站得住腳。湊在一起就一片混亂。請在動工之前先把範疇寫下來，並要求「使用者證據」才能修改它。
04
經驗不足造成的資安漏洞
代理式工具寫出來的程式碼會動，但不會自動具備安全性。在任何使用者碰到產品之前先做一次資安審查——這是負責任的最低門檻。
Claude 如何協助
在動程式碼之前，先定義架構與範疇
- 架構脈絡文件。打開 Claude（不是 Claude Code），描述你正在打造什麼、為誰服務、預期的規模有多大。把產出存成
CLAUDE.md——這份持久化的專案記憶，會被每一次 Claude Code 對話讀取。 - 範疇先寫下來，要修改得有證據。明確寫出產品「會做什麼」、「刻意不做什麼」、以及「在什麼樣的使用者證據下才會新增功能」。這把問題從「我們該不該做這個？」轉成「使用者是否親口告訴我們，沒有這個就拿不到價值？」
- Claude Code 的對話樣板。開場帶上脈絡文件與當下任務，收尾留下一段簡短日誌。每場對話多花五分鐘寫文件，是抵抗架構漂移最便宜的保險。
- 使用者出現之前先做資安審查。請 Claude 跑過身分驗證、Session 管理、輸入驗證、API 回應介面與相依套件漏洞。把發現的問題視為必須處理的待辦事項，而不是建議。
- 在上線之前就建立衡量框架。定義留存基準、啟用條件、Day 7 / Day 30 指標目標，以及「什麼樣的數字算是假陽性」——在第一位使用者註冊之前就要想清楚。
- 該轉就要轉。連續三輪迭代都沒有起色之後，做一次診斷：是否有某個區隔的反應與其他人不同？這是定位問題還是產品問題？要讓現在這個產品找到 PMF，前提需要是什麼？
上線階段
你已經證明這個產品值得存在，接下來要證明這門生意值得長大。
上線，是真正抓到產品動能的公司仍可能潰散的階段——只要產品周圍的組織跟不上。這個階段的目標不是把自己從公司裡抽離，而是搭建出一套營運系統，讓你的注意力得以釋放，去處理只有創辦人才能做的決定。
目標
從動能到可重複的引擎
把早期訊號轉化為可持續的成長。把產品底下的基礎建設加固。並真正圍繞產品打造出一家公司。
離開條件
三個條件，缺一不可
- 成長是可重複、由通路驅動的。CAC、LTV、回收週期，都是你能說出口、也守得住的數字。
- 產品撐得起正式流量的負載。基礎建設已加固，資安與法遵也已就位。
- 營運不再卡在創辦人身上。流程已建立、自動化已上線，你不再是親自分流每一件事的人。
需留意的挑戰
找到 PMF 之後反而把公司搞垮的原因
01
技術債到期
MVP 階段的程式碼跑得夠用，足以證明產品概念可行。但正式流量、新功能、不斷增加的複雜度，會把先前的捷徑全部攤在陽光下。請在下一輪功能週期之前完成稽核、重構，並擴大測試覆蓋率。
02
創辦人成為瓶頸
本來一小時就能拍板的決定，現在拖一週還決定不了。客服請求堆積如山，因為只有你知道答案。從「親自做事」轉變為「設計系統」，是整個生命週期裡最難跨過的一道坎。
03
資安與法遵從理論議題變成生死問題
當你已經擁有真實使用者、真實資料，桌上也擺著企業合約，MVP 時代可以延後處理的事項，現在已經變成負債。請在規模真的到來之前就做完系統性的審查——而不是事後補救。
04
在還沒準備好之前就擴張
新市場、新受眾會引入你還無法解讀的變數。盲目追逐它們，反而可能冷落了那群真正讓動能成為動能的早期使用者。
Claude 如何協助
建立系統，取代創辦人的注意力
- 在問題複利之前先還掉技術債。Claude Code 跑架構稽核，Claude 為工作分流與排序，
CLAUDE.md把過去只存在你腦中的決策記錄下來。 - 把資安當成持續工作流，而不是一次性專案。依照你切入的市場，做對應 SOC 2 / GDPR / HIPAA 的程式碼層級審查。產出：依優先順序排好的修復清單，加上企業採購團隊一定會索取的文件。
- 一套輕量的產品作業系統。Sprint 節奏、最小規格樣板、Bug 分流決策樹、從真實資料源拉出的每週指標簡報——由 Claude 設計、跑在 Claude Cowork 上。
- 創辦人瓶頸盤點。把所有目前需要經過你才能往下走的事項列出來，分成三類：自動化、授權出去、只有創辦人能做。然後為前兩類建立工作流邏輯。
規模化階段
從一場賭注變成一門生意。創辦人的角色，從建造者重新對焦為對外的經營者。
到了規模化階段，把程式碼養大的工作，會與把整家公司養大的工作並肩同行。數千名使用者長成數百萬人，單一市場長成許多市場。「離開」這個階段不是某一個里程碑，而是一個門檻：公司的營運即使在創辦人逐漸不再直接掌舵的情況下，依然可持續。
目標
系統化、能守得住的成長
透過長期累積出來的深度建立護城河——把領域知識嵌入產品、與使用者仰賴的工具深度整合、累積出競爭對手無法重現的系統資料。
離開條件
三種樣貌，皆可被檢驗
- 達到不再需要外部資金的、可持續的獲利規模。
- 具備 IPO 準備度——成長、治理、法遵都能通過公開市場的審視。
- 被一位真正看懂你護城河的收購方買下。
需留意的挑戰
規模化階段才會冒出來的新考驗
01
營運層的授權
放手太快，關鍵決策會在缺乏創辦人脈絡的情況下做出；抓得太緊，你自己就會變成瓶頸。最困難的工作是把那些只存在你腦袋裡的組織知識編碼下來。
02
所有面向都要做到企業級
客戶不再只是評估你的產品——他們要看完整的文件、SLA、可觀測性、事件應變流程，以及一份能傳遞「組織已經夠成熟」訊號的可靠度保證。
03
打造一個真正的 GTM 部門
「創辦人親自衝」是有上限的。多數新創就在規模化階段撞到這個上限。你會需要市場區隔、訊息架構、銷售腳本，以及一套面向你從沒賣過的受眾的品牌語氣。
Claude 如何協助
把優勢複利成一條護城河
- 把創辦人的知識外化。把產業術語、法規地雷、邊緣案例，還有那些「表面答案行不通，因為……」的判斷，全部寫進可被搜尋的脈絡裡。幾個月累積下來，就是一份通用型 AI 怎麼也比不過的專有知識底層。
- 把領域邊緣案例編碼進產品。你的測試套件，會變成一張你的護城河地圖。每當競爭對手會做錯的場景出現，就把它補進案例庫。
- 讓使用者資料複利成可守住的優勢。數千名使用者在你的產品裡持續打磨自己工作流所留下的行為指紋，是隨時間鎖死、無法被重新製造的東西。找出訊號最強的模式，並設計把「使用」轉化為「系統性改進」的迴圈。
- 用深度創造工作流黏著度，而不是用摩擦力。原生整合、API、Webhook、SDK——讓客戶站在你的產品上開發，而不是只是用你的產品。這是最深層的黏著。
- 啟動 GTM 引擎。Claude 草擬市場區隔、訊息架構、面向投資人的敘事；Claude Cowork 運轉內容生產線、外展節奏、業務管道報表；Claude Code 打造在你忙著開董事會時也能成交的 Demo 環境與整合文件。
工作未變，規則已改
創辦人的工作沒有變，變的是走完這份工作的路徑。
找到一個真實的問題。打造一個能解決它的東西。把它規模化成一家真正重要的公司。工作本身沒有改變。真正不同的，是壓縮：過去要好幾個月的驗證循環，現在用一個下午就能跑完。可運作的原型不再需要一位手裡握著對的技術棧的共同創辦人，只需要一個清楚定義的問題，加上幾場與編碼代理高度聚焦的對話。上線準備變成一條持續推進的工作流，而不是上線前夕的兵荒馬亂。規模化階段的營運重量被交給 AI 承擔，把你的團隊從繁瑣中釋放出來，去做那些終將成為你護城河的判斷題。
瓶頸不再是你能蓋出什麼，而是你選擇蓋什麼。 — 創辦人的行動手冊，第 7 章
延伸資源
從 Anthropic 的資料庫，往下一步走。
用 Claude 開發
01
Claude Code 文件
從安裝到進階代理工作流程，一次涵蓋。
↗
02
Claude Code 最佳實務
脈絡管理、權限設定、規劃與驗證。
↗
03
使用 CLAUDE.md 檔案
設定持久化的專案記憶——MVP 階段必讀。
↗
04
教學資源庫
可搜尋、手把手的任務式教學。
↗
計畫與社群
「從一場賭注，變成一門生意。」
當成長是系統性的、護城河經得起檢視、組織具備可持續性——這時候，恭喜你，是發自內心的。