geo-content-writer 是一套 backlog-row-first 的內容生產系統。它先把 Dageno 的 prompt 機會展開成「扇出待辦」(fanout backlog),再把選定的某一列逐步產出編輯簡報、草稿合約、審查合約,最後輸出過品質閘的 GEO 文章,並可推送到 WordPress。
多數 AI 寫作工具以單一題目輸入、輸出單篇文章。geo-content-writer 的設計不同:它以 Dageno 真實機會資料(prompt opportunities、fanout、citations)為原料,先展開成一張扇出待辦表。每一列帶有叢集角色與優先級,工作重心從「構思題目」轉為「從 backlog 選哪一列開工」。
被選中的列會依序通過有合約的產線:先生成編輯簡報(受眾、角度、差異化、E-E-A-T 目標),再進入分段草稿合約與審查合約,最後輸出包含 editorial_brief、draft_package、review_package、writer_prompt 的結構化 payload。每一步均有可驗證的契約約束。
產出後有一道品質閘:check-article-quality 以字數、結構等指標執行 pass/fail 驗證,通過後才進入下一步。最終由 publish-wordpress 將成品推送為 WordPress 草稿或文章。整條產線的設計目標是可重複、可審查、可規模化,適合需要維護內容月曆的團隊。
環境需求:Python 環境、設好 PYTHONPATH、本機檔案系統存放 knowledge base 與 backlog。DAGENO_API_KEY 為必填,用於取得 opportunities、prompts、fanout 與 citations;未設定則整條產線無法取得真實資料。WordPress 發佈所需的 WORDPRESS_* 變數為選填。
所有指令都透過 geo_content_writer.cli 模組執行,記得帶 PYTHONPATH=src。先建扇出待辦、選出可寫的列、產出 publish-ready payload,最後把 payload 變成 Markdown。
knowledge/backlog/fanout-backlog.json,品牌知識庫建議放在 knowledge/brand/brand-knowledge-base.json。同一份 backlog 快照可以用 --backlog-file 反覆重用,讓整個內容月曆維持一致性。
指令不是平行的功能選單,而是一條前後相接的產線:探索 → 建待辦 → 選列 → 產 payload → 草稿 → 品質閘 → 發佈。每一步吃上一步的產出,讓「一篇文章」變成「一條可重複的流程」。
--allow-exploratory-fallback 應對庫存不足。--top-n 控制這輪要處理幾列。--min-words 與 --json 出機器可讀報告。
扇出待辦的每一列都有一個狀態,決定它在產線上的去向。write_now 是綠燈,其餘狀態都需要先處理過才能往下推。
| 狀態 | 意義 |
|---|---|
write_now |
資料充分、可立即進入產 payload 與草稿。 |
needs_merge |
與其他列題目重疊,需先合併再寫,避免內容自相蠶食。 |
needs_cleanup |
原始扇出資料雜訊多,要先清理才有寫稿價值。 |
exploratory |
由 exploratory fallback 產生,屬探索性質,推進產線前需人工驗證。 |
skip |
判定不值得做成內容,直接略過。 |
這套系統的價值建立在「只用真實 Dageno 扇出」這條紀律上。以下密技全部來自 README 與專案文件,重點都是怎麼讓產線維持可信、可規模化,而不是更會「生字」。
README 的鐵律:生產工作流只能用真實 Dageno fanout 起頭,不要為了生產而生成猜測的扇出。資料一旦造假,後面整條產線的可信度就垮了。
來源 · 官方 README · Limitations題目標籤只是入口,不是大綱。應讓它走完 publish-ready-article 產出 editorial_brief,由簡報確定受眾與角度後再進草稿。略過此步驟會失去差異化。
庫存不足時加 --allow-exploratory-fallback,搭配 --exploratory-min-write-now 與 --exploratory-max-items 控制量。產出列會標 status=exploratory,務必人工驗證後才升級。
品牌知識庫與題目不匹配時,系統會擋住 publish-ready 生成。--allow-brand-mismatch 可強制覆寫,但 README 明說不建議。此閘門用於保護品牌一致性。
check-article-quality 加 --min-words 1200 --json 會吐機器可讀的 pass/fail 報告。把它接進 CI 或排程,內容月曆就能自動把不合格的稿擋在發佈前。
用 --backlog-file 指定同一份 fanout-backlog.json 快照,可以反覆重跑同一批列。內容月曆需要一致性與可追溯時,這比每次重新探索更穩。
以下為 B2B SaaS 情境範例:從 Dageno 機會建出扇出待辦、挑出一列 write_now、產出結構化 payload、生成 Markdown、通過品質閘,最後推送為 WordPress 草稿。全程僅使用真實扇出資料。
產線的關鍵在於每一步都有契約與閘門:品牌庫不符合會被擋下、字數不足則品質閘 fail、扇出資料不真實則不應進入產線。產出物為帶有 editorial_brief、draft_package、review_package 的結構化 payload，而非單純的生成文字。
從 38 個候選列到一篇通過品質閘的草稿，每一步均有明確依據。backlog-row-first 的設計目標是維護一條可審查的內容生產系統，而非管理單篇輸出。
status=exploratory,在升級進產線前要人看過。把它當「待確認」,不是「可直接寫」。
check-article-quality 驗的是字數、結構這類可量化指標。過閘不代表內容夠好,最後一關還是要人讀。
契約與規格均以檔案形式存放。schemas/ 存放驗證 schema、references/ 存放 pipeline 規格、knowledge/brand/ 存放品牌庫。調整這些檔案即可改變整條產線的行為，無需修改核心程式碼。
1. 養好品牌知識庫。把 knowledge/brand/brand-knowledge-base.json 寫紮實,品牌一致性閘才有判斷依據,產出語氣才會像「你的品牌」而不是通用 AI。
2. 自訂叢集角色策略。category、buyer_shortlist、decision_stage_comparison 等叢集角色決定文章類型。依你的內容矩陣調整選列邏輯,讓 backlog 直接對齊漏斗。
3. 把品質閘接進 CI。用 check-article-quality --json 的輸出當 gate,讓內容月曆在發佈前自動擋掉不合格稿,而不是靠人記得檢查。
4. 用 schema 鎖住 payload 形狀。schemas/ 的驗證 schema 確保 editorial_brief / draft_package / review_package 結構穩定,接後續自動化才不會散。
5. 擴充發佈通路。WordPress 只是範例。照同樣的 payload → 渲染 → 發佈模式,接你自己的 CMS 或多通路分發。
① README.md：完整指令、payload 結構、限制與客製化選項。
② references/：pipeline 規格，說明每個合約的約束範圍。
③ examples/：publish-ready payload 與文章範例，可作為產出對齊參考。