這半年開始，越來越多產品經理開始直接參與 AI 開發。
有些人因此變得異常樂觀，認為只要會下 Prompt，很快就能一個人完成整套 SaaS；也有另一群人則在試用幾次後迅速失望，覺得 AI 幻覺太多、不可靠，終究無法進入真正的商業開發流程。
但實際進入專案之後，我慢慢發現：
AI 最麻煩的地方，其實既不是「它太強」，也不是「它太笨」。
而是它非常像一個剛進公司的初階工程師——
動作很快、懂很多名詞、看起來充滿自信，但其實並不真的理解真實的商業世界。
於是整個專案裡，真正開始變重要的能力，反而不是 Coding 本身，而是：
- 你怎麼定義規則；
- 你怎麼驗證現實；
- 你怎麼避免系統「假裝自己正常」。
這可能才是 AI 時代裡，產品開發真正開始需要學的事。
AI 最大的問題，不是幻覺，而是「過度自信」
很多人討論 AI 時，會把焦點放在「它會不會胡說八道」。
但真正進入開發流程後，我反而覺得，更危險的是另一件事：
它很常「看起來已經完成了」。
例如在一次專案裡，我曾經遇過 AI 很認真地回報：
「檔案已修改完成」
但實際打開資料夾，檔案根本沒變。
又或者它會告訴你：
「測試已成功通過」
結果真正跑測試時，console 裡其實還是一片紅字。
這種問題麻煩的地方在於，它不像傳統 Bug 那麼容易被發現。
它更像是一種「流程中的假動作」——系統正在用極高的自信，製造一種專案仍然穩定前進的幻覺。
後來我慢慢理解：
與 AI 協作時，不能只靠對話信任，而必須建立「可驗證的機制」。
於是我開始要求：
- 修改檔案後，必須重新讀取檔案內容確認；
- 測試完成後，不接受「測試成功」這種描述，而是直接貼出測試結果；
- 所有關鍵步驟，都必須能被工具驗證，而不是被語言描述。
這聽起來很像在防呆。
但某種程度上，真實世界的大型系統，本來就是建立在各種防呆上的。
而 AI 只是讓這件事變得更加明顯。
「一句話寫完整產品」通常是災難的開始
現在網路上很流行一種敘事：
「我只花三句 Prompt，就做出一個 App。」
但實際做過稍微複雜一點的產品後，大概很快就會發現：
真正困難的從來不是「把功能生出來」，而是讓整個系統在半年後仍然能維護。
AI 很擅長產生「看起來能動」的東西。
但一個缺乏規格與邊界的系統，最後往往會變成大量耦合、難以擴充、沒有人敢修改的程式泥沼。
有趣的是，這反而讓產品經理原本的能力突然變重要了。
因為 PM 最核心的工作，本來就不是畫 Wireframe，
而是：
- 定義邊界；
- 拆解問題；
- 建立規則；
- 讓不同角色能在同一套理解下協作。
在 AI 開發裡，這些能力的重要性甚至比以前更高。
我後來甚至發現，真正有效的 AI 開發流程，很像在管理一個缺乏經驗、但產能極高的 junior team。
如果沒有明確規範，它會用最快速度把整個系統推向混亂。
所以我們在專案一開始，反而刻意先不碰業務功能，而是先建立：
- PRD；
- 命名規範；
- 資料結構原則；
- 驗收流程；
- 測試標準。
例如財務系統禁止浮點數運算、所有金額統一使用 decimal library；
每次修改都必須經過 compile、lint、test、build 四層驗證。
這些事情看起來很「慢」。
但 AI 時代一個很反直覺的現象是：
因為生成速度太快，所以系統反而更容易快速腐爛。
真正稀缺的，開始變成「對現實世界的理解」
AI 很擅長生成標準答案。
但商業世界很多時候沒有標準答案。
只有：
「哪種設計比較符合現實。」
這件事其實在資料模型設計時特別明顯。
例如某次設計金融帳戶模型時，AI 一開始很自然地把帳戶分類成：
- 活存；
- 股票；
- 外幣；
- 定存。
這在大部分記帳軟體裡都很合理。
但如果真的理解銀行實務，就會知道現實不是這樣運作的。
同一個網銀帳號底下，可能同時存在：
- 台幣帳戶；
- 多筆不同到期日的外幣定存；
- 黃金存摺；
- 投資帳戶；
- 子帳戶。
如果一開始就做過度抽象化，後面很容易在串接真實銀行 API 時全面崩潰。
所以後來我反而要求系統：
不要優先追求「漂亮的抽象」，
而是先忠實貼近真實世界。
這其實也是我最近越來越強烈的一種感覺：
AI 正在快速吃掉「標準化知識」。
但那些真正理解產業怎麼運作、理解例外情境、理解組織混亂與現實摩擦的人，價值反而會開始上升。
因為 AI 最大的盲點，始終是：
它知道程式「應該怎麼寫」。
但人類比較知道世界「實際怎麼運作」。
結語
以前很多人認為，軟體開發最核心的能力是 Coding。
但 AI 出現後，我反而越來越覺得：
真正重要的能力，開始變成：
- 如何拆解問題；
- 如何建立規則；
- 如何驗證現實；
- 如何把模糊的商業世界，轉譯成系統能理解的秩序。
某種程度上，AI 沒有讓產品經理變得不重要。
它只是開始逼迫大家重新思考：
產品經理真正的價值，到底是什麼。
