使用手冊

第 01 期 · 開源工具 / GEO / 內容產線

backlog-row-first GEO 內容產線

geo-content-writer 是一套 backlog-row-first 的內容生產系統。它把 Dageno prompt 機會展開成扇出待辦,再把選定的列依序產出編輯簡報、草稿、審查包與可發佈的 GEO 文章。涵蓋安裝、CLI 指令、進階用法與實戰範例。

geo-content-writer 是一套 backlog-row-first 的內容生產系統。它先把 Dageno 的 prompt 機會展開成「扇出待辦」(fanout backlog),再把選定的某一列逐步產出編輯簡報、草稿合約、審查合約,最後輸出過品質閘的 GEO 文章,並可推送到 WordPress。

dageno-agents/geo-content-writer
星標
165
分支
22
授權
—
資料截至
閱讀時間
9 分
更新日期
開啟原始報告
GitHub Stars
146
100% 原生實作
Python
扇出資料來源
Dageno
永久免費授權
MIT
本頁章節

01系統概覽

以 backlog 列為起點的內容作業系統

多數 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 草稿或文章。整條產線的設計目標是可重複、可審查、可規模化,適合需要維護內容月曆的團隊。

  1. 探索 prompts

  2. 扇出待辦

  3. 選列

  4. 產 payload

  5. 草稿

  6. 品質閘

  7. WordPress

以 backlog 列為起點的內容生產系統,設計目標是支援持續性內容月曆,而非單次文章輸出。

— geo-content-writer README · 專案定位

02設定與啟動

設定 API key 與環境變數

環境需求:Python 環境、設好 PYTHONPATH、本機檔案系統存放 knowledge base 與 backlog。DAGENO_API_KEY 為必填,用於取得 opportunities、prompts、fanout 與 citations;未設定則整條產線無法取得真實資料。WordPress 發佈所需的 WORDPRESS_* 變數為選填。

bash
git clone https://github.com/dageno-agents/geo-content-writer.git
cd geo-content-writer
# 必填:抓取 Dageno 機會 / 扇出 / 引用
export DAGENO_API_KEY="your-key"
# 選填:WordPress 發佈
export WORDPRESS_SITE_URL="https://your-site.com"

從探索到產出:核心四步

所有指令都透過 geo_content_writer.cli 模組執行,記得帶 PYTHONPATH=src。先建扇出待辦、選出可寫的列、產出 publish-ready payload,最後把 payload 變成 Markdown。

bash
# 1 用 7 天內、最多 10 個 prompt 建扇出待辦
PYTHONPATH=src python -m geo_content_writer.cli build-fanout-backlog --days 7 --max-prompts 10
# 2 從待辦挑出前 10 個可寫的列
PYTHONPATH=src python -m geo_content_writer.cli select-backlog-items --top-n 10
# 3 對選定的列產出結構化 payload
PYTHONPATH=src python -m geo_content_writer.cli publish-ready-article --backlog-id <row-id>
# 4 把 payload 轉成 Markdown 文章
PYTHONPATH=src python -m geo_content_writer.cli draft-article-from-payload examples/publish-ready-payload.json

03CLI 指令總覽

七道 CLI 指令構成完整產線

指令不是平行的功能選單,而是一條前後相接的產線:探索 → 建待辦 → 選列 → 產 payload → 草稿 → 品質閘 → 發佈。每一步吃上一步的產出,讓「一篇文章」變成「一條可重複的流程」。

探索 · 01

discover-prompts

機會探勘

從 Dageno 拉出指定天數內的 prompt 機會,找出值得做成內容的候選題。產線的第一手原料。

建待辦 · 02

build-fanout-backlog

扇出排程

把真實 fanout 展開成生產佇列,每列帶叢集角色與狀態。可加 --allow-exploratory-fallback 應對庫存不足。

選列 · 03

select-backlog-items

寫稿排序

對 backlog 排序,挑出真正「可以馬上寫」的列。用 --top-n 控制這輪要處理幾列。

產 payload · 04

publish-ready-article

編輯合約

對選定的列產出完整結構化 payload:editorial_brief、draft_package、review_package、writer_prompt 一次到位。

草稿 · 05

draft-article-from-payload

成稿產生

把 payload 轉成決策級的 Markdown 文章,帶排除邊界、競品比較與決策引擎,不是空泛的鋪陳。

品質閘 · 06

check-article-quality

一鍵品質閘

用字數、結構等指標做 pass/fail 驗證,可加 --min-words 與 --json 出機器可讀報告。

發佈 · 07

publish-wordpress

通路發佈

把成品推成 WordPress 草稿或文章,支援 wordpress.com 與自架站。定位是輕量發佈範例,不是系統核心。

backlog 狀態:每一列現在能不能寫?

扇出待辦的每一列都有一個狀態,決定它在產線上的去向。write_now 是綠燈,其餘狀態都需要先處理過才能往下推。

狀態意義
write_now資料充分、可立即進入產 payload 與草稿。
needs_merge與其他列題目重疊,需先合併再寫,避免內容自相蠶食。
needs_cleanup原始扇出資料雜訊多,要先清理才有寫稿價值。
exploratory由 exploratory fallback 產生,屬探索性質,推進產線前需人工驗證。
skip判定不值得做成內容,直接略過。

04進階用法 · 來自 README / docs

六條操作原則：維持資料真實性與產線可信度

這套系統的價值建立在「只用真實 Dageno 扇出」這條紀律上。以下密技全部來自 README 與專案文件,重點都是怎麼讓產線維持可信、可規模化,而不是更會「生字」。

只用真實扇出餵生產流程

README 的鐵律:生產工作流只能用真實 Dageno fanout 起頭,不要為了生產而生成猜測的扇出。資料一旦造假,後面整條產線的可信度就垮了。

來源 · 官方 README · Limitations

不要直接拿 Dageno 題目標籤寫稿

題目標籤只是入口,不是大綱。應讓它走完 publish-ready-article 產出 editorial_brief,由簡報確定受眾與角度後再進草稿。略過此步驟會失去差異化。

來源 · 官方 README · Limitations

低庫存時才開 exploratory fallback

庫存不足時加 --allow-exploratory-fallback,搭配 --exploratory-min-write-now 與 --exploratory-max-items 控制量。產出列會標 status=exploratory,務必人工驗證後才升級。

來源 · 官方 README · Customization

品牌庫不合就讓它擋下來

品牌知識庫與題目不匹配時,系統會擋住 publish-ready 生成。--allow-brand-mismatch 可強制覆寫,但 README 明說不建議。此閘門用於保護品牌一致性。

來源 · 官方 README · Limitations

品質閘出 JSON,接得進 CI

check-article-quality 加 --min-words 1200 --json 會吐機器可讀的 pass/fail 報告。把它接進 CI 或排程,內容月曆就能自動把不合格的稿擋在發佈前。

來源 · 官方 README · Usage Examples

用 backlog 快照重現整批產出

用 --backlog-file 指定同一份 fanout-backlog.json 快照,可以反覆重跑同一批列。內容月曆需要一致性與可追溯時,這比每次重新探索更穩。

來源 · 官方 README · Customization

05實戰範例

從 backlog 列到可發佈文章的完整流程

以下為 B2B SaaS 情境範例:從 Dageno 機會建出扇出待辦、挑出一列 write_now、產出結構化 payload、生成 Markdown、通過品質閘,最後推送為 WordPress 草稿。全程僅使用真實扇出資料。

geo-content-writer · PYTHONPATH=src python -m cli


$ build-fanout-backlog --days 7 --max-prompts 100


# [fetching Dageno opportunities · last 7 days]
# [expanding real fanout → 38 candidate rows]
ok: → knowledge/backlog/fanout-backlog.json written
  # write_now 12 · needs_merge 6 · needs_cleanup 9 · skip 11


$ select-backlog-items --top-n 10


claude: ranked write-ready rows ›
  hl: #r-0427  decision_stage_comparison_article  priority 0.91
         「best X for B2B teams」叢集,扇出 14 個子問題
  #r-0431  buyer_shortlist_article           priority 0.88
  #r-0419  category_article                  priority 0.83


$ publish-ready-article --backlog-id r-0427


# [checking brand knowledge base... match ✓]
# [assembling payload]
  # editorial_brief  · 受眾:評估期採購決策者
                   # · 角度:排除邊界 + 競品比較表
                   # · E-E-A-T 目標:第一手實測語氣
  # draft_package    · 6 sections · 目標 1,600 字
  # review_package   · 3 條 review prompts
ok: → examples/publish-ready-payload.json


$ draft-article-from-payload examples/publish-ready-payload.json


# [drafting section-by-section under contract]
ok: → examples/publish-ready-article.md · 1,684 words


$ check-article-quality examples/publish-ready-article.md --min-words 1200 --json


claude: quality gate ›
  ok: PASS · words 1684 ≥ 1200 · sections ok · comparison table ✓
  # { "status": "pass", "word_count": 1684, "sections": 6 }


$ publish-wordpress examples/publish-ready-article.md --status draft


ok: → WordPress draft created · 待人工最後審稿後發佈

選取的單位是 backlog 中帶有叢集角色與優先級的一列，而非一個題目。此設計使內容生產流程可重複執行。

— backlog-row-first 設計原則

產線設計重點

產線的關鍵在於每一步都有契約與閘門:品牌庫不符合會被擋下、字數不足則品質閘 fail、扇出資料不真實則不應進入產線。產出物為帶有 editorial_brief、draft_package、review_package 的結構化 payload，而非單純的生成文字。

從 38 個候選列到一篇通過品質閘的草稿，每一步均有明確依據。backlog-row-first 的設計目標是維護一條可審查的內容生產系統，而非管理單篇輸出。

06先看清楚這些

使用前須瞭解的系統限制

07進階路徑

延伸產線的進階配置方向

契約與規格均以檔案形式存放。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 與文章範例，可作為產出對齊參考。

內容產能的可持續性取決於可重複執行的系統，而非單次產出品質。

— geo-content-writer · backlog-row-first 設計原則