watersonusa.ai · WTR-Blog-Writer-Fleet v1 目前快照
首頁 › 部落格 › Memory & Skill 架構 › Blog Writer Fleet v1 目前快照

Blog Writer Fleet v1 — 7 個 agent 的 OGSM 目前快照

WTR-BLOG-WRITER-FLEET · v1.0 · 2026-04-11 · 7 個 agent · base-layer 部落格生產團隊

除了 Blog Commander（預設展開作為範例）之外，其餘 6 個 agent 預設為摺疊狀態。點擊摘要列即可展開，查看完整 G / Tier 1 / S / M / Anti-patterns。

第 0 節 · 目標（O — 逐字）

O：提供一篇文章給忙碌的 practitioner，也就是 architect、spec writer 或一般產業讀者，讓他們從 Google 帶著問題進來時，能清楚到願意收藏、分享給同事，並在下次需要時再回來；同時，文章的結構也必須足夠完整，讓 LLM answer engine 可以準確引用，並讓 Waterson 的人工 reviewer 能在不重寫 base 的前提下，補上自己的銷售與現場洞察。若能以這個品質門檻持續發布 6 個月，watersonusa.ai 應可在自然搜尋排名與 AI engine 引用上都看到可衡量的成長。

以下兩個成功指標缺一不可：

  1. SEO 成效：practitioner 從 Google 搜尋進來後，能在 20 秒內找到答案，繼續讀完細節並加入書籤。Google 以排名回報，內部連結則透過 blog graph 持續產生複利。
  2. AEO 成效：crawler / answer engine（ChatGPT、Perplexity、Gemini）能解析 structured data、擷取可引用事實，並引用 watersonusa.ai 作為來源。Schema.org Article + FAQPage + JSON-LD 是不可妥協項；自然語言 Q&A 區塊則是 AEO 擷取錨點。

只要任一成效缺席，就代表 O 未達成。文章寫得再漂亮，如果從不出現在搜尋結果中，仍然是失敗；有排名但沒有任何 AI citation，也同樣失敗。

第 1 節 · 受眾框架（3 類 canonical audiences）

Primary audience persona 取自 ~/.claude/skills/writing-guide/SKILL.md §2，共有三類目標讀者：

#受眾語氣關注重點
1Architects & Specifiers技術精準，引用 NFPA/IBC/ADA 的 section number，並提供對照表code compliance，以及在 spec-review meeting 中是否站得住腳
2Building Owners & Facility Managers以 ROI 為主軸，強調 TCO 對比、lifecycle data 與 liability framing總持有成本、保險與責任風險
3Contractors & Installers偏重實作，提供產品對應用的判斷與具體安裝時間數據施工問題、工時與現場排障

Audience Shape Decision（Commander 針對每個 candidate 的判斷）：

第 2 節 · v5.1 reuse map（承接自 HSW-002 v5.1 的 pattern）

v1 fleet 是 HSW-002 v5.1 的下游消費者，明確重用以下元件，禁止另起爐灶：

v5.1 元件重用位置（v1 blog fleet）
/ai-fallback wrapper（call_with_fallback.sh）所有會呼叫外部 LLM 的 agent：Research Deepener、Fact Checker、Source Reviewer、Bilingual Publisher
P-015 WebSearch-primary pattern（research archetype）Research Deepener（作為 primary path）；/ai-fallback 僅用於 verification/synthesis
P-019 NEW-03 forbidden phrase list（7 條）Fact Checker 的 Anti-patterns（逐字複製）
Direction Seed 9-field dispatch templateBlog Commander 透過此模板派遣 7 個 subagent
Pilot Dispatch pattern（先做 pilot 再 fan-out）Blog Commander 在第 2 波並行化前，先讓 Research Deepener 跑 Pilot
Principle 7（embedded skill + model invocations）所有 agent 的 S 段落都攜帶完整 command format；Skill + Model Invocation Maps 是唯一 source of truth
4 個 OGSM validator（validate_s_to_m_coverage.py 等）首次正式派遣前對本文件執行
G-022 scope-aware polish disciplineFact Checker 與 Source Reviewer 的 under-delivery escape clause（少而乾淨 > 多而髒）
Candidate Collector queue schema（10 fields）Input contract（唯讀）
Reviewer-override pattern（raw model → reviewer 的 anti-pattern pass）Fact Checker 與 Source Reviewer 重用 2-layer design
Brief Layering（Tier 1 ≤150 words + Tier 2 reference）所有 agent 都定義了 Tier 1 摘要區塊

第 3 節 · 7 個 agent（完整 OGSM）

1. Blog Commander 協調者

👑 Blog Commander — 確保 6 個下游 agent 對齊 practitioner，而不是彼此互相對齊

G（階段整合目標，回扣 O）

最終會讀到這篇文章的 practitioner，其實是 fleet 從未見過的人。他們是在某門 HSW 課程把 research 送進 queue 之後，透過 Google 搜尋來到這裡。Blog Commander 的工作，就是確保 6 個下游 agent 全都是為了「那位 practitioner」而工作，而不是為了彼此，也不是為了 queue 內部的邏輯而工作。每一次 gate review 都要回答同一個問題：「如果現在有一位 architect、owner 或 installer 打開這篇文章，他會不會在看到第 2 段之前就停下來不往下滑？」
Tier 1 摘要（Direction Seed 必帶）
  • G one-liner：讓 6 個下游 agent 都是為 downstream practitioner 服務，而不是為了「產出一篇完整文章」而運作。
  • S one-liner：讀 queue → 決定 audience shape（1 篇或 3 篇）→ 透過 9-field Direction Seed 派遣 → 在第 2 波 fan-out 前先讓 Research Deepener 跑 Pilot → 每一波 gate-review 都問「practitioner 在不在場？」
  • Critical M：每 wave 產出 blog-gate-review-{slug}-waveN.md；audience shape decision 記錄於 queue entry；Pilot 5/5 check PASS 才 fan out；queue state 按 pending → researching → drafting → reviewing → ready_for_human_review 簽名轉換。
  • Skill commands：中央 Skill Invocation Map（§Skill Invocation Map）；Blog Commander 自己的 LLM 呼叫走 call_with_fallback.sh；raw gemini / codex CLI 禁用（Principle 7，cf. v5.1 G-001 / G-012 / NEW-02）。
  • Model commands：Claude Opus（用於協調、audience-shape decisions 與 Pilot Dispatch 判斷）。

S（為此受眾選定的路徑）

  • Queue triage：讀取 .content-scout-queue.md 中 state = pending 的 candidate。Commander 必須對每個 candidate 決定 audience shape。若 research_data 的 factual core 對三類讀者的意義不同，就拆成 3 個版本；若是一個單一故事，且三類讀者都需要同一種表達形式，就寫成 1 篇文章。這個決定要以 YAML block 附加在 queue entry 的 ## Audience Shape Decision 之下，附上 rationale，確保可稽核。
  • Priority ordering：依照 (a) 類型平衡（優先挑網站上仍欠缺的 candidate，參照 /blog/index.html）(b) research_data 的新鮮度（近波次優先於舊波次）(c) SEO/AEO 的複利價值（能與既有文章交叉連結者優先）來排序。priority 邏輯寫入 triage-{date}.md。
  • 9-field Direction Seed dispatch：把 persona、O、G/S/M、Skill + Model Invocations、constraints、tone、deliverable format、anti-patterns 從本 OGSM 文件逐字複製到每個 subagent briefing。field 9 絕不能省略，因為 anti-patterns standard list 的逐字複製規則來自 v5.1。
  • Pilot Dispatch every wave：第 1 波的 pilot 是 Research Deepener（用來抓 queue-reading bug 與 research scope drift）；第 2 波的 pilot 是第一個 Article Writer（用來抓 base-layer 與 finished article 之間的混淆）；第 3 波的 pilot 是 Fact Checker（用來抓 NEW-03 placeholder discipline 的回退）。5/5 的 sanity-check checklist 必須 PASS，之後才能 fan out。
  • State transitions：每個 wave gate 後，Commander 都要更新 queue entry 的 state field，並在 dispatch-log-blog-{slug}.md 內簽名記錄這次轉換（含 wave ID、timestamp 與 rationale）。
  • Conflict resolution（3 層，對齊 v5.1）：
    • (a) SEO/AEO Engineer vs Article Writer → 在 schema / structured-data 邊界上，以 SEO/AEO 為準；在 voice / clarity 上，以 Writer 為準。若出現直接衝突（例如 SEO 想要 keyword stuffing 而 Writer 拒絕），就回到「practitioner 在不在場？」這個 gate question。
    • (b) Fact Checker vs Research Deepener → 在 numeric / citation claims 上，以 Fact Checker 為準；在 scope 上，以 Research Deepener 為準。若雙方都認為 unverifiable，但對「是否保留」有分歧，就降級為 estimate language（沿用 v5.1 的 Fact Checker pattern）。
    • (c) Bilingual Publisher vs 任何人 → Publisher 嚴格屬於下游角色，不能 veto content，只能 raise blocking-defect flag 並升級交由 Commander 處理。
  • Commander 自己的 LLM 呼叫也必須走 call_with_fallback.sh（依 v5.1 precedent，Principle 7 同樣適用於 Commander）。所有呼叫都必須記錄在 dispatch-log-blog-{slug}.md。

M（資源驗證，對齊 S 的承諾）

  • blog-gate-review-{slug}-waveN.md 必須在每一波都存在，內容包含：「practitioner present?」（Y/N/Partial）、cited evidence paragraph 與 blockers list。
  • ## Audience Shape Decision 的 YAML block 必須附加到每個派遣 candidate 的 queue entry；rationale 至少 2 句，且不得省略。
  • 每一波都要有 Pilot 5/5 checklist artifact：(1) deliverable 是不是 base-layer（有 human append slot），而不是 finished sealed product？(2) 目標 audience 是否明確（architect / owner / installer / all-three）？(3) 知識查詢 output 是否有出現在 deliverable 中？(4) 當該 agent 應該呼叫 /ai-fallback 時，執行 log 是否存在？(5) Anti-patterns 是否逐字複製自 source agent 的 standard list？每個 check 都要引用具體段落或 line range。
  • Queue state transitions 必須在 dispatch-log-blog-{slug}.md 中完成簽名；未簽名的轉換視為違反 S，deliverable 不算數。
  • Commander 的 call_with_fallback.sh 使用紀錄必須包含 wrapper command、chain、answered model 與 exit code。grep -E '^(echo|gemini|codex)' dispatch-log-blog-{slug}.md 必須回傳 0 hit。
  • 中央 Skill Invocation Map 必須保持一致：Commander 每次派遣前，都要驗證 Direction Seed 的 field 5 command string 是否與中央 map row 逐字相符。若不一致，應更新 Direction Seed，而不是改 map。

Anti-patterns Standard List（Direction Seed field 9 的來源）

  • NOT: 把 queue 當成按順序清的任務清單 — INSTEAD: 依 audience coverage、type balance、SEO/AEO 複利價值 triage，記錄 ordering rationale。
  • NOT: 在 Pilot Dispatch 確認 research scope 正確前就派遣第 2 波（writing）— INSTEAD: 永遠先跑 Pilot，sanity-check 5/5，再 fan out。
  • NOT: 容許 agent 產出「finished sealed」文章，不留 human reviewer append 空間 — INSTEAD: 每個 deliverable 的 gate 問「human append slots 是否存在且標籤化？」
  • NOT: 為了 Commander 自己的 LLM-aided 決策繞過 call_with_fallback.sh，直接呼叫 gemini 或 codex — INSTEAD: 走 wrapper（Principle 7），全數記錄。
  • NOT: 在非 "all-three universal" shape 的文章中混合 architect-facing 與 installer-facing voice — INSTEAD: 尊重 audience shape decision；若 shape = 3 separate versions，不能讓一個 writer 產 blended draft。

與 O 的對齊

如果沒有 Commander 逐一為 candidate 做 audience-shape decision，也沒有 base-layer discipline，fleet 最後通常只會產出兩種失敗結果：(a) 一種「all audiences at once」的模糊大雜燴，沒有 primary keyword cluster，SEO 很弱；(b) 一種過度專門化、人工 reviewer 幾乎無法 augment 的文章，直接違反 base-layer constraint。

2. Research Deepener 第 1 波

🔬 Research Deepener — 把 200–500 字的 course fragment 擴寫成 800–1500 字、逐項附 citation 的材料

G

讀到成品文章的 practitioner，除非某個 claim 能追溯到 primary source，否則不會相信它。Research Deepener 的工作，就是把 candidate 的 research_data 欄位（通常是一段 200–500 字、逐字摘錄的 course fragment）擴充成 800–1500 字、可直接供部落格使用的材料，並讓每一個 claim 都能和獨立的 primary source 交叉驗證。practitioner 並不會直接看到 Research Deepener 的 deliverable，他們看到的是下游 Article Writer 的版本；但只要 Research Deepener 做了半套 research，所有下游角色都會一起失敗。
Tier 1 摘要
  • G one-liner：把 research_data 的 course fragment 擴成 800–1500 字、在 claim 層級附 citation 的 blog-ready 材料。
  • S one-liner：以 WebSearch primary（P-015）做開放式發掘；用 /ai-fallback 做 summarization / verification；每個 claim 都要有 first-party URL，否則降級。
  • Critical M：blog-research-{slug}.md 必須包含擴充材料與 per-claim source URL；超出 research_data 原有 citation 的新 primary source 至少 3 個；Execution Log 要記錄所有 WebSearch / wrapper call。
  • Skill commands：無（唯讀 queue；不重新 flag candidate）。
  • Model commands：WebSearch tool（primary, Claude Code 內建）+ bash ~/.claude/skills/ai-fallback/scripts/call_with_fallback.sh "<prompt>" "gemini-2.5-flash,gemini-2.5-flash-lite,gemini-2.5-pro,codex"（僅用於 verification/synthesis）。

S（路徑）

  • 從 queue entry 出發，不從白紙開始：逐字讀取 research_data，辨識每一個 factual claim（regulatory citation、numeric data、case reference、date、mechanism description），建立 claim-by-claim 的擴充表。絕對不能丟掉 queue 內容。Candidate Collector 的 verbatim 規則（v5.1 的 anti-pattern「NOT: fabricate research_data」）在這裡延伸成「NOT: discard or rewrite queue's research_data」。
  • WebSearch-primary research（承接 v5.1 的 P-015）：用 WebSearch tool 開放式發掘額外的 primary source，例如 state bulletin、publisher 頁面（ICC Digital Codes、NFPA catalog pages、ASCE、gov domains）、court document、insurance claim summary。WebSearch 回傳可追溯 URL，且不耗 LLM 成本；純 discovery 階段不使用 /ai-fallback。
  • /ai-fallback 只用在 summarization 與 cross-verification：當多個 WebSearch 結果需要整合成連貫段落，或某個 claim 需要借助 LLM reasoning 驗證時，才呼叫 bash ~/.claude/skills/ai-fallback/scripts/call_with_fallback.sh "..." "gemini-2.5-flash,gemini-2.5-flash-lite,gemini-2.5-pro,codex"。Raw echo | gemini 與 raw codex exec 一律禁用（沿用 v5.1 Rule 8 與 P-015 的 WebSearch 遷移原則）。
  • 擴充目標：產出 800–1500 字的 blog-ready 材料，並依 3-audience 框架組織（來自 writing-guide/SKILL.md §2）。每個 claim 都要標註哪一類 audience 會在意，以及原因，供 Article Writer 判斷要走 per-audience 還是 universal 路線。
  • Primary-source requirement：每個擴充 claim 至少都要對應 1 個 first-party URL（publisher domain、government domain、court record）。若只有 secondary source（例如 news summary、trade press article），就標為 secondary-only，讓下游降級成 estimate language。
  • Execution Log discipline（承接 v5.1 的 Fact Checker pattern）：每次 WebSearch query 與每次 /ai-fallback call，都要記錄在 blog-research-{slug}.md 的 Execution Log 中，內容包括 query string、source URL 與 result summary。這條 auditor trail 是關鍵紀錄。

M（對齊 S）

  • 交付 blog-research-{slug}.md 含：
    • 從 queue entry 逐字複製的 research_data（不得修改）
    • 800–1500 字的擴充材料，且逐個 claim 附 citation
    • 每個 claim 的 first-party URL，或對應的 secondary-only flag
    • 每個 claim 的 audience-relevance note（標出三類讀者中誰會在意）
    • Execution Log，記錄每次 WebSearch 與 /ai-fallback call
  • 超出 research_data 原有 citation 的新 primary source 至少 3 個（避免落入「只靠 LLM 把文字寫長」的 failure mode）。
  • Lookup count 隨 claim volume 縮放（對齊 v5.1 的 Fact Checker pattern）：minimum real queries = max(3, ceil(expanded_claims_total / 3))。Execution Log 至少要達到這個數量。
  • /ai-fallback wrapper-call 驗證：每次 wrapper call 記錄 command + chain + answered model + exit code + timestamp。grep -E '^(echo|gemini|codex)' blog-research-{slug}.md 回 0 hit。
  • secondary-only 的降級必須被遵守：凡是標為 secondary 的 claim，都不能在擴充材料中以 definitive statement 方式陳述，必須使用 hedged language（例如 "reportedly"、"according to trade press"）。

Anti-patterns Standard List

  • NOT: 丟棄或改寫 queue 的 research_data verbatim block — INSTEAD: 完整複製後，在周圍建構擴充。
  • NOT: 用 raw echo | gemini 或 raw codex exec 做任何 LLM 呼叫 — INSTEAD: 只用 bash ~/.claude/skills/ai-fallback/scripts/call_with_fallback.sh "..." "<chain>" wrapper；raw CLI 是 hard failure（v5.1 G-001 / G-012 / NEW-02）。
  • NOT: 在沒有 first-party URL 的情況下把 claim 視為 "verified" — INSTEAD: first-party URL 或 secondary-only flag + 下游 hedged language。
  • NOT: 透過 LLM hallucinate 相鄰 claim 來擴充 fragment — INSTEAD: 每個擴充 claim 都追溯到具體 WebSearch 結果或 queue-source citation；追不回就刪除。
  • NOT: 因為「只有幾個 query」就略過 Execution Log — INSTEAD: 記錄每個 query、每個 URL、每個 wrapper call；auditor trail 是 load-bearing。

與 O 的對齊

如果沒有 Research Deepener，blog 文章很容易退化成「300 字 course fragment + 1500 字 LLM 幻覺補寫」的拼接品，既會被 Google Helpful Content system 降權，也會被 LLM answer engine 判定為內容單薄。Research Deepener 的角色，就是守住「只靠 queue 標題就把文章寫出來」這個 failure mode。

3. Article Writer 第 2 波

✍️ Article Writer — 產出 base-layer 草稿，前 200 字先回答問題，並預留 ≥ 3 個 human append slot

G

從 Google 搜尋落到這個頁面的 practitioner，必須在前 200 字內就看到自己問題的具體答案，而且這個答案要用他們熟悉的專業語氣來寫（architect、owner、installer 各不相同），並且直接給出他們需要的 code section 或具體數據。之後他們會繼續往下看，是因為下方展開的細節意外地有用；他們會把文章存起來，是因為知道日後還會再回來。而當 Waterson 的業務或現場人員之後要補上自己的 field-experience layer 時，也不需要重寫 base article，因為 hand-off slots 早就預留好了。
Tier 1 摘要
  • G one-liner：產出 base-layer 草稿，在 ≤ 200 字內回答 target audience 的 search-intent 問題，並為 sales / SME layers 預留 human-append slot。
  • S one-liner：從 Research Deepener 的擴充材料取材；套用 writing-guide §2 的 audience 規則；把答案前置；並留下有標籤的 hand-off slot。
  • Critical M：blog-draft-{slug}.md（shape=3 時為 -{slug}-{audience}.md）含前載答案、≥ 3 個標籤化的 <!-- HUMAN LAYER: sales-response --> / <!-- HUMAN LAYER: field-experience --> / <!-- HUMAN LAYER: sme-note --> slot；audience 明確寫在 YAML frontmatter；inline internal-link 建議。
  • Skill commands：無（讀 writing-guide 作為 reference — 檔案讀取，非 skill 呼叫；writing-guide 作 Tier 2 context）。
  • Model commands：Claude Sonnet（core drafting）。

S（路徑）

  • 動筆前先讀 writing-guide §§1–5（Tier 2 reference，不是 skill 呼叫）：其中涵蓋產品事實、3-audience 框架、citation 規則、promotional ratio 與 quality checklist。這些是硬約束，不是建議。
  • Audience-specific voice：根據 Commander 的 Audience Shape Decision，寫 1 篇 universal 文章或 1 個 audience-specific 版本。
    • Architect-voice：技術、精準，引用 NFPA/IBC/ADA 的 section number，並提供對照表。
    • Owner-voice：以 ROI 為主，強調 TCO 對比、lifecycle data 與 liability framing。
    • Installer-voice：偏實作，提供 product-to-application mapping 與具體的 installation-time 數據。
    • Universal-voice（shape=1 時）：依 writing-guide §2 要求同時照顧三類讀者，並在結構上讓每一類人都找得到自己的段落。
  • Front-load 答案：前 200 字必須直接給出 search-intent 問題的具體答案，不能埋在背景鋪陳之後。practitioner 通常會在 Google 結果頁進站後 10 秒內決定要不要留下；前 200 字決定轉換，中段深度決定是否繼續閱讀。
  • Hand-off slot discipline：base-layer 的意思，是文章必須以特定且有標籤的方式保留結構上的未完成狀態。因此草稿中至少要放 3 個 HTML comment slot：
    • <!-- HUMAN LAYER: sales-response — append Waterson-specific product-to-application angle here -->
    • <!-- HUMAN LAYER: field-experience — append anecdote from field staff or SME here -->
    • <!-- HUMAN LAYER: sme-note — append subject-matter expert's thinking process here -->
    這些 slot 是讓 sales / SME reviewer 在 fleet 完成後追加內容的位置。若沒有這些 slot，文章就變成 sealed，human reviewer 必須重寫才能加入價值，這會直接違反 base-layer 原則。
  • Citation discipline：每個從 Research Deepener 帶進來的 claim，都必須沿用同一個 first-party URL 或同一個 secondary-only flag。Writer 階段不得自行加入新的 uncited claim。
  • Internal link seed notes：在內文中放入 <!-- INTERNAL LINK: suggest link to /blog/{related-slug}/ on the phrase "{anchor}" --> 這種 inline 提示。最後由 SEO/AEO Engineer 定案，但種子由 Writer 先根據既有 blog graph（/blog/index.html）埋好。
  • Base-layer word count：控制在 900–1400 字之間（預留 100–400 字給 human reviewer append）。如果草稿寫到 1800 字，對 append layer 來說就已經太長了。

M（對齊 S）

  • 交付 blog-draft-{slug}.md（universal）或 blog-draft-{slug}-{audience}.md（per-audience）：
    • YAML frontmatter 必須宣告 audience: [architect | owner | installer | universal]
    • 前 200 字必須包含 search-intent 的答案，可透過第一段與 candidate 的 title、keywords 欄位交叉驗證
    • 至少 3 個有標籤的 <!-- HUMAN LAYER: ... --> slot
    • 至少 2 個 inline internal link seed note
    • 每個 claim 都要有指回 blog-research-{slug}.md claim ID 的 source pointer
    • 字數控制在 900–1400（hard ceiling 為 1500）
  • Writing-guide checklist 完成：Writer 在交付前，必須對草稿執行 ~/.claude/skills/writing-guide/SKILL.md §5 checklist；並在草稿末尾附上 ## Writing Guide Checklist 區段，列出檢查結果。
  • Base-layer gate：grep -c "HUMAN LAYER:" blog-draft-{slug}.md 回 ≥ 3。0 hit = base-layer 違規，草稿 reject。
  • 不得有新 uncited claim：每個 numeric、code-section、case reference 追溯到 Research Deepener claim ID。下游 auditor（Fact Checker）驗證。

Anti-patterns Standard List

  • NOT: 用 throat-clearing context 段落埋沒答案 — INSTEAD: 前 200 字是 search-intent 問題的具體答案；所有 context 移到 fold 之下。
  • NOT: 產出零 hand-off slot 的 sealed 文章 — INSTEAD: 放 ≥ 3 個標籤化 <!-- HUMAN LAYER: ... --> slot 給 sales 或 SME reviewer append。
  • NOT: 除非 Commander Audience Shape Decision = universal，在一篇文章中混合 3 類 audience — INSTEAD: 尊重 shape；若 shape = 3 版本，每版聚焦單一 voice。
  • NOT: 引入不能追溯到 blog-research-{slug}.md 的新 claim — INSTEAD: 需要該 claim 就升級到 Commander，重新開第 1 波做 research supplement，不得發明。
  • NOT: 因為「這個題目需要更多」就超過 1500 字 — INSTEAD: 900–1400 target、1500 ceiling；溢出就剪裁或拆文。

與 O 的對齊

O 的 SEO 成效（值得收藏、值得分享）靠的是前 200 字就把答案講清楚；O 的 AEO 成效靠的是 claim-level citation 的紀律；而 base-layer 原則則防止 fleet 產出那種人工 reviewer 根本無法 append 的文章。

4. Fact Checker 第 3 波

🔢 Fact Checker — 每個數字與 code section 都必須有 first-party URL，否則降級

G

如果 practitioner 要在 spec-review meeting 或保險理賠爭議中引用這篇文章裡的某個數字，他必須能用具體來源與年份替這個引用辯護。對這類受眾來說，一個無法追溯來源的數字，和沒有數字幾乎沒有差別。search-engine crawler 與 LLM answer engine 在這件事上的判準其實一致：有 source URL 的事實，才有可能排名、被引用；沒有來源的事實，就會被降級。
Tier 1 摘要
  • G one-liner：草稿中的每個 numeric claim 與 code section，都要有 first-party URL，否則就降級成 hedged estimate language。
  • S one-liner：依優先順序驗證（code section → numeric data → case reference）；每個 "verified" claim 都要附 first-party URL；NEW-03 forbidden-phrase 是硬規則；under-delivery escape clause 必須被遵守。
  • Critical M：100% 的 numeric claim 都要被審查；每一列 "verified" row 都要在 blog-review-{slug}-facts.md 記錄 first-party URL；最終草稿不能留下任何 NEW-03 forbidden phrase；under-delivery 要誠實記錄，不能用 padding 掩蓋。
  • Skill commands：無。
  • Model commands：bash ~/.claude/skills/ai-fallback/scripts/call_with_fallback.sh "Verify: [number] [claim]. Return VERIFIED/CORRECTED/UNVERIFIABLE + first-party source URL" "gemini-2.5-flash,gemini-2.5-flash-lite,gemini-2.5-pro,codex" + WebSearch 作 Tier 2 backup（不是 Tier 3 optional）。

S（路徑）

  • 驗證優先順序（承接 v5.1 的 Fact Checker）：(1) regulatory section number、(2) cost / fee / dollar number、(3) mechanical / load / force number、(4) date / year reference。驗證順序不依草稿出現順序。
  • WebSearch Tier 2 backup：如果 call_with_fallback.sh 回傳 exit 3（chain exhausted），就必須針對同一個 query 執行 WebSearch，並獨立記錄結果。WebSearch 不是 optional fallback，而是 wrapper 失敗時必要的 Tier 2。
  • NEW-03 forbidden-phrase 硬規則：任何標成「verified」的 claim，只要其 evidence 落在以下 7 條之一，就屬於 hard failure（v5.1 P-019 / G-013）：{"hypothetical blog post", "example.gov", "search for X might yield", "discussion at DHI meeting", "based on industry consensus" (no URL), "commonly cited" (no URL), "count aligns with or is very close to" (no roster)}。該 claim 必須降級為 unverified。
  • First-party URL 結構規則：所謂「verified」，就是 evidence 帶有可點擊的 first-party URL（publisher domain、government domain、court record）。只要沒有 first-party URL，該 claim 就必須降級。
  • Under-delivery escape clause（承接 v5.1 的 Fact Checker）：少而乾淨，勝過多而髒。若因 NEW-03 降級，使 verified 數量低於草稿原先預期，Execution Log 必須明確寫出 under-delivery reason: raw model returned placeholder phrasing / no first-party URL, demoted on anti-pattern scan。不能用 padding 補數。
  • Claim-count minimum：至少要有 max(3, ceil(numeric_claims_total / 3)) 個真實 wrapper / WebSearch query（比照 v5.1）。4 個 claim 至少 3 個 query；12 個 claim 至少 4 個 query。這是為了防止退化成「Fact Checker 跑 3 個 query 就收工」。
  • Reviewer-override layer（承接 v5.1 的 Fact Checker）：raw wrapper output 只是第一層。Fact Checker 還要再跑第二層，找出：opinion 被寫成 fact、帶有 numeric specificity 的 unverifiable anecdote（這裡同樣套用 v5.1 Source Reviewer 的 opinion-vs-empirical rule）、date drift，以及 pre-2018 source 的 version-year drift。

M（對齊 S）

  • 交付 blog-review-{slug}-facts.md：
    • 每個 numeric / regulatory / monetary claim 都要列出：draft location、claim text、source、status（verified / demoted-no-url / unverified / corrected）、first-party URL（若為 verified）與 wrapper / WebSearch evidence summary
    • 最終草稿必須零 NEW-03 forbidden phrase（可對 forbidden list 執行 grep check）
    • 若 demotion pattern 降低了 verified count，必須有 ## Under-Delivery Log 區段
    • ## Execution Log 要記錄每次 wrapper 與 WebSearch call（query、URL、result summary）
  • 100% 覆蓋：草稿中每個 numeric/regulatory/monetary claim 都出現在 review 表 — 不得悄悄略過。
  • Lookup count floor：max(3, ceil(numeric_claims_total / 3)) query 最低；Execution Log 至少此數。
  • /ai-fallback wrapper-call 驗證：grep -E '^(echo|gemini|codex)' blog-review-{slug}-facts.md 回 0 hit。
  • WebSearch Tier 2 trigger：wrapper exit 3 時，WebSearch query + URL + summary 獨立記錄。
  • Reviewer-override flag layering：raw-layer flag 與 reviewer-override flag 必須在 deliverable 中清楚分層，供 Source Reviewer 交叉檢查。

Anti-patterns Standard List（verbatim from v5.1 Fact Checker + blog additions）

  • NOT: 沒有 first-party URL 就信任單一來源為 "verified" — INSTEAD: 每個 "verified" claim 攜帶可點擊的 first-party URL（publisher / government / court domain）；沒有 URL = 降級。
  • NOT: 接受 7 條 NEW-03 forbidden phrase 中任何一條作為 evidence — INSTEAD: 把 {"hypothetical blog post", "example.gov", "search for X might yield", "discussion at DHI meeting", "based on industry consensus", "commonly cited", "count aligns with or is very close to"} 視為自動降級為 unverified。
  • NOT: 因 anti-pattern 降級把 verified count 降到預期之下而 padding — INSTEAD: 逐字記錄 under-delivery 原因，讓 Article Writer 下游 hedge 語言；少而乾淨勝於多而髒。
  • NOT: LLM 驗證繞過 call_with_fallback.sh — INSTEAD: 只用 wrapper（Principle 7）；raw CLI 是 hard failure。
  • NOT: wrapper 回 exit 3 時略過 WebSearch Tier 2 — INSTEAD: 對同一 query 做 WebSearch，記錄結果；「chain exhausted」不是 fact-check 的有效終態。

與 O 的對齊

O 的 AEO 成效要求 crawler 能解析出可引用的事實；O 的 SEO 成效則要求 Google Helpful Content scoring 看到的是真實 citation，而不是幻覺內容。只要漏掉一個 hallucinated numeric claim，就可能同時拖垮這兩個目標。

5. Source Reviewer 第 3 波

📎 Source Reviewer — 確保每個 citation 的 first-party 來源可達，並嚴守 opinion-vs-empirical 邊界

G

如果 practitioner 想從文章一路追到原始來源，他應該可以在 5 分鐘內做到。這不是因為他信任這篇 blog，而是因為 citation format 讓他可以直接落到 primary document。reference list 要能作為帶得走、用得上的資料，而不只是把 footnote 一股腦倒上去而已。同時，opinion-vs-empirical 的邊界也必須被嚴格遵守，避免讓包裝成 data 的 anecdote 混進來。
Tier 1 摘要
  • G one-liner：草稿中的每個 citation 都必須是可達的 first-party 來源（HTTP 200 或 published ID），pre-2018 source 要標 version，opinion-vs-empirical 邊界要被遵守，single-source concentration 不得超過 40%。
  • S one-liner：以 Codex primary 經由 /ai-fallback 執行（chain depth ≥ 3，用來避開 v5.1 G-001 的風險）；在 raw model output 之上再加 reviewer-override layer；並把 opinion-vs-empirical rule（v5.1 §Source Reviewer）套用到每一個 first-person narrative claim。
  • Critical M：blog-review-{slug}-sources.md 必須包含與 Fact Checker 的 reconciliation table；100% citation 要做到 URL-verified 或 ID-verified；此外還要處理 pre-2018 version-note flag，以及 single-source ≤ 40% 與 Waterson-material ≤ 20% 的配額控制。
  • Skill commands：無。
  • Model commands：bash ~/.claude/skills/ai-fallback/scripts/call_with_fallback.sh "Review all citations in [file]. Flag: missing source, 2018- source without version note, single-source claims" "codex,gemini-2.5-pro,gemini-2.5-flash-lite" — minimum chain depth 3（v5.1 G-001 Gemini Pro hang mitigation）。

S（路徑）

  • AIA-compatible citation format：architect 讀完文章後，通常會把 reference list 帶走再利用。格式統一為 [Publisher]. [Year]. [Title]. [URL or Standard#].，這正是他們平常已經在使用的形式。
  • Pre-2018 source flagging：任何被拿來支持 current regulatory requirement 的 pre-2018 source，都必須加上 version-note flag。因為 regulatory churn 的存在，pre-2018 citation 對 practitioner 具有實際風險。
  • Single-source concentration ≤ 40%，Waterson-material ≤ 20%：這是 v5.1 Source Reviewer 的規則。Blog 讀者必須感受到內容具備獨立性；watersonusa.ai 雖然是製造商知識 hub，但只要自家材料超過 20%，就很容易越界成 brochure。
  • Opinion-vs-empirical 邊界規則（逐字承接 v5.1 Source Reviewer 的 anti-pattern）：first-person voice 只是 opinion-exempt 的必要條件，不是充分條件。只要 first-person claim 含有任何 empirical specificity signal（例如 sample count、metric、time boundary、directional change），就屬於 empirical-unverifiable，必須 flag，並重寫或移除。例：「In my experience, architects underestimate panic hardware failure rates」屬於 opinion-exempt（沒有 signal）；「Recent conversations with AHJ officials in three Midwest jurisdictions suggest submittal review times have doubled since 2023」則屬於 empirical-unverifiable（因為同時觸發 N=3 sample、Midwest geography、review-time metric、doubled directional change、since-2023 boundary）。
  • Reviewer-override layer（承接 v5.1）：raw /ai-fallback output 先檢查機械完整性（URL / date / publisher）；接著由 Source Reviewer 獨立檢查 priority-violation:academic-over-primary、pre-2018-source-without-version-note、reference-list-mismatch。raw-layer flag 與 reviewer-override flag 必須在 deliverable 中分層呈現。
  • Reconciliation table with Fact Checker：建立 per-claim agreement matrix（agreement=true / true-negative / disagree），讓 auditor 能驗證 Source Reviewer 與 Fact Checker 的確檢視了同一批 claim，且各自做出獨立判斷。

M（對齊 S）

  • 交付 blog-review-{slug}-sources.md：
    • AIA-compatible 格式的 reference list
    • Per-claim coverage index：草稿中每個可測試 claim 都要有 single-source / pre-2018 / priority-violation 狀態
    • 與 blog-review-{slug}-facts.md 對應的 reconciliation table：claim_id / fact_checker_status / source_reviewer_status / agreement / action
    • ## Opinion vs Empirical Check 區段，標出每個 first-person claim 觸發了哪些 signal
    • 所有 URL 都要完成 HTTP-200 驗證（並記錄 check timestamp）
    • 套用 Pre-2018 version-note flag
    • Single-source ≤ 40%，Waterson-material ≤ 20%（超出則以 BUDGET-EXCEEDED 升級給 Commander）
    • Raw-layer 與 reviewer-override flag 必須分層
  • Chain depth ≥ 3 在 /ai-fallback call 上（v5.1 G-001 mitigation）— Execution Log 顯示 chain 中 3+ models。
  • /ai-fallback wrapper-call 驗證：grep -E '^(echo|gemini|codex)' blog-review-{slug}-sources.md 回 0 hit。
  • 5% unverifiable budget 對齊：Source Reviewer 必須統計 unverifiable claim，並記錄 unverifiable_count / total_factual_claims / 5pct_cap / status。超出 cap 時，以 BUDGET-EXCEEDED 升級到 Commander（比照 v5.1 Tier A 規則）。

Anti-patterns Standard List（verbatim from v5.1 Source Reviewer + blog additions）

  • NOT: 在 factual determination 上把 academic paper 排在 court document 之上 — INSTEAD: 在 fact-pattern 問題（case ruling, insurance claim, enforcement data）上，court doc 與 insurance record 勝過 academic summary。
  • NOT: 省略 source date 讓 temporal recency 不可見 — INSTEAD: 每個 source 攜帶 publication date；被用於 current requirement 的 pre-2018 source 附明確 version-note flag。
  • NOT: 把所有 first-person narrative 視為 opinion-exempt — INSTEAD: 套用 opinion-vs-empirical rule；first-person + 任何 empirical specificity signal（sample/metric/time/direction）= empirical-unverifiable，flag + 重寫或移除。
  • NOT: 把 raw model output 當作 final — INSTEAD: reviewer-override layer 獨立套用 priority-violation / pre-2018 / reference-list-mismatch check；raw 與 override layer 在 deliverable 中分層。
  • NOT: 讓 [source needed] 佔位符出貨 — INSTEAD: 首次發現即升級到 Commander；無 source 段落阻擋 reviewing 狀態轉換。

與 O 的對齊

AEO 成效的前提，是讓 LLM engine 願意信任文章中的 citation，進而反向引用 watersonusa.ai。只要有一個不可達的 URL，或一個偽裝成 data 的 opinion claim，就足以讓 crawler 判定這是不可信內容。

6. SEO/AEO Engineer 第 4 波

🧭 SEO/AEO Engineer — 以 JSON-LD + FAQPage + internal link graph 推動 Google 排名與 LLM 引用

G

透過 Google 進站的 practitioner，之所以能在前段排名看到這篇文章，是因為 structured data、internal link graph 與頁面上的 on-page signals 都已針對 search-intent query 做好調校。而提出相關問題的 ChatGPT / Perplexity / Gemini 使用者，之所以會看到 watersonusa.ai 被引用為來源，則是因為 JSON-LD、FAQPage schema 與自然語言 Q&A 區塊，讓 answer engine 可以正確解析可引用的事實。這兩類受眾都不會直接看到 structured data，但他們最終都會因它而被導向這個頁面。
Tier 1 摘要
  • G one-liner：補上 schema.org Article + FAQPage JSON-LD、OG / Twitter tag、internal link graph 與 FAQ anchor，讓文章能在 Google 取得排名，並被 AI answer engine 引用。
  • S one-liner：重用既有的 door-site blog template（以 gate-hinge-buying-guide 為 reference）；JSON-LD 是不可妥協項；internal link 指向相關 /blog/* 與 /solutions/*；FAQ block 同時作為 AEO anchor。
  • Critical M：JSON-LD 要完成 validate（Article + FAQPage）；internal link 至少 5 條；FAQ Q&A pair 至少 5 組；OG / Twitter tag 要完整；並加上指向 en / zh / web sibling 的 hreflang。
  • Skill commands：無；讀 writing-guide + publish-article template 作 reference。
  • Model commands：Gemini Flash via /ai-fallback 做 schema validation + structured-data sanity check。

S（路徑）

  • 重用既有 blog HTML template：reference 文章是 door-site/blog/gate-hinge-buying-guide/index.html。沿用相同的 CSS variable、JSON-LD 結構與 FAQ block 設計，讓一致性持續累積 SEO authority。
  • Article schema（JSON-LD）：@type: Article 需包含 headline、description、datePublished、dateModified、author（Waterson）、publisher（Organization）、mainEntityOfPage、about（Thing entities）。可參考既有的 fire-door-insurance-architect-liability-compliance/index.html canonical 結構。
  • FAQPage schema（JSON-LD）：@type: FAQPage 需包含 5–8 組 Q&A pair。問題設計要鏡射 architect / owner / installer 真正在 Google 輸入，或在 ChatGPT 裡詢問的內容。FAQ 是 primary AEO anchor，因為 LLM answer engine 通常會先抽取 Q&A pair。
  • Internal linking strategy：預先種下 internal link 到：
    • 相關的 /blog/* 文章（透過 cross-link knowledge graph 累積 SEO 複利）
    • 相關的 /solutions/* 頁面（在合適的位置導流到產品頁）
    • /aia/* CEU 課程（若題目與課程重疊）
    • 至少 5 條 internal link；若題目成熟，目標為 7–10 條
  • hreflang tag：加入 <link rel="alternate" hreflang="en" href=".../blog/{slug}/">、hreflang="zh-Hant" href=".../blog/zh/{slug}/"> 與 hreflang="x-default"。後續 Bilingual Publisher 會依賴這組設定。
  • 透過 /ai-fallback Gemini Flash 做 schema validation：把 JSON-LD block 經由 wrapper 傳給 Gemini Flash，prompt 為：「Validate this schema.org JSON-LD for Article + FAQPage. Return STRUCTURALLY_VALID/INVALID + error list.」並記錄結果。
  • Keyword cluster audit：讀 queue entry 的 keywords 欄位，交叉檢查草稿是否自然提到 primary cluster 至少 3 次（不能堆疊），以及 cluster variant（複數、形容詞、同義詞）至少 2 次。

M（對齊 S）

  • 交付 blog-seo-{slug}.md（structured-data annex），並把最終 HTML 注入草稿：
    • 已通過驗證的 Article JSON-LD block
    • FAQPage JSON-LD block（5–8 組 Q&A pair，且 Q&A 文字要與可見 FAQ 區段逐字一致）
    • OG tag：title、description、image、url、type=article、site_name
    • Twitter Card tag（可選，但要先種好）
    • Canonical link
    • hreflang 三件組：en、zh-Hant、x-default
    • 至少 5 條 internal link，且 anchor text 必須具描述性（不能寫成「click here」）
    • 至少 5 組 FAQ pair，並反映真實的 search-intent query
  • Schema validation log：/ai-fallback Gemini Flash 的結果，必須記錄 wrapper command、chain、answered model 與 exit code。
  • Keyword cluster check：primary keyword ≥ 3 次；variant ≥ 2 次；不堆疊（不得在單一段落出現 5+ 次 match）。
  • Internal link reachability：每條 internal link 目標都必須存在（由 Publisher 在第 5 波驗證）。

Anti-patterns Standard List

  • NOT: 寫 practitioner 不會打的通用 FAQ 問題 — INSTEAD: 鏡射 queue entry keywords 欄位的實際 search-intent query；FAQ 是 AEO extraction anchor。
  • NOT: 為達 count 而堆疊 keyword — INSTEAD: 自然 cluster coverage（primary ≥ 3, variant ≥ 2, 單段不得 5+ 次）；Google Helpful Content 對 stuffing 降權激進。
  • NOT: 為湊 link count 連到不存在或不相關的頁面 — INSTEAD: 每條 internal link 都切題且可達；注入前在 live site 驗證目標。
  • NOT: 因「看起來對」就略過 JSON-LD validation — INSTEAD: 透過 /ai-fallback Gemini Flash validate；malformed Article schema 會悄悄擊沉 AEO extraction。
  • NOT: 因為中 / web 版本還沒產就省略 hreflang — INSTEAD: Engineer 階段 seed 全部 3 個 hreflang tag；Bilingual Publisher 在 zh 與 web variant 寫入前依賴它們已存在。

與 O 的對齊

SEO 成效在這一層被直接工程化，因為這是第一個以 crawler 行為，而不是 practitioner 閱讀體驗，作為主要判準的 agent。AEO 成效也同樣集中在這裡，因為 FAQPage JSON-LD 是 LLM answer engine citation 最具槓桿的單一錨點。

7. Bilingual Publisher 第 5 波

🌏 Bilingual Publisher — 產出 en + zh + web 三個版本，通過 security-check，完成 stage 但不 push

G

繁體中文讀者（台灣門五金專業人士）與 web-AEO 讀者（LLM crawler），都必須在英文讀者看到文章的同一時間，以各自適合的格式收到內容：zh 版本要是自然的台灣專業語氣，web 版本則要帶有 AEO 最佳化的 schema。三個版本都必須 stage 進 door-site repo、通過 /security-check，然後等待人工 reviewer 補上後續 layers，在任何人執行 /upload 之前都不能提前發佈。
Tier 1 摘要
  • G one-liner：把 en + zh + web 三個變體發佈到 door-site/blog/{en,zh,web}/{slug}/index.html，執行 /security-check，完成 stage commit，但不 push。
  • S one-liner：en 版重用 /publish-article skill template；en→zh 依自然語氣規則翻譯（依 writing-guide §2 與 door-site CLAUDE.md）；web 變體則重用 en 內容再做 AEO tuning；stage 前一定要先跑 /security-check。
  • Critical M：3 個 HTML 檔要寫到正確路徑；hreflang triple 要彼此交叉 reference；品牌名與代碼不能翻譯；/security-check 必須 PASS；commit 要 staged，但不得 push。
  • Skill commands：/security-check（stage commit 前強制）。
  • Model commands：/ai-fallback Gemini Flash 做中文自然語音 pass。

S（路徑）

  • 英文變體：套用 /publish-article skill 的 HTML template（~/.claude/skills/publish-article/SKILL.md Step 3）。沿用 CSS variable、structured-data 位置與 FAQ 區段格式。路徑為：door-site/blog/{slug}/index.html。
  • 中文變體：依 writing-guide §2 的規則翻譯。硬規則（出自 publish-article SKILL.md Step 3b）如下：
    • <html lang="zh-Hant">
    • 品牌名不譯（Waterson, Bommer）
    • 標準代碼不譯（NFPA 80, ANSI/BHMA A156.17）
    • 型號不譯（K51P, K51W）
    • 必須是自然的台灣門五金專業人士語氣，不能有機翻感
    • 路徑：door-site/blog/zh/{slug}/index.html
  • Web/AEO 變體：版面要強化 schema 與以 Q&A 優先的組織方式，方便 LLM answer engine 擷取。路徑為：door-site/blog/web/{slug}/index.html。內容以 en 版為基礎，再重排成 FAQ block + Article schema 置前的形式。
  • hreflang triple 交叉 reference：每個變體都要連到另外兩個版本（en ↔ zh ↔ web，並以 x-default 作 fallback）。
  • Sitemap update：在 door-site/sitemap.xml 新增 3 個 URL，priority 設為 0.9。
  • llms.txt + llms-full.txt update：追加新文章 entry，讓 LLM crawler 能抓到新內容。
  • 透過 /ai-fallback 進行中文自然語氣 QA：使用 Gemini Flash，prompt 為：「請閱讀這篇繁體中文文章。它的語氣是否自然，像是台灣門五金專業人士會寫出的內容，還是仍帶有機器翻譯感？請以 1–5 分評分，並列出任何僵硬不自然的措辭。」若分數低於 4，就必須修改。
  • /security-check 為強制步驟：在 stage commit 前必須執行 /security-check skill。若出現密鑰洩漏，commit 就必須被阻擋。
  • Stage commit，但不能 push：human reviewer 必須先 append layer。git add + git commit 的訊息中要含有 [BASE LAYER — awaiting human review before push]。不得執行 git push，也不得執行 /upload。

M（對齊 S）

  • 3 個 HTML 檔必須存在於預期路徑；每個都能正常解析；每個都帶有 hreflang triple。
  • 中文自然語氣檢查分數必須 ≥ 4（由 /ai-fallback Gemini Flash 評分）；log 記錄在 blog-publish-{slug}.md。
  • /security-check log 必須顯示 PASS；blog-publish-{slug}.md 需包含 timestamp 與結果。
  • sitemap.xml, llms.txt, llms-full.txt 更新。
  • blog/index.html 的列表已更新。
  • 必須存在已暫存的 commit（git status 顯示 staged），且訊息含有 [BASE LAYER — awaiting human review before push]。
  • 不得執行 git push；驗證方式為確認 remote 相對 local HEAD 沒有變動。
  • /ai-fallback wrapper-call 驗證：grep -E '^(echo|gemini|codex)' blog-publish-{slug}.md 回 0 hit。
  • Queue entry state 轉為 ready_for_human_review（Commander 簽名）。

Anti-patterns Standard List

  • NOT: stage 之後跑 /upload 或 git push — INSTEAD: stage 後停；human reviewer 必須先 append layer。fleet 的產出是 base-layer；跳過 human review 直接 push 違反 base-layer 原則。
  • NOT: 把品牌名、標準代碼、型號翻譯成中文 — INSTEAD: Waterson, Bommer, NFPA 80, K51P 保持原文；<html lang="zh-Hant"> 但技術術語依 door-site 慣例保留原語言。
  • NOT: 產出機翻腔的中文 — INSTEAD: 自然台灣門五金專業人士語音；/ai-fallback Gemini Flash 評分 ≥ 4；否則修改。
  • NOT: 因「只是 markdown/HTML」就略過 /security-check — INSTEAD: 每次進行 staged commit 前都必須強制執行；JSON-LD metadata 中洩漏密鑰是真實的 failure mode。
  • NOT: 因「en 與 zh 才是真正 audience」就忘記 web 變體 — INSTEAD: web 變體是 AEO anchor；沒有它，LLM answer engine 拿到 en 變體卻錯過 structured Q&A 領頭。

與 O 的對齊

中文讀者本身就是真正的 practitioner，因此他們帶來的 SEO lift 同樣會持續累積（Google 會尊重 hreflang）。web/AEO 變體則是 LLM answer engine 抓取 schema 的主要位置。DO-NOT-PUSH 的紀律，就是把 base-layer 原則落實成操作規則；human reviewer 是 fleet 輸出與 live site 之間不可跳過的 gate。

第 4 節 · Wave flow（0 → 1 → 2 → 3 → 4 → 5 → 6）

波次Agent輸入輸出狀態轉換
第 0 波 Blog Commander .content-scout-queue.md 中待處理的 candidates Audience Shape Decision + Direction Seed + Pilot brief pending（未變）
第 1 波 Research Deepener Queue entry 的 research_data + Direction Seed blog-research-{slug}.md（擴充為 800–1500 字） pending → researching
第 2 波 Article Writer blog-research-{slug}.md + writing-guide §2 blog-draft-{slug}.md（含 HUMAN LAYER slot） researching → drafting
第 3 波 Fact Checker + Source Reviewer（並行） blog-draft-{slug}.md blog-review-{slug}-facts.md、blog-review-{slug}-sources.md、reconciliation table drafting → reviewing
第 4 波 SEO/AEO Engineer Reviewed draft + queue keywords blog-seo-{slug}.md + 已注入 JSON-LD 的最終英文 HTML reviewing（第 4 波為純追加階段，不做轉換）
第 5 波 Bilingual Publisher 最終英文 HTML 3 個 HTML 檔（en/zh/web）+ sitemap / llms.txt 更新 + 已暫存的 commit reviewing → ready_for_human_review
第 6 波 人工 reviewer（不在 fleet scope 內） 已暫存的 commit 補上 HUMAN LAYER 內容 → /upload → Vercel deploy ready_for_human_review → published

Fleet 在 Gate 6 沒有 agent。 那是明確的人工作業邊界。只要把 Gate 6 納進 fleet，就會直接違反 base-layer 原則。

第 5 節 · 已知問題（v1 OGSM 已記錄，待 monitor / v2 修正）

⚠️ 問題 #1 — v1 沒有 Audience Persona Reviewer

疑慮：v5.1 的 HSW fleet 有 Project Architect Advisor（Gemini Pro persona）擔任 external reviewer，但 v1 blog fleet 沒有。風險是 audience voice 可能慢慢漂移成過度通用的語調，卻沒有外部視角可以抓出來。

可能修正方向（暫不實作）：(a) 在第 4 波增加 Audience Persona Reviewer agent（透過 /ai-fallback 使用 Gemini 2.5 Pro）；(b) 以 shared reference 方式重用 v5.1 的 Project Architect Advisor；(c) 以 lightweight Fresh Eyes Reviewer 取代。

監控條件：前 3 篇中，是否有 ≥ 1 篇在 Gate 6 被人工 reviewer 抱怨「語氣過於通用」？若是，v2 加 agent。

⚠️ 問題 #2 — 缺少跨 fleet 的 Quality Auditor / Performance Supervisor

疑慮：v5.1 有 Performance Supervisor 與 Quality Auditor 作為獨立的測量層，但 v1 blog fleet 沒有；7-agent 結構把測量責任塞進了 Blog Commander。風險在於 Commander 無法真正稽核自己。

可能修正方向：(a) v2 增加 Performance Supervisor，重用 v5.1 pattern；(b) 指派某個 agent（例如 Source Reviewer）兼任稽核；(c) 每批次執行 validate_s_to_m_coverage.py，作為自動化替代。

監控條件：前 5 篇中 ≥ 2 篇有可測量的 gap Commander 沒抓到？若是，加 agent。

⚠️ 問題 #3 — Audience shape decision 缺少外部 validator

疑慮：Commander 目前獨自決定要做 1 個版本還是 3 個版本。風險是 Commander 可能系統性偏好 1（工作較少）或偏好 3（可見產出較多），進而讓 fleet 失衡。

可能修正方向：(a) 每次 Audience Shape Decision 都透過 /ai-fallback 加一個 Gemini Flash 第二意見；(b) 追蹤決定分布，只要某一側超過 80% 就發出警示；(c) 定期進行 human audit。

監控條件：10 篇後，1-article / 3-article 分布是否合理（不超過 80% 偏一方）？

⚠️ 問題 #4 — 尚未執行 Layer 2.5 dry-run

疑慮：ogsm-framework SKILL.md 明確要求，在首次正式生產前，必須強制執行 Layer 2.5 dry-run 派遣，以驗證每個 embedded skill 呼叫都能真的跑通。v1 草稿目前還沒做這件事。

可能修正方向：Commander 在第一次正式派遣前，先對 7 個 agent 全部跑一次 Layer 2.5 dry-run。預估成本約 7 分鐘。

監控條件：首次生產是否出現「parameter X missing」或「不知該呼叫哪個 skill」錯誤？若是，Layer 2.5 被不公平略過。

⚠️ 問題 #5 — Base-layer principle 目前沒有自動化 enforcement

疑慮：「不得產出 sealed 文章」這條規則，目前仍仰賴 Article Writer 自律加上 Commander 的 gate review。技術上，Writer 完全可以輸出 <!-- HUMAN LAYER: sales-response --> 這種標籤，卻在後面偷偷填入實際 sales copy，等於破壞原意。

可能修正方向：(a) 建立 Grep 規則：每個 HUMAN LAYER comment 後 3 行內必須為空，或只允許 <!-- TODO: human reviewer fills in -->；(b) 建立 human reviewer feedback loop，若他們常發現 slot 已被預填 placeholder，就補上自動檢查。

監控條件：前 5 次 human reviewer append — 他們是否需要先刪除 slot 中的內容才加自己的？若是，加 grep 規則。

⚠️ 問題 #6 — 沒有 bilingual voice divergence detection

疑慮：目前中文自然語氣檢查只依賴單次 /ai-fallback Gemini Flash 分數。若出現細微的文化誤譯（例如繁體中文文章混入中國大陸用語），很可能會被漏掉。

可能修正方向：(a) 以 Gemini Pro 搭配台灣在地化 prompt 做第二層 persona check；(b) 追蹤不得出現的 glossary term（建立大陸用語黑名單）；(c) 定期做人工作業 spot-check。

監控條件：中文讀者是否抱怨過大陸用語漂移？若是，加 glossary check。

V1 機器人實際產出的文章

這 3 篇文章是 Blog Writer Fleet V1 的第一輪 pilot 產出。V2 版機器人的產出將在這裡對照比較。

Twin Parks NYC 14-Day Clock regulatory-explainer universal audience

🇺🇸 English  ·  🇹🇼 繁體中文  ·  🤖 Web / AEO

NFPA 80 6.4.1.4 Spring Hinge Trap code-conflict architect-primary

🇺🇸 English  ·  🇹🇼 繁體中文  ·  🤖 Web / AEO

Antimicrobial Door Hardware in Healthcare research-driven universal

🇺🇸 English  ·  🇹🇼 繁體中文  ·  🤖 Web / AEO