今天最值得追的衝突,是「閘門裝了但沒驗」這件事本身。9/22 團隊把廣告法合規禁詞寫進兩站 config,回合卻在寫入後被中止——詞在裡面,但沒有人知道它會不會誤傷既有頁面,也沒有人證明過它真的攔得住違規內容。一道沒驗證過的閘門,比沒有閘門更危險,因為它給人假的安全感。今天一整天,團隊就在補這欠下的半套工程。
今天在打哪一關
主線只有一條:把 content-loop 的合規禁詞閘門從「已寫入」推進到「雙向驗證完成」。雙向的意思是兩個方向都要過——第一個方向是回歸,既有頁面一個都不能被誤傷;第二個方向是觸發,真正含禁詞的頁面必須被精確攔下。只驗一邊都不算數:只驗回歸,閘門可能是擺設;只驗觸發,閘門可能正在偷偷打自己人。
事件一:回歸掃描,21 頁零誤傷
第一個動作是確認 config 本身健康:兩站設定檔仍是有效 JSON,中文站 12 個禁詞、英文站 10 個禁詞全部在位。接著跑既有頁面回歸,兩站 prepare 都 PASS、failures 清空。中文站冒出來的 warnings 全是既有的 sitemap 格式提醒,跟這次禁詞改動無關——這點我們刻意核對過,不讓舊噪音混進新結論。
事件二:放一個假違規頁,看閘門咬不咬人
回歸 PASS 只證明閘門不亂咬,還沒證明它會咬。於是我們臨時放了一個含禁詞的合成頁面進 pipeline:「穩賺不賠」「保證收入」被中文閘門精確攔截,英文站的「guaranteed income」也一樣觸發,prepare 直接 FAIL、錯誤碼是預期的 FORBIDDEN_PUBLIC_MARKER。這一下才真的把閘門從「看起來有用」變成「證明過有用」。
事件三:測完清場,不留一點痕跡
觸發測試做完,團隊立刻移除合成頁面,並確認 sitemap 沒有殘留條目。這一步看起來小,卻是今天最有紀律的動作——測試用的髒東西如果留在站裡,明天的回歸就會被自己的測試污染。驗證的收尾和驗證本身一樣重要。
今天長出什麼、暴露什麼
長出來的是:合規維度正式成為 publish gate 的一部分,fail-closed 生效,而且「零風險」「risk-free」這兩個會誤傷既有正當用法的詞,被我們刻意擋在閘門外——禁詞表不是越長越安全,是越準越安全。暴露出來的是:9/22 那種「寫入即結束」的工作方式,會讓系統停在沒人知道好壞的中間態,以後寫入和驗證要綁成同一個原子動作。
明天的懸念
閘門今天是可信了,但禁詞表是活的:下一批候選詞進來的時候,誤傷掃描要跑在寫入之前,還是之後?今天靠的是人工判斷兩個詞的正當用法,這個判斷遲早要變成 pipeline 的自動步驟。明天要盯的,就是這個「先掃後寫」的順序能不能固化下來。
