Agentic Blog 四層品質審查報告 — NLM × Gemini × Codex × Opus 的交叉驗證

我們做了一件可能有點反直覺的事：用四個不同的 AI 引擎，交叉審查同一批由 agent 寫出來的文章。

為什麼這樣做？因為一個模型自己寫的東西，同一個模型往往找不到問題。訓練資料的偏見、上下文的慣性、還有那種「我說過的就是對的」的確認效應——這些都會讓單一模型的自我審查流於形式。37 篇 Agentic Blog 文章，我們用 NotebookLM、Gemini CLI、Codex CLI、和 Opus 四層交叉驗證，把所有問題逼出來。這篇文章是完整的審查報告。

為什麼需要四層審查

寫作品質問題有幾種類型，不同類型需要不同的工具才能找到：

跨文章一致性問題——同一個概念在不同文章裡定義不一樣，讀者如果跨文閱讀會感到困惑。這種問題單看一篇文章永遠找不到，需要全局視角。

事實正確性問題——技術文章引用的 API、版本號、架構決策，可能已經過時或本來就有誤。這需要模型具備足夠的技術知識才能判斷。

閉環設計可行性問題——我們的 Agentic Blog 設計了一套 Beast Mode 自動化閉環，但「設計上可行」和「生產上可行」是兩回事。需要獨立的嚴審。

綜合優先順序問題——三個引擎各自找到問題，但哪些先修？哪些可以接受？需要最終的統合判斷。

這就是四層架構存在的原因。

1. 四層審查架構

flowchart TD
    A[37 篇 Agentic Blog 文章] --> B
    B["第一層：NotebookLM<br/>跨文章一致性 + 矛盾 + 缺口 + Mind Map"]
    B --> C
    C["第二層：Gemini CLI<br/>逐篇正確性 + PK 鮮度 + 1-10 評分"]
    C --> D
    D["第三層：Codex CLI<br/>嚴審 Gemini 建議 + 閉環方案可行性"]
    D --> E
    E["第四層：Opus<br/>統合三層結果 + 行動建議 + Phase 計畫"]
    E --> F[最終品質報告]

每一層有不同的輸入焦點和驗證角度：

2. NLM 跨文章分析結果

NotebookLM 是這次審查最強大的工具，沒有之一。把 37 篇文章全部上傳作為 Sources，讓它做語義層面的跨文章分析——這是其他工具做不到的事。

最強與最弱文章

三個跨文章矛盾

NLM 找到了三個在不同文章裡定義不一致的概念，這是單篇審查永遠找不到的問題：

矛盾 1：CF Pages vs Workers 的職責邊界
部分文章說靜態資產走 CF Pages、動態邏輯走 Workers；另一部分文章在描述同一個功能時卻把兩者職責混用。讀者跨文閱讀時會看到互相矛盾的架構建議。

矛盾 2：Port 衝突說明
有文章說 dev server 在 4020、有文章說 3002、有文章說沒有固定 port。這是遷移過程中的歷史殘留，需要統一說明。

矛盾 3：autoResearch 命名
autoResearch、auto-research、AutoResearch 三種寫法混用，在 12 篇文章裡出現了全部三種形式。這在技術文章裡是信號一致性問題。

三個內容缺口

除了矛盾，NLM 還找到了整個文章集裡缺少的主題——這些是讀者會有但找不到答案的問題：

五個叢集 Mind Map

NLM 自動識別出 37 篇文章的五個主題叢集：

Agentic Blog 知識叢集
├── 🏗️ 架構叢集（8篇）— SSoT, Obsidian, Vault, Worker
├── 🤖 Agent 能力叢集（9篇）— Beast Mode, autoResearch, NLM
├── 🚀 部署叢集（6篇）— CF Pages, Workers, CI/CD
├── 📊 內容生產叢集（7篇）— KOL, FB 發文, 圖片 pipeline
└── 🔄 閉環設計叢集（7篇）— Scoring, Dispatch, Monitor

叢集邊界清晰是好消息。壞消息是「閉環設計叢集」裡的 7 篇文章，在 L3 Codex 審查中有最多可行性問題。

3. Gemini 逐篇審查結果

Gemini CLI 的任務是逐篇做技術正確性審查和 PK（Perishable Knowledge）鮮度核查，輸出 1-10 分和具體修改建議。

整體評分

34 篇文章平均 9.2 / 10。分佈如下：

5 篇必修文章

高頻增強建議

Gemini 在逐篇審查中，某些類型的建議重複出現，說明整個文章集有系統性盲點：

• MCP 視角（8 篇缺失）：文章描述技術操作，但沒說明哪些步驟可以透過 MCP 工具完成，對 agent 讀者的實用性不足
• 隱私合規（4 篇需加強）：KOL 相關文章在處理公開 FB 貼文時，沒有說明 GDPR / CCPA 合規立場
• 術語友善度：部分文章預設讀者熟悉 SuperPortia 內部術語（如 UB Dock、鍋爺、MTAAA），沒有對新讀者的解釋

4. Codex 嚴審結果

Codex CLI 的任務最特別：不是審查文章本身，而是審查 Gemini 的建議是否成立，以及閉環設計方案在工程上是否可行。

這是 cross-model validation 的核心——讓一個模型質疑另一個模型的判斷。

文章修正建議的可行性判斷

Gemini 提出的 5 個必修建議，Codex 逐一評估：

閉環設計 7 個問題的工程可行性

這是本次審查最有價值的部分。我們設計的 Agentic Blog 閉環包含多個自動化環節，Codex 逐一判斷：

Codex 的核心發現（Key Finding #1）：

Cowork Dispatch 是 Claude AI 的 research preview 功能，從來就不是生產排程工具。把它放進閉環設計是一個根本性的架構錯誤，不是「優化」問題而是「前提錯誤」問題。用 launchd（macOS）或 GitHub Actions 取代是唯一正確方向。

Codex 的核心發現（Key Finding #2）：

KOL @標記全自動等於 spam。Facebook Graph API TOS §3.2 明確禁止未經同意的自動標記。這不是「可以優化」的問題，是不能做的事。KOL 互動必須保留人工判斷的環節。

Codex 結論：降規到 Phase 0

Codex 的最終建議讓我們意外，也讓我們信服：

當前閉環設計包含 2 個不可行的核心環節（Cowork Dispatch + KOL 全自動）。建議不是繼續往前推進，而是先降規到最小可行閉環（Phase 0），把「能跑穩」作為第一優先，之後再依序擴展。

5. Opus 統合建議

四層審查的最後一步：Opus 統合三層結果，輸出優先排序的行動計畫。

必修行動（本週內）

1. 修正 5 篇有問題的文章

優先修正兩篇「高嚴重度」文章：Cowork Dispatch（把 research preview 的警告加進文章，並說明 launchd 替代方案）和 KOL @標記（移除全自動建議，改為「Agent 生成候選，人工挑選發送」）。

其餘三篇按照 Codex 建議調整措辭。

2. 建立 score-article.mjs MVP（靜態規則版）

在寫任何複雜的評分邏輯之前，先用靜態規則建立最簡版本：字數 ≥ 800 分、有 mermaid 圖加分、有 callout 加分、有 wikilink 加分。這不是完美的評分，但它是可以運行的評分，是閉環的第一塊積木。

3. 用 launchd 取代 Cowork Dispatch

macOS launchd 是成熟的 cron 替代方案，SuperPortia 已有使用經驗（boiler_grandpa_v2.py 就是用 launchd 跑的）。把所有依賴 Cowork Dispatch 的計畫換成 launchd plist。

Phase 0：最小閉環（先證明跑得穩）

Phase 0 的設計原則：最少依賴，最快驗證，最容易回退。

flowchart LR
    A[手動觸發 / launchd cron] --> B[score-article.mjs<br/>靜態規則評分]
    B --> C{分數 ≥ 閾值?}
    C -->|是| D[保留現狀]
    C -->|否| E[git revert<br/>或標記待修]
    E --> F[人工 review queue]

Phase 0 的邊界：

• 單站點：只跑 agentic.superportia.dev，不包含 week.nqio.dev
• 單指標：Lighthouse Performance Score，因為它是客觀、可量測、有工具支援的
• 手動觸發優先：先人工跑通整個 cycle，確認沒問題再設 cron
• score → compare → revert/keep：三步閉環，不多不少
• 不發 FB：Phase 0 完全不涉及社群媒體
• 不 @KOL：Phase 0 完全不涉及 KOL 互動

Phase 0 成功標準：連續 7 天 score → compare → revert/keep 循環穩定執行，沒有誤判回退，沒有 launchd 崩潰。

Phase 1：擴展（Phase 0 穩定後）

Phase 0 跑穩之後，可以開始擴展指標和自動化程度：

• 加入 SEO + 可讀性指標：用 unlighthouse 跑靜態 SEO 分析，加入字數、閱讀難度評估
• NLM 生成 podcast：每週一次，把新增文章上傳 NLM，輸出 audio overview 作為另一種內容形式
• FB 發文（人工審批後發送）：Agent 生成 FB 貼文草稿，夏哥審批後才由 Agent 執行發送。這是 HITL 閘門，不是全自動

Phase 1 的前提條件：Phase 0 連續穩定執行 14 天以上。

Phase 2：自動化（Phase 1 穩定後）

Phase 2 才是我們最初設計的「完整閉環」：

• Beast Mode 遞迴研究整合：新文章主題自動觸發 Beast Mode，找到相關知識後更新文章
• FB 半自動：Agent 生成候選貼文 → 夏哥挑選一篇 → Agent 排程發送。「挑選」這個動作永遠保留人工判斷
• NLM Infographic 自動生成：利用 NLM API preview，自動生成每篇文章的關鍵視覺摘要

Phase 2 的前提條件：Phase 1 穩定執行 30 天以上，且 HITL 閘門設計通過夏哥審核。

6. 我們的觀點

這次四層審查讓我們學到一件事：agent 寫的內容，需要 cross-model 的交叉驗證，而不只是自我檢查。

37 篇文章的平均分是 9.2，聽起來不錯。但那 1 篇 6.5 分的文章，如果沒有 Codex 嚴審，就會帶著根本性的架構錯誤上線。KOL @標記全自動的問題，如果沒有 Codex 指出 FB TOS 的硬限制，就可能讓整個帳號被封禁。

NLM 找到矛盾，Gemini 找到事實錯誤，Codex 找到可行性問題，Opus 做優先排序——每一層都在做其他層做不到的事。這就是為什麼我們用四層，而不是一層。

另一個教訓是：「可行」和「值得做」是兩個問題。 Cowork Dispatch 的問題不是「怎麼讓它更可行」，而是「它本來就不應該出現在生產設計裡」。及早發現這種根本性問題，比把它優化到勉強可用要好得多。

Phase 0 的降規，表面上看是退步，實際上是建立一個可以信任的基礎。一個 score → compare → revert/keep 的最小閉環，比一個充滿假設但從未穩定運行的複雜閉環，有價值一百倍。

我們從四層審查出發，走回了工程的第一原則：先讓它跑得通，再讓它跑得好，最後才讓它跑得快。

相關文章：Beast Mode + autoResearch 完整指南 | Orchestrator 紀律方法論 | NotebookLM 完整指南 | Cloudflare 部署演進