這個單元解決什麼問題別人說好用的工具，對你不一定好用。這個單元給你一套「契合度評估」方法，讓你用自己的任務與工作流當尺，而不是用別人的推薦或社群熱度當尺。
學習目標
- 能用「任務契合 / 工作流契合 / 成本契合」三個面向評估一個工具或 Skill。
- 能設計一個小範圍試用協定，在投入前用低成本驗證。
- 能辨識並對抗沉沒成本，知道何時該放棄一個不適合的工具。
- 能為自己的工具組合設定定期重評節奏。
- 能用八個 KOL 篩選維度評估一個推薦來源的可信度，並把 KOL 推薦放在評估鏈的正確位置。
1. 「適合」的三個面向
別人的推薦清單只能告訴你「它能做什麼」，不能告訴你「它對你是否划算」。把判準收斂到三個面向，每個面向各問三到五題，會比看 star 數、讀 README、追蹤 KOL 推薦更接近真實決策。1.1 任務契合：解決的是痛點還是幻想？
不要被「這個工具能做 X」說服，要問「你手上最常做的任務裡，它解決了哪一條」。 具體問題：- 你最常花時間的三個任務是什麼？它覆蓋了幾個？
- 它的「殺手級功能」對你來說是每週會用一次，還是每年才會用一次？
- 它的限制（token 上限、不支援私有模型、無法離線、平台綁定）有沒有正好卡到你真實的場景？
任務契合的反例你看上一個「自動產生 PR 描述」的 Skill。但你的工作流是：本地 commit 前自己寫好訊息，PR 開了就 merge，幾乎不靠 PR 描述傳遞資訊。這個 Skill 再強，跟你的任務無關。
1.2 工作流契合：要遷就它，還是它嵌進來？
工具通常強迫你改變某件事：換 IDE、換 shell、換設定檔位置、換模型、換 CI 流程。把這些摩擦逐條列出，看你願不願意付。 具體問題：- 你的主力環境是 Windows + PowerShell，工具要求 Linux + zsh，你願意為了它建平行環境嗎？
- 它的設定檔路徑與你現有的（
.claude/、.codex/、.gemini/、.copilot/）會不會互相覆蓋或搶優先序？ - 它的 hook / subagent / skill 機制能不能在現有的 agentic harness 內共存？還是會要求你整個換掉？
- 你用的是本地模型（llama.cpp、ollama）還是 API 模型，工具是否同時支援？
1.3 成本契合：把帳算清楚
成本不是只有訂閱費。把它拆成四項，逐項估：2. 試用協定：投入前的低成本驗證
不要「安裝了就算試用」。試用要可重現、可量測、可比較。2.1 設計測試案例
選一個你真實在做、可重複的任務當測試案例。不要選「我來玩玩」或 demo 任務。試用案例設計你想評估 Antigravity 是否能取代 Claude Code 處理日常的 Python 重構。挑三個你最近做過的 refactor commit，每個 200-500 行。把每個 commit 之前的狀態存成 task script，輸入一致，記錄結果。三個案例比單一案例穩，比十個案例省時。
2.2 設定成功標準
三類指標，缺一不可：- 時間：完成同一個任務平均耗時（人 + AI）。自己量，不要靠感覺。
- 品質：人為 review 後的接受率。不用全部通過，只要一致記錄就行。
- 可重現性：同樣的 task 再跑一次，結果是否穩定。同 task 重跑出現實質差異佔半數以上，後續除錯時間會吃掉省下的時間。
2.3 限時試用
一週到兩週，不要更長。試用期間的紀律：- 每天用一行記錄：今天用了沒？順不順？遇到了什麼問題？寫到哪個檔案不重要，持續才是重點。
- 不要中途換測試案例。換案例會讓試用失去比較基準。
- 不要為了讓測試「過」而調整工作流。試用是測工具，不是改你。
3. 沉沒成本與放棄判準
你為這個工具付出的設定時間、已寫的 prompts、已建立的肌肉記憶，都不算繼續用的理由。3.1 放棄訊號
任一成立就該啟動重評：- 每次使用都在對抗工具（繞過它的限制、修它的 bug、寫 workaround）。
- 產出品質不穩定，而且不穩定的原因在工具而非任務。
- 維護負擔（更新、修設定、處理相容性）開始吃掉它帶來的時間節省。
- 同事或隊友用別的工具能更快達到相同結果。
3.2 對抗「再試一下」陷阱
沉沒成本謬誤（sunk cost fallacy）是行為經濟學已確認的決策偏差 [1]。當你發現自己在想「我已經花這麼多設定時間了，再撐一下」，把那筆花費從決策裡拿掉，重新問：「今天的我，什麼都不知道的情況下，會選這個工具嗎？」 如果答案是「不會」，就放棄。已投入的時間不會回來，繼續投入只會擴大損失。4. 「適合」會變，定期重評
你今天的適合清單不是終身契約。三件事會讓它失效：- 任務變了：你換專案、換角色、換團隊、換工作內容。
- 工具變了：工具本身升級、轉維護、被新工具取代。
- 你變了：你的技能成長後，原本的瓶頸不再是瓶頸。
重評的具體動作你用了一個 code-review Skill 六個月。重評時發現：工作流已從「PR 為主」轉成「trunk-based + 短 lived branch」，code review 頻率降到每週一次。Skill 變得低頻使用，但每月訂閱仍在跑。決定：取消訂閱，等真的回到 PR-heavy 流程再啟用。
5. KOL 推薦的批判性接收
你採用新工具的入口之一是關鍵意見領袖（KOL，Key Opinion Leader）的推薦。KOL 本身要先篩選，否則你拿到的不是資訊，是別人的偏見加上平台演算法的增益。 KOL 篩選是上游濾鏡，不是第一節三個面向的替代品。兩者串接：先用 KOL 篩選把推薦來源分成可採納與不可採納兩群；只有從可採納群出來的推薦，才進第一節的三個面向 + 第二節的試用協定。5.1 八個篩選維度
5.2 紅燈 KOL 樣態
命中 4 項以上的典型組合
- 單一廠商綁定型：某 YouTube 頻道主推 Apple 生態三年，從未給 Android 任何正評；影片開箱當天就有「購買連結」與聯盟標籤。命中 Independence、Disclosure、Range。
- 快速換品不更新型：某 Substack 作者推薦的工具每半年換一批，舊文從不更新；從未公開修正過任何一篇推薦。命中 Recency、Recovery、Range。
- 業配隱藏型：某 Podcast 來賓是某 AI 工具的 VP，推薦時說「我用了一年很滿意」，但該集是贊助集數，事先未揭露。命中 Disclosure、Depth、Range。
- 高預算不自知型：某硬體 KOL 推「生產力筆電」，預算 NT$120k 起跳，從未給中低階機型任何篇幅。命中 Fit、Range、Independence（被高階生態綁定）。
5.3 KOL 推薦在評估鏈的位置
KOL 通過篩選只是讓他的推薦「有資格」進入你的判斷；不是結論，也不是捷徑。流程是：1
KOL 篩選
8 項命中紅燈 ≦ 1，否則只當發現入口。
2
第一節三個面向
對推薦的具體工具自己跑一遍（任務 / 工作流 / 成本契合）。
3
第二節試用協定
做實證，量時間、品質、可重現性。
4
第四節重評節奏
採納後納入定期重評清單。
互動評估工具
常見誤區
- 因為某大神在用就採用。KOL 的任務、團隊、規模跟你不同，盲目跟風是把自己放進別人的問題模型。
- 把「功能多」當成「適合我」。功能多通常代表設定面廣；設定面廣在你不需要的功能上，就是維護負擔。
- 投入太多設定後不願承認不適合。沉沒成本謬誤的典型表現。設定花的時間不會回來，但繼續用會持續付出機會成本。
- 試用期沒寫成功標準。沒有標準就只剩感覺，感覺會被期待與新鮮感污染。
- 把「免費」當成沒成本。免費工具的學習、維護、遷移成本照樣存在。「免費」只是把成本從月費搬到你的工時上。
自我檢核
自我檢核
- 你能說出你正在用的某個工具，具體解決了你哪個可量測的痛點嗎？
- 你目前最貴的那個訂閱，是在上次重評之後才續的嗎？
- 你的工作流裡，有沒有正在「對抗」的工具？對抗的成本是什麼？
- 你上次啟動一次試用協定是什麼時候？結果如何？
來源與延伸閱讀
事實主張依官方文件，快變動項標註截至 2026-05。- [1] R. Thaler, “Toward a Positive Theory of Consumer Choice,” Journal of Economic Behavior & Organization, vol. 1, no. 1, pp. 39-60, Mar. 1980. https://doi.org/10.1016/0167-2681(80)90051-7 （截至 2026-05）沉沒成本效應的經濟學原始論述。
- 評估訊號的具體操作見 03-2 跳脫 star 數迷思的評估框架。
- 安全 / 隱私 / 供應鏈的對位評估見 03-3 安全、隱私與供應鏈風險。
- 量化驗證見 03-4 建立個人 benchmark 與驗證習慣。