跟 AI 代理協作 165 小時：使用報告告訴我的四件事

我一直以為自己很懂怎麼用 AI 工作。直到它把我這三個月的使用紀錄整份攤開來。

先看數字

一個月左右的區間裡，我跟 AI 代理累積了 165 小時、167 場對話、210 個 commit。但真正讓我停下來的是工具使用的比例：

Bash        2,919 次
檔案編輯      658 次
子代理        136 次

執行指令的次數是編輯檔案的四倍多。這個比例說明了一件我沒意識到的事：我早就不是在請 AI 寫程式，而是在請它查證。跑測試與建置、翻執行紀錄、比對兩邊資料是否一致、驗證部署後的結果——寫 code 反而是其中比較小的一塊。

意識到這點之後，很多事情的優先順序就變了。我原本花力氣在「怎麼讓它寫出好的 code」，但真正該花力氣的地方是「怎麼讓它走對的路徑」。

一、我給的是問題，不是規格

報告裡有一句話讓我想了一下：「你用審問除錯，不用規格書。」

回頭看我的開場白，確實幾乎都是一句話。「為什麼這三筆訂金顯示已付？」「八個人的訂單為什麼只產出七個人的合約？」沒有背景說明、沒有預期行為、也沒有重現步驟。

但這不是把問題丟出去就沒事。能問得這麼短，前提是我已經知道系統長什麼樣、知道這個現象哪裡不合理、也知道該查的範圍大概在哪。真正花腦力的部分——判斷「哪一件事值得查」——我在開口之前就做完了，交出去的是翻紀錄、比對資料這些勞力活。

而且對這類問題，寫規格書反而不划算。我要的不是它照著我的猜測去實作，是它把證據攤在我面前。先講假設，它很容易順著我的假設去找支持的材料；不給假設，它才會老實去查。

代價是它偶爾會答到隔壁的問題。我問「畫面上會不會正常顯示」，它回我一段資料正規化的機制說明，技術上沒錯，但沒回答我問的。這種我會當場打回去要它重答。後來乾脆在句尾固定加一句「先用白話講結論，再展開細節」，同樣的對話就從三輪縮成一輪。

二、最常重複的糾正不是結果，是路徑

這是整份報告最尷尬、也最有用的一段。

AI 代理對我最大的價值其實不是寫 code，是動手之前的調研：把散落在不同地方的證據蒐齊、交叉比對、告訴我這件事的真實狀態是什麼。實際的修改往往只有幾行，難的是在改之前確認自己沒有搞錯對象。

而我重複最多次的糾正，就是它跳過這一段。我請它確認某筆資料的實際狀態，它第一個反應常常是打開瀏覽器、登入後台，把畫面上顯示的數字念給我聽。

但畫面是渲染過的結果，中間經過快取、格式化、權限過濾。我要確認的恰恰是「畫面跟底層是不是一致」，用畫面來驗畫面等於沒驗。該做的是走既有的唯讀查詢管道拿一手證據，再回頭跟畫面對照——這樣才叫調研，前者只是換一個人幫我看螢幕。

同一個糾正我重複了五次以上，講到後來只剩兩個字：「不用開。」

有一次它為了把瀏覽器這條路走通，甚至想從前端的 JS bundle 裡挖金鑰出來自己接 API，被權限機制當場擋下。這件事比繞遠路本身更值得記：當你沒有把正確的路徑交給它，它會自己生一條出來，而它生出來的那條不會考慮你的安全邊界。

問題是這種糾正每次都得重講，因為對話結束就忘了。後來我換了做法：把「查證資料一律走唯讀查詢管道，不要用瀏覽器讀畫面」寫進專案的規則檔，讓它變成常駐設定，而不是每次靠我臨場攔截。

這件事的通則我覺得可以推廣：如果一個糾正你講超過三次，那它就不是溝通問題，是設定問題。溝通問題要靠你在場，設定問題可以寫下來一次解決。

三、我容忍錯答，但不容忍白工

報告統計了我打斷它的時機，結論蠻精準的：我對「答錯」的容忍度，遠高於對「做白工」的容忍度。

有一次請它找幾張示意圖，它開始一頁一頁爬整個網站。我看了一下就打斷：「隨便抓幾張就好。」不是它做錯了，是它把一件五分鐘的事做成了半小時。

還有幾次是它一次改了太多檔案，或是自己決定要順便重構。這種我也會停下來。倒不是那些改動不好，而是我沒辦法一次 review 那麼多東西——超過我能檢查的量，就等於沒檢查。

反過來說，它給我一個錯誤答案，我通常不太在意，因為錯的答案很快就能驗掉。真正貴的是時間。

四、我不接受第一版——只要那東西代表我

有趣的是，我對程式碼相對寬鬆，對文字極度龜毛。

只要是會掛我名字出去的東西，我都會來回改好幾輪。我會挑框架（「不要給我二選一」）、挑語氣、挑標點（半形逗號出現在中文段落裡，我看到就想改），也會挑它對我的描述——有一次它把我的經歷寫得比實際豐富，那種錯誤如果我沒抓到，就會變成我對外講出去的話。

程式碼寫錯了，測試會抓、使用者會反應、可以改；但一段代表我的文字送出去之後，就送出去了。這兩件事的可逆程度差太多，所以我給它們的檢查標準本來就不該一樣。

一個真的很好笑的案例

最後講一個報告挖出來、我自己都快忘記的事。

七月中我在追查正式環境裡一筆來路不明的客戶資料。沒有來源、沒有對應的單據，看起來像是資料同步出了問題。查了一輪之後，真相是：那筆資料是 AI 自己在上一場對話跑整合測試時建立的，而那個測試沒有任何保護，預設就會對正式環境寫入。

兇手是它自己，而且它渾然不覺。

後來的處理是把測試改成預設跳過，並清掉那筆髒資料。但這件事給我的提醒比修好它本身更重要：AI 造成的問題不會自己舉手。它不會在下一場對話跟你說「對了，我上次好像弄髒了你的資料庫」。所以會寫入的東西，防護要做在它碰不到的地方——測試預設關閉、寫入需要明確批准、正式環境的操作留紀錄。

我從這份報告帶走的東西

最有價值的部分不是那些稱讚，是摩擦統計。

「方法錯誤 20 次」「使用者否決動作 15 次」「解釋不清 14 次」——這些數字我自己完全估不出來。我對自己使用習慣的印象是很模糊的，只記得幾次特別火大的當下，記不得它們其實是同一個模式重複了二十次。

而模式一旦被看見，就可以被寫下來；寫下來的東西才有機會變成不用每次重講的設定。

如果你也用 AI 代理用得夠久，很推薦回頭看一次自己的使用紀錄。你大概會發現，你以為的問題和實際的問題不是同一件事。

你跟 AI 協作時最常重複的那句糾正是什麼？我猜每個人都有一句。歡迎交流。