隨著 Openclaw（小龍蝦）的出現，不確定 PM 們會不會有一種感覺：「好像很多東西可以自己上手了，但又不知道做給誰看」，AI 工具讓 PM 可以生成 Prototype、甚至架設網站或 APP 或小遊戲，甚至可以打造全新的產品，但當做出來已經不是問題，接下來要問的是我們要做給誰。
一、PM 的 AI 焦慮時代
⠀⠀有種焦慮叫做「不學就會被淘汰」。
每次新工具的出現，產品經理圈子都會討論一波新的討論：「PM 是不是要具體 Python 能力？」「是否要有 SQL 和數據分析能力才能應徵？」「是否要具備 LLM、RAG 的基礎才能在 AI 浪潮活下來？」
經過一些激辯後，大家仍在原本的軌道工作，繼續做 PM、繼續寫 PRD、繼續跟工程師討論優先級。
但 Claude Code、Cursor、Codex 這些工具的出現，讓「自己做出一個可以跑的產品」這件事，讓 PM 開始可以自己打造產品，完成做產品的最後一哩路，只要你能把需求說清楚，只要能理解基本的程式基礎，像是部屬步驟，AI 就能做完所有事情。
2025 下半年到最近，Threads 和 Youtube 開始出現各種分享：
- 我用 Claude Code 一個週末做了一個訂閱管理工具
- 我用 Cursor 三天做出了一個 AI 面試練習 app
- 我不會寫 code，但 Openclaw 幫我部屬了 app
PM 的生態越來越捲，焦慮也每天都存在，但在這股浪潮底下，有一個問題幾乎比較少看到有人在討論：「做出來了，然後呢？」
⠀⠀
二、當 PM 開始 Vibe Coding
⠀⠀
做產品久了都會遇到一個職涯上的痛點，多數 PM 都是靠一張嘴工作，腦中有畫面，但只能透過 Wireframe、PRD、口頭說明把這個畫面翻譯給設計師、工程師，然後再等他們實現出來。
這個翻譯過程，永遠有誤差，永遠需要多輪對齊。
如果自己也能動手，就算只是做出一個 Prototype 都能提升溝通效率，親手做出一個產品，就會知道什麼功能看起來簡單但實作很複雜，也能知道什麼 UI 在設計稿上很漂亮但用起來很卡，也能知道為什麼工程師說「這個要兩週」是真的。
所以 PM 學 vibe coding 好處不只是「可以自己做產品」，而是讓自己能更立體地理解開發這件事。
⠀⠀
但是，有個有趣的現象出現了！
現在 APP Store 上面有一堆都是 side project 做出來的 APP，多數是開發者為了解決「自己的問題」所打造的，每個 APP 多半是單點問題出發，只能解決單一痛點，但如同 2015 年那幾年的 APP 熱潮，每個使用者在手機內願意安裝的 APP 數量是有上限的，沒有使用者會為了持續安裝多個 APP 來解決小型痛點。
Vibe coding 讓做產品這件事的門檻大幅降低，但「找到真實需求」這件事似乎沒有變的更容易，反而讓大家更容易跳過需求驗證這個步驟。
以前要做一個產品，光是找工程師、主管、各利害關係人估時程，就要好幾個天甚至幾週，不論最後有沒有做出來，都至少讓產品經理一些時間想清楚「這個值不值得做」。
現在一天內就能上架一個 MVP，但「做出來到底要解決誰的問題」這件事很容易被那股快感蓋過去，或是說「學習到某個工具的小成就」會蓋過產品經理去探索需求的時間。
⠀⠀
三、為了誰打造產品
⠀⠀
目前興起的 AI 工具的風潮，有點像之前數據分析這個話題出來時大家瘋狂學習 Python、SQL、大數據、數據清洗、數據洞察的樣態，比較像是一股工具浪潮。
工具學習仍有價值，但如果問正在學 vibe coding 的 PM「學這個是為了解決什麼問題？服務哪群用戶？」，很可能得到的答案是「因為這是趨勢」、「怕以後被取代」、「覺得 PM 需要懂這些」、「覺得 PM 和 RD 介面會變模糊」。
這些答案都是關於「自己」的，不是關於「用戶」的。
⠀⠀
現在搶著學 AI 技能，驅動力有兩大方向：
- PM 對於職涯的焦慮或自我保護，掌握 AI 才能有價值
- 看到市場有個用戶痛點還沒被滿足，可以透過 AI 自己做出來
觀察下來比較多是前者，但身為產品經理不得不說在這股浪潮下，我自己也被帶著走，很難完全脫離這個狀況。
就像廚師瘋狂學習各種最新的烹飪技法，卻沒有走出廚房問顧客「你想吃什麼、你為什麼來吃」。
⠀⠀
四、PM 的真正優勢是看見需求
⠀⠀
上述都是在講現況，但產品經理仍需要回答一個問題：在 AI 時代，PM 的核心競爭力到底是什麼？
AI 降低了技術門檻，但同時提高了需求洞察的競爭門檻。
因為現在任何人包含 Designer、Engineer、Sales、Marketer 都可以做出一個「看起來像產品」的東西，技術能力的稀缺性正在快速消失，當技術門檻變成人人都跨得過去的門檻，它就不再是競爭優勢。
但需求洞察這件事，從來都不容易，而且 AI 讓大家看起來「似乎都有掌握用戶痛點」。
- 能不能從 100 個抱怨識別出那個「值得解決的真實問題」？
- 能不能在一個市場找到那個「夠痛、夠大、沒有被滿足好」的缺口？
- 能不能在資源有限的情況下，在功能和情緒之間做出正確的取捨？
上面這些仍是產品經理需要在意和磨練的技能。
⠀⠀
在沒有 AI 時，需求驅動型的產品決策，會是：「我發現有一群人在 Y 這個情境裡，有個一直沒被解決好的問題，我找到一個新的方式來解決它。」
但目前 AI 時代，技術驅動型的產品決策，變成：「我發現我可以用 AI 做到 X，那我來根據 X 持續迭代。」
前者是「問題找工具」，後者是「工具找問題」。
⠀⠀
五、學完 AI 之後可以問的三個問題
⠀⠀
洞察比工具重要，但產品經理要怎麼把這些能力落地成機會？有三個問題框架可以思考。
⠀⠀
▍問題一：我要解決誰的問題？
⠀⠀
認真問自己，上一個 side project 的使用者是誰？能描述出他們的生活嗎？他們在什麼情境下會需要這個產品？他們現在的解決方案是什麼？
如果答案是「我自己」，那要小心了，因為代表尚未開始找尋潛在用戶。
好的用戶洞察，要走出自己的認知泡泡，觀察沒有接觸過的使用情境、訪談一些潛在使用者，或是直接在 Threads 貼文招募第一批使用者。
之後在打開 Claude Code 或 AI 之前，也許可以先問「我的用戶遇到 OO 痛點，他的背景是 OOO，我可以怎麼協助他」
⠀⠀
▍問題二：這個需求痛點有多痛？
⠀⠀
現在的測試比之前更簡單了，直接在 Threads 丟一個問題，看有多少人有共鳴。
最理想的區間，是找到一個「在特定情境下，對特定族群來說，非常痛的問題」，這個族群不需要很大，但他們的痛必須是真實的、迫切的，盡可能獲取他們描述的情境，且詢問他們為什麼找不到滿意的解決方案。
同時這裡也要小心「想要」和「願意付費」是兩個層級，問題不只是「有沒有人有這個需求」，而是「有沒有人為了這個需求，每個月願意掏出 X 元，換掉他們現在的解決方式」。
在做產品的時候，可以用一個很直覺的思考，這個產品能夠比 Notion 或 Excel 方便嗎？
⠀⠀
▍問題三：AI 在這個痛點的角色是？
⠀⠀
一個功能加了 AI 就叫做「智能 XX」，但如果 AI 功能，拿掉之後對核心體驗沒有任何影響，那可能就不是一個主要產品價值。
真正的 AI 整合是 AI 在這個場景裡解決了一個沒有它就解決不了的問題，像是提升某件事的品質、效率、速度、個人化，達到了以前做不到的水準。
所以在設計任何附加 AI 的功能時，都要問自己：AI 在這個場景下的角色是什麼。
⠀⠀
六、產品經理下一步：先冷靜，再加速
⠀⠀
重新拿起最熟悉的用戶觀察習慣，帶著新的工具能力，去重新審視最熟悉的那個市場或族群。
在相同產業做了幾年產品，通常會比大多數人更懂那裡的用戶在痛什麼，應該有些問題是你一直覺得「應該有更好的解決方式，但一直沒有人做好」的。
因此比起到處摸索想像出來的痛點，做出很多沒有賣點的小產品，也許可以先從自己公司的產品出發，思考在自己擅長的產品和使用者身上，如何讓 AI 融合進公司的產品或工作流程（前提是公司產品也是穩定成長的）。
AI 工具讓 PM 能做得更多，但「為什麼做」這個問題，工具也無法幫產品經理回答。
⠀⠀
如對這系列文章有興趣可以再觀看：
