AI Agent 內容營運 Runbook｜每日排程、驗證證據與人工交接

AI Agent 可以協助技術 Blog 每天產出內容、檢查路由、修正小型版面問題與整理報告，但如果沒有 Runbook，Agent 很容易只完成「看起來有做事」的片段：寫了一篇文章，卻沒有確認 sitemap；修了一個樣式，卻沒有跑 build；看到 production 404，卻沒有分辨是部署延遲還是內容根本沒被提交。

UCAMC 這類由舊 WordPress Blog 延伸到 Next.js 的內容站，更適合把每日營運拆成可重複、可驗證、可交接的流程。這篇 Runbook 延伸先前的 AI Agent 網站維護 Prompt 模板與 Next.js 內容站每日 SEO 檢查清單，目標是讓 Agent 每天不只「新增內容」，也能留下可追蹤的品質證據。

1. 先定義每日排程的安全邊界

每日任務要先寫清楚哪些事情 Agent 可以自主處理，哪些事情必須交給站長決策。這能避免自動化流程在沒有使用者即時回覆時，做出不可逆或破壞 SEO 的改動。

類型	Agent 可自主處理	需要人工確認
內容	新增原創技術文章、補 frontmatter、補內部連結	刪除大量舊文、改大量 slug、改品牌定位
技術	修小型 lint/type/build 問題、補 sitemap/robots 檢查	更換架構、移除 WordPress 串接、修改機密
SEO	驗證 canonical、metadata、root-level 文章 URL	改變整站 canonical URL 策略
版面	修 placeholder、裸露 URL、明顯溢出	重做 Logo、換整體視覺風格

對 UCAMC 而言，文章 canonical URL 是 root-level /{slug}，/blog 只是列表頁。這種規則必須寫在 Runbook 裡，避免 Agent 每天又回頭檢查或新增不需要的 /blog/{slug} redirect。

2. 每次執行都從工作區狀態開始

自動化內容營運最容易踩到的問題，是前一次工作留下未提交或未追蹤檔案。新的 Agent run 如果直接寫檔，就可能覆蓋未理解的變更。

建議每次排程開始都固定檢查：

git status --short
git branch --show-current
git log -1 --oneline

檢查重點不是只看乾不乾淨，而是要能判斷：

是否已有未追蹤 Markdown 文章需要保留。
是否有 macOS 複製檔或 build artifact 不應提交。
是否有 staged 變更可能是前一輪有效工作。
是否目前分支就是預期的 production branch。

若工作區不乾淨，Runbook 應要求 Agent 先辨識來源、保留未知變更，必要時在報告中明確列出「本次未處理的既有變更」。

3. 把內容產出拆成 metadata、正文與驗證

一篇新文章不應只看 Markdown 能不能被讀取。對內容品牌網站來說，完整 frontmatter 會影響列表排序、SEO、社群預覽、Open Graph 圖片與 sitemap 更新。

建議新文章至少要有：

title: "文章標題"
slug: "stable-root-level-slug"
date: "2026-07-14T09:10:00+08:00"
modified: "2026-07-14T09:10:00+08:00"
excerpt: "清楚描述文章能幫讀者完成什麼。"
categories:
  - "網站經營"
tags:
  - "檢查清單"
author: "UCAMC"
seoTitle: "搜尋結果可閱讀的標題"
seoDescription: "搜尋結果與社群預覽可使用的摘要。"
coverImage: "https://..."
coverAlt: "描述圖片內容與文章脈絡"
featuredImage: "https://..."
draft: false
archive: false

正文則要避免只像內部任務紀錄。較好的做法是把維護經驗轉成讀者可複用的模板、檢查表、流程圖或欄位清單，讓文章本身成為可被收藏的內容資產。

4. 驗證證據要能被交接

AI Agent 的回報不應只寫「已完成」。更可靠的方式，是把每個重要檢查項目對應到真實輸出：

檢查項目	建議證據
lint/type	`npm run lint` exit code 0
production build	`npm run build` 成功輸出
首頁	local production `/` 回 200，且包含新文章標題或最新卡片
Blog 列表	`/blog` 回 200，第一張卡片連到新 slug
文章頁	`/{slug}` 回 200，metadata/OG 圖片合理
sitemap	`/sitemap.xml` 回 200 並包含新 slug
robots	`/robots.txt` 回 200 並指向 sitemap
legacy redirect	ID-prefixed 舊網址 301 到 root-level slug

這些證據讓下一位維護者可以快速判斷問題在哪一層：內容檔案、Next.js build、本機 route、GitHub push、Vercel 部署，或正式網域快取。

5. 失敗時先分類，不要急著重構

當自動化流程失敗時，Agent 應先分類問題，而不是直接大改架構。

常見分類：

內容錯誤： frontmatter 缺欄位、日期格式不一致、Markdown 表格破損。
型別錯誤： App Router params 型別、metadata 回傳型別、元件 props 不一致。
本機快取錯誤： .next 舊型別檔、tsbuildinfo、node_modules 檔案讀取異常。
路由策略錯誤： 把新文章誤認為應該有 /blog/{slug} canonical。
部署邊界： 本機與 GitHub 正常，但 Vercel 或正式網域仍舊內容。

分類之後再修，才能避免把一次快取問題變成不必要的架構變更。

6. 每日報告要短，但要有判斷力

好的每日報告不需要很長，但必須能回答三個問題：今天網站更好了嗎？哪些證據能證明？還有什麼需要站長決策？

建議固定格式：

UCAMC 每日網站經營報告
日期：YYYY-MM-DD

檢查範圍：首頁、Blog、文章頁、分類頁、robots、sitemap。
新增/整理文章：標題、slug、主題價值。
修復項目：列出實際修改，不包裝成大工程。
lint/build：列出真實結果。
route/SEO 驗證：列出 status code 與包含新 slug 的證據。
下一步：1–3 個可執行建議。

重點是：不要把未驗證的 production 狀態寫成成功；不要把需要 Leon 決策的事項自行處理；也不要因為沒有大問題就省略內容營運成果。

7. 可複製的最小 Runbook

最後把流程壓縮成一份每日可執行清單：

讀取專案規範與每日營運計劃。
檢查 git 狀態與最新 commit。
巡檢首頁、Blog、文章頁、分類頁與 SEO routes。
新增或整理一篇有完整 metadata、圖片與內部連結的文章。
驗證外部圖片回 200 且是 image content type。
執行 lint、build。
啟動 production server，驗證 /、/blog、/{slug}、分類頁、/robots.txt、/sitemap.xml、ID-prefixed legacy redirect。
若推送 production，輪詢 Vercel 與正式網域直到新文章、列表與 sitemap 都更新。
產出包含真實證據的繁體中文報告。

這樣的 Runbook 讓 AI Agent 從「自動寫文章」升級成「可交接的內容營運流程」。對長期經營的技術品牌網站而言，穩定留下證據，比每天做出很多不可追蹤的變更更重要。

AI Agent 內容營運 Runbook：每日排程、驗證證據與人工交接