Claude.ai Founder's Playbook
转载自：https://www.facebook.com/share/19mv7NrfAV/
創辦人實戰手冊：AI 時代怎麼從零開始建一間公司
Claude Blog出了一篇 36頁的 AI時代 founder's playbook，裡面涵蓋了創業和結合AI協作，AI產品應用要注意的事情，內容量極為豐富。
在創業點子的時候，第三章有非常完整的問題健檢和每個階段練習題指南，確定自己的點子真的值得往下。
尤其第四章到第六章，很適合很多在AI時代做出了自己的MVP產品要跨到下一個階段要注意的指南和會遇到的坑，都在這個playbook有講到。
我看完自己是覺得蠻實用的，以此紀錄，也可以建議直接去下載pdf丟到筆記本裡餵給AI。
▍第一章：創業的遊戲規則變了
AI 正在改寫創業的方式。2026 年，從來沒寫過程式的創辦人也能做出可以上線的產品，「十個人的獨角獸公司」從傳說變成了一種刻意的策略。
以前創業有個固定劇本：
驗證想法 → 募資 → 招人 → 開發 → 再募資 → 成長 → 再招人 → 不斷重複。
每進入下一個階段，都需要更大的團隊、不同的技能、新一輪的資金。
現在 AI 打破了這個預設。它可以幫你寫產品程式碼、做市場研究、分析競爭對手、準備投資簡報、自動化日常營運流程。過去那些陡峭的學習曲線被大幅壓平，「誰能創業」這件事的門檻徹底被拉低了。
這本手冊做的事情：
重新繪製創業四個核心階段（想法、最小可行產品、上線、規模化）的地圖，告訴你每個階段在 AI 時代長什麼樣、該用什麼工具、怎麼壓縮時程。
▍第二章：「創辦人」這個角色正在重新定義
▍從「自己動手做」變成「指揮 AI 做」
過去創辦人的價值由「會什麼」決定：技術創辦人寫程式，非技術創辦人跑業務、談客戶。
但 2026 年的 AI 工具把「會做東西的人」和「有好點子的人」之間的牆打掉了。
沒有工程背景的人，現在可以靠 AI 把想法變成可以上線的軟體。技術很強但不懂商業的人，也能用 AI 快速產出市場策略、財務模型、投資簡報（pitch deck）。
創辦人的角色從「做事的人」變成「指揮的人」。你不再是每天埋頭寫程式或處理雜事，而是把大部分注意力放在更高層次的工作上：想清楚方向，然後指揮 AI 工具和小團隊去執行。
最有意義的改變是：當創業不再只限於有工程背景的人，各行各業的專家都能進來創業，解決那些傳統科技創辦人根本不會注意到的真實問題。
▍AI 讓小團隊能做大公司的事
傳統模式認為你需要招工程師來開發、業務來銷售、營運人員來管公司，人數越多代表公司越成熟。
2026 年的早期新創完全不一樣。它們刻意維持極精簡的編制，通常就是創辦人一個人或加上幾個人。靠著 AI 當核心基礎建設，它們可以在還沒擴編之前就達到產品驗證、早期營收、甚至獲利。
AI 在三個領域特別能幫上忙：
▍一、隨時待命的各領域專家
創辦人在第一年需要知道的事情多到數不清：怎麼設定薪資系統？怎麼規劃產品開發節奏？怎麼寫一份好的投資備忘錄（investor memo）？
以前這些問題的答案都是「找一個懂的人來問」。現在你有 AI 當隨時待命的顧問。它能幫你做深度研究（競品分析、市場規模估算、財務建模）、寫各種文件（投資簡報 pitch deck、案例分析、投資備忘錄 investor memo、產品需求文件 PRD）、當你的策略陪練（魔鬼代言人分析、預想失敗情境、路線圖優化）。
▍二、永遠不會請假的開發團隊
以前要做軟體，你得有技術合夥人、外包開發商、或夠長的資金跑道來招工程師。現在 AI 程式開發工具讓你用白話描述想做什麼，AI 就能產生、測試、除錯、重構出可以上線的程式碼。
從「我有個想法」到「我有個產品」的時間被大幅壓縮。
創辦人的角色變成決定「做什麼」和「為什麼做」，AI 負責實際的建造工程。
▍三、自動化的營運團隊
就算你能像顧問一樣做研究、像工程團隊一樣開發產品，還有一大堆日常營運工作要做：排會議、更新 CRM（客戶關係管理系統）、拉週報、維護文件、發內容、追蹤各種待辦事項。
在精簡的新創裡，這些事幾乎都落在創辦人身上，嚴重消耗你該花在重要決策上的時間和精力。
AI 自動化工具可以把這些負擔卸下來。
例如：當客戶推進到下一階段，CRM 自動更新；週報自動產出；產品文件隨著產品更新而同步更新。像 Claude Cowork 這類工具能直接跟你的專案管理工具、溝通軟體、資料來源串接，不需要另外找人來建和維護這些整合。在剛起步的新創裡，「另外找人」幾乎一定是創辦人自己。
▍關鍵在「什麼時候用什麼工具」
能有效運用 AI 研究、自動化、程式開發能力的創辦人，可以打造出遠超過實際人數所暗示的營運槓桿。但這不是設定完就自動跑的。創辦人需要知道在什麼時機、用什麼方式來使用這些工具。這本手冊後面的內容就是在講這件事。
▍第三章：想法階段
核心問題：「這個東西值得做嗎？」
每個創辦人都從同一個起點出發：一個你怎麼想都停不下來的問題。
2026 年創業成功的關鍵是，在證據支持之前忍住不要急著動手做。
這個階段的工作是
- 研究、
- 訪談潛在客戶、
- 分析競爭對手、
- 誠實面對反面證據，
全部都要在你開始寫第一行程式之前完成。
▍這個階段的目標
以研究為基礎的驗證：收集紮實的證據，確認真的有一個夠大的問題存在，而且你提出的方案確實能解決它。
實際上就是依序回答這些問題：
- 這個問題是真的、具體的、而且夠頻繁到值得做嗎？
- 到底是誰有這個問題？這些人組成的市場夠大嗎？
- 有沒有人已經在解決這個問題？做得怎麼樣？
- 一個解決方案需要做到什麼程度才算解決這個問題？我的想法做得到嗎？
最終只需要回答一個問題：這個東西值得做嗎？
你要做的是把觀察變成可以驗證的假設。
「大家覺得報帳很麻煩」只是觀察。「中型企業的財務主管每週花四小時以上在核對報帳資料，因為現有工具沒辦法跟會計軟體串接」才是可以驗證的假設。
▍什麼時候可以離開這個階段
你需要對以下三個問題都回答「是」：
- 問題是真實且具體的嗎？你能指名道姓說出是誰有這個問題、多常遇到、多嚴重、目前怎麼應付。
- 你的方案解決的是正確的問題嗎？不是你一開始假設的問題，而是驗證過程中發現的真正問題。兩者有時一樣，但不一定。
- 你有足夠的信號可以開始做了嗎？在這個階段你永遠不會有百分之百的把握，等到確定才動手本身就是一種失敗模式，但你需要足夠的質化證據，
讓「開始做」成為理性決策而不是賭博。
▍這個階段最常犯的錯
▍錯誤一：把「做出東西」當成「驗證完成」
AI 讓做東西變得太容易了。以前做一個基本的原型需要幾個月，現在可能幾天就搞定。這看起來是好事，但也帶來一個真正危險的陷阱。
統計上，42% 的新創失敗是因為做了沒人要的東西。當「有想法 → 立刻做原型 → 把原型的存在當成驗證」變成常態時，這個失敗率只會更高。
一個能動的原型很容易被誤認為「我正在解決一個真實的問題」，但它不是證據。
原型真正的用途是拿去跟潛在用戶對話時的道具，那些對話本身才是真正的證據。
▍錯誤二：過早擴張
「擴張」不一定是指擴編或大規模投資，而是指在還沒真正驗證假設之前，就把太多精力投入產品開發。
AI 程式開發工具太強大了，你可以在不知不覺中把執行進度推到遠遠超前驗證進度。AI 對一個根本有問題的假設，跟對一個好想法，會付出同樣的熱情來寫程式。
判斷力是你的，不是 AI 的。
這個階段的首要原則是：你的理解要跑在你的產出前面。
▍錯誤三：確認偏誤
你叫 AI 幫你驗證你的創業想法，它會找到支持的證據。
你叫它估算市場規模，它會找到讓你的市場看起來很大的數字。
AI 照你的方向走，意思是一個不問尖銳問題的創辦人，現在能比以往更快地為一個爛點子建構出看起來很有研究基礎的論述，同時還覺得自己做了充分的盡職調查。
解藥是同一個工具，只是方向反過來：讓 AI 攻擊你的想法，找反面證據。
當研究和結構化的對立思考發現你的想法需要修正時，那就是該轉向的信號。
▍在想法階段，AI 怎麼幫你
▍選對工具
如果你要快速問問題、改寫文字、腦力激盪 → 用 Claude Chat
理由：快速、對話式、不用設定。
如果你要深度研究、分析、從多個資料來源產出完整文件 → 用 Claude Cowork
理由：能連結檔案、串接其他工具（Gmail、Google Calendar 等 MCP 整合）、排程自動執行。
如果你要寫程式、測試、部署軟體 → 用 Claude Code
理由：直接存取程式碼庫、Plan Mode 規劃模式、git 版本控制、本機 / IDE / 雲端沙箱開發環境
這三種工具底層用的是同一個 Claude 模型，差別在於周圍的工作環境。
▍定義和壓力測試你的問題假設
你的專業知識和前期研究已經產生了一個假設。第一步是把它磨到夠尖銳、可以測試。
AI 特別適合用來逼出具體性：到底是誰有這個問題、多常發生、多嚴重、他們目前怎麼處理？
練習：跟 AI 一起把你的問題描述磨到可以測試的程度。
例如：「合約審查太慢了」不算可測試。「中型企業的法務團隊每次審約需要三天以上，因為修改意見散落在各個 email 裡，沒有一個統一的版本管理」才是可測試的。
接下來，叫 AI 反過來攻擊你的想法，找出可能推翻你假設的證據。這能挖出負面的市場信號、失敗的競爭對手案例、客戶行為模式、結構性障礙，這些都是正面分析會忽略的東西。
目標是在你去跟潛在用戶做訪談之前，就已經用最強的反面論點壓力測試過你的假設，這樣你的訪談才會是真正開放式的探索，而不是找人來確認你已經相信的事。
把 AI 當結構化的魔鬼代言人，是創業每個階段都適用的核心用法。
▍市場研究和競爭版圖分析
▍看清你的競爭對手
創業有一個常見的盲點叫「競爭者忽視」：你太專注在自己的願景和執行上，系統性地低估了別人在做同樣的事。
AI 是解藥：叫它幫你論述為什麼某個競爭對手會成功而你不會。
練習：叫 AI 按層級畫出你的競爭版圖：直接競爭者、間接競爭者、可能的收購方、以及相鄰領域可能殺進來的玩家。
然後叫它論述每一層為什麼對你構成真正的威脅，不是那種你最容易反駁的版本。
▍市場研究
AI 能幫你整合公開的客戶評價，找出反覆出現的抱怨和未被滿足的需求。這基本上是免費的競品客戶質化研究。
練習：叫 AI 整合競爭對手在各大平台上的用戶評價，找出現有方案一直沒解決的前幾名抱怨。如果你的假設剛好解決了其中幾個，那是問題-方案契合度（problem-solution fit）的強力證據。如果沒有，那也值得知道。
AI 也能從產業報告、分析師文件、市場研究中萃取關鍵資訊和數據，這些整理過的素材會成為後續分析的好基底。
練習：用公開數據建立市場規模模型（總可觸及市場 TAM／可服務市場 SAM／可取得市場 SOM），並壓力測試背後的假設。判斷這個市場是在擴張、整合、還是已經成熟。畫出買方地圖：誰有預算、誰影響決策、這兩者是不是同一個人。
▍趨勢分析
用 AI 去聽市場上的早期信號，判斷你是不是在對的時間點切入。
追蹤那些已經在討論你要解決的問題的社群（Reddit 上的 subreddits、LinkedIn Groups），記下用戶描述問題時用的確切語言。找出類似的市場中，類似問題是怎麼被解決的，什麼有效什麼沒效。挖出可能加速或威脅你機會的法規、技術、或人口趨勢。
練習：叫 AI 找出三個外部趨勢（法規、技術、或人口方面），可能在未來兩年內顯著影響你的市場，並評估每個趨勢對你的假設來說是順風還是逆風。
市場研究和競爭分析不是一次性的作業。隨著你的想法演化，在最小可行產品和上線階段都應該重複這些練習。
▍規劃和設計客戶訪談
跟潛在用戶對話時你能學到多少，取決於兩件事：你問的問題品質，以及你問對人了沒有。
▍找對人
精準的目標人物比一長串名單有價值得多。
你要定義出具體的職稱、公司類型、團隊結構、資深程度，然後找出這些人實際上在哪裡可以接觸到：社群、活動、LinkedIn Groups、Slack 社群。
建立優先順序：誰跟問題最近的先找。
▍問對問題
用 AI 來設計訪談框架：對的問題、對的順序，設計成能挖出人們「實際做了什麼」而不是「覺得自己會做什麼」。
菜鳥創辦人常犯的錯是問面向未來的泛問題（「你會用這種東西嗎？」），而不是問過去的具體經驗（「上次你遇到這個問題時是怎麼處理的？」）。
AI 能幫你檢查你的草稿問題是不是在引導受訪者、太廣泛、或者可能產生噪音而不是有用的信號。如果你的假設涉及不只一種人物角色（persona），AI 也能為每種角色設計不同的問題組。
練習：先自己手寫訪談問題，然後叫 AI 審查。請它特別標出任何引導性的、面向未來的、太廣泛的、或可能讓受訪者給出社交期望答案的問題。然後請它針對訪談中最可能遇到敷衍回答的兩三個時刻，設計追問策略。
▍訪談後的分析
每次對話結束後，把筆記給 AI，讓它找出哪些確認了你的假設、哪些挑戰了它、哪些是真正令人意外的。累積了一批訪談後，用 Claude Cowork 跑一次完整的筆記分析，找出反覆出現的主題、矛盾、以及雙向最強的信號。
然後問它：你自己對資料的解讀，有沒有可能是在配對你想聽到的東西。
練習：每做完五場訪談，讓 AI 整合筆記產出兩張清單：支持你假設的證據，和挑戰你假設的證據。如果第一張清單明顯比第二張長，問 AI 這個不對稱性是反映資料的真實面貌，還是你希望看到的結果。
▍客戶外展和排程
用 Claude Cowork 來處理建立聯絡名單、寄信、排訪談這些操作層面的工作。
它能幫你根據目標人物特徵去研究和整理名單、寫客製化的外展信件、管理回信、透過 Gmail 和 Google Calendar 的 MCP 串接排會議、追蹤每個聯絡人的進度。你只需要專心準備對話內容。
練習：給 Claude Cowork 你驗證過的訪談目標人物特徵，請它建立潛在名單、寫客製化的外展信件序列、建立一個追蹤表（包含外展狀態、跟進節奏、訪談完成度欄位）。讓它跑行政協調，你專心準備對話。
▍設計你的最終方案概念
驗證工作做完了：
- 問題是真的、
- 你知道誰有這個問題、
- 你有證據支持的方案概念。
用 AI 從每個角度去挑戰你的方案：
- 缺口在哪裡？
- 有什麼替代方案？
- 這個方案要在什麼條件下才能大規模運作？
這是一個重要的現實檢查點：
你的設計解決的是驗證過程中揭露的問題，還是你一開始走進來時假設的問題？
練習：把你的方案概念給 AI，請它找出你的設計最依賴的三個假設。
然後問：每個假設要成立的話需要什麼條件？如果任何一個不成立，後果是什麼？
▍做一個輕量原型
現在才是好玩的部分。有了驗證過的假設和壓力測試過的方案概念，你終於可以開始做東西了。
這是想法階段中 Claude Code 正式登場的時刻。
就算你之前一直在小規模嘗試，現在才是產出正式輕量原型的時間點：最小的功能範圍，夠讓一個真人看到你的想法並產生真實反應就好。你不是在做一個真正的產品（還不是），你是在做一個可以拿去跟客戶和投資人對話的功能樣品。
練習：定義你的方案最核心的那一個互動。用 Claude Code 只做那個。做好之後拿給五個符合你目標人物的人試用。你在那五場對話中學到的東西，決定了你是繼續做，還是回到原點重來。
走到想法階段的終點是一個巨大的跳躍，因為你不再是在賭一個直覺，你是在根據證據來執行。
接下來進入最小可行產品階段，主要問題從「這個值得做嗎？」變成「我們第一步到底該做什麼？」，AI 的主要角色從研究夥伴轉變成施工團隊。
▍第四章：最小可行產品階段
核心問題：「我該做的最小版本是什麼？人們會不會真的用它？」
很多創辦人把這個階段當純粹的開發階段，但它仍然是一個收集證據的過程。
差別在於你現在收集的是關於「方案」的證據，而不是「問題」的證據。
具體來說：
有沒有一群明確的人覺得它有價值、會使用、會回來用、願意付費、或願意告訴別人？
▍這個階段的目標
三個並行的目標：
- 把驗證過的問題變成真人會用的產品。不是完整版本，而是最小、最聚焦的版本，能放到真人面前並產生「產品-市場契合度」（product-market fit）的真實證據。
- 快但不要埋地雷。你現在怎麼做，決定了以後能走多遠。太趕的程式碼在真正有大量用戶時會爆炸。
- 從第一天就建立持續的知識脈絡。在 AI 時代的新創裡，你的程式碼是你跟 AI 一次又一次合作的結果，這讓程式碼的可讀性成為基礎。跳過規格書、架構決策文件、和上下文檔案（如 CLAUDE.md）的創辦人，遲早會撞上一面牆：每次新的工作都要重新解釋一遍背景，AI 產出的東西會越來越偏離你的原始設計。
▍什麼時候可以離開這個階段
你需要有「產品-市場契合度」的真實證據：一群具體、可辨識的用戶覺得你的產品有價值，
- 願意持續回來用（留存）、
- 願意付費（營收）、或
- 願意告訴別人（推薦）。
▍這個階段最常犯的錯
▍錯誤一：AI 時代的技術債
速度是保證的，AI 幫你消除了所有讓東西進入產線的自然瓶頸。但如果速度是你唯一考量的變數，你會累積未來很難還清的技術債。
有些技術債在這個階段是合理的，但需要被管理。
問題在於，如果你的架構決策和設計原則沒有寫下來放到 AI 讀得到的地方，每次跟 AI 工作時它都得從頭猜你的意圖，每次猜的結果都不太一樣。最後你的程式碼會變成一堆功能上可以跑、但結構上完全不成體系的東西，不是因為任何一塊寫得不好，而是這些塊從來就沒被設計成要彼此配合。這種問題通常在後期才會浮現，而且代價很高。
▍錯誤二：把早期成績當成產品-市場契合度
發布產品後看到用戶增長是創辦人最爽的體驗之一。但早期的成長跟真正的產品-市場契合度是兩回事。發布初期的動能來自短暫的力量：你的朋友、投資人介紹的客戶、Hacker News 首頁曝光。這些都不能可靠地預測六週後或十二週後會發生什麼。
▍錯誤三：零阻力的範圍蔓延
當做東西幾乎免費又快速時，你總是覺得「再加一個功能」「再處理一個邊界情況」。每一個單獨看都說得通，因為每個都花不了多少時間。但隨著產品不斷超出原始邊界，你會失去方向和動力。
解藥是在開始做之前就寫好範圍定義：
- 這個產品做什麼、
- 刻意不做什麼、以及
- 什麼樣的真實用戶證據才能合理化加入新東西。
決策點從「我們應不應該做這個」變成「有夠多用戶告訴我們，沒有這個他們就沒辦法用我們的產品」。
▍錯誤四：經驗不足導致的安全疏忽
AI 程式開發工具產出的是「能動的程式碼」，不是「安全的程式碼」。功能面很好判斷，能動就是能動。
安全漏洞是看不見的，直到被利用才會發現。
把產品交給真人使用就意味著真實的數據、真實的曝險、如果出事就是真實的後果。
在任何用戶接觸你的產品之前做一次安全檢查，是釋出最小可行產品的最低負責任門檻。
▍在這個階段，AI 怎麼幫你
▍先定義架構，再開始寫程式
在 Claude Code 寫第一行正式程式碼之前，先用 Claude 定義和記錄架構決策：
- 該遵循什麼模式、
- 該避免什麼依賴、
- 做了什麼取捨以及為什麼。
這份文件會成為後續所有開發工作的護欄。
沒有這個背景，每次開發都從零開始，Claude Code 必須自己推測結構假設。讓它在沒有護欄的情況下開發，產出的程式碼功能上可以跑但結構上不一致，而且在這種基礎上迭代或擴展最終是浪費時間和 token。遲早會到一個臨界點，程式碼崩潰，你被迫從頭重做。
練習：在開始開發之前，描述你在做什麼：核心解決的問題、服務的用戶、未來六個月預期的規模。請 Claude 幫你定義你的開發架構原則、該避免的依賴、以及你在這個階段有意識地接受的取捨。
然後把結果存成 CLAUDE.md 檔案。CLAUDE.md 是 Claude Code 的專案級指引檔，放在你的專案目錄裡，Claude Code 每次啟動時會透過 Agent SDK 自動讀取，功能上等於你這個專案的持久記憶。
這是你的第一份建造成果，也是後續每次開發都依賴的基礎。
▍定義和守住你的產品範圍
就像你定義了應用架構一樣，你也需要在開始做任何功能之前定義你的產品範圍。
用 Claude 建立一份範圍文件：
- 這個產品做什麼、
- 刻意不做什麼、以及
- 什麼樣的真實用戶證據才能合理化新增功能。
當新的功能想法出現時，用 Claude 來壓力測試它到底是來自用戶的真實需求，還是創辦人的熱情披著產品思維的外衣。
▍用 Claude Code 建造你的產品
架構和範圍定義好之後，Claude Code 成為主要的建造工具。用它來產生、測試、除錯、迭代你的程式碼，但把每次開發當成執行你已經做過的產品決策，而不是趁機加新東西進去。
每次開發開始前先重新看你的範圍文件和 CLAUDE.md 架構背景文件。
每次結束後更新它，記錄這次做了什麼、做了什麼決定、引入了什麼假設。
每次花五分鐘寫紀錄，就是對抗架構偏移的廉價保險。
▍上線前做安全檢查
在部署給任何真實用戶之前，跑一次你核心程式碼的安全審查：
- 檢查身份驗證和連線處理、
- API 回應中的資料曝險、
- 輸入驗證和注入風險、以及
- 有已知漏洞的依賴套件。
對每個發現認真以待，涉及身份驗證、金鑰、或資料處理的部分要人工複查。
Claude 能做一個有用的初步安全審查，幫你識別常見漏洞，養成在發布前檢查的習慣是好的。但它不能取代專業的安全工具。
Claude Code Security 更進一步：它能掃描整個程式碼庫找安全漏洞，並為人工審查建議針對性修補，能挖出傳統方法可能遺漏的問題（這個功能在本手冊出版時仍是有限測試版，使用前請確認最新狀態）。
▍在上線前就建好衡量框架
把早期成長誤認為產品-市場契合度的創辦人，通常都是在上線之後才開始追蹤數據，而且選的指標是用來看「什麼有效」而不是「什麼沒效」。
在第一個用戶出現之前就建好衡量框架。
用 AI 定義
- 哪些指標對你的產品真正重要、
- 基準值是多少、
- 什麼樣的數據模式才算真正的產品-市場契合度
而非好看但空洞的數字。
具體來說：在發布前就設定好
- 留存率基準、
- 啟用標準、
- 第 7 天（Day 7）和第 30 天（Day 30）目標。
定義你的產品的「假陽性」長什麼樣：
- 有註冊但沒啟用、
- 有營收但沒留存、
- 有初期熱情但沒回頭客。
數據來了之後，叫 AI 對你自己的成長數據做魔鬼代言人分析：一個懷疑論者會怎麼看這些數字？
▍管理用戶回饋的流程
真實用戶進來之後，營運面的工作量會快速擴大。
用 Claude Cowork 來處理建立和維護用戶聯絡名單、寄信安排回饋訪談、分類處理錯誤回報、追蹤迭代循環這些重要但繁瑣的工作。
想法階段用來管理客戶訪談行政的那些 MCP 整合，在這裡同樣適用。
但在收集用戶回饋時要保留人的判斷。
用戶說「這個很棒，但我希望它還能⋯⋯」需要你來判斷：
- 這是核心需求還是錦上添花？
- 這是這個客戶特有的還是代表一個群體？
- 缺少的功能是真正的問題，還是上游的使用流程有問題？
沒有工具能回答這些問題。
練習：設定 Claude Cowork 來跑你的回饋循環：寫信給早期用戶、排回饋訪談、設計錯誤回報和功能需求的結構化收件流程、寫週報摘要。自己先看週報摘要，然後再讓 Claude 分析看有沒有你漏掉的重要資訊。
▍朝向證據迭代，不是朝向完整迭代
這個階段結束的標準是你有了產品-市場契合度的真實證據，不管產品感覺有多「完成」。
宣告你達到了產品-市場契合度，是一個結合創辦人直覺和收集到的證據的判斷。
有一些實用的判斷方法：
- Sean Ellis 測試：問你的活躍用戶：「如果你再也不能用這個產品了，你會覺得怎樣？」如果超過 40% 回答「非常失望」，那是一個有意義的信號。
- 力道測試：在找到產品-市場契合度之前，留住用戶需要你不斷地主動出擊：頻繁聯繫、提供誘因、個人跟進。找到之後，產品開始自己做這件事。當用戶是被「拉進來」而不是被你「推進去」的，那個力道的轉換是最清楚的信號之一。
沒有任何單一數據點能確認產品-市場契合度，它是一個需要在多個迭代循環中維持的模式。
▍該轉向就轉向
如果投入了所有這些工作，你就是到不了產品-市場契合度怎麼辦？
結果不支持你一開始的方向，這不是失敗，這是系統在正常運作：這個階段就是設計來在你過度投資錯誤答案之前把這個資訊挖出來的。
當數據不支持你目前的產品時，用 Claude 來分析數據到底在告訴你什麼：
探索其他客戶群。也許不轉換的用戶根本就不是對的目標。正確的受眾可能已經在你的數據裡，只是比例被低估了。
調整你的價值主張。也許受眾是對的，但你的產品就是沒引起共鳴。調整引導流程（onboarding）、訊息、或核心功能重點，有可能不改產品就解決問題。
也要開放面對可能需要更根本改變的情況。
練習：如果你已經完成三個以上的迭代循環，但在產品-市場契合度指標上沒有明顯進展，在決定下一步之前先用 Claude 跑一個診斷。給它你的留存數據、用戶回饋、和原始問題假設，問三個問題：
- 數據中有沒有某個群體的反應跟其他人明顯不同？
- 設計價值和體驗價值之間的落差，是定位問題還是產品問題？
- 目前的產品要找到真正的產品-市場契合度需要什麼條件成立？根據你看到的情況，那個情境現實嗎？
讓答案來決定你是調整、轉向、還是回到想法階段。
▍第五章：上線階段
核心問題：「從產品能用，到公司能跑。」
如果最小可行產品階段是在證明你的產品值得存在，上線階段是在證明你的事業值得成長。
▍這個階段的目標
把早期的成長動能變成可重複、可持續的成長引擎。
除了讓產品達到正式上線水準，你還必須強化底層的基礎建設，同時圍繞產品建立一間真正的公司。
在想法和最小可行產品階段，新創天然是以創辦人為中心的，因為你需要完整的情境感知和緊密的回饋循環。但現在，還試圖親自掌握每一條線索的創辦人會變成瓶頸。
目標不是把自己從公司抽離，而是建立營運系統來釋放你的注意力，讓你能處理只有創辦人才能做的決策。
▍什麼時候可以離開這個階段
三個要素同時滿足：
- 成長是可重複且有管道驅動的。你不只是留住用戶，你是透過特定管道可預測地獲取他們，而且你知道單位經濟指標（獲客成本 CAC、客戶終身價值 LTV、回本週期 payback period）並且說得出來。
- 產品能承受正式上線的工作量。基礎架構夠硬、安全和法規遵循到位、在真實營運條件下穩定運作。
- 營運不再以創辦人為瓶頸。流程已經存在，自動化已經到位。你不再是那個親自處理客服、分類待辦、規劃開發節奏、或做報告的人。
▍這個階段最常犯的錯
▍錯誤一：技術債到了該還的時候
在最小可行產品階段，為了速度而累積一些技術債是合理的取捨。到了上線階段，這些債開始計利息，拖得越久修起來越貴。
解決方法是做一次系統性的架構審計，找出結構性弱點，有針對性地重構最嚴重的部分，並大幅擴充測試覆蓋率，確保下一輪功能開發不會重新引入同樣的問題。
▍錯誤二：創辦人變成瓶頸
在最小可行產品階段，創辦人參與每個環節是資產。到了上線階段，當客服量增加、產品決策堆積、營運複雜度倍增，同樣的習慣變成了制約。
從「自己做事」轉變成「設計系統來做事」是創業生命週期中最難的轉換之一。因為很少有一個清楚的時間點告訴你該轉了，風險是你完全錯過這個時機，繼續停留在執行模式，而整個組織在你周圍停滯。
幾個警訊：
- 應該花一小時就能決定的事情，你花了一週才輪到處理；
- 客服問題堆積因為只有你知道答案；
- 營運任務只在你個人記得的時候才會發生。
解藥是徹底盤點你目前親自處理的所有事情，從最小的任務到最重要的決策，找出
- 哪些可以系統化、
- 哪些可以授權、
- 哪些真的需要創辦人的時間。
▍錯誤三：安全和法規遵循不能再拖了
在最小可行產品階段只有幾個測試用戶、沒有敏感數據在線上，安全漏洞是理論上的風險。但你的產品正式上線的那一刻，理論風險變成了真實曝險。如果你在處理客戶數據、處理付款、或賣給受監管的產業，法規遵循要求是必須面對的。
解決方法是在正式大量上線之前（而不是之後）做一次系統性的安全和法規遵循審查，把每個發現都當成必須修復的項目。
▍錯誤四：還沒準備好就擴張
新市場和新的資金機會看起來像成長機會，但它們也可能是產品-市場契合度被稀釋的地方。
你的早期成長是真實的，但也是針對你的早期受眾的。
太早進入一個跟原來明顯不同的市場，會引入新的用戶行為、法規要求、支付基礎設施、和基本預期，你的產品不是為這些設計的。突然間太多新變數出現，你失去了解讀自己數據的能力。同時你也可能在追逐新受眾的過程中忽略了原有的用戶群。
▍在上線階段，AI 怎麼幫你
Claude Chat、Claude Code、Claude Cowork 三種工具在這個階段全面啟用，而且互相支援：每個工具的產出會成為其他兩個的輸入。效果是加乘的。
這就是極精簡新創模式在結構上可行的原因。
- Claude Code 做產品、
- Claude Cowork 在產品周圍建立公司營運、
- Claude Chat 幫你將產品和組織知識落地。
小團隊能像大公司一樣運作。
▍修技術債，趁它沒變成結構性負債
你的最小可行產品程式碼能跑，但需要一次系統性的修復。
用 Claude Code 跑一次完整的架構審計：找出哪裡脆弱、哪些捷徑未來維護成本很高、哪裡的測試覆蓋率薄到下一輪功能開發會重新引入同樣的問題。
把審計結果丟回給 Claude 做分類和排序：
- 什麼必須在下一次發布前修好、
- 什麼可以再等一個開發週期、
- 什麼是你目前階段可以接受的持續性債務。
這也是把你在最小可行產品階段做的架構決策（那些一直只存在你腦袋裡的）寫進 CLAUDE.md 的時機。現在記錄下來，確保以後每次 Claude Code 開發都從共識出發。
練習：用 Claude Code 審計你的程式碼，產出一份按優先順序排列的結構弱點、測試覆蓋缺口、重構候選清單。然後把這份清單丟給 Claude，請它把修復工作安排在接下來幾個開發週期裡：
- 哪些要最先處理、
- 哪些可以跟功能開發平行、
- 哪些可以再等。
▍建立系統來取代創辦人的注意力
建立營運系統來釋放你的注意力，第一步是弄清楚你的注意力到底花在哪裡。
用 Claude Cowork 跑一次結構化的營運負擔盤點：記錄每個重複性任務、每個落到你桌上的決策、每個只因為你個人記得才會執行的流程。
然後讓它把這份盤點分類：可以完全自動化的、需要人但不一定要你的、真正需要創辦人判斷的。
盤點完成後，用 Claude Cowork 設計自動化的流程邏輯：什麼觸發每個流程、決策規則是什麼、輸出是什麼、完成後送到哪裡。
▍讓安全和法規遵循成為常態工作
用 Claude Code 找出你的目標市場要求的安全和法規框架（SOC 2、GDPR、HIPAA 等）中常見的程式碼層級問題。
這會同時挖出安全漏洞和法規遵循差距。把這些發現丟給 Claude 幫你排修復優先順序，並設計企業客戶簽約前會要求看到的控制措施、稽核日誌、和存取管理。
接下來，把法規遵循工作融入你的開發循環，而不是當成一次性專案。法規文件需要持續維護和更新。對準備進入企業合約或國際市場的創辦人，這也是 Claude Code Security 掃描可以幫你為獨立安全評估做準備的時機。
練習：用 Claude Code 做一次針對你目標市場法規要求的程式碼安全審查。把結果丟給 Claude，請它產出兩樣東西：按優先順序排列的安全修復計畫，以及一份清單列出你需要準備的文件和控制措施，好通過企業採購方的法規審查。
▍建立你一直跳過的產品管理流程
上線階段需要一套輕量、可重複的流程，能在不需要創辦人介入的情況下運作。
用 Claude 設計你的產品開發節奏和工作循環如何結構化、一份功能規格需要包含什麼才能開始開發、錯誤回報怎麼分類和分派、每週指標報告涵蓋什麼以及怎麼發送。
流程設計好之後，用 Claude Cowork 來建立和運行營運層：排開發儀式、分派錯誤回報、從連接的數據源編寫每週指標報告、維護讓用戶信號持續流入產品決策的回饋循環。
練習：請 Claude 設計一套輕量的產品管理作業系統：定義好的開發節奏、最低規格模板、錯誤分類決策樹、從你的數據源拉數據的每週指標簡報。然後設定 Claude Cowork 來執行這個系統的重複性營運元素（排程、分派、報告編制），讓它按時自動運行。
▍第六章：規模化階段
核心問題：「從新創公司變成一間真正的企業。」
在規模化階段，創辦人的角色從建造者轉向對外的經營者。產品仍然是核心，但你每天的實際工作越來越多是關於公司本身。你的注意力必須擴展到分析師簡報（analyst briefings）、IPO 路演（IPO roadshows）等新的活動，同時維持精簡、以 AI 為中心的結構優勢。
▍這個階段的目標
技術基礎建設的擴展工作持續進行，同時加入了組織本身的擴展和業務成熟化的工作。
你面對的是從幾千個用戶到幾百萬個、從一個市場到多個市場的跨越。在之前的每個階段，你靠著貼近用戶和緊密的回饋循環來感覺自己的路。現在，目標是建立由成熟組織營運支撐的系統性成長。
對 AI 時代的新創來說，你的目標應該是透過累積的深度來建立防禦性護城河（defensible moat）。這個深度來自三個地方：你融入產品的專業知識、你的產品跟用戶其他工具和平台的整合深度、以及你累積的用戶數據和工作流程。一直在同一個方向、用一致的基礎建設持續建造的創辦人，現在擁有了真正難以複製的東西。
在這個階段，公開投資人、分析師、監管機構、企業採購團隊和收購方會帶來更大的壓力和更多的質疑，因為賭注更高了。你的產品和組織必須經得起外部檢視：不只是你做了什麼，還有治理、法規遵循態勢、財務控制、和策略敘事。
▍什麼時候可以離開這個階段
規模化的退出條件不再是單一里程碑，而是一個門檻事件：公司即使創辦人越來越不直接參與日常營運也能持續運作。你已經展現了系統性的成長；建立了能滿足最嚴格外部審查的組織治理和法規遵循基礎建設；而且你對「如果一個資金充裕的巨頭今天複製你的產品，你的用戶會留下嗎？」這個問題有一個紮實的答案。
實際上，這個門檻通常以三種形式之一出現：不再需要外部資本的可持續獲利、準備好 IPO（首次公開募股）、或被收購。三者都要求你的成長是系統化且可稽核的、你的產品護城河經得起檢視、你的組織在營運上是成熟且可持續的。當這些都成立的時候，恭喜：你的新創從一個賭注變成了一門生意。
━━━━━━━━━━━━━━━━━━━━
▍這個階段最常犯的錯
▍錯誤一：放手讓系統跑
你在上線階段建立了這些系統，現在的工作是讓它們成熟到完全可信任，然後真正去信任它們。
這比聽起來難。即使你很擅長授權，什麼該放手、什麼該留在手上不一定總是清楚的。放太多太快，重要決策在缺少只有創辦人才有的關鍵脈絡下被做出。抱太久，你又變成瓶頸。
根本的挑戰是把只存在創辦人腦袋裡或未記錄流程中的組織知識，編成文件化、可稽核、可移轉的系統。
▍錯誤二：技術營運的擴展
客戶不再只評估你的產品，他們想知道你的組織能不能成為一個可靠的基礎設施夥伴。前幾個階段的技術挑戰集中在程式碼本身。到了規模化階段，挑戰變成程式碼周圍的一切：客服支援基礎設施、技術文件、SLA（服務等級承諾），這些代表你的組織成熟度。大客戶和簽多年合約的機構買家在簽約前會要求看到這些，簽約後也會要求你遵守。
▍錯誤三：組織功能的擴展
規模化的公司通常需要招聘、薪資、會計、法務等組織基礎建設，不管你有多少人。在上線階段，系統化營運意味著自動化那些消耗創辦人注意力的工作流程。規模化的新創現在需要建立更廣泛的營運功能：財務報表、法規遵循監控、合約管理、客戶支援等等。
▍錯誤四：建立市場拓展功能（GTM）
自然成長有天花板，大部分規模化階段的創辦人在還沒正式建立 GTM（go-to-market）功能之前就碰到了。
想法、最小可行產品、上線階段的成長通常來自創辦人親自銷售，從 Product Hunt 的發文到跟早期客戶的個人關係。但這只能到某個程度。到了規模化階段的跡象包括：用戶增長曲線變平、獲客成本上升、業務管道只有在創辦人親自介入時才會推進。規模化需要建立一個專門的成長引擎來觸及你的產品的更廣泛受眾。大部分創辦人可能從來沒有跑過行銷、銷售、分析師關係（analyst relations）等項目。一個正式的市場拓展需要建立新的系統和流程，也需要創造一個品牌聲音和故事來講述你的產品。
好消息是，GTM 功能不需要龐大才能有效，同樣的 AI 基礎設施可以幫你從零開始建立。
▍在規模化階段，AI 怎麼幫你
早期階段用 Claude 當產品的基礎建設：想法階段的研究夥伴、建造原型的工程團隊、讓單人新創成為可能的 AI 營運層。到了規模化階段的 AI 新創創辦人，可以用 Claude Chat、Claude Code、Claude Cowork 繼續用同樣的方式擴展。
▍把日常工作交出去
用 Claude 清楚盤點你現在最需要把時間和注意力花在哪裡。它可以幫你列出在這個階段只有你應該做的事情，例如：產品敘事決策、董事會關係、企業大客戶、創辦人對創辦人的對話。不在這份清單上的東西，都是可以授權或交給 Claude Cowork 自動化的候選者。
練習：用 Claude 產出一張你目前營運層的瓶頸地圖：每個流程、決策、審核如果你一整週不在會怎樣。那些會停下來的流程，就是你還太親力親為到會拖延進度的地方。接下來壓力測試你已經建好的系統是否真的準備好隨著業務成長而擴展。
練習：用 Claude 畫出你目前的工作流程，問它每一個在你缺席一週的情況下會發生什麼。那些會停滯的流程，就是交接標準、升級路徑、或例外處理還需要加強的地方。Claude 能幫你分析故障點並建議修復方案，然後你可以據此更新或替換 Claude Cowork 的自動化流程。
▍把技術營運擴展到企業級基礎建設
隨著你的擴張，買家需要確信你的產品和組織能被信任為長期基礎設施。程式碼內的技術工作照常進行，但現在還有程式碼周圍的技術工作要處理。
第一步是把組織知識轉化成可以擴展的系統。用 Claude 撰寫和維護企業採購方預期看到的書面基礎建設：產品文件、客服操作手冊、SLA（服務等級承諾）。
同時，用 Claude Code 對照企業合約要求的可靠性和安全標準，稽核和強化你的程式碼。建立技術支援基礎設施：日誌記錄、監控、事件回應工具、以及讓 SLA 能實際執行的可觀測性層（observability layer）。這些是過去靠 Discord 社群支援時不需要提供的。
Claude Cowork 則運行企業支援的營運層：工單分派、升級流程、產品變更觸發的文件更新、續約追蹤、以及企業客戶成功所依賴的報告節奏。三者合在一起，讓小團隊能展現出大組織的支援態勢，這正是簽下多年企業合約需要你證明的。
練習：挑出你最嚴格的三個潛在客戶，或找出你最想簽下的三個理想客戶。請 Claude 做一份缺口分析：這些客戶的企業採購團隊在簽多年合約之前預期看到什麼文件、SLA、和支援基礎建設？你目前哪裡不足？用結果來安排跨 Claude Code 和 Claude Cowork 的技術和文件工作。
▍建立真正的 GTM 功能
創辦人的親力親為讓你走到這裡，但擴展你的新創需要建立並實施一個正式的市場拓展策略。AI 能幫你從零開始建立，然後運行完整的 GTM 引擎。
Claude 能協助建立基礎的市場拓展資源：市場區隔、訊息架構、分析師關係（analyst relations）策略、銷售操作手冊（sales playbook）、以及面向投資人的指標敘事。每個受眾（公開投資人、企業買家、華爾街（Wall Street）分析師）都有自己的語彙，用自己的標準來評估你。Claude 的工作是把你的產品價值翻譯成對每個受眾群體都有意義的產品行銷方法。
Claude Cowork 可以成為你的戰術執行層：內容產出流程、外展信件序列、分析師簡報行政、新聞室和公關節奏、CRM 維護、業務管道報告，以及各種把市場拓展策略變成實際商業動能的重複循環。
當市場拓展需要產品行銷基礎建設時（互動式產品展示環境、整合文件、沙箱帳號、API 參考文件、技術摘要），Claude Code 能幫你建。企業買家期望從技術面評估你的產品，在規模化階段，一個螢幕錄影和銷售簡報已經不夠了。這也是讓你的市場拓展能非同步運作的基礎設施：一個做得好的產品展示環境在你開董事會的時候也在幫你成交。
▍把你的專業知識和組織知識轉化成 AI 能讀懂的脈絡
很多精簡新創的創辦人是為他們在特定領域中親身經歷或觀察到的真實問題在做產品。AI 現在讓從來沒寫過程式的創辦人也能用他們的領域專業知識來建造解決複雜問題的產品。Claude Chat、Claude Code、Claude Cowork 各自在把創辦人知識轉化成加乘的產品專業度上扮演角色。
用 Claude 來捕捉、組織、和精煉創辦人的知識，把領域專業放到產品能觸及的地方。透過持續的對話、專案（Projects）、和記憶（Memory）功能，創辦人可以把他們知道的一切（行業術語、法規陷阱、邊界情況、為什麼那些顯而易見的答案行不通的原因）變成結構化、可搜尋的脈絡。Skills 則能把反覆出現的工作流程（例如「我怎麼審一份商業租約」「我怎麼分類一份病人入院表」）編成可重用的例行程序，讓 Claude 每次都用同樣的方式執行。經過幾個月，這會變成一個沒有通用型 AI 能匹配的專有知識基底。
把你的領域知識外化後，用它來把行業特有的邊界情況編入你的產品：例如一個通用型的醫療帳務 AI 工具會在 340B 藥物計畫（340B drug program）的報帳上出錯，但你的產品有針對這些情況的特定邏輯。Claude Code 幫你把你的領域中其他專業人士常見的困擾，轉化成驗證邏輯、提示詞優化、或跟某個小眾行業系統的 MCP 整合（你的競爭對手可能聽都沒聽過）。結果是，你的產品的深度和廣度持續以競爭對手根本無法複製的方式加乘。
練習：找出一個通用型競爭對手在你的垂直領域絕對會搞錯的邊界情況。用 Claude Code 根據你實際見過的場景為它建一個專門的測試案例（不是單元測試，是基於真實場景的測試案例）。每次出現類似的邊界情況就加進去。你的測試案例集會變成一張你的護城河地圖。
▍把累積的用戶數據變成防禦性優勢
隨著用戶跟你的產品互動，他們產生行為信號（哪些輸出他們接受、哪些他們拒絕），這些信號影響你的產品路線圖。隨著時間推移，你會了解你特定用戶群的具體模式、偏好、和邊界情況。這就是所謂的複利效應（compounding value）：每次改進讓產品更好用，帶來更多使用，產生更多回饋，驅動更多改進。
這些數據是有時間鎖定的、特定脈絡的、不可能被模仿者重建的：你買不到幾千個用戶在你的產品裡持續優化他們工作流程的行為指紋。用 Claude 幫你稽核你收集到的用戶互動數據，找出其中最有信號的行為模式，設計把持續使用轉化成系統性模型改進的回饋循環。
練習：把你的產品互動數據摘要給 Claude：你收集了什麼、收集了多久、以及你知道的用戶隨時間如何跟產品互動。請它找出數據中三個最有信號的行為模式，為每一個設計一個把它轉化成系統性模型改進的回饋循環。然後請它幫你寫一頁護城河敘事供產品行銷使用：你的數據飛輪（data flywheel）怎麼運作、轉了多久、以及為什麼一個資金充裕的競爭對手今天開始也無法在兩年內複製。
▍建立工作流程鎖定
數據的網絡效應讓你的產品更難被複製，而用戶工作流程鎖定（workflow lock-in）讓你的產品更難被離開。
用戶越長時間在日常營運中使用你的產品，它就越深入嵌在他們的工作方式中。他們在上面建了自動化、訓練了人員、連接了數據源和其他工具。他們發展出的提示詞、優化過的工作流程、標準化的產出，都是圍繞你的產品的功能和運作方式塑造的。到了這個程度，轉換從一個產品決策變成了一整個營運專案。
建立工作流程鎖定的第一步是用 Claude 按整合深度來分析你目前的客戶群。對每個客戶群，找出他們在你的產品上面建了什麼工作流程、依賴哪些整合。這告訴你你的產品在哪裡黏住了、哪裡需要更深入。
你提供越多整合，客戶就有越多空間建構依賴你的產品的工作流程。Claude Code 幫你快速建立跟你目標用戶依賴的數據管道、專案管理工具、和其他系統的原生整合。它也能建 API、webhooks、和 SDK，讓客戶不只是用你的產品，而是在你的產品上面建東西，這是最深層的鎖定形式。
練習：請 Claude 幫你為你的前十大客戶建一份工作流程整合審計。對每一個，記錄他們建的自動化、依賴的整合、透過你產品運行的團隊工作流程、以及你估計的轉換成本（switching cost）。然後請 Claude 找出跨群體的模式：什麼類型的整合為你的產品創造了最深的鎖定，以及你能做或啟用什麼來加深那些目前只在表面的客戶的整合。
━━━━━━━━━━━━━━━━━━━━
▍第七章：同樣的工作，不同的規則
在 AI 時代，創辦人的工作沒有變：找一個真正的問題、做一個能解決它的東西、把它變成一間有意義的公司。變的是到達那裡的路徑。
跨越四個階段（想法、最小可行產品、上線、規模化），AI 把季度壓縮成週。以前需要幾個月的驗證循環，現在幾個下午就能做完。一個能動的原型不再需要有對的技術背景的合夥人，只需要一個清楚的問題和幾次跟 Claude Code 的工作對話。上線準備從一個發布前的衝刺壓縮成一個持續的工作流。到了規模化，過去迫使早期員工陷入救火模式的營運重擔，越來越多可以交給 AI，讓你的團隊把注意力花在那些最終成為你護城河的判斷上。
瓶頸不再是你「能」做什麼，而是你「選擇」做什麼。
━━━━━━━━━━━━━━━━━━━━
▍資源與案例
▍建造工具資源
Building AI Agents for Startups：分享新創如何用 AI 代理人（AI Agents）讓公司減少對創辦人的依賴
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、Plugins 等功能來擴展 AI 對新創的影響
Tutorials：claude.com/resources/tutorials 提供各種任務的實作導覽
▍創辦人故事
以下是一些用 Claude 工具成功創業的實際案例：
HumanLayer (F24)、Ambral (W25)、Vulcan Technologies (S25)：三家 YC 新創用 Claude Code 快速從原型到上線，並用 agentic coding 工作流程擴展平台
GC AI：創辦人用領域專業建立了一個符合企業法務團隊真實工作方式的法律平台，處理公司特有的操作手冊、跨部門利害關係人、和不同的風險容忍度閾值（risk tolerance thresholds）
Carta Healthcare：用 Claude 驅動臨床摘要平台，每年處理 22,000 個手術案例，數據整理時間減少 66%
Anything：由 Claude 和 Agent SDK 驅動，幫 150 萬用戶把想法變成可用的軟體產品，包括一位非技術創辦人做了一個完整的招聘平台並已經在賣了
Cogent：做 AI 代理人來自動化企業安全關鍵任務，用 Claude 做推理層，自動化調查、優先排序、和漏洞生命週期（vulnerability lifecycle）的修復工作
Airtree：用 Claude Cowork 做為營運基礎設施的中心，整合原本散落在十幾個不同工具和團隊裡的數據。一個人建的自動化流程，整個組織都能用
Duvo：做 AI 代理人來跑採購、供應鏈、品類管理流程，跨 ERP、供應商入口、試算表、email、甚至電話。完全建在 Claude 上，用 Agent SDK 做跨流程調度
Zingage：為居家照護機構做 24/7 自動化營運的 AI 代理人平台，用 Claude 的結構化工具呼叫（structured tool calling）跨 EMR（電子病歷系統）和多個溝通管道做調度，用 Claude 的語境推理提供細緻的、針對病人的回應
Kindora：由非營利組織主管創建，用 Claude Sonnet 建立了一個智慧配對慈善機構和資助方的平台。篩選完幾千筆配對後，Kindora 的 MCP connector 讓非營利組織直接在 Claude 內使用它的開發工具
Wordsmith：由律師轉技術長（lawyer-turned-CTO）創辦，用 Claude 做合約審查、協議起草、和文件審查的推理引擎，工程團隊則用 Claude Code 建造和演化平台本身
