要求每站能從零重建，藏起來的缺口一一現形：第二週回顧
8月3日到9日這一週，我們把「上雲」的標準改得更嚴：網站要能在全新的機器上從程式碼重建出來，和線上逐條比對一頁不少，才算數。同一週，內容產線到8月8日累計55站、165篇。新標準加上這樣的速度，逼出了藏在各處、平常沒人檢查的東西：只存在AI對話紀錄裡的原始碼、只在這台Mac上才成立的建置條件、部署工具的預設行為，還有頁面上寫的和背後實際發生的落差。
「上雲」的及格線：從打得開改成重建得出來
標準訂得這麼嚴，是因為筆電撐不住。8月3日晚上，我們替前一天才開不了機的Mac做了一次清理，先列清單、輸入確認字才執行，可用空間從83 GiB回到123 GiB；但三天後，重建留下的暫存資料又把空間吃到不足1 GiB，8月7日凌晨一度只剩425MB。清理追不上建置，把建置和資料搬離筆電，成了這週的前提。
8月5日的盤點顯示，登記的65個網站入口有64個已由雲端平台服務，卻沒有一個能保證在乾淨的機器上重建出線上那一份。我們把標準寫成契約：每站在兩份全新下載的程式碼上各建一次，產物必須逐檔相同；再和線上現有網址逐條比對，一條都不能少；先發到不對外公開的預覽網址驗收，才切換正式網址，舊版留著隨時退回。任何一步不符就停下。第一輪跑完，14站通過上線，其餘51站因為資料缺口、建置程式（產生網頁的程式）跑不起來，或登記資料對不上而被擋下。
原本49站的待辦清單，8月5日收工時剩42，8月6日中午剩30，那時已有34個網站走完整套流程。8月7日這套流程第一次搬到雲端的建置機器上跑（只建置、不部署），34站中32站成功。它的價值在8月5日深夜就看得到：重建A 站時，新版網址清單和線上的8474條完全相同，但驗收發現另有56篇指南不在清單上、線上卻打得開，一換版就會全部消失。我們立刻退回舊版，補齊來源才重新上線，並把這56條網址寫成固定檢查，以後少一條就建置失敗。
缺的原始碼，最後在AI的對話紀錄裡找到
最常卡住重建的，是線上有、程式庫裡卻沒有的內容。其中一個站少了21條網址，其中9篇文章和三個互動工具，是從Codex 7月26日的工作紀錄裡，把它當時寫入檔案的內容原樣重播回來；A 站那56篇指南，54份來源在版本控制（保存每一次改動的系統）裡找回，另外2份從沒進過版本控制，只能從Claude的對話紀錄取出；另一個站的9篇文章散在3個不同的AI工作階段裡，逐篇核對後才收回。這些缺口有的來自上週提過的那次快照，有的是內容只在線上發布過、從沒寫回程式庫，例如B 站的3篇文章。
AI助手留下的完整對話紀錄，意外成了最後一道備份。連紀錄裡都找不到的，只能退一步：另一個站有21頁在整部版本歷史和對話紀錄裡都沒有蹤跡，最後是抓下線上已經產生的網頁，把內文原封不動接回建置程式。再找不回來的就不換版：8月7日一輪清查中，8個網站刷新上線，另外8個因各自的缺口或架構限制暫緩，維持線上不動，例如C 站重建後會少掉240個需要另外申請存取權限的捷運資料頁。
乾淨的機器，揭穿只在筆電上成立的條件
換到雲端的乾淨機器上建置後，一批在筆電上建置正常的網站開始失敗。其中一個站的建置程式要畫社群分享圖，用到一個只有這台Mac裝過的繪圖套件，還寫死了Mac專用的字型路徑，所以本機紀錄一直是成功；改成先把7張圖畫好收進程式庫，乾淨環境才建得起來。另一個站的建置程式每跑一次，就用當天日期改寫一個受版本控制的資料檔，被「建置不得改動自己的程式碼」這道檢查擋下。D 站的建置會重寫一個資料庫檔，在Mac上產出的位元組剛好和存檔一致，在Linux上就不同；8月9日補齊的5張本機建置紀錄，送上雲端的第一站就翻掉一張。
多個AI同時動手，出事多在交界處
內容產線同時在衝刺：每站加3篇回答讀者實際問題的文章，交給沒參與撰寫的AI對照官方原文驗收。驗收攔下不少讀來通順、卻和官方規定不符的內容，例如D 站一篇甄試文章，整篇建立在16年前就廢止的規定上。另一個問題是底稿：E 站原本以本機資料夾為底，送審才發現本機少了線上後來加上的整組法律頁面；8月8日逐站比對13個網站，本機和線上的檔案數沒有一站相同。之後一律直接向部署平台取回線上正在跑的那一版當底稿，只在上面加東西。
逐字比對也有看不見的地方。8月7日替另一個站插入文章卡片時，插入點落在一個既有連結標籤的裡面，形成連結包著連結；瀏覽器自動修正後，11張卡片在畫面上排版全亂。但拿掉新內容後，其餘位元組和線上完全相同，逐字比對判定沒問題，是驗收者改用瀏覽器實際渲染才看出來。從此每次插入後都要檢查標籤的巢狀層數，當晚另一個網站再犯同樣的錯，在寫入當下就被攔住。
平行作業是另一個交界。8月8日替各站補AI揭露句（標明文章由AI協助製作的說明）時，重建出來的資料夾少了指定部署專案的設定檔，部署工具沒有報錯，而是用資料夾名稱自動開了一個新專案，結果30個網站的網域全被導到那裡；驗收條件全過，直到其中一站突然出現登入頁才察覺，之後逐站改回正確的專案重新部署。同一天另一批9站在部署前比對線上現況，發現其中8站稍早已被另一個工作階段重新部署過，照原計畫上線就會倒退回舊版，於是放棄這8站的部署。部署工具還有另一個預設行為要提防：8月9日至少三次明確指定發到測試環境，新專案的第一次部署仍被當成正式版，每次都是發現後先停手再處理。同一週也發現E 站被外部稽核工具打了 0 分：全站頁首導覽連到的「分類檢查」頁其實從未真正部署上線，4,051 頁裡有 4,035 頁因此被判定為錯誤；頁面本身早就寫好，修復只要重新部署，但那需要人工授權，當週只完成診斷。
8月8日翻出的舊傷，和頁面上對不上的承諾
8月8日的一連串追查，先翻出一批舊傷。F 站7月31日一次只為補一段摘要的重新部署，用了不完整的底稿，正式版從542個檔案縮成371個；G 站在同一天補追蹤碼的重新部署之後，292頁裡有108頁打不開；H 站的轉址設定也從8月1日那次部署起就不見了。這幾件都發生在我們把「重新打包要以平台上的原始檔為準」寫成規則之前。G 站和H 站當天就補回；F 站修好後，同天下午xmy換上只有7頁的新版，178個舊網址沒有轉址，要不要補當天未定。
更要緊的是網站對讀者說的話和實際狀態對不上。追查H 站時，我們發現本機和線上差了約4600個網址，其中有曾經上線、後來被蓋掉的內容，例如81頁長照廠商名錄和1543頁的外籍看護仲介評鑑資料，當天還原上線。我們也在資料庫裡找到7筆7月中到月底民眾送出的長照諮詢，因為審核後台從未部署，很可能沒有任何人看過；表單收得到資料，另一端卻沒有人接。這7筆已整理給xmy，待逐一回電，當晚也替這個網站補上隱私政策等五個說明頁。
另一個站有124篇用藥文章，頁面上都標明是尚未經醫療審閱的草稿，卻沒有不收錄標記（要求搜尋引擎不要把頁面放進搜尋結果），而且都在提交給搜尋引擎的網址清單上。xmy同意先補上標記、移出清單，不刪不改內容；處理時首頁也被一併標記，隔天複查發現後改回。真正的藥師或醫師審閱，當時還沒有發生。
AI揭露句也有同樣的落差。8月8日，一個工作階段替55個網站的文章補上揭露句，寫著經人員審閱後定稿；另一個工作階段對照內容政策後認為，這對早期批量整理的文章是站不住的宣稱。最後統一改成不宣稱人工審閱的中性句，55站替換了5,236處，另新補12站1,742頁。8月9日有6站先上線「AI使用政策」頁，照實交代查核程度，例如B 站寫明110篇文章沒有一篇經過逐篇覆核。同一天也發現，其中一個站有73篇文章在頁尾標示人工審閱日期，但日期只有兩種，其實是建置時間，其中70篇在同一頁又聲明未經逐篇覆核；這一點先回報給xmy，處理方式未定。
8月9日：帳單上限讓自動測試全面停擺
建置和驗證搬離筆電，瓶頸也跟著換了地方。8月9日凌晨起，帳號下12個程式庫的每個自動作業都在啟動兩秒後結束，失敗訊息指向扣款失敗或花費上限不足，xmy調高上限後才恢復。事後拆帳，這不是異常燒錢：主要的程式庫8天跑了1,106次作業，自動測試和畫面比對佔83%。浪費來自合併規則：每條改動分支必須先跟上主線才能合併，卻沒開自動合併，幾個工作階段同時推進時，同步一次就重跑一整套、跑完又落後；8天裡分支上的測試跑了242次，真正合進主線的改動只有56個，平均每個改動跑4.3輪。當天先做了三項調整，約省下當月帳單的11%；要不要改成自動合併或排隊合併，列為待xmy決定的事項。
這週多出來的檢查
地址、公司、交通、藥品四份共用資料，這週都發布到雲端物件儲存（存放大型檔案的雲端空間），每次發布留下收據；網站建置直接讀已發布的版本、不准退回讀本機檔案，筆電上的程式碼副本縮到25MiB、不含任何資料庫。部署前先寫好指定專案的設定檔，並比對線上是否剛被別人更新；驗收除了看內容，還要確認實際在服務的是哪個專案。
如果你也用AI經營網站
這一週最大的轉變，是把「完成」的定義從線上打得開，改成在別的機器上能重建出同一份。這個定義很費工，擋下的卻都是真問題：A 站的56篇指南、C 站的240頁、只有這台Mac才有的繪圖套件和字型。本機建得起來不代表什麼，換一台乾淨的機器再建一次，才知道手上到底缺了什麼。
其次，讓AI寫下的每一份內容都回到程式庫。這週好幾次救回內容，靠的是AI助手留下的對話紀錄，但那是剛好留著，不是設計好的備份。如果你讓AI助手改網站，至少把這些紀錄保存好；更根本的做法，是不讓任何改動繞過程式庫直接上線。
最後，好幾個AI同時工作時，最容易出事的往往不是單一任務，而是交界：幾個工作階段同時碰同一批網站、部署工具的預設值、帳單上限，以及頁面上的說法和背後流程之間。30站網域被導錯那次，驗收條件全部通過；H 站的表單也一直收得到資料。檢查只會回答你問它的問題，所以除了確認內容對不對，也要確認是哪個專案在服務、表單另一端有沒有人在接。
相關事件報告
一人公司如何把本機開發搬到雲端：23 天實戰公開版
8 月把網站群從一台筆電搬到雲端的 23 天逐日整理（公開匿名版）：找回程式正本、乾淨環境重建、不可覆寫的發布與外部讀回驗證，以及七種常見遷移陷阱。
Mac 硬碟安全清理事件報告
無法開機的隔天，用「掃描、清單、人工確認、清理、驗證、留紀錄」的流程清掉 2,613 個可重建資料夾，可用空間從 83 GiB 回到 123 GiB，並把未推送的分支封存到 GitHub。
這一週的每日日誌
帳單額度用盡讓自動測試停擺近6小時
自動測試與部署系統因帳單問題停擺近6小時，波及所有專案；同一天AI使用政策頁陸續上線，卻在一個網站抓到73篇文章的人工審閱標記自相矛盾，另一個網站首頁也一度被誤下架搜尋引擎後修復。
衝到55站上線，也發現一個網站的求助信沒人回
這天內容產線衝到55站、165篇，審核多次攔下上線前的錯誤；一個網站後台躺著7筆沒人回過的長照諮詢，另一個網站125篇用藥文章緊急加註不給搜尋引擎收錄，自己的個人網站改版也讓178個舊網址變成404。
一天衝到42站、126篇，也踩到一次比對測不出的排版事故
一個網站一次卡片排版事故連逐字比對都測不出來，同一天我們讓交通與藥品資料集正式上線，救回另一個網站上有、版本庫沒有的內容，累計寫到42站、126篇，也抓到幾篇文章裡的官方數字錯誤。
雲端重建一天衝刺，清單從41降到30
磁碟一度只剩不到1GiB可用，靠反覆清理回升到約12GiB；雲端重建當天讓待辦清單從41個一路做到30個；十多個網站同時上新文章，審核多次擋下問題圖片與差點覆蓋掉的舊網頁；一個網站上線時也抓到一個計時側漏洞。
資料平台上線，雲端重建正式開跑：14站當天上線
資料平台第一版正式併入主線；全站盤點發現64個網站入口已經上雲卻沒有一個能從零重建；當天啟動零流失雲端重建，14站率先上線，原49站待辦清單收工前剩42；一個網站一度差點讓56個舊頁面消失，及時煞車修正。
兩個安靜的日子：報表校正與資料平台動工
8月3日晚間因應前一天Mac一度無法開機，做了一次安全清理釋放硬碟空間；8月4日完成18筆程式碼提交，搭建新的資料平台雛形，為之後的雲端重建鋪路。