WordPress 內容自動化流水線：從研究選題到穩定發佈的實務架構（初稿）
> 產出時間：2026-04-30（Asia/Taipei）
> 參考來源：工作區內 topic 研究池、任務記憶與「WordPress skill vs 方案」任務卡；**非**單一即時新聞稿，而是**可長期運作**的編排與技術說明。
摘要
本稿描述一條以「每 6 小時產文並發佈」為願景的 **WordPress 自動化內容流水線**：目標是**可維運的管線**而非單篇文章。實務上採**研究／選題 → 寫稿 → 圖片 → 發佈**分階段推進；技術上依站點型態在 **自架 WordPress（REST + Application Password）**、**WordPress.com（OAuth2 + 官方 API）**、**WP-CLI（可 SSH 時）** 間分流；同步處理 **cron／編排層逾時** 與 **引用與合規** 等治理議題。下列各節可直接作為內部 SOP 或對外知識文之骨架。
—
1. 目標定義：流水線，不是單次投稿
– **正式目標**：建立可長期運作、可觀測、可回滾的**自動化內容流水線**。
– **非目標**：單一爆款文、或「固定腳本直出」作為唯一主路徑（腳本直出僅作 **fallback**，研究品質不可長期被犧牲）。
與單次發文相比，流水線多出的責任包括：狀態可追（草稿 ID、任務階段）、失敗可重試、權限可撤銷、與**選題來源**可稽核。
—
2. 階段化流程（預設單輪只推一個 stage）
| 階段 | 內容 | 產出物（例） |
|——|——|—————-|
| 研究／選題 | 熱榜、趨勢、品牌邊界、合規 | 研究摘要、候選標題、禁止題清單 |
| 寫稿 | 結構、段落、內部連結策略 | Markdown 主稿 |
| 圖片 | 版權、尺寸、alt | 圖片審查紀錄、檔名規則 |
| 發佈 | 草稿／排程／已發 | post id、狀態、錯誤碼 |
**狀態真實來源（SSOT）**：以**本地**任務卡／工作流狀態為主；Notion 等可當看板與備援，**不**作唯一真相來源（與團隊既定決策一致時從之）。
—
3. 技術路線分流（與「skill vs 方案」任務卡對齊）
3.1 站點型態
– **自架 WordPress**
– 主線：**WordPress REST API**（如 `/wp/v2/posts`），認證採 **Application Passwords（Basic Auth）**。
– 已知官方能力：可建立文章並控制 `status`。
– **WordPress.com**
– **獨立 API + OAuth2**；不可假設與自架 REST + App Password 同一套路。
– **可 SSH、主機可控**
– **WP-CLI**（如 `wp post create`）可作為比「跨網路 REST」更穩定的替代；REST **不是**唯一主線。
3.2 明確排除或非主線
| 做法 | 定位 |
|——|——|
| XML-RPC | 新專案**不作主線** |
| wp-admin UI 自動化 | **不作主線** |
| n8n／Zapier 等 | 可作 MVP **加速**，**不**作核心依賴 |
| 第三方 SaaS 包全套 | **不**將核心流程完全外包 |
3.3 失敗治理（摘要）
對 REST／API 呼叫至少區分：**401／403／400／429／5xx**，並定義重試、退避、人工介入與**憑證輪替／撤銷**。完成定義應包含：**能否穩定建立草稿或發佈並回報狀態**、**權限最小化**、**媒體與排程**是否涵蓋。
—
4. 選題與「下一階段研究」的銜接（來自 2026-04-30 議題池）
將「熱門議題池」轉成可排程的編輯規則時，建議優先研究下列方向（可直接作為 backlog）：
1. **Threads「趨勢話題」規則化**：前五主題＋摘要 → 草稿標題／首段（**合規與來源標註**）。
2. **熱搜懶人包模板**：政治／消費／國際分欄、更新頻率、內部連結。
3. **高互動迷因題**：是否納入輕量娛樂分類與**品牌調性邊界**。
4. **國際線／在地線自動路由**：例如油價運河 vs 人物質詢 → **分類規則**。
5. **資料來源治理**：第三方榜單 vs Google Trends vs 原媒體 → **自動化最低引用層級**。
**限制**：無單一權威「此刻」全網排序；即時榜需以 Trends、官方或第一線媒體**交叉驗證**。若需瀏覽器級取樣或 SERP 重跑，應由具對應能力的路徑執行，而非假設單一工具覆蓋。
—
5. 維運現況與已知痛點（依任務記憶）
– **觀察**：主要失敗點較常落在 **`cron → agent／session → 編排` 層的逾時**（例如 `cron: job execution timed out`），**不一定**是 WordPress 發布器本身。
– **對照**：**手動最小路徑**曾成功建立 WordPress **草稿**（例如 post id 3255），代表發佈鏈路在可控條件下可通。
– **主機／閘道層**：若需排查 cron 逾時與執行鏈，應交由具宿主權限的一方（例如既定流程中的 Cursor／維運）處理，**容器內助理不可假設已改完宿主設定**。
—
6. Fallback 與延續性
– **研究／品質**：寧可多輪推進單一 stage，也不要為穩定而永久降級為無查證直出。
– **技術**：REST 失敗時可評估 WP-CLI、排程降載、縮小單次 prompt；第三方自動化僅作輔助。
– **脈絡延續**：任務應可由簡短口令喚回（例如先讀 `current-focus` 再接續），避免「失憶即重開」浪費成本。
—
7. 建議的下一步（給主線／編排）
1. 盤點站點型態（自架 vs WP.com）並鎖定 **PoC-A／PoC-B** 其中一條為近期預設路徑。
2. 將 **cron／逾時** 與 **WordPress API 成功路徑** 分開觀測（指標、log、告警）。
3. 把「議題池 → 草稿」化成可排程的 **規則表**（含禁止題、引用層級、分類路由）。
4. 補齊 **E2E 憑證演練與回滾**（任務卡中標為待完成項）。
—
草稿後記（供主線验收）
– **本稿假設**：上游「研究結果」以工作區已落地之 topic 池、記憶與 WP 方案卡為準；**未**另附獨立研究報告全文。
– **若需重寫**：建議先補「站點實際 URL／憑證型態／目前 cron 秒數與 timeout 設定」三項事實，再將 §3、§5 改寫為**完全對應貴站**的版本；讀者可另增一篇「純營運／讀者向」刪去技術細節。
