這個題目是訂閱區的歐陽醫師許願的。他說得很準：認真看 AI 運行的資料夾，好像都才幾十 MB，但是電腦容量就是被吃掉一大半。
這件事我自己也遇到很多次了。我的 C 槽 953 GB，過去一個多月每隔幾週就快滿一次，每次都是跟 Claude 說「幫我清理」，清完過陣子又滿回來。這次我們不清了，改成把一個多月來每一次清理的對話全部翻出來對帳，算清楚是誰一直長回來。
查出來四層，照體積排序。其中一層是我們自己開源出去的工具，這個下面會老實講。
一、雲端同步：檔案被讀一次，就永久回到你的電腦
這台電腦的 OneDrive 雲端有大約 400 GB。檔案設成「僅雲端」之後，檔名在、圖示在，不佔空間。但只要有任何程式打開那個檔案，同步軟體就會把它下載回本機，而且除非你自己把它釋放回雲端，它就會一直佔著空間。
八月十七號那次大掃除清出 382 GB。四天後回頭看少了 56 GB，其中課本 PDF 那幾個資料夾自己回到本機 45 GB。
這件事的怪，怪在因果被切斷了。吃掉容量的那個動作，跟長出來的那些檔案，看起來完全沒關係。你翻遍 AI 的資料夾，當然只有幾十 MB。
我們怎麼把它抓出來的
這一段是這篇最想分享的：不是我自己會查，是我跟 Claude 一起把範圍縮小的過程。
第一步，先問清楚機制。 我請他上網查「OneDrive 在什麼情況下會自動把僅雲端的檔案下載回本機」。查回來的答案是：只要有程式開啟那個檔案就會，不必真的讀內容。這一句話後來就是破案關鍵。
第二步，一個一個排除。 每關掉一個嫌疑犯就重新量一次本機佔用：
- Windows 搜尋索引：停掉六分鐘，佔用沒變化
- 檔案總管縮圖、防毒掃描、Google Drive、iCloud、Synology Drive：都排除
- OneDrive 自己重抓：手動把二十個檔案標成「釋放空間」，六分鐘內一個都沒有被抓回來
排到這裡，OneDrive 本身的嫌疑就洗清了。它只是執行者，不是發動者。
第三步，我提了一句話，方向就轉了。 當下我們一直在找「現在正在跑的東西」，可是我想到：這些下載搞不好是幾個小時前下的指令留下來的，那支程式可能還活著，只是沒人注意。
我把這句話丟給他，他回頭去翻還在執行中的舊程序，當場抓到兩支：
- 下午五點二十某個 AI session 下的
find指令，尾巴接了head，本來只要前二十筆。head 拿夠了自己結束，前面的find卻沒有跟著死，一路跑了五個小時，回抓 19 GB - 抓它的同時，另一個 session 又下了一支掃全機的
find，三分鐘再吃掉 6 GB
兩支都殺掉之後，回抓當場歸零。
原因就是第一步查到的那句話：find 為了分辨走過的東西是資料夾還是檔案，會把每一個項目都開起來看一眼。它不讀內容，但在 Windows 上，開啟一個僅雲端的檔案本身就等於送出一次下載請求。掃過去，就抓下來。ls -R、grep -r、du 也一樣。
這條線在一般的量測下完全看不到：find 只開檔不讀內容，它自己的讀寫幾乎是零，所有下載流量都記在 OneDrive 頭上，看起來就像雲端硬碟自己在亂抓。真的要指認元凶，得開系統層級的檔案存取追蹤才看得到是哪支程式開了哪個路徑，這個細節就不展開了。
停掉那兩支之後，再讓 OneDrive 把積壓的「釋放空間」標記處理完，那四天流失的 56 GB 全部回來了：本機佔用從 63.4 GB 掉到 14.1 GB，可用空間從 472 GB 回到 528 GB。
預防勝於治療：這種事不能靠「請它記得」
抓到兇手只是止血。真正的問題是：下次還是會有人下同一種指令。
我一開始的想法是把規矩寫進它的記憶檔，或包成一支腳本。我們討論的結論是這條路沒用，因為記憶檔跟腳本的失效模式一模一樣，都要它先「想起來」才有用。這件事我在讓 AI 自己調查自己為什麼一直犯錯那篇寫過，這次又驗證了一次：這個晚上讀完規矩三分鐘後，它就又下了一支會掃到雲端資料夾的指令。
所以改用三道關卡，前兩道不必它記得：
- hook（在它動手前攔下來）：它要下指令的那一刻，我的程式先檢查，掃到雲端資料夾的寫法直接被擋掉。這不是提醒它別做，是那一次真的送不出去；它會知道自己被擋、可以改用別的方法，但會掃到雲端的那條路已經封起來了（機制細節在我怎麼跟 AI agent 講話）
- 定期巡邏：每三十分鐘巡一次，殺掉已經跑超過二十分鐘的掃描程序。萬一有漏網的，下一輪就會被收掉，不會像那天一樣跑五小時
- 所有背景指令一律包 timeout：這條是規矩、不是機器擋的，我本來就有，就是為了避免沒人管的程式越堆越多。曾經有一次背景堆了 239 個 python 程序，吃掉 92 GB 記憶體，整台電腦卡死
如果你也用 AI 幫你在電腦上找檔案，而且雲端硬碟開了「僅雲端」，這三道關卡比事後清理有用得多。
二、我們自己開源的工具（已經修好）
這個要老實說。
我們開源的筆記語意搜尋工具 vault-search，底層用的資料庫有一個特性：每改一次資料就留下一個可以回溯的舊版本，舊的資料片段要主動叫它清才會消失。我們的索引程式從頭到尾沒有叫它清。
於是索引每天更新，舊版本每天堆。我這台實測下來：
- 八月十六號那天，光課本索引那張表就累積了 51 個舊版本、吃掉 13 GB，把 C 槽壓到只剩 3.3 GB
- 最尷尬的是同一天，連「壓實」這個清理動作本身都因為沒空間而失敗（壓實需要暫存空間），變成想清也清不掉，只能先去別的地方挪空間出來
- 八月二十一號我把所有表一起清一次，9.42 GB 降到 4.52 GB。一列資料都沒有少，少的全是舊版本
這裡要多提一句：如果你是照 textbook-to-note 的說明去建課本資料庫的，也是同一個洞。那份說明會請你把索引工作交給 vault-search 的課本索引器，而那支索引器有同樣的問題，v2.8.0 是兩支一起修的。
如果有朋友在用這些工具，要跟你說聲抱歉，你電腦一直變小可能就是它造成的。你可以直接請你的 agent 查一下底層的 LanceDB 資料夾是不是一直膨脹，確認之後升級到新版，再跑一次索引就會清掉。
已經修好了：v2.8.0 之後，索引跑完會自動清掉舊版本，我這台當場清出 4.9 GB。有在用的朋友升級再跑一次索引就會瘦回來。
這件事還有一個延伸的體會。用 AI 做工具，從零到能跑真的很快，但很多設計不良的地方要等實際用一段時間才會冒出來，這個「舊版本沒人清」就是典型：程式沒有壞，測試也過，它只是在你不看的地方慢慢長大。所以回頭修正是必修課，而且比較好的做法是一開始就用 SDD（spec-driven development，先把規格寫清楚再讓 AI 照規格實作），遇到這種結構性的問題，照規格重做有時候比修還快。這部分展開講會是另一篇，有興趣的話可以先自己搜尋 SDD，或是留言跟我說，我再寫。
順便講一件跟這個直接有關的事：工具修好了，你手上那份不會自己知道。 從六月底開源各個工具到今天，這些工具一共出了 112 個版本，而我發文介紹過的只有二十幾次。如果你是看到某一篇貼文才去下載的，你手上那份大概就停在下載那天。所以更新清單我固定放在訂閱區，每個月整理一次，哪個工具改了什麼、要不要回去重抓，一次講完。
三、對話逐字稿
每一次跟 AI 的對話都會存成檔案留在你的電腦。我這台目前累積 5.8 GB，大約每個月長 3 GB。Claude Code 有個設定叫 cleanupPeriodDays，預設保留 30 天。
這裡有一個容易被忽略的來源：派出去的分身（subagent）也在寫逐字稿，而且寫得比你想像的多。我把整台兩千多個逐字稿檔案量了一遍：5.8 GB 裡有 4.7 GB 是分身寫的，超過八成，不是我跟主對話講的話。你叫它「找一下這件事」，它派三個分身出去查，三份完整紀錄就都留在你硬碟上。
我自己反而把保留期調成 90 天。舊對話是回頭查「當初為什麼這樣決定」的原料，這整篇的辦案過程，就是靠翻兩個月前的對話破的。留久一點的代價是那些檔案都是明文，你貼進去的東西也在裡面，敏感資料本來就不該讓它讀到。
四、模型跟套件的快取
在自己電腦上跑模型的人這層最有感：ollama 模型 13 GB，Python 工具鏈的快取 20 GB。它們不屬於任何一個專案，所以你翻遍專案資料夾都找不到。
npm、pip 的快取刪掉會自己重新下載，容量不夠時可以放心刪除。模型跟工具鏈的快取要多看一眼，正在用的工具可能就住在裡面，刪之前先確認。
一條判斷原則，四個動作
刪之前只問一句：刪掉之後能不能重建。
能重建的是產物，快取、舊版本快照、過期暫存，隨時可刪。不能重建的是你的東西，筆記、原始資料、轉錄稿，碰都不要碰。
四個動作，前兩個是預防，後兩個是清理：
- 雲端硬碟有開「僅雲端」的人，先擋掃描：這是最大的一層，而且會一直復發。裝上面那三道關卡，讓 AI 沒辦法拿掃描指令掃過你的雲端資料夾
- AI 工具的對話保留期，設一個你能接受的天數；會派分身的話，天數要抓保守一點
- 有在用 vault-search 的話，升級到 v2.8.0，跑一次索引
- 把清理排成每週自動跑一次：冷資料夾退回雲端、資料庫舊快照清掉、過期暫存刪掉。我現在就是這樣
有了這些之後，希望「幫我清理」這句話可以從我的常用語裡退休了。
至於電腦跑久了會越來越慢、非得重開機才會好，那是另一件事。我自己遇到的是記憶體的 commit 額度被吃光，跟硬碟沒關係，症狀卻很像。那條線我前幾天放在訂閱區講過了。