Gary Talks Stuff：AI 時代怎麼創業？Anthropic Playbook 一次看懂四階段 workflow

開場閒聊

Gary 一開場就拋出了一個很有意思的概念——「十個人的獨角獸公司」（10% Unicorn）。他說這句話聽起來很細骨，但背後其實講的是 AI 生產力爆發後的一種全新公司型態。

以前創業的過程大概是這樣：先用最小可行產品驗證市場，然後募資，然後擴編，然後做產品，然後再募資，再找更多人，再做更多功能。每往前走一步，公司就要變大，管理就要變重，成本就要變高。

但 Anthropic 認為這條路徑正在被 AI 改寫。現在一個創業者可以用 Claude 做市場研究，用 Copilot 做產品原型，用 Co-work 處理營運流程。

不過 Gary 馬上補了一句：「AI 不是讓創業變簡單，而是讓執行和試錯的成本都變得更低。」這句話點出了整個影片的核心矛盾——AI 同時放大判斷力和愚蠢，關鍵在於你怎麼用它。

---

我花了大約 17 分鐘看完這部片，內容從創業流程的重新定義，一路聊到如何用 Anthropic 的產品全家桶在每個階段建立真正的 workflow。這篇文章我幫大家整理出四個階段的關鍵做法，並附上我自己在 AI 工具使用上的一些補充觀察。

---

傳統創業 vs AI-native Startup：本質差異

Gary 開門見山地比較了兩種創業模式的本質差異。

傳統創業幾乎在進入每個新階段都要擴編。你要做研究，所以要找懂市場的人；你要做產品，所以要找工程師；你要做營運，所以要找 ops；你要做增長，所以要找行銷和 BD。公司成長等於 headcount 成長，因為過去的工作就是靠人堆出來的。

但 AI-native startup 的狀況完全不同。在很多階段，你可以先用 AI 把工作流跑起來，等到某個流程真的被驗證、真的有穩定需求、真的值得專人負責，再去招人。以前是先招人再加入流程；現在可以先用 AI 跑流程，再決定哪些流程值得變成職位。

這就是「小團隊大公司」的本質——不是十個人突然都變成天才，而是每個人背後都有一整套 AI 系統在放大產出。

Gary 也點出了一個關鍵陷阱：當 AI 放大了團隊的執行力，你的判斷力也會變得尤為重要。沒有判斷力的人，錯誤只會用更快的速度被放大。一個沒被驗證的想法，以前頂多寫在 Notion 裡，現在你可以叫 Claude 幫你做出 Demo、寫 Pitch Deck、搞 Landing Page，甚至連銷售信都可以一起生出來。做出來的東西看起來有模有樣，但它可能只是被 AI 包裝過的錯誤假設。

Anthropic 產品分工：Chatbot、Co-work、Code

在進入四個階段之前，Gary 花了一分鐘把 Anthropic 的三個產品分工講清楚。

最單純的是 Claude Chatbot——你開個聊天框隨手問的那種，問個問題、改一段文字、快速 Brainstorm，不用設定，即開即用。

再來是 Claude Co-work——處理那種要花時間、要跨很多份資料、最後要生出一份成品的任務。比如把一疊客戶訪談記錄整理成一份 findings，爬十幾個競品網站拼出一張競爭地圖，或是每週固定丟一份 KPI brief 到共用資料夾。

最後是 Claude Code——真正在寫程式的工具，直接碰你的 codebase、Git 開發環境，從原型一路做到上線。

Gary 給了一個很好記的分法：隨手想問個問題用 Chatbot，要產出一份非軟體的成品用 Co-work，要寫程式用 Code。

Stage 1：Idea — 驗證比產品更重要

Idea Stage 最重要的不是做產品，而是做驗證。AI 在這個階段最大的用途是市場研究、競品分析，以及反向挑戰你的假設，避免做出一個沒人要的東西。

Anthropic 的 Playbook 要求創業者一開始回答五個關鍵問題：

1. 這個痛點是不是真的存在？
2. 誰有這個問題？
3. 這個問題發生的夠頻繁嗎？
4. 現在大家怎麼解決？
5. 你的解法到底有沒有打中真正的問題？

Gary 強調這些問題聽起來很基本，但最容易被跳過。CB Insights 的資料顯示，42% 的 startup 失敗是因為「build something nobody wanted」——做了一個沒人要的東西。AI 不會自動解決這個問題，AI 只會讓你更快做出一個沒人要的東西。

Idea Stage 的具體 Use Case

第一，讓 Claude 扮演反方。輸入你的問題假設、解法草案、目標市場和競品，請 Claude 找出這個 Idea 最可能失敗的原因。輸出四類分析：客戶為什麼可能根本沒有這個痛點、競品為什麼已經夠好、市場為什麼可能太小、解法為什麼即使做出來也很難賣。

Founder 要判斷的不是 Claude 說的對不對，而是哪些反對意見是真的會讓你改變方向，哪些只是你需要承擔的風險。

第二，Customer Discovery 訪談設計。Gary 分享了一個很關鍵的 insight：很多創業者訪談客戶其實是在問廢話。例如「如果我做一個可以幫你節省時間的工具，你會不會用？」這種問題沒有意義，大部分人都會說會，因為聽起來沒成本又不用現在掏錢。

真正有用的問題是問過去，不是問未來。不要問你會不會用，要問你上一次遇到這個問題是什麼時候、當時怎麼處理的、花了多久、有沒有花錢解決。Claude 可以幫你設計訪談問題，然後檢查哪些問題太具備誘導性、哪些太過抽象。

Stage 2：MVP — 速度快不等於可控

MVP 階段是很多人最興奮的地方，因為 AI 讓打造一個可以快速驗證市場的 MVP 變得超級快。但 Gary 認為這一段也最容易出事。

AI coding 最大的問題不是寫不出來，而是太願意寫。以前 scope creep 會被工程成本擋住——你想加功能，工程師會皺眉、PM 會排優先級、老闆會看 budget。現在沒有這些摩擦，你的每個突發奇想都可以很快變成產品的一部分。

最關鍵的區別：AI 最擅長的是 Greenfield project（從零開始做 demo），但真正麻煩的是 Brownfield project（產品已經有人用、資料已經進來、架構開始累積技術債之後的持續疊代）。

MVP Stage 的三個 Use Case

第一，MVP Scopedoc。在開始寫 code 之前，先定義這個 MVP 做什麼、不做什麼。產出一份 scopedoc，包含核心功能、未來疊加新功能的條件（比如要達到多少月活用戶），以及最重要的——排除功能，也就是 MVP 版本不做哪些功能。AI coding 的年代，不做比做更重要。

第二，Claude Markdown。Playbook 裡講得很清楚：AI-native startup 的 codebase 是一個 session 接一個 session 跟 AI 一起協作的東西。如果沒有 specs、沒有 context files，每次開新 session，AI 都會重新推導一次系統該長什麼樣。Code Markdown 的作用就是讓 Claude 每次進來都知道專案的基本規則，像員工手冊一樣，保持架構上的一致性。

第三，上線前的 Security Review。AI 寫出來的程式碼能跑不等於安全。功能對不對一眼看得出來，但安全漏洞不會報錯、不會當機，會靜靜躺在那裡等到有人利用它。越不會寫 code 的 founder，這個坑越深。Gary 建議在上線前先讓 Claude 掃一輪，重點看 authentication、session 處理、API 是否洩漏機密資料。

Stage 3：Launch — 從手工操作變成可重複系統

Launch Stage 不只是產品上線發一篇文章或開始打廣告。在 Anthropic 的 Playbook 裡，它更像是公司開始從 founder 手工操作變成一套可以重複運作的系統。

MVP 階段，founder 在每個 loop 裡面是優勢，因為要貼近使用者、快速感受問題、親自判斷哪些 feedback 是真的。但到了 Launch 階段，如果所有事情都還要你親自記得、親自整理、親自判斷，你就會變成效率上的瓶頸。

Gary 強調了一個重點：AI 真正有價值的地方不是偶爾幫你做一件事，而是能不能把重複出現的工作流變成一套固定會運作的系統。

Launch Stage 的 Use Case

第一，Weekly Metrics Brief。Launch 之後會有很多數據出現：activation、retention、usage、bug count、conversion、funnel。很多 founder 會被 launch spike 騙到——剛上線時朋友支持、社群曝光、來自好奇心的流量，都會讓數字看起來不錯。但問題是六週後、十二週後這些人還在不在？

讓 AI 固定產出每週 metrics brief，包含本週變化、異常訊號、可能原因、下週應該追的問題。這樣你可以直觀判斷這些數字是在反應真實 product-market fit，還是在反映短期熱鬧。

Playbook 也提到了 Sean Ellis Test：問活躍使用者「如果你不能再用這個產品，你會有多少失望？」如果超過 40% 回答 very disappointed，這是一個有意義的 PMF 指標。

第二，Support 和 Bug Triage SOP。產品開始有使用者以後，問題會一直來。有些是 bug，有些是 onboarding 不清楚，有些則是產品設計本身的問題。如果每個問題都直接丟給 founder 或工程師，公司很快就會被小事淹沒。

Claude 可以產出一套 triage SOP，幫你建立分類規則、優先級、標準回覆、升級條件。這樣你可以看懂哪些問題可以流程化，哪些問題不能只靠流程處理——因為它們代表產品本身需要改。

Stage 4：Scale — 護城河是累積出來的

Scale Stage 決定一間 AI-native startup 最後到底有沒有護城河，還是只能曇花一現。到這個階段，founder 的角色會從做產品的人慢慢變成對外的經營者。

Playbook 在這裡點出三個關鍵概念：

Accumulated Depth（累積深度）：你的護城河來自你對這個領域的理解、產品跟客戶其他工具整合的深度，以及手上那些別人沒有的資料和流程。

Proprietary System Data（獨有系統資料）：產品被用得越久，你就越懂這群人怎麼做事。這些細節不是競爭對手看你的 landing page 就能抄走的。

Workflow Locking（工作流綁定）：當客戶把自動化、團隊習慣、標準輸出全都建在你的產品上面，要換掉就不再是取消訂閱這麼簡單，而是一個 operational project。

Gary 舉了兩個具體例子。第一是 User Behavior Data Flywheel：從使用者行為裡找出可以持續改善產品的訊號——哪些 output 被改掉、哪些流程被重複使用、哪些功能根本沒人碰。持續追蹤，把這些訊號轉成優化 idea，產品越用越準，越準就越多人用。

第二是避免「單功能陷阱」。一個產品最容易被替換的狀態，就是它只有一個功能。今天你做摘要，明天別人也做摘要，沒有技術壁壘。但如果你的產品已經接到客戶的資料來源、進入團隊流程、影響標準輸出，那離開成本就會高到不像話。

Scale 階段一個很值得做的 use case 是讓 Claude 幫你做一張 workflow 盤點。把使用頻率、團隊協作流程、客戶依賴的模板和輸出格式餵給它，請它整理出不同客戶群各自把你的產品用得有多深，哪些是最難被替換的節點。

懶人包速覽

核心痛點	關鍵觀點
創業成本高、擴編壓力大	AI-native startup 可以先用 AI 跑流程，驗證後再招人，從「先招人再訂流程」翻轉為「先跑流程再決定職位」
Idea 階段容易做出沒人要的東西	42% startup 失敗是因為 build something nobody wanted，Claude 可以扮演反方辯論手驗證假設
AI coding 太快導致 scope creep	MVP 階段先用 scopedoc 定義做什麼不做什麼，用 Code Markdown 保持架構一致性
Launch 後 founder 變成瓶頸	把重複性工作變成固定系統——weekly metrics brief、bug triage SOP，讓 founder 專注判斷而非執行
產品容易被複製替換	透過 accumulated depth、proprietary data、workflow locking 建立真正護城河

QA 精選

Q1：AI-native startup 的定義是什麼？跟一般用 AI 工具的公司有什麼不同？

Gary 在影片中做出了非常明確的區分：AI-native startup 不是「用了 AI 工具的公司」，而是「把 AI 變成工作系統的公司」。真正的差距在於誰能把 AI 系統化得更好——把 AI 放進每個階段的工作流程、放進營運流程、放進 scale 流程，讓 feedback、metrics、support 不再全部卡在 founder 身上，並把資料和 workflow 沉澱成產品護城河。一般公司只是拿 AI 來寫信或做摘要，AI-native startup 則是讓 AI 從頭到尾嵌入在每個營運環節中。

Q2：為什麼 Gary 說 AI 讓創業「更容易做出錯的東西」？

這是一個反直覺的觀點。Gary 指出，以前工程成本高，某種程度上是創業者的剎車——你真的要花錢花時間找人，才有辦法把一個想法做出來。現在沒有這個剎車了，每個突發奇想都可以快速變成產品的一部分。沒有 scope、spec、context 的約束，AI 不是幫你加速，而是幫你把混亂放大。CB Insights 的 42% 失敗率背後，現在可能變成更多創業者用 AI 更快地把錯誤的假設包裝成看起來有模有樣的產品。

Q3：Claude Chatbot、Co-work、Code 這三者的分工差異是什麼？創業者該如何選擇？

Gary 給了一個非常實用的記憶法。Chatbot 是隨手問問題用的，不用設定即開即用，適合 brainstorming 和快速問答。Co-work 處理的是需要跨多份資料、產出一份成品的工作——比如整理客戶訪談記錄、爬競品網站、每週產 KPI brief。Code 則是真正碰 codebase 和 Git 開發環境的寫程式工具。簡單來說：Chatbot 問問題，Co-work 產檔案，Code 寫程式。創業者在不同階段應該用不同的工具組合，而不是只用一個。

Q4：Launch 階段最容易犯的錯誤是什麼？如何判斷產品是否真的達到 product-market fit？

Gary 點出一個常見錯誤：被 launch spike 騙到。剛上線時朋友支持、社群曝光、好奇心的流量都會讓數字看起來不錯，但關鍵是六週後、十二週後這些人在不在、有沒有付費、有沒有持續使用。他引用了 Sean Ellis Test 作為判斷工具：問活躍使用者「如果你不能再用這個產品，你會有多少失望？」如果超過 40% 回答 very disappointed，這才是一個有意義的 PMF 指標。Launch 階段的 AI 不應該是聊天機器人，而應該開始變成營運系統的一部分，定期產出 metrics brief 幫助 founder 做數據驅動的判斷。

Q5：AI-native startup 的護城河到底是什麼？不應該是技術本身嗎？

Gary 的回答很直接：技術本身不會是護城河，因為用 AI 這件事很快就不會是差異了。真正的護城河來自三個面向：accumulated depth（對領域理解和整合深度）、proprietary system data（長期累積的獨有資料）、workflow locking（客戶把工作流綁在你的產品上）。他舉了一個很生動的例子：今天你做摘要，明天別人也做摘要，使用者換掉你沒什麼成本。但如果你的產品已經接到客戶的資料來源、進入團隊流程、影響標準輸出，那離開成本就會高到不像話——不是按一個取消訂閱，而是一個 operational project。

主編隨筆

Gary 在影片中花了很多篇幅談到 AI-native startup 的 workflow 建立，但我認為他真正點出卻沒有深談的一個關鍵是——AI 時代的創業，其實正在製造一種新型態的「判斷力鴻溝」。

過去創業的門檻是執行力：你有想法，但你能不能做出來？能不能找到人來做？能不能募到錢來支撐 execution？這些門檻某種程度上是公平的，因為它們可以被資本和努力克服。但現在 AI 大幅降低了執行門檻，真正拉開差距的變成了「判斷力」——而判斷力相較於執行力，是更難用錢或時間買到的東西。

我觀察到一個現象：過去創業者至少要做錯兩三次產品迭代，才會因為沒錢而被迫停下來反思。現在有了 AI，你可以一個月內做錯八次迭代，而且每次看起來都像模像樣。這其實很危險——因為速度不會讓你更聰明，只會讓你把錯誤累積得更快。當你連 Landing Page 的文案都是 Claude 寫的、市場研究報告都是 AI 生成的、連客戶回覆都是自動化的時候，你會漸漸失去對市場真實溫度的感知。

我自己在軟體開發領域的經驗是，AI 工具最危險的使用方式就是把它當成黑盒子——輸入想法、產出成品、直接拿去用。真正有效的方式是讓 AI 產出 drafts，然後由人類判斷、修改、打磨，再把修改後的版本餵回去讓 AI 學習你的判斷標準。這個循環才是 workflow 的價值所在，而不只是讓 AI 幫你做完所有事情。

回到 Playbook 的這句話：「AI 會放大創業者的判斷力，也會放大創業者的愚蠢。」我覺得這句話可以寫在每個 AI-native startup 的牆上。

結語

Anthropic 的這份 AI 新創 Playbook，表面上是在講 Claude 可以怎麼幫助創業者，但 Gary 點出了最核心的 takeaway——未來新創公司的差距，不是誰有沒有用 AI，而是誰能把 AI 系統化得更好。

從 Idea 階段的驗證、MVP 階段的 scope 管理、Launch 階段的系統建立，到 Scale 階段的護城河累積，每個階段都有對應的 AI workflow。真正的 AI-native startup，是能把公司拆成一條條流程，問清楚每個流程需要的是研究、建構、營運還是沉澱，然後再問 AI 在這條流程裡應該扮演什麼角色。

不是用了 AI 工具的公司，是把 AI 變成工作系統的公司——這大概是整部影片最值得記住的一句話。