從 0 開始：透過 AI Agent 建立並部署 Foliohaven 網站

上一篇介紹了 Foliohaven 的開發動機與功能。這篇以「Foliohaven 工作室」官網為例，讓 Agent 協助完成環境準備、頁面製作、內容管理與部署。整個流程都在同一個對話中進行，讓 Agent 沿用前面整理的需求與操作結果，避免不必要的交接。

操作從整理網站需求開始，並依序交給 Agent 執行。沒有工程背景或開發經驗也可以跟著做，再依自己的需求調整用法。有經驗的讀者可以把這篇當作參考，沿用自己習慣的工作模式。指令中需要登入帳號、填寫設定或操作服務後台的地方，會請 Agent 說明位置與步驟，帶著你完成。

先準備這次使用的 AI 帳號，並在要建立網站的電腦安裝桌面版。以下以 ChatGPT 與 Claude 為例，選擇自己使用的服務即可。

• 使用 ChatGPT：開啟 ChatGPT 桌面版並登入，切換到 Work 模式。確認這個工作環境能存取本機資料夾並使用終端機。如果原本在一般對話中，畫面提示改用 Work 繼續時，依提示切換即可。
• 使用 Claude：安裝 Claude 桌面版，登入可使用 Claude Code 的付費帳號。開啟側邊欄的 Code 頁籤，在輸入框下方選擇 Local（本機執行環境），再透過 Open folder… 開啟要存放網站的工作資料夾。

釐清需求：整理網站要呈現的內容

以下的工作室背景、聯絡資料與活動均為虛構範例。先整理網站的用途、目標對象，以及手邊已有的文案、Logo、圖片或參考網站。還沒決定的部分也可以列出來，再請 Agent 協助釐清。

給 Agent 的提示詞：

請只整理以下網站需求，作為後續建站的依據，先不進行實作。
這個階段只在對話中回覆；即使已有可用環境或專案，也不要建立或修改檔案、執行指令、安裝、啟動、建置或部署。

網站名稱：Foliohaven 工作室。
服務：網站設計、品牌內容規劃、網站維護。
對象：小型店家、獨立品牌與自由工作者。

需要的頁面：
首頁 /：工作室簡介、三項服務、合作流程、近期活動與聯絡入口。
About Us /about/：工作理念、服務對象與合作流程。
Contact Us /contact/：email、電話，以及之後可加入的聯絡表單。

視覺：明亮、安靜的編輯式設計；米白底、炭黑字、深綠重點色，大標題、寬留白與細線分隔。
素材：先用文字標誌與簡單幾何圖形，活動文章另製作圖卡。
聯絡資料：hello@foliohaven.example、02-0000-0000。
內容管理：之後要發布「品牌網站交流日」活動公告。

請回覆頁面、內容與素材清單，以及需要補充的問題。完成需求整理後先停在這裡，等我另行交辦下一階段。

可以根據需求換成自己的品牌、文案與素材。已有參考網站時，也可以附上網址，說明喜歡的是配色、排版、導覽，還是某個區塊。

這份需求會讓 Agent 先知道網站要服務誰、需要哪些頁面，以及內容要怎麼安排。工作室官網的重點是介紹服務與合作方式，讓訪客找到聯絡入口；近期活動則由後續新增的文章提供內容。

請只整理以下個人技術部落格的網站需求，作為後續建站的依據，先不進行實作。
這個階段只在對話中回覆；即使已有可用環境或專案，也不要建立或修改檔案、執行指令、安裝、啟動、建置或部署。

網站名稱：【名稱】。
寫作主題：【主題】，主要讀者：【對象】。
配色與素材：【視覺偏好、文案、Logo、圖片或參考網址】。

首頁先放作者介紹與網站主題，再放精選文章、最新文章與分類入口；About 說明背景，Contact 提供聯絡方式。
文章以長文閱讀為主，需要舒適字級與行高、自動目錄、程式碼、表格、圖片及延伸閱讀。
後續製作沿用專案的內容與媒體規則；驗收需涵蓋手機、桌機、鍵盤、區塊捲動與返回後的閱讀位置。

請回覆頁面、內容與素材清單，以及需要補充的問題。完成需求整理後先停在這裡，等我另行交辦下一階段。

接下來依序進行：建立環境並啟動專案 → 完成頁面與共用外觀 → 新增文章 → 修正及檢視 → Cloudflare 初次設定 → 部署與驗收。各階段沿用同一份專案與前面確認的需求。

建立環境並啟動專案

確認網站需求後，沿用前面準備好的本機工作環境，填好以下指令的專案位置與 Git 身分，再請 Agent 建立環境並啟動專案。

給 Agent 的提示詞：

請在【專案位置】建立並啟動 Foliohaven，Git 身分為【名稱】與【email】。
我授權這次所需的本機工具安裝、專案設定與本機基準 commit。

先檢查主機系統、已安裝工具、指定目錄與既有專案，再依需要執行：

1. 準備 Git、Docker／Compose，以及下載、校驗與解壓工具。已安裝且可用的工具只需檢查，不重複安裝。
2. 到 https://github.com/hsunAlfred/foliohaven/releases 查詢最新正式版本，排除 Draft 與 Pre-release，下載該版的 foliohaven-版本-source.tar.gz 與 SHA256SUMS。校驗相符後解壓，記錄實際版本、tag 與校驗結果。需要的專案目錄由你建立。
3. 閱讀下載版本的 README、AGENTS.md 與相關指南。依同版 .env.example 準備本機 Docker 設定；Linux 主機先查 UID／GID，再對齊容器帳號，保留非 root 執行與本機監聽。
4. 尚無 Git repository 時先執行 git init，再設定上述專案 Git 身分，沿用 .gitignore，檢查檔案後建立本機基準 commit。
5. 依同版 README 建置並啟動 Docker 專案，確認 Studio、來源預覽與成功網站，回報網址與結果。

若已有完整來源，先辨識版本並沿用，不重新下載或覆蓋既有內容；已有 .env 就保留原值，再調整必要欄位；已有 Git repository 就沿用歷史；服務已啟動時沿用現有服務並檢查，不再啟動第二組。

需要我輸入系統密碼、操作介面、重新登入或重啟時，請說明在哪裡做、要做什麼，等我完成後接續。

【專案位置】填網站要存放的路徑，Agent 會建立需要的目錄；【名稱】與【email】是這份專案的 Git 提交身分。已經有專案時，填現有位置即可，指令會讓 Agent 先辨識目前狀態，再處理尚未完成的項目。

Agent 會依主機系統準備工具，從 Releases 確認最新正式版，再下載同版來源包與校驗檔。安裝過程若需要系統密碼或重新登入，會把需要你操作的部分列出來，完成後繼續。Docker 容器會提供 Node.js、pnpm、媒體處理與測試工具，主機的安裝項目由同版 README 決定。

這裡的 .env 用來設定本機 Docker。專案隨附的 .env.example 只有版本、image 名稱、UID／GID 與連接埠等參數，沒有 token，因此交給 Agent 依主機情況建立及調整。已有設定時先保留原值；Cloudflare token 與 R2 憑證會在後面的 .env.cloudflare 另外準備。

確認環境已可使用

這份指令已經包含啟動。完成後，確認 Agent 回報的版本、來源包校驗、Git 基準與服務狀態，再開啟三個本機網址：

若使用其他主機或已調整連接埠，就開啟 Agent 回報的實際網址。遇到啟動失敗時，把錯誤交給 Agent，請它檢查後接續原本流程。

完成頁面與共用外觀

專案啟動後，繼續在同一個對話中請 Agent 依前面確認的需求製作頁面與共用外觀。有新的 Logo、照片或參考網站時，再一併補充。

給 Agent 的提示詞：

理解專案，請依前面整理的需求，製作「Foliohaven 工作室」官網。
先讀取同版 README、AGENTS.md，以及固定頁、版型與品質指南。

配色採米白底 #F6F3EC、炭黑字 #25302B、深綠重點色 #315B4C，搭配文字標誌、簡單幾何圖形、大標題、寬留白與細線分隔。

首頁 /：
主標「為小型品牌建立清楚、好用的網站」，依序放工作室簡介、網站設計／品牌內容規劃／網站維護三項服務、合作流程與近期活動。
主要按鈕「洽談網站需求」連到 Contact Us。
近期活動只讀「活動公告」（events）分類的已發布文章；分類或內容還沒建立時顯示空狀態。

About Us /about/：
介紹「先釐清內容，再設計網站」的理念、服務對象，以及需求盤點→規劃設計→製作驗收→後續維護的流程。

Contact Us /contact/：
顯示 hello@foliohaven.example 與 02-0000-0000，加上 mailto:／tel: 連結。

Header、Footer 與文章版型沿用同一風格。
文章要有標題、日期、分類／Tag、主圖、目錄、正文與延伸閱讀，字級易讀、行高舒適，手機採單欄。

需要直接改內容、媒體 metadata 或網站設定前，先協調 Studio 切到 IDE 模式；完成後檢查、切回 Studio 並重新讀取。
先完成固定頁與共用版型，活動文章留到下一階段建立，完成後提供桌機與手機預覽。

這份範例可以直接使用。改成自己的網站時，替換網站名稱、服務、頁面文案、聯絡方式與配色；有提供品牌素材或參考網址，也在指令裡註明。

Agent 會依專案指南完成首頁、About、Contact、導覽與共用文章版型。近期活動先按分類讀取內容，還沒有公告時保留空狀態，後續發布活動文章後再顯示。文章共用版型也在這一階段處理，之後新增內容就沿用同一套排版。

完成後開啟編輯預覽(4321 port)，確認頁面、配色、區塊與按鈕位置，並試著使用導覽、email 與電話連結。直接改檔時用 IDE 模式暫停 Studio 保存來源，檢查完成後再回 Studio 接續管理內容。

加入聯絡表單

需要表單時，先準備收件信箱；方案還沒選好，也可以讓 Agent 依目前使用的工具協助選擇。

給 Agent 的提示詞：

請用【表單方案】串接 Contact Us 表單，欄位為姓名、email、訊息，通知寄到【收件信箱】，保留原有 email 與電話連結。

請協助我完成帳號、收件、網域與授權設定；有需要我操作的部分，說明在哪裡做、取得什麼資料，以及填到哪裡。
完成欄位驗證與成功／失敗提示，先在本機或測試環境確認送出及實際收件。
我確認後，再隨網站部署上線；正式網址也再測一次送出與收件。

【表單方案】填要採用的服務，【收件信箱】填實際接收通知的地址。方案未定時，可以把第一句改成「請依我目前使用的服務，協助選擇聯絡表單方案」。常見選擇如下：

• Google 表單：適合習慣 Google 生態系的使用者。可以嵌入或連到表單，確認發布與作答權限後，開啟新回覆通知。需要自訂信件或後續流程時，再加入 Apps Script。
• Formspree：保留網站自訂表單外觀，將 HTML 表單送到服務端點，由服務處理收件與通知。設定方式與額度可看串接指南與方案。
• Cloudflare Workers、Turnstile 與寄信服務：另建表單接收 Worker 或 API，在後端驗證 Turnstile，再寄到已驗證的收件信箱。表單後端與網站的靜態部署分開維護，依寄信設定完成寄件網域與收件者設定，並做後端驗證。
• 自建表單 API：需要特殊資料串接或流程時，可自行開發收件程式，同時安排寄信、防垃圾、錯誤處理與後續維護。

指令會讓 Agent 處理串接與程式，需要帳號或後台設定時再引導你操作。完成後檢查正常送出、必要欄位缺漏、錯誤提示與實際收件，也把使用的服務與資料處理方式整理進隱私說明。

新增文章：用 Studio 建立活動公告

接著要建立一篇「品牌網站交流日」公告，在同一個對話中一併提供準備好的活動資料與現有素材。

給 Agent 的提示詞：

請協助我建立 Foliohaven 工作室的「品牌網站交流日」活動公告，先保存為草稿。

目的與對象：透過案例分享與內容討論，協助準備架站或改版的店家、獨立品牌及自由工作者釐清網站方向。
時間：2027/1/16 14:00–17:00，臺北時間。
地點：Foliohaven 工作室交流空間，臺北市示範路 100 號 2 樓。
名額與費用：12 人、免費；請帶筆電及現有網站或參考連結，尚無網站也可參加。
流程：14:00 報到→14:15 網站案例分享→15:00 休息→15:15 品牌內容討論→16:15 自由交流與 Q&A→17:00 結束。
報名：2027/1/13 前寄至 hello@foliohaven.example，主旨「品牌網站交流日報名」，附姓名、聯絡方式及品牌／網站簡介；收到工作室回信才算完成，額滿截止。

正文依活動介紹、適合對象、時間地點、流程、準備事項與報名方式安排。
分類用「活動公告」，網址名稱 events；Tag 用「品牌」「網站規劃」「交流活動」。
文章網址名稱用 brand-website-meetup。
摘要：「Foliohaven 工作室邀請店家與自由工作者，透過半日網站案例分享、品牌內容討論與現場交流，整理架站或改版的方向。」

封面使用活動名稱、日期與工作室名稱的簡潔圖卡，沿用官網配色。
文章發布與更新時間依實際操作填寫，與活動日期不一定相同。

依文章與 SEO 指南完成正文、分類／Tag、摘要、媒體處理、選圖、Alt 與 SEO 繼承檢查。
能直接完成的部分請協助完成；需要我在 Studio 操作時，說明位置與步驟。直接改檔前先協調 IDE 模式，完成後回 Studio 重讀。
保存後重新開啟及預覽，等我確認內容再發布，並檢查 4321 的文章頁與首頁近期活動。

這份活動資料是教學範例，改成自己的公告時，替換活動名稱、對象、時間、地點、名額、費用、流程、準備事項與報名方式，再調整分類、Tag、文章網址與摘要。

這段指令會讓 Agent 整理正文與文章設定，完成分類、Tag、封面與媒體處理，檢查 SEO 繼承，並先保存為草稿。需要你操作 Studio 的部分，Agent 會說明位置與步驟；完成後，再從 Studio 查看結果。

在 Studio(5173 port) 檢查草稿

在 Studio 的「文章」列表開啟 Agent 已保存的「品牌網站交流日」草稿。先在「文章設定」核對文章標題、摘要、文章網址名稱、分類與 Tag，確認與這次公告相符。

接著展開「發布與更新時間」，核對文章的發布時間與最後更新時間。日期依網站設定的顯示時區解讀。需要調整時，可以直接輸入日期與時間，或按欄位旁的日曆選擇，再按「套用時間」。

「填入目前時間」會補上尚未設定的發布時間，並把更新時間設為現在；已有的發布時間會保留。之後修改已發布文章時，可以保留原發布時間，調整更新時間。一般保存或建置不會自動把日期改成現在，手動調整後仍要保存；文章是否公開，則由發布狀態決定。

接著在「即時預覽」閱讀正文，核對活動目的、時間地點、名額費用與報名方式。寬螢幕可以並排對照「文章正文」與預覽，較窄的畫面則切換「正文」、「預覽」與「文章設定」頁籤。預覽也能選擇桌機、平板或手機，檢查不同寬度下的排版。

「文章標題」會由版型顯示為頁面最上方的主標題（H1），正文接著呈現介紹段落與各章節內容。H2 用於主要章節，H3 用於章節內的小節；系統依 H2、H3 產生目錄，並用 Agent 設定的 id 對應章節位置。這些章節識別名稱必須有效且不重複。檢查時，對照目錄與正文的章節名稱、順序及層級。

圖片也在預覽中一起檢查：封面與正文圖片是否出現，手機裁切會不會切掉重要文字。回到「文章設定」核對精選圖片的引用尺寸與 Alt（圖片替代文字），確認描述符合實際畫面。

在 SEO 設定查看生效值與來源，確認標題、描述與分享圖符合這篇公告。這份範例的單篇 SEO 保持繼承，文章頁型預設使用摘要與精選圖片；網站先前調整過策略時，就依目前顯示的來源檢查。完整的繼承與文案操作會在 SEO 篇接著說明。

確認內容並發布

有要調整的地方，就在同一個對話中說明是哪段內容、哪張圖片或哪個設定，以及希望改成什麼，請 Agent 接續修改。修改完成後，重新讀取草稿，再核對這次的結果。

若直接在 Studio 修改，按「保存目前內容」後，再回到文章列表重新開啟，確認正文與設定已保存。即時預覽會顯示編輯中的內容，本身不會保存文章。

草稿先在 Studio 的預覽查看，確認內容、圖片與設定後，再請 Agent 發布公告。

發布後，先到編輯預覽(4321 port)查看 /events/brand-website-meetup/、首頁近期活動與分類／Tag 列表，確認文章已出現。下一節會把這篇公告與前面完成的頁面一起檢查，完成整站建置，再從部署前預覽(4322 port)確認結果；正式網站則在後續部署時更新。

修正及檢視網站

先記下要調整的頁面網址、裝置或寬度，以及看到的問題。已確認的內容與風格也列出來，方便保留。

給 Agent 的提示詞：

我已看過目前網站，請協助修正及檢視【頁面網址】。
裝置或寬度：【裝置或寬度】。
需要調整：【問題與希望呈現的結果】。
請保留：【已確認的內容與風格】。
如果問題欄填「無」，直接進行檢查、建置與驗收。

修正後依同版 AGENTS.md 與品質指南，執行適用的內容、型別與相關測試，再完成正式 pnpm build。
請用這次成功的 4322 檢查受影響頁面，涵蓋手機、桌機、鍵盤、圖片、搜尋與閱讀操作；依指南量測適用的 Lighthouse 指標。
回報改了什麼、本次檢查與量測結果，以及尚未確認的部分。這一階段完成本機網站。

【頁面網址】填目前要檢查的預覽網址；【裝置或寬度】填實際看到問題的尺寸；【問題與希望呈現的結果】描述具體差異；【已確認的內容與風格】填需要保留的部分。沒有要修改的地方時，問題欄填「無」即可。例如首頁在 390px 時主標行距太密、服務項目留白不一致，就交代要調整哪一段，同時保留已確認的配色與其他頁面。

Agent 會依回饋修改來源，依改動範圍執行檢查，再建立本次完整網站。上面的指令已包含網站建置，Agent 完成後，查看回報，並開啟部署前預覽(4322 port)確認結果。若要自行更新已保存的內容，也可以選擇以下的 Studio 或終端機方式。

透過 Studio 更新網站：

1. 先保存要納入網站的修改，確認活動公告已發布，再前往「網站更新與工作」，按「更新網站」。
2. 開啟這次的工作紀錄，在「工作詳細資料」查看階段、進度與診斷。更新期間先暫停編輯，等待工作完成。
3. 回到同頁的「目前網站版本」，確認顯示「網站已更新至目前保存的內容。」後，再重新整理部署前預覽(4322 port)查看新版。

若更新失敗，部署前預覽(4322 port)仍可能顯示前一次建置成功的版本；先查看這次的工作結果與目前網站版本，修正問題後再更新。完整型別檢查、相關測試與 Lighthouse 量測，則依修改範圍另外安排。

docker compose exec app pnpm validate:content
docker compose exec app pnpm build

查看部署前預覽與閱讀操作

確認本次網站更新成功後，開啟部署前預覽(4322 port)，從首頁依序進入 About、Contact 與活動公告，確認導覽、聯絡連結、分類／Tag、搜尋與 404 的呈現。手機再看一次，檢查換行、行距、留白與圖片是否合適，也試著用鍵盤移動焦點，確認按鈕與連結可以操作。

閱讀活動公告時，從目錄跳到不同章節，再試著返回上一頁、前進回文章，確認頁面與閱讀位置是否正常。文章有程式碼或表格時，也檢查能否在區塊內捲動，而不把整個頁面撐寬。

文字放大後的排版，以及停用 JavaScript 後主要內容與基本連結是否仍可閱讀、操作，也可以交給 Agent 用瀏覽器工具檢查。將看到的問題連同頁面網址、裝置與重現方式，帶回同一個對話接續修正。

讓 Agent 量測網站品質

網站更新完成後，再用工具量測載入速度、無障礙與 SEO，找出閱讀檢查時不容易察覺的問題。這一輪依專案品質指南，以手機與桌機的 Performance 至少 95，Accessibility、Best Practices、SEO 各 100 為目標。

本機網站使用 Lighthouse；已有可公開存取的網址時，可以使用 PageSpeed Insights，服務不可用時再改用 Lighthouse。Agent 若已提供本輪完整報告，就先查看結果；需要補測或改測公開網址時，再貼上以下指令。

給 Agent 的提示詞：

請依本專案品質指南，直接完成【受測網址】的網站品質量測，先確認網址對應本次成功建置或已部署的版本。
已有本輪同版本、同條件的完整報告時，直接整理結果，缺少的項目再補測。

網址是 localhost 或內網時，使用本機 Lighthouse。
可供外部服務直接存取的公開網址，優先使用 PageSpeed Insights；遇到額度限制、服務不可用或無法取得有效結果時，改用 Lighthouse 測同一網址，記錄切換原因與測試環境。

手機與桌機分開，每組網址、工具與條件依序量測三次，保留原始報告，分別計算四類分數與各效能指標的中位數。切換工具、版本或網址時另列一組結果，不混用數值。
以 Performance 至少 95，Accessibility、Best Practices、SEO 各 100 為目標；預期不收錄的頁面依原本索引策略檢查。

回報受測網址、日期、來源版本、Build 或部署識別、工具版本、裝置與節流條件、三次結果、中位數，以及值得修正的問題。
若有實際使用者資料，另列頁面或來源範圍與資料期間；沒有資料就標示未取得，也不要用 TBT 代替 INP。
本次量測現有的本機網站或已公開版本，公開發布依後續部署階段另行交辦。

【受測網址】填要檢查的完整網址。本機可填 http://localhost:4322/，再加上活動公告等代表頁面的網址；正式部署後，換成對應的公開網址。Agent 會依網址與工具可用性選擇測試方式，並把本機與公開網站的結果分開呈現。

報告中需要修正的項目，可以接回前面的修改流程。本機修改後先重新建置，再測部署前預覽(4322 port)上的同一組頁面；公開網址則等後續部署完成，再核對新版本並量測。各輪報告分別保留版本與環境，才能對照實際改善。

Cloudflare 初次設定

本機網站確認後，接著準備 Cloudflare 的部署設定。先備妥 Cloudflare 帳戶與網站要使用的網域，並確認網域已加入同一個帳戶管理。

請引導我準備 Cloudflare 帳戶與網站要使用的網域，並將網域加入這個帳戶管理。
已有項目先確認並沿用，逐步說明在哪裡操作，以及如何確認已完成。

帳戶與網域準備好後，在同一個對話中請 Agent 協助開通服務、準備部署設定，並完成本機預檢。

給 Agent 的提示詞：

Cloudflare 帳戶與網域已準備好，請依目前專案版本的 Cloudflare 部署文件，協助完成部署前的設定。
正式網址為【HTTPS 網址】，網站 Worker 名稱為【Worker 名稱】，R2 bucket 為【bucket 名稱】。

請依序協助我完成：
1. 核對同一個帳戶的 Account ID，引導我開通 Workers／R2，並建立上述網站專用 bucket。
2. 引導我建立可查詢、建立與部署 Worker 的 API Token，以及限該 bucket 的 R2 Object Read & Write S3 憑證。
3. 依同版範例準備 cloudflare.config.json 與 .env.cloudflare；已有設定時保留原值，核對後再調整。依部署文件確認檔案擁有者及 0600 權限。
4. 修改 siteUrl 前先協調 IDE 模式，將它設為上述正式網址，完成後切回 Studio 並重新讀取。
5. 執行 pnpm deploy:cloudflare --dry-run，保留本次 deployment UUID，回報版本、部署目標與本機預檢結果。

需要我操作服務後台或填寫帳務資料時，說明位置、用途與確認方式，再由我操作。
憑證由我填入本機私有的 .env.cloudflare，不貼進對話。
這一階段完成本機預檢，正式上傳留到下一階段。

依引導準備服務與憑證

前面的設定提示詞已包含服務與憑證的引導，Agent 通常會依下面的順序帶你操作。這裡列出後台路徑與欄位設定，方便對照；先選擇前面網域所屬的 Cloudflare 帳戶，名稱沿用 foliohaven-studio 與 foliohaven-studio-assets。Worker 會在首次正式發布時由工具建立。

1. 開通服務：進入帳戶的「Workers & Pages」，依首次使用畫面完成服務設定；接著到「Storage & databases → R2 → Overview」，依畫面完成 R2 訂閱與帳務資料。已開通的服務直接沿用，R2 開通流程可對照 官方說明。

2. 取得 Account ID：在「Workers & Pages → Account Details」複製 Account ID，此值對應 cloudflare.config.json 的 accountId，用來辨識這次部署使用的帳戶。也可在後台搜尋輸入 Copy account ID 取得；這裡要用的是帳戶 ID，與網域的 Zone ID 不同。位置可對照 帳戶識別說明。

3. 建立網站專用 bucket：到「Storage & databases → R2 → Overview → Create bucket」，依下表設定，再按 Create bucket。已有這個網站專用的 bucket 時，先請 Agent 核對後沿用。

   欄位	設定值
   Bucket name	foliohaven-studio-assets，與前面選定的名稱相同。
   Location	使用 Automatic／預設自動位置；畫面顯示 None 時，表示由 Cloudflare 自動選擇。
   Jurisdiction	沿用預設管轄範圍，不選 Specify jurisdiction。
   Default storage class	Standard，適合網站與媒體這類經常讀取的資料。

   本版部署工具使用預設 jurisdiction 的 S3 endpoint，因此保留上述管轄設定。Location 是儲存位置的選擇，與管轄限制不同，欄位可對照 R2 資料位置與 儲存類別。公開來源網域留到下一節上傳後再連接。

4. 建立 Worker 部署 Token：從右上角個人選單進入「My Profile → API Tokens → Create Token」，建立自訂 Token，設定如下：

   欄位	設定值
   Token name	foliohaven-studio-deploy，方便辨識這個網站的部署憑證。
   政策類型	Account，建立帳戶層級的政策。
   資源範圍	只選擇前面取得 Account ID 的帳戶。
   權限／角色	Workers 的 Admin，適用範圍為 Workers 產品。

   首次發布要建立新 Worker，因此依目前的 Workers 權限說明，需要產品範圍的 Admin；Editor 用於既有 Worker，不能建立新 Worker。這組權限也涵蓋查詢設定與版本、更新及部署。網域分流仍由你在後台操作，這個 Token 只設定部署需要的 Workers 權限。

   按「Continue to summary」核對帳戶與權限，再按「Create Token」。將產生的 Token 填入本機 .env.cloudflare 的 CLOUDFLARE_API_TOKEN，作為 Worker 部署憑證。建立流程可對照 API Token 說明。

5. 取得 R2 S3 憑證：回到「Storage & databases → R2 → Overview」，在「Account Details → API Tokens → Manage」進入管理頁，選「Create User API token」，設定如下：

   欄位	設定值
   Token name	foliohaven-studio-r2，方便辨識這個網站的 R2 憑證。
   Permissions	Object Read & Write，供部署工具讀寫網站資源。
   Bucket 範圍	選 Apply to specific buckets only，僅勾選前面建立的 foliohaven-studio-assets。

   按「Create User API token」後，將 Access Key ID 填入本機 .env.cloudflare 的 R2_ACCESS_KEY_ID，Secret Access Key 填入 R2_SECRET_ACCESS_KEY。Secret Access Key 只在建立時顯示一次，當下就保存到本機私有設定；它與上一個步驟的 Worker Token 是不同憑證。操作可對照 R2 憑證說明。

需要填入憑證時，Agent 會先依同版範例準備專案根目錄的 cloudflare.config.json 與 .env.cloudflare：前者記錄帳戶、Worker 與 bucket 等部署目標，後者保存部署憑證。已有檔案時，它會先核對並保留設定，檢查擁有者與權限，再引導你將後台取得的憑證填入本機檔案的對應位置。

Agent 也會將前面確認的正式網址寫入全站設定的 siteUrl，供 canonical、分享網址、RSS 與 Sitemap 使用。修改網站設定前，它會先協調切換 IDE 模式，完成後檢查、切回 Studio 並重新讀取。

設定與本機預檢結果會由前面的提示詞一併回報。

請確認剛才這輪 Cloudflare 初次設定與 dry-run 的結果。
沿用同一個對話、專案設定與本輪已完成的本機預檢紀錄，核對版本、正式網址、Worker、bucket、設定檔及 siteUrl。
已有完整的本輪回報時直接判讀，將本機已確認的項目，以及仍待正式上傳與網域設定確認的項目分開說明，並回報下一步。
這次只整理已執行的結果，不重新建置或執行 dry-run，也不連線或上傳 Cloudflare；找不到本輪紀錄時，先列出缺少的資訊。

Agent 確認本機預檢通過後，下一節再用提示詞請它正式上傳網站，並引導完成網域設定與公開網址驗收。

部署與驗收

接下來用提示詞請 Agent 上傳網站，再由它引導完成網域分流與公開網址驗收。整個流程沿用前面確認的部署設定，在同一個對話中接續；需要操作 Cloudflare 後台的部分，由你依 Agent 的說明完成。

上傳網站並確認結果

確認上一節的本機預檢通過後，請 Agent 執行正式發布。

給 Agent 的提示詞：

我已確認本機網站與前一節的部署設定，授權使用 pnpm deploy:cloudflare 正式發布網站。
沿用前面確認的正式網址、Worker 與 bucket 設定，執行前核對實際部署目標。
請保留本次正式上傳的 deployment UUID 與私有部署紀錄，後續查詢與驗收所需的識別由你直接帶入。
遠端結果不明時，先用 pnpm deploy:cloudflare:status 查證本次部署，再決定下一步。

上傳成功後，請依序引導我設定 R2 公開來源、主站 DNS、三條 Worker Routes、Cloud Connector、快取、HTTPS、non-www 重新導向 www，以及本站 RUM。
控制台由我操作，說明每一步的位置、設定值與確認方式；等我確認後台設定完成，再進行正式網址驗收。

這段指令沿用前一節準備的設定。Agent 會重新建置完整網站，將網頁、RSS、Sitemap 與搜尋資料等檔案交給 Workers Static Assets，assets/ 與 media/ 交給 R2，並保存這次正式部署的紀錄。

取得上傳成功的回報後，接著依 Agent 引導完成網域分流。

請確認剛才這次正式上傳的結果，沿用你保存的 deployment UUID 與本機部署紀錄。
已有完整的本輪回報時直接整理；必要時執行 pnpm deploy:cloudflare:status，並自行帶入這次正式部署的 UUID 查證。
請說明 R2 與 Worker 是否上傳完成、正式網址是否仍待驗收，以及接下來要做什麼。
這次只確認既有上傳結果，不重新建置、上傳或還原。若無法確定對應哪次正式部署，或只找到 dry-run 紀錄，先回報待確認事項。

依引導完成網域分流

前面的發布提示詞已包含後台設定的引導，Agent 通常會依下面的順序帶你操作。這裡列出各步驟的位置與設定，方便對照；範例沿用 www.example.com、storage.example.com 與前面選定的 Worker、bucket 名稱。

完成後，首頁、文章與網站資料會由 Worker 提供，/assets/ 與 /media/ 則經 Cloud Connector 到 R2。

1. 連接 R2 公開來源：進入網站專用 bucket 的「Settings → Custom Domains → Add」，填入 storage.example.com。網域須由同一帳戶、同一 Zone 管理；等待狀態為 Active，再用這次上傳的實際資源確認可以讀取。

2. 設定主站 DNS：在「DNS → Records」新增或核對 www 的 CNAME，目標填 storage.example.com，Proxy status 選 Proxied。這是主站的連線入口，目標使用上一步已啟用的 R2 公開來源。

3. 設定 Worker Routes：在該網域的「Workers Routes」，或對應 Worker 的「Settings → Domains & Routes」，設定以下三條路由。後兩條選 None，讓資產請求繞過網站 Worker；每條尾端的 * 都要保留。

   Route	目標
   www.example.com/*	網站 Worker：foliohaven-studio
   www.example.com/assets/*	None／不指定 Worker
   www.example.com/media/*	None／不指定 Worker

4. 設定 Cloud Connector：在「Rules → Cloud Connector」建立規則，Provider 選 R2，來源 hostname 填 storage.example.com。條件比對主站 www.example.com，且路徑以 /assets/ 或 /media/ 開頭，保留原路徑。這裡使用 R2 公開自訂網域，與工具上傳時使用的 S3 API endpoint 不同。

5. 設定資產快取：在「Caching → Cache Rules → Create rule」新增或核對規則，匹配條件沿用前一步的主站與資產路徑。依下表設定，讓同網址的圖片或樣式更新後仍能重新驗證；已有其他快取規則時，一併核對套用順序。欄位可參考 Cache Rules 設定。

   欄位	設定值
   Cache eligibility	Eligible for cache
   Edge TTL	Use cache-control header if present, bypass cache if not
   Browser TTL	Respect origin
   Status Code TTL	維持未額外設定

6. 設定 HTTPS：在「SSL/TLS」確認主站與 R2 來源憑證有效，加密模式使用 Full (strict)；若同一 Zone 已有其他網站，先由 Agent 核對既有設定再調整。

   接著在「Rules → Overview」新增 Redirect Rule／Single Redirect，處理主站的 HTTP 轉 HTTPS。自訂條件填 http.host eq "www.example.com" and not ssl，目標類型選 Dynamic，運算式填 concat("https://www.example.com", http.request.uri.path)，狀態碼選 301，並勾選 Preserve query string，保留路徑與查詢參數。

7. 設定 non-www 重新導向 www：本例使用常見的 www 網址形式，以 https://www.example.com/ 作為正式網址。先確認根網域 example.com 有 Proxied 的 DNS 記錄，且 HTTPS 憑證已生效。

   若根網域只用來轉址、尚無對應的 A／AAAA／CNAME 記錄，可依 Cloudflare 的轉址設定新增 A 記錄：名稱填 @、IP 填 192.0.2.1，並開啟 Proxied。www 主站仍沿用前面連到 R2 公開來源的設定。

   在「Rules → Overview」另建一條 Redirect Rule／Single Redirect，設定如下：

   欄位	設定值
   匹配條件	http.host eq "example.com"
   URL 轉址類型	Dynamic
   目標 URL 運算式	concat("https://www.example.com", http.request.uri.path)
   狀態碼	301，永久重新導向
   Preserve query string	勾選，保留查詢參數

   匹配條件涵蓋根網域的 HTTP 與 HTTPS，動態目標保留路徑，查詢參數則由勾選項目保留。將 example.com 換成自己的網域，欄位可參考 Single Redirects 設定。例如，http://example.com/about/?from=test 預期會導向 https://www.example.com/about/?from=test；轉址結果會在正式驗收時一起檢查。

8. 停用本站 RUM 自動注入：在「Rules → Overview」新增 Configuration Rule，條件填 http.host eq "www.example.com"，只加入並啟用 Disable Real User Monitoring (RUM)，再部署這條規則。這會停止本站的 RUM 效能量測與程式注入，讓公開 HTML 與上傳檔案保持一致；其他 hostname 保留原設定。選項可參考 RUM 停用規則。

驗收正式網址

依引導完成上面的後台設定後，回到同一個對話告知 Agent，再請它驗收正式網址。

給 Agent 的提示詞：

Cloudflare 後台設定已完成，請沿用前面確認的正式 HTTPS 網址，以及本輪正式上傳成功的 deployment UUID，完成正式網址驗收。
請從這個對話與專案部署紀錄取得所需資料，執行 pnpm verify:cloudflare，domain 與 deployment 參數由你帶入。

回報公開檔案與 Chromium、Firefox、WebKit 的檢查結果，再引導我核對 Routes、Cloud Connector、快取等人工項目。
同時確認 www 主站的 HTTP 網址會轉到 HTTPS，並保留路徑與查詢參數。
也請檢查 non-www 網址的 HTTP 與 HTTPS，確認保留路徑及查詢參數，重新導向正式的 www HTTPS 網址，且沒有重新導向迴圈。
另外對正式網址完成手機與桌機的 PageSpeed Insights 量測，保留各次結果與中位數，記錄工具版本、條件與未驗範圍。
PageSpeed Insights 不可用時，改用 Lighthouse 測試同一個正式網址，記錄切換原因與測試環境；不同工具的結果分開呈現。

Agent 會核對專案設定的正式網址，沿用本次成功上傳的部署紀錄，將檢查結果整理在同一個對話中。

公開檔案與瀏覽器：Agent 先執行 verify:cloudflare，核對這次部署的公開檔案、內容類型、SEO、404 與資源，再用 Chromium、Firefox、WebKit 檢查頁面與互動。報告保存在 .foliohaven/reports/cloudflare/ 下對應 UUID 的目錄。

後台規則與轉址：接著依 Agent 引導核對 Routes、Cloud Connector 與快取，檢查 www 主站的 HTTP 是否轉到 HTTPS，以及 non-www 的 HTTP／HTTPS 是否正確轉到 www；兩者都要保留路徑與查詢參數，且沒有迴圈。自動報告中的 manualVerification: pending 對應這些另行核對的項目，實際確認結果另外記錄。

PageSpeed：verify:cloudflare 不會量測 PageSpeed，Agent 會另外對正式網址進行手機與桌機量測。沿用前面的品質指南，每組條件測三次，保留原始結果並分別取分數與指標中位數，記錄網址、日期、版本、部署 UUID 與條件。已有本輪同版本、同條件的完整公開網址報告時，就沿用並補齊缺項。

本機 Lighthouse 與 PageSpeed Insights 的雲端結果分開呈現；有實際使用者資料時，再另列頁面或來源範圍與資料期間，未取得時註明未取得。接著從正式網站走過導覽、文章目錄、搜尋、聯絡入口與選用表單，確認送出與收件、圖片及其他資源符合這次修改。

將本輪檢查結果與看到的問題留在同一個對話中接續處理；網站內容有修改時，重新部署後再驗受影響的部分。

交付時保留專案版本、Git 基準、本次成功 Build、部署 UUID、檢查與量測結果，以及還需要處理的項目。原始內容、媒體、自訂程式與私有 .foliohaven/ 一起備份，之後就能接著目前的狀態更新。

後續的架構篇會說明渲染、建置與效能檢查，SEO 篇則沿用這份工作室與活動公告，整理設定繼承、文案與正式輸出。