快速解答： 準備階段（Preparation Phase）是把已核准的設計，轉化成一份團隊（或你自己搭配 Claude）真正能開發的計畫。它包含三件事：定義以價值傳遞為核心的里程碑、支援工程團隊的技術準備、主持一場清楚交代脈絡的專案啟動會議。跳過任何一項，你都會在開發途中付出比現在高好幾倍的代價。

文章同步發表在 我們的部落格

你是不是也曾經在設計核准之後，立刻打開 Claude Code，開始叫它生成程式碼？

先停一下。

前面幾篇，我們走過了功能機會驗證、用戶價值精煉、商業價值精煉、功能設計的發散與收斂、設計核准。每一步，你都在確認「這個功能值不值得做」「該怎麼做」。但確認完之後，還有一個環節，多數新手——不管是團隊裡的 PM，還是自己一個人用 Claude 打造產品的獨立開發者——會直接跳過：準備。

準備階段做的事，不是想點子，也不是寫程式。它是把前面所有的驗證成果，整理成一份清楚的作戰計畫——定義里程碑、確認技術可行性、把所有人（或者只有你和 Claude）帶上同一條起跑線。跳過這一步，你等於是帶著一份漂亮的設計稿，直接衝進一場沒有地圖的戰鬥。

這篇文章，會帶你走完準備階段的三個關鍵活動，並且看看 Claude AI 能在哪些地方幫上忙。

為什麼準備階段常常被跳過，卻決定了專案成敗？

因為它看起來像行政作業，不像創造性工作。

寫程式很有成就感——你打字，畫面就動起來。但定義里程碑、跟工程對齊、主持啟動會議？這些事聽起來乾巴巴的，很容易讓人想跳過，直接進入「真正的」開發。

問題是，跳過準備階段的團隊，通常會撞上三種代價：範疇蔓延、開發途中的返工、利害關係人認知不一致。花時間把這些工作做好，反而能省下後面好幾週的重工時間。

如果你是自己一個人用 Claude 打造產品，這件事更重要，而不是更不重要。沒有團隊幫你把關進度、沒有工程主管幫你抓技術風險——你必須自己扮演那個「先規劃、再動工」的角色。

什麼是里程碑？為什麼多數新手把它定義錯了？

里程碑，是你把一個大專案拆解成的一連串小階段。

聽起來很直覺，對吧？但定義好的里程碑，其實是整個準備階段裡最容易做錯的一件事。

多數新手 PM 沒有經過反覆試錯，很難憑直覺抓到定義里程碑的訣竅。結果，他們幾乎都會掉進同一個陷阱：只依照技術依賴關係排序里程碑，完全忽略了另一個同樣重要的目標——盡快把價值交付給用戶。

Anand 在 Zynga 擔任 PM 時，見證過這個陷阱的代價。當時團隊想改善多人遊戲《Words With Friends》的留存率，做法是用 Elo 評分系統，把技能相近的玩家配對在一起。這套系統需要先蒐集大量數據，才能準確評分。

團隊原本的計畫，是等所有現有玩家都有了 Elo 分數，才推出配對功能——這代表要等上好幾週，功能才能上線。後來團隊重新設計了里程碑：先用有限數據做出粗略的估計分數，讓配對功能提早上線，留存率立刻獲得改善；等蒐集到足夠數據，再推出完全依賴 Elo 評分的版本。

同一個功能，兩種里程碑排法，結果天差地遠。差別就在於，第二種排法同時考慮了依賴關係，也考慮了價值交付的速度。

怎麼用「價值傳遞鏈」定義里程碑：發現性與可用性

好的里程碑，會逐一驗證價值傳遞鏈上的每一個環節。

用戶要能從一個功能得到價值，需要三件事同時成立：他們找得到這個功能（發現性）、他們用得懂這個功能（可用性）、這個功能真的解決了他們的問題（效用）。 少一個環節，整條鏈就斷了，用戶拿不到價值，公司也拿不到成果。

先看發現性。如果用戶找不到你的功能，一切都白搭。

Dropbox 的文件掃描功能一開始藏在畫面角落的三點選單裡，用戶幾乎找不到。後來 Dropbox 把它移到「加號」按鈕彈出的動作清單，並且在檔案頁面加上明顯的按鈕——功能本身完全沒變，使用率卻明顯上升。問題從來不是功能不好，是沒人找得到它。

但發現性不是「越明顯越好」這麼簡單。有些功能只鎖定部分用戶——這時候你反而要小心，別讓功能太顯眼，也別讓它太隱蔽。Gmail 的鍵盤快捷鍵功能，藏在設定頁面的分頁裡，只有真正需要它的高效用戶會主動找到，這是刻意的設計。相反地，LinkedIn 的「Open to Work」徽章，用自我選擇的方式——在 Jobs 頁面明顯標示開關——讓真正想找工作的用戶主動打開它，而不是把它硬塞給所有人。

還有一種被忽略的發現性風險：現在能發現，不代表未來也能發現。 人資平台 Gusto 早期用動態消息通知現有用戶新功能，但六個月後才加入的新用戶，完全看不到過去的公告。Gusto 後來把新功能放進頂層導覽列，變成一個永久存在的入口，才解決了這個問題。

再看可用性。用戶找到功能了，但如果用起來太費力，同樣拿不到價值。

心理健康新創 Path 在設計預約排程功能時，團隊對「該優先參考醫生的行事曆，還是病患的行事曆」爭論不休。與其僵持不下，團隊定義了一個里程碑：先做出一個可運作的原型，交給兩位客服代表實際試用。測試結果證明，以醫生行事曆為主的做法是對的——爭議一次解決。

可用性風險也常常藏在使用者旅程的細節裡。Airbnb 要求新用戶上傳身分證件時，加入了「用網路攝影機直接拍照」的選項，並且說明隱私保護措施，降低了這個步驟帶來的實體與心理阻力。Gusto 的薪資設定流程，則是在每個步驟底下加上「為什麼需要這個」「準備好這些資料」「需要協助嗎」三段簡短說明，大幅降低了用戶的認知負擔。

怎麼用效用與依賴關係，定義最後一段里程碑？

效用，是價值傳遞鏈的最後一環：這個功能，到底有沒有真正解決用戶的問題？

Dropbox 曾經推出一個叫 Dropbox Badge 的功能，讓多人協作編輯同一份檔案的用戶，能看到「有人正在編輯這份檔案」的提示。但這個功能沒有解決真正的問題——它只讓用戶知道有人在編輯，卻沒辦法讓多人真正同時協作同一個版本。效用這一環，斷了。

要測試效用，你有兩個槓桿可以拉：人口涵蓋範圍和功能完整度。

社群語音 App Clubhouse 選擇先在 iOS 上線，蒐集足夠數據後，再決定怎麼開發 Android 版本——這是用人口涵蓋範圍測試效用的例子。Dropbox Business 則有一個叫 Early Access 的計畫，讓自願的用戶提早拿到新功能，換取回饋。

功能完整度的例子更貼近開發現場。Path 的排程功能，不是一次做完才測試，而是先推出「自動化行事曆」這個小元件，驗證它真的減少了客服代表對照試算表的麻煩，再推出「自動建立病患記錄」的元件，最後才完成整個預約與通知流程——每一步都在蒐集數據、降低風險。

同樣地，Dropbox for Business 有一個「遠端刪除裝置上的 Dropbox」功能，只對已經取得裝置管理權限的用戶有效——大約佔 90%。與其等到能涵蓋所有邊緣案例才上線，Dropbox 選擇先服務這 90% 的「happy path」用戶，再回頭處理剩下的邊緣情況。

至於商業效用，別忘了觀察第二順位指標。語言學習 App Duolingo 曾經測試讓用戶跳過練習題、直接建立帳號——這確實提升了帳號創建數，但也可能拉低下游的 30 天活躍用戶數，因為部分低意圖用戶被提早放進了漏斗。改善一個指標，可能同時傷害另一個指標。定義里程碑時，把這一點放在心上。

最後,別忘了依賴關係。你可以透過三個管道找出依賴：跟工程夥伴討論、回顧設計審查的結論、靠自己的判斷補齊缺口。常見的依賴類型有五種——輸入輸出（設計稿要先做完，前端才能開工）、整合（資料架構和模型可以並行開發，但最後要合併）、第三方限制（像 Credit Karma 得配合 IRS 的報稅測試時程）、資源（唯一懂郵件系統的工程師正在忙別的專案）、重要日期（假期、季度回顧會議都會壓縮可用產能）。

怎麼支援工程準備工作，而不是當個甩手掌櫃？

里程碑定義好之後，接下來的技術規格、工時估算、人力配置，主要是工程團隊的工作。但這不代表你可以完全放手。

不是每個功能都需要技術規格。判斷標準很簡單：如果要做出來的東西很明確，但實現的技術路徑有複雜性需要事先釐清，這時候技術規格才有價值。 一個設定頁面的深色模式切換按鈕，通常不需要；但像 Path 這種建立在第三方電子病歷系統上的產品，要新增一個「修改帳號 email」的功能，看似簡單，背後牽涉到「哪個系統該存新地址、怎麼同步到其他系統」等問題——這時候技術規格就非常關鍵。

工時估算階段，你該做的是回頭檢查產品需求裡，哪些是真正必要的，哪些可以砍。想像你要把一個功能在地化成多國語言，結果工程發現某個語言需要多出 30% 的版面空間才能容納文字。這時候，該不該堅持包含這個語言，答案不在工程手上，在你當初驗證過的機會評估裡——如果這個市場正是你的策略重點，多花的工程成本就值得；如果不是，這筆額外投入很可能是浪費。

人力配置階段，你的責任是主動提供背景，說明這個專案的相對優先順序和複雜度，讓工程做出更好的配置決定——而不是等結果出來才發表意見。

如果你是獨立開發者，這一整段完全可以套用在你跟 Claude Code 的合作上。 動工前，先問問自己：這個功能的實現路徑夠明確嗎？有沒有先讓 Claude 幫你梳理一份簡單的技術方案？哪些需求是核心、哪些是可以先砍掉的「德文版面問題」？把這些問題想清楚，再打開對話框，會比邊寫邊想有效率得多。

怎麼用 Claude AI 主持一場真正有用的專案啟動會議？

專案準備好了，最後一步是啟動。這是整個準備階段最容易被隨便帶過，卻代價最高的環節。

如果把產品開發的生命週期想成一場接力賽，專案啟動就是 PM 和設計師，把接力棒正式交到工程手上的那一刻。核心參與者應該包括你自己、設計師、被配置到專案的工程師；如果專案會影響其他團隊——例如銷售、行銷、客服——也該邀請對方指派一位聯絡窗口參加。

一場好的啟動會議，通常走過五個階段：分享議程與目標、總結機會、介紹設計說明與原型、標出風險、討論角色分工與下一步。這五個階段裡，最容易被輕忽、卻最該花時間講清楚的，是機會總結。 把策略契合、用戶價值、商業價值講清楚，能讓工程理解「為什麼」和「為誰而做」——理解了背後的邏輯，他們才能在你沒想到的地方，做出聰明的判斷和取捨。

這正是 Claude AI 能派上用場的地方。 把你整理過的機會摘要、設計描述、原型連結、迭代收斂過程中的取捨紀錄丟給 Claude，請它幫你草擬一份完整的啟動簡報大綱、甚至協助生成 PRD 文件和實作指引，把散落各處的準備成果，收攏成一份清楚的溝通素材。這能把原本要花上大半天整理的工作，壓縮到一小時內完成。

但別忘了：簡報稿是 Claude 給你的草稿，不是最終答案。 真正決定哪個風險該優先標出來、哪個取捨值得花時間解釋——這些判斷，永遠得靠你自己。

準備做得紮實，開發才跑得快

走完這一輪，你應該已經看出準備階段真正的邏輯：定義以價值傳遞為核心的里程碑、當工程準備工作的啟用者而不是旁觀者、用一場清楚的啟動會議把接力棒交出去。

三件事做到位，你的專案就不再是一場賭博，而是一份有憑有據、團隊（或你和 Claude）都理解「為什麼要做」的計畫。Claude AI 能幫你加速整理、草擬文件、彙整風險清單——但真正決定哪個里程碑該優先、哪個技術取捨值得堅持、哪場啟動會議該講清楚什麼——這些判斷，永遠是你的工作。

下次設計一核准完，先別急著打開 Claude Code。先問自己：我的里程碑，兼顧了依賴關係和價值交付嗎？我跟工程準備好對齊了嗎？我的啟動會議，能讓所有人（包括未來的你自己）理解這個專案的全貌嗎？

準備階段不是走過場的行政工作。它是讓開發階段真正跑得快的那份地圖。

常見問題

準備階段通常要花多久時間？
視專案規模而定。小型功能，定義里程碑加上簡短的工程對齊，可能一到兩天內就能完成；規模較大或牽涉多個依賴關係的專案，可能需要一到兩週，涵蓋更完整的技術規格討論與跨團隊協調。

我是自己一個人用 Claude 打造產品，也需要走完整個準備階段嗎？
需要，只是形式不同。你同時扮演 PM、設計師、工程師三個角色，定義里程碑能幫你避免半途返工；跟 Claude Code 討論技術方案，等於是你自己版本的「工程準備」；就算沒有團隊，寫一份簡短的啟動筆記,也能幫你在真正動手前理清思路。

跳過里程碑規劃，直接開始開發，最大的風險是什麼？
最大的風險是只依照技術依賴排序工作，卻忽略了盡快交付用戶價值——就像 Zynga 案例裡,原本的計畫會讓功能延遲好幾週才上線。你也可能在開發到一半，才發現功能的發現性或可用性有問題，這時候修正的成本，遠比在里程碑規劃階段發現要高得多。

什麼情況下,一個功能需要技術規格文件?
當你要做出來的東西很明確，但實現的技術路徑存在複雜性，需要工程團隊事先釐清時，技術規格才有價值。像深色模式這種需求單純的功能通常不需要；但涉及多系統資料同步的功能，技術規格能幫工程提早排除疑慮。

Claude AI 在準備階段，最能幫上什麼忙？
它最擅長把分散的驗證與設計成果，整理成結構化的文件——像是啟動簡報大綱、PRD 更新內容、風險清單。但判斷哪個里程碑該優先、哪個技術取捨值得堅持，仍然需要你對用戶和業務脈絡的理解。