創辦人的行動手冊

需留意的挑戰

AI 原生構想階段特有的三種失敗模式

定義並壓測問題

把假設磨利到「可被檢驗」

• 逼出具體性。「合約審查很耗時」沒辦法被檢驗。「中型企業的法務團隊每份合約要花 3 天以上，因為紅線修訂散落在 email 串、而非單一版本控管的文件裡」才可以。
• 替反方辯護。請 Claude 為「你的點子行不通」辯護——挖出負面市場訊號、失敗的競品、客戶行為模式，這些都是討喜的綜整會悄悄淡化掉的。把 Claude 當成有架構的反方辯護人，是整個生命週期每個階段的核心用法。

市場研究與競品地圖

動手前先把戰場畫清楚

• 克服「競品忽視」。創辦人傾向低估別人在做什麼。請 Claude 為「每個競品為何會贏」提出最有力的論述——分層:直接競品、間接競品、潛在收購方、鄰近玩家——說明真正的威脅，而不是最容易被打發的那一版。
• 挖競品評論。讓 Claude Cowork 跨來源彙整競品評論，找出既有解法尚未解決的主要抱怨。如果你的假設正好回應其中之一，那就是強力的問題—解法證據;如果沒有，這也值得知道。
• 估市場並壓測它。建立 TAM/SAM/SOM 模型並挑戰背後的假設——市場是在擴張、整併、還是已成熟?描繪買方地圖:誰掌握預算、誰影響決策、這兩者是不是同一人。
• 做趨勢分析。找出三個外部趨勢——法規、技術或人口結構——可能在未來兩年顯著影響你的市場，並評估每一個對你的具體假設是順風還是逆風。

規劃與設計客戶探索

找對的人、用對的方式談

• 找誰談。一份精準的目標輪廓(職稱、公司類型、團隊結構、層級)勝過一長串聯絡名單。找出這些人在哪裡找得到，並依「離問題多近」排出優先順序。
• 問什麼。用 Claude 建立訪談架構:對的問題、對的順序，設計成能逼出人們實際做了什麼、而非他們說會做什麼。把「你會用這個嗎?」換成「上一次你遇到這個問題時是怎麼處理的?」並請 Claude 標出任何誘導性、面向未來、或會引出社會期許答案的問題。
• 訪後分析。每場對話後把筆記餵給 Claude，找出哪些確認了假設、哪些挑戰了假設、哪些真正出乎意料。每進行五場，讓 Claude Cowork 整理兩份清單——支持與反對的證據。若第一份明顯較長，反問自己:這個落差反映的是資料，還是你的期待?

客戶外展與排程

把操作性的負擔自動化

• 把驗證過的目標輪廓交給 Claude Cowork，讓它研究並彙整出一份附驗證聯絡資訊的潛在對象清單，再依每個人的角色與情境草擬個人化的外展信。
• 透過 MCP 連到 Gmail 與 Google 日曆後，它能管理對話串、處理排程、依設定節奏草擬跟進(例如對未回覆者第七天的提醒),並隨時更新追蹤表——讓你清楚每位對象的進度，同時把心力留給對話本身。

設計最終解法概念

從每個角度壓測你的解法

• 問題已驗證、解法概念也有證據支撐後，用 Claude 發展並挑戰它:提出你的設計最仰賴的三個假設，再追問每個假設要成立需要什麼前提、若其中一個不成立會有什麼後果。
• 這是一個現實檢查點——這個設計回應的，是驗證過程「真正揭露」的問題，還是你一開始「假設」的那個問題?

打造輕量原型

此時——也只在此時——才打開 Claude Code

• 這是 Claude Code 登場的時刻。你還不是在蓋真正的產品，而是做出一個可運作的樣本，用在客戶與投資人的對話裡——一個人們真的能觸碰的東西。
• 只蓋你的解法所仰賴的那一個核心互動。把它放到五位已驗證的目標使用者面前，請他們試用。你在這五場對話裡學到的東西，決定你該繼續往下蓋、還是回到原點重來。

需留意的挑戰

當速度變免費後，新出現的失敗模式

在動程式碼前先定義架構

寫下 Claude Code 將在其中運作的護欄

• 在 Claude Code 寫下任何一行正式程式碼之前，打開 Claude，描述你在打造什麼、為誰服務、未來六個月實際預期的規模。讓它定義應遵循的架構原則、應避免的相依、以及你有意識接受的取捨。
• 把產出存成 CLAUDE.md——你的架構脈絡文件，也是這次開發的第一份產物。之後每一次對話都會讀它;它本質上就是專案的持久化記憶，會在 Agent SDK 於某個目錄執行時自動載入。沒有它，每場對話都自行推測結構假設，程式庫便朝著失序漂移。

定義並守住範疇

決定你刻意不做什麼

• 用 Claude 寫一份範疇文件:MVP 會做什麼、刻意不做什麼、以及什麼樣的真實使用者證據才能正當化新增功能。
• 當新功能點子冒出來時——它們一定會——用 Claude 壓測:這究竟是來自使用者的真實訊號，還是包裝成產品思維的創辦人熱情。

用 Claude Code 開發

每場對話都在執行你已做好的決策

• 架構與範疇定義好後，Claude Code 成為主要的開發工具——但把每場對話當成「執行已做好的產品決策」,而不是趁機塞新功能的機會。
• 用對話樣板:開場帶上架構脈絡文件與當下的具體任務;收尾留下一段簡短日誌——蓋了什麼、做了什麼決策、引入了什麼假設。每場多花五分鐘寫文件，是抵抗漂移最便宜的保險。

使用者出現前先做資安審查

在使用者把資料託付給你之前，先搞清楚程式庫裡有什麼

• Claude 能對 AI 生成的程式碼做一次有用的初步資安審查、標出常見漏洞——這是出貨前該養成的習慣。它不能取代資安工具;在更高風險時，也不能取代真人審查者。
• Claude Code Security 走得更遠:它掃描程式庫找漏洞、並針對人工審查提出有針對性的修補建議，揪出傳統方法會漏掉的問題。(出版時它是限量 beta，使用前請確認最新可用狀態。)
• 練習:部署給任何真實使用者之前，帶著明確指令把核心應用程式碼交給 Claude 跑一遍——身分驗證與 Session 管理、API 回應中的資料暴露、輸入驗證與注入風險、以及有已知漏洞的相依套件。把每個發現都當真，凡涉及身分驗證、機密或資料處理的，都要有真人審查。

衡量、管理回饋、持續迭代

在第一位使用者註冊前就把標準訂好

• 在上線之前就建立衡量框架。定義留存基準、啟用條件、Day 7 / Day 30 目標，以及對你的產品而言「什麼算假陽性」。資料進來時，請 Claude 為你自己的成績做反方論述。
• 管理探索與回饋的後勤。Claude Cowork 處理繁瑣的操作層——建立使用者聯絡名單、跑外展、安排回饋會議、分流 Bug 回報。保留真人在迴圈裡做細膩判讀:「這很棒，但我希望它也能…」是核心需求還是錦上添花?
• 朝證據迭代，而非朝「做完」迭代。當你拿到真正的 PMF 證據，這個階段就結束了，無論產品感覺多「完成」。沒有單一數據能確認 PMF——它是一個必須跨多個迭代週期持續成立的模式。
• 該轉就轉。連續三輪迭代都沒有明顯起色後，和 Claude 做一次診斷:是否有某個區隔反應不同?設計價值與體驗價值之間的落差，是定位問題還是產品問題?要讓現在這個產品找到 PMF，前提需要是什麼——而那實際嗎?讓答案決定你要調整、轉向、還是回到構想階段。

需留意的挑戰

找到 PMF 之後反而把公司搞垮的原因

在技術債複利前先還掉

稽核、排序、把決策寫下來

• 用 Claude Code 跑一次完整架構稽核:哪裡脆弱、哪些捷徑會越來越貴、哪裡測試覆蓋太薄會讓同樣的問題重演。
• 把這些發現餵給 Claude 來分流與排序修復——什麼必須在下次發布前修、什麼可以等一個 sprint、什麼是可接受的持續性債。這也是把過去只存在你腦中的架構決策記進 CLAUDE.md 的時刻。

把資安與法遵變成持續工作流

而不是一次性專案

• 用 Claude Code 揪出那些在你目標市場的 SOC 2、GDPR 或 HIPAA 稽核裡常見的程式碼層級問題——漏洞與法遵缺口都涵蓋。AI 掃描是輔助，不能取代合格的法遵審查。
• 把法遵建進開發週期，而不是只跑一次。針對你市場要求的框架做程式碼層級資安審查，再請 Claude 產出依優先順序排好的修復清單，以及企業採購團隊一定會索取的文件與控制項。

建立你一直略過的產品管理流程

一套輕量的產品作業系統

• 上線階段需要不靠創辦人介入也能運轉的、輕量且可重複的流程。用 Claude 設計你的產品時間軸與工作週期如何安排、一份規格該包含什麼、Bug 回報如何分流與路由、每週指標報告涵蓋什麼。
• 再用 Claude Cowork 運轉操作層:安排 sprint 儀式、路由進來的 Bug 回報、從連接的資料源彙整每週指標、並維護讓使用者訊號持續流入產品決策的回饋迴圈。

建立取代創辦人注意力的系統

先盤點，再自動化或授權

• 用 Claude Cowork 對你的營運負載做一次結構化盤點:每一項重複任務、每一個落到你桌上的決策、每一個只因為你記得才會發生的工作流。
• 請 Claude 把清單分成三類:可完全自動化的、需要真人但不必是你的、以及真正需要創辦人判斷的——然後為前兩類建立工作流邏輯。

需留意的挑戰

規模化階段才會冒出來的新考驗

把日常交給 Claude Cowork

對「你的注意力該放哪」有清醒的認識

• 請 Claude 列出此刻只有你該做的事——產品敘事、董事會關係、企業大單、創辦人對創辦人的對話。不在這份清單上的，都是授權或交給 Cowork 自動化的候選。
• 產出一張營運層的瓶頸地圖，再問:你一週不在時，每個工作流會怎樣?那些會停擺的，正是你還親力到足以拖慢進度的地方——把那些自動化收緊或替換掉。

把技術營運擴展成企業級基礎建設

打造程式庫周圍的工作

• 用 Claude 草擬並維護企業採購會看的書面基礎建設——產品文件、支援手冊、SLA。
• 指揮 Claude Code 依企業可靠度與資安標準稽核並加固程式庫，並建出一個 Discord 社群從不需要的支援基礎建設:日誌、監控、事件應變工具，以及讓 SLA 真正可執行的可觀測性。接著 Claude Cowork 運轉企業支援本身——工單路由、升級、由產品變更觸發的文件更新、續約追蹤、回報節奏。

把領域專業變成 AI 脈絡

一份通用型 AI 比不過的專有知識底層

• 透過延伸對話、專案與記憶，把你所知的一切——產業術語、法規地雷、邊緣案例、「表面答案行不通的原因」——寫進一份結構化、可搜尋的脈絡。Skills 接著能把重複的工作流編碼成可重用的常式，讓 Claude 每次都以同樣方式執行。
• 把領域邊緣案例編碼進產品。讓 Claude Code 為你在這個垂直領域看過的每個真實邊緣案例建一個專屬測試案例(不是單元測試)。每次有類似的出現就補進去——你的測試套件，會變成一張你的護城河地圖。

把使用者資料複利成可守住的優勢

一個複製者無法重現的行為指紋

• 使用者互動時會產生行為訊號——他們接受什麼、拒絕什麼——這些都餵養路線圖。這份資料是時間鎖死、與情境綁定的:你買不到數千名使用者在你產品裡持續打磨工作流所留下的行為指紋。
• 請 Claude 稽核你蒐集到的互動資料，找出訊號最強的三個模式，並設計把每一個轉化為系統性模型改進的回饋迴圈——再草擬一份給產品行銷用的一頁護城河敘事:你的資料飛輪如何運作、轉了多久、以及一個今天才起步的資金雄厚競爭對手，為何兩年內都複製不了。

建立工作流黏著度

用深度鎖住，而非用摩擦力

• 使用者把你的產品跑進日常營運越久，它就嵌得越深——在它之上建的自動化、被訓練來用它的人、與他們其他工具的連接。到那個程度，「換掉」就從一個產品決策，變成一個完整的營運專案。
• 請 Claude 依整合深度描繪你的客戶群，再讓 Claude Code 拉出原生整合、API、Webhook 與 SDK，讓客戶站在你的產品上開發，而不只是使用它——這是最深層的黏著。

打造真正的 GTM 部門

啟動 go-to-market 引擎

• Claude 從零草擬基礎 GTM 資源——市場區隔、訊息架構、分析師關係策略、銷售腳本、面向投資人的指標敘事——把你產品的價值主張，翻譯成對每個受眾區隔都切題的產品行銷方法。
• Claude Cowork 成為戰術執行層:內容生產線、外展節奏、分析師簡報後勤、新聞室與 PR 節奏、CRM 整潔、管道報表。當動作需要產品行銷基礎建設——互動 Demo 環境、整合文件、沙盒租戶、API 參考——由 Claude Code 打造，讓一個建得好的 Demo 在你開董事會時也能成交。