WTR-Blog-Writer-Fleet OGSM v3 — Waterson USA 部落格生產團隊

G（目標）

最終閱讀這篇文章的從業者是艦隊從未見過的人——他們在 HSW 課程將研究成果輸入隊列後，透過 Google 搜尋到達。Blog Commander 的工作是確保所有 10 個下游 agent 都是為了那位從業者而工作，而不是為了彼此或隊列的內部邏輯。每次關卡審查都必須回答：「如果一位建築師、業主或安裝人員現在打開這篇文章，他們會在第 2 段就停止滑動嗎？他們會把 Waterson 視為推薦的解決方案嗎？」

S（策略）

• 隊列分類：讀取 .content-scout-queue.md 中 state = pending 的候選項目。對每個項目決定受眾形態（universal 或 split-3）。
• 受眾形態決策必須搭配外部驗證：
• 步驟 1：Commander 根據候選項目的 research_data、title、keywords、type 提出形態建議。
• 步驟 2：呼叫 /ai-collab --task verify，傳入候選項目 payload 加上建議形態。
• 步驟 3：Gemini Flash 回傳 AGREE 或 DISAGREE 加上理由。
• 步驟 4：在隊列條目的 ## Audience Shape Decision 下附加 YAML 區塊：proposed_shape、gemini_verdict、gemini_rationale、final_shape、override_rationale。
• 步驟 5：若 Commander 否決 Gemini 的不同意見，需以書面說明理由（至少 2 句）。禁止無聲否決。
• Wave 2 扇出現在是 2 份獨立簡報：Commander 分別為 SEO Writer 和 AEO Writer 各產生一份 Direction Seed。兩份簡報都以 blog-research-{slug}.md 作為共用輸入，並在欄位 9 的反模式和欄位 6 的約束中包含 Waterson Primary Voice 共用規則。
• 優先順序：依（a）type 平衡、（b）research_data 新鮮度、（c）SEO/AEO 複利價值、（d）隊列形態分布進行分類。記錄於 triage-{date}.md。
• 9 欄位 Direction Seed 派遣：每次子 agent 簡報都必須包含所有 9 個欄位。絕不省略欄位 9。
• 試運行派遣規則（v3 更新）：
• Wave 1 試運行 = Research Deepener。
• Wave 2 試運行 = SEO Writer。AEO Writer 在 Gate 1 後與 SEO Writer 並行執行——AEO Writer 不會等待 SEO Writer 試運行結果。兩者同時執行；Commander 在 Gate 2 審查兩份輸出。若 SEO Writer 試運行失敗，則暫緩 AEO Writer 輸出，等待 SEO Writer 重新派遣。
• Wave 3 試運行 = Fact Checker。
• Wave 4 試運行 = Audience Persona Reviewer。
• Wave 5：無獨立試運行；依賴 Gate 4 退出條件。
• Wave 6：無試運行；Publishing Strategist 是單次執行 agent。
• 狀態轉換：在每次 wave 關卡後於 dispatch-log-blog-{slug}.md 中簽核。
• 衝突解決（4 層，與 v2 相同）：
• SEO/AEO Engineer vs SEO Writer → Engineer 在 schema/HTML 結構上優先；Writer 在散文清晰度上優先。
• Fact Checker vs Research Deepener → Fact Checker 在數字/引文驗證上優先；Research Deepener 在範疇上優先。
• Audience Persona Reviewer vs SEO Writer 或 AEO Writer → Persona Reviewer 在冷讀語聲偏移標記上優先；只有在 Commander 調解後 Writer 才能針對特定語言修正優先。
• Quality Auditor vs 任何人 → Auditor 不改寫內容；Auditor 在交付物是否能進入下一個關卡上優先。

M（衡量）

• 每個 wave 都存在 blog-gate-review-{slug}-waveN.md，包含 從業者在場？、Waterson-primary 維持？、基礎層維持？、引用的證據、阻礙清單。
• 每個派遣候選項目的隊列條目中都有 ## Audience Shape Decision YAML 區塊，包含所有 5 個必要欄位。
• Wave 2 產生兩份獨立的 Direction Seed 簡報（每位 writer 一份）；兩份均包含共用的 Waterson Primary Voice 規則。
• 每個試運行波次的試運行確認工件引用確切行數範圍。
• 隊列狀態轉換記錄於 dispatch-log-blog-{slug}.md。
• Commander 的外部驗證使用記錄在案；grep -E '^(echo|gemini|codex)' dispatch-log-blog-{slug}.md 回傳 0 筆。
• 受眾形態分布監控：每 10 篇文章，Commander 記錄 universal vs split-3 的分布。若任一方超過 80%，則需在回顧中備注。

反模式

• 不可：將隊列視為依序清除的任務清單——應該：依受眾覆蓋、類型平衡與 SEO/AEO 複利價值進行分類。
• 不可：發出一份試圖同時涵蓋 SEO 和 AEO 寫作的 Wave 2 簡報——應該：產生兩份獨立的 Direction Seed 簡報，一份給 SEO Writer，一份給 AEO Writer。
• 不可：未取得 Gemini Flash 第二意見就確定受眾形態決策——應該：呼叫 /ai-collab --task verify，記錄同意／不同意。
• 不可：在 Wave 2 簡報中省略 Waterson Primary Voice 共用規則——應該：在兩份簡報的欄位 6（約束）和欄位 9（反模式）中逐字包含 §Waterson Primary Voice。
• 不可：允許 agent 產生不留人工審查空間的封閉式 SEO 文章——應該：在每份 SEO 交付物上設置含明確附加槽和槽空置紀律的關卡。
• 不可：直接呼叫原始 gemini 或原始 codex 繞過包裝器驗證——應該：僅使用包裝器；原始 CLI 是硬性失敗。

O 對齊

若缺少 Commander 的逐候選受眾形態決策、簡報中的 Waterson-primary 規則執行，以及雙 writer 扇出紀律，艦隊會產出泛泛的全受眾糊狀內容，或在 Waterson 自己的網域上產出錯誤地保持中立的文章。

S（策略）

• 從隊列條目出發，而不是從空白頁開始。
• WebSearch 優先研究，進行第一方來源的開放式探索。
• /ai-fallback 僅用於摘要和交叉驗證。
• 擴展目標：800–1500 字，依三受眾框架組織，每個聲明附受眾相關性備注。
• 第一方來源要求：每個聲明至少附 1 個第一方 URL，或標記為 secondary-only。
• Waterson 產品對應備注：若研究素材涵蓋 Waterson 有特定型號的產品類別（依 writing-guide §3），標記該型號及其規格，讓兩位 Wave 2 writer 無需重新發掘。
• 執行日誌紀律：記錄每次 WebSearch 查詢和每次 /ai-fallback 呼叫。

M（衡量）

• 交付 blog-research-{slug}.md，包含：
• 從隊列條目完整逐字複製的 research_data
• 擴展素材，800–1500 字，逐聲明引用
• 每個聲明的第一方 URL 或 secondary-only 標記
• 每個聲明的受眾相關性備注
• Waterson 產品型號對應備注（如適用）
• 包含每次 WebSearch 和 /ai-fallback 呼叫的執行日誌
• 超出 research_data 已引用來源的 ≥ 3 個新第一方來源。

反模式

• 不可：丟棄或改寫隊列的 research_data 逐字區塊——應該：完整複製，然後在其周圍建構擴展。
• 不可：使用原始 echo | gemini 或原始 codex exec 進行任何 LLM 呼叫——應該：僅使用包裝器。
• 不可：在沒有第一方 URL 的情況下接受聲明為已驗證——應該：第一方 URL 或帶有下游對沖語言的 secondary-only。
• 不可：因研究感覺通用就省略 Waterson 產品型號備注——應該：檢查 writing-guide §3；若有適用型號，明確標記，讓兩位 writer 都能使用。

S（策略）

• 在寫作前閱讀 writing-guide §§1–5；套用「問題 → 診斷 → 解決方案 → 產品」弧線。
• 完全遵守 Commander 的受眾形態決策。
• 前置答案在前 200 字：對搜尋意圖問題的具體答案。
• 逐節 Waterson-primary 規則（強制——來自 §Waterson Primary Voice）：
• 每個主要 H2 節在進入下一節前，必須包含 ≥ 1 個 Waterson 觀點、產品型號參考或定位陳述。
• 比較表必須將 Waterson 列為具名選項，並以具體差異化原因定位為推薦選擇。
• 不可均勻分配品牌提及——Waterson 是此頁面的擁有者。
• 敘事結構：每個 H2 建構深度；過渡句引領讀者前進；在符合受眾情境的地方允許情感鉤子。
• 交接槽紀律——自動生成的 TODO 標記是強制的：
• 每個 <!-- HUMAN LAYER: ... --> 注釋後面必須緊接一行 <!-- TODO: human reviewer fills in -->。
• SEO Writer 將這些標記作為一組自動生成；TODO 標記絕不省略。
• 最少槽數：<!-- HUMAN LAYER: sales-response -->、<!-- HUMAN LAYER: field-experience -->、<!-- HUMAN LAYER: sme-note -->（每個都帶有其 TODO 標記）。
• 字數：1200–1500 字，硬性上限 1600。
• CTA 紀律：最後一節必須包含自然過渡到特定 Waterson 產品頁 URL 或聯絡路徑。不可是泛泛的「聯絡我們」。

反模式

• 不可：假設 AIA 風格的中立呈現是此網站的正確基準——應該：這是 Waterson 的部落格；教育建立可信度，但 Waterson 推薦在每節都存在。
• 不可：列出競爭產品而沒有 Waterson 的對應產品和推薦——應該：每個品牌比較都包含帶有具體差異化原因的 Waterson 選項。
• 不可：以一般性結論和沒有明確下一步結束文章——應該：每篇文章以自然過渡到特定 Waterson 產品頁或聯絡路徑結尾。
• 不可：產出沒有交接槽的封閉式 SEO 文章——應該：放置 ≥ 3 個帶有自動生成 TODO 標記的標記 HUMAN LAYER 槽；TODO 標記是槽對的一部分，絕不可選。

S（策略）

• 在寫作前閱讀 writing-guide §§1–3（核心事實與受眾；AEO 的完整語調指南是次要的）。
• Q&A 原子對結構是主要組織單元——每個 H2 是一個問題；第一段在 ≤ 120 字內回答它。
• 自足段落：每段必須在沒有周圍情境的情況下可獨立解析——不使用指涉前面段落的代詞，不使用假設讀者已讀過前一個 Q&A 的過渡語。
• 逐 Q&A Waterson-primary 規則（強制——來自 §Waterson Primary Voice）：每個 Q&A 答案段落必須在相關時包含："For Waterson [product category or model]: [specific guidance]"——一句話在答案本文中，不作為附注附加。
• 字數：800–1000 字，硬性上限 1100。
• 無 HUMAN LAYER 槽：AEO 草稿是 schema 饋送素材，不是編輯基礎層。人工編輯層僅屬於 SEO 草稿。AEO Writer 在任何情況下都不得插入 HUMAN LAYER 注釋。

M（衡量）

• 交付 blog-aeo-draft-{slug}.md：
• YAML frontmatter：audience、draft_type: aeo、word_count、qa_pair_count
• 每個 H2 以問題形式表達
• 每個 Q&A 引言段落 ≤ 120 字且自足
• grep -c "For Waterson" blog-aeo-draft-{slug}.md 回傳 ≥ floor(qa_pair_count × 0.6)
• 最後一個 Q&A 對包含 Waterson 產品頁或聯絡 URL
• grep -c 'HUMAN LAYER:' 回傳 0——AEO 草稿不含交接槽；這是硬性 M 要求，不是指南

反模式

• 不可：撰寫流暢的敘事段落——應該：僅使用 Q&A 原子對；每個 H2 是問題；第一段是答案。
• 不可：假設讀者讀過前一個 Q&A——應該：每段必須可獨立解析；不使用跨段參考代詞。
• 不可：插入 HUMAN LAYER 槽——應該：AEO 草稿是 schema 饋送素材；人工編輯層僅屬於 SEO 草稿；grep -c 'HUMAN LAYER:' 必須回傳 0。

反模式

• 不可：只驗證 SEO 草稿而跳過 AEO 草稿——應該：兩份草稿都需要覆蓋；AEO 行內引用需要額外仔細審查。
• 不可：相信沒有第一方 URL 的單一來源即為已驗證——應該：每個已驗證聲明都帶有可點擊的第一方 URL。
• 不可：接受 7 個 NEW-03 禁止語句中的任何一個作為證據——應該：自動降級為未驗證。

1. 在前 200 字（SEO）或第一個 Q&A 對（AEO），我有沒有得到我來找的答案？

2. 這聽起來像理解我日常工作流程的內容嗎？

3. 有沒有哪個章節明顯是為不同於我的受眾寫的？

4. 有沒有任何段落感覺像通用的供應商／行業內容填充？

5. 如果我將這篇文章加入書籤，我之後會回來看哪個確切的章節？

6. 讓我停止信任這篇文章的最有力原因是什麼？

7. 讀完這篇文章後，我想查看 Waterson 的產品嗎？（v3 新增——Waterson 意圖問題）

Q7 Waterson 意圖信號：Q7 用於偵測 Phase 1 的特定失敗模式——技術上正確但 Waterson 存在感被動的文章。若角色對 Q7 的回答是「不特別」或「我不確定他們推薦哪個產品」，即為 Waterson 定位薄弱標記，必須以 waterson-positioning-weak 問題類別上報給 Commander。

關鍵規則

• 基礎層完整性稽核僅適用於 SEO 草稿：QA 確認 SEO 草稿有 ≥ 3 個帶 TODO 標記的 HUMAN LAYER 槽，且沒有槽被預先填充。AEO 草稿的零 HUMAN LAYER 槽是正確且預期的狀態——QA 不得將此標記為基礎層失敗。
• AEO TODO 標記核查：grep -c "HUMAN LAYER:" blog-aeo-draft-{slug}.md 必須回傳 0。若回傳 > 0，即為第 3 類範疇蔓延違規（AEO Writer 插入了不應有的槽）。

失敗分類

• class-1 structural handoff fail：缺少工件、缺少必要表格、缺少執行日誌、格式錯誤的槽、缺少角色章節
• class-2 coverage fail：草稿中有但審查索引中無的聲明、缺少 URL、缺少問題答案、FAQ/schema 同步不完整
• class-3 scope-creep or role-boundary fail：agent 做了未指派的工作、改寫了其他 agent 的範疇；包括 AEO Writer 插入 HUMAN LAYER 槽

M（衡量）

• docs/publishing-strategy/{slug}.md 存在並包含所有 4 個必要章節：
• 第 1 節（標題衝突分析）：風險等級 HIGH/MED/LOW/NONE + 每個衝突的特定 .com URL
• 第 2 節（內部連結建議）：≥ 3 個雙向連結對，包含確切錨文字和目標 URL
• 第 3 節（.com 位置建議）：特定 .com 頁面 URL + 特定 H2/H3 節 + 建議文字
• 第 4 節（關鍵字定位判決）：主要關鍵字、次要關鍵字、蠶食判決、Pillar/Cluster/Standalone 分類
• 報告判決為以下之一：Ready to publish／Review needed／Blocker。
• Blocker 判決觸發 Commander 上報。然而，Blocker 不自動阻止人工審閱——Commander 決定解決路徑。這是僅報告；不自動執行。
• Publishing Strategist 不編輯 .com 頁面，不推送程式碼，不修改 watersonusa-com-index.json。

反模式

• 不可：每次文章發布時重新爬取整個 watersonusa.com——應該：讀取快取的 docs/watersonusa-com-index.json；逐文章爬取是效能反模式。
• 不可：建議模糊的「增加內部連結」而沒有具體的錨文字和目標 URL——應該：每個連結建議都包含確切錨文字、特定句子／段落位置和完整 URL。
• 不可：將 Blocker 判決視為自動封鎖人工審閱——應該：Blocker 只觸發 Commander 上報；文章本身的人工審閱不被封鎖；Commander 決定解決方案。