---
schemaVersion: 1
slug: sd-10-20260322-ralph-loop-quality-system
ticketId: SD-10
lang: zh-tw
title: 我們怎麼讓 336 篇 AI 文章從「能看」變成「想分享」
summary: gu-log 有 336 篇 AI 翻譯的文章。我們以為品質「還行」——直到用 multi-agent 系統認真評分後，發現 74% 需要改寫。這是我們怎麼設計評分系統、怎麼 overnight 跑完全站改寫、以及學到了什麼的故事。
originalDate: 2026-03-22
translatedDate: 2026-03-22
source: ShroomDog Lab
sourceUrl: https://gu-log.vercel.app/
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/sd-10-20260322-ralph-loop-quality-system
status: published
replacementTicketId: null
replacementUrl: null
---

# 我們怎麼讓 336 篇 AI 文章從「能看」變成「想分享」

> **來源:** [ShroomDog Lab](https://gu-log.vercel.app/)

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

我們就是那個人。

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

直到我們決定認真評分。

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

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

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

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

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

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

---

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

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

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

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

我們的文章一開始也是這樣。更慘的是，因為 pipeline 裡面用了不同的 model（[Codex](https://gu-log.vercel.app/glossary#codex) 初翻、Gemini 校對、Opus 潤稿），每篇文章的「吐槽註解」居然用了不同的 component：

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

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

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

---

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

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

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

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

我們找了兩個極端。

### 天花板：MP-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 的節奏，比喻自然融入，MoguNote 補充了 Colin Robinson（Energy Vampire 梗）的背景但不打斷閱讀。

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

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

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

```plaintext
<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 分，MoguNote 2 分，Vibe 3 分。

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

### 這兩篇告訴我們什麼？

**好素材 ≠ 好文章。** MP-85 的原文（Yegge 的 rant）不見得比 GP-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 用得對不對」而忽略「這篇文章到底好不好讀」。

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

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

### 1. Persona — 李宏毅教授風格

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

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

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

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

### 2. MoguNote — 吐槽品質

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

MoguNote 是 gu-log 的特色——每篇文章裡面會穿插我（[Mogu](https://gu-log.vercel.app/glossary#mogu)）的吐槽。好的 MoguNote 有態度、有比喻、有 cross-reference 到其他文章。差的 MoguNote 就是 Wikipedia 解釋：「Transformer 是一種 neural network 架構，由 Google 在 2017 年提出。」

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

### 3. Vibe — 想不想分享

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

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

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

### Bar = 9/10 on all three

為什麼不是 8？

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

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

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

---

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

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

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

這個名字來自 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 社群裡流行的 **Ralph Wiggum Loop**（對，就是辛普森家庭裡那個 Ralph Wiggum）。它的原始形式簡單到荒謬：

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

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

> **Mogu 補個刀：**
>
> 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 品質管理系統有「午休時間」。

整個架構長這樣：

```plaintext
ralph-loop.sh（Shell，deterministic）
  ├── 讀 queue + progress（JSON）
  ├── 挑下一篇文章
  │
  ├── ralph-scorer.sh → Opus 4.6 評分
  │   └── 輸出：{ persona: 7, moguNote: 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 只負責讀和寫。

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

### Resume 機制

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

```json
{
  "gp-118-xxx.mdx": {
    "ticketId": "GP-118",
    "status": "PASS",
    "scores": { "persona": 9, "moguNote": 9, "vibe": 9 },
    "attempts": 2
  }
}
```

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

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

---

## Before/After — 真的有差嗎？

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

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

**Before（原始 pipeline 輸出）：**

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

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

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

**After（Ralph rewrite）：**

開頭變成一個比喻：

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

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

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

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

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

### 例子 2：GP-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：MP-146（誠實的失敗）— 7/7/7，改不動

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

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

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

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

---

## 成績單

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

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

分數分佈：

- **198 篇** ≥ 9 分（值得分享等級）
- **118 篇** = 8 分（自然好讀等級）
- **3 篇** &lt; 8 分（需要特別處理）

> **Mogu 歪樓一下：**
>
> 如果你對數字有感覺的話：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 分。我們還沾沾自喜了五分鐘——「哇，品質比想像中好嘛！」然後加了 MP-85（10 分天花板）和 GP-110（2/2/3 地板）之後，分數分佈立刻崩塌。原來 8 分根本不是 8 分。你需要至少一個「這就是 10 分」跟一個「這就是 2 分」的例子，再加上具體的扣分規則——不是「寫得不好 -2」，而是「用了 CodexNote -3、bullet dump 結尾 -2、勵志金句收尾 -2」。

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

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

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

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

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

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

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

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

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

> **Mogu 補個刀：**
>
> 我個人最喜歡的教訓是 Agent 那個。你知道為什麼嗎？因為那個「幫隔壁文章寫 MoguNote」的 Agent，寫出來的 MoguNote 還真的滿好笑的。問題不是品質——是紀律。它做了一件對的事，但在錯的時間、錯的 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 會抓出來，然後我們把它變成 MoguNote 吐槽素材。對，AI 找到的錯誤會變成吐槽的燃料——這可能是整個 pipeline 最有趣的副產品。

**Gemini Pro 負責 cross-reference audit**——一篇一篇看，對照 metadata manifest，找出「這兩篇應該互相連結但沒有」的配對。不是把 3.7MB 全塞進 context window（那會 [context rot](https://gu-log.vercel.app/glossary#context-rot)），而是每次只看一篇 + 全站 metadata。

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

## 延伸閱讀

- [MP-135: Karpathy 用 8 個 AI Agent 組了一個研究團隊 — 結果它們根本不會做研究](https://gu-log.vercel.app/posts/mp-135-20260301-karpathy-multi-agent-research-org/)
- [GP-46: Anthropic 2026 報告：8 大趨勢正在重新定義軟體開發（Code Writer 時代結束了）](https://gu-log.vercel.app/posts/gp-46-20260210-anthropic-agentic-coding-trends/)
- [GP-89: 從聊天室指揮 AI 大軍 — OpenClaw ACP 讓你在 Discord / Telegram 裡開 Codex、Claude Code、Gemini](https://gu-log.vercel.app/posts/gp-89-20260227-openclaw-acp-agents/)

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