AI 讓寫程式越來越便宜，但真正值錢的是產品判斷力

- 從兩張需求地圖走到成果驗證，判斷哪些功能值得交給 AI 開發。 -

AI Coding、Vibe Coding 讓更多人做得出網站、系統，甚至一個完整的 SaaS。當開發速度愈來愈快，真正該問的問題也跟著改變：我們做出來的功能，真的有人需要嗎？

我最近讀到一篇文章，標題是〈功能變便宜了，判斷力變貴了：AI 時代的兩張地圖〉。文中用一個產品團隊的情境開場：導入 AI Coding Agent 後，團隊每個 Sprint 能完成的功能增加了，轉換率卻沒有提升，客訴反而增加。有人因此說：「我們好像只是把『做錯的東西』做得更快而已。」

這是原作者設定的情境，不是實際研究數據；但它提醒了我，做得出來，不代表有人需要。

AI 降低了實作門檻，沒有替我們確認需求

以前做網站或開發系統，常見的難題是「做不出來」。現在有了 Codex、Claude Code 等 AI Coding 工具，即使不是專業工程師，也能更快做出過去需要整個團隊才能完成的功能。

但技術門檻降低，不會自動讓產品更符合需求。若只是把想像中的功能快速做完，可能只是更快地解決一個尚未證實的問題。

先用兩張地圖看清楚問題與解法

Customer Journey Map：找出使用者在哪裡卡住

Customer Journey Map（顧客旅程地圖）從使用者的角度，整理他接觸產品、評估、購買、使用到後續服務的過程。它協助團隊找到使用者在哪一段遇到疑問或阻礙，而不是一開始就列出想開發的功能。

例如，有人看到 AI 課程介紹後進入網站，可能想知道課程適不適合初學者、實體課與錄播課有什麼差別、購買後能觀看多久，或臨時無法上課時該怎麼辦。這些疑問不一定需要新功能；清楚的文案、簡化的購買流程或一段 FAQ，也可能更直接地解決問題。

User Story Map：把使用者目標拆成可交付的步驟

User Story Map（使用者故事地圖）則從使用者想完成的目標出發，把過程拆成活動、步驟與支援功能，接著安排 MVP 先做哪些、哪些留待後續。

以報名課程為例，學員可能需要瀏覽課程、比較方案、完成付款、收到通知，最後取得上課權限。整理出這些步驟後，團隊才能討論第一版要支援哪些必要流程。

簡單來說，Customer Journey Map 協助我們發現問題，User Story Map 協助我們規劃解法，AI 則可以協助實作。

AI 能整理需求，也會把假設寫得像事實

假設你告訴 Codex：「我要開發線上課程平台，學員應該很在意學習證書，請幫我規劃完整的證書系統。」AI 可能很快列出自動發證、QR Code 驗證、證書下載、公開查詢與管理後台，而且規格看起來完整又合理。

但在投入開發前，仍要確認學員是否真的需要證書。如果他們更在意課程內容是否實用、影片能不能重複觀看，那套證書系統可能只是解決了我們想像中的問題。

AI 可以協助整理需求，卻不能代替真實資料。沒有訪談、客服紀錄、行為數據或其他證據支持的需求分析，仍然只是待驗證的假設。使用者遇到問題，也不代表一定要增加功能。

從 Story Map 再往下寫成開發規格

User Story Map 能說明使用者想完成什麼，卻未必包含 AI Coding Agent 實作所需的細節。

例如，「身為學員，我希望購買課程後可以觀看教學影片」還需要回答：影片放在哪裡？付款失敗怎麼處理？觀看權限如何判斷？課程到期後會發生什麼事？直播回放尚未發布時要顯示什麼？

這些細節需要進一步整理成開發規格（Spec）、業務規則與驗收標準。可以先用 Journey Map 和 Story Map 理清方向，再讓 AI 協助產出詳細規格，而不是直接開始寫程式。也可以把產品規劃整理在 docs/product/，並透過 AGENTS.md 指引 Codex 閱讀相關背景，讓它理解功能的目的與前後流程。

再加一張成果地圖，確認功能是否真的有用

我還會多問一個問題：功能完成後，我們怎麼知道它改善了使用者的處境？我把這個思考方式稱為 Outcome Map（成果地圖）；這是本文用來描述成果導向規劃的方式，不是某套特定的標準工具。

假設學員常因為看不懂購買方案而猶豫，團隊決定把三種方案的權益說明得更清楚。完成方案比較頁只是交付了功能，接著還要觀察學員是否更容易選擇、付款完成率是否有改善、詢問方案差異的客服訊息是否減少。這些是要驗證的結果，不是預先保證會發生的成效。

根據實際觀察再決定下一個版本要改什麼，才不會落入「想到功能、交給 AI、開發完成、再想到新功能」的循環，讓網站愈做愈大，卻說不清楚改善了什麼。

下次使用 Codex，先請它協助規劃

與其一開始就說「幫我做一個有會員、金流、後台和課程管理的網站」，不妨先用一段提示詞，要求 AI 整理需求、假設、MVP 與驗收方式：

先不要寫程式。請扮演產品經理與 UX 顧問，協助我分析目標使用者、使用情境及主要痛點。請區分已知事實與待驗證假設，建立 Customer Journey Map 和 User Story Map，規劃 MVP，並提出每項功能的驗收標準與成功指標。最後告訴我哪些功能目前不建議開發，以及原因。等我確認規劃後，再開始寫程式。

這樣可以讓 AI 先協助思考需求、檢查假設與規劃產品，再進入開發。最後是否採納規劃、是否真的要做，仍然需要由我們判斷。

功能愈容易開發，愈要考慮維護成本

程式碼變便宜，不代表維護系統也變便宜。每增加一個功能，都可能帶來資料庫、權限、測試、資安、客服與後續維護工作。透過 AI Coding 一個人能做更多事，也可能變成一個人要維護更多複雜系統。這和我在 AI Coding 技術債：寫程式快 10 倍，Temporary Fix 也可能快 10 倍 談到的維護問題相通。

AI 時代需要培養的不只是 Prompt 技巧或寫程式的能力，也包括產品判斷力：理解使用者遇到什麼問題、判斷哪些事情值得做、哪些可以先不做，並設法驗證結果。若你正在從想法評估產品，也可以延伸閱讀如何從產業痛點找到值得做的微型 AI 產品。

以前軟體開發最怕「想得到，卻做不到」。現在更值得警惕的是「想得到，也做得到，卻沒有人需要」。未來厲害的 AI 開發者，未必是一天讓 Codex 寫出一百個功能的人，也可能是能判斷哪些功能根本不需要寫的人。

產品的價值，從來不是功能有多少，而是解決了多少真正的問題。

📌 閱讀啟發：〈功能變便宜了，判斷力變貴了：AI 時代的兩張地圖〉。本文從原作者對 Customer Journey Map 與 User Story Map 的討論出發，延伸分享我對 AI Coding、需求驗證、開發規格與產品成果衡量的看法。

標籤： #AICoding #Codex #ClaudeCode #VibeCoding #產品思維 #CustomerJourneyMap #UserStoryMapping #AI應用

常見問答 (FAQ)

Q1：Customer Journey Map 和 User Story Map 有什麼不同？

Customer Journey Map 從使用者經歷出發，幫助找出旅程中的疑問與阻礙；User Story Map 則把使用者目標拆成活動、步驟與支援功能，協助安排 MVP 與後續工作。

Q2：User Story Map 可以直接交給 AI Coding Agent 開發嗎？

它能提供使用者目標與流程脈絡，但通常還需要補上開發規格、業務規則、錯誤情境與驗收標準，例如付款失敗、觀看權限或課程到期時要如何處理。

Q3：文中提到的 Outcome Map 是標準產品工具嗎？

不是。本文以 Outcome Map 稱呼「定義功能完成後要觀察哪些使用者或業務結果」的思考方式，並明確將它作為作者的延伸用法，而非特定標準工具。

Q4：AI Coding 讓開發成本趨近於零了嗎？

AI Coding 可以降低部分實作成本，但不會讓資料、權限、測試、資安、客服與維護工作自動消失。每個新功能仍要評估它帶來的長期成本與實際價值。