「幫我做一個文章網站，其他你看著辦！」
AI 超認真開工：加文章、做多語系、加相關文章、站內連結、搜尋、品質檢查、安全檢查，還有自動修復。原本只是巷口的小雜貨店，最後變成有翻譯部、品管部、稽核室，再加一個「逗號核准委員會」的大工廠。
最後畫面跳出來的是 BUILD FAILED。
AI：「修好了。」下一次建置：失敗。AI：「我改了別的地方。」還是失敗。打倒一隻魔王，下一隻魔王又出現。以下用 Cloudflare Pages 和 Astro 當例子，說明為什麼會這樣、該怎麼處理。這裡講的是一般原理，不是替哪個網站的故障下定論。
1. 建置到底在做什麼？
Markdown 稿子、圖片、版面設計和程式只是原料，不等於做好的網站。建置（Build）就是把這些原料轉成瀏覽器打得開的頁面和檔案。Astro 通常會把可以直接上線的靜態檔案產生在 dist 資料夾。[1]
稿子是食譜，建置是下廚。把生洋蔥和食譜擺上桌說「上菜囉」，客人應該會翻桌。
2. Cloudflare 負責哪一段？
Cloudflare Pages 可以從 Git 抓程式碼，執行你設定好的建置指令，再把成果發布出去。[2] 一般流程是：抓程式碼 → 安裝工具 → 事前檢查 → 產生頁面 → 確認成品 → 部署。實際步驟看專案設定。
建置是生產，部署是出貨上線。 新的建置失敗，這個版本就上不了線。廠房是 Cloudflare 提供的，但裡面像迷宮一樣的生產線，很多時候是網站自己的程式拉出來的。
3. 自動發文的網站，在做頁面之前就已經忙翻了
一般部落格把稿子轉成 HTML 就結束了。自動發布的系統還會在前後加一堆工作：這篇可以發嗎？翻譯齊了嗎？文章 ID 和網址對得上嗎？相關文章和站內連結對嗎？搜尋資料做得出來嗎？標題、圖片說明、廣告、安全規則都有遵守嗎？
每一項單看都合理。問題是改一行字，所有部門就得從晨會重新開始。只是想改一個標點，全廠員工卻戴著安全帽集合。
4. 文章和語言一多，為什麼就變難？
10,000 篇文章不代表工作量一定變成 10,000 倍。但檔案會變多、文章之間的關聯會變多，每多一種語言就多一套對應網址和搜尋資料。如果每次都拿每篇文章跟其他所有文章比一輪，規模越大就越吃力。
所以要只算有改的部分、能重複用的結果先存起來、每個步驟花多久都量一下。哪裡慢，看數字，不要用猜的。圖書館多進一本書，就把全台灣的書架重排一次，館員會先崩潰。
5. 為什麼修好一個，又跳出一個？
步驟照順序跑的時候，前面的錯誤會把後面的錯誤擋住。稿子檢查卡住 → 修好 → 連結檢查卡住 → 修好 → 產生頁面卡住 → 修好 → 搜尋資料又卡住，一關接一關。
這不一定代表每次修改都製造了新 bug。 可能一開始就藏了好幾個問題，只是在排隊。反過來，修改也真的可能弄出新問題。到底是哪一種，要看日誌和修改紀錄來判斷。推開一扇門還是一扇門，每扇都寫著「最後一關」。
6. 建置失敗的 6 種常見原因
① 程式和套件：打錯字、少裝套件、版本不合。② 輸入資料：稿子缺漏、格式不對。③ 檢查規則：頁面做得出來，卻被檢查擋下。④ 資源：時間、記憶體、檔案數量超過上限。⑤ 執行環境：自己電腦和 Cloudflare 那邊設定不同。⑥ 發布步驟：產生後的確認或上傳失敗。
只要建置指令回傳的結束碼不是 0，Cloudflare Pages 就會判定失敗。[2] 所以最後那句「Build failed」只是結果，不一定是真正的原因。只看推理小說的封面，是猜不到兇手的。
7. 看日誌，要找「第一個失敗的地方」
在 Cloudflare 的部署詳細資料裡可以打開 Build log。[3] 不要盯著最後一行紅字，要找第一個真的失敗的步驟，再判斷它屬於資料、程式、規則、資源還是環境。能單獨跑那一步，就單獨重現。臨時繞過和根本修復要分清楚，修好之後也要讓後面的步驟跑過。
「全部重跑！」喊 100 次，不存在的檔案也不會自己長出來。需要的不是幹勁，是壞掉那台機器的編號。
8. Cloudflare 的額度不是同一個錢包
根據截至 2026 年 10 月 10 日的官方文件，Pages 免費方案每月 500 次建置、同時只能跑 1 個、每次建置 20 分鐘逾時、每個網站最多 20,000 個靜態檔案。[4] 大網站要注意，除了 HTML，圖片和搜尋用的檔案也會算進檔案數。
Workers 的請求次數和執行時間另有一套限制。Pages Functions 的請求有可能算進 Workers，但不能因為 Workers 額度用完了，就認定 Pages 建置失敗也是同一個原因。[4][5] 會計大喊「超支了」，先問清楚是哪一本帳。
9. 很高級，不代表一定需要
個資外洩、嚴重的安全問題、重要頁面壞掉，這些就該擋下來不要發。但相關文章的順序有點不順眼，需要讓整個網站停工嗎？這是兩回事。
檢查可以分成三種：一定要擋住發布的／只跳警告的／和發布分開、定期跑的。判斷標準不是檢查名稱多厲害，而是對讀者和經營者有沒有實際傷害。因為品管室門把有灰塵就讓工廠永久停業，那是檢查把正事吃掉了。
10. 叫 AI「看著辦」，功能就會越長越多
「順便做一下搜尋優化」「多加幾種語言」「不要再出錯」「再加個檢查」。這樣一說，AI 很快就把功能加好。每一項單看都沒問題，可是全部串成一條線，就可能變成每個部門都蓋完章，一篇文章才能出廠。
這也不只是 AI 的問題，人自己開發也會功能加過頭、累積技術債。AI 只是加得更快。你不用每行程式都自己寫，但要畫好界線：什麼一定要守、什麼可以晚點做、在哪裡停手。叫 AI 掃地，它先成立了掃地機器人監督委員會。地板還是髒的。
11. 復原分 3 步
先止血：新功能先暫停，保住最近一次正常上線的版本，找出第一個失敗點。隱私和安全的檢查不要隨手關掉。
再拆開：每次建置只留真正需要的頁面產生，耗時的全站分析和小檢查拆出去另外跑。Cloudflare 有 Build watch paths（依照改到的路徑決定要不要啟動建置）和建置快取。[6][7] 不過只是打開這些設定，你自己寫的全站處理程式並不會自動變成只處理有改的部分。
防止再犯：記下每一步的耗時、失敗種類、產生的檔案數、發布成功率和復原時間。成功不是「AI 說修好了」，而是一路通過檢查、真的上線。
12. 結論：最終魔王可能是工廠的線路
文章多、語言多、還有相關連結和品質檢查，這套東西真的很難。但難的工作不需要全部塞進同一次建置。回頭問問：這個警告憑什麼擋住發布？為什麼每次都要全部重算？其他工作能不能各自繼續跑？
理想的工廠是：人睡著了，危險的文章照樣被擋下，安全的照常發出去，只有壞掉的那一步會通知你。
AI：「全部搞定！」 人：「那上線了嗎？」 AI：「建置失敗了。」
唯一真正全自動的，只有生產藉口的功能。
參考資料（7筆）
- Astro Docs, CLI reference: astro build docs.astro.build
- Cloudflare Docs, Build configuration (updated 2026-09-18) developers.cloudflare.com
- Cloudflare Docs, Debugging Pages (updated 2026-06-02) developers.cloudflare.com
- Cloudflare Docs, Pages limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Workers limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Build watch paths (updated 2026-04-21) developers.cloudflare.com
- Cloudflare Docs, Build caching (updated 2026-05-27) developers.cloudflare.com
