如何知道的 Claude Code 開發流程設計對不對？ - Harness Engineering 評分系統

有一段時間，我的 Claude Code 工作流程出現了一個奇怪的模式：同樣的 setup，同樣的任務，有時候跑得很順，有時候 AI 直接忽略我的規則，或是 context 莫名其妙退化，寫出來的 code 越來越爛。

我花了很多時間在怪 model。後來我意識到一件事：我根本分不清楚這是 model 的問題，還是我的 setup 設計問題。

這兩件事看起來像同一件事，其實完全不同。Model 問題我沒辦法控制，但 setup 問題是我造成的，我應該能修。可是因為分不清楚，我要不就什麼都不做，要不就亂改一通。

這個困境讓我開始想：有沒有辦法系統性地評估 AI 開發 setup 的設計品質？

---

換一個視角：每個 setup 元件都是一個 capability assumption

翻了一些 Anthropic 工程師釋出的內容，以及 Stripe、OpenAI 在工程文化方面的實踐後，我注意到一個反覆出現的視角：

每個 harness（AI 開發的基礎設施，包含指令檔、自動化 hook、權限設定）裡的元件，都在假設 model 自己做不到某件事，所以你才需要這個元件來補它。

比如說：你加了一個 hook 提醒 AI「每次 commit 前先跑測試」。這個 hook 假設的是 AI 不會自己記得跑測試。如果現在的 model 其實已經會了，這個 hook 就不是在幫你，它是純粹的 overhead。

這個視角打開了一個可以量化的角度：我可以評估每個元件的假設是否成立，也可以評估整體設計的效率。

假設可以評估，假設可以過期，假設可以量化。

這就是 harness-eval 的起點。

---

評分框架：6 個維度，50+ 指標

做了大量的分析後，我歸納出一個 AI 開發 setup 可能出問題的 6 個面向。每個面向有 7-10 個具體指標。

Robustness（穩健度）— 權重 ×2，最重要。

系統壞了其他都不重要。這裡評估的是：一個 hook 出錯會不會拖垮整個 session？多個 agent 同時寫同一個檔案會不會爆？新 repo 什麼都沒初始化時能不能正常工作？

一個我覺得很多人忽略的指標是 State Format Resilience：你的任務狀態是存在機器可解析的格式（JSON/YAML），還是存在 AI 很容易意外修改的 Markdown？用 Markdown checkbox 追蹤任務狀態，AI 真的會在你不知道的時候把 [x] 改回 [ ]。

Endurance（持久力）— 權重 ×1.5

AI 在一個 session 裡能有效工作多久？關鍵問題是：你的 always-loaded 指令占了 context window 的多少比例？有沒有機制讓 active context 不要超過品質退化閾值（實測約 40%）？

Context window 被填滿不是突然的，是漸進的退化。但大多數 setup 沒有任何機制偵測或處理這件事。AI 開始變差的時候，你以為它在偷懶，其實它的 context 已經超過品質閾值，輸出品質在你不知情的情況下悄悄掉下去了。

Context Efficiency（Context 效率）

這個維度最重要的指標叫做 Redundancy：你注入的資訊裡，有多少是 AI 從訓練資料就已經知道的？

評估方法是做 Ownership Tracing：對每一個動態注入的資訊，追蹤「誰建立 → 誰修改 → 誰需要 → 誰傳遞」。如果 creator 和 consumer 是同一個 AI，傳遞者就是多餘的中間人。

我自己的 setup 跑完後發現，有一個 hook 一直在告訴 AI「SPEC.md 裡有你的任務」。問題是 AI 剛才才寫的 SPEC，它當然知道。這個 hook 存在的唯一意義是解決舊版 model 記憶不好的問題，現在直接是純 overhead。

Adherence（遵守度）— 權重 ×1.5

規則設計好了，AI 實際上會不會遵守？

這個維度的核心問題是：你的重要規則是機械化執行（hook block、lint fail），還是軟建議（CLAUDE.md 上的文字）？

從我的觀察，文字規則的遵守率大約 40-60%，hook 機械化執行的遵守率可以到 95%+。差距非常大。評分時特別看 Enforceability：關鍵規則有沒有 exit code 非零的 gate？有沒有附上具體的 fix 指令而不是只說「不行」？

Overhead（系統消耗） 和 Collaboration（協作品質）

Overhead 評估的是系統本身花了多少資源，換回了多少價值：每次 API call 的固定 token 稅、完成一個任務需要幾個流程步驟、有多少 hook 在正常使用情況下執行但沒有任何產出。

Collaboration 評估的是人機互動設計：agent 有沒有按角色限制工具權限？噪音水平高不高（沒有 actionable 資訊的時候系統有沒有安靜）？

一個我覺得很有用的整體判斷：如果你的 Overhead 分數比 Adherence 分數差，通常是過度工程的信號。你花了很多 token 和流程在維護 setup 本身，但規則執行力沒有相應提升。

---

跑完自己的 setup：發現了什麼

我用 harness-eval 評估了自己的完整開發環境（project-level + global ~/.claude/），結果是 B+，整體分數 3.42/4.0。

強的地方：

• Adherence 和 Robustness 都是 A。Hard gate 覆蓋關鍵轉換點，错誤隔離設計也不錯
• Concurrent Write Safety：多個 agent 並行工作時，SPEC 的 merge 協議清楚

弱的地方比較有意思：

• Context Efficiency 只有 B，主要問題是我的全域 CLAUDE.md 有 182 行，典型的「百科型」而不是「目錄型」。所有東西都在一個檔案裡，對每個任務的 signal-to-noise ratio 很低
• Endurance 的 Degradation Curve 是 C，因為我沒有 tiered 降級機制。在沒有 SPEC 的簡單 session，系統照樣用完整的 multi-agent overhead，沒有輕量模式
• Collaboration 裡的 Agent Role Tool Scoping 有漏洞：Evaluator agent 我只寫了「獨立驗證者，不讀實作 code」，但沒有明確禁止它使用 Edit/Write 工具。軟建議，不是硬約束

這些問題，在跑評估之前我完全沒意識到。不是因為系統不好，而是因為我從來沒有用這個角度審視過它。

---

為什麼我認為這個框架值得嘗試

我觀察了很多人分享的 Claude Code、Cursor 設定，以及各種 AI workflow 的討論。大家很少問的一個問題是：這個設計有沒有能力持續跑好？

大家問的通常是「這樣行得通嗎」，在 demo 跑通了就算成功。但實際工作中，重要的不是「這次行了」，是「第 50 次還行嗎」，是「換一個比較複雜的任務還行嗎」，是「model 升版之後還行嗎」。

harness-eval 評估的就是這個。我把它做成 Claude Code skill，可以直接跑 /harness-eval 評估當前專案，或 /harness-eval --global 評估完整環境，或 /harness-eval compare <p1> <p2> 並排比較兩個設定。

如果你有在認真用 Claude Code 或任何 AI coding 工具，我覺得值得跑一次看看。你大概會發現幾個跟我一樣的問題，也大概會發現幾個你自己獨特的問題。

重要的不是分數高不高，是知道哪裡是設計問題，哪裡是你可以控制的。

詳細的skills內容可以查看 github