/goal 功能與 Evaluation Rubric — 讓 AI 自動跑 27 小時不偏離¶

Gary Chen（2026-05-24）。從 Anthropic 研究出發，拆解三大 AI 工具同時推出的 /goal 功能背後原理，並提出六步 SOP 將抽象的「品味」轉化為可自動執行的評分標準。

目錄¶

為什麼 AI 會偷懶停下來
三家公司同時推出 /goal
/goal 的運行原理
好提示詞五要素
Anthropic 的網頁設計實驗
六步 SOP：把品味變成 Rubric
核心觀點
相關資源

為什麼 AI 會偷懶停下來¶

真正的自動化不只是「把任務從你手上移到 AI 手上」，而是把那件事從你的心上徹底移開。只要心裡還掛著「等 AI 跑完我要回去改」，注意力就被佔用。

Anthropic 研究發現，LLM 做到一半會停的根本原因叫做 Context Anxiety（上下文焦慮）：

Context Anxiety 運作機制：

  Context Window 使用率上升
        │
        ▼
  LLM 感覺快滿了 → 開始慌
        │
        ▼
  啟動 wrap-up 機制 → 想要快點交差 → 提前停下

這是刻在 LLM 基因裡的「下班心態」。 /goal 功能就是為了對抗這種惰性而生。

三家公司同時推出 /goal¶

Claude Code、OpenAI Codex、Hermes Agent 幾乎同時推出同名功能 /goal：

工具	使用方式	核心行為
Claude Code	`/goal <目標>`	自動迭代到目標達成
OpenAI Codex	`/goal <目標>`	同上
Hermes Agent	`/goal <目標>`	同上

這不是巧合——三家都在解決同一個問題：AI 做到一半停下來問「我可以繼續嗎？」或更糟地，沒做完就假裝完成了。

歷史對照：去年中社群很火的插件 RoughLoop（靈感來自辛普森家庭裡永不放棄的角色 Ralph），做的就是同一件事——持續迭代到完成。如今這個理念變成了官方功能。

/goal 的運行原理¶

/goal 背後採用雙角色架構：

┌─────────────────────────────────────────────────┐
│              /goal 運行架構                       │
│                                                 │
│   ┌──────────┐      ┌──────────┐                │
│   │  實作者   │◄────│  評審    │                │
│   │ (Worker) │ 指令 │(Reviewer)│                │
│   └────┬─────┘      └────┬─────┘                │
│        │                   │                     │
│        ▼                   ▼                     │
│    執行任務           檢查目標                    │
│    產出成果           是否完成？                  │
│        │                   │                     │
│        │              ┌────┴────┐                │
│        │              │         │                │
│        │            未完成     已完成             │
│        │              │         │                │
│        │         點出問題     結束                │
│        │         給新方向    回報成果             │
│        │              │                          │
│        └──────────────┘                          │
│           (持續迭代)                              │
└─────────────────────────────────────────────────┘

比喻：就像在豬鼻子前面吊一根胡蘿蔔——豬還沒吃到就不會停下來，只有在到達終點時才給。

好提示詞五要素¶

隨便丟「把這個專案改得好一點」= AI 五分鐘交差。好提示詞需要五個關鍵元素：

#	元素	說明	範例
1	Outcome（結果）	完成時應該是什麼狀態	結帳頁反應速度降到 0.2 秒以內
2	Verification（驗證）	怎麼證明真的完成了	用速度測試工具驗證
3	Constraint（限制）	哪些事不能做	只能改結帳區塊，其他功能保持完好
4	Iteration Policy（迭代策略）	每次嘗試之間要做什麼	記錄改了什麼、測出速度、下一步方向
5	Error Handling（錯誤處理）	什麼情況要停下來回報	測試工具跑不起來或所有方法都試過

好提示詞範例（vs 壞提示詞）：

❌ 壞：「把這個專案改得好一點」
   → AI 做一兩個小改動就說完成了

✅ 好：「把網站結帳頁面的反應速度降到 0.2 秒以內，
     用速度測試工具驗證。過程中其他功能保持完好無缺。
     只能改結帳區塊的程式碼跟相關測試。
     每改一次就記錄改了什麼、測出速度、下一步方向。
     如果工具跑不起來或方法都用盡，停下來告訴我。」

核心洞察：好提示詞的關鍵不是 prompt engineering，而是你把「完成的定義」寫得有多明確。

Anthropic 的網頁設計實驗¶

Anthropic 讓 Claude 設計「漂亮的網頁」，面臨的核心問題是：漂亮是主觀的，AI 不會覺得自己做的東西醜（再醜都會自評為「現代感高質感」）。

解法：拆成四個可評分的維度¶

 Anthropic 網頁設計評估框架
 ┌──────────────┬────────────────────────────────────┐
 │ 維度         │ 判斷標準                           │
 ├──────────────┼────────────────────────────────────┤
 │ 1.設計品質   │ 顏色/字體/排版是否共同營造出       │
 │              │ 獨特的氛圍和識別感                   │
 ├──────────────┼────────────────────────────────────┤
 │ 2.原創性     │ 是否有刻意設計選擇？還是在用預設   │
 │              │ 模板？（如漸層卡片=沒原創）        │
 ├──────────────┼────────────────────────────────────┤
 │ 3.技術執行   │ 字體階層、間距、配色對比是否一致？ │
 ├──────────────┼────────────────────────────────────┤
 │ 4.可用性     │ 使用者能找到主要按鈕嗎？能直覺     │
 │              │ 完成來到網站的最初目的嗎？           │
 └──────────────┴────────────────────────────────────┘

關鍵技巧：加權模型弱項¶

Anthropic 發現 Claude 在技術執行和可用性上通常做得好，但在設計品質和原創性上容易產出平庸結果。所以他們故意提高弱項的評分權重，逼模型往不擅長的方向突破。

結果：第 10 輪的飛躍¶

第 1-9 輪：產出符合預期但不特別的美術館 landing page
第 10 輪：突然用 CSS 3D 透視渲染出虛擬房間，藝術品掛在牆上，觀眾走進不同廳——研究人員說「從未看過從單次 prompt 產出的創意」

非線性成長：不是每輪都比上一輪好。第 10 輪可能比第 15 輪漂亮。但只要評審和執行者繼續對話，複雜度和野心會增加，某幾輪會出現意料之外的飛躍。

評審的工作方式¶

不是讓評審看程式碼，而是讓評審用 Playwright 打開瀏覽器截圖，像真人一樣看實際畫面再打分。

六步 SOP：把品味變成 Rubric¶

這是影片最實操的部分，適用於任何「質化」工作（寫作、設計、影片剪輯等）。

Step 1：讓 AI 先跑一輪 baseline¶

不要急著寫 rubric。先丟 5-10 個任務給 AI，讓它隨便跑。這是在測驗 AI 目前的基準能力。

Step 2：親自看 AI 的產出，記錄「皺眉時刻」¶

每一個產出都親自看。重點不是「哪裡好」，而是皺眉的具體原因：

常見皺眉原因示例（寫作）：
├── 開頭沒有 hook，「在這個快速變化的時代」這種廢話開場
├── 沒有提供具體例子或數據
├── 滿滿的 AI 腔調（破折號、不是 A 而是 B 的句型）
└── 文章沒有作者個人視角

Step 3：把皺眉理由分類成維度¶

把散亂的清單收斂成幾個大類。例如 50 條皺眉理由可能收斂成：

皺眉理由 → 維度收斂示例

「邏輯有斷裂」
「前後文接不起來」──────→ 維度 1：邏輯鬆散
「沒有具體例子」
「沒有個人視角」─────────→ 維度 2：沒有人味
「用了破折號」
「不是 A 而是 B」─────────→ 維度 3：AI 腔調
「開頭沒 hook」

Step 4：把每個維度整理成具體案例¶

這是整套 rubric 的核心。不能寫「避免 AI 味」這種抽象描述，要寫：

❌ 抽象：「保持原創性」
✅ 具體：
   - 絕對不要用 Inter, Roboto, Arial, system fonts
   - 絕對不要用漸層層蓋在白色卡片上
   - 絕對不要用「在這個快速變化的時代」開頭
   - 絕對不要用「不是 A 而是 B」句型
   - 絕對不要用破折號連接兩個短句當節奏感

每一條都要評審一眼就能抓到、可推斷的標準。

Step 5：用多樣化案例取代單一範例¶

Anthropic 的血淚教訓：一開始 rubric 寫了「博物館等級的質感」，結果所有產出都變成博物館風，極度單一。

❌ 單一：「設計成博物館等級的質感」
   → 所有產出都長一樣

✅ 多樣：列出 11 種風格讓 AI 選擇
   → brutalist / art deco / pastoral / industrial /
     retro-futuristic / ...（根據當下狀況選擇）

原理：AI 容易對單一範例 overfitting（過度遵從），多個方向才能確保多樣性、激發創意。

Step 6：跑起來，人工校準¶

把 rubric 放進 /goal prompt，讓 AI 跑幾輪後人工抽查：

如果評審判斷和你的直覺不一致 → rubric 沒抓到你真正的標準，回去修改
通常三四輪校準後，你會發現內心對「做得好」的定義正在被一條一條梳理出來

核心觀點¶

影片最終想傳達的核心：

Evaluation > Prompt Engineering > Context Engineering

不論是 /goal 功能、Anthropic 的研究、還是 Andrej Karpathy 推出的 AUTOMODEL，全部指向同一件事——你能不能定義清楚「什麼叫做得好」。

Rubric 表面上是給 AI 用的，實際上是在逼你把腦中模糊的品味具體化成文字。一旦寫成文字，AI 就能幫你守住它、大規模執行它。