AI 讓實作變便宜，PM 判斷價值更高了！

最累人的 AI 工具，常常不是一開始就失敗的那種。

一開始就失敗，至少你很快知道不能用。更麻煩的是另一種：它看起來已經完成 95%，你卻得坐在旁邊盯著最後 5%。檢查它有沒有漏掉條件、引用錯資料、改壞既有流程、在不該自作主張的地方自作主張。

這時候，名義上是 AI 幫你自動化；實際上，是你被安排成它的監工。

數位時代 4 月 30 日轉述 Lenny’s Podcast 對 Anthropic Claude Code 產品負責人 Cat Wu 的訪談，把這個問題講得很清楚：當寫 code 變得更便宜，AI 時代真正變貴的不是把東西做出來，而是知道什麼值得做、什麼才算好。

這句話很容易被聽成 PM 的職涯安慰劑：AI 不會取代你，因為人類還有品味。

但如果只停在這裡，就太空了。對 AI 產品來說，產品品味不是一種性格，也不是一句「我比較懂使用者」。它應該落到更硬的問題：什麼工作可以交給 AI？做到什麼程度才算可以交？錯了怎麼停？模型變強後，今天做出來的介面和流程還剩多少價值？

實作變便宜後，壞判斷也變便宜

Claude 官方頁面把 Claude Code 定位成 agentic coding tool：它可以理解 codebase、編輯檔案、執行命令，並進入開發者的 terminal、IDE、桌面或瀏覽器工作環境。這類工具的方向很清楚：讓「把想法變成可運行軟體」的成本下降。

成本下降不代表工程不重要。真正改變的是瓶頸位置。

以前一個產品想法要排進 roadmap，要經過設計、開發、測試、上線，實作成本本身會自然篩掉很多想法。現在，AI coding agent 讓團隊更容易把很多想法快速做成 demo、prototype、internal tool、feature variant。

這聽起來是好事，但它也讓壞判斷變得更便宜。

如果一個團隊不知道什麼值得做，AI 只會讓它更快做出一堆不值得做的東西。如果一個 PM 說不清楚什麼叫做「好」，AI 會讓模糊需求更快變成模糊產品。如果團隊沒有定義錯誤邊界，AI 會把原本藏在人工流程裡的風險，直接帶進自動化流程。

所以 PM 的稀缺性不是從「會不會寫規格」轉成「會不會下 prompt」。更準確地說，是從管理產出流程，轉成定義產品判斷。

什麼問題值得被解？什麼工作值得被委派給 AI？什麼結果可以不經人工逐項檢查就交付？這些才是 code 變便宜後，PM 變貴的地方。

95% 自動化，可能只是把人放到最後盯梢

數位時代文章裡最值得抓住的點，是 95% 自動化不一定是真自動化。

一個工具如果能完成 95%，剩下 5% 需要人高度警戒，它未必讓人更輕鬆。因為人的注意力不是照比例消耗的。你不會因為 AI 做了 95%，就只花 5% 的心力。很多時候，你要重新讀一遍、驗一遍、想一遍，才能確定它沒有在最後一步出錯。

這就是 AI 產品最常見的落差：demo 看起來像魔法，日常使用像監工。

原因不是模型一定不夠好，而是產品沒有定義清楚「委派門檻」。所謂委派門檻，是一個很具體的產品問題：

• 這個任務可以容忍哪一種錯誤？
• 哪些錯誤一定要提早停下？
• AI 什麼時候可以直接執行，什麼時候只能提出建議？
• 使用者要檢查的是重點摘要，還是每一行細節？
• 失敗時，產品要把人帶回哪一個可理解的位置？

如果這些問題沒有被設計出來，AI 產品就會把責任丟回給使用者。介面看起來很自動，心理負擔卻沒有消失。

好的 AI 產品不是讓使用者感覺「AI 很努力」。好的 AI 產品是讓使用者知道：這件事我可以放心交給它；如果它不確定，我知道它會在哪裡停；如果它犯錯，我知道我該怎麼修。

Eval 要測的，是產品承諾

這也是為什麼 eval 會變成 PM 的核心能力。

很多團隊一聽到 eval，會把它當成模型工程或 QA 工作：準備測資、跑準確率、比較模型版本。這些當然重要，但對產品來說，eval 更像是把 taste 寫成可以檢查的承諾。

如果 PM 說「這個 AI agent 要能幫工程師處理小 bug」，這還不是產品規格。真正的規格要更接近：

• 它能處理哪一類 bug？
• 它需要先讀哪些檔案？
• 它能不能自己執行測試？
• 它改動超過多少範圍要停下？
• 它要怎麼解釋自己的修改？
• 什麼情況下它應該承認無法處理？

這些問題的答案，才會變成 eval。

換句話說，eval 不是冷冰冰的分數表，而是產品品味的壓力測試。你認為好的使用者體驗是什麼？你認為哪些錯誤不能接受？你認為 AI 應該在什麼時候保守、什麼時候主動？如果這些判斷沒有被寫成 eval，它就只存在會議裡。

在傳統軟體裡，PM 可以把很多判斷交給流程：設計稿、PRD、驗收標準、QA checklist。AI 產品裡，輸出不是固定的，模型能力也會變。這讓 eval 從後段測試工具，變成前段產品定義。

PM 不一定要親手寫所有測試，但必須知道該測什麼。因為你測什麼，就代表你認為產品承諾是什麼。

別把暫時補洞誤認成護城河

AI 產品還有一個麻煩之處：今天很重要的設計，明天可能被模型能力吃掉。

數位時代文章也提到類似問題：一些為了彌補模型不足而做的 scaffolding，可能隨著模型變強而變得不再必要。這對 PM 來說很殘酷，因為你辛苦設計的流程、提示、輔助步驟、todo list、檢查機制，可能只是暫時補洞。

但這不代表產品設計沒有價值。它代表 PM 要更清楚分辨兩種東西。

第一種是暫時性 scaffolding：為了讓今天的模型不要失控，額外包上的提示、格式、流程限制。這些東西可能必要，但不應被誤認為長期護城河。

第二種是耐久的產品價值：使用者場景理解、資料整合、權限邊界、信任機制、團隊工作流、可觀測的 eval 系統、從錯誤中恢復的路徑。模型變強後，這些仍然重要，甚至更重要。

舉例來說，一個 AI coding agent 的 prompt 模板可能很快過時；但它如何理解一個公司的 codebase、如何遵守權限、如何在高風險改動前停下、如何把修改交給人 review、如何留下可追蹤的決策紀錄，這些比較不容易被單純模型升級取代。

PM 的 taste 就在這裡變得具體：不要愛上今天的 workaround，要看見明天還站得住的產品層。

PM 要少問「做完沒」，多問「能不能交出去」

如果 AI 讓產品團隊更快做出東西，PM 最需要改掉的習慣，是把「功能完成」當成主要進度。

在 AI 產品裡，功能能跑只是起點。更重要的是，這個功能是否能被委派。

一個比較好的 PM checklist，應該長這樣：

第一，先寫清楚 delegation threshold。

這個 AI 功能到底要接手哪一段工作？是建議、草稿、執行，還是完整代理？如果只是草稿，就不要把它包裝成自動化；如果要完整代理，就要定義它什麼時候必須停下。

第二，把 taste 寫成 eval。

不要只說「答案要好」、「修改要乾淨」、「語氣要像我們」。把好拆成可檢查的情境、失敗案例、最低標準和不可接受錯誤。

第三，設計 failure path。

AI 不確定時，產品應該怎麼呈現？它是要求更多資訊、提出替代方案、回到人工流程，還是直接停止？很多 AI 產品難用，不是因為它從不犯錯，而是因為它犯錯後讓人不知道怎麼接手。

第四，分辨暫時 scaffolding 和耐久價值。

今天為了補模型缺口做的流程，不一定要刪掉，但要知道它可能不是長期核心。真正該投資的是資料、權限、工作流、eval、信任與恢復機制。

第五，重新定義人的角色。

如果 AI 產品的結果是讓人永遠盯著最後 5%，那不是把人解放出來，而是把人放進更累的位置。好的產品應該讓人從逐項監工，移到設定目標、批准高風險決策、處理例外、校準標準。

這也是 Cat Wu 這類討論值得被寫的原因。它不是在說 PM 只要有品味就安全，也不是說 AI coding agent 會讓產品工作變簡單。相反，它讓產品工作變得更難逃避。

以前，模糊的產品判斷可能會被漫長實作流程稀釋。現在，AI 讓模糊判斷更快變成產品；PM 要守住的，就是這個速度背後的標準。

當 code 變便宜，真正昂貴的是你能不能說清楚：我們到底要做什麼，做到什麼才算好，以及什麼東西不該交給 AI 自己決定。

林子睿（編輯：廖玄同），《AI 讓實作變便宜，PM 判斷價值更高了！》，矽基前沿 [Si]gnals，2026-04-30。https://signals.tw/articles/ai-pm-product-taste/