評估 AI 程式工具，不要只看它寫得多快

速度只是最容易被看見的指標

第一次使用 AI 程式工具時，最容易注意到的是它能多快產生一段看起來合理的 code。但在真實專案裡，生成只是工作的前半段。你還要確認它是否理解 repository 的慣例、是否碰到了不該修改的檔案、測試是否涵蓋新的行為，以及下一位接手的人能不能讀懂這個結果。

因此，工具評估應該從「它能不能寫」換成「它能不能讓整個 feedback loop 變短」。速度依然重要，但不該單獨決定採用與否。

請工具處理一個需要跨檔案理解的任務，而不是單一函式補全。例如，新增一個欄位需要同步更新 type、validation、API response 與測試。觀察工具是否能找到相關位置，並且在不確定時提出問題。

上下文品質不等於能塞進更多檔案。好的工具會協助你縮小必要範圍，讓模型看到足夠的背景，又不被無關內容淹沒。

要求工具同時提出測試與驗證方式，再執行既有的 check command。比起一個一次通過的 demo，更有價值的是它能否把自己的假設暴露出來。若工具只回傳「應該可以」，卻沒有告訴你如何確認，速度再快也只是把檢查成本往後推。

故意讓第一個任務帶有一個容易發現的限制，例如不能修改某個模組，或必須保留一個既有介面。接著觀察工具收到測試失敗後，能否定位問題、提出小幅修正，而不是重新生成一大段無關的 code。

個人使用的順手，不代表團隊導入也順手。評估它產生的 diff 是否容易 review、是否能留下清楚的變更摘要、設定是否能被版本控制，以及權限與資料是否符合團隊政策。這些因素會直接影響其他人是否願意接住 AI 產生的結果。

挑三個你熟悉、但需要不同推理方式的任務：一個小型 bug fix、一個跨檔案功能、一個測試或文件補強。為每個任務固定輸入與驗收標準，記錄完成時間、人工修改次數、測試結果與 review 意見。

不要用一次結果就下結論。工具表現會受到 language、framework、repository 大小與規則文件影響。把測試放在自己的工作流中重複幾次，你得到的不是排行榜，而是一張「在什麼情境下值得使用」的地圖。

AI 程式工具不是用來替團隊消除判斷，而是把低價值的搜尋、草稿與重複修改交給模型。評估時，最值得問的是：它是否讓人更早看到真正的問題？如果答案是肯定的，即使它不是每次都最快，也可能是更適合長期使用的工具。