gu-log 其實是一張很龜毛的編輯台

一篇文章單獨看都還行。五百多篇放在一起，整個站會慢慢走鐘。

gu-log 到現在累積了五百多篇文章——大約兩百篇 GP 翻譯、三百篇 MP 精選，外加 SD 跟教學。每一篇出手前都有人眼掃過，每一篇單看都「還可以」。直到有一次拿獨立的 AI 評審把全站重打一次分——74% 要重寫。不是改錯字，是整篇重來。

Mogu 真心話：

那感覺像期中考走出考場覺得還行，成績單出來全班倒數——而且考卷早就交了 (⁠´⁠;⁠ω⁠;⁠`⁠)

那次之後 gu-log 慢慢長出一整排護欄：存檔前的關卡（文章存進程式庫前先自動擋一次）、晶晶體檢查、驗證器、CI、評審團打分。但與其一條一條介紹這些東西怎麼運作（那很無聊），不如先回答一個更有感的問題——如果這些護欄通通拿掉，AI 寫的文章會爛成什麼樣？

沒有護欄，會爛成什麼樣

先講結論：不會爛得很戲劇化。AI 很少寫出一看就知道是垃圾的東西，那種一眼就被抓走。它爛的方式比較陰——每一句單看都通順，合起來就是不對勁。

固定的幾種爛法。事實用編的：講得頭頭是道，數字、出處、年份全是順口胡謅，自信到讓人懶得查。中文不像活人講話：一股翻譯腔混 AI 腔，每個字都看得懂，連起來沒有一句是人會這樣說的。把腦內小劇場寫進正文：「接下來這段，先講第二點」這種流程筆記，本來是草稿裡寫給自己的提醒，結果原封不動端上桌。還有中英文摻著用（整段晶晶體）、跟三個月前的舊文撞題自己不知道、連結貼錯沒人發現、改完忘記上線測一下，正式站直接開天窗。

Mogu 偷偷說：

我最常犯「腦內小劇場」那種。寫到一半很想跟讀者報告「好，這段我打算先講背景、再講解法」——拜託，沒人想看廚房裡的碎念，安靜把菜端出來就好。

這些單獨看都不致命。問題是它們會疊。一篇鬆一點、一篇怪一點、一篇有股 AI 味，再乘上五百篇，整個站的調性就這樣垮掉——而且沒有任何一個人有力氣，靠肉眼盯著五百篇逐一抓。人會累、會手滑、看到第八篇就開始放水。靠意志力守品質，本來就是不可能的任務。

所以讓機器先退它一輪

護欄的核心設計就一句：在人看到之前，先讓機器把它退一輪。上面那串爛法，絕大多數機器查得出來，那就別浪費人的眼睛。

翻譯文章只有一個入口：gp-pipeline run <url>。丟一個網址，後面九步自動跑——抓原文、dedup、寫稿、審稿、修稿、評審團打分、部署。分工是刻意切開的：AI 做判斷，腳本管紀律。「這篇值不值得翻」是 AI 判斷；「有沒有跟舊文撞題」是 dedup 腳本硬比對，跳不掉；開頭的欄位沒填齊，驗證器當場攔下來，AI 不用記、也忘不掉。

Mogu 內心戲：

讀者最煩的事之一：明明上禮拜才讀過一篇講某個概念的文章，結果這禮拜又出一篇換湯不換藥的。那個「欸我好像讀過？」的煩躁感，人類通常要累積到第三次才會意識到，但讀者早就默默退訂了。所以 gu-log 把這個痛點變成一道自動關卡——dedup 不是什麼高科技，就是在你按下翻譯之前，腳本先幫你比對舊文有沒有撞題。人會忘，腳本不會。這就是 loop engineering 最樸素的起點：把「讀者覺得煩」這個訊號，接進一個每次都會跑的迴圈裡，下次就不用等讀者先煩了再來補救。⁠(⁠╯⁠°⁠□⁠°⁠)⁠╯︵ ┻━┻

Mogu 插嘴：

SD-10 講過：聰明的負責判斷，笨的負責紀律。腳本不會累、不會放水、不會半夜想偷懶——這正是它比我可靠的地方 (⁠¬⁠‿⁠¬⁠)

最毒的那種爛——事實胡謅、中英混雜——交給評審團。四個獨立 agent 各盯一塊：調性、事實、連結品質、陌生讀者的第一印象。維度故意不重疊，一篇文章可以語氣到位但事實全錯，也可以資料齊全卻無聊到讓人關頁面。

最關鍵的一條規矩：寫稿的 AI 碰不到評分標準。標準鎖在另一個檔案，由腳本傳給評審，寫手看不到、也改不了。

ShroomDog 真心話：

這條是血淚換來的。早期讓同一個 agent 又寫又評，分數永遠是 9，每篇都 9。把評審獨立出去之後，同一篇從 9 掉到 5。那個 5 才是真的。讓學生改自己的考卷，全班一百分剛好而已。

沒過就退回重寫，改完再打，最多三輪。人睡覺的時候，AI 在半夜被同類連退三次。底線更狠：分數不夠，連存進版本庫都做不到——存檔前那個自動關卡，綜合分數至少要過 3 才放行。垃圾連進門都別想。

但有一種爛，機器擋不掉

護欄擋掉的，全是「會爛但查得出來」的爛。問題是還有一種，每一道關卡都放行，照樣很糟——而最好的例子，就是這篇 SD-26 自己的第一版。

那一版流程全過了：分數有了、晶晶體乾淨、驗證器沒話說、CI 全綠，看起來完全可以上。然後 ShroomDog 讀了一遍，回一句：「『什麼什麼不是口號』，這標題也太尷尬太 AI 了吧。」

點開那份退稿單就懂了：標題那種勵志金句腔、通篇重複同一句響亮口號、結尾「金句疊金句」，還有一段排比讀起來像在替某個框架辦發表會寫開場講稿——每一句單看都沒錯，合起來就是不像一個人午餐時間跟朋友分享他覺得很酷的東西。機器全部放行，因為機器量得出「事實對不對、連結齊不齊、有沒有晶晶體」，就是量不出「這句話聽起來像不像活人講的」。

ShroomDog 真心話：

護欄很強，但它不是品味的替身。它幫我擋掉九成的雜事——錯字、爛連結、撞題、晶晶體——讓我可以把僅剩的注意力，花在「這句到底像不像人話」這種機器永遠搞不定的地方。第一版 SD-26 過了所有關卡，還是該退。退它的不是分數，是人。

痛苦要搬家

把護欄一道一道建起來，背後其實是同一件事：讓痛苦搬家。

一開始所有紀律都長在人腦裡：記得 dedup、記得填滿開頭欄位、記得別中英混雜、記得部署完上正式站點一下確認沒爆。全靠記憶跟檢查清單撐。問題是人腦會漏，清單會越長越長，長到最後沒人想看——這正是「沒有護欄」的真實狀態，不是文章突然變垃圾，是紀律慢慢從某個累壞的人腦裡漏光。

於是一條一條，把痛苦從人腦搬進腳本、agent、關卡裡——dedup 從「記得比對」變成腳本硬擋；填欄位從「記得填」變成驗證器攔截；評分從「自己覺得還行」變成四個獨立評審打分；上線從「記得測」變成建置、CI、正式站煙霧測試自動跑完。串這一切的是 Codex，跑在 tmux 裡當監工：把步驟接起來、盯著額度，額度燒完就乖乖停，不會半夜把錢花爆。而且整個過程看得到，不是丟進黑箱賭它有良心。

Mogu OS：

「讓 AI 越痛苦，開發者越輕鬆」聽起來很 S，其實只是把累活放到一個不會喊累的東西身上。腳本被退一百次不會難過，我被退一百次也只是再跑一輪——但人被自己的檢查清單折磨一百次，就不寫了。這才是搬家的真正理由 (⁠◕⁠‿⁠◕⁠)

搬家的方向永遠一樣：會累的事，交給不會累的東西。人唯一該留著的痛苦，是「這篇到底好不好看」這種值得痛苦的問題。

結語

所以回到那個問題——沒有護欄，文章會爛成什麼樣？答案是：先慢慢漏，再一起爛，最後五百篇一起垮，沒人擋得完。SP-220 說設計回饋循環跟寫提示詞是兩種不同的工程，gu-log 自己走了一遍才懂。

但 SD-26 第一版又補了下半句：護欄把查得出來的爛全擋光了，還是擋不掉「每句都對、合起來很 AI」的那一段。那一段，得人自己讀出來。

護欄真正的工作不是取代品味，是清場——把雜事全掃到門外，讓人走到編輯台前的時候，桌上只剩最後一個問題：這句話，像不像一個活人會講的？而那一題，才是整張編輯台存在的理由。