vibe coding 有個前提：AI 不知道你的電腦長什麼樣子。

它知道 Godot 怎麼寫，但不知道 Godot 裝在哪；
它知道怎麼跑測試，但不知道終端機會把輸出吃掉。
這些東西每開一個新對話就要重講一次，不然它就會用猜的，然後猜錯。

第二版番茄鐘：踩到了，解決了，然後忘記了

Sproutimer 踩過的坑，現在只能從 commit 訊息反推。舉一個例子，4 月 10 日晚上 8 點 28 分（0f2eca0）：

fix: disable embed_subwindows so SettingsWindow opens as a separate OS window

Godot 預設會把子視窗嵌在主視窗裡畫。對一般遊戲沒問題，但我的主視窗是個 260x260 的透明小方塊，設定視窗如果也嵌進去就會超出主視窗的畫面，導致看不到一大段的設定都看不到。
而這必須要關掉 embed_subwindows，它才會變成真正的作業系統視窗。

同一天晚上還有幾個類似的：

• 20:20（0b91609）設定視窗和狀態機一起做進來
• 20:28（0f2eca0）關掉 embed_subwindows
• 20:58（0854565）主視窗縮成 300x300，設定視窗改成獨立視窗

每一個都是解決、往前走，沒有任何一筆記錄被寫進文件。

而三個月後，同一個坑出現在新專案的風險清單裡，被當成「還沒發生的風險」重新寫了一次。

第四版番茄鐘：動工前先寫下來

Pomofocus 的交接文件有一節叫「本機 Godot 環境（重要，容易踩雷）」，是這樣寫的：

Godot 4.6.2-stable 位於 <--使用者資料夾-->\Godot\Godot_v4.6.2-stable_win64.exe\ —— 這層是資料夾（解壓縮時建的同名資料夾），直接當 exe 執行會報 "Is a directory"。裡面才是執行檔：

• GUI 版：Godot_v4.6.2-stable_win64.exe
• Console 版：Godot_v4.6.2-stable_win64_console.exe —— CLI 操作一律用這個，GUI 版的 stdout 在 shell 收不到。

下面還有幾條：

從 Claude Code 執行時用 Bash tool（會等待程式結束）；PowerShell 的 Start-Process 在 sandbox 下會失敗。

跑測試指令時 輸出勿接 | tail（管線緩衝會讓 parse error 完全看不到；腳本有 parse error 時 app 不會 quit，看起來像測試卡死）。直接收全部輸出即可。

Godot API 踩雷：DisplayServer 沒有 screen_get_rect()，要用 screen_get_position(i) + screen_get_size(i) 自組 Rect2i。

這幾條每一條都是真的踩過。

這件事值多少

這我沒辦法精算，但可以給一個對照：
Sproutimer 在 13 個開發日子裡，光是視窗相關的 fix commit 就有十幾個；
Pomofocus 前三個里程碑在同一天（6/12）就做完了，中間沒有任何一個 commit 是在處理環境問題。

而差別只在於我把那些會重複發生的麻煩，從「每次重講」變成「寫一次」。

帶走這個：值得寫進環境筆記的四種東西

不是所有事情都要記。我的判準是「這件事會不會在下一個新對話裡重新出現」。符合的通常是這四種：

1. 路徑與版本 ——工具裝在哪、哪個執行檔才吃得到輸出。（我那個「exe 對 AI 來說其實是資料夾」）
2. 指令的怪癖 ——什麼情況下輸出會被吃掉、哪個執行方式在你的環境會失敗。（| tail 吞掉 parse error）
3. API 不存在的東西 ——你以為有、但這個版本沒有的方法。（DisplayServer 沒有 screen_get_rect()）
4. 一定要關/開的設定 ——關掉會整組失效。（embed_subwindows 必關）

每條就三行：

現象：直接執行外層那個 .exe 會報 "Is a directory"
Why：外層看似執行檔其實是解壓縮建的同名資料夾
How：用裡面的 console 版，CLI 一律用它，stdout 才收得到

寫在專案的 CLAUDE.md 或交接文件裡，新對話就會自己讀到；跨專案共用的（例如工具路徑）就存成 memory 或安裝 Claude 根目錄的 CLAUDE.md 中。

判斷標準只有一個：同一件事講第二次的時候，就可以把它寫下來。
我在這件事上慢了兩個專案。

明天回到 Sproutimer，講講 MVP 做完的當天晚上，我問 AI「這東西在市場上有需求嗎」。