Boloop 閱讀示意圖（AI 生成）：從內容、訪問權限到日常運營，網站需要逐層補齊。

Boloop 是我記錄 AI 生圖、項目開發和個人 Agent 嘗試的地方，也收錄我推薦的软件、Skills 和閱讀。它的建設過程讓我逐漸看清一件事：頁面做好之後，還有很長一段路要走。

首屏能看、菜單能點，解決的是「東西出現了」。接下來更具體的問題是：我在這裡修改內容？保存後誰能看到？附件下架後還能不能登入？登入失效時，剛寫的文字還在不在？上線後，又憑什麼判斷有人真的用過它？

這篇按實際建設順序，記錄 Boloop 逐步補齊的幾段鏈路。它不是推薦所有個人網站都照著建設一整套後台，而是解釋我們為什麼走到了這些地方。

內容開始變化，頁面就需要一個穩定的數據來源

Boloop 有文章、软件和 Skill，後來又增加了作品案例。它們的公開信息不同：文章需要正文和作者，软件需要原項目入口，原創 Skill 可能提供下载，推薦 Skill 則需要保留第三方來源。

如果只把這些內容當成一組漂亮卡片，差別很容易被抹平。推薦别人做的软件，看起來像自己開發的產品；一次外鏈點擊，看起來像一次下载；一個空作者字段，又可能被模板自動補成站長名字。

因此，CMS 對我們首先意味著明確內容的分。界面從已發佈字段取得標題、摘要、作者和來源，未填寫的信息保持為空。後台保存的是正在編輯的草稿，公開頁面讀取的是已發佈快照。

這個區分解決了一個日常問題：我可以繼續改一篇已經上線的文章，而不讓讀者看到寫到一半的內容。早期隔離 browser 驗收中，我們實際改過草稿標題，再刷新公開頁，公開標題仍保持原樣；恢復歷史修訂時，也只恢復到草稿，沒有順帶重新發佈。

有了上傳按鈕，还要補上文件的完整生命週期

文章配圖和 Skill ZIP 都會經過上傳，但「服務器收到文件」只是其中一步。文件還需要通過格式檢查、關聯到正確資源，並隨內容狀態決定是否公開。

在早期隔離驗收裡，我們做過一條完整路徑：上傳測試 ZIP，保存關聯，發佈，再從公開頁面下载，比較下载文件與後台文件的 SHA-256。另一條反向路徑同樣重要：仍被草稿或已發佈內容引用的附件不能直接歸档；解除有效引用後，才能歸档；恢復附件也不會自動替內容重新關聯和發佈。

這讓後台裡的幾個動作有了各自清楚的含義。保存、關聯、發佈、歸档和恢復，不再只是幾個狀態相近的按鈕。

上傳出錯時，系統還需要保留輸入。我們在隔離環境注入過對象存儲故障，恢復後使用原表單和原文件重試。那是可控故障的驗收；後來遇到 browser 操作工具本身超時時，則必須保留「上傳結果未知」的判斷，不能把兩件事混為一次已解決的故障。

網站搬了地方，真實登入要重新走一遍

遷移到 Cloudflare Pages 後，構建產物能夠運行，並不能自動證明管理員能正常使用。

我們需要分別處理 Google 登入的回調、站點會話、管理員身份和後台接口權限。隔離測試能驗證「假定這個身份有效時，應用如何反應」，真實登入則要驗證 Google 返回之後，browser 是否建立了正確會話，普通賬戶是否仍被拒绝。

還有一個容易忽視的場景：編輯途中會話過期。早期遷移候選的 browser 驗收覆蓋了這個過程：保存被拒绝後隱藏私有表單，恢復同一管理員會話，再重新驗證，未保存標題仍然保留。這個結果來自隔離環境，不能替代真實 OAuth 回調和線上 Cookie 的驗收，但它把需要驗證的行為說清楚了。

佈署到這裡、用什麼身份、連著哪套數據，是同一條用戶路徑上的條件，不能只看首頁是否返回成功。

公開以後，抓取、權限和統計開始互相影響

网站公開之後，新的問題來自不同規則相遇的地方。

Google 驗證文件會經過 Pages 的路由處理；公開圖片可能仍走著帶有爬蟲限制的附件地址；推薦詳情有意保留的 noindex，又不能被日常巡檢誤判成站點故障。

這些問題都需要縮小到具體入口檢查。驗證文件要核對實際请求是否跳轉、最終字節是否正確；圖片要同時看引用它的內容是否公開、返回的 MIME 和響應頭是什麼；索引狀態則要區別「站點提供了頁面」和「Google 已經處理了頁面」。

統計同樣如此。Boloop 的本站事件、GA4 和 Search Console 有各自的日期和覆蓋範圍。頁面上的數字存在，不代表已經有足夠樣本解釋增長；一次上線驗收訪問，也不能被寫成一個自然搜索帶來的讀者。

下一步需要什麼，由真實使用決定

這一路並不是先列出所有系統，再一次做完。內容越来越多，目錄需要分頁和跨頁搜索；出現真實上傳問題，恢復路徑才變得具體；開始運營之後，統計郵件、診斷和選題任務又需要交接與去重。

對另一個正在用 AI 搭網站的人，我建議先選一條真實路徑完成它。例如：寫一篇文章，保存草稿，預覽，發佈，在匿名頁面讀到正確版本，再確認撤下後的行為。路徑涉及的功能，就是首版真正需要補齊的部分。

隨後給這條路徑加一個會發生的反例：會話過期、存儲暫時失敗，或者發佈後繼續編輯。看它能否保留工作，能否說明結果，能否恢復。

Boloop 的經驗會繼續變化。早期建設和驗收發生在雲端隔離環境，2026 年 10 月 19 日之後開發與隔離測試遷到本機，再將經過驗證的構建發佈到 Pages。這樣的邊界應該留在記錄裡：讀者需要知道哪一段已經實際走過，哪一段還只是候選。

网站能長期維護，靠的是這些路徑逐步連起來。AI 幫忙寫出的界面是一個很好的起點；當內容、權限、失敗恢復和運營結果都有了明確去處，這個起點才開始成為自己的產品。