照抄就行，Anthropic 教你做 AI 時代一人公司
整理版優先睇
Anthropic 發佈 AI 一人公司四階段手冊：判斷力先係真正瓶頸
呢篇文章係關於 Anthropic 上週發佈嘅一份 36 頁創始人手冊《The Founder's Playbook: Building an AI-Native Startup》。作者係 Anthropic 團隊，透過呢份手冊想解答一個核心問題：當 AI 將技術門檻壓平之後，創業到底邊度變咗，邊度仲係老樣子。整體結論係：技術門檻消失之後，判斷力成為最稀缺嘅資源。手冊提出一個四階段框架——Idea、MVP、Launch、Scale——每個階段都有具體嘅目標、退出標準同 AI 用法，仲特別提醒 AI 時代新出現嘅陷阱。
作者強調，AI 雖然令「由想法到原型」快咗好多，但同時令確認偏見同「將建造當驗證」呢啲失誤更加危險。手冊建議開發者用 CLAUDE.md 記錄架構決策，對抗 AI 開發產生嘅技術債複利。另外，手冊仲介紹咗 Claude 三個產品面（Chat、Cowork、Code）嘅用法矩陣，同 MVP 階段常見嘅三類失誤，包括將早期勢頭當 PMF、零摩擦嘅功能蔓延，同忽略安全門檻。
到 Launch 階段，創始人本人會變成瓶頸，手冊建議用 Claude Cowork 自動化運營任務，只留真正需要判斷嘅決策。Scale 階段嘅護城河來自領域知識、工作流嵌入同行為數據形成嘅飛輪。最後，手冊提醒讀者：技術門檻消失後，創始人嘅判斷力先係決定成敗嘅關鍵。
- 技術門檻消失後，判斷力成為最稀缺資源：咩問題值得解決、咩功能值得加、邊個信號係真市場回饋，呢啲 AI 答唔到，要靠創始人自己。
- 四階段框架（Idea、MVP、Launch、Scale）提供咗具體嘅目標同退出標準，每個階段都有對應嘅 AI 用法，避免「將建造當驗證」之類嘅陷阱。
- AI 時代嘅確認偏見更危險：Claude 可以幫你揾支持證據，亦可以揾反對證據，方向由你決定。先用 Claude 審查訪談問題，再去做用戶研究。
- 開發者要善用 CLAUDE.md 記錄架構決策，防止 AI 技術債複利滾存，尤其係 Node.js 呢類約定弱嘅技術棧，呢個方法可以保持代碼庫一致性。
- 用 Sean Ellis Test 驗證 PMF：問活躍用戶「如果冇得再用呢個產品，你會唔會好失望？」超過 40% 答「非常失望」先算真信號，唔好俾早期流量誤導。
The Founder's Playbook 原文下載
Anthropic 官方發佈嘅 36 頁創始人手冊 PDF，免費下載。
AI 一人公司嘅新規則
手冊開頭就點出一個事實：從來冇寫過 code 嘅人，而家都可以上線生產級應用。聽落好正，但實際上失敗模式反而更危險——42% 嘅創業公司失敗係因為做咗冇人想要嘅野，而家 AI 令你可以更快咁沿住錯誤方向衝，全程覺得好順。
Idea 階段最大嘅陷阱就係「將建造當驗證」
手冊話：「People struggle with expense reporting 係一種觀察；Finance managers at mid-market companies spend four-plus hours a week reconciling submissions because their current tools don't integrate with their accounting software 先係可測試嘅假說。」前者係感覺，後者係假說，呢個分別決定你係創業定發夢。
四階段框架：由 Idea 到 Scale
- 1 Idea 階段：目標係驗證問題精準度，用 Claude 將問題描述壓縮成可測試假說，再叫 Claude 扮競爭對手攻擊你個方案。
- 2 MVP 階段：目標係用最少資源做出最小可行產品，專註解決核心問題，同時用 CLAUDE.md 記錄架構決策，防止 AI 技術債複利。
- 3 Launch 階段：目標係上線同增長，創始人要識得將重複任務自動化，只留真正需要判斷嘅決策畀自己。
- 4 Scale 階段：目標係規模擴張，護城河來自領域知識、工作流嵌入同行為數據，技術本身唔係護城河。
每個階段都有明確嘅退出標準，滿足曬先進入下一階段
手冊仲提供咗 Claude 三個產品面嘅用法矩陣：Chat 快問快答、Cowork 做研究同自動化工作流、Code 寫程式。喺 MVP 階段，Claude Code 寫 code，Claude Cowork 管理用戶反饋，Chat 做日常決策支持。呢個組合係「一人公司」結構上可行嘅原因。
MVP 階段嘅常見失誤
- 1 第一類：將早期勢頭當 PMF。朋友轉發、帖文爆紅帶來嘅用戶唔算，要持續六週以上自然增長先值得信。用 Sean Ellis Test 驗證：超過 40% 活躍用戶話冇咗產品會好失望，先叫真 PMF。
- 2 第二類：零摩擦嘅功能蔓延。AI 加功能太易，一個下晝搞掂，結果產品邊界模糊。寫定範圍文檔，明確 MVP 做咩唔做咩，用戶證據未夠之前唔準加功能。
- 3 第三類：忽略安全門檻。AI code 功能上跑得鬱，但安全性隱形。任何真實用戶訪問之前一定要做安全審查，Claude Code Security 可以幫手，但關鍵發現要人覆核。
每個單獨功能決策都合理，但產品邊界唔知唔覺消失咗
Launch 階段：創始人係瓶頸
好多技術創始人冇諗到，進入 Launch 階段之後，技術已經唔係主要挑戰，支持量上升、產品決策堆積、運營任務得你自己記得做，呢啲加埋令你成為成間公司嘅瓶頸。
用 Claude Cowork 列出所有經過你嘅任務、決策同審批
- 可以完全自動化嘅事：設計成 Cowork 工作流自動執行
- 需要人但唔需要你嘅事：授權畀其他成員或者 AI Agent
- 真係需要你判斷嘅決策：呢啲先留畀自己
Launch 階段嘅退出標準有三條：用戶增長來自可重複渠道、產品扛得住生產負載、運營唔依賴你本人觸發。三條都成立，先算進入 Scale 階段。
護城河同最後提醒
Scale 階段嘅核心轉變係創始人由「構建者」變成「對外代表公司嘅人」。護城河唔來自技術本身，而係三個來源：領域專業知識被編碼入產品、工作流深度嵌入（用戶喺你產品上搭咗自動化、接咗數據源、培訓咗團隊）、時間鎖定嘅行為數據。
「每個改進令產品更有用，驅動更多使用，產生更多回饋，再驅動更多改進」呢個飛輪轉起嚟之後，時間就係你嘅武器
手冊最後一章只得一句話：The bottleneck is no longer what you can build, but what you choose to build。技術門檻消失之後，判斷力就係最稀缺嘅資源。呢份手冊值得完整讀一次，唔係話抄襲就能成，而係佢將每個階段應該認真諗嘅野整理得好清楚，對照自己嘅判斷，比大部份創業課有用。
Anthropic 上星期發佈咗一份36頁嘅創始人手冊，題目係《The Founder's Playbook: Building an AI-Native Startup》。
呢篇唔係軟文，亦都唔係嗰種羅列工具名嚟充塞讀者嘅內容。讀完成份PDF，最直接嘅感覺係：呢份係一份真正假設你喺2026年生活嘅指南，由頭到尾都喺度答同一個問題，當AI將技術門檻壓平之後，創業究竟邊度變咗，邊度仲係老規矩。
核心框架係四個階段：Idea（創意驗證）、MVP（最小可行產品）、Launch（上線增長）、Scale（規模擴張）。每個階段有目標、有退出標準，有一節講呢個階段應該點樣用AI，仲有一節專門講嗰啲只有喺AI時代先會出現嘅新陷阱。
我將最有價值嘅部分整理出嚟，特別係嗰啲針對開發者、容易被人忽略嘅洞察。
技術門檻壓平咗，但陷阱更多咗
手冊開頭嘅判斷好直接：
“"Founders who've never written a line of code are shipping production applications today, and the lean 10-person unicorn has gone from scrappy underdog story to deliberate plan of action."
從來冇寫過程式碼嘅人，而家可以上線生產級應用。聽落係好事，隨即就嚟咗一個反轉：AI時代反而令某啲失敗模式變得更危險。
歷史數據係：42% 嘅創業公司失敗，原因係做咗冇人想要嘅嘢。而家呢？AI令「從想法到原型」嘅距離壓縮到幾日，意味住你可以更快咁沿住錯誤方向跑，而全程感覺非常順暢。
手冊將呢個叫做「將建造當驗證」，係Idea階段最大嘅陷阱。具體點發生：創始人有個想法，AI幫佢快速搭咗個原型，原型行得鬱，睇落好似真產品，呢個事實本身就會令人誤以為驗證已經完成。但原型嘅存在只係證明到「做得」，證明唔到「有人要」。
建造喺驗證之後，唔係驗證嘅替代品。呢個順序喺AI時代反而比以前更加重要，因為順序搞反咗你甚至都感覺唔到。
Idea階段：問題精準度比想法質量更加重要
手冊裏面有一句話令我印象好深：
“"People struggle with expense reporting" is an observation. "Finance managers at mid-market companies spend four-plus hours a week reconciling submissions because their current tools don't integrate with their accounting software" is a testable hypothesis.
第一句話係感受，第二句話係可測試嘅假說。兩者嘅分別決定咗你係喺創業定係發夢。
AI喺呢度嘅用法：叫Claude幫你將問題描述壓縮成假說，等佢指出邊啲措辭太寬泛、冇辦法測試。然後，叫佢以「競爭對手」嘅視角嚟論證點解你嘅方案會失敗。主動壓測，唔係被動驗證。
手冊專門提到咗一個AI特有嘅風險：確認偏見而家有咗搜索引擎加持。你叫Claude幫你驗證想法，佢會揾到支持你嘅證據；你叫佢幫你估算市場規模，佢會畀出令TAM睇落適合融資嘅數字。
解法都係AI，只係轉個提問方向：叫Claude揾反對證據，而唔係支持證據。AI幫你質疑自己嘅假設同埋幫你為自己辯護，係用同一套能力，只係方向相反。
進入用戶訪問之前，先叫Claude審查你嘅訪問問題，佢會指出邊啲問題係引導性嘅、邊啲太寬泛、邊啲只會得到社交期望嘅回答而唔係真實想法。
畀開發者嘅關鍵洞察：CLAUDE.md 就係你嘅架構記憶
進入MVP階段，手冊提出一個對開發者非常實用嘅建議，喺大多數解讀裏面幾乎冇人提到。
AI技術債唔係普通技術債。
普通技術債積累慢，可以喺某個sprint裏面集中還。但AI開發產生嘅技術債會複利滾。原因係：如果你冇寫低架構決策同約束條件，每次新開一個Claude Code session，佢都會由頭推斷呢個代碼庫嘅結構假設，而呢啲假設每次都可能唔同。最後你嘅代碼庫裏面，每一塊單獨睇都合理，拼埋一齊卻冇統一嘅架構心智。
唔係某一塊程式碼寫錯咗，係呢啲塊從來就冇被設計成要裝埋一齊嘅。
手冊嘅解法係 CLAUDE.md。
喺寫第一行產品程式碼之前，先打開Claude描述你要做啲咩、要服務邊個、未來六個月嘅規模預期，等佢幫你定義MVP階段嘅架構原則、要避免嘅依賴、同埋你有意接受嘅技術權衡。將呢個輸出保存為 CLAUDE.md。
Claude Code 每次啟動時會自動讀取呢個文件，佢係AI協作嘅持久記憶。每次session結束，更新裏面記錄咗邊啲決策同假設被引入，5分鐘嘅文檔維護係對抗架構漂移最平嘅保險。
呢個方法對使用Node.js技術棧嘅開發者尤其有價值。Node生態選項多、約定弱，如果唔寫低，AI每次可能拉唔同嘅庫、用唔同嘅模式嚟解決相同嘅問題，長期睇代碼庫會越來越混亂，而你好好難揾到一個明確嘅「出錯點」。
三個Claude產品面嘅用法矩陣
手冊對三個產品面嘅區分比較清晰：
三個面底層用嘅係同一個模型，變嘅係「工作空間」。
喺MVP階段，Claude Code負責寫程式碼；Claude Cowork負責管理用戶反饋、整理訪問筆記、每星期出一份信號合成報告；Chat負責日常快速決策支援。到咗Launch同Scale階段，Cowork接管越來越多的營運自動化，Claude Code繼續迭代產品。
手冊認為呢套組合係「一人公司」喺結構上可行嘅原因：Claude Code構建產品，Claude Cowork構建公司營運，兩者嘅輸出互為輸入。
MVP階段嘅三類常見失誤
手冊將MVP階段嘅失誤分咗三類，對有開發經驗嘅人都好有共鳴。
第一類，將早期勢頭當產品市場契合度（PMF）。
你上線咗，朋友轉發，某個帖文帶嚟一波流量，頭幾百個用戶入咗嚟。呢個唔係PMF，呢個係發佈能量。六個星期之後，冇PMF嘅產品需要創始人不斷推動先至留得住用戶；有PMF嘅產品開始自己拉用戶。推同拉，感覺完全唔同。
手冊推薦Sean Ellis Test：直接問活躍用戶「如果你冇辦法再用呢個產品，你會覺得有幾失望？」如果超過40%答「非常失望」，咁先係值得相信嘅信號。
第二類，零摩擦嘅功能蔓延。
用AI加一個功能太容易喇，一個下晝就搞掂。呢個導致每個單獨嘅功能決策都感覺好合理，但產品邊界喺不知不覺中消失咗。
手冊嘅解法係寫一份範圍文檔，喺開始寫第一行程式碼之前，明確呢個MVP做啲咩、唔做啲咩，以及咩嘅用戶證據先可以觸發增加功能。決策標準從「我哋應該做嗎」變成「有大量用戶話唔做呢個就冇辦法用產品嗎」，兩者之間嘅差距喺AI時代會被放大。
第三類，安全唔係功能，係門檻。
AI生成嘅程式碼功能上行得鬱，但安全性係隱形嘅，問題喺被利用之前唔會暴露。手冊講得好直接：喺任何真實用戶訪問之前做安全審查，係發佈MVP嘅最低責任門檻，唔係之後嘅事。
Claude Code Security 可以做程式碼層面嘅安全掃描，但手冊都提醒：呢個唔係替代人工審查，而係第一道篩。凡是涉及認證、金鑰管理、數據暴露嘅發現，都要由人嚟複核。
Launch階段：你本人係樽頸
呢個係好多技術創始人冇諗到嘅事。
進入Launch階段，技術已經唔係主要挑戰。支援量上升、產品決策堆積、營運任務只有你得記住做，呢啲加埋令你成為成間公司嘅樽頸。
手冊畀咗一個具體嘅審計方法：用Claude Cowork列出所有經過你嘅任務、決策同審批，然後分三類，邊啲可以完全自動化，邊啲需要人但唔需要你，邊啲真係需要你嘅判斷。唔喺最後一類裏面嘅，設計成Cowork可以運行嘅工作流。
創始人嘅注意力只應該留畀真正需要創始人判斷嘅決策。
手冊對Launch階段嘅退出標準定咗三條：用戶增長來自可重複嘅渠道、產品可以頂得住生產負載、營運唔依賴你本人觸發。三條都成立，先算進入Scale階段。
Scale階段：護城河喺邊度嚟
Scale階段嘅核心轉變係：創始人從「構建者」變成「對外代表公司嘅人」，日常工作變成分析師簡報、投資人關係、企業合同談判。
手冊對呢個階段最有價值嘅分析係關於護城河。對於AI-native創業公司，護城河唔嚟自技術本身，因為技術可以被快速複製，而係嚟自三個來源：
領域專業知識被編碼入產品：你喺某個行業嘅深度，對手使錢都買唔到 工作流深度嵌入：用戶喺你嘅產品上搭咗自動化、接咗數據源、培訓咗團隊，切換成本變成咗一個營運項目 時間鎖定嘅行為數據：用戶同產品互動積累嘅行為模式，任何今日由零開始嘅競爭對手冇辦法複製
手冊用一句話總結呢個飛輪：「每一個改進令產品更有用，推動更多使用，產生更多反饋，推動更多改進。」飛輪轉起嚟之後，時間係你嘅武器。
幾個真實案例
資源頁列咗唔少真係用呢套方法嘅公司，摘幾個有代表性嘅：
Anything：已經有150萬用戶，幫助非技術創始人將想法變成軟件產品，唔使寫程式碼。其中一個創始人靠AI Agent建咗一個完整嘅招聘平台並已經喺度賣。 Carta Healthcare：用Claude驅動臨牀摘要平台，每年處理2.2萬例手術案例，數據抽取時間縮短66%。 Wordsmith：一名律師轉型CTO，用Claude做合同審查同法律文件分析，Claude Code用嚟構建同迭代平台本身。 Kindora：一個非營利機構管理者用Claude Sonnet搭咗慈善機構同資助方嘅智能匹配工具，加咗MCP連接器等非營利機構可以直接喺Claude裏面訪問佢。
呢啲案例指向同一個模式：領域專家加上AI，做出咗夠垂直、夠深嘅產品，而呢個正正係泛化競爭對手冇辦法簡單複製嘅方向。
幾個值得獨立思考嘅地方
成份手冊讀起嚟好紮實，但有幾點值得留意。
成個框架假設創始人對要解決嘅問題已經有清晰嘅意識同一定嘅領域積累，AI嚟放大呢種意識。如果對問題本身仲未諗透，AI只會更快咁喺錯誤方向跑，而且跑得非常順暢，你甚至嚟唔切發現。「編排者」呢個角色比「執行者」需要更強嘅判斷力，唔係更弱。
另一點係工具依賴嘅集中性。成個框架深度綁定Claude產品生態，Chat、Cowork、Code三個面協同工作，對已經喺Anthropic生態裏面嘅團隊係加分，對仲未決定工具鏈嘅人，需要提前評估遷移成本同單一依賴嘅風險。
呢啲唔係手冊嘅缺陷，而係使用前應該清楚知道嘅前提。
最後
手冊最後一章只有一句話：
“"The bottleneck is no longer what you can build, but what you choose to build."
技術門檻消失之後，判斷力成為咗最稀缺嘅資源。咩問題值得解決，咩功能值得加，邊個信號係噪音，邊個信號係真實嘅市場反饋，呢啲問題AI答唔到，只能由你嚟答。
呢份36頁嘅手冊值得完整讀一次。唔係因為照抄就成功，而係因為佢將每個階段應該認真思考啲咩，整理得夠曬清楚，拎嚟對照自己嘅判斷，比大多數創業課有用。
PDF原文喺claude.com/blog/the-founders-playbook可以免費下載。
Anthropic 上週發佈了一份 36 頁的創始人手冊，題為《The Founder's Playbook: Building an AI-Native Startup》。
這不是一篇軟文，也不是那種羅列工具名字糊弄讀者的內容。讀完整份 PDF，最直接的感受是：這是一份真正假設你生活在 2026 年的指南，從頭到尾都在回答同一個問題，當 AI 把技術門檻壓平之後，創業到底哪裏變了，哪裏還是老樣子。
核心框架是四個階段：Idea（創意驗證）、MVP（最小可行產品）、Launch（上線增長）、Scale（規模擴張）。每個階段有目標、有退出標準，有一節講這個階段應該怎麼用 AI，還有一節專門講那些只有在 AI 時代才會出現的新坑。
我把最有價值的部分整理出來，特別是那些針對開發者的、容易被忽視的洞察。
技術門檻壓平了，但坑更多了
手冊開頭的判斷很直接：
“"Founders who've never written a line of code are shipping production applications today, and the lean 10-person unicorn has gone from scrappy underdog story to deliberate plan of action."
從來沒寫過代碼的人，現在可以上線生產級應用。聽起來是好事，隨即就來了一個反轉：AI 時代反而讓某些失敗模式變得更危險了。
歷史數據是：42% 的創業公司失敗，原因是做了沒人想要的東西。現在呢？AI 讓"從想法到原型"的距離壓縮到了幾天，意味着你可以更快地沿着錯誤方向跑，而全程感覺非常順暢。
手冊把這個叫做"把建造當驗證"，是 Idea 階段最大的陷阱。具體怎麼發生的：創始人有個想法，AI 幫他快速搭了個原型，原型跑起來了，看起來像個真產品，這個事實本身就會讓人誤以為驗證已經完成。但原型的存在只能證明"能做"，不能證明"有人要"。
建造在驗證之後，不是驗證的替代品。這個順序在 AI 時代反而比以前更重要，因為順序搞反了你甚至都感覺不到。
Idea 階段：問題精度比想法質量更重要
手冊裏有一句話讓我印象很深：
“"People struggle with expense reporting" is an observation. "Finance managers at mid-market companies spend four-plus hours a week reconciling submissions because their current tools don't integrate with their accounting software" is a testable hypothesis.
第一句話是感受，第二句話是可測試的假說。兩者的區別決定了你是在創業還是在做夢。
AI 在這裏的用法：讓 Claude 幫你把問題描述壓縮成假說，讓它指出哪些措辭太寬泛、無法測試。然後，讓它以"競爭對手"的視角來論證為什麼你的方案會失敗。主動壓測，不是被動驗證。
手冊專門提到了一個 AI 特有的風險：確認偏見現在有了搜索引擎加持。你讓 Claude 幫你驗證想法，它會找到支持你的證據；你讓它幫你估算市場規模，它會給出讓 TAM 看起來適合融資的數字。
解法還是 AI，只是換個提問方向：讓 Claude 找反對證據，而不是支持證據。AI 幫你質疑自己的假設和幫你為自己辯護，用的是同一套能力，只是方向相反。
進入用戶訪談之前，先讓 Claude 審查你的訪談問題，它會指出哪些問題是引導性的、哪些太寬泛、哪些只會得到社交期望的回答而不是真實想法。
給開發者的關鍵洞察：CLAUDE.md 就是你的架構記憶
進入 MVP 階段，手冊提出一個對開發者非常實用的建議，在大多數解讀裏幾乎沒人提到。
AI 技術債不是普通技術債。
普通技術債積累慢，可以在某個 sprint 裏集中還。但 AI 開發產生的技術債會複利滾。原因是：如果你沒有寫下來架構決策和約束條件，每次新開一個 Claude Code session，它都會從頭推斷這個代碼庫的結構假設，而這些假設每次都可能不同。最後你的代碼庫裏，每一塊單獨看都合理，拼在一起卻沒有統一的架構心智。
不是某一塊代碼寫錯了，是這些塊從來就沒有被設計成要裝在一起的。
手冊的解法是 CLAUDE.md。
在寫第一行產品代碼之前，先打開 Claude 描述你要做什麼、要服務誰、未來六個月的規模預期，讓它幫你定義 MVP 階段的架構原則、要避免的依賴、以及你有意接受的技術權衡。把這個輸出保存為 CLAUDE.md。
Claude Code 每次啓動時會自動讀取這個文件，它是 AI 協作的持久記憶。每次 session 結束，更新裏面記錄了哪些決策和假設被引入，5 分鐘的文檔維護是對抗架構漂移最便宜的保險。
這個方法對使用 Node.js 技術棧的開發者尤其有價值。Node 生態選型多、約定弱，如果不寫下來，AI 每次可能拉不同的庫、用不同的模式來解決相同的問題，長期看代碼庫會越來越混亂，而你很難找到一個明確的"出錯點"。
三個 Claude 產品面的用法矩陣
手冊對三個產品面的區分比較清晰：
三個面底層用的是同一個模型，變的是"工作空間"。
在 MVP 階段，Claude Code 負責寫代碼；Claude Cowork 負責管理用戶反饋、整理訪談筆記、每週出一份信號合成報告；Chat 負責日常快速決策支持。到了 Launch 和 Scale 階段，Cowork 接管越來越多的運營自動化，Claude Code 繼續迭代產品。
手冊認為這套組合是"一人公司"在結構上可行的原因：Claude Code 構建產品，Claude Cowork 構建公司運營，兩者的輸出互為輸入。
MVP 階段的三類常見失誤
手冊把 MVP 階段的失誤分了三類，對有開發經驗的人都很有共鳴。
第一類，把早期勢頭當產品市場契合度（PMF）。
你上線了，朋友轉發，某個帖子帶來一波流量，前幾百個用戶進來了。這不是 PMF，這是發佈能量。六週之後，沒有 PMF 的產品需要創始人不斷推動才能保留用戶；有 PMF 的產品開始自己拉用戶。推和拉，感覺完全不同。
手冊推薦 Sean Ellis Test：直接問活躍用戶"如果你無法再使用這個產品，你會有多失望？"如果超過 40% 回答"非常失望"，那才是值得相信的信號。
第二類，零摩擦的功能蔓延。
用 AI 加一個功能太容易了，一個下午就搞定。這導致每個單獨的功能決策都感覺很合理，但產品邊界在不知不覺中消失了。
手冊的解法是寫一份範圍文檔，在開始寫第一行代碼之前，明確這個 MVP 做什麼、不做什麼，以及什麼樣的用戶證據才能觸發增加功能。決策標準從"我們應該做嗎"變成"有大量用戶說不做這個就沒法用產品嗎"，兩者之間的差距在 AI 時代會被放大。
第三類，安全不是功能，是門檻。
AI 生成的代碼功能上能跑，但安全性是隱形的，問題在被利用之前不會暴露。手冊說得很直接：在任何真實用戶訪問之前做安全審查，是發佈 MVP 的最低責任門檻，不是之後的事。
Claude Code Security 可以做代碼層面的安全掃描，但手冊也提醒：這不是替代人工審查，而是第一道篩。凡是涉及認證、密鑰管理、數據暴露的發現，都要人來複核。
Launch 階段：你本人是瓶頸
這是很多技術創始人沒想到的事情。
進入 Launch 階段，技術已經不是主要挑戰。支持量上升、產品決策堆積、運營任務只有你記得做，這些加在一起讓你成為整個公司的瓶頸。
手冊給了一個具體的審計方法：用 Claude Cowork 列出所有經過你的任務、決策和審批，然後分三類，哪些可以完全自動化，哪些需要人但不需要你，哪些真的需要你的判斷。不在最後一類裏的，設計成 Cowork 能運行的工作流。
創始人的注意力只應該留給真正需要創始人判斷的決策。
手冊對 Launch 階段的退出標準定了三條：用戶增長來自可重複的渠道、產品能扛住生產負載、運營不依賴你本人觸發。三條都成立，才算進入 Scale 階段。
Scale 階段：護城河來自哪裏
Scale 階段的核心轉變是：創始人從"構建者"變成"對外代表公司的人"，日常工作變成分析師簡報、投資人關係、企業合同談判。
手冊對這個階段最有價值的分析是關於護城河。對於 AI-native 創業公司，護城河不來自技術本身，因為技術可以被快速複製，而來自三個來源：
領域專業知識被編碼進產品：你在某個行業的深度，對手花錢買不到 工作流深度嵌入：用戶在你的產品上搭了自動化、接了數據源、培訓了團隊，切換成本變成了一個運營項目 時間鎖定的行為數據：用戶和產品交互積累的行為模式，任何今天從零開始的競爭對手無法複製
手冊用一句話總結這個飛輪："Each improvement makes the product more useful, which drives more usage, which creates more feedback, which drives more improvement." 飛輪轉起來之後，時間是你的武器。
幾個真實案例
資源頁列了不少真實在用這套方法的公司，摘幾個有代表性的：
Anything：已有 150 萬用戶，幫助非技術創始人把想法變成軟件產品，不用寫代碼。其中一個創始人靠 AI Agent 建了一個完整的招聘平台並已經在賣。 Carta Healthcare：用 Claude 驅動臨牀摘要平台，每年處理 2.2 萬例手術病例，數據抽取時間縮短 66%。 Wordsmith：一名律師轉型 CTO，用 Claude 做合同審查和法律文件分析，Claude Code 用來構建和迭代平台本身。 Kindora：一個非營利機構管理者用 Claude Sonnet 搭了慈善機構和資助方的智能匹配工具，加了 MCP 連接器讓非營利機構直接在 Claude 裏訪問它。
這些案例指向同一個模式：領域專家加 AI，做出了足夠垂直、足夠深的產品，而這正是泛化競爭對手無法簡單複製的方向。
幾個值得獨立思考的地方
整份手冊讀起來很紮實，但有幾點值得留意。
整個框架假設創始人對要解決的問題已經有清晰的意識和一定的領域積累，AI 來放大這種意識。如果對問題本身還沒想透，AI 只會更快地在錯誤方向上跑，而且跑得非常順暢，你甚至來不及發現。"編排者"這個角色比"執行者"需要更強的判斷力，不是更弱。
另一點是工具依賴的集中性。整個框架深度綁定 Claude 產品生態，Chat、Cowork、Code 三個面協同工作，對已經在 Anthropic 生態裏的團隊是加分，對還沒決定工具鏈的人，需要提前評估遷移成本和單一依賴的風險。
這些不是手冊的缺陷，而是使用前應該清醒知道的前提。
最後
手冊最後一章只有一句話：
“"The bottleneck is no longer what you can build, but what you choose to build."
技術門檻消失之後，判斷力成了最稀缺的資源。什麼問題值得解決，什麼功能值得加，哪個信號是噪音，哪個信號是真實的市場反饋，這些問題 AI 答不了，只能由你來答。
這份 36 頁的手冊值得完整讀一遍。不是因為照抄就能成，而是因為它把每個階段應該認真思考什麼，整理得足夠清楚，拿來對照自己的判斷，比大多數創業課有用。
PDF 原文在 claude.com/blog/the-founders-playbook 可以免費下載。