# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：宝玉 (@dotey) · 平台：X (Twitter) · 日期：2026-05-18

> 原始來源：https://x.com/dotey/status/2055819034671604048

## 中文摘要

# 創辦人手冊：打造 AI 原生初創公司

原文：The founder's playbook: Building an AI-native startup

## 目錄

- 2026 年，初創公司生命週期的重啟

- 創辦人定義的演變

- 構思階段

- MVP 階段

- 發布階段

- 擴展階段

- 目標未變，規則已改

- 資源推薦

## 2026 年，初創公司生命週期的重啟

AI 正在徹底重塑初創公司的誕生方式。如今，哪怕是連一行程式碼都沒寫過的創辦人，也能發布可供實際使用的生產級應用 (production applications)。而那種只有 10 個人的精益獨角獸公司（獨角獸指估值超過 10 億美元的未上市初創企業），已經不再是什麼草根逆襲的傳說，而是成了大家精心規劃的常規操作。

到了 2026 年，AI 已經能夠編寫生產級程式碼、開展市場研究、梳理競爭格局、起草融資材料，甚至還能讓業務流程實現自動化。以前，為了把腦子裡的點子變成現實，哪怕是經驗豐富的技術型創辦人，也要面對整合各種工具、平台和系統時那陡峭的學習曲線。現在，AI 抹平了這些障礙，徹底打破了創立公司或打造產品的門檻。

在 2026 年，一個好點子能讓創辦人走得比以往任何時候都遠。依靠 Agentic 程式開發（指利用 AI Agent 自主編寫、測試和修改程式碼的程式開發方式），以前需要一整個工程師團隊才能幹完的活，現在創辦人自己就能搞定並發布。

傳統的初創公司發展路徑往往是這樣的：驗證想法 → 融資 → 招人 → 開發產品 → 再融資 → 增長業務 → 再招人 → 循環往復。

但這套玩法過時了。初創公司進入新階段，不再必然意味著需要擴充團隊、補充新技能，更不需要立刻去拉新一輪投資。

本手冊將根據這些新現實，重新梳理創業旅程的核心四個階段：構思、MVP、發布和擴展。看看當 AI 變成技術和組織的核心基建時，創辦人應該用什麼工具，以及如何靠它們來瘋狂壓縮時間。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779085863408-iaHIe5tubWoAAWU55jpg.jpg)

## 創辦人定義的演變

過去，創辦人的身份往往是由他們的技能決定的：技術創辦人負責寫程式碼，非技術創辦人負責搞業務和談單子。但到了 2026 年，創辦人手裡的各種模型、系統和 AI Agent，已經徹底推倒了「懂開發的人」和「有絕佳點子的人」之間的那堵牆。

AI 原生 (AI-native) 初創公司正在從根本上改變「創辦人」的含義。現在，毫無工程背景的人也能開發出能落地的生產級軟體；反過來，只懂技術、缺乏商業嗅覺的創辦人，也能輕鬆搞定市場推廣策略 (go-to-market strategy)、財務模型，拿出一份極其專業的商業計畫書 (pitch deck)（向投資人展示專案以尋求融資的演示文稿）。

回顧歷史，創辦人們把大把的時間都花在了執行上：寫程式碼、管團隊、處理日常瑣事。但在 AI 原生公司裡，創辦人的角色不再是埋頭苦幹的員工，而是變成了 AI Agent 的指揮家——這些專業的 AI 助手能閱讀文件、執行指令、執行程式碼，甚至還能上網搜尋。創辦人的注意力因此得以提升到更高層面的工作上：想出好點子，並指揮手下的系統（包括 AI Agent、各種工具，以及精簡的團隊）把想法變成現實。

將 AI 作為核心基礎設施，帶來的最具革命性的成果，是徹底解放了那些懂行業的非技術創辦人。當創辦人的圈子不再局限於有工程背景的人時，你會看到背景各異的人建立起形形色色的初創公司。他們會去解決那些傳統技術圈從來不關心，甚至根本沒注意到的真實痛點。

## 為精益初創公司量身打造的 AI 工具能力

傳統的創業模式認為：你得招工程師來開發，招銷售去賣貨，招營運來管業務。公司的員工數量，往往被看作是企業發展勢頭和產品成熟度的標誌。

2026 年的早期初創公司則完全不同。它們天生就極其精簡，往往只有創辦人光桿司令一個，或者頂多加上三兩隻小貓。透過把 AI 作為技術和組織發展的核心基礎設施，它們甚至在擴充團隊之前，就能完成產品驗證、獲得早期收入，甚至實現獲利。特別是在以下三個方面，AI 讓一家微型初創公司運轉得像個大企業：研究調查、Agentic 程式開發，以及核心業務流程自動化。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779085863470-diaHIe5J49WQAAng0jpg.jpg)

## 對話式智慧與研究調查

一句話總結：全領域的隨時待命專家

想像一下創辦人在創業第一年需要面對，卻幾乎完全抓瞎的那些事：怎麼發薪水？怎麼規劃產品開發衝刺週期？怎麼寫一份滴水不漏的投資備忘錄 (investor memo)？

以前，這些早期創業問題的答案永遠只有一個：找個懂行的人問問。對於自掏腰包 (bootstrapped) 或處於種子前輪 (pre-seed)（指專案剛起步，尚未獲得正式機構投資的階段）的創辦人來說，這不僅意味著把原本該用來搞開發的時間花在了到處打聽上，還可能要被迫拿出一大筆早期資金去請顧問。現在呢？他們擁有了 AI 這個在所有領域隨叫隨到的專家。

- 深度研究：競品分析 (competitive analysis)、市場規模估算 (market sizing)、財務建模。

- 文件起草：商業計畫書、案例分析、投資備忘錄、產品需求文件 (PRDs)。

- 戰略思考夥伴：扮演唱反調的「魔鬼代言人」、進行事前驗屍 (pre-mortems)（一種風險管理技巧，假設專案已經失敗，反推失敗原因）、情境規劃、路線圖優化。

## Agentic 程式開發

一句話總結：那個永遠在線、從不卡殼的工程師

過去，你要麼得拉個懂技術的共同創辦人，要麼找個外包開發團隊，或者手頭有足夠的資金跑道 (runway)（指公司在資金耗盡前還能維持營運的時間）去養個工程師團隊，然後才能寫下第一行生產級程式碼。

現在，有了 Agentic 程式開發工具，每個懷揣夢想的創辦人只需用大白話描述自己想要什麼。AI 就會以一整個工程師團隊的速度和規模，生成、測試、除錯並重構出企業級的程式庫。

從「我有個點子」到「我做出了產品」的時間被大幅壓縮。創辦人的核心任務變成了決定「做什麼」和「為什麼做」，而 AI 負責把地基打好，搭建出真正面向使用者的可用基礎設施。

## 流程自動化

一句話總結：按需召喚的全自動營運團隊

哪怕創辦人能像顧問一樣做研究，像團隊一樣寫程式碼，除了戰略規劃和產品開發，依然有成堆的雜活等著幹。安排會議、更新 CRM 系統（客戶關係管理系統）、拉取週報、維護最新文件、發布內容、跟進合規要求，還要想法子把公司裡用到的各種工具和系統串聯起來。在精益初創公司裡，這些重擔幾乎全壓在創辦人肩上——這嚴重擠占了他們本該用於做關鍵決策的時間和精力。

AI 工具提供的流程自動化，把創辦人從這些苦活累活裡解救了出來。你可以把那些重複性的日常操作設為自動執行：交易一推進，CRM 自動更新；一週結束，週報自動生成；產品一改動，文件自動同步。更厲害的是，像 Claude Cowork 這樣的工具能無縫接入你現有的系統——你的專案管理工具、溝通軟體、資料來源——完全不需要專人去開發和維護這些介面。而在起步首日 (Day Zero) 的初創公司裡，那個「專人」往往只能是創辦人自己。

## 把握時機與統籌調度是一切的關鍵

能夠熟練駕馭 AI 研究、自動化和 Agentic 程式開發能力的創辦人，就能撬動遠超其團隊規模的槓桿效應。他們終於能把大部分時間和精力投入到真正有價值的工作中去。

當然，這並非完全是自動駕駛。身為 AI 工具的指揮官，創辦人必須懂得使用的時機和方法。

## 構思階段

所有的創業者都從同一個起點出發：一個讓他們魂牽夢縈、揮之不去的問題。在這個階段，想法將與現實發生碰撞。要想在 2026 年取得成功，你需要一種克制：在沒有確鑿證據之前，絕不盲目動手開發。

現階段的核心任務是：深入研究、客戶調查 (customer discovery)、競品分析，以及誠實地面對那些與你想法相左的反面證據。做完這一切之後，再去讓 Claude Code 幫你寫下第一行生產級程式碼。

## 構思階段的目標

在構思階段，創辦人首要目標是基於研究的驗證：在投入資源進行開發之前，收集堅實的證據，證明你眼中的痛點確實存在（並且你提供的方案能有效解決它）。

具體來說，在這個階段你需要按順序回答幾個問題：

- 這個痛點真實存在嗎？夠具體嗎？頻率高到值得為它做個產品嗎？

- 到底是誰有這個痛點？這能算是一個市場嗎？

- 有沒有別人已經在解決這個問題？如果有，他們是怎麼做的，做得好不好？

- 一個能真正解決這個問題的方案，到底需要具備哪些功能？我的點子符合要求嗎？

這些問題的答案，最終都指向一個終極拷問：這玩意兒值得做嗎？

這意味著在你真正採取行動之前，必須把問題想得無比具體。「大家覺得報銷很麻煩」這只是個粗淺的觀察；而「中型企業的財務經理每週要花 4 個多小時核對報銷單，因為他們現有的工具沒法和財務軟體打通」，這才是一個可以被測試驗證的假設。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779085862997-iaHIe5OjOXcAA3h6sjpg.jpg)

## 構思階段的通關條件

構思階段的通關標誌是找到問題與解決方案的契合點 (problem-solution fit)。在你開始擼起袖子造輪子之前，你已經獲得了定性的證據（主要來自與真實使用者的交流），證明你確實在為真實的人解決真實的痛點。

當你能對以下三個問題大聲說「是」的時候，你就可以離開構思階段了：

1. 痛點真實且具體嗎？ 回答「是」，意味著你能準確說出誰在經歷這個痛點，他們多久碰到一次，痛到什麼程度，以及他們現在是怎麼湊合應對的。

1. 你的方案能解決實際痛點嗎？ 注意，這裡說的是你在調查中發現的「真實痛點」，而不一定是你一開始想像的那個。有時兩者是一回事，但很多時候不是。

1. 你有足夠的訊號支持你動手開發嗎？ 在這個階段你永遠不可能有百分百的確定性（死等確定性也是一種常見的失敗方式），但你需要有足夠的定性證據，讓「開發一個 MVP」成為一個深思熟慮的決定，而不是一次盲目的豪賭。

## 構思階段的挑戰

構思階段是你創業旅程中最重要的一環，因為這也是最容易犯下致命錯誤的地方：現在走錯一步，你那剛萌芽的幼苗很快就會長歪。

不過，這個階段的大部分坑，都是因為「行動快於認知」造成的。所以，只要創辦人能保持冷靜、謀定而後動，就能穩步向前。

## 把「開發」當「驗證」

挑戰：當技術門檻被徹底抹平後，滿腔熱血的創辦人很容易跳過創業中最關鍵的一步：驗證他們的想法真的是人們需要且願意使用的解決方案。

即便在當前的 Agentic 程式開發時代到來之前，也有高達 42% 的初創公司死於「做出來的東西根本沒人要」。而現在，像 Claude Code 這樣的 Agentic 程式開發方案大幅縮短了從「點子」到「產品」的距離，這個失敗率恐怕只會繼續飆升。

雖然對於擁有絕佳點子的創辦人來說，現在是最好的時代，但反直覺的是，「一眨眼就能搞出個原型」這件事，對 AI 原生初創公司構成了真正的致命威脅。

就在不久前，開發軟體還需要實打實的人力和預算，搗鼓出一個最基礎的原型通常也得幾個月。可現在，技術開發的門檻基本消失了，AI 讓創辦人太容易跳過實地驗證，直接開始埋頭苦幹。

要達到問題與解決方案的契合，必須先驗證假設，然後再動手。但很多新手（甚至一些老手）創辦人誤以為 AI 能夠繞開這個定律。他們的流程變成了：有個點子 -> 立刻搞個原型 -> 把原型的存在當成點子被驗證的證據。他們拿著原型，就堅信自己一開始的假設是對的，根本沒去驗證這在真實世界裡是否行得通。

一個能跑起來的原型，很容易讓人產生錯覺，以為自己真的在解決實際問題。但事實並非如此。你的原型真正的作用，是在跟潛在使用者的交流時，拿來做壓力測試的道具。那些交流的回饋本身，才是你真正需要的證據。

## 過早擴張

挑戰：當開發變得像呼吸一樣簡單且幾乎零成本時，你的執行速度很可能會把真實的商業需求遠遠甩在身後。

過早擴張意味著，你在還沒有真正確認一條路是否值得走之前，就已經在上面狂飆突進了。

這一直是初創公司的頭號殺手，但在 AI 時代，創辦人更容易在不知不覺中掉進這個陷阱。Agentic 程式開發助手太強大了，以至於創辦人稍不留神，就會在尚未驗證市場契合度的情況下，把執行規模盲目擴大。

AI 會用同樣飽滿的熱情，去幫你生成、測試、除錯並重構程式碼——哪怕你這個專案的底層邏輯爛得掉渣。系統裡的智慧是你賦予的。所以這個階段的最高準則就是：讓你的腦子走在手的前面，特別是當寫程式碼變得如此飛速和不費吹灰之力的時候。

## 喪失客觀性

挑戰：如果你讓 AI 工具幫你找證據來支持你已經深信不疑的觀點，它一定會幫你找到。「確認偏誤」 (Confirmation bias)（指人們更願意相信那些支持自己已有觀念的資訊的心理學現象），現在自帶強大的研究引擎。

確認偏誤一直是創業者的職業病：創辦人天生就對自己的點子充滿狂熱。現在，AI 工具給這種偏誤加了一個超級濾鏡。如果你讓 AI 去驗證你的創業點子，它會順著你的意思找出一堆證據；如果你讓它估算潛在市場規模，它一定會給你捏造出一個讓投資人看了流口水的龐大數字。

AI 會順著你的思路走。這就意味著，如果不去提出尖銳的問題，創辦人現在比以往任何時候都更容易為一個糟糕的點子包裝出一套看似經過詳實研究的商業邏輯，並且還自我感覺良好，以為自己真的做了盡職調查 (due diligence)。解藥其實還在同一個工具裡，只不過要反著來：AI 在幫你推翻一個點子時，和在幫你證明一個點子時一樣賣力。

當對抗性思考暴露出想法的漏洞時，果斷調整方向 (Pivot)。

## Claude 如何助力構思階段的創辦人

推動你的 AI 原生專案熬過構思階段，有時會讓人覺得無比漫長。你是個創辦人，你骨子裡就渴望「馬上動手」。但這個至關重要的起步階段，本質上是一場研究和驗證的戰役。這意味著你必須借助那些能幫你思考得更縝密的工具，而不是急匆匆地去寫程式碼。下面我們將介紹如何利用 Claude 的三大產品介面（Chat、Claude Cowork 和 Claude Code），幫你最快地度過構思階段，同時扎實地完成盡職調查。

## Chat、Claude Cowork 還是 Claude Code：選對正確的 Claude 介面

AI 能幫助初創創辦人更快交付產品、自動化繁瑣流程並大規模營運，但你使用的工具介面很關鍵。這裡是針對不同任務如何選擇 Chat、Claude Cowork 或 Claude Code 的指南。

Chat 適合在不離開當前應用程式的情況下進行快速交流。用它來處理營運公司的瑣碎小事：從冗長的投資人備忘錄裡提煉核心金句、在開董事會前檢查某個說詞有沒有漏洞，或者幫你理清團隊在 Slack 上的長篇大論。

Claude Cowork 適合做那些真正需要時間沉澱的知識型工作：它能從多方匯集資訊，梳理邏輯，並輸出一個完整的成品，比如文件、PPT 或表格。比如：把一資料夾的客戶訪談錄音整理成產品評審會上的主題分析報告；在融資前翻閱十幾家競品網站總結出一份競爭格局分析；或者設定一個每週一早上的例行任務，讓它自動從關聯工具裡抓取資料，生成一份 KPI 簡報放到共享資料夾裡。

Claude Code 是為團隊中的工程師準備的 Agentic 程式開發環境：它能直接存取程式庫，擁有規劃模式 (Plan Mode)，整合了 git，並支持本地、IDE 或沙盒雲環境。在這裡，精簡團隊可以不斷為日益龐大的程式庫添加新功能，遷移 MVP 階段留下的舊程式碼，從原型平滑過渡到生產環境，而無需苦等招聘新人。

| 任務類型... | 該用誰 | 為什麼選它 |
| :--- | :--- | :--- |
| 問個問題、改寫段落、快速腦力激盪 | Chat | 速度快、對話式、無需繁瑣設定 |
| 研究分析，或基於你的文件和系統生成完整文件 | Claude Cowork | 能存取資料夾、有 plugin 連接、支持技能、可定時執行 |
| 編寫、測試或發布軟體 | Claude Code | 直接存取程式庫、支持程式碼差異比對 (diffs)、整合 git、支持開發環境 |

這三者的底層都是相同的 Claude 模型，改變的只是外圍的工作空間。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779085863012-iaHIe5TLQWAAAElPAjpg.jpg)

## 定義並對你的問題假設進行壓力測試

憑藉你的行業經驗和前期調查，你心裡大概已經有了一個假設。第一項工作，就是把它打磨鋒利，直到它變得真正可以被測試：到底是誰有這個痛點？頻率多高？痛點多深？他們現在是怎麼應付的？如果一個問題陳述無法精確回答這些問題，那就說明它還不具備被驗證的條件。

- 實操練習：和 Claude 一起打磨你的問題陳述，直到它變成一個可測試的假設。比如，「合約審查太慢了」這就沒法測試；但「中型企業的內部法務團隊在每個合約審查週期要花 3 天以上時間，因為他們總是在 email 往來裡改紅線，而不是用一個版本控制文件」，這就非常具有可測試性了。

下一步，讓 Claude 來反駁你的想法，讓它去尋找那些能推翻你假設的負面證據。這能幫你挖出負面的市場訊號、已經倒閉的競品、潛在的客戶行為模式，以及那些你在盲目樂觀時很容易忽視的結構性障礙。

這樣做的目的是，在真正接觸客戶進行調查之前，你的假設就已經經受了最強反方辯友的狂轟濫炸。這樣一來，當你去做使用者訪談時，你是在真誠地開放式傾聽，而不是為了驗證自己的偏見去尋找心理安慰。

注意：讓 Claude 扮演結構化的「魔鬼代言人」（唱反調的人），是貫穿 AI 初創公司整個生命週期的核心用法。

## 市場調查與梳理競爭格局

摸底競爭對手

創業圈有一種現象叫「競品盲區」 (competitor neglect)：創辦人往往過度沉浸在自己的宏大願景和執行計畫中，習慣性地看低同賽道其他人的努力。好在 AI 給了我們一劑解藥：讓 Claude 站在競品的立場，給出最強有力的理由，論證為什麼他們會成功，而你會一敗塗地。

Claude 會幫你分析：為什麼他們的做法其實更好？為什麼客戶會選他們？為什麼你自以為是的護城河其實不堪一擊？

- 實操練習：讓 Claude 把你的競品分個類：直接競品、間接競品、潛在收購方，以及隨時可能跨界打劫的周邊玩家。然後讓它給出理由，分析為什麼每一類玩家都對你構成了真正的生存威脅，別讓它挑好聽的敷衍你。

市場調查

Claude Code 可以抓取並綜合公開的客戶回饋，幫你找出那些被反覆吐槽的痛點和未被滿足的需求。額外福利：這相當於在給競品的客戶做免費的定性研究。

- 實操練習：指揮 Claude Cowork 梳理各個主流管道的競品評價，揪出現有方案一直沒解決的幾大痛點。如果你的假設正好切中其中一兩個要害，那就是證明問題與解決方案契合的強烈訊號；如果沒有，早點知道也是好事。

Claude Cowork 還能從厚重的行業報告、分析師文件和市場研究中提取核心資料；整理乾淨後，這些資料將成為 Claude 進一步深入分析的絕佳素材。

- 實操練習：利用公開資料建立 TAM/SAM/SOM 模型（即總可尋址市場 / 可服務可尋址市場 / 可獲得服務市場，用於評估市場規模），並對背後的假設進行壓力測試。看清這個市場是在擴張、洗牌還是已經成熟；這些背景資訊會直接影響你對入場時機和差異化競爭的判斷。梳理客戶畫像：誰負責掏錢？誰能影響決策？這倆是同一個人嗎？

趨勢分析

最後，用 Claude 幫你捕捉那些決定入場時機的早期指標。追蹤討論相關問題的 Reddit 子版塊和 LinkedIn 群組，抓取使用者在描述痛點時使用的原汁原味的詞彙。讓 Claude 找找有哪些類似的跨界市場曾經解決過相似的問題，看看他們什麼管用，什麼掉坑了。揪出那些可能加速或者威脅你專案機會的政策法規、技術突破或人口結構變化趨勢。

- 實操練習：讓 Claude 找出三個能在未來兩年內深刻影響你所在市場的外部趨勢（政策、技術或人口），並客觀評估每一個趨勢對你的具體假設到底是順風還是逆風。

注意：本節中的市場調查和競品梳理工作不是一次性的。在接下來的 MVP 和發布階段，隨著你認知升級，你的假設也會迭代，這時候必須把這些動作再重複一遍。

## 規劃並設計客戶調查

你能從潛在使用者的嘴裡套出多少有價值的資訊，取決於兩點：(1) 你問的問題水平如何；(2) 你是不是在對正確的人發問。在這方面，Claude 是個絕佳幫手，它能幫你搞定找誰聊、聊什麼，以及如何解讀聽到的回饋。

找誰聊

一個精準的目標使用者畫像，比一份漫長的通訊錄有價值一萬倍。這包括具體的職位、公司類型、團隊架構，以及痛點最深的人群職級。接著，揪出這些人平常都在哪兒扎堆——哪些社群、活動、LinkedIn 群組和 Slack 頻道——然後根據他們離痛點的遠近，制定出一份優先級拜訪框架。

問什麼

目標確定後，利用 Claude 幫你搭建訪談框架：在正確的時間問正確的問題，以此挖掘使用者「實際做了什麼」，而不是他們「想像自己會做什麼」。新手創辦人最愛犯的錯，就是拋出一個空泛的、面向未來的問題（「你會用這種產品嗎？」），而不是精準地追問相關的歷史（「跟我講講你上次遇到這破事兒是怎麼處理的」）。Claude 能夠精準捕捉到你的草稿中哪些問題帶有誘導性、太寬泛，或者容易引出廢話噪音而不是有效訊號。Claude 還能幫你設計連環追問，用來對付那些含糊其辭或避重就輕的回答。

如果你的專案涉及多種角色，Claude 還能為不同的人量身訂製不同的問卷。財務經理和 CFO 面對同一個痛點的關係是完全不同的，拿同一套題去套所有人絕對是災難。

- 實操練習：先自己手寫一遍訪談問題，然後讓 Claude 充當審計員。特意讓它揪出那些帶有誘導性、面向未來、太寬泛，或者容易讓受訪者為了「討好你」而說假話的問題。接著讓它為你可能遭到敷衍的兩三個關鍵訪談時刻，設計一套防守反擊的追問技巧。

訪談後分析

每次聊完，讓 Claude 幫你復盤：把筆記扔給它，讓它提煉出哪些驗證了你的假設，哪些推翻了你的假設，以及哪些是意料之外的驚喜。等你攢夠了一批訪談，把所有的筆記餵給 Claude Cowork，讓它提煉高頻詞、自相矛盾的地方，以及正反兩方最強烈的訊號。最後拿著綜合輸出的報告去找 Claude，問問它：我的解讀是不是在尋找心理安慰進行模式匹配，而不是反映真實資料？

- 實操練習：每聊完五個客戶，就讓 Claude Cowork 對筆記進行綜合梳理，列出兩份清單：支持假設的證據，和反對假設的證據。如果第一份清單比第二份長出太多，問問 Claude：這是資料的真實反映，還是我一廂情願希望看到的結果？

客戶拓展與日程安排

利用 Claude Cowork 把整理名單、發送開發信、安排使用者訪談這些雜活實現自動化。

Claude Cowork 能利用你之前和 Claude 定好的目標畫像（包括職位、公司類型、職級），去研究並整理出一份包含經過驗證聯絡方式的結構化線索名單。然後它會大規模地批量起草個性化的開發 email，確保每一封都緊扣對方的角色和背景。

收到回覆後，它能透過 MCP (模型上下文協議) 連接到你的 Gmail 和 Google 日曆管理溝通執行緒，處理會議邀請，並把訪談穩穩地塞進日程表。這個工作流還在繼續：Claude Cowork 會按既定節奏（比如給七天沒回信的人發跟進草稿）自動生成後續回覆，並在完成後自動更新追蹤表格，確保你時刻掌握每個潛在客戶的漏斗進度。

- 實操練習：把你驗證過的目標畫像丟給 Claude Cowork，讓它去建立名單、寫個性化開發信序列、建一個包含拓展狀態、跟進節奏和訪談進度的追蹤表格。然後讓它去搞定那些協調工作，你只需要集中精力準備對話本身就行了。

## 設計最終的解決方案概念

你已經做完了驗證工作：痛點是真實的，目標人群是明確的，你手裡的解決方案概念也得到了證據支撐。現在，用 Claude 從各個角度來開發和拷打你的方案設計：哪裡還有漏洞？市面上有沒有替代品？如果要規模化運作，這套方案必須具備哪些先決條件？

這是很重要的一道現實檢查：現在的這個設計，解決的到底是你調查出來的真實問題，還是你最初瞎猜的那個原始假設？

- 實操練習：把你的方案概念丟給 Claude，讓它挑出支撐你設計的三個最致命的依賴假設。然後追問它：如果要讓這些假設成立，需要滿足什麼條件？如果哪怕只有一個假設不成立，會有什麼嚴重後果？

## 用 Claude Code 打造一個輕量級原型

終於到了好玩的環節：帶著經過驗證的假設和被反覆壓力測試過的方案概念，你終於可以開始造東西了。

在構思階段的這一刻，Claude Code 正式登場。即使你之前一直在搗鼓，現在才是你生成官方版輕量級原型的時候：它是你為了獲取真人真實回饋所需要的最小表面積體驗。

你現在做的還不是真正能落地的產品；你只是在搭建一個方案的「體驗樣本」，拿去給客戶和投資人看。讓真實使用者體驗看得見摸得著的東西，能給你帶來的情報，遠比做十幾次痛點發現訪談要多得多。之前，你是在證明痛點存在；現在，你是在邀請潛在使用者與提出的解決方案進行互動。

- 實操練習：明確你的產品最核心的一個互動依賴點。指揮 Claude Code 只做這一個核心功能。做出來後，把它扔給你目標畫像裡的五個人，讓他們上手試用。在這五次溝通中獲取的認知，將決定你是繼續往下開發，還是推倒重來。

能順利熬過構思階段，意味著你在 AI 創業賽道上邁出了巨大的一步，因為你現在不再是憑直覺下注；你是在跟著證據執行。

熬過構思階段，創辦人面臨的問題就變成了：「第一步該做啥？」這時候，AI 的角色也從調查搭子，變成了你的王牌施工隊。

## MVP 階段

很多創辦人把 MVP 階段當成單純的施工期，但其實它本質上仍然是一場「收集證據」的演習。區別在於，你現在收集的不再是關於「痛點」空間的證據，而是關於「解決方案」的證據：具體來說，到底有沒有一群明確的人，覺得你的產品好用到願意反覆用（留存）、願意掏錢買（營收），或者願意四處安利（推薦）？

## MVP 階段的目標

作為 AI 原生初創公司的創辦人，你的目標是將經過驗證的痛點，轉化成一個讓真實使用者實際使用的可用產品。它不需要塞進路線圖上的所有功能，只要提供最精簡、最聚焦的核心體驗。它的使命，就是把真實的解決方案懟到使用者臉上，然後拿到產品市場契合度 (product-market fit, PMF) 的實錘證據。

與此同時，你現在的開發方式，直接決定了你未來的天花板。這意味著 MVP 階段還有一個同等重要的目標：在快速移動的同時，絕不能欠下那種利滾利的「技術債」 (technical debt)——一旦有意義數量的真實使用者湧入，這些債遲早會反噬你。

最後，從第一天起就在持續上下文 (persistent context) 方面做投資，是讓 AI 成為力量倍增器而不是混亂之源的關鍵。在 AI 原生公司，你的程式庫是你每天跟 AI 一起結對協作的產物，所以程式碼的清晰易讀是地基。那些跳過說明文件、架構決策和上下文文件（比如 CLAUDE.md）的創辦人，都會撞上一堵可預見的牆：每次新開會話都得重新解釋程式庫，而且 AI 生成的程式碼會逐漸偏離最初的願景。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779085863004-iaHIe5YDNW4AAR9f2jpg.jpg)

## MVP 階段的通關條件

MVP 階段的通關條件是拿到產品市場契合度的真實證據：證明有一群特定的明確使用者，認為你的產品有價值，願意繼續用（留存）、願意掏錢（收入）或者願意幫你拉客（推薦）。

## MVP 階段的挑戰

在 MVP 階段，創辦人的核心法則就是速度與判斷力。此時的挑戰在於，你能不能在不偷工減料、不給自己挖坑的前提下，以足夠快、快到有意義的速度，用正確的方法，做出正確的東西。

Agentic 技術債
挑戰：因為 AI 幾乎消滅了阻礙程式碼上線的所有天然瓶頸，所以「速度」是絕對有保證的。但是，如果創辦人只把速度作為建構 MVP 時的唯一變數，他們就會欠下一屁股很難還清的技術債。

在 MVP 階段欠點技術債是可以理解的，前提是你清楚在擴容前必須把帳還上。傳統技術債是漸漸累積的，你大可以花時間或者搞個專門的衝刺期去清理。但 AI 的技術債，是帶複利的。

如果沒有一份寫好並讓 AI 讀取的說明規範和架構約束，AI 在每次會話中都會從零開始倒推底層邏輯，而這些決策會不可避免地發生漂移。最後你會得到一個毫無靈魂和框架可言的程式庫——不是因為裡面哪段程式碼寫得爛，而是因為這些碎片打一開始就沒打算湊在一起。這是個大麻煩，而且往往到後期才會徹底暴露。

沉迷於虛假的產品市場契合度
挑戰：AI 工具能幫你刷出極其亮眼的早期資料，但這絕不代表市場真的需要你的產品。

早期勢頭是創辦人能體驗到的最強大的心理毒藥。經歷了數週或數月的調查和克制的開發，產品一上線就感覺是在向全世界宣布：你從一開始就是對的！

Agentic 程式開發工具能讓你以比以往快得多的速度體驗到這種快感，但「早期流量」和真正的 PMF 差了十萬八千里。產品剛發布的那些熱度，通常靠的是轉瞬即逝的力量：比如創辦人的朋友捧場、投資人拉來其他被投公司的潛在買家，或者碰巧在 Hacker News 上上了個頭條。遺憾的是，等到第六週或者第十二週最初的熱度退去，這些都沒法可靠地預測接下來會發生什麼。

零阻力的範圍蔓延
挑戰：當開發程式碼變得毫不費力且幾乎零成本的時候，你總會覺得「再加一個酷炫的功能」或者「再處理一個邊緣情況」也無妨。這種範圍蔓延 (scope creep)（指專案功能不斷無節制增加的現象）往往弊大於利。

範圍蔓延一直是創業風險。不同的地方是，以前防備它的強制煞車機制——實打實的工程時間成本——當加個功能只需一下午而不是一個衝刺週期時，這種阻力就不復存在了。

現在的難點在於，每一次加功能的衝動在當時聽起來都無比合理。產品「當然」應該處理那個邊緣情況，「當然」使用者會想要那個工作流。

因為用 Agent 敲程式碼實在太輕鬆了，所以在當時你根本感覺不到這叫範圍蔓延。但隨著產品越來越臃腫，逐漸偏離最初的邊界，你就會迷失方向，喪失勢頭。

解藥是在動手開發之前，先白紙黑字地立個範圍定義：明確寫下這產品做什麼、堅決不做什麼，以及到底需要真實使用者提供什麼樣的特定證據，才允許加新功能。這把決策點從「我們要不要做這個功能？」變成了「是不是有足夠多的核心使用者告訴我們，沒有這個功能他們就得不到價值？」

因為沒經驗而忽視安全
挑戰：利用 AI 工具火急火燎地把應用程式推向市場，卻沒有事先理解基本的安全原則的創辦人，最終會讓使用者暴露在完全可以預防的風險之中。

殘酷的事實是，Agentic 程式開發工具生成的是「能跑」的程式碼，而不是天生安全的程式碼。功能實現很容易，因為它要麼有用要麼沒用。但安全漏洞在被駭客利用之前是看不見的，這意味著根本沒有天然的回饋循環來提醒新手創辦人出問題了。然而，向真實使用者發布即時運行的 MVP，就意味著真實的資料、真實的暴露風險，以及出事後必須承擔的真實後果。

輕視安全並不是 AI 原生專案才有的新問題。在各個時代，自籌資金的初創公司往往都喜歡把安全考慮無限延後，有時甚至拖到正式生產上線前的一刻。但在把任何最小可行性產品丟給世界之前，做一次安全審計，是對大眾最起碼的責任底線。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779085863232-iaHIe5cx0XgAAdhbWjpg.jpg)

## Claude 如何助力 MVP 階段的創辦人

## 開發前先定好架構

在讓 Claude Code 寫下第一行生產程式碼之前，先讓 Claude 幫你定義並文件化這個階段必須遵守的架構決策：該遵循什麼模式，該避開哪些依賴庫，你做出了哪些妥協，為什麼要妥協。這份產出將成為你的核心架構上下文文件，並為 Claude Code 確立運行時的護欄。

沒有這份上下文，每次會話都會從零開始，Claude Code 只能被迫瞎猜你的結構假設。讓沒有護欄的 Claude Code 瞎跑，會造出一個能跑但結構極度混亂的程式庫。在混亂的程式庫上迭代和擴容，最終純粹是浪費時間和 token。遲早有一天程式碼會不可避免地崩盤，逼著你從頭重寫。

- 實操練習：在打開 Claude Code 之前，先打開 Claude，描述你要開發什麼：它解決的核心問題、服務的使用者，以及未來半年你預期的現實規模。讓它幫你提煉出約束 MVP 的架構原則、在當前限制下必須避開的依賴庫，以及現階段你主動接受的權衡。

然後，把這段輸出存為 CLAUDE.md markdown 文件。這是你專案建構的第一個產物，也是以後每一次會話賴以生存的根基。CLAUDE.md 文件是給 Claude Code 看的專案級指令，提供了專案特有的上下文，只要它在目錄裡運行，Agent SDK 就會自動讀取它。從功能上講，它們就是你專案的永久「記憶」。

## 定義並嚴格執行 MVP 邊界

毫無摩擦的範圍蔓延，是 AI 時代 MVP 最具代表性的失敗模式之一。就像你需要定義並記錄架構一樣，在寫任何一個功能之前，你必須劃定 MVP 的範圍。

Claude 能幫你起草一份範圍文件，說明你的 MVP 產品做什麼、堅決不做什麼，以及功能修改的觸發標準：到底需要真實使用者提供什麼樣的鐵證，在現階段才值得加新東西。

當新功能的點子冒出來時——它們絕對會冒出來的——用 Claude 來做個壓力測試：這到底是來自使用者的真實吶喊，還是披著產品思維外衣的創辦人自嗨？

## 用 Claude Code 搭建 MVP

一旦架構和範圍確立，Claude Code 就正式成為核心的 MVP 開發工具。用它來生成、測試、除錯並迭代你的程式庫，但請記住：每次會話都應視為對既定產品決策的執行，而不是用來塞進新點子的機會。

每次啟動 Claude Code 會話前，做到兩點：(1) 重溫你的範圍說明文件；(2) 把包含架構上下文的 CLAUDE.md 文件餵給模型。

每次會話結束時，把本次做出的所有決策更新到文件裡。你要的是一個你能解釋清楚其結構的程式庫，而不僅僅是一個能跑起來的程式庫。

- 實操練習：給你的 Claude Code 工作建立一個極簡的會話模板，包含架構上下文文件、本次的具體任務，以及必須遵守的約束或模式。每次收工前，在上下文文件裡加一條簡短的日誌記錄：詳細說明開發了什麼，做了什麼決定，引入了什麼新假設。每次花五分鐘寫文件，是你防止架構漂移、避免程式庫徹底失控的最廉價保險。

## 在使用者觸碰之前進行安全審計

作為 AI 原生初創公司的創辦人，你的責任是清楚程式庫裡有什麼，弄懂潛在的暴露途徑，絕不能把明顯的漏洞推送給那些信任你的真實使用者。

Claude 能對 AI 生成的程式碼進行非常有效的初審，幫你識別常見的漏洞。把它養成上線前必做的良好習慣。但是，它代替不了專業的安全工具，而在高風險場景下，它更代替不了人類審計員——把 AI 當成萬金油的創辦人，最終都成了新聞裡的反面教材。

Claude Code Security 更進一步：它能掃描程式庫中的安全漏洞，並提供針對性的補丁供人類審計，這往往能發現傳統方法容易遺漏的隱患。

注意：在本手冊發布時，Claude Code Security 仍處於限量測試版本，所以在使用前請先確認其當前可用性。

- 實操練習：在部署給任何真實使用者之前，帶著明確的指令把核心應用程式碼推給 Claude 審計：檢查身份驗證和會話處理、API 回應中的資料暴露、輸入驗證和注入風險，以及具有已知漏洞的依賴庫。嚴肅對待每一個發現，評估是否需要修復。任何涉及驗證、金鑰或資料處理的部分，必須交由人類複核。

## 上線前先搭好資料指標框架

那些把早期流量錯當成產品市場契合度的創辦人，往往都是在發布之後才開始看資料，而且選取的指標都是為了證明「我們做得很好」，而不是去發現「哪裡不對勁」。解藥就是：在第一個使用者出現之前，先把衡量框架確立好。

用 Claude 幫你定義：對你的特定產品來說，哪些指標才最重要？基準線在哪？資料呈現什麼樣的模式才算是真正的 PMF，什麼僅僅是好聽的噪音？具體來說：在發布 MVP 之前，設定好你的留存基準線、啟用標準，以及第 7 天和第 30 天的目標。

接著，定義一下針對你產品的「假陽性」長什麼樣：比如，註冊了卻沒有啟用、有收入卻沒有留存，或者最初熱情高漲隨後卻不再重複使用。當資料出爐時，讓 Claude 站在對立面給你的資料挑刺：一個懷疑論者會怎麼看待這些數字？

## 管理調查和使用者回饋的後勤工作

一旦真實使用者進入產品，營運層面的工作就會迅速膨脹。Claude Cowork 可以接手那些重要但繁雜枯燥的工作，比如建立和維護使用者聯絡人列表、執行 email 拓展序列、安排回饋會話、對 Bug 報告進行分診，以及追蹤迭代週期。在構思階段用來管理調查後勤的 MCP 整合，在這裡同樣適用。

在回饋收集的環節中，必須保持人類在循環內，以便對使用者回饋進行細緻的探索。例如，如果使用者說「這很好，但我希望它還能……」，這就需要解讀：這是一個核心剛需還是個錦上添花的功能？它是特定於這個客戶的，還是代表了一個細分市場？缺失的功能是真正的問題，還是新手引導階段的某個上游環節沒做好？沒有任何工具能替你回答這些問題。

- 實操練習：配置 Claude Cowork 來運行你的 MVP 階段回饋閉環：起草發給早期使用者列表的 email、安排回饋日程、為 Bug 報告和功能請求設計結構化的接收流程，並撰寫一份每週收件彙總。你自己先審計這份彙總；然後，你可以讓 Claude 分析這些資訊，幫你捕捉可能漏掉的重大關鍵點。

## 向「證據」迭代，而不是向「完整」迭代

只要拿到了真實的產品市場契合度 (PMF) 證據，MVP 階段就可以宣告結束了，無論你的產品感覺起來有多「半成品」。宣稱已經實現 PMF 並準備從 MVP 階段進入發布階段，歸根結底是一個將創辦人直覺與收集到的證據相結合的判斷過程。不過，這裡有一些有用的試金石測試：

- 肖恩·埃利斯測試 (The Sean Ellis test)：去問你活躍的使用者：「如果以後你再也不能用這個產品了，你感覺如何？」如果超過 40% 的人回答「非常失望」，這就是一個非常有意義的 PMF 指標。

- 費力程度測試：在找到 PMF 之前，維持留存需要不斷的干預，包括頻繁的觸達、激勵措施、個人跟進，以及消耗創辦人極其龐大的精力才能讓使用者保持參與。但在找到 PMF 之後，產品開始自己完成這些工作。當事情開始從你「推」變成市場「拉」的時候，這種發力程度的轉變，是某個真實事物發生改變的最清晰訊號之一。

歸根結底，沒有任何單一的資料點能蓋棺定論確認 PMF，因為它必須是在經歷了多個迭代週期後依然成立的一種模式，然後你才能確鑿地下定論。

## 當證據指向別處時果斷轉型

如果投入了這麼多工作，還是找不到 PMF 怎麼辦？這不是失敗，這是系統在發揮正常作用：在錯誤的方向上浪費更多錢之前，果斷止損。

當資料不支撐你當前的產品時，利用 Claude 來深入分析資料到底在告訴你什麼。

- 探索替代客戶群體。也許沒有轉化的使用者從一開始就不是正確的目標受眾。通常正確的受眾已經隱藏在你的資料裡了，只是你權重給低了。

- 調整產品的價值主張。也許你找對了受眾，但你的 MVP 根本沒有引起使用者的共鳴。對新手引導、話術資訊或核心功能的強調重點進行微調，有可能在不改變已建構內容的情況下解決這個問題。

保持心態開放，脫節的問題可能深到需要你做出更根本的改變：

- 實操練習：如果你已經完成了三個或更多的迭代週期，但在 PMF 基準上卻沒有取得有意義的進展，在決定下一步怎麼走之前，用 Claude 跑個診斷。把你的留存資料、使用者回饋和你最初的痛點假設餵給它，然後問它三個問題：

- 資料裡有沒有哪個特定群體的反應和其餘人不同？

- 設計價值和體驗價值之間的差距，是定位問題還是產品問題？

- 當前的產品想要找到真正的 PMF，到底需要滿足什麼前提條件？結合你目前看到的現象，這種情境現實嗎？

讓這些答案來決定你是調整、轉型 (pivot)，還是退回到構思階段。

## 發布階段

如果說 MVP 階段是為了證明你的產品配得上存在，那麼發布階段，就是為了證明你的企業配得上成長。

## 發布階段的目標

在發布階段，初創公司的創辦人必須將早期的勢能轉化成一個可重複、可持續的成長引擎。除了讓你的產品達到生產級可用之外，你還必須強化底層的技術基礎設施，同時圍繞著你的產品，建立一家真正的公司。

在構思和 MVP 階段，初創公司以創辦人為中心是很自然的，因為你需要對全局瞭若指掌和緊密的回饋循環。但現在，如果創辦人仍然試圖親自抓住每一根線頭，就會成為發布階段的瓶頸。現在的目標不是讓你徹底從公司抽身，而是要建立營運系統，把你的注意力解放出來，去處理那些只有創辦人才能做出的決策。

## 發布階段的通關條件

發布階段的退出條件包含三個要素：

1. 成長是可重複的且由管道驅動。你不僅僅是在留住使用者，你還在透過特定的管道可預測地獲取他們，並且單位經濟效益是清晰的：獲客成本 (CAC)、客戶終身價值 (LTV) 和投資回收期，是那些你清楚且能辯護的數字。

1. 產品能夠處理生產負載。基礎設施得到加固，安全和合規整頓就緒，在真實的生產條件下（而不僅僅是你測試的條件下）能保持可靠性。

1. 營運不再卡在創辦人這裡。流程已經存在，自動化已經到位。你不再是那個親自處理支持、分發任務、規劃衝刺或寫報告的人。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779085863204-iaHIe5hkxXQAERlaDjpg.jpg)

## 發布階段的挑戰

找到產品市場契合度 (PMF) 是早期創業生命週期中最難的問題。現在，創辦人的挑戰變成了保持住它。發布階段是那些找到了真實產品吸引力的公司可能仍然會分崩離析的地方，如果圍繞並支持產品的組織無法跟上的話。以下是需要警惕的失敗模式。

## 技術債到期催收

挑戰：為了速度和驗證而建構的 MVP 程式庫跑得足夠好，證明了產品有效，但生產流量、新功能和不斷成長的複雜性現在暴露了它走過的捷徑。

在 MVP 時期，為了速度累積一些技術債是一個合理的權衡。在發布階段，這筆債務開始產生利息，並且懸而未決的時間越長，修復的成本就越高。

解決方案包括：進行系統的架構審計以識別結構性弱點，進行有針對性的重構以解決最嚴重的問題，以及有意義地擴大測試覆蓋率，以便下一輪的功能開發不會重新引入同樣的問題。

## 創辦人淪為最大瓶頸

挑戰：在 MVP 階段，創辦人事必躬親是一種資產。在發布階段，隨著客服請求量成長、產品決策堆積以及營運複雜性倍增，同樣的本能反而成了約束。

從執行具體工作向設計能夠執行工作的系統轉變，是初創公司生命週期中最難的跨越之一。因為很少有明確的時刻提醒你改變發生了，這裡的風險在於完全錯失良機，繼續停留在建構者模式中，而組織卻在你周圍停滯不前。發生這種情況的明顯跡象包括：本該一小時做出的決定現在需要一週時間等你處理，客服請求堆積如山因為只有你知道答案，營運任務只有當你親自想起來的時候才會去執行。

解藥是對你個人正在處理的所有事務（從最微小的任務到最高風險的決策）進行全面審計，以確定什麼可以被系統化，什麼可以被委派，以及什麼真正仍然值得創辦人投入時間和注意力。

## 安全與合規已退無可退

挑戰：在 MVP 階段保持安全和合規措施簡單是可以的，但現在，有了真實使用者、真實資料，桌面甚至可能放著企業合約，這就會變成一種負債。

在 MVP 時，只有少數幾個 Beta 使用者，生產環境中沒有敏感資料，安全漏洞只是理論上的風險。然而，當你的產品帶著依賴它的真實使用者進入生產環節的那一刻，假設立刻變成了非常真實的暴露風險。此外，當開始處理客戶資料、處理支付或銷售到受監管行業時，那些對原型不適用的合規要求，立刻就變成了硬性規定。

解藥是：在生產規模到來之前（而不是之後）進行系統的安全和合規審計，並將暴露出來的每一個問題視為必須修復的要求——而不是建議——然後才能迎接下一波使用者的到來。

## 沒準備好就盲目擴張

挑戰：新市場和融資機會看起來像成長機遇。它們同樣也可能成為產品市場契合度 (PMF) 的墳墓。

你所建立的初步吸引力是真實的，但它同樣特定於你的早期受眾。過早地擴展到一個與你原始市場有顯著差異的市場，會引入新的使用者行為、合規要求、支付基礎設施和你的產品並未針對其設計的基準期望。突然之間，新增了太多變數，你失去了清晰解讀自身資料的能力。你還面臨著為了追逐一個全新且未經驗證的受眾，而冷落原始使用者群的風險。

## Claude 如何助力發布階段的創辦人

Claude 的三種形態在發布階段都在全面投入使用，它們相互支持：每個工具產生的輸出都會成為另外兩者的輸入。結果有機地產生複利效應，同時使用這三種工具的創辦人所獲得的遠大於各部分之和。

這就是讓超精益創業模式在結構上成為可能的原因。當 Claude Code 建構產品，Claude Cowork 圍繞產品建立公司，而 Claude 幫助將這種產品和組織知識運轉起來時，一個小團隊就能跑出其體量 N 倍的爆發力。

## 趁早清剿技術債，別等利滾利

你的 MVP 程式庫能夠運行，但它也需要進行系統的排查，以尋找任何可能成為結構性負債的技術債務。

首先，利用 Claude Code 進行全面的架構審計：找出程式庫脆弱的地方、將來維護起來代價高昂的捷徑，以及測試覆蓋薄弱到下一輪功能開發會重新引發相同問題的地方。

將 Claude Code 的審計結果回饋給 Claude，對修復工作進行分類和排序：哪些需要在下一次發布前修復，哪些可以等一個衝刺週期，哪些鑑於目前的階段代表著可接受的持續債務。

這也是將你在 MVP 階段所做的架構決策（那些因為沒時間寫下來而存在腦子裡的決策）文件化的最佳時機。現在將它們放入 CLAUDE.md 中，可以確保以後的每個 Claude Code 會話都是從對系統如何設計以及為何如此設計的共同理解開始的。

- 實操練習：指揮 Claude Code 審計你的 MVP 程式庫，並生成一份包含結構弱點、測試覆蓋差距和重構候選對象的優先級列表。然後把該列表餵給 Claude，讓它跨越多個衝刺週期為你排期修復工作：你需要首先解決的重大問題、可以與新功能開發並行處理的事項，以及可以延後處理的事項。

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

建立能夠釋放你的注意力、讓你去處理只有創辦人才能應對的責任的營運系統，前提是要確切知道你的注意力都耗費在了哪裡。利用 Claude Cowork 對你當前的營運負載進行結構化審計，記錄下每一個循環任務、每一個落在你桌上的決策，以及每一個只有在你親自記起時才會發生的流程。然後讓 Claude Cowork 將這份清單分類為：可以完全自動化的、需要人工介入但不一定必須是你的，以及真正需要創辦人判斷力的。

一旦審計完成，利用 Claude Cowork 為需要自動化的任務設計工作流邏輯：什麼訊號觸發每個工作流，決策規則是什麼，輸出長什麼樣，完成後資料丟到哪裡。

## 把安全和合規變成產品開發的一部分

利用 Claude Code 找出那些在 SOC 2、GDPR 或 HIPAA 審計中經常出現的程式碼級問題，以及你的目標市場所要求的標準合規點。這能同時暴露漏洞和合規差距。將這些發現餵給 Claude，以幫助你對修復工作進行優先級排序，並設計企業買家在簽字前會要求查看的控制、審計日誌和存取權限管理。注意：AI 掃描是輔助工具，不能代替合格的合規審計。

接下來，將合規工作流建構到你的日常開發週期中，而不是將其作為一次性專案運行；合規文件需要持續維護和更新。對於正在接觸企業合約或國際市場的創辦人來說，此時也是 Claude Code 安全掃描幫助你準備獨立安全評估的關鍵時刻。

- 實操練習：帶著你的目標市場所要求的框架標準，讓 Claude Code 運行一次程式碼級安全審計。把輸出餵給 Claude，並要求它產出兩樣東西：一份帶優先級的安全補丁排期表，以及一份你為了滿足潛在企業買家合規審計所需的檔案和控制措施清單。

## 補上你一直假裝不存在的產品管理流程

發布階段需要一套輕量、可重複的流程，這些流程無需創辦人干預即可觸發或運行。利用 Claude 來設計你的產品時間表和工作週期結構、在 Claude Code 動程式碼前需求規範裡需要包含什麼、Bug 報告如何分診和路由，以及你的每週指標報告涵蓋哪些內容並如何分發。

流程設計完成後，利用 Claude Cowork 來建構和運行營運層：安排衝刺週期會議、將傳入的 Bug 報告分配到正確的位置、從連接的資料來源編譯每週指標，以及維護讓使用者訊號持續轉化為產品決策的回饋閉環。

- 實操練習：要求 Claude 設計一個輕量級產品管理作業系統：定義好的衝刺節奏、極簡需求規範模板、Bug 分診決策樹，以及一份提取實際資料的每週指標簡報。然後配置 Claude Cowork 來執行和運行該系統中循環往復的營運要素，如日程安排、路由分發和報告彙編，讓它按時自動發生而無需你操心。

## 擴展階段

在擴展階段，創辦人的角色將從建構者轉變為面向公眾的高管。產品仍然是核心，但你個人的日常工作越來越變成圍繞公司本身的經營。此時，你不僅要努力保持精益、以 AI 為中心的結構優勢，你的注意力還必須擴大到包括分析師簡報和 IPO 路演等擴展階段的新活動。

## 擴展階段的目標

擴展技術基礎設施的工作仍在繼續，現在又加入了擴展組織本身並將其發展為企業的工作。

在擴展階段，你需要面對從成千上萬的使用者激增到數以百萬計的使用者，並且從單一市場跨越到多個市場。在之前的每一個階段，成長是你透過貼近使用者，以及基於緊密回饋循環中的資料再加上創辦人強大的直覺，來摸索著調整方向的。但現在，目標是建立由成熟組織營運所支撐的系統性成長。

對於 AI 原生初創公司而言，你的目標應該是透過累積的深度來建構防禦護城河，這種深度源自你注入產品的專業知識、你的產品與使用者依賴的其他工具或平台深度整合的程度，以及專有的系統資料和業務流。只要創辦人在堅實的基礎設施上，朝著明確的方向持續建構，你現在所擁有的東西就是極難被複製的。

在這個階段，由於風險更大，公眾投資者、分析師、監管機構、企業採購團隊和收購方都會施加更大的壓力——並帶著更多的懷疑態度。你的產品和組織必須經得起外部審視：既要看產品的硬實力，還要看治理、合規、財務管控等軟實力。

## 擴展階段的通關條件

擴展階段的退出條件不再是一個單一的里程碑，而是一個門檻事件：公司能夠可持續運轉，即使創辦人越來越不再直接管理日常營運。你已經證明了系統性成長；建構了滿足最嚴苛外部審計員的組織治理和合規基礎設施；並且在被問到「如果一個資金雄厚的現存巨頭今天複製了你的產品，你的使用者還會留下來嗎？」時，你能給出堅實的答案。

在實踐中，這個門檻通常會採取三種形式之一：達到不再需要外部資金的可持續獲利規模、IPO 就緒狀態，或是被收購。這三者都要求你的成長是系統且可審計的，你的產品護城河經得起推敲，且你的組織足夠成熟和可持續。

當這些成為現實時，恭喜你：你的初創專案已經從一場押注轉變為了一門真正的生意。

## 擴展階段的挑戰

## 放權營運層

挑戰：擴展階段的營運系統必須在沒有保姆看顧的情況下可靠且可持續地運行。對於從第一天起就親力親為的創辦人來說，這種轉變在心理上的挑戰不亞於結構上的挑戰。

你在發布階段的工作是創建系統；在擴展階段，變成了 (1) 使這些系統成熟直到完全值得信賴，以及 (2) 然後真正地信任它們。

說起來簡單。即使你是一個善於放權的創辦人，到底該交出什麼、該留下什麼，通常並不明確。放權太多、太快——尤其是交給 AI 自動化系統——關鍵決策可能在缺乏只有創辦人才能提供的關鍵上下文的情況下做出。但如果抓得太久，你可能就會成為一個瓶頸。

這裡的根本挑戰在於，你要找出那些僅存在於創辦人腦海中或未記錄工作流中的機構知識，然後將它們編纂成已記錄的、可審計的、可轉移的系統。

## 擴展技術營運

挑戰：客戶不再僅僅評估你的產品功能；他們想知道你的組織是否可以成為一個可靠的基礎設施合作夥伴。

初創公司前四個階段的技術挑戰主要集中在程式庫上：在不累積技術債務的情況下建構正確的解決方案，然後為真實使用者加強安全和合規性。當到達擴展階段時，技術挑戰變成了圍繞程式庫的一切；創建支撐設施、文件以及證明成熟度的可靠性保證。

簽署多年期合約的更大型客戶和機構買家會在簽字前要求看到這些東西，一旦簽約他們也會拿這些來約束你。

然而，幫助你走到這一步的同一個 AI 基礎設施，也可以幫助你建構具備明確回應時間支持的專用支持功能，以及新客戶的工程團隊能夠真正使用的文件。

## 擴展組織職能

挑戰：一個處於擴展階段的公司通常需要招聘、薪資管理、會計核算和法務營運等組織基礎設施，不管到底有幾個人在跑業務。

在發布階段，系統化營運意味著把消耗創辦人注意力的工作流自動化。到了擴展階段，初創公司現在需要發展出更廣泛、在某些方面也更關鍵的一系列營運功能，例如財務報告、合規監控、合約管理以及客戶支持等等。

## 建立 GTM (市場推廣) 職能

挑戰：有機成長是有天花板的，而大多數擴展階段的創辦人在還沒有來得及建立真正的市場推廣 (GTM) 職能時，就已經撞到它了。

構思、MVP 和發布階段的成長通常源於創辦人主導的銷售，從一個恰到好處的 Product Hunt 貼文到與早期客戶的個人關係。但這種有機成長只能走到某一步，大多數初創公司在擴展階段達到了這個極限。跡象包括使用者曲線拉平、獲客成本上升，以及只有創辦人親自介入時管道才會有動靜。

擴展階段的成長需要建立一台專用的成長引擎，觸達產品新的、更廣泛的受眾群。然而，大多數初創創辦人以前可能從未親自操盤過諸如市場行銷、大客戶銷售和分析師關係等專案。一個正規的 GTM 動作需要的不僅僅是建立新系統和流程，還要為你希望如何講述你的產品創立一種品牌腔調和故事。因為，在初創公司生命週期的這個階段，你需要依靠它不僅來觸達個體新使用者，還要觸達包括投資者和企業買家在內的整個目標受眾群。

幸運的是，GTM 職能並不需要龐大就能奏效，建構了產品的同一個 AI 基礎設施同樣能將其推向市場。

## Claude 如何助力擴展階段的創辦人

早期的初創階段利用 Claude 作為產品本身的基礎設施：它是驗證想法的研究夥伴、設計和建構原型的工程師團隊，以及使單人初創公司成為可能的 AI 營運層。熬到了擴展階段的 AI 原生初創公司創辦人，現在可以利用 Claude、Claude Code 和 Claude Cowork 來以與開發時相同的方式繼續擴展公司規模。

## 將日常雜活甩給 Claude Cowork

開啟擴展階段時，你必須清楚眼下最需要投入時間和精力的地方，這對於沒開過公司的初創創辦人來說可能是個挑戰。Claude 可以幫你列出在這個階段「只有你才該做的事情」的清單，這可能包括諸如產品敘事決策、董事會關係、企業級交易以及創辦人對創辦人的對話等。未出現在此清單上的任何事，都是委派或借助 Claude Cowork 自動化的候選對象。

- 實操練習：讓 Claude 幫你畫出現有營運層的瓶頸地圖：列出當前所有透過你路由的工作流、決策和審批節點。

現在，問 Claude：如果你消失一週不干預，每一個環節會發生什麼？那些陷入停滯的工作流，就是你仍然過度親力親為並拖慢進度的地方。

這與你利用 Claude 制定的創辦人優先級清單和職責盤點吻合嗎？

接下來，需要進行壓力測試，確保你已經建立的系統在業務成長時能真正做好擴展的準備。

- 實操練習：利用 Claude 映射當前工作流，然後問它：如果我消失一週會怎樣？那些停擺的工作流，正是交接標準、升級匯報路徑或異常處理機制仍需強化的地方。Claude 可以幫助分析這些失敗節點並推薦合適的修補方案，以便你可以根據需要更新或替換 Claude Cowork 的自動流。

## 將技術營運擴展為企業級基礎設施

隨著規模的擴大，買家需要確認你的產品和組織可以作為長期基礎設施被信賴。程式庫內的技術工作一如既往地進行，但現在還需要處理圍繞程式庫的外圍技術工作。

第一步是將機構知識轉化為可以規模化的系統。利用 Claude 起草並維護企業採購團隊希望看到的書面基礎設施，包括產品文件、客戶支持操作手冊和 SLAs (服務級別協議)。

同時，指揮 Claude Code 審計並加固程式庫，使其符合企業合約要求的特定可靠性和安全標準，並建構那種僅僅在 Discord 社群服務時無需提供的技術支持基礎設施：日誌、監控、事件回應工具，以及使 SLAs 真正可執行可觀測分層。

然後，Claude Cowork 負責運行企業級支持本身的營運層：工單路由、升級提醒工作流、由產品變更觸發的文件同步、續約追蹤，以及企業客戶成功團隊所依賴的定期匯報週期。這三者結合，讓一個小團隊擁有了龐大得多的組織支持態勢，這正是你簽署多年企業合約時所需展示的肌肉。

- 實操練習：挑選出你最苛刻的三個潛在客戶，或確定三個你極其渴望簽下的理想客戶企業。讓 Claude 出一份差距分析報告：這些公司的企業採購大爺們在簽署多年長約之前，希望看到什麼樣的支持文件、SLAs 和基礎保障體系？你現在還差多遠？利用輸出的報告，在 Claude Code 和 Claude Cowork 之間排期分配各項技術和文件工作。

## 建立真正的 GTM (市場推廣) 職能

創辦人的幹勁把你帶到了這裡，但擴展初創公司規模需要創建並實施一套真正的市場推廣策略。AI 能夠幫你建構並運行這一整套 GTM 引擎。

Claude 可以協助你從頭建立基礎的 GTM 武器庫：細分市場、搭建話術架構、制定分析師關係策略、編排銷售話術本，以及當你面對公眾投資者、企業買家和華爾街分析師時那些極其關鍵的面向投資者的敘事故事。這些受眾都有自己的「黑話」，並且用他們自己的標準來評估你；Claude 的任務是將你的產品價值主張，翻譯成與每個細分受眾群都高度相關的產品行銷手段。

此時，Claude Cowork 就成為了你的戰術執行層：生產內容流水線、群發開發序列信件、安排分析師簡報會後勤、制定新聞發布室和 PR 宣傳節奏、清理 CRM 資料、匯報銷售漏斗進度，以及運行各種將 GTM 策略轉化為真金白銀交易的重複週期。

如果 GTM 動作需要硬核的產品行銷基礎設施——互動式演示環境、對接整合文件、沙盒測試租戶、API 說明手冊、技術核心一頁紙——Claude Code 可以幫你搞定。買方期望能從技術層面上實打實地評估你的產品，在擴展階段，丟過去一個 Loom 錄影和一份 PPT 早就不夠用了。而且，正是這種基礎設施讓你的 GTM 動作實現了非同步運

## 標籤

產業趨勢, 教學資源, AI-native