29天26個倉庫：AI流水線中真正出問題的並非程式碼

一位開發者使用 Claude Code 在 29 天內構建了 26 個倉庫、1,549 次提交和 335 個頁面。該流水線採用靜態優先架構，所有內容部署到 Cloudflare Workers 的邊緣節點。每個會話都遵循相同迴圈：描述目標、讓模型規劃並構建、審查差異、讓模型自行驗證現場站點、然後提交。驗證步驟至關重要——下文中的每個失敗案例都是被檢查捕獲的，而非靠運氣。

真正出問題的地方並非語法錯誤、構建失敗或無法執行的程式碼。每個實際問題都是結構性的——在單獨的差異中不可見，只有從系統整體角度才能發現。

第一個問題是流水線自相殘殺。當要求構建一個單詞工具中心時，流水線愉快地在 /word-tools/ 下建立了一個，而現有工具位於 /tools/ 下。兩個頁面針對相同的查詢，導致了經典的SEO關鍵詞衝突。教訓是：模型針對你要求的頁面進行最佳化，而不是針對你已有的網站。

第二個問題是URL約定不一致。有些工具被構建為平面檔案（page.html），有些則構建為目錄（page/index.html）。在Cloudflare的靜態資產服務上，這兩者的尾部斜槓行為相反，導致網站積累了規範標記不匹配、兩次重定向鏈以及一批Search Console重定向錯誤。修復消耗了衝刺中最大的兩天提交量（各114次），並催生了一套書面URL約定和一個預部署爬蟲檢查器。教訓是：必須在第二個倉庫之前而不是第二十個倉庫之後寫下模型必須遵循的約定。

第三個問題是原始碼與生產環境悄然脫節。遊戲倉庫被映象到中心網站進行部署。數週內，SEO改進被應用於生產映象，但從未回傳到原始碼倉庫。陷阱在於：明顯“同步”操作——將原始碼複製到映象——會悄然破壞即時後設資料。只有在複製前進行差異檢查成為強制要求後才被發現。教訓是：同一檔案的任何兩個副本都會產生差異，除非強制進行比較，否則AI不會注意到。

第四個問題是驗證工具自身也會說謊。第一次連結圖譜審計報告了大量孤立頁面，但這是誤報：爬蟲比較了絕對URL與未解析的相對href。後來的一次規範審計報告了123個規範標記不匹配，這也是誤報，因為檢查器假設檔案路徑等於服務路徑，而CDN提供的是簡潔URL。兩次都是透過先探測現場站點然後才相信靜態分析才發現的。教訓是：驗證驗證者。AI編寫的檢查繼承了編寫它的AI的所有盲點。

經濟方面：衝刺產生了44個工作會話和826 MB的會話記錄。當審計token賬單時，發現約93%的token消耗是快取的上下文被一遍遍地重新讀取，這些上下文來自本應分割的長會話。解決方法是不花任何成本：在任務之間清除上下文，將持久知識儲存在小型記憶檔案中，下一會話可以在幾百個token內載入，並將“一次會話=一個任務”設為預設。

最後，該網站從257個有搜尋資料的頁面獲得了7,320次展示和207次點選。對於一個大約五週大的域名來說，這是一個正常、健康的軌跡。最大的流量來源是2048遊戲頁面，該頁面擁有可見的AI求解器——那裡有著最真實的工程。搜尋需求追隨深度而非頁面數量。

倖存下來的規則包括：釋出前進行可重複的基準測試；任何覆蓋檔案的操作都必須先進行差異比較；在信任靜態分析之前透過HTTP驗證生產站點；在擴充套件之前將約定寫入模型每次會話載入的記憶檔案；一次會話只做一件事；安排審計以檢查整個系統而非單個差異。