原文：How to Decide When an AI Tool Is Worth Keeping

最近 AI 工具真的多到有點跟不上。今天有人推薦一個新的 AI 筆記工具，明天又看到一個 Agent 可以幫忙做簡報，過幾天可能原本使用的工具又更新一堆新功能。
看到這些工具時，很容易有一種焦慮：「大家都開始用了，我是不是也應該趕快學？」
大家都在用，不代表它真的適合你；公司買了，也不代表每件工作都應該硬塞進去。
所以比起問「這個 AI 工具厲不厲害？」，更實際的問題應該是：跟我現在原本的做法相比，它到底有沒有讓這件事情變得更好？

不要先玩工具，而是先決定你想改善哪一件事

我們平常測試一個新的 AI 工具，很容易走兩個極端。第一種是隨便丟一個很適合 Demo 的任務進去，結果看起來超厲害，就覺得這工具一定可以提升效率；另一種則是剛好拿它做一件不擅長的事情，用了一次覺得很難用，就直接放棄。
但這兩種方式其實都沒有回答真正的問題：它適不適合「我的這項工作」？
這也是 PROVE Framework 想處理的事情。PROVE 分別代表 Problem Alignment、Risk、Output Quality、Velocity 和 Experience。它不是要幫公司選出「全公司最好的 AI 工具」，而是很單純地幫一個人判斷：這個工具用在這項任務上，值不值得繼續用。

第一步是 Problem Alignment，也就是問題有沒有對上。
與其先打開工具到處玩，不如先找一件自己真的會重複做，而且需要花不少時間的工作，再看看這個工具的能力能不能剛好解決它。
例如你每週都要整理會議紀錄，那 AI 如果能幫你節省 20 分鐘，長期下來就很有價值。但如果一年只做一次，就算節省一半時間，實際幫助可能也沒有想像中大。
原文拿 Gemini Notebooks 當例子。使用者每週都會挑兩到四篇文章，再整理成一段內容分享到 Slack。他已經自己閱讀、挑好文章，真正耗時間的是把這些內容整理成 Digest。而 Gemini Notebooks 剛好很擅長讀取多個來源再進行整理，所以這個任務跟工具能力就很吻合。

能做到之前，還要先確認「能不能安全地做」

第二個是 Risk。
這點我覺得很容易被忽略。因為 AI 太方便了，很容易想說：「我就把資料丟進去看看。」
但如果今天放進去的是客戶資料、訪談逐字稿、還沒公開的產品策略，甚至公司的程式碼，問題就不只是生成結果好不好，而是這個工具到底能不能接觸這些資料。
所以在花很多時間研究一個工具之前，其實應該先確認公司有沒有允許使用、資料會怎麼被處理，以及這次的內容是不是包含個資、機密或專有資訊。如果本來就不適合把資料放進去，那這項評估其實到這裡就可以停了。

AI 做得「還不錯」，到底算不算夠好？

接下來是我覺得很實用的 Output Quality。
評估 AI 的品質，不應該只有「看起來不錯耶」這種感覺，而是拿自己過去真的做過的成果跟它比較。
而且「好」沒有統一標準。
如果今天只是公司內部自己看的大綱，AI 寫得八十分可能已經非常夠用；但如果是要直接寄給重要客戶的提案，可能就要九十五分以上才敢交出去。
Gemini Notebooks 的案例就很有意思。它整理出來的內容正確、完整，也沒有亂編資料，但問題是「不像人寫的」。原本自己寫的版本比較像在跟同事聊天，AI 的版本卻像一份有 Summary、Significance 的正式報告。
所以它不是品質不好，而是內容做對了，語氣還沒有符合這個任務。

不要只看生成用了 3 秒，要看你最後到底花了多久

第四個是 Velocity，也是我覺得自己很容易被 AI 騙到的一點。
AI 三秒鐘產出答案，看起來超快，但如果接下來我要花三十分鐘檢查、改錯字、調語氣、重新排版，那它到底有沒有比較快？
所以真正應該比較的是完成整項任務所花的總時間，包含準備資料、下 Prompt、檢查內容、修改錯誤、重新排版，以及在不同系統間搬資料。
原本人工寫一篇 Digest 大概需要 25 分鐘，使用 Gemini Notebooks 後，包含修改語氣，大約十多分鐘。這樣才是真的有節省時間。
不過文章也提醒另一種情況：有些 AI 工具可能沒有比較快，但它能做到原本自己做不到的品質。這時候即使花的時間變長，也不代表沒有價值。
所以「效率」其實不能只看速度，還是得回頭看最後得到什麼。

最後一個常被忽略的成本：它到底好不好融入工作流程？

最後是 Experience。
有些工具產出的東西很好、速度也很快，但你就是不會想天天用。
原因可能很小：每次都要重新上傳資料、在好幾個分頁之間切換、複製貼上、重新調格式……單看一次好像沒什麼，但如果這是一個每天或每週都做的任務，這些摩擦會一直累積。
所以這裡很重要的一個判斷，是區分「第一次才會遇到的麻煩」和「每次都會遇到的麻煩」。
第一次學習介面、設定帳號其實還好，因為用久就沒了。但如果每次使用都得重複五個很煩的步驟，那才是真正需要注意的成本。
Gemini Notebooks 的例子原本只有「看文章 → 寫內容 → 發 Slack」三個步驟，加入 AI 後反而變成「看文章 → 上傳 → Prompt → 複製出來 → Slack 重新排版 → 發布」六個步驟。雖然總時間還是比較短，但 Workflow 其實變碎了。
我覺得這點滿真實的。有時候我們以為加入 AI 就是在「自動化流程」，但其實只是在原本流程中間多塞了一個工具。

PROVE 最後不是算出一個分數，而是做出一個可以解釋的決定

評估完後，Output Quality、Velocity、Experience 可以用五分制簡單評分，3 分代表和現在的做法差不多。
不過重點不是最後加總得到幾分，而是能不能清楚回答：我測試了什麼工具、拿它做什麼工作、結果怎麼樣，以及下一步到底要繼續使用、再試一個月，還是暫時放棄。
而且一次測試也不能直接變成「這個工具超好用，全公司都應該使用」。
它真正能證明的只有： 「這個工具，在這個任務、這組資料和目前的使用方式下，看起來值得繼續試。」
未來工具更新、自己的工作方式改變，答案都可能重新變化。所以 PROVE 做出來的不是永久結論，而是一個目前有證據支持的暫時決定。

我的延伸思考

1. PM 在導入 AI 功能時，是不是也可以用同樣的方法？

我覺得可以，而且不只拿來挑工作工具。
現在很容易有一句需求是：「我們這裡也來加 AI。」但其實第一個問題不應該是「要用哪個模型」，而是 Problem Alignment：這裡到底有什麼問題值得 AI 解決？
例如使用者完成一個任務原本只要 30 秒，就算 AI 可以幫忙，也不一定值得增加新的介面和學習成本；但如果使用者每天都要人工整理大量資料、比較十幾個選項，那 AI 帶來的價值就可能很明顯。
所以我覺得 PROVE 對 PM 最大的提醒，就是先有問題，再找 AI，而不是先有 AI，再替它找問題。

2. 公司一直要求「多用 AI」，PM 該怎麼回應？

我覺得這篇提供了一個滿好的思考方式。
不是直接說「AI 沒有用」，也不是為了符合期待硬塞 AI，而是把問題改成： 「我們測過哪些 Workflow？在哪些地方真的有改善？」
例如可以很具體地說：「我們測試 AI 整理訪談摘要，原本需要 60 分鐘，現在包含人工檢查需要 35 分鐘，而且品質可以接受，所以繼續使用；但需求規格這項任務，目前修改成本太高，所以暫時不採用。」
這樣討論的焦點就從「你有沒有使用 AI」，變成「AI 到底在哪裡帶來價值」。
我覺得這也比較像 PM 應該做的事情：不是追每一個新工具，而是判斷 哪一個工具真的值得進入 Workflow。

最後

現在 AI 工具更新的速度，已經快到不可能每一個都學會。
所以看完這篇後，我反而覺得，不需要追求「知道最多 AI 工具」，而是要建立一套自己判斷工具的方法。
這個工具有沒有解決真正的問題？資料能不能安全使用？結果夠不夠好？整體真的有比較快嗎？使用久了會不會反而增加更多麻煩？
當這幾個問題都有答案後，「要不要用 AI」就不再只是因為 FOMO 或覺得大家都在用。
AI 工具不是越多越好，最後留下來的，應該是那些真的讓工作變好的工具。
了解自己想要解決什麼問題，比學很多 AI 來的重要。