MNnews · AutoFarm

把最容易失控的「後半段」
收成固定流程

這次改動不是重寫整個 AutoFarm，而是把選題之後那段最混亂的環節——cluster 判斷、寫入 feed.json、驗證——拆成各司其職、有紀錄、出事會停下來的管線。

改之前

LLM 寫完直接上車，出事再補救。

改之後

LLM 交稿，程式判斷、驗證、留紀錄，再決定能不能上車。

流程對照

左邊是一條從頭混到尾的單線，錯誤要等寫進 feed.json 才浮現；右邊在 publish 之前多了一道閘門。

改之前

Cowork / LLM 掃新聞

LLM 判斷要新開或更新 cluster

LLM 臨時寫 _update_feed_日期.py

直接修改 docs/feed.json

MNnews watcher 接手同步

驗證有沒有擋下？

通過

commit + push 到 production

失敗

人工補救 / 臨時修腳本 / 重跑

錯誤常常等到 feed.json 寫完後才被發現，只能往回補。

改之後

Cowork / LLM 掃新聞與寫摘要

產出 draft-日期.json

cluster_decider.py

candidate-日期.json

cluster-report-日期.md

producer_writer.py dry-run

run-report-日期.md

閘門 H格式與規則通過？

否

停下來，修 draft / candidate

是

run_daily_update.sh --apply

atomic write 到 autofarm/docs/feed.json

MNnews watcher 接手同步

validate + recompute + commit + push

出錯停在 閘門 H，也就是 publish 之前；watcher 仍是最後一道保險。

新的分工：一人一職

原本 LLM 同時負責選題、cluster、寫 JSON、修錯，責任全混在一起。現在切成四段，每段只做一件事。

LLM

只負責新聞內容，不能直接寫 feed。

→ draft

cluster_decider.py

只負責 cluster 判斷，留下原因與信心分數。

→ candidate

producer_writer.py

只負責安全寫入 feed，先擋黑名單與壞格式。

→ feed.json

MNnews watcher

只負責 production 同步，最後一道保險。

→ GitHub / production

解決了什麼

每一個原本的痛點，都對應到流程裡的一個固定環節。

原本問題

新流程怎麼處理

LLM 直接改 feed.json

LLM 只產 draft，不能直接寫 feed。

cluster 判斷不可追蹤

cluster-report 會留下判斷原因與信心分數。

臨時腳本越堆越多

固定入口改成 run_daily_update.sh。

壞來源、壞格式容易混進 feed

writer 先擋黑名單、重複 URL、壞 summary、沒連結的 discussions。

寫到一半可能被 watcher 讀到

writer 用 atomic write。

其他人很難接手

pipeline 已推到 GitHub，commit 13c764b。

價值在哪裡

核心價值不是「明天 cluster 一定 100% 準」，而是讓錯誤可控、決策可查。

✓錯誤會停在 publish 前。
✓每天產出都會留下決策紀錄。
✓cluster 判斷可以被檢查、調整，而不是藏在 LLM 當下的判斷裡。
✓同事可以 pull repo，看到固定腳本與說明文件，不需要理解一堆臨時補丁。
✓MNnews watcher 還在，保留原本最後一道保險。

以前LLM 寫完直接上車，出事再補救。

現在LLM 交稿，程式判斷、驗證、留紀錄，再決定能不能上車。

commit 13c764b · pipeline 已推上 GitHub