決策紀錄
包含中途停掉的事 —— 那種東西不寫下來就永遠消失
⛔ 老闆 2026-08-16：「**這個為什麼訓練到一半就沒用了，過程發生什麼問題也都沒有記錄下來嗎？
你們之後都要把這些心路歷程寫下來。**」
⭐ 這一份記的不是「做了什麼」（那在 git 和改動紀錄裡），是為什麼那樣決定、後來發生什麼、現在怎麼看。
特別是中途停掉的事 —— 那種東西不寫下來，下一個人會重做一遍，或者像這次一樣，
東西躺在硬碟裡三天沒人知道它存在。
每一則的格式：當時的處境 → 當時怎麼決定 → 後來發生什麼 → 現在怎麼看。
⛔ 不要事後美化。決定錯了就寫錯了。
時間：2026-08-13 ～ 08-14 狀態：⛔ 停在 epoch 4，當時沒寫下原因
（本則 08-16 回頭翻對話紀錄補記 —— ⭐ 老闆：「你認真去找對話一定有」，他是對的）
生出來的畫面反覆出現「阿兔兔手上長出碎花布」—— 碎花只該在耳朵內側和腳掌。
改 prompt 壓不住，決定訓 LoRA 根治。
RealVisXL_V5.0（SDXL）| 時間 | 發生什麼 |
|---|---|
| 08-14 上午 | 訓練跑了 4 小時，中途完全沒有樣圖（漏設 --sample_prompts），也不知道跑到第幾步（log 寫成要等結束才輸出） |
| 11:28 | 停下訓練來測效果，VRAM 從 15.5 GB 降到 5.8 GB |
| 11:31 | 對照組確認：沒有 LoRA 會長花布（品檢判 FAIL） |
| 11:33 | LoRA 版也失敗，而且多了新問題（方塊化、肢體破碎） |
| 11:34 | ⭐ 抽幀一看，兩支都碎成彩色方塊 —— 根本不是 LoRA 的問題。<br>真兇是訓練佔滿 VRAM 時，ComfyUI 把殘缺的權重載進快取，照樣生成、照樣輸出、不報任何錯 |
| 11:45 | 重啟 ComfyUI 再測 → 兩支都正常了，而且帶 LoRA 那支比 Veo 版更像真的 Jellycat（耳襯碎花、腳掌碎花都對） |
| 12:01 | 即時 log 上線後立刻抓到：21.8 秒／步，預估還要 10.6 小時。真兇是解析度太高（832×480 逼到 15.9/16.3 GB，被迫 blocks_to_swap 16，權重一直在顯卡和記憶體之間搬）。查到的建議是訓練用 512×512 就夠 |
| 12:10 | ⚠️ 停下來想到更根本的一件事：我從沒驗證過「Wan 到底有沒有花布問題」 |
「手上花布」是 Veo 的毛病，不是 Wan 的。
老闆當初抱怨的那支影片是 Veo 生的。後來工具換成 Wan，我直接把結論套過去，
沒有重新量，就跳去訓 LoRA。
12:11 用像素統計逐幀掃描兩支影片（不靠品檢的主觀判斷），把「彩色像素最多」的四幀放大：
那些彩色全部是耳襯和腳掌本來就該有的碎花，前爪是純白的，一格都沒錯。
而且有 LoRA 與無 LoRA 兩支幾乎一模一樣（彩色像素 7585 vs 6704，在雜訊範圍內）。
→ 判定「Wan 沒有花布問題，LoRA 不需要」，省下剩餘約 9 小時的訓練。
當時還把三方對照圖（實物／Veo／Wan）送給老闆自己判斷，說「不想再替你決定」。
當時的判斷有一半是對的：
✅ 「花布是 Veo 的問題」—— 這個對，而且是用像素統計驗出來的，不是憑感覺。
✅ 「在花 9 小時訓練前應該先確認問題存在」—— 這條教訓正確，該記住。
但有三件事錯了：
跨 17 格看，耳朵長度、嘴巴顏色、比例一直在漂 —— 08-15 老闆逐格審片時全被抓出來。
Jellycat」—— 那是 LoRA 有效的證據。但因為結論已經倒向「不需要」，這句話就被放掉了。
LORA.md 停在第一顆 SDXL 的資訊、還寫著「已上線」；第二顆 613 MB 的 Wan LoRA 躺在廣州硬碟裡。**08-16 老闆問「我們做影片有用到 LoRA 嗎」，
我查了才發現它存在 —— 隔了三天。**
現在的狀態：animate_wan.py 的 --char-lora 預設 None，17 格全部沒帶。
正在補測那顆 Wan LoRA（同一顆 seed，帶 vs 不帶）—— 這次要看的不是花布，
是跨格的角色一致性，那才是它真正該解決的問題。
⭐ 附帶還沒用上的兩條情報（當時查到但沒實作）：
時間：2026-08-13 起 狀態：⚠️ 一直是雲端，但沒有評估過
當時：畫面生成從一開始就用 Gemini（nano-banana-pro），因為角色一致性靠「參考圖注入」，
而那時本地還沒有能吃參考圖的流程。
後來：影片生成搬到廣州本地、成本歸零之後，圖片仍然留在雲端 —— 沒有重新評估過。
2026-08-16 老闆問「生圖我記得你也說改成廣州自己生成了」，我才去查：
廣州那台其實有 RealVisXL_V5.0 和 flux1-dev-fp8，本地生圖是做得到的。
現在怎麼看：這是慣性，不是決定。而且它連帶讓第一顆 SDXL LoRA 沒有用武之地 ——
如果生圖在本地，那顆 LoRA 就能掛上去。待評估：本地生圖的品質是否夠、要不要搬。
時間：2026-08-15 狀態：✅ 已解決
當時的處境：老闆連續三次說「像慢動作」「11 秒兔子只會舉右手再舉左手」。
我試了改 prompt、換 seed、下最硬的禁令、加首尾幀、接 CLIP Vision —— 全部沒用。
怎麼決定：派兩個 agent 去讀官方原始碼與 workflow JSON，不再自己猜。
發現（四個真因沒有一個是 prompt 問題）：
結果：改成三段取樣（第一步用沒掛加速的原始模型、cfg 3.5），
動作量 2.05 → 5.03，停滯 2.1 秒 → 0.2 秒。
現在怎麼看：⭐ 我在 prompt 這一層打轉了整整一天，真因全在更下面。
判準：同一個方向試了三次還不行，就該換一層去查，而不是把同一層的參數再調一次。
時間：2026-08-15 狀態：✅ 已驗證
處境：阿兔兔揮手時掌心必長碎花。角色鎖裡明明寫了「碎花只在耳朵和腳掌」。
試過：加中文負面提示 → 還是長。改成正面描述「手掌就是一整片平滑的奶油白」→ 還是長。
提高第一段步數 → 還是長。連續三次 FAIL。
最後怎麼解：換起始幀 —— 生一張「手已經舉起、掌心純白朝前」的圖當起點。一次就過。
現在怎麼看：原因是模型從沒看過那隻手掌長什麼樣（起始幀裡手收在胸前），
一轉向鏡頭就自己填了花紋。⭐ 這條老闆的 CLAUDE.md 早就寫著
（「必定生壞的東西就換構圖」），我還是硬碰硬試了三輪才回頭看它。
時間：2026-08-15 狀態：✅ 已成為通則
處境：老闆說 S04「沒有感受到跑一跑突然有一股大風吹來」。
診斷：那格的起始畫面本身就是「風已經在吹」（圍巾橫飄、落葉亂飛）——
整整 5 秒都是同一種風，當然沒有「突然」。
通則：「突然發生某事」的鏡頭，起始幀必須是「還沒發生」的狀態。
分鏡圖畫的如果是「事情發生後的樣子」，那張圖是結束幀，不是起始幀。
同樣適用於：東西掉下來（起始＝還在手上）、角色嚇一跳（起始＝放鬆）、
天黑（起始＝白天）、圍巾被扯走（起始＝還在脖子上）。
blocks_to_swap 我調反了方向，同一個錯犯兩次時間：2026-08-14（第一次）· 2026-08-16（第二次才發現） 狀態：✅ 已解決並量出來
訓練時 GPU 顯示 100% 使用率，但功耗只有 35 W（那張卡滿載該是 180 W），
VRAM 15,960 / 16,311 MiB（97.9%），第一步跑不完。
「100% 使用率但不吃電 ＝ 卡在資料搬運 ＝ blocks_to_swap 太大，搬太多次」
→ 把 30 降到 20，想「少搬一點就快了」。
結果 VRAM 幾乎沒降，還是卡住。
blocks_to_swap 是「把幾層權重搬去系統記憶體」——
數字越大，留在 VRAM 的層越少，VRAM 越空，越有空間做運算。
14B 模型就算 fp8 也要 14.3 GB，而卡只有 16.3 GB。
我把數字調小，等於讓更多層擠在 VRAM 裡 → 沒有空間放中間結果 → 整個訓練都在等。
改成 34 之後：
| 之前（swap 20/30） | 之後（swap 34） | |
|---|---|---|
| VRAM | 15,960 MiB（97.9%） | 8,527 MiB（52%） |
| 功耗 | 35 W | 163 W |
| 速度 | 第一步跑不完 | 8.0 秒／步 |
| 660 步 | 卡死 | 約 1.5 小時 |
⛔ 同一個錯誤犯了兩次。 2026-08-14 那次訓練 21.8 秒／步、預估 10.6 小時，
當時 blocks_to_swap 16 —— 完全一樣的病，我當時歸咎於「解析度太高」，
其實真因是這個參數調反了。
⭐ 判準：先看數字往哪邊動，再決定方向。
我改了參數卻沒有立刻回頭量 VRAM，所以第一次改錯（20）之後還以為是別的原因。
改一個參數 → 立刻量它該影響的那個數字 → 沒動就是改錯方向。
⭐ 另一條：功耗是最誠實的指標。
「使用率 100%」會騙人（等資料也算佔用），但功耗不會——
35 W 就是沒在算，163 W 才是真的在算。往後訓練一律看功耗，不看使用率。