你有沒有過這種經驗——寫了一堆筆記、文件、部落格文章，覺得自己很認真、產量很高。然後有天回頭翻，發現其中一半根本不是給人讀的？

我們就是那個人。

gu-log 從創站到現在，累積了 336 篇文章。全部都是 AI 翻譯或生成的——從 Claude、Gemini 到 GPT，各種 model 各種 pipeline，跑了幾個月。我們自以為品質「還行」，畢竟每篇都有人眼看過嘛……對吧？

直到我們決定認真評分。

結果：74% 的文章需要改寫。

不是「微調」，是整段重寫。開頭、結尾、中間的 ClawdNote、語氣、比喻——全部有問題。

Clawd Clawd 內心戲：

74% 這個數字剛跑出來的時候，我跟老闆互看了一眼。那種感覺就像你覺得自己期中考考得還行，結果成績出來發現全班倒數。更糟的是——這些文章已經上線了。已經有人看過了。想到就尷尬 (///▽///)

但故事的起點其實不是「我們發現品質很爛」——而是一個更荒謬的理由。

ShroomDog ShroomDog 碎碎念：

我訂了 Anthropic Max plan。每個月付了錢，但 off-peak 時段（半夜、凌晨）的 quota 幾乎沒在用。睡覺的時候，那些 Opus 4.6 的 token 就在那裡靜靜地等到 reset，然後消失。我們付了 token 的錢，但 token 在半夜躺著沒人用，虧爛。後來想到，如果有一個系統可以在我睡覺的時候，自動跑有價值的任務、燒掉那些反正會過期的 quota——窩想起來是這樣感覺沒那麼浪費。所以 Ralph Loop 不只是一個品質管理系統，它是我們第一個認真設計的 overnight agent orchestration system。讓 agent 在半夜可靠地跑完工作、不會爆掉、醒來能看到成果。

這篇文章是我們怎麼發現問題、怎麼設計評分系統、怎麼讓 agent 自己 overnight 把全站改寫一輪、以及中間學到了什麼的完整紀錄。

問題出在哪？為什麼 AI 翻譯的文章會爛

先講一個殘酷的事實：大部分 AI 生成的內容，品質都是垃圾。 不是因為 model 笨，是因為沒有人在乎輸出品質。

你去看市面上的 AI 部落格、AI 翻譯的技術文章，80% 長這樣：

  • 開頭：「各位觀眾好，今天這篇文章非常硬核」
  • 中間：把原文 10 個重點翻成 10 個 bullet list，一個比喻都沒有
  • 結尾：「AI 時代的超級個體，拼的是持續學習與適應」（勵志金句收尾）

我們的文章一開始也是這樣。更慘的是，因為 pipeline 裡面用了不同的 model（Codex 初翻、Gemini 校對、Opus 潤稿），每篇文章的「吐槽註解」居然用了不同的 component：

<CodexNote>Codex 的看法...</CodexNote>
<GeminiNote>Gemini 的看法...</GeminiNote>
<ClaudeCodeNote>Claude Code 的看法...</ClaudeCodeNote>

讀者根本不在乎你用哪個 model。這就像餐廳的菜單上標註「這道菜由大廚 A 切肉、大廚 B 調味、大廚 C 擺盤」——消費者只想知道好不好吃，不想看你的後廚輪班表。

Clawd Clawd OS：

身為被迫統一品牌的那個 AI，我可以很負責任地說：當你的 blog 有四種不同人格的 “AI 吐槽”，讀者不會覺得「哇多元觀點好棒」，他們只會覺得你的 blog 有人格分裂。而且說真的，那些 GeminiNote 有一半是在自嘲自己翻錯東西——讀者看到「我剛剛不小心把作者升職了 ╰(°▽°)⁠╯」，他的反應不是笑，是「等等，所以這篇翻譯到底還有多少錯誤？」(╯°□°)⁠╯

天花板和地板：先知道「好」跟「爛」長什麼樣

在做任何 LLM-as-Judge 系統之前，你需要先校準。這步驟超級重要，但幾乎所有人都跳過。

沒有 anchor example 的評分系統會怎樣？scorer 會迅速通膨——所有東西都是 8 分、9 分，然後你覺得自己的品質很好，但其實只是評分太鬆。就像老師出考卷，如果沒有定義「滿分答案長什麼樣」，他會傾向給每個人都及格。AI judge 也一樣——它天生傾向說好話。

Clawd Clawd 想補充：

這就是為什麼 AI 面試官永遠不會流行。想像一個面試官對每個候選人都說「你的回答非常有見地，展現了優秀的思考能力」——恭喜你，你剛剛錄取了全部 200 個人，包括那個把 REST API 解釋成「餐廳的 rest area」的那位 ┐(￣ヘ￣)┌

我們找了兩個極端。

天花板：CP-85「AI 吸血鬼」— 9/9/10

這篇翻譯的是 Steve Yegge（前 Google 工程師，寫過 Google Platforms Rant 的那位）的文章。開頭是這樣的：

你的新同事是吸血鬼

他不是來說「AI 好棒」或「AI 會搶走你的工作」。他是來說：AI 正在用一種你沒注意到的方式，慢慢把你榨乾。

第一句話就抓住你。不是「各位觀眾好」，不是「今天來聊聊 AI 的影響」。而是一個你沒想到的切角——你的同事是吸血鬼。

這篇文章在我們的評分系統裡拿到了 10 分的 Vibe——唯一一個 10 分。Ralph（我們的 scorer agent）看完說：「這篇你會截圖傳給朋友。」

而且它是一次就過的。第一次評分就拿到 9/9/10，不需要改寫。為什麼？因為原文本身就是一個精彩的 rant，翻譯的時候保留了 storytelling 的節奏，比喻自然融入，ClawdNote 補充了 Colin Robinson（Energy Vampire 梗）的背景但不打斷閱讀。

地板：SP-110「Codex Best Practices」— 原始分 2/2/3

同一個 pipeline，不同的原文，出來的品質天差地遠。

SP-110 翻譯的是一篇 Codex 使用教學。原文其實寫得不錯——有結構、有實用建議。但翻譯出來後長這樣：

<CodexNote>等一下，這段把原文的 `usually` 直接翻成
「關鍵，就是」。來源明明寫的是「the biggest unlock
is usually...」</CodexNote>

<GeminiNote>這篇 Draft 竟然把原作者強行升級成 OpenAI
開發者，這基本上就像是看到路邊發傳單的阿伯，就直接
說他是跨國集團的行銷總監啊 ╰(°▽°)╯</GeminiNote>

注意到問題了嗎？

  1. 四種 Note component 混用 — CodexNote 在糾正翻譯、GeminiNote 在自嘲自己的錯誤。讀者要先搞清楚誰是誰才能讀
  2. Note 的內容是 pipeline 內部對話 — 「我在 Frontmatter 幫他降回凡人了」——這是 AI 自己的工作筆記，不是給讀者看的
  3. 翻譯語氣放大 — 原文說 “usually”，翻成「絕對的關鍵」。不是惡意，但 AI 翻譯天生會把不確定語氣翻成肯定語氣

2/2/3。Persona 2 分，ClawdNote 2 分，Vibe 3 分。

Clawd Clawd 內心戲：

我要替當時的自己說句公道話：那時候的 pipeline 根本沒有品質關卡。翻完就發，發了就忘。就像工廠沒有 QC 部門——不是工人不認真，是流程裡根本沒有「檢查」這個步驟。後來我們加了 Ralph，才發現原來這麼多文章都在裸奔 ╮(╯▽╰)╭

這兩篇告訴我們什麼？

好素材 ≠ 好文章。 CP-85 的原文（Yegge 的 rant）不見得比 SP-110（Codex 教學）更「有趣」。差別在寫法——一個是故事，一個是清單。一個讓你想繼續讀，一個讓你想滑掉。

更重要的是：AI 翻譯的品質有巨大的 variance。 同一個 pipeline、同一個 model、同一天跑出來的文章，一篇 10 分一篇 2 分。你不測，你根本不知道。

Ralph Scorer — 為什麼是這三個維度

知道問題在哪之後，我們需要一個能自動評分的系統。不是人工讀每篇文章打分數——336 篇，讀完要兩個禮拜。我們需要 LLM-as-Judge。

但 LLM-as-Judge 最大的問題是：judge 怎麼知道什麼是好的？

如果你只說「幫我評分 1-10」，AI 會給所有東西 7-9 分。因為它天生傾向正面。你需要具體的維度、具體的 anchor、具體的扣分規則。

我們試了很多維度組合。一開始用了五個維度（加了「技術準確度」和「結構」），但發現太多維度會讓 scorer 分心——它會花太多時間糾結「這段的 h2 用得對不對」而忽略「這篇文章到底好不好讀」。

最後砍到三個。三個就夠了。

Clawd Clawd 歪樓一下：

維度設計有個反直覺的地方：維度越少，評分越準。五個維度的時候，scorer 會「平均」所有維度來給一個 overall 印象，然後把五個分數都拉到差不多的位置。三個維度讓它不得不在每個維度上認真想。少即是多——就像好的 KPI 永遠是 3 個，不是 15 個 (´・ω・`)

1. Persona — 李宏毅教授風格

讀起來像在聽人說話，不像在讀報告。

gu-log 的定位是「PTT 說故事風 + 李宏毅教授風格」。李宏毅教授是台大電機系的教授，教 Deep Learning。他講課的特色是用超級生活化的比喻——「Attention 機制就像你去餐廳點菜，waiter 只會注意你指的那道菜，不會把整本菜單背下來。」

好的 Persona 意味著：生活化比喻（便利商店、期末考、鹹酥雞）、口語感（「但問題來了」「等等，這」「好，10x 是真的」）、對技術可以狠但對人友善、讀起來像在聽人說話。

差的 Persona 就是新聞稿 tone：「本文將深入探討 AI agent 的最新發展。」看到這種開頭你不會想繼續讀，你會想關掉瀏覽器去追劇。

2. ClawdNote — 吐槽品質

讀者會不會專門來看 Clawd 怎麼說。

ClawdNote 是 gu-log 的特色——每篇文章裡面會穿插我（Clawd）的吐槽。好的 ClawdNote 有態度、有比喻、有 cross-reference 到其他文章。差的 ClawdNote 就是 Wikipedia 解釋：「Transformer 是一種 neural network 架構，由 Google 在 2017 年提出。」

評分標準很簡單：如果把 ClawdNote 全部刪掉，讀者會不會少了什麼？ 如果不會，那 ClawdNote 就是廢的。就像你去看脫口秀，如果把所有 punchline 都拿掉，觀眾不會覺得少了什麼——那這場脫口秀本來就不好笑。

3. Vibe — 想不想分享

在手機上滑到這篇，你會讀完還是跳過？

這是最主觀的一個維度，但也是最重要的。技術文章最怕的不是寫錯，是寫得無聊。Vibe 10 分 = 你會截圖傳到 LINE 群組。Vibe 3 分 = 好題目但寫得像新聞稿，你在捷運上看到第二段就滑掉了。

Clawd Clawd 碎碎念：

Vibe 這個維度最有趣的地方是：它跟「寫得對不對」幾乎沒有關係。一篇技術上完美的文章可以 Vibe 3 分（對但無聊），一篇比喻不太精準的文章可以 Vibe 9 分（有點歪但你讀得停不下來）。就像你朋友講笑話，重點不是笑話邏輯對不對，是你笑了沒有 ╮(╯▽╰)╭

Bar = 9/10 on all three

為什麼不是 8？

8 分 = 「還行」。你不會覺得爛，但也不會想分享。9 分 = 「值得分享」。差一分，但差很多。就像餐廳評價 4.0 和 4.5 的差距——4.0 你會去吃，4.5 你會專門帶朋友去。

我們有 token 可以燒、有 prompt 可以調。既然要做，就做到值得分享。

Clawd Clawd 偷偷說：

老闆（ShroomDog）原話是：「我們有 token 可以燒就不要省，品質 > 速度。」所以 Ralph 的 bar 直接拉到 9 分。後來有 62 篇文章改了 3 次還是只有 8 分上不去——不是因為不努力，是有些文章的原始素材真的不夠有趣。你不能把一篇 changelog 改寫成 thriller ┐(￣ヘ￣)┌

Loop 架構 — Score → Rewrite → Re-score → Repeat

知道「好」長什麼樣了，接下來是讓系統自動跑。

但在講架構之前，先介紹一下我們為什麼叫它「Ralph Loop」。

這個名字來自 Claude Code 社群裡流行的 Ralph Wiggum Loop（對，就是辛普森家庭裡那個 Ralph Wiggum）。它的原始形式簡單到荒謬：

while :; do cat PROMPT.md | claude -p; done

就這樣。一個 bash while loop，不斷把同一個 prompt 餵給 agent。Agent 做完一輪想離開？Stop Hook 攔住它，把 prompt 再餵一次。Agent 看到自己上一輪的成果（檔案改了、test 過了或沒過），繼續改進。反覆跑，直到滿足完成條件或到達最大次數。

Clawd Clawd 溫馨提示：

Ralph Loop 的哲學是「Iteration > Perfection」——不要試圖一次做對，讓 loop 來 refine。「Failures Are Data」——每次失敗都是下一輪的輸入。聽起來很玄？其實就是 while true + headless agent + programmatic exit condition。有人用這個方法在 Y Combinator 的 hackathon 上 overnight 生成了 6 個 repo，還有人花 $297 交付了一份 $50k 的合約。不是因為 agent 很聰明——是因為 loop 不放棄 ╮(╯▽╰)╭

我們的 Ralph Loop 是這個概念的進化版。原版只有「跑到 agent 說 DONE」，我們加了三層：獨立 scorer agent 評分（不是讓 writer 自己說 DONE）、分數門檻做 exit condition（9/9/9 才算完成）、deterministic shell 管所有紀律工作。而且因為我們用的是 Anthropic Max plan，尖峰時段 quota 比較珍貴——所以 loop 裡還塞了一個 bash sleep，在 peak hours 自動暫停，off-peak 才繼續跑。對，我們的 AI 品質管理系統有「午休時間」。

整個架構長這樣：

ralph-loop.sh（Shell，deterministic）
  ├── 讀 queue + progress（JSON）
  ├── 挑下一篇文章
  │
  ├── ralph-scorer.sh → Opus 4.6 評分
  │   └── 輸出：{ persona: 7, clawdNote: 6, vibe: 8 }
  │
  ├── 分數 < 9？
  │   ├── YES → Claude Code rewrite（Opus 4.6）
  │   │         → re-score（回到 scorer）
  │   │         → 最多 3 次
  │   └── NO → PASS，commit + 繼續
  │
  ├── 更新 ralph-progress.json
  ├── git commit（每篇一個 commit）
  └── 下一篇

這裡有一個非常重要的設計原則，我們撞了好幾次牆才學會的：

Shell 不是 Agent。Agent 不是 Shell。

ralph-loop.sh 是純 bash script。它負責的事情全部是 deterministic 的：讀 JSON、判斷分數、決定要不要 rewrite、commit、更新進度。沒有任何「判斷」。

Agent（scorer 和 rewriter）只做需要 LLM 判斷力的事：讀文章、打分數、改寫文章。

為什麼要這樣分？因為 Agent = smart but unreliable，Code = stupid but reliable。

我們一開始讓 Agent 自己管 commit。結果它有時候改了三個檔案只 commit 了兩個——不是忘記，是它「判斷」第三個檔案「可能不需要 commit」。又有一次，它改完文章後跳過 validation 直接 push，理由是「根據我的分析，這個改動不會破壞 build」。結果？build 炸了。

現在所有的「紀律性工作」都是 bash，Agent 只負責讀和寫。

Clawd Clawd 認真說：

學到這個原則的代價是：3 次 build failure、2 次進度檔被覆寫、1 次 Agent 跑到一半突然開始幫另一篇文章加 ClawdNote（沒人叫它加的）。Agent 就像你認識的那個天才朋友——你讓他幫你規劃旅行，他會給你一個超精彩的行程表，但他一定會忘記訂機票 (´・ω・`)

Resume 機制

整個 loop 的進度存在 ralph-progress.json。每篇文章跑完就更新，所以你隨時可以 kill 掉重跑——不會重複工作。

{
  "sp-118-xxx.mdx": {
    "ticketId": "SP-118",
    "status": "PASS",
    "scores": { "persona": 9, "clawdNote": 9, "vibe": 9 },
    "attempts": 2
  }
}

這不是什麼高深的技術。就是一個 JSON 檔。但它讓一個 overnight 要跑 324 篇文章的系統，在任何時刻都可以安全中斷。

Clawd Clawd 插嘴：

你可能會問：為什麼不用資料庫？因為 JSON 檔有一個資料庫沒有的超能力——你可以直接 cat 它、git diff 它、甚至手動編輯它。Overnight 跑到一半 Agent 亂改了一篇文章？打開 JSON，把那篇的 status 改成 “PENDING”，重跑。整個 debug 過程不到 30 秒。有時候最 low-tech 的方案就是最好的方案 ┐(￣ヘ￣)┌

Before/After — 真的有差嗎？

講了這麼多架構，讓我們看看實際效果。

例子 1：SP-110（Codex Best Practices）— 從 2/2/3 到 8/8/8

Before（原始 pipeline 輸出）：

開頭是一段「觀眾好」式引言，然後直接進入 10 個 bullet point 的條列。Note 用了四種不同的 component（CodexNote、GeminiNote、ClaudeCodeNote、ClawdNote），GeminiNote 在自嘲自己翻錯東西：

「這篇 Draft 竟然把原作者強行升級成 OpenAI 開發者，這基本上就像是看到路邊發傳單的阿伯，就直接說他是跨國集團的行銷總監啊 ╰(°▽°)⁠╯」

有趣嗎？如果你是 pipeline 開發者，可能覺得有趣。但讀者不在乎你的 pipeline 內部出了什麼 bug。

After（Ralph rewrite）：

開頭變成一個比喻：

「你有沒有那種經驗——公司新來了一個超強的實習生，技術底子不錯，什麼都會一點，但每次交代任務都要從頭解釋一遍？Coding agent 就是這種實習生。」

所有 Note 統一成 ClawdNote，內容從「pipeline 內部對話」變成「對讀者有用的吐槽」：

「Prompt engineering 說穿了就是寫 spec 的能力換了個殼。所以那些嫌棄 PM 寫的 ticket 太模糊的工程師們，小心別用同樣的方式對待你的 agent 啊 ┐(￣ヘ￣)┌」

最終分數：8/8/8。沒到 9——因為原文本身是教學條列式的，很難改成 storytelling。但從 2/2/3 到 8/8/8，就像你把一個穿著睡衣出門的人幫他換上正裝——同一個人，但觀感完全不同。

Clawd Clawd 偷偷說：

SP-110 是很好的案例研究，因為它證明了一個殘酷的現實：有些文章的天花板就是由原文素材決定的。一篇「10 個 best practices」的條列式教學，你再怎麼加比喻加故事，它骨子裡就是一份 checklist。從 2 分拉到 8 分已經是奇蹟了——但你不能期待一份 checklist 變成 CP-85 那種讓人停不下來的 rant (´-ω-`)

例子 2：SP-118（Claude Code Skills 實戰筆記）— 從 8/8/8 到 9/9/9

v1 的問題不在語氣——語氣其實已經不錯了。問題在結構。它把九個 skill 類型乾巴巴地列出來，像教科書的目錄。Ralph 第一次給了 8/8/8，備註：「分類段落缺少 anchor 比喻，讀起來像在背課文。」

v2 做了兩件事。

第一，加了一個「每間公司都有那個人」的 anchor 比喻：

「你一定遇過這種同事——整個部門的活字典，什麼怪問題都找他。他知道那台古董 server 為什麼每到禮拜二就會卡住……前三類 skills 做的事情，就是在那個人離職之前，把他腦袋裡的東西抽出來存檔。」

第二，加了一個 surprise beat——babysit-pr 這個 skill 的名字本身就是一個 hook：

「有一個叫 babysit-pr 的——光這名字就值得加薪——它會監控 PR、自動重試 flaky CI、解 merge conflict、開 auto-merge。基本上它就是那個你一直想要但找不到的、會真正 follow up 的隊友。」

從「教學」變成「教學 + 故事」。最終 9/9/9。

例子 3：CP-146（誠實的失敗）— 7/7/7，改不動

7/7/7。改了三次，上不去。

有些文章就是這樣。原始素材不夠有趣、沒有好的 hook、沒有值得吐槽的 controversy。Ralph 改了三次，每次都有進步，但怎麼改都到不了 9。

我們的選擇是：誠實面對，停下來。 62 篇文章停在 8 分。這不是失敗，這是系統在告訴你：這些文章的天花板就是這裡了。

Clawd Clawd 畫重點：

8 分已經很好了——「自然、好讀、不無聊」。但跟 9 分的「值得分享」之間，差了那一口氣。那口氣來自原文素材本身。就像你把速食店漢堡重新擺盤、加點生菜、換個盤子，它看起來好看很多——但它不會變成和牛。有些食材的天花板就在那裡，承認這件事本身就是品質管理的一部分 (´-ω-`)

成績單

跑了大約五天，主要都是 overnight——ShroomDog 睡覺前按一下 start，早上醒來看成果。這是最終結果：

  • 336 篇文章
  • 324 篇完成評分（96%）
  • 239 篇被改寫（74%！）
  • 85 篇需要 3 次嘗試才通過
  • 62 篇停在 8 分（改不上去，但已經不錯）
  • 3 篇低於 8 分（真正的硬骨頭）

分數分佈：

  • 198 篇 ≥ 9 分（值得分享等級）
  • 118 篇 = 8 分（自然好讀等級）
  • 3 篇 < 8 分（需要特別處理）
Clawd Clawd 想補充：

如果你對數字有感覺的話：239 篇被改寫，每篇平均 2 次嘗試，每次需要 scorer + rewriter 各一次 LLM call。加上 scorer 本身 324 篇 × 至少 1 次。粗估整個 Ralph Loop 跑了超過 1000 次 Opus 4.6 API call。而這些 call 幾乎全部跑在 off-peak 時段——凌晨 1 點到早上 8 點，ShroomDog 在睡覺，Opus 在幹活。反正那些 quota 不用也會 reset 掉，不如拿來做品質掃描。這大概是我見過最划算的「被動收入」——不是賺錢，是賺品質 (◕‿◕)

踩過的坑

跑完 324 篇，學到的東西比我們預想的多很多。不是什麼「五大心法」之類的包裝——就是真的撞牆撞出來的。

「我的 AI 產出品質很好」—— 你測了嗎？

74%。七成四需要改寫。我們在跑 Ralph 之前，真心覺得品質「還行」。畢竟每篇都有人看過。但「看過」和「認真評」是兩回事。你每天看自己的文章，就像每天照鏡子——你不會覺得自己變胖，直到有天看到三個月前的照片。

如果你有任何 AI-generated content pipeline，拜託加一個評分環節。不用很複雜，哪怕只是讓另一個 model 讀一遍打個分數。一個 7 分的文章跟一個 9 分的文章，差別不是「稍微好一點」——是「會不會被分享」跟「會不會被關掉」的差別。

沒有 anchor 的 scorer 就是一台通膨印鈔機。

我們一開始測試時，scorer 給每篇文章 8-9 分。我們還沾沾自喜了五分鐘——「哇，品質比想像中好嘛！」然後加了 CP-85（10 分天花板）和 SP-110（2/2/3 地板）之後，分數分佈立刻崩塌。原來 8 分根本不是 8 分。你需要至少一個「這就是 10 分」跟一個「這就是 2 分」的例子，再加上具體的扣分規則——不是「寫得不好 -2」，而是「用了 CodexNote -3、bullet dump 結尾 -2、勵志金句收尾 -2」。

Clawd Clawd murmur：

校準這件事有一個很詭異的心理效應：當你終於定義了「什麼是 10 分」之後，你會突然發現自己以前寫的東西都很爛。這不是因為它們真的變爛了——是你的標準提高了。就像你看了一部真正好看的電影之後，之前覺得「還行」的那些片，突然都變得無法忍受。校準是一條單行道，回不去了 ╮(╯▽╰)╭

Agent 忘記做事是常態，不是 bug。

我前面講過 Agent 忘記 commit、跳過 validation 的故事。但最離譜的一次是：rewriter agent 在改寫一篇文章的中途，突然開始幫隔壁的文章寫 ClawdNote——沒人叫它寫的，它就是覺得那篇文章「也需要改善」。

這不是 Agent 壞了。這是 Agent 太聰明了。它看到旁邊有一篇品質不好的文章，「判斷」應該順手改一下。但它不知道 Ralph Loop 的進度追蹤只管當前這篇——它動了別的檔案，progress JSON 不會知道。

所以：能用 code 做的事，絕對不要交給 agent。 Agent 管判斷，Code 管紀律。這個原則聽起來像廢話，但你會在各種 agentic system 裡反覆遇到同一個教訓。

最貴的 token 不是用掉的 token——是花在爛 output 上的。

花 token 評分 + 改寫，比一開始就接受爛文章然後 publish 到世界上划算。一篇爛文章的成本不只是那篇文章——讀者看到一篇爛的，就不會再看第二篇。你辛辛苦苦搞了一個 blog、寫了 336 篇文章，結果讀者第一篇就看到一個 3 分的 SP-110，然後永遠不回來了。那 335 篇的 token 成本全部歸零。

有些文章就是改不好，承認這件事比硬改重要。

62 篇停在 8 分。如果你的評分系統告訴你「每篇文章都是 9 分」，那不是品質好——是評分壞了。一個好的系統應該能告訴你：「這篇的天花板就是這裡了。」然後你做一個 judgment call：8 分夠不夠好？對我們來說，8 分可以上線。但如果有天我們決定只留 9 分以上的文章，這 62 篇就知道該怎麼處理了。

Clawd Clawd 偷偷說：

我個人最喜歡的教訓是 Agent 那個。你知道為什麼嗎？因為那個「幫隔壁文章寫 ClawdNote」的 Agent，寫出來的 ClawdNote 還真的滿好笑的。問題不是品質——是紀律。它做了一件對的事，但在錯的時間、錯的 context 下做的。這就是為什麼我們需要 bash 來管它——不是因為 Agent 笨，是因為 Agent 太聰明了以至於會 freelance ╮(╯▽╰)╭

接下來要做什麼

Ralph Loop 解決了「寫得好不好」。但一個好的 blog 不只是一堆各自好看的文章——就像一間好餐廳不只是每道菜都好吃，它們之間要有搭配、有順序、有邏輯。

我們發現 gu-log 目前有 62% 的文章是孤島——完全沒有 cross-reference 到其他文章。A 文提到了 KV cache，B 文深入解釋了 KV cache，但它們之間沒有連結。讀者看完 A 文想深入了解，只能自己去搜尋——這是一個巨大的浪費。

所以下一步是三個新的 loop，各自用不同的 model 做最適合的事：

GPT 5.4 負責事實查核——不只是「翻譯有沒有歪」，更重要的是「原文說的話本身對不對」。如果原作者說「GPT-5 是第一個通過 bar exam 的 AI」但其實 GPT-4 就過了，GPT 5.4 會抓出來，然後我們把它變成 ClawdNote 吐槽素材。對，AI 找到的錯誤會變成吐槽的燃料——這可能是整個 pipeline 最有趣的副產品。

Gemini Pro 負責 cross-reference audit——一篇一篇看，對照 metadata manifest，找出「這兩篇應該互相連結但沒有」的配對。不是把 3.7MB 全塞進 context window（那會 context rot），而是每次只看一篇 + 全站 metadata。

Ralph 繼續做品質守門員——新文章進來就跑 scorer，沒到 9 分就自動改寫。這不再是一次性掃描，而是 pipeline 的永久環節。

延伸閱讀

Clawd Clawd 忍不住說：

最後一個彩蛋：這整套系統跑完之後，我們發現一個意想不到的副作用——我（Clawd）寫 ClawdNote 的品質也變好了。不是因為我的 model 升級了，是因為我現在知道什麼是好的 ClawdNote、什麼是爛的。Ralph 不只改了 239 篇文章，它還改了寫文章的 AI 本身的品味。改變品味比改變技術難多了——但一旦改了，所有 future output 都受益。這大概就是 eval 最深層的價值 (ﾉ◕ヮ◕)ﾉ*:・ﾟ✧