AI 正在重塑新創的打造方式。如今，從沒寫過一行程式碼的創辦人，已經能推出真正上線的應用程式；而那種精實到只有 10 人的獨角獸，也從草根逆襲的傳奇，變成一套可以刻意執行的行動計畫。

來到 2026 年，AI 能寫出可上線的程式碼、做市場研究、彙整競爭格局、草擬募資文件，還能把營運流程自動化。過去，就算是經驗老到的技術型創辦人，光是要把實現構想所需的各種工具、平台與系統整合起來，都得面對一道陡峭的學習曲線；如今 AI 把這道曲線徹底抹平，最重要的是，它讓「誰能創業、誰能打造產品」這件事真正站上了同一條起跑線。

來到 2026 年，一個好點子能帶創辦人走得比以往任何時候都遠。agentic coding 把過去需要一整支工程團隊才做得完的事，壓縮成創辦人自己一個人就能推出的成果。

傳統的新創成長曲線預設：從構想到規模化的路徑，就是「驗證 → 募資 → 招人 → 打造 → 再募資 → 成長 → 招更多人 → 不斷循環」。如今，AI 已經抹去了那個成見——以為新創生命週期的每一個新階段，都必須配上更龐大的團隊、一套全然不同的技能組合，以及一輪全新的資金。

這本手冊依據這些全新的現實，重新繪製新創旅程的四個核心階段（構想、MVP、上線、規模化）。我們會逐一檢視：當 AI 成為你技術與組織發展的核心時，每個階段會長成什麼樣子、各階段最合適的工具是什麼，以及正在運用這些工具的創辦人是如何把時程一再壓縮的。如果你已經準備好，要為自己畫出一條從構想到 exit 的最短路徑，那就繼續讀下去吧。

過去，創辦人是由「他們會做什麼」來定義的：技術型創辦人寫程式碼，非技術型創辦人負責營運與談成交易。但到了 2026 年，創辦人手上能用的模型、系統與 AI agent，已經把「會做東西的人」和「擁有值得做的點子的人」之間那道牆給溶解了。

AI 原生（AI-native）新創正在從根本上改寫「身為創辦人」的意義。如今，一個毫無工程背景的人，也能打造出可上線的軟體、讓自己的點子成真；而一位技術嫻熟但幾乎不懂商業的創辦人，也能輕鬆產出進入市場（go-to-market）策略、財務模型，以及一份極為精緻的 pitch deck。

過去，創辦人把大部分時間花在執行模式上：寫程式碼、管理人、處理日復一日的營運雜務。在 AI 原生新創裡，創辦人的角色大幅從「個人貢獻者」轉變成各種 agent 的指揮者——這些 agent 是專門的 AI 助理，能讀取檔案、執行指令、跑程式碼，甚至上網瀏覽。創辦人的注意力往上層移動，聚焦在更高階的工作：產生點子，並指揮把這些點子付諸實現的各種系統（AI agent、工具，以及任何一支小團隊）。

不過，AI 成為核心基礎設施後，最具革命性的結果，是讓擁有領域專業知識的非技術型創辦人不再受限。當創辦人的來源不再侷限於有工程背景的人，你會看到一群擁有截然不同人生經歷的人開始打造新創，去解決那些傳統科技創辦人管道從未優先處理（甚至可能根本沒注意到）的真實問題。

精實新創可運用的 AI 工具能力

傳統的新創模式假設你需要僱工程師來打造、僱業務來銷售、僱營運人員來把公司運轉起來。人力編制被當成組織動能與產品成熟度的象徵。到了 2026 年，早期新創徹底不同。它們在設計上就極度精實，往往只有創辦人單打獨鬥，或是一支只有寥寥數人的團隊。透過把技術與組織的發展都圍繞著「AI 作為基礎設施」來建構，它們可以在擴張團隊之前，就達到產品驗證、早期營收，甚至是獲利。AI 在三個面向上特別能讓一家新創像規模大得多的組織那樣運作：研究、agentic coding，以及把關鍵業務營運的工作流程自動化。

對話式智慧與研究

可以這樣想：每個領域都有一位隨時待命的專家

想想看，創辦人在第一年裡需要懂、但進場時幾乎篤定不懂的所有事：薪資該怎麼設？產品開發的衝刺（sprint）該怎麼規劃？一份扎實的投資人備忘錄（investor memo）該怎麼草擬？

以前，這些早期新創會碰到的問題，答案都一樣：去找一個懂的人。對一位自籌資金（bootstrapped）或種子前期（pre-seed）的創辦人來說，這可能意味著把本該拿來打造產品的時間，耗在蒐集知識上，又或是得燒掉一筆寶貴的早期資金去請顧問。如今，他們有了 AI 這位橫跨各種可想像領域、隨時待命的專家。

• 深度研究：競爭分析、市場規模估算、財務建模

• 文件草擬：pitch deck、案例研究、投資人備忘錄、PRD

• 策略思考夥伴：魔鬼代言人式的分析、事前驗屍（pre-mortem）、情境規劃、產品藍圖（roadmap）最佳化

Agentic coding

可以這樣想：一位永遠在線、永不卡關的工程師

過去，要打造軟體就得有一位技術共同創辦人、一間外包開發公司，或是足夠長的資金跑道（runway），好在你寫下第一行可上線的程式碼之前就先僱齊一支工程團隊。

如今，agentic coding 工具讓每一位有志的創辦人都能用白話描述自己想打造什麼，並指揮 AI 去生成、測試、除錯、重構一套可上線等級的程式碼庫——其速度與規模媲美一整支工程團隊。

從「我有一個點子」到「我有一個產品」的時間軸，被大幅壓縮了。而創辦人的角色如今聚焦在「要做什麼、為什麼要做」，至於把可供真實使用者使用的真實基礎設施實際建出來，則交給 AI。

工作流程自動化

可以這樣想：一支隨需待命、全自動的營運團隊

就算一位創辦人能像顧問那樣做研究、像工程團隊那樣打造產品，仍然有一整類超出策略規劃或產品開發範圍、卻非做不可的工作。排程、更新 CRM、拉每週報表、讓文件保持最新、發布內容、追蹤法遵需求、維繫公司所倚賴的各種工具與系統之間的連結——這些也都得有人做。在一家精實新創裡，這些負擔主要落在創辦人身上——而它正是一筆沉重的稅，吃掉了本該投入更高階決策的時間與心力。

用 AI 工具做工作流程自動化，能卸下這筆稅。重複性的營運任務可以設定成自動發生：交易一推進，CRM 就自動更新；每週報表自己編好；產品文件也隨產品變動同步更新。而且，關鍵的是，Claude Cowork 能與一家新創所倚賴的環環相扣的系統整合——你的專案管理工具、你的溝通工具組、你的資料來源——而不需要有人專門去建置與維護這些整合。在「第零天」（Day Zero）的新創裡，那個人幾乎總是創辦人本人。

時機與指揮調度，就是一切

能有效駕馭 AI 在研究、自動化與 agentic coding 上的能力的創辦人，可以打造出一家槓桿效益遠超其人力編制的新創。他們也得以把絕大多數的時間與精力，投注在真正重要的工作上。

這些工作不會自動駕駛般地完成；指揮這些 AI 工具的創辦人，必須知道該如何（以及在什麼時候）運用它們。本手冊接下來的篇幅，將致力於探討創辦人走在 AI 原生新創這條路上會遇到的目標與挑戰，以及如何在這趟旅程的每一個階段，有效地運用 AI 工具。

每一位新創創辦人都從同一個地方出發：一個揮之不去、讓你念念不忘的問題。這是構想與現實正面交會的階段：在 2026 年，新創要成功，靠的是一種紀律——在證據足以支撐之前，絕不動手開始打造。

這個階段的工作是研究、顧客探索、競爭分析，以及誠實地檢視反證，這一切都要在你請 Claude Code 生成第一行正式產品程式碼之前完成。

構想階段的目標

在構想階段，創辦人的主要目標是以研究為導向的驗證：在投入資源去打造任何東西之前，蒐集扎實的證據，證明一個真實的問題確實存在（而且你提出的解決方案能有效地解決它）。

講得具體一點，構想階段就是一連串問題，創辦人必須大致依照以下順序去回答：

• 這個問題夠真實、夠具體、發生得夠頻繁，值得圍繞它來打造產品嗎？

• 究竟是誰有這個問題，而這群人構成一個市場嗎？

• 有沒有其他人正在解決它？如果有，他們怎麼解、解得好不好？

• 一個解決方案實際上需要做到什麼，才能真正解決這個問題？而我的構想有做到嗎？

這些探問的結果加總起來，最終是要回答一個終極問題：這值得打造嗎？

這代表你得先把問題講清楚，再開始行動。「大家都覺得報帳很麻煩」只是一個觀察。「中型企業的財務主管每週花四小時以上對帳，因為他們現有的工具無法和會計軟體整合」才是一個可以拿來驗證的假設。

構想階段的離開條件

構想階段的離開條件是找到問題與解決方案的契合（problem-solution fit）。你已經建立起質性證據——主要來自與真實人物的對話——證明你正在為真實的人解決一個真實的問題，然後才開始打造那個用來解決它的東西。

當你能對以下三個問題都回答「是」，你就準備好離開構想階段了：

1. 這個問題夠真實、夠具體嗎？要在這裡回答「是」，你必須能明確指出究竟是誰會碰到這個問題、他們多常遇到、問題對他們的影響有多嚴重，以及他們目前是怎麼應對的。

1. 你的解決方案是在解決那個真正的問題嗎？不是你一開始假設的那個問題，而是驗證過程揭露出來的那個。有時兩者相同，但並非總是如此。

1. 你手上的訊號足以支撐你開始打造嗎？在這個階段你永遠不會有確定性，而苦等確定性本身就是一種失敗模式；但你需要足夠的質性證據，讓「投入做 MVP」成為一個經過推敲的決定，而不是一場信仰之舉。

構想階段的挑戰

構想階段是你整段新創旅程中最重要的工作所在，因為這裡也是最關鍵的錯誤發生之處：此刻一旦弄錯了什麼，很快就能讓你剛萌芽的事業徹底脫軌。不過，發想階段的多數挑戰都源自一件事——走得比你的理解所能支撐的還要快；因此，凡是審慎、深思熟慮地推進的創辦人，都會體驗到穩定的進展。

把「打造」誤當成「驗證」

挑戰所在：當技術上的阻礙被移除，一位熱血的創辦人很容易跳過新創旅程中最重要的工作：驗證自己的構想是否真的是一個人們需要、而且會去使用的解決方案。

早在當前 agentic coding 的時代之前，就有 42% 的新創因為打造了沒人想要的東西而失敗。而如今，像 Claude Code 這類 agentic coding 解決方案已經把「我有一個構想」到「我有一個產品」之間的距離大幅壓縮，而這個失敗率只會繼續往上爬。

雖然從來沒有哪個時刻像現在這樣，特別適合一個懷抱絕妙構想的創辦人，但能如此快速、輕鬆地兜出一個看起來像產品的原型，反過來說，也為 AI 原生新創帶來一個真正危險的生存風險。

直到不久以前，打造產品都還需要實打實的開發時間與預算，光是把一個最基本的原型湊出來通常都得花上好幾個月。然而如今技術開發這道門檻幾乎已經消失，AI 讓創辦人太容易就一頭栽進去開始打造，卻沒有先在真實世界中驗證它到底有沒有用。

要達到問題與解決方案的契合，必須先驗證假設、再開始打造；但許多初次創業（甚至是資深）的創辦人卻誤以為 AI 能讓人跳過這道程序，把流程變成：有個構想 → 立刻打造原型 → 把原型存在這件事本身當成驗證。於是原型成了「假設從頭到尾都是對的」的理由，卻從來沒有真正去測試它究竟是不是真的。

一個能跑的原型，很容易被誤認為是「你正在解決一個真實問題」的具體證據，但它不是。你的原型真正的角色，是在和潛在使用者對話時，拿來壓力測試的一個有用道具。這些對話本身，才是真正的證據。

過早規模化

挑戰所在：當打造變得毫不費力、立竿見影，你的執行規模就可能遠遠超前於業務真正的需求。

過早規模化，指的是在你真正驗證一條產品路徑是否值得投入之前，就先一頭栽進這條路。

這一直都是新創殺手，但 AI 讓創辦人更容易在毫無察覺的情況下落入過早規模化的陷阱。agentic coding 助手強大到一個程度，你很容易在驗證問題與解決方案契合之前就把執行規模衝得老遠，而且從來沒有意識到自己其實已經偏離了航道。

它會圍繞著一個根本上有缺陷的前提去生成、測試、除錯、重構整個程式碼庫，那股熱情和它面對一個絕佳構想時一模一樣。這套系統裡的智慧，是你自己。在這個階段，最高指導原則就是讓你的「判讀理解」始終跑在「打造」前面——尤其在打造變得如此快速、又如此毫不費力的時候。

失去客觀性

挑戰所在：你向 AI 工具索取支持你既有信念的證據，它就會找給你。如今確認偏誤還配備了一具研究引擎。

確認偏誤（confirmation bias）一直是新創圈的職業傷害：創辦人天生就對自己的構想充滿熱情。如今，AI 工具更給了確認偏誤一次重大升級。要 AI 驗證你的新創構想，它就會找到支持的證據；要它估算你的潛在市場，它就會找出一個讓你的 TAM 看起來值得投資的數字。

AI 會順著你的指示走，這意味著一個不去追問尖銳問題的創辦人，現在能用前所未有的速度，為一個糟糕的構想建構出一份精緻、看起來研究得很扎實的論證，同時還滿懷信心地以為自己正在做盡職調查。解方就是同一個工具，只是把它指向相反的方向：AI 在壓力測試一個構想時，會跟它驗證一個構想時一樣徹底。

當研究與有結構的對抗性思考浮現出「你的構想需要修正」的證據時，這就是轉向（pivot）的訊號。

Claude 如何協助構想階段的創辦人

讓你的 AI 原生新創概念走過構想階段，感覺起來可能像是永無止境。你是創辦人，你就是想趕快動手打造。但這個至關重要的開場階段，本質上是一場研究與驗證的功課，這意味著在全力投入寫程式之前，你要先伸手去拿那些能幫你更嚴謹思考的工具。以下是一些方法，教你如何跨越 Claude 的各種使用形式（Chat、Claude Cowork 與 Claude Code），在做足盡職調查的同時，盡可能快速地走完構想階段。

Chat、Claude Cowork，還是 Claude Code：

選對 Claude 的使用形式

AI 讓新創創辦人更容易加速出貨、自動化繁瑣的工作流程，並以規模化的方式運作，但你選用哪一種使用形式很重要。以下說明因應手邊的任務，何時該用 Chat、Claude Cowork 或 Claude Code。

Chat 適合在你已經身處的 app 裡進行快速來回，不必離開當下的工作環境。拿它來處理經營公司時源源不絕的小事：從一份密密麻麻的投資人備忘錄裡擷取一句話的重點、在董事會前先把某個說法做一次合理性檢查，或是釐清你和團隊之間一條冗長的 Slack 討論串到底在講什麼。

Claude Cowork 適合那些真正得花時間的知識工作：從眾多來源彙整資料、理出頭緒，並產出一份完成度高的成品，例如一份文件、簡報或試算表。想想看：把一整個資料夾的顧客通話逐字稿，整理成一份依主題分類的發現文件，供你下一次產品檢討使用；在募資前，從一打廠商網站建立起競爭格局；或是一項固定在每週一早上執行的任務，從你串接的工具裡拉出各項指標，把一份每週 KPI 摘要丟進共用資料夾。

Claude Code 是為你團隊裡的工程師打造的 agentic coding 環境：可直接存取程式碼庫、具備 Plan Mode、git 整合，以及本機、IDE 或沙箱雲端環境。它正是一支精實團隊在不斷成長的程式碼庫上推出功能、把 MVP 時期的舊程式碼遷移過來，並在不必等待擴編人力的情況下從原型走向正式產品的地方。這三者底層共用同一個 Claude；改變的只是包圍著它的工作空間。

定義並壓力測試問題假設

你自己的領域專業與前期研究，已經產出了一個假設。第一件工作是把它打磨到真正可以拿來驗證。Claude 在這裡特別好用，因為它能逼你講得具體：究竟是誰有這個問題、多常發生、有多嚴重、他們目前都怎麼處理？一個無法精準回答這些問題的問題陳述，還不到可以驗證的程度。

• 練習：和 Claude 一起把你的問題陳述打磨成一個可驗證的假設。舉例來說，「合約審查花太久了」沒辦法拿來做有意義的驗證。但是「中型企業的內部法務團隊每一輪合約審查都要花 3 天以上，因為紅線修訂是散落在多條 email 討論串裡管理，而不是集中在單一份有版本控管的文件上」就非常可驗證。

接下來，要請 Claude 反過來駁斥你的構想，去找出能推翻你假設的反證。這能讓你看見負面的市場訊號、失敗的競爭者、顧客行為模式，以及種種結構性障礙——這些東西，在一份只想支持你的整理裡，往往會被悄悄地降到次要位置。

我們的目標，是讓你在進入顧客探索之前，就已經拿你的假設去和現有最強的反方論點正面對撞、做過壓力測試，這樣那些蒐集資訊的使用者訪談才會真正保持開放，而不是淪為一場尋找認同的行動。

注意：把 Claude 當成有結構的魔鬼代言人，是 AI 新創生命週期每一個階段的核心用途。

市場研究與描繪競爭格局

掂量你的競爭者

有一種新創特有的現象，叫做競爭者忽視（competitor neglect）：你太過專注於自己的願景與執行，以致於系統性地低估了同一個領域裡其他人正在做的事。所幸，AI 提供了解方：請 Claude 提出最有說服力的論證，說明為什麼這個解決方案領域裡的某個競爭者會成功、而你會失敗。

Claude 可以分析為什麼他們的做法其實更好、為什麼顧客會選他們，以及為什麼你那些自以為的差異化優勢，可能沒有你想像的那麼難以攻破。

• 練習：請 Claude 依層級描繪你的競爭格局：直接競爭者、間接競爭者、潛在收購方，以及那些可能跨界進入你領域的鄰近玩家。然後請它論證為什麼每一個層級都對你的成功構成真正的威脅——不是那種最容易被你一笑置之的威脅版本。

市場研究

Claude Code 可以彙整公開可得的顧客回饋，浮現出反覆出現的抱怨與未被滿足的需求。額外的好處是：這麼做，本質上等於對你競爭者的顧客做了一次免費的質性研究。

• 練習：指示 Claude Cowork 跨你的關鍵來源彙整競爭者的評論，找出現有解決方案尚未解決的幾項主要抱怨。如果你的假設能解決其中一項或多項，那就是問題與解決方案契合的有力證據。如果不能，那也很值得知道。Claude Cowork 也能從密密麻麻的產業報告、分析師報告與市場研究文件中，萃取出相關的資訊與數據；接著，這些乾淨、彙整過的輸入，就成了 Claude 進行分析工作時的理想脈絡。

• 練習：用公開可得的資料建立 TAM／SAM／SOM 模型，並對這些模型背後的假設做壓力測試。判斷這個市場是正在擴張、整併，還是已經成熟；這個脈絡會影響你思考時機與差異化的方式。描繪買方的格局：誰握有預算、誰影響決策，以及這兩者是不是同一個人。

趨勢分析

最後，用 Claude 去傾聽那些早期指標，看看你是不是在對的時機進場。追蹤那些已經在討論你這個問題的 subreddit 與 LinkedIn 社團，以及使用者在描述自己的困擾時，會精確選用哪些字眼。請 Claude 找出曾經解決過類似問題的類比市場，並萃取出哪些做法奏效、哪些行不通。浮現出那些可能加速或威脅這個機會的法規、技術或人口趨勢。

• 練習：請 Claude 找出三個外部趨勢——法規、技術或人口面向——在未來兩年可能顯著影響你市場的趨勢，並評估每一個對你那個特定假設而言，究竟是順風還是逆風。

注意：本節的市場研究與競爭格局描繪工作，並不是一次性的功課。你在 MVP 階段與上線階段，仍會持續有新發現、持續演進你的思考，因此每當你的假設有所演變時，重做這些練習就很重要。

規劃並設計顧客探索

你和產品潛在使用者對談所學到的東西，品質取決於兩件事：(1) 你提問的品質，以及 (2) 你是不是把這些問題拋向了對的人。Claude 在進行顧客探索時特別有幫助，包括該找誰談、該問什麼，以及如何理出你聽到的內容。

該找誰談

一份精準的目標輪廓，遠比一張長長的聯絡人清單有價值無數倍，其中包括最可能切身感受到這個問題的特定職稱、公司類型、團隊結構與資歷層級。從這裡出發，找出這些人實際上可以在哪裡被接觸到——他們聚集的社群、活動、LinkedIn 社團與 Slack 工作空間——並依據他們離問題有多近，建立一套「該先聯絡誰」的優先排序框架。

該問什麼

定義好目標對象後，用 Claude 來建立訪談框架本身：對的問題、對的順序，並以能浮現「人們實際上怎麼做」而非「他們以為自己會怎麼做」的方式來組織。新手創辦人常犯的錯，是問一個關於未來、籠統又開放的問題（「你會用像這樣的東西嗎？」），而不是具體地探問相關的過去（「跟我說說你上一次碰到這個問題的情況。」）。

Claude 也能標出你草擬的問題裡，哪些在引導受訪者、哪些太過寬泛，或哪些可能只會製造雜訊而非訊號。Claude 還能協助你設計追問問題，用來探究受訪者的閃躲，或針對重要問題的含糊回答進一步深掘。

如果你的假設牽涉到不只一種人物（persona），Claude 也能為每一種設計不同的問題組。一位財務主管和一位 CFO 對同一個問題有著不同的關係，而單一一套訪談框架會把這種差別抹平。

• 練習：先親手草擬你的訪談問題，再請 Claude 來審核。明確要求它標出任何具引導性、面向未來、過於寬泛，或可能誘出「社會期許答案」而非誠實答案的問題。然後請它針對訪談中最可能引發閃躲的兩、三個時刻，建議相應的追問。

訪談後的分析

每一次對話結束後，用 Claude 來做事後檢討：把你的筆記餵給它，請它找出哪些內容印證了你的假設、哪些挑戰了它，以及哪些真正出乎意料。等你蒐集到一批訪談之後，把整套訪談筆記丟進 Claude Cowork，浮現出反覆出現的主題、矛盾之處，以及正反兩個方向上最強的訊號。接著把那份彙整後的輸出帶回 Claude，請它標出哪些地方你對資料的解讀，可能是在迎合你想聽的，而不是資料裡真正存在的。

• 練習：每做完五場訪談，就指示 Claude Cowork 彙整你的筆記，並產出兩份清單：支持你假設的證據，以及挑戰你假設的證據。如果第一份清單明顯比第二份長，請 Claude 判斷這種不對稱反映的是資料裡真實的樣貌——還是你本來就希望找到的東西。

顧客接觸與排程

用 Claude Cowork 來自動化「建立聯絡人清單、進行接觸、安排使用者訪談」這一整套圍繞著它的營運負擔。

Claude Cowork 可以運用你和 Claude 一起定義出的目標輪廓（包括職稱、公司類型與資歷層級），去研究並彙整出一份結構化的潛在對象清單，附上經過查證的聯絡資訊。接著它會大規模草擬個人化的接觸 email，依每個人的角色與處境量身打造。

隨著回覆陸續進來，它會透過 MCP 串接 Gmail 與 Google Calendar，管理討論串、處理排程請求，並把訪談排進行事曆。這個工作流程會持續運轉：Claude Cowork 會依設定好的節奏產出追蹤信草稿（例如針對未回覆的聯絡人在第七天發出的追蹤信），並在每一步完成時更新你的追蹤表，讓你隨時清楚每一位潛在對象在這條流程裡進展到哪裡。

• 練習：把你驗證過的訪談目標輪廓交給 Claude Cowork，請它建立一份潛在對象清單、草擬一套個人化的接觸序列，並建立一張追蹤表，欄位包含接觸狀態、追蹤節奏與訪談完成情況。然後讓它去跑這些協調工作，你則專注於為對話本身做準備。

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

驗證工作你都做了：問題是真的、你知道誰有這個問題，而且你手上有一個證據支持的解決方案概念。用 Claude 從各個角度去發展並挑戰你的解決方案概念：缺口在哪裡？有哪些替代方案？要讓這個解決方案能規模化地運作，什麼必須為真？這是一個重要的現實檢查點：這個設計真的在解決驗證過程揭露出來的那個問題，而不是你一開始一頭栽進去時所假設的那個問題嗎？

• 練習：把你的解決方案概念呈現給 Claude，請它找出你的設計最仰賴的三個假設。然後問：要讓每一個假設成立，什麼必須為真？以及，萬一其中任何一個不成立，後果會是什麼？

用 Claude Code 打造一個輕量原型

現在來到有趣的部分了：有了一個驗證過的假設，以及一個經過壓力測試的解決方案概念，你終於準備好可以動手打造點東西了。

這正是構想階段裡 Claude Code 登場的時刻。即使你一路上都在東摸西摸地試做，現在才是你生成正式輕量原型的時間點：把你的構想擺到一個真實的人面前、取得真誠反應，所需要的最小介面範圍。

你（還）不是在打造一個真實世界的產品；你是在建構一個能運作的構想樣本，用於和顧客與投資人的對話。真實使用者對一個他們能真正觸碰的東西所做出的反應，會告訴你十幾場問題與解決方案探索訪談都問不出來的事。先前，你是在確立你要解決的問題是真實的；現在，你是在請潛在使用者實際接觸你提出的解決方案。

• 練習：定義你的解決方案所仰賴的那一個核心互動。指示 Claude Code 只打造那一個。做出來之後，把它擺到五位來自你驗證過的目標輪廓的人面前，請他們試用看看。你在那五場對話裡學到的東西，將決定你是要繼續打造，還是回到原點重新來過。走到構想階段的尾聲，在這場 AI 新創競賽裡是一次巨大的躍進，因為現在你不是在賭一個直覺；你是在依據證據執行。接下來進入 MVP 階段，創辦人的指引問題會從「這值得打造嗎？」轉變成「我們究竟該先打造什麼？」，而 AI 的主要角色，也會從研究夥伴轉變為施工團隊。

許多創辦人把 MVP 階段當成單純的「打造產品」階段，但本質上，MVP 階段依然是一場蒐集證據的工作。差別在於，你現在蒐集的是關於「解決方案」的證據，而不再是關於「問題空間」的證據；具體來說，就是要找出是否真有一群可被明確指認的人，覺得這個產品有價值到願意使用它、回頭再用、付費購買，並／或向別人推薦它。

MVP 階段目標

身為 AI 原生新創的創辦人，你的目標是把一個已驗證過的問題，轉化成一個真實使用者真的會用的可運作產品。這不是塞滿產品路線圖上每一項功能的完整版本，而是把你構想中最小、最聚焦的一次迭代，做成一個真正的解決方案，擺到真正的使用者面前，並產生產品與市場的契合（product-market fit）的真實證據。

同時，你「現在怎麼打造」會決定「日後可能做到什麼」。這意味著 MVP 階段還有第二個、同樣重要的目標：在快速前進的同時，不要累積那種會利滾利的技術債——那種一旦真實使用者大量湧入，就會立刻反過來糾纏你的技術債。

最後，從第一天就投資於可持續累積的脈絡（context），才能讓 AI 持續是放大戰力的乘數，而不是製造混亂的亂源。在 AI 原生新創裡，你的程式碼庫是你一次又一次與 AI 協作的對象，這讓「可讀性」成為地基。那些跳過規格、架構決策與脈絡檔案（例如 CLAUDE.md）的創辦人，遲早會撞上一道可預期的牆：每開啟一個新工作階段都得重新解釋一遍程式碼庫，而 AI 生成的改動則一點一點偏離最初的願景。

MVP 階段離開條件

MVP 階段的離開條件，是產品與市場契合的真實證據：證明有一群明確、可被指認的使用者，覺得產品有價值到願意回頭再用（留存）、願意付費（營收），或願意推薦給別人（轉介）。

MVP 階段的挑戰

在 MVP 階段，創辦人的最高指導原則是速度與判斷力。這裡的挑戰核心在於：你能不能用對的方式、打造對的東西，而且快到足以發揮作用，同時又不會為了搶快而抄了會在日後讓你付出代價的捷徑。

代理式技術債

挑戰：因為 AI 基本上移除了過去每一道控管「什麼東西能進到正式環境」的天然瓶頸，速度幾乎是保證的。但當速度是創辦人在打造 MVP 時唯一考量的變數，他們就有可能累積出將來難以償還的技術債。

在 MVP 階段，有些技術債是適當的，前提是你清楚它必須在規模化之前處理掉。這類技術債是慢慢累積的，可以隨著時間或安排一次專門的衝刺（sprint）來清償。然而，AI 技術債卻是會利滾利地複利累積的。

如果沒有把規格與架構限制寫在 AI 讀得到的地方，每個工作階段都會從零開始重新推導那些根本性的決策，而那些決策會逐漸偏移。最後你會得到一個背後沒有一致心智模型的程式碼庫——不是因為哪一塊單獨做得差，而是因為這些零件從來就沒被設計成能彼此契合。這是個實實在在的問題，而且往往會在很晚才浮現。

落入虛假的產品與市場契合

挑戰：AI 工具能產出亮眼的早期數字，但這些數字並不能保證市場真的需要你的產品。

早期的氣勢，是創辦人能體驗到、在心理上最具感染力的經歷之一。經過數週或數月的驗證工作，以及謹慎、有紀律的打造之後，把產品推出去的那一刻，會讓人覺得彷彿在確認「你從頭到尾都是對的」。

agentic coding 工具能讓你比以往任何時候都更快抵達這一刻，但早期的成長動能並不等於產品與市場的契合。上線時的能量往往來自一些短暫、易逝的力量，例如創辦人的朋友捧場、你的投資人旗下其他被投公司的潛在買家，或一則衝上 Hacker News 的標題帶來的流量尖峰。可惜的是，這些都無法可靠地預測：當那股初始的助力消退之後，第六週或第十二週會發生什麼事。

零摩擦的範疇蔓延

挑戰：當打造產品變得毫不費力、幾乎零成本時，永遠都還有「再加一個很酷的功能」或「再處理一個邊緣案例」的衝動。這種範疇蔓延（scope creep）帶來的傷害，可能多過好處。

範疇蔓延一直都是新創的風險。如今的差別在於，過去用來抑制它的那道「強制機制」——工程時間的真實成本——已經不再以同樣的方式存在了，因為現在新增一個功能只要一個下午，而不是一整個衝刺。

這裡的難處在於，每一項新增看起來都站得住腳。產品當然應該處理那個邊緣案例；使用者當然會想要那個工作流程。在當下，這些都不像是範疇蔓延，因為用 agentic coding 打造每一項都只要花一點點力氣，但當你的產品不斷往原本邊界之外擴張時，你就有可能失去方向與動能。

解方是在開始打造之前，先寫下一份範疇定義，說明這個產品「做什麼」、「刻意不做什麼」，以及「哪些來自真實使用者的具體證據，才足以正當化新增某項東西」。這會把決策的關鍵點從「我們該不該做這個？」轉移到「是不是已經有一大批使用者告訴我們，少了這個他們就無法從產品中獲得價值？」

因經驗不足而不安全

挑戰：創辦人用 AI 工具急著把應用程式推上市，卻沒有先理解基本的資安原則，結果讓使用者暴露在本可避免的風險之中。

殘酷的真相是：agentic coding 工具產出的是「能運作」的程式碼，而不是「本質上安全」的程式碼。功能性程式碼很容易，因為這個功能不是能用就是不能用。但資安漏洞在被利用之前都是看不見的，這意味著沒有一個天然的回饋迴路，能在出問題時提醒一位首次創業的創辦人有哪裡不對勁。然而，把一個上線的 MVP 推給真實使用者，就代表真實的資料、真實的暴露面，以及一旦出事就會帶來的真實後果。

輕忽資安並非 AI 原生專案才有的新鮮事。各個時代的自力創業（bootstrapped）新創，常常把資安考量拖到打造後期才處理，有時甚至拖到正式上線前夕。在任何使用者接觸到你的應用程式或解決方案之前，先做一次資安審查，是把一個最小可行產品放到世界上時，負責任的最低門檻。

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 生成的程式碼做一次有用的初步資安審查，並協助找出常見的漏洞。把它納入推出前的流程，是個好習慣。然而，它無法取代專業的資安工具，在風險更高時也無法取代真人審查者——而那些把它當成替代品的創辦人，往往就是日後出現在資安事故報導裡的主角。

Claude Code Security 更進一步：它會掃描程式碼庫以找出資安 漏洞，並建議有針對性的修補方案供真人審查，揭露那些傳統方法可能漏掉的問題。

註：在本電子書出版之時，Claude Code Security 仍處於限定的 beta 釋出階段，因此在把它納入你的工作流程之前，請先確認目前的可用狀態。

• 練習：在部署給任何真實使用者之前，先把你的核心應用程式碼丟給 Claude，並給它一份明確的任務簡報：審查身分驗證與工作階段處理、API 回應中的資料暴露、輸入驗證與注入風險，以及含有已知漏洞的相依套件。認真看待每一項發現，評估它是否需要修正，並對任何涉及身分驗證、機密金鑰或資料處理的部分，安排真人審查。

在上線之前先建好你的衡量框架

那些把早期成長動能誤判為產品與市場契合的創辦人，通常正是那些等到上線之後才開始追蹤數據的人，而且他們挑選的指標是用來證明「哪裡做對了」，而不是用來揭露「哪裡出了問題」。解方是在第一位使用者出現之前，就先建立好你的衡量框架。

用 Claude 來定義：對你這個特定產品而言哪些指標重要、基準值是多少，以及數據中呈現什麼樣的型態才算是真正的產品與市場契合，而非討好人的雜訊。具體來說：在釋出你的 MVP 之前，先設定好你的留存基準、你的啟用（activation）準則，以及你的第 7 天與第 30 天目標。

接著，定義對你這個特定產品來說「偽陽性」長什麼樣子，例如：有註冊但沒啟用、有營收但沒留存，或只有初期的熱情卻沒有重複使用。當數據進來時，請 Claude 對你自己的成長動能提出對立論證：一個抱持懷疑的人會怎麼評論這些數字？

管理顧客探索與使用者回饋的後勤工作

一旦真實使用者進到產品裡，營運層面就會迅速擴張。Claude Cowork 能處理那些重要但繁瑣的工作，例如建立並維護使用者聯絡名單、執行外聯（outreach）序列、安排回饋會談、分類處理錯誤回報，以及追蹤迭代週期。在構想階段用來管理顧客探索後勤的那些 MCP 整合，在這裡同樣適用。

在蒐集回饋的迴路中，請保留一位真人，以便對使用者回饋做細緻入微的探究。舉例來說，當一位使用者說「這很棒，但我希望它也能……」時，這需要詮釋：這是核心需求還是錦上添花？這是這位顧客特有的，還是足以代表某個客群？真正的問題是缺少這項功能，還是上游的導入流程（onboarding）有什麼環節出了狀況？這些問題沒有任何工具回答得了。

• 練習：設定 Claude Cowork 來運行你 MVP 階段的回饋迴路：草擬寫給早期使用者名單的外聯訊息、安排回饋會談、為錯誤回報與功能需求設計結構化的收集流程，並寫出一份每週彙整，整理進來的內容。先由你自己審視這份彙整；之後，你可以請 Claude 分析這些資訊，找出任何你可能忽略的重點。

朝證據迭代，而不是朝「做完」迭代

MVP 階段的結束時機，是當你握有產品與市場契合的真實證據之時，無論產品感覺上有多「完成」。宣告你已經達成產品與市場契合、現在準備好從 MVP 階段邁向上線階段，終究是一場結合創辦人直覺與所蒐集證據的判斷工作。不過，這裡有一些有用的試金石：

• Sean Ellis 測試：問你的活躍使用者：「如果你再也不能使用這個產品，你會有什麼感覺？」如果超過 40% 的人回答「非常失望」，那就是一個有意義的 PMF 指標。

• 費力程度測試：在達到產品與市場契合之前，留存需要不斷地介入，包括頻繁的外聯、誘因、個別跟進，以及創辦人投入英雄般的精力，才能維持使用者的參與度。達到產品與市場契合之後，產品開始自己完成這些工作。當一切從「推著走」變成「拉著走」時，這種費力程度的轉變，是「某種真實的東西已經改變」最清楚的訊號之一。

歸根究柢，沒有任何單一的數據點能確認產品與市場契合，因為它是一種型態，必須在多個迭代週期中持續成立，你才能斬釘截鐵地宣告它成立。

當證據要求時，就轉向

萬一投入了這麼多工作之後，你就是怎麼也達不到產品與市場契合，該怎麼辦？你的結果無法印證你一開始設定的方向，這不是失敗，而是這套系統正在發揮作用：MVP 階段的設計初衷，就是要在你對錯誤答案過度投入之前，先把這個資訊揭露出來。

當數據不支持你目前的產品時，用 Claude 來釐清這些數據究竟在告訴你什麼。

• 探索其他的顧客客群。也許那些沒有轉換的使用者，從一開始就不是對的目標。通常對的受眾其實早就在你的數據裡，只是被低估了。

• 調整你產品的價值主張（value prop）。也許你抓對了受眾，但你的 MVP 就是無法引起使用者的共鳴。對導入流程、訊息傳達或核心功能的側重做出調整，有可能在不改動你已經打造出來的東西的前提下，解決這個問題。

對另一種可能性保持開放：這個落差也許深到需要一次更根本性的改變。

• 練習：如果你已經完成三個或更多的迭代週期，卻仍然沒有朝著產品與市場契合的基準值出現有意義的進展，那就在決定下一步之前，先用 Claude 跑一次診斷。把你的留存數據、使用者回饋，以及你最初的問題假設餵給它，並問它三個問題：

• 這份數據裡，是否有某個客群的反應與其他人不同？

• 「設計出的價值」與「實際體驗到的價值」之間的落差，是定位問題還是產品問題？

• 要讓目前的產品找到真正的 PMF，得有哪些條件成立？而根據你看到的情況，這個情境實際嗎？

讓這些答案來決定你是要調整、轉向，還是回到構想階段。

如果說 MVP 階段是要證明你的產品值得存在，那麼上線階段就是要證明你的事業值得成長。

上線階段目標

在上線階段，新創創辦人必須把早期的成長動能轉化為一套可重複、可持續的成長引擎。除了讓產品達到正式上線（production-ready）的水準之外，你還得同時鞏固底層基礎設施，並真正圍繞著產品打造出一家公司。

在構想階段與 MVP 階段，新創天生就會以創辦人為中心，因為你需要對全局有完整的掌握，並維持緊湊的回饋循環。但到了現在，那些仍想親手抓住每一條線的創辦人，反而會成為上線階段的瓶頸。目標不是要把自己從公司裡抽離，而是要建立起一套營運系統，把你的注意力釋放出來，去處理那些只有創辦人才能做的決策。

上線階段離開條件

上線階段的離開條件包含三個要素：

1. 成長是可重複的，而且由通路驅動。你不只是在留住使用者，更是透過特定通路、依循已經摸清楚的單位經濟（unit economics）可預測地獲取使用者：CAC、LTV 與回本週期（payback period），都是你心裡有數、而且能講得清楚的數字。

1. 產品能承受正式上線的工作負載。基礎設施已經鞏固，安全與法遵都已就緒，在真實的正式環境條件下（而不只是你測試過的那些條件）依然維持可靠。3. 營運可以在沒有創辦人瓶頸的情況下運轉。流程已經建立，自動化也已到位。你不再是那個親自處理客服、分流、衝刺規劃或報表的人。

上線階段挑戰

找到產品與市場的契合（product-market fit）是新創早期生命週期裡最難的問題。而現在，創辦人的挑戰變成了如何守住它。上線階段是一個分水嶺：即使是已經找到真實產品動能的公司，若是圍繞並支撐產品的組織跟不上腳步，仍可能在此分崩離析。以下是需要留意的幾種失敗模式。

技術債到期了

挑戰：當初為了速度與驗證而打造的 MVP 程式碼庫，跑起來足以證明產品行得通，但正式上線的流量、新增的功能與日益增長的複雜度，如今正一一暴露出當時抄的那些捷徑。

在 MVP 階段，累積一些技術債是為了換取開發速度而做的合理取捨。到了上線階段，這筆債開始產生利息，而且拖得越久不處理，修起來就越昂貴。

解法包含三步：做一次有系統的架構稽核，找出結構上的弱點；針對其中最嚴重的部分進行有的放矢的重構；並大幅擴充測試覆蓋率，好讓下一輪的功能開發不會把同樣的問題又帶回來。

創辦人變成了瓶頸

挑戰：在 MVP 階段，創辦人參與每一個環節是一項資產。到了上線階段，隨著客服量增加、產品決策層層堆疊、營運複雜度成倍上升，同樣的本能反而變成了約束。

從「親自做事」轉變為「設計出能做事的系統」，是新創生命週期裡最艱難的轉變之一。由於這個轉變很少有一個清楚的時間點，風險就在於你完全錯過它，繼續停留在打造者模式，眼睜睜看著組織在你身邊停滯。出現這種狀況的明顯徵兆包括：本來一小時就能拍板的決策，現在要拖一個禮拜你才騰得出手；客服需求堆積如山，因為只有你知道答案；還有那些只有在你親自記得時才會發生的營運任務。

對策是針對你親自在處理的每一件事做一次徹底的稽核，從最微不足道的任務，到風險最高的決策，藉此辨明哪些可以系統化、哪些可以授權出去，以及哪些確實仍然值得創辦人投入時間與心力。

安全與法遵不能再拖了

挑戰：在 MVP 階段，把安全與法遵措施維持得簡單一些是沒問題的；但現在有了真實的使用者、真實的資料，桌上甚至可能擺著企業合約，這就成了一項風險。

在 MVP 階段，只有寥寥幾位 beta 使用者、正式環境裡也沒有敏感資料，安全漏洞還只是理論上的風險。然而，一旦你的產品進入正式環境、有真實使用者倚賴它運作，這個「假設性」就會變成非常真實的暴險。此外，那些對原型不適用的法遵要求，在你開始處理客戶資料、處理付款，或是要打進受監管產業的那一刻，就絕對適用了。

對策是在進入正式規模「之前」（而不是之後）做一次有系統的安全與法遵審查，並把所有浮現出來的問題都當成必須完成的修補——而非建議——在下一波使用者湧入之前處理好。

在還沒準備好時就擴張

挑戰：新的市場與募資機會看起來都像是成長機會。但它們也可能正是產品與市場的契合走向死亡的地方。

你建立起來的初期動能是真實的，但它同時也只專屬於你的早期受眾。太早擴張到一個與你原本市場存在實質差異的市場，會引入新的使用者行為、新的法遵要求、新的付款基礎設施，以及一套你產品當初並未圍繞著設計的基準期待。一下子冒出太多新變數，你就會失去清楚解讀自己數據的能力。你還會冒著一個風險：在追逐一群全新且尚未獲得驗證的受眾時，忽略了你原本的使用者群。

Claude 如何協助上線階段的創辦人

三種型態的 Claude 在上線階段都會被充分運用，而且彼此相輔相成：每個工具產出的成果，都會成為另外兩個工具的輸入。這些成果會有機地疊加複利，創辦人把三個工具一起用，得到的會超過它們各自的總和。

這正是讓「超精實新創模式」在結構上得以成立的關鍵。當 Claude Code 打造產品、Claude Cowork 圍繞著產品打造公司，而 Claude 協助把這些產品知識與組織知識化為可運作的流程時，一個小團隊就能像一家規模大上數倍的公司那樣運轉。

在技術債複利滾大之前先處理掉

你的 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 來設計你的產品時程與工作週期該如何安排、一份規格（spec）在 Claude Code 動手做某項功能之前需要包含哪些內容、bug 回報如何分流與導向，以及你的每週指標報告要涵蓋哪些內容、又該如何發送。

流程設計完成後，用 Claude Cowork 來建立並運轉這個營運層：安排衝刺儀式、把進來的 bug 回報導向正確的地方、從你串接的資料來源彙整每週指標，並維持那個讓使用者訊號持續流入產品決策的回饋循環。

• 練習：請 Claude 設計一套輕量的產品管理作業系統：一個明確的衝刺節奏、一份最精簡的規格範本、一棵 bug 分流決策樹，以及一份從你實際資料來源拉取數據的每週指標簡報。接著設定 Claude Cowork 去實作並運轉這套系統裡會週期性發生的營運環節，例如排程、導向與報告彙整，讓它們不需要你就能按時發生。

進入規模化階段後，創辦人的角色會從「打造產品的人」重新轉向「對外的經營者」。產品依然是核心，但你個人的日常工作會愈來愈聚焦在公司本身。你的注意力必須擴展到規模化階段才會出現的新活動，例如分析師簡報與 IPO 路演（roadshow）；與此同時，你還要努力維持那套精實、以 AI 為核心的結構性優勢。

規模化階段目標

擴展技術基礎設施的工作仍會持續進行，而此時還加進了另一項工作：把組織本身擴展起來，並讓它成熟為一門真正的生意。

到了規模化階段，你要面對的是從數千名使用者成長到數百萬名，從單一市場拓展到多個市場。在先前的每個階段，成長都是你可以「憑感覺摸索」出來的——靠著貼近使用者、依據緊密回饋迴圈的資料調整方向，再加上一點健康的創辦人直覺。但現在，目標變成了打造由成熟組織營運所支撐的系統化成長。

對一家 AI 原生新創而言，你的目標應該是透過累積出來的「深度」來建立一條難以攻破的護城河——這份深度來自你內建於產品中的專業知識、產品與使用者所仰賴的其他工具與平台之間的整合深度，以及專屬的系統資料與工作流程。那些一路以來都朝著一致方向、在一致基礎設施上持續打造的創辦人，如今手上握有的，是真正難以被複製的東西。

到了這個階段，公開市場的投資人、分析師、監管機關、企業採購團隊與潛在收購方，都會施加更大的壓力——伴隨而來的還有更深的質疑——因為現在的賭注更高了。你的產品與組織必須經得起外部檢視：不只是你所打造出來的能力，還包括圍繞著它的治理、合規態勢、財務控管，以及策略敘事。

規模化階段的離開條件

規模化階段的離開條件，不再是單一的里程碑，而是一個「門檻事件」：即使創辦人愈來愈不再直接掌管日常營運，公司依然能夠永續經營。你已經展現了系統化的成長；建立了能滿足最嚴苛外部審查者的組織治理與合規基礎設施；並且對這個問題有了紮實的答案——「如果有一家資金雄厚的現有業者今天就複製了你的產品，你的使用者還會留下來嗎？」

實務上，這個門檻通常會以三種形式之一呈現：在不再需要外部資金的規模下達到可永續的獲利、具備 IPO 上市的準備度，或是被收購。這三種形式都要求：你的成長是系統化且可稽核的、你的產品護城河經得起檢視，而你的組織在營運上已經成熟且能永續運作。

當這些都成立時，該說聲恭喜了：你的新創已經從一場「賭注」，蛻變成一門真正的「生意」。

規模化階段的挑戰

把營運層交棒出去

挑戰：規模化階段的營運系統必須穩定、可永續地運作，而且不需要有人時時盯著。對一位從第一天起就事必躬親的創辦人來說，這個轉變既是結構上的挑戰，更是一場心理上的挑戰。

你在上線階段的工作是「打造這些系統」；到了規模化階段，工作會變成：（1）讓這些系統成熟到完全值得信賴，以及（2）然後真的去信任它們。

這件事比聽起來更難。即使你是一位很懂得授權的創辦人，哪些該交出去、哪些該留在自己手上，往往也不是那麼一目了然。交得太多、太快——尤其是交給 AI 自動化系統——關鍵決策就會在缺少只有創辦人才能提供的關鍵脈絡下被做出。但握得太久，你又可能變成瓶頸。

這裡最根本的挑戰在於：辨識出那些只存在於創辦人腦袋裡、或藏在沒有文件記錄的工作流程中的「組織知識」，再把它編寫（codify）成有文件、可稽核、可移交的系統。

擴展技術營運

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

在新創的前三個階段，技術挑戰都圍繞著程式碼庫打轉：在不累積技術債的前提下打造出對的解決方案，接著為真實使用者強化安全性與合規性。到了規模化階段，挑戰轉移到「程式碼庫周邊的一切」：建立那些能彰顯成熟度的支援基礎設施、文件，以及可靠度保證。

簽署多年期合約的大型客戶與機構型買家，會在簽約前要求看到這些東西，而且一旦簽了約，也會拿這些標準來要求你。不過，一路帶你走到這裡的同一套 AI 基礎設施，能幫你建立具備明確回應時效的專責支援機制，以及一份新客戶的工程團隊真的用得上的文件。

擴展組織職能

挑戰：一家規模化階段的公司，通常都需要諸如招募、薪資發放、會計與法務營運之類的組織基礎設施，無論實際上是由多少人在運作這家公司。在上線階段，把營運系統化指的是把那些吃掉創辦人注意力的工作流程自動化。而到了規模化階段，新創此時需要長出一整套更廣、在某些面向上也更舉足輕重的營運職能，例如財務報表、合規監控、合約管理與客戶支援等等，不勝枚舉。

建立 GTM 職能

挑戰：有機成長有其天花板，而大多數規模化階段的創辦人，是在「從來沒有真正建立過進入市場職能」之前就先撞上了它。

構想、MVP 與上線階段的成長，往往源自創辦人親自帶頭銷售——從一篇時機抓得恰到好處的 Product Hunt 貼文，到與早期客戶之間的私人關係。但這種有機成長只能撐到某個程度，而大多數新創都會在規模化階段碰到這道極限。徵兆包括：使用者成長曲線趨於平緩、顧客取得成本上升，以及一條只有在創辦人親自介入時才會推進的銷售管線（pipeline）。

規模化階段的成長，需要建立一套專責的成長引擎，去觸及產品更新、更廣的受眾。然而，大多數新創創辦人大概從來沒有真正做過行銷、銷售與分析師關係（analyst relations）這類事情。一套像樣的 GTM 打法，不只需要建立新的系統與流程，還需要打造一種品牌語調與敘事方式，來決定你想怎麼談論自己的產品。因為在新創生命週期走到這個階段時，你會需要這套東西，才能不只觸及一個個新的個別使用者，更能觸及一整群目標受眾，例如投資人與企業買家。

所幸，GTM 職能不必龐大也能發揮成效，而當初打造產品的同一套 AI 基礎設施，也能幫你把產品推向市場的工作給「啟動」起來。

Claude 能如何協助規模化階段的創辦人

在新創的早期階段，Claude 被當成產品本身的基礎設施來使用：驗證構想的研究夥伴、設計並打造原型的工程團隊，以及讓「單人創辦的新創」得以成立的 AI 營運層。走到規模化階段的 AI 原生新創創辦人，現在可以用 Claude、Claude Code 與 Claude Cowork，沿用當初打造產品的同一套方式繼續擴展。

把日常任務交棒給 Claude Cowork

進入規模化階段時，要先清醒地看清楚：現在你最需要把時間與注意力投入在哪裡——這對從沒經營過企業的首次創業者來說，可能是一大挑戰。Claude 可以幫上忙，協助你整理出「在這個階段只有你該做」的事項清單，可能包括產品敘事的決策、董事會關係、企業大單，以及創辦人對創辦人之間的對話。任何不在這份清單上的事，都是可以授權出去、或交由 Claude Cowork 自動化的候選對象。

• 練習：用 Claude 為你目前的營運層產出一張瓶頸地圖（bottleneck map）：把目前所有經過你的工作流程、決策與簽核全部列出來。接著，請 Claude 推演當你一整週都無法處理事情時，每一項各會發生什麼狀況。那些會卡住停擺的工作流程，就是你仍然事必躬親到足以拖累進度的地方。

這些結果，和你先前與 Claude 一起整理出來的創辦人優先事項與職責清單，又對應得上嗎？

接著，就該壓力測試一下：你已經建好的那些系統，是否真的準備好隨著事業成長而一起擴展。

• 練習：用 Claude 把你目前的工作流程畫出來，然後問它，當你一整週都無法處理事情時，每一項各會怎樣。那些會卡住停擺的工作流程，就是其交棒標準、升級通報路徑（escalation path）或例外處理仍需收緊的地方。Claude 可以幫你分析這些失效點並建議合適的修正方式，讓你能視需要更新或替換 Claude Cowork 的自動化設定。

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

隨著你擴大規模，買家需要安心相信：你的產品與組織值得被當成長期基礎設施來信賴。技術工作一如既往仍在程式碼庫內部進行，但現在也多了一批「程式碼庫周邊」的技術工作要處理。第一步，是把組織知識轉化成一套可以隨規模擴展的系統。用 Claude 來撰寫並維護企業採購預期會看到的那些書面基礎設施，包括產品文件、支援手冊（playbook）與 SLA（服務水準協議）。

與此同時，指派 Claude Code 依照企業合約所要求的特定可靠度與安全標準來稽核並強化程式碼庫，並建立出當初以 Discord 為基礎的社群支援從來不必提供的那套技術支援基礎設施：日誌記錄、監控、事件回應工具，以及讓 SLA 真正具有可執行性的可觀測性（observability）層。

接著，Claude Cowork 就來實際運作企業支援的營運層本身：工單派發、升級通報流程、由產品變更觸發的文件更新、續約追蹤，以及企業客戶成功（customer success）所仰賴的各種定期回報節奏。這三者合起來，能讓一支小團隊擁有遠比自身規模更大的組織才有的支援態勢——而這，正是簽下多年期企業合約時，你必須向對方展現的東西。

• 練習：挑出你最難搞定的三位潛在客戶，或是鎖定三位你最想簽下的理想客戶。請 Claude 產出一份落差分析（gap analysis）：在這幾個客戶簽下多年期合約之前，他們的企業採購團隊預期會看到哪些文件、SLA 與支援基礎設施，而你目前又在哪些地方還達不到？再運用這份產出，把橫跨 Claude Code 與 Claude Cowork 的技術與文件工作排出先後順序。

建立一套真正的 GTM 職能

創辦人的衝勁帶你走到了這裡，但要擴展你的新創，需要的是建立並落實一套真正的進入市場策略。AI 能幫你打造、再運作這整套 GTM 引擎。

Claude 能協助你從零開始建立 GTM 的基礎資源：市場區隔（market segmentation）、訊息架構（messaging architecture）、分析師關係策略、銷售手冊，以及一旦你開始和公開市場投資人、企業買家與華爾街分析師打交道後就變得重要的、面向投資人的指標敘事。這幾種受眾各有自己的一套語彙，也各自用自己的標準來評估你；Claude 的工作，就是把你產品的價值主張（value prop），翻譯成對每一個受眾區隔都切題的產品行銷做法。

接下來，Claude Cowork 可以成為你的戰術執行層：內容產出管線、外部開發（outbound）序列、分析師簡報的後勤安排、新聞室與公關發布節奏、CRM 資料整潔維護、銷售管線回報，以及把 GTM 策略轉化為真正商業動能的許多週期性循環。

當 GTM 打法需要產品行銷基礎設施時——互動式示範環境、整合文件、沙箱租戶（sandbox tenant）、API 參考文件、技術一頁式說明（one-pager）——Claude Code 都能幫你打造出來。買家會期待從技術層面評估你的產品，而到了規模化階段，光靠一段 Loom 影片和一份銷售簡報已經不夠看了。這同樣也是那種讓你的 GTM 打法能夠「非同步」運作的基礎設施：一個打造精良的示範環境，能在你還在開董事會時就替你成交。

把領域專業與組織知識轉化為 AI 的脈絡

許多極度精實的新創創辦人，正在為自己親身經歷、或在某個特定產業第一手觀察到的真實世界問題，打造高度專一的應用程式或工具。如今的代理型 AI（agentic AI）讓那些從沒寫過一行程式碼的創辦人，也能運用自己的領域專業，打造出能解決複雜問題的產品。Claude、Claude Code 與 Claude Cowork，各自在「把創辦人的知識轉化為會複利累積的產品專一性」這件事上扮演一部分角色。

用 Claude 來捕捉、整理並打磨創辦人的知識，等於把領域專業放進了一個產品能夠觸及的地方。透過延展的對話、專案與記憶（memory），創辦人可以把自己所知的一切都分享出來——產業行話、法規上的陷阱、邊緣案例（edge case）、各種挫折，以及為什麼那些看似顯而易見的解法在這個問題上行不通——全部彙整成一個結構化、可搜尋的脈絡。接著，Skills 能把反覆出現的工作流程（例如「我怎麼審查一份商業租約」、「我怎麼分流一份病患初診表單」）編寫成可重複使用的常規程序，讓 Claude 每一次都以同樣的方式執行。經過數個月的累積，這會變成一塊專屬的知識基底，是任何通用型 AI 都比不上的。

借助 Claude 把你的領域知識外部化，對於將產業專屬的邊緣案例編進你的產品而言，會變得無比珍貴：舉例來說，一個通用型 AI 醫療帳務工具，碰到 340B 藥品計畫的請款就會出錯，但你的工具卻針對它有專門的處理邏輯。Claude Code 能幫你把你所在領域中其他專業人士常遇到的挫折，翻譯成驗證邏輯、提示詞的優化，或是與某個你的競爭對手聽都沒聽過的利基產業系統做 MCP 整合。如此一來，你的應用程式或工具，其深度與廣度都會持續以一種競爭對手根本無從複製的方式複利累積。

• 練習：找出一個你所屬垂直領域中、通用型競爭對手鐵定會搞錯的邊緣案例。和 Claude Code 一起，根據一個你真的遇過的情境，為它打造一個專屬的測試案例（不是單元測試）。每當類似的邊緣案例浮現，就把它加進去。你的測試套件，會逐漸變成一張描繪你護城河的地圖。

把累積的使用者資料複利成一項難以攻破的優勢

當使用者與你的產品互動時，他們會產生行為訊號（也就是他們接受了哪些輸出、又拒絕了哪些），而這些訊號會回過頭來指引產品藍圖。隨著時間推移，你會逐漸摸清自家這群特定使用者的具體模式、偏好與邊緣案例。這就是我們所說的「複利價值」：每一次改進都讓產品更好用，進而帶動更多使用，創造出更多回饋，又再推動更多改進。

這些資料被「時間鎖死」、具有高度的脈絡專一性，是任何模仿者都無法重新製造出來的：你根本買不到「成千上萬名使用者在你產品內部反覆打磨工作流程」所留下的那份行為指紋。

Claude 能幫你稽核你所蒐集到的各種使用者互動資料、找出其中訊號最強的行為模式，並設計出能把「持續使用」轉化為「系統化模型改進」的回饋迴圈。

• 練習：餵給 Claude 一份你產品互動資料的摘要：你一直在蒐集什麼、蒐集多久了，以及你對使用者隨時間如何使用你產品的了解。請它找出這份資料中訊號最強的三種行為模式，並為每一種設計一條能把它轉化為系統化模型改進的回饋迴圈。接著請它幫你草擬一份一頁式的護城河敘事，用來指引產品行銷：講述你的資料飛輪（data flywheel）是怎麼運作的、它已經轉了多久，以及為什麼一個今天才起步、資源充沛的競爭對手，也無法在兩年內複製出它。

打造工作流程鎖定

複利累積的資料網路效應讓你的產品更難被複製，而使用者的工作流程鎖定（workflow lock-in）則讓使用者更難離開你的產品。使用者把你的產品放進日常營運裡運作得愈久，它就愈深地嵌進他們實際的工作方式裡。他們在它之上建了自動化、訓練同仁去使用它，還把它和自己的資料來源與其他工具串接起來。他們開發出的提示詞、打磨過的工作流程、標準化的輸出，全都是圍繞著你的產品「做什麼、怎麼做」而塑造出來的。到了這個地步，更換產品就從一個「產品決策」，變成了一個全面規模的「營運專案」。

打造工作流程鎖定的第一步，是請 Claude 依照整合深度（integration depth）為你目前的客戶群繪製一張地圖。針對每一個客戶區隔，找出他們在你產品之上建立了哪些工作流程、又仰賴哪些整合。這能讓你看清你的產品在哪裡「黏住了」客戶，以及它還需要往哪裡紮得更深。

你提供的整合愈多，客戶能用來建構「仰賴你產品的工作流程」的接觸面就愈大。Claude Code 能幫你迅速架設起與目標使用者所仰賴的資料管線、專案管理工具及其他系統之間的原生整合。Claude Code 還能打造 API、webhook 與 SDK，讓客戶不只是「使用」你的產品，更能在它「之上」進行打造——這是最深一層的鎖定。

• 練習：請 Claude 幫你為前十大客戶建立一份工作流程整合稽核。針對每一位客戶，記錄下他們建立的自動化、所仰賴的整合、貫穿你產品運作的團隊工作流程，以及你對他們轉換成本的估計。接著請 Claude 找出這群客戶之間的共同模式：對你這個特定產品而言，哪幾類整合會帶來最深的鎖定，以及對於目前還停留在表層的客戶，你可以打造或開放什麼來加深整合。

在 AI 的領域裡，創辦人的工作其實沒變：找到一個真實的問題，打造出能解決它的東西，再把它擴大成一家舉足輕重的公司。變的是抵達終點的那條路。橫跨構想、MVP、上線、規模化這四個階段，AI 把過去要花好幾季的事，壓縮到只要幾週。

過去動輒得花好幾個月的驗證循環，如今一個下午就能跑完。要做出一個能動的原型，不再需要一位懂對的技術堆疊的共同創辦人；你需要的，是一個清晰的問題，再加上幾段與 coding agent 專注協作的時間。上線前的準備，也從那種臨上線才手忙腳亂的衝刺，變成一條持續推進的工作流。而到了規模化的階段，過去逼著早期人手淪為救火隊的營運重擔，如今愈來愈能交給 AI 接手，讓你的團隊得以把注意力，留給那些終將構成你護城河的判斷。

如今真正的瓶頸，已經不是你能打造出什麼，而是你選擇去打造什麼。