給 coding agent 很多「寫檔」「列目錄」的工具，並不難。難的是：它改完之後，能不能穩定地看見自己幹了什麼。
山姆鍋看過太多次這種對話——模型信心滿滿說修好了，人一開畫面，錯還在。問題不一定是模型笨，而是迴圈斷了：改了檔，沒有可靠的重載；重載了，讀不到 console；讀得到，又跟當前目標檔對不上。
目錄
最小有用的迴圈
對「改前端／改小程式」這類工作，山姆鍋心裡的最小閉環大概是：
- 選定目標（哪個專案、哪個入口）。
- 改檔（最好能帶一點防呆，例如預期雜湊）。
- 重載或確認畫布／程序已吃到新檔。
- 讀輸出：console、明顯錯誤、必要時網路或簡單狀態。
- 不對就回到 2；對了再收工。
你可以再疊搜尋、測試、截圖。但若 3、4 不穩，前面寫檔再華麗也只是加速製造謎題。
別用「更多 API」逃避觀察
工程師（含山姆鍋）的職業病是：觀察不穩時，先加下一個能力——再一個 shell、再一個 eval、再一個「讓模型直接看 DOM 的萬能函式」。有時有用，更多時候是在補償斷掉的迴圈。
寧可先問：
- 重載是否幂等、是否可等待完成？
- console 是否按目標隔離，還是混成一鍋？
- agent 能不能「等到某句 log」而不是盲 sleep？
這些看起來很土，卻常比再暴露一整個 Linux 世界更值錢。
案例：遊樂場總管那邊
在本站遊樂場，總管透過宿主 API 改工作沙盒、重載畫布、讀 console——主軸就是這條觀察迴圈。山姆鍋甚至為此砍過「瀏覽器裡塞真 Linux」的幻想：對日常除錯槓桿不夠高。
重點仍是通用的：你換一套 coding agent，也可以用同一把尺量——它看得見自己的副作用嗎？
結語
山姆鍋沒有要列工具清單。只想提醒：設計 coding agent 時，先把「改→看見→再改」做成無聊但可靠的一圈。酷炫能力可以後加；看不見的自信，加得愈多愈可怕。
你若有反例——觀察很爛但靠測試綠燈照樣活——下面留言區歡迎分享。