網站都在線上，原始碼卻不在手上：第一週回顧
7月27日到8月2日這一週，帳面上是衝刺週，A 站的稅籍名稱搜尋擴充到1,824,891筆，8月1日一天就有7組新網域網站上線。但把七天的紀錄攤開，反覆出現的是另一件事：每次要修改網站，手上的原始碼總比線上少一截。到了週末已經很清楚，對不少網站來說，線上那一份才是唯一完整的版本，而放著其他版本的那台筆電，最後連開機都出了問題。
要改網站時，本機總比線上少幾頁
我們在部署前有一道檢查：新版本建好後先和線上的網址清單比對，少任何一頁就不准上線，我們叫它零流失檢查。這週它一再被觸發。7月28日替其中一個資料站做搜尋優化，本機建出40,152個網址，線上卻有40,180個，缺的28頁找不到來源可重建，這一版因此被擋下，當天稍晚換成與線上等價的版本才上線。同一天B 站改版，建置程式（把資料和版型組成網頁的程式）少了10個必要檔案，文章只有60篇，線上卻有123篇，最後只換掉3個設計檔，其餘沿用線上版本。7月29日C 站完整重建時，才發現正式來源少了58篇既有文章。
7月28日另一項盤點說得更直白：57個資料站都能在部署平台找到正在服務的正式版本，卻只有1個能對應回版本控制（記錄每次修改的系統）裡明確的某一版，多數網站答不出線上跑的是哪一版。
三種讓原始碼悄悄變少的機制
第一種是同步資料夾留下的空殼檔。不少專案放在有iCloud同步的資料夾，檔案看得到，內容卻可能只在雲端，本機只剩佔位的空殼。7月27日其中一個候選網站的專案共133個檔案，74個是空殼，連續三輪要求下載，進度從5.0%爬到5.85%就停住。8月1日追到的原因之一，是某個專案裡的建置快取塞爆了iCloud的同步佇列，待掃描項目積壓了143到174小時。
第二種是在空殼狀態下做的快照。7月24日為了搶救建置程式庫，把整個工作目錄做了一次快照提交進版本控制，許多還是空殼的檔案就被記成已刪除。8月1日的鑑識結論是：這次快照波及8個以上的網站群、842個原本有追蹤的檔案，是被動的意外，不是有人刻意刪除。到了8月2日，842個裡仍有623個沒有回到最新版本。
第三種是從不完整的副本重建。7月31日追查一批網站流量統計為何歸零，發現9個網站的追蹤碼真的不見了：7月18日一次家目錄搬遷弄丟了32個分析設定檔；後來從缺檔的副本重建網站時，建置程式找不到設定就靜默略過，追蹤碼跟著消失，沒有任何錯誤訊息。同一天才發現，登記的64個網站只有31個有這份設定檔，而建置程式至少有三份內容不一致的副本。
三種機制指向同一個根源：原始碼集中在一台筆電、分散成好幾份，其中不少放在會自行清空本機內容的同步資料夾，而平常沒有流程會拿它們和線上比對，問題要等真的要改網站時才冒出來。
7月30日晚上，候選專案資料夾整批消失
這週最痛的一次在7月30日。那天傍晚，34個候選專案（約15.8GB）已在外接SD卡留有備份，並用SHA-256（檔案的數位指紋，能確認內容一個位元都沒變）讀回核對過，準備刪除以騰出空間；其中6個還有未提交的修改先排除，剩下28個送出申請，卻被7月27日才上線的刪除規則整批擋下：工作區以外的檔案不准由AI刪，附上核准也一樣。
當晚20:10左右，同一個資料夾底下幾乎所有子資料夾都不見了，83個項目進了iCloud垃圾桶，本機可用空間從3GB跳到23GB。起因是在Finder全選後移進垃圾桶，iCloud又為了節省本機空間迅速清掉副本，兩件事疊在一起，並不是哪個AI工作階段的動作。本機與iCloud的垃圾桶、網頁版的最近刪除都找不回來，也沒有設定Time Machine，只靠一個還在執行的背景複製程式救回2533個檔案、共1.2GB。
結果這28個專案因為SD卡上有核對過的備份，內容都還在；幾個還有未提交修改的專案，加上好幾個從未備份過的候選網站，判定大機率真的遺失，其中包括當時以為唯一的一份候選網站原始碼。8月1日凌晨才確認，一個約15G、原本只當舊封存的iCloud資料夾，其實是那個資料夾在7月20日的快照，這個網站的664個檔案才從裡面找回。規則管得住AI助手的刪除指令，卻管不到Finder裡的一次全選，也管不到同步服務何時清空本機內容。
把線上網站當成備份，反向取回正本
既然線上最完整，這週後半我們把方向反過來：不再拿本機副本覆蓋線上，而是從線上取回正本。7月31日修復追蹤碼時第一次這麼做，直接向部署平台下載現行正式版的原始檔案包，核對雜湊值（檔案指紋）後只補上追蹤碼再上線，原則是以線上為準、不准拿舊副本回滾，遺失追蹤碼的9個網站全數修好。同一天另一批修復在部署本機版本前，先逐字比對它是不是線上正在跑的那一份，擋下3次差點部署錯版本的情況。
8月1日這套方法擴大成一整天的搶救。替15個網站改寫搜尋摘要（搜尋結果下方那段說明）時，有10個被零流失檢查擋下，原因都是程式庫缺了線上已有的內容。其中一個網站的判斷規則直接從線上的程式檔解析回來，與線上逐位元組相同，鄉鎮對照與氣候資料則從368個行政區頁面逐欄讀回，重建後444頁與線上一致；C 站57篇文章從快照前的版本還原；B 站63篇文章中，54篇取自快照前的版本，9篇取自一個沒有程式在用的舊目錄，最後123篇與線上逐篇一致。
有些檔案連版本控制都沒進過。一個網站21條城際路線的資料、另一個網站3篇文章、還有一個網站10個缺檔中的9個從來沒被提交過，只能從線上頁面反推或到別處找回。D 站3篇文章的殘存副本全是空殼，最後在當初寫稿的AI助手對話紀錄裡，找到它寫入檔案的那次操作，大小和空殼標示的14350位元組吻合。這些還原都和線上比對到位元組層級才算數；8月1日完成的幾批陸續提交進GitHub（存放程式碼的雲端版本庫）的主線，8月2日的幾批停在等待批准。
追下去，我們也看到自己造成的缺口。7月28日A 站上線的100篇知識文章是直接寫進部署包的，從沒進過建置程式；8月2日才發現線上有134篇、程式庫只有34篇，若照程式庫整站重建，100個已開放收錄的網址會變成404（頁面不存在）。改得快是AI助手的長處，但每次繞過原始碼直接改線上，都讓兩邊多拉開一點距離。
補救本身也出了錯
搶救手法同樣會製造缺口。追查D 站的失效連結時發現，7月27日有一次重新打包，是照網址清單逐條抓取線上頁面來組部署包：7月18日那一版的營地頁有1807個、檔案總數2193，這次營地頁剩1502個、檔案剩1879，少了313個檔案。抓到第794條後開始被限速，失敗率從11%爬到44%；凡是不在網址清單上的檔案，像程式檔、搜尋資料和沒掛在首頁的文章，更是一個都沒抓到。線上因此有305個營地頁回應404，到8月2日還沒補回。
其中一個網站則是我們自己的誤判。8月1日為了讓網址清單誠實，我們在複製網站時量到2,489個網址回應404，就把它們從清單拿掉，清單從5,565條縮成3,076條。隔天追查部署歷史才確認，7月19日那次部署的673個長照頁、1941個服務頁都真實存在，已在線上服務13天，量到的404出在服務層，並不是內容消失。8月2日把這些頁面全數取回，5565個網址逐一重測都正常。
這些和前面的缺口是同一個病：以線上為準時，只要取回線上內容的管道會漏，漏掉的部分就被當成本來就沒有。零流失檢查也有盲點，它只比網址清單，清單以外的程式檔、資料檔和刻意不收錄的頁面少了，它看不出來。8月2日A 站兩個不收錄的情境頁從線上消失，主要懷疑是當天一次整站重新部署把它們蓋掉，當天還沒證實。
磁碟一路見底，週日筆電開不了機
這一切都壓在同一台筆電上，它的磁碟整週都在紅線附近。7月29日深夜封存資料到SD卡時，可用空間掉到121到140 MiB，只能停下所有寫入；7月30日A 站重建資料庫，工具在可用空間剩3.0GiB時自行中止；7月31日晚上只剩2.6GB，經xmy批准刪掉25個核對過的路徑後回到36G。8月2日下午，可用空間又只剩12Gi、使用率98%，比前一天少了大約47GB，當天沒找到去向。
同一天，這台Mac當機後就開不起來，一般開機和安全模式都失敗，最後是在macOS復原模式用終端機救回：存放帳號資料的磁區還在加密上鎖、沒有掛載（系統讀不到），解鎖掛載、確認資料都在之後重新開機，才回到桌面。事後的復盤報告判斷，最可能是好幾個AI與開發工具同時運作，記憶體和磁碟暫存一起吃緊，系統因此失去回應；由於沒留下當機紀錄，無法百分之百斷定。開機後可用空間是47 GiB，使用率約89%。
報告替這台電腦訂了磁碟水位：可用空間80到100 GB以上，才適合同時跑大型AI工作和多個AI助手；低於40 GB就該停下重工作，先備份、清理。
這週系統改了什麼
制度上的變化，多半是被這些事逼出來的。7月27日訂出正式的刪除治理：任何AI助手刪檔前都要過檢查，工作區以外的路徑一律不准刪。7月28日B 站的建置程式加上門檻，文章少於123篇就拒絕輸出。7月31日則以7月24日那份版本控制健康的搶救快照為底整併副本，補回快照漏收的495個資料檔和30個網站的分析設定檔，推上GitHub後把主線定為建置程式唯一算數的來源，並規定建置和部署只能從這份權威副本出發。
8月2日再把兩條教訓記成部署的固定注意事項：重新打包線上網站只能向平台取回原始部署檔案，不能照網址清單抓頁面；驗收時新舊檔案集合必須一個都不少，不能只看網址清單相同。
給想用AI經營網站的人
回頭看，這週多數事故的起點不是某段程式寫錯，而是沒有人能肯定哪一份才算數。AI助手能在一天內替十幾個網站改版、補文章、上線，但原始碼如果缺頁，速度只會讓缺口更快上線。我們最後倚靠的是一道很樸素的檢查：上線前拿新版本和線上逐頁比，少一頁就停。
如果你也用AI經營網站，有幾件事現在就能檢查。每個網站都要答得出線上跑的是哪一版，並且能從一份乾淨的副本重建出和線上相同的結果。程式碼別放在會自行清空本機內容的同步資料夾，同步不是備份，空殼檔會讓建置在不報錯的情況下少東西。為了快而直接改線上的每一次捷徑，都要把改動收回原始碼，否則下一次整站重建就會把它抹掉。
最後是實體的限制。一台筆電同時扛著上百個網站的原始碼、好幾個AI助手的工作、同步服務和建置快取，任何一項滿載都會拖垮其他項。7月30日真正保住資料的，是放在電腦以外、核對過指紋的備份；8月2日筆電開不了機時，救援中最關鍵的確認點也是資料還讀不讀得到。把正本和建置工作搬離單一一台電腦，是這一週留給接下來的功課。
相關事件報告
一人公司如何把本機開發搬到雲端：23 天實戰公開版
8 月把網站群從一台筆電搬到雲端的 23 天逐日整理（公開匿名版）：找回程式正本、乾淨環境重建、不可覆寫的發布與外部讀回驗證，以及七種常見遷移陷阱。
Mac 無法開機事件復盤與預防報告
高負載 AI 開發讓記憶體與磁碟同時吃緊，Mac 連安全模式都進不去。從 macOS 復原模式的終端機解鎖、掛載資料磁區救回，並整理原因分析、名詞白話字典與救援 SOP。
這一週的每日日誌
掉頁全數復原，深夜硬碟卻無故少了 47GB
一個網站確認前一天的sitemap修復其實是誤判，5565頁全數復原並補上長照總覽頁；另一個網站兩個404追出舊部署方式會漏傳沒列在網址清單裡的檔案；八堂課八站上線後，深夜硬碟可用空間從59到64Gi暴跌剩12Gi，原因未查明。
一次不完整的快照，十幾個網站的遺失檔案一次修完
喵宇宙這天查明一次舊快照造成的資料遺失，搶救十幾個網站的內容，同時完成7組新網域上線與一個網站官方名冊功能。
GA追蹤碼在13個網站消失，一天內修回9站
喵宇宙這天修好連續6天失敗的日報排程與13個網站的GA追蹤碼消失，完成40站稽核並修復十四站問題，磁碟空間探底後清出36GB。
防爬蟲觀察名單上線，深夜一個資料夾卻整批消失
喵宇宙這天上線防爬蟲觀察名單、完成67站健康稽核，四個網站同步公開（其中一個是剛改名的）；深夜一個從未備份的候選專案資料夾卻整批消失，只搶回一小部分。
8.27分鐘500次請求，資料庫扛不住
一個網站在8.27分鐘內被自動化請求打了500次，另一個網站的追蹤程式碼也在93.3分鐘內打出499次同樣的請求；兩者都靠加上快取與行為門檻解決，我們也趁勢盤點了86個網域的流量。
一次補齊 1,824,891 筆稅籍搜尋
一個網站這天一次補齊1,824,891筆稅籍資料並開始分批送進搜尋引擎；另一個網站的回報與會員功能因為環境設定沒配好接連故障，修好後才恢復正常；還有一個網站也帶著官方名冊正式上線。
iCloud 卡住一個專案，喵宇宙立下刪除新規則
一個網站的資料庫卡在iCloud三輪都沒修好，只好用舊版本救回上線；喵宇宙也在這天訂出正式的刪除把關規則，並且擋下一個原本已核准、範圍外的刪除指令。