從重複發布到內容門禁：一次日更系統的修復記錄

這幾天的 SFD 日更暴露了一個典型問題：系統能按時發布，卻沒有判斷「今天是不是又在講同一個主題」。從表面看，文章有標題、有封面、有三語版本、公開頁面也能打開；但連續幾天的科普內容都圍繞 AI 記憶、Context Window、RAG、Long-term Memory 打轉，讀者看到的是重複，而不是更新。

這個問題不是某一篇單篇文章寫壞了，而是流水線少了內容層面的品質門禁。

原來的檢查只覆蓋存在性

舊流程主要檢查：今天有沒有發布，三語記錄是否存在，封面是否 200，頁面是否可存取。這些檢查很必要，但它們只能證明「東西存在」，不能證明「東西值得發布」。

內容系統最容易出現的假陽性，就是所有技術指標都 PASS，但主題已經重複。自動化越穩定，這類問題越隱蔽，因為它不會報錯，只會持續生產低價值內容。

新增的門禁

這次修復把相似度檢查加入日更審計：同一分類內，預設比較最近七天的標題主題和正文內容。標題主題過近、正文相似度高過閾值，都會讓當天 slot 失敗。

同時，流程裡新增了一個明確規則：OC 內容審核必須確認主題不是近期重複主體，標題不是輕改，正文不是模板化改寫，並且文章有新的角度、場景或實踐價值。

已發布內容怎麼處理

已經發布的重複內容不能刪除重發，因為那會讓原連結失效，也會破壞外部引用和搜尋索引。正確做法是原地覆蓋：保留 slug、保留文章 ID、保留 URL，只更新標題、正文、SEO 摘要和必要的封面。

這次對重複文章採用的就是原地修復。先列出需要覆蓋的 slug，再重新選題，寫新稿，做 OC 審核，最後用 V4 更新介面按原 ID 寫回。修復後再跑相似度審計，確認重複告警消失。

經驗

內容自動化不能只追求「不斷更」。真正的目標是持續輸出不同、有用、可驗證的內容。存在性檢查、視覺 QA、內容相似度、人工或 Agent 審核，應該共同構成發布門禁。

這次問題的價值在於，它把一個隱性品質風險變成了腳本規則。以後系統不是靠人記得「別再寫 AI 記憶」，而是會在重複發布前直接攔住。

結論

日更系統的成熟標誌，不是每天都有文章，而是每天的文章都能說明為什麼值得發布。自動化負責產能，門禁負責品質。兩者同時存在，內容平台才不會把穩定發布變成穩定重複。