AI 第三次用同一個笨方法時，叫它停下來做工具

本文提到的遊戲修改，都是在封閉本機做的數位保存與相容性研究，不提供任何遊戲檔案、修改檔或私服營運。

你讓 AI 改專案裡的一個小東西，例如把一個數值調大一點。它很勤勞：先寫一支 python -c 翻檔案，再寫一支把結果整理出來，改完再開 Computer use 一格一格點畫面確認；如果是網站，就是重開 dev server、自己用 curl 戳一遍。半小時過去，額度掉了一截。隔天要改另一個數值，它又從頭寫一次。

我前陣子在一款 2012 年、沒有原始碼的老遊戲上，帶著 AI 從逆向開始一路改。改到第三天，我在 Threads 寫下這段心得：

讓 AI 改遊戲是一件很燒 token 的事情，尤其在沒有原始碼的前提下，只能透過逆向工程，而且 AI 會很笨的幫你一直用土方煉鋼的方法。

這篇用遊戲當例子；如果你的 AI 專案會持續好幾天，也可以留意有沒有重複做同一件事。

AI 為甚麼又慢又燒額度？

慢，通常是因為它每次都在重做同一件事。

在那個專案裡，AI 每次想理解一段遊戲邏輯，就去讀一堆記憶體和組語。它不會先把整個程式一次反編譯完、建好可以搜尋的索引，也不會搭配 codegraph 這類工具一次撈出相關程式碼。所以每改一個小東西，都要從頭翻一次，不但久，還很吃額度。

測試也一樣。AI 很喜歡用 Computer use 開遊戲、移滑鼠、點按鈕。它完全沒想到，既然都能改遊戲了，當然也能做一組專屬指令，在背景控制遊戲行為，再用 log 和截圖確認結果。

	每次現場做	先蓋好工具
找相關程式碼	每次讀記憶體、讀組語，從頭摸	一次反編譯完，建索引，一行指令搜
測試	Computer use 點畫面，慢而且容易誤點	專屬指令在背景操作，看 log 判斷過沒過
第二次改類似的東西	再從頭來一遍	直接用上次的工具

AI 為甚麼不會自己先蓋工具？

一個可能的原因是，它先解決眼前這一題。

對「這一次」來說，現場寫一支腳本可能比較快。蓋工具是為了第二次、第三次；如果沒交代後面還會重複，AI 可能只做完眼前的工作。

所以人要先判斷後面是否還會重複。在真正動手改遊戲功能之前，我先停下來，讓 AI 做了很多腳本工具和機制，也先讓它優化遊戲本身的讀取速度和資料庫效能。把基礎建設弄起來之後，改功能快又準，測試也能讓 AI 自己來。

甚麼時候該叫它停下來？

那個專案後來把這件事寫成一條規則：同一件事第 3 次出現，就升級成工具或自動檢查。

回到你的專案，可以看這三個訊號：

同一種一次性腳本寫到第三支。 終端機裡又出現一支 python -c 或 analyze_xxx.py，做的事和前兩支差不多。
每次都從頭讀同一批檔案。 它每換一個問題，就重新搜尋、重新讀一遍同樣的東西。
每次都手動驗證。 遊戲或桌面程式是開 Computer use 點畫面；網站或後端則常見每改一次就重開 dev server、自己用 curl 一個個戳，或重寫一段臨時的驗證腳本。

看到其中一個，就先判斷這個動作還會不會重複。像腳本已經寫到第三次，可以直接這樣講：

程式碼

這是你第三次寫類似的腳本了。先停下來，把它做成 tools/ 底下一支有名字的指令，
參數化、寫好用法說明，加進 CLAUDE.md 的工具清單，之後同類查詢都用它。

那個專案後來有了反編譯搜尋工具，也有不動滑鼠的自動測試。

工具做好了，它還是不用怎麼辦？

工具做好了不代表 AI 會用。

在那個專案裡，工具明明做好了，AI 一急還是會本能地打出一次性的 python -c。後來的做法是加一道 Hook（在 AI 執行指令前先檢查的程式），偵測到舊的寫法就直接擋下，錯誤訊息裡寫清楚該改用哪一支工具。

擋的範圍要窄，只擋已經有工具能取代的那種寫法，例如「用 python -c 載入反組譯套件」，而不是所有 python -c。錯誤訊息直接寫出替代指令，例如「這類查詢請改用 tools/find.py <函式名>」，AI 被擋下後就知道下一步怎麼做。

這一步也不是做完就好。專案紀錄裡，補上工具和檢查之後，還是有耗時與報錯的問題。

工具會有缺口，自動檢查也要持續核對涵蓋範圍，邊用邊補。蓋工具沒辦法一次解決所有的慢；但如果之後能重複用，就有機會省下重做的時間。

甚麼時候不值得蓋？

兩種情況，現場做就好：

專案一兩天就結束。 工具還沒用到第三次，專案就結束了，蓋工具的時間收不回來。
每次的動作都不一樣。 如果三次腳本做的是三件不相干的事，就沒有東西可以做成工具。

要看的是同一個動作會不會繼續出現，做工具本身並沒有比較專業。

下次看到 AI 第三次用同一個土方法，先叫它停下來，把這個動作做成指令，再繼續改功能。

這篇可以先收藏，下次開長專案時拿出來對一下那三個訊號。