模組六｜治理與收斂（Day 28–30）

最後三天。前面 27 天講產線怎麼跑，這三天講它留下了什麼。

先講一個數字：.git 目錄 3.2 GB。

整個 repo 6.06 GB，其中 52% 是版控歷史。

有制度，而且是規格驅動的

我要先講對的部分，因為它比我預期的完整。

repo 裡有一份完整走過的變更提案，理由寫得很清楚（原文大意）：

專案長期演進後，根目錄累積過多腳本、預覽產物與一次性工具，增加搜尋成本、誤提交風險與維護負擔。

它產出四份 MUST/SHALL 要求：

1. 根目錄邊界治理：根目錄必須維持低雜訊入口區
2. 產物與暫存檔治理：可重建的產物必須輸出到指定目錄，且必須被忽略
3. 腳本生命週期治理：必須維護 active / legacy / archive-candidate 三態標記
4. 可量化熵減驗收：必須定義並追蹤 KPI

而 KPI 是真的有在追：

下一個里程碑：根目錄腳本 ≤ 10。

還有一份月度 27 項檢查清單，其中一條直接命中 AI 垃圾：

是否存在無用途的 *_v2、test_*、temp_* 根目錄檔案？

這是這條產線上治理做得最完整的一塊：有規格、有 KPI、有基線、有檢查清單。

.gitignore 裡有一份 AI 垃圾清單

.gitignore 有一段標為 "entropy-control baseline"，而它的 pattern 讀起來就是一份 AI 協作副產物的目錄：

tmp_icon_*.png      # 臨時生成的圖示
*.tmp.png           # 中間產物
*.preview.png       # 預覽圖
*.bak-*             # 改檔前的備份
*_render.log        # 渲染日誌
build/*
__pycache__/

每一條都對應一種「跑一次就丟」的東西。而它們會被生出來，是因為AI 協作的工作方式就是「先做一個看看」：先產一張預覽、先備份一份、先寫一支驗證腳本。

那些「先」，全部會落在磁碟上。

規則沒接住的部分

現在講難看的。

一、規則寫得太晚，垃圾已經被追蹤了。

.gitignore 有 *.bak-* 跟 *_render.log，而 git 裡仍然追蹤著 8 個備份檔跟 4 個 render log。

因為 .gitignore 不會 untrack 既有檔案，它只擋新的。

而那 4 個 log 裡，一個是 0 byte 的空檔，另外三個位元組數完全相同（同一個腳本跑三次的輸出）。

二、有些東西根本不在規則裡。

.DS_Store 不在忽略清單（磁碟上 38 個）、macOS 的 AppleDouble 檔也不在。有一個集數目錄裡甚至有一個內嵌的 git repo。

三、資料檔快照無限複製。

6 份不同時期的資料檔快照，被追蹤在不同的集數目錄裡。

2.2 MB → 2.8 MB → 2.8 MB → 5.2 MB → 5.5 MB → 5.8 MB，單調成長、內容互不相同。

合計約 24 MB 的近似重複 JSON，永久留在 git 歷史裡。

而它們為什麼在那裡？因為 Day 27 那個「整包複製上一集」。 資料檔剛好在那個目錄裡，所以它被複製了，然後被 commit 了。

複製式初始化的成本，最後是以 repo 體積的形式付掉的。

四、AI 生成物的原始檔名沒改。

一個目錄裡有一張 8.25 MB 的圖，檔名是生圖服務給的亂數字串。它從產生到現在一個字都沒改過。

五、最大的一塊，而任何治理文件都沒提到。

根目錄有 30 個以上不同 AI 編碼工具的設定目錄。

多數建立於同一天，內容高度重複：同一份 skill 文件，在四個不同工具的目錄下各有一份完全相同的副本。同時根目錄還有三份說明同一個 repo 的 AI 指引檔。

而 Day 16 講過：那三份指引裡，有一份少了一整個步驟。

副本越多，分岔越快。而這件事沒有出現在任何一份 hygiene 文件裡，因為那份文件是在盤點「腳本」的時候寫的，而這些目錄不是腳本。

六、壞掉的自動化入口。

有兩支自訂指令，它們呼叫的腳本根本不存在。跟 Day 11 那顆按鈕一樣，做了、壞了、留著。

七、跨機器路徑污染。

兩份剪輯記錄裡的素材路徑，寫著另一台機器的使用者家目錄，還帶著另一個 repo 名。

為什麼規則接不住

把這七項排開看，共同點是：

.gitignore 只擋 git，不擋磁碟。月度檢查清單是人工的。

前者處理「不要進版控」，後者處理「定期打掃」。而兩者都不處理「為什麼會一直生出來」。

而我認為真正的來源在 Day 27：整包複製上一集。它每一集複製一次，把上一集的所有殘留原封不動帶進來，然後我在新目錄裡又生出新的。

這是推論：我沒有辦法證明那 6 份重複快照是複製動作帶進來的，我只能證明它們分別躺在不同的集數目錄裡、內容互不相同、而那些目錄都是複製出來的。因果關係是我補的。

清理規則追的是症狀，而症狀的產生速度比清理快。

代價

這篇列的七項，我一項都沒處理。

而它們的處理成本差很多：

• 備份檔跟 log 被追蹤 → git rm --cached，幾分鐘
• .DS_Store 沒被忽略 → 加一行，幾秒
• 30 個工具設定目錄 → 這個要決定「我到底要支援幾個工具」，那是一個判斷，不是一個指令
• 24 MB 重複快照在歷史裡 → 要改寫歷史，跟 Day 11 那組金鑰同一個難度

第二個代價，比較根本：我的治理規格盤點的是「腳本」，而最大的一塊不是腳本。

那份熵減提案很認真地盤了 24 支根目錄 Python 檔，把它們標了三態、追了 KPI、從 24 降到 15。

而同一個根目錄裡，30 個 AI 工具設定目錄安靜地躺著，從來沒有進過任何一份清單。

盤點的邊界，決定了你會發現什麼。 而我當初盤點的邊界，是「我當時覺得亂的那一類東西」。

帶走什麼

.gitignore 只擋新的。

寫規則之前已經進版控的東西，不會因為你加了規則就消失。加完規則要跑一次 git rm --cached，否則那份規則是半殘的，它讓你以為問題解決了，而舊的還在。

第二條，關於 AI 協作的副產物：

AI 的工作方式是「先做一個看看」，而那些「先」全部會落在磁碟上。 預覽圖、備份檔、驗證腳本、臨時 HTML，它們的產生速度比任何人工清理都快。

所以 ignore pattern 要在導入 AI 協作的第一天就寫，不是等亂了才寫。而且要寫成 pattern（*.preview.png），不是逐個檔名，因為你猜不到它下次會生出什麼。

第三條，也是這一天最刺的一條：

盤點的邊界決定你會發現什麼。

我很認真地盤了腳本，於是我解決了腳本的問題。而 30 個工具設定目錄、24 MB 的重複快照、一個內嵌的 git repo，它們不在我當初畫的那個圈裡，所以它們不存在。

下次做這種盤點，值得先問一句：我這次要盤的是「哪一類東西」？那不在這一類裡的，誰在管？

明天講另一種垃圾：那些寫得很完整、然後一次都沒再用過的方案。