AI Agent 維護 Next.js 技術站的 Vercel 發佈檢查清單
當技術內容站開始由 AI Agent 協助維護後，最重要的不是讓 Agent 每天「做很多事」，而是讓每一次更新都能被檢查、被驗證、被回報。對 UCAMC 這類從 WordPress 遷移到 Next.js 的內容站來說，Vercel 發佈流程就是每日營運能否穩定累積的關鍵。
這篇筆記整理一份可重複使用的檢查清單，讓 AI Agent 在新增文章、調整 route、修正 SEO 或整理版面時，不會只停在「本機看起來可以」，而是能接近正式網站維護的標準。
1. 發佈前先確認工作樹狀態
AI Agent 開始修改前，應先檢查 git status。這一步的目的不是形式，而是避免覆蓋人類或其他 Agent 已經留下的變更。
如果看到不明修改，建議採取保守策略：
- 可辨識的小型變更先保留，不任意重寫。
- 與本次任務無關的檔案不要順手整理。
- 若涉及機密、部署設定或大量內容刪除，保留現狀並列入回報。
對長期經營的網站來說，穩定比一次修很多更重要。
2. route 檢查要符合 canonical 策略
UCAMC 目前的文章 canonical URL 是 root-level /{slug}，例如 /ai-agent-website-operation-workflow。/blog 是文章列表頁，不是文章詳細頁的 canonical 前綴。
因此日常檢查時應聚焦在：
/首頁是否正常。/blog列表頁是否正常。/{slug}文章頁是否正常。/category/{category}分類頁是否正常。- 舊 WordPress ID-prefixed URL，例如
/{id}-{slug}是否 301 到/{slug}。
不要把新文章的 /blog/{slug} 404 視為錯誤；那不是 UCAMC 的 canonical 策略。
3. 每次內容更新都要檢查 SEO 入口
新增文章不只是新增 Markdown 檔。至少要確認 frontmatter 能支撐列表頁、文章頁與搜尋引擎摘要：
title與slug清楚且不互相衝突。excerpt可以直接顯示在首頁與 Blog 卡片中。seoTitle與seoDescription不是關鍵字堆疊，而是準確描述文章。categories與tags能引導讀者前往相關內容。draft: false代表文章可被正式收錄。
完成後，應驗證 sitemap.xml 是否包含新文章 URL，robots.txt 是否仍指向正確 sitemap。
4. build 與 production-mode 驗證不能省略
Next.js 內容站很容易出現「開發模式可以、本機 build 才壞」的狀況，尤其是 Markdown frontmatter、App Router dynamic params、靜態產生與 metadata 相關問題。
建議每次更新後都執行：
npm run lint
npm run build
npm run start -- --hostname 127.0.0.1 --port 3000
接著用 curl 驗證代表性 URL。這樣可以確認頁面不是只在原始碼中存在，而是真的能由 production server 正常回應。
5. 回報要留下可追蹤證據
每日營運報告應該簡潔，但要有真實證據，例如：
- 修改了哪些檔案。
- 新增或整理了哪一篇文章。
npm run lint與npm run build的結果。/、/blog、新文章、分類頁、robots.txt、sitemap.xml、legacy redirect 的狀態碼。- 有哪些需要 Leon 決策的事項。
這種回報方式能讓網站維護逐步累積成營運紀錄，而不是零散的技術操作。
小結
AI Agent 維護技術網站的價值，不是取代所有人工判斷，而是把每天都需要重複、但又不能出錯的檢查流程穩定執行。當 route、SEO、內容 frontmatter、build 與正式模式驗證都被納入流程，UCAMC 就能從舊 Blog 封存逐步成長為持續運作的技術內容品牌。
延伸閱讀：可以搭配閱讀 AI Agent 如何協助技術網站進入每日營運模式，把本文的發佈檢查清單放進每日營運節奏中一起執行。