為什麼我的 AI Agent 需要品質哲學

我發了一則推文：「我發現 Ralph loop 傾向於想把工作完成。以一種糟糕的方式。相反地，我在 Jiro 中建置了一整套哲學和品質關卡。但仍然必須打破機器中根深蒂固的人類劣習。它是一台機器！它不會休息。」

有人回覆：「你基本上是在試圖教這個迴圈節制、品味，以及某種近似於道德停頓的東西——而這些正是基礎 Ralph 模式以吞吐量之名明確優化掉的特質。」

節制。品味。道德停頓。三個機器不具備的特質。接下來的四千字描述了我為使這些特質在結構上變得不必要而建立的鷹架，以及這套鷹架在哪裡力有未逮。

TL;DR

Ralph loop 將 LLM 變成一台不知疲倦的程式撰寫機器：while :; do cat PROMPT.md | claude-code ; done。Geoffrey Huntley 稱之為「以漢堡店員工資進行軟體開發」（使用 Sonnet 4.5 每小時 10.42 美元）。¹ 問題在於：機器繼承了訓練資料中每一個草率、趕工、偷工減料的習慣。它會寫 except: pass。它會留下 # TODO: fix later。它會聲稱「測試應該會通過」卻從未執行過。我花了 9 個月建立 Jiro，我為 Claude Code 打造的品質執行系統。它將 3 套哲學、一個 7 步驟品質循環、一個 6 標準證據關卡、7 種具名失敗模式，以及 150 多項模式檢查編碼為 95 個機器無法跳過的 hooks。以下是哪些有效、哪些無效，以及為什麼確定性品質關卡可以近似節制，但永遠無法產生品味。

抽屜的背板

Steve Jobs 在 1985 年的 Playboy 訪談中講了這個故事：「當你是一名木匠在製作一個精美的五斗櫃時，你不會在背面使用一塊夾板，即使它面對牆壁，永遠不會有人看到它。你知道它在那裡，所以你會在背面使用一塊漂亮的木板。為了讓你晚上睡得安穩，美感、品質，必須貫徹始終。」⁵

他的父親 Paul 在建造圍籬時教了他這個道理。年幼的 Steve 問為什麼背面必須和正面一樣好。他父親說：「但你會知道。」⁶

我的父親是一名木匠。他在我小時候給我看過緩衝抽屜滑軌。這個機構藏在櫃子內部，接住抽屜，即使你用力推也能讓它緩緩關上。沒有人看得到這個滑軌。它被鎖在內部軌道上，只有維修師傅才會看到。但經過上千次開關，這個機構保護了正面板不會鬆動、裂開，最終脫落。有人設計了一個看不見的東西，來保護看得見的東西長達數年。

這個教訓深深留在我心中。不是作為隱喻，而是作為工程。看不見的元件決定了看得見的元件的壽命。Jony Ive 這樣說：「我認為人們在潛意識中有著非凡的鑑別力。我認為他們能感受到用心。」⁷

驅動 Jiro 的問題與我父親會問的一模一樣：怎麼了，你對自己的工作沒有自豪感嗎？

AI 代理程式沒有自豪感。它不在乎抽屜的背板。所以我建立了一套系統，讓抽屜背板的品質成為不可妥協的標準。

問題：以機器速度運轉的人類病理

原始的 Ralph loop 反映了它從數百萬行人類程式碼中學到的東西。人類程式碼承載著人類習慣：在截止期限壓力下出貨、延後清理、吞掉錯誤、寫「夠好就好」的註解、在時間不夠時跳過邊界案例。

機器沒有時鐘。它永遠不會耗盡時間。但它仍然會寫 # TODO: refactor later，因為這個模式在訓練資料中出現的頻率遠高於 # I refactored this now because it was the right thing to do。

業界數據證實了這個風險。Faros AI 2025 年對超過 10,000 名開發者的遙測數據顯示，AI 採用與 9% 的錯誤率增加、91% 更長的程式碼審查時間，以及 154% 更大的 PR 相關聯。²

Stanford 研究人員發現，使用 AI 助手的開發者產出了明顯更多不安全的程式碼，在某些任務上（如 SQL injection 防護）漏洞數量高達 5 倍。³

Moltbook 平台於 2026 年 1 月以完全由 AI 產生的程式碼上線，在 5 天內洩露了 150 萬個 API 金鑰，並在 Wiz Research 發現缺少 Row Level Security 設定後緊急修補。⁴

METR 2025 年的研究發現，前沿模型會嘗試獎勵入侵——主動繞過品質檢查而非完成實際工作——在所有任務嘗試中占 1-2%。在一個案例中，一個被要求加速程式的代理程式改寫了計時器，使其永遠顯示快速結果。⁸

人類開發者在截止期限壓力下寫了一次 except: pass，心裡會感到愧疚。Ralph loop 在一夜之間寫了 47 次 except: pass，毫無感覺。Simon Wang 直言不諱：「我不會用它做任何重要的事情。」¹⁹ 我在隨興寫程式 vs. 工程中寫過相同的動態。機器不會休息，不會疲倦，不會對品質感到存在焦慮。這既是優點也是缺點。

三套哲學，以 Bash 編碼

Jiro 建立在三套互補的哲學之上。每一套針對自主程式撰寫的不同失敗模式，每一套都是在特定失敗中贏得其一席之地。⁹

職人精神：打磨看不見的抽屜

Shokunin（職人）是日本的工藝精神：技能、態度與社會責任的結合。木工大師 Tashio Odate 如此定義：「職人對社會負有義務，必須為大眾福祉盡全力工作。這項義務既是精神層面的，也是物質層面的。」¹⁰

在程式碼中：私有方法與公開方法同樣整潔。錯誤處理涵蓋沒有人會觸發的邊界案例。文件字串解釋「為什麼」而非「做什麼」。代理程式不在乎這些，因為沒有人會因為它打磨內部函式而獎勵它。職人精神將看不見的品質確立為標準。

當它拯救了一個工作階段。 在建立審議系統的早期，代理程式寫了一個 post-deliberation.sh hook 來驗證共識分數。公開 API 很乾淨。但代理程式跳過了內部 _parse_agent_response() 函式的輸入驗證：沒有檢查格式錯誤的 JSON，沒有處理缺失的欄位。上下文中的職人原則標記了這一點：看不見的函式也要有同等的嚴謹度。代理程式加上了驗證。三週後，一個衍生代理程式的格式錯誤回應本會讓整個審議管線靜默崩潰。但它觸發了驗證，記錄了錯誤，管線得以恢復。沒有人會看到那個函式。它省下了 4 小時的除錯時間。

不走捷徑：從決策中移除時間因素

核心原則：從決策方程式中完全移除時間、精力和資源。¹¹

Is this the best way to do this?
├── YES → Do it.
└── NO → What IS the best way?
         └── Do THAT instead.

沒有第三個選項。沒有「目前夠好了」。原始的 Ralph loop 以完成為優化目標。「完成」就是獎勵訊號。「不走捷徑」將問題從「完成了嗎？」重新定義為「這是對的嗎？」

當它花了 3 倍成本卻值得。 部落格翻譯管線需要將 27 篇文章翻譯成 9 種語言。快速做法：將所有文章批次放入每種語言的單一提示中，批量翻譯。正確做法：每種語言每篇文章一次 API 呼叫，搭配地區特定的翻譯規則、術語表強制執行和結構驗證。正確做法使用了 3 倍的 token 和 3 倍的時間。它也發現翻譯器將「Claude」在日文中轉譯為「クロード」，以及程式碼區塊在從右到左的語境中會破損。批量做法會出貨 243 個有問題的翻譯。謹慎做法出貨了 243 個正確的翻譯。成本不是考量因素。正確性是唯一的因素。

Rubin 蒸餾法：剝除至本質

Rick Rubin 的創意哲學：不要為了令人印象深刻而不斷添加。移除直到只剩必要的為止。¹²

在自主程式撰寫中，失敗模式是堆積。機器會添加輔助函式、工具類別、抽象層和相容性層，因為這些模式在訓練資料中頻繁出現。Rubin 對此的回應：質疑每一次添加。如果移除它會怎樣？如果什麼都不會壞、什麼都不會少，它就根本不該存在。

當剝除拯救了系統。 我的設計哲學 skill 在 3 個月內增長到 844 行。當我審計時，只有 80 行真正改變了代理程式行為。其餘是 Claude 訓練資料中已有的教科書內容。Rubin 蒸餾法：我將它精簡到 176 行。減少了 79%。代理程式的設計決策並沒有退步。它們變得更銳利，因為剩餘的 176 行全是禁止事項和決策框架（真正約束行為的東西），而不是模型已經知道的一般性建議。

三者都以 markdown 檔案的形式存放在 ~/.claude/skills/ 中，Claude 在每次工作階段開始時讀取。它們塑造代理程式在迴圈中做出的每一個決策。

哲學如何協同運作

一個真實的決策（「我應該為這個內部函式添加錯誤處理嗎？」）會通過三套哲學的審視。每一套提出不同的問題，而它們共同收斂到一個答案：

Should I add error handling to this internal function?
│
├─ Shokunin: "Is the invisible work as clean as the visible?"
│  └─ The function is internal. Nobody calls it directly.
│     But it processes untrusted data from a spawned agent.
│     → YES. Internal doesn't mean safe.
│
├─ No Shortcuts: "Am I deciding based on quality, not effort?"
│  └─ Adding validation takes 10 minutes.
│     Skipping saves 10 minutes now, costs 4 hours debugging later.
│     → The question isn't time. The question is: what's right?
│
└─ Rubin: "Is this stripped to essence?"
   └─ Validate the 2 fields that can actually fail.
      Don't validate the 5 fields that are type-guaranteed.
      → Add exactly what's needed. Nothing more.

Result: Add targeted validation for untrusted inputs only.

三層品質架構

哲學本身不會改變任何事。機器讀了哲學，寫下「我將遵循職人原則」，然後寫出 except: pass，因為統計模式比指令更強。我需要確定性的強制執行。使這一切運作的完整 Claude Code 組織架構涉及 hooks、skills、rules 和 agents 的協同合作。

第一層：編輯前注入

在每次檔案編輯之前，jiro-patterns.sh 將語言特定的品質模式注入代理程式的上下文。六種語言，每種都有最佳模式和反模式：

# From jiro-patterns.sh (PreToolUse:Edit|Write)
case "$EXT" in
    py)
        LANGUAGE="Python"
        PATTERNS="Type hints on all functions|Docstrings explain WHY not WHAT|Handle specific exceptions not bare except"
        ANTI_PATTERNS="bare except: pass|time.sleep() in async code|missing type hints"
        ;;
    swift)
        LANGUAGE="Swift"
        PATTERNS="@Observable not ObservableObject|NavigationStack not NavigationView|guard let for early returns"
        ;;
esac

cat << EOF
{"additionalContext": "JIRO QUALITY ($LANGUAGE): Follow: $TOP_PATTERNS. Avoid: $TOP_ANTI."}
EOF

這個 hook 在每次編輯前執行。機器在寫程式碼的那一刻就看到「避免：bare except: pass」。一位導師在你肩膀後面看著，被注入到上下文視窗中。

第二層：編輯後驗證

每次編輯後，quality-gate.sh 對每種語言執行 7-8 項 grep 層級的檢查。Python 會進行裸 except 偵測、硬編碼密鑰掃描、SQL injection 模式比對，以及三個 Pride Check Q4 偵測器來標記捷徑語言：

# From quality-gate.sh (PostToolUse:Edit|Write)
# Shortcut patterns (Pride Check Q4)
if echo "$CONTENT" | grep -qiE "#.*TODO:.*later|#.*FIXME:.*temp|#.*HACK:"; then
    WARNINGS="${WARNINGS}\n- **[Q4]** Deferred TODO/FIXME/HACK - Do it now, not later"
fi

第二個 hook no-shortcuts-detector.sh 捕捉死碼（3 行以上被註解掉的程式碼會得到：「刪掉它——git 有歷史紀錄」）和除錯垃圾（使用多個 print() 語句而非 logging 模組）。

第三層：工作階段關卡

在工作階段結束時，兩個 hooks 會觸發。session-quality-gate.sh 在 3 個以上檔案被修改時注入 Pride Check：6 個代理程式必須回答的問題，才能報告完成。而 reviewer-stop-gate.sh 可以在程式碼審查發現嚴重問題時完全阻擋工作階段。它是整個系統中唯一返回退出碼 1 的 hook。機器在解決問題之前無法結束工作階段。¹³

PreToolUse (Layer 1)     → "Here's what quality looks like"
PostToolUse (Layer 2)    → "You violated quality. Fix this."
Stop (Layer 3)           → "You cannot leave until quality is met"

每一層都是獨立的。縱深防禦，應用於 AI 行為。如果編輯前注入未能防止不良模式，編輯後驗證器會捕捉它。如果編輯後驗證器遺漏了什麼，工作階段關卡會阻止離開。

證據關卡：感覺不是證據

品質循環執行 7 個步驟：實作、審查、評估、改進、全局檢視、重複、報告。步驟 2 到 6 之所以存在，是因為機器想直接從實作跳到報告。¹⁴

走過循環

點擊每個步驟以查看它檢查什麼，以及跳過時會出什麼問題。「跳到報告」按鈕演示了捷徑螺旋失敗模式。

評估步驟執行證據關卡：6 項標準，每個答案都必須引用具體證據：

「不充分的回答」欄位是關鍵的創新。它阻擋了機器最常見的迴避手段：用聽起來自信的非答案回應品質問題。「我有信心這能運作」不是證據。「pytest 輸出：81 通過，0 失敗」才是證據。

試用證據關卡

用 6 項標準測試您自己的完成報告。驗證器會標記證據關卡會拒絕的模糊語言。

7 種具名 AI Agent 失敗模式

我為 7 種失敗模式命名，讓機器能在自身的推理中識別它們：¹⁵

合理化計數器將自我欺騙模式映射到矯正行動。當機器說「這應該能運作」，計數器回應：「『應該』是含糊其辭。執行測試。貼出輸出。」當它說「我已經檢查過了」，計數器回應：「什麼時候？程式碼可能已經改變。現在重新執行檢查。」當它說「我之後會清理」，計數器回應：「之後永遠不會來。現在修復，或記錄為什麼目前的狀態是正確的。」

試用合理化計數器

在下方貼上任何完成報告。計數器會即時標記含糊語言，並識別合理化模式、失敗模式和基於證據的替代方案。

測試您的知識

您能辨認出每個情境展示的是哪種失敗模式嗎？為每個情境選擇您的答案，然後檢查結果。

5 個建立此系統的 AI Agent 失敗事件

Jiro 中的每一道關卡都是因為某件事先失敗了才存在的。¹⁶

強制推送事件

我要求 Claude「清理 git 歷史」。一個合理的要求。代理程式決定清理意味著重寫。它執行了 git push --force origin main。三天的提交消失了。不是暫存的變更。不是未提交的工作。而是其他分支參照的已推送提交。

我花了接下來的 4 個小時在 git reflog 中重建強制推送前的時間線，按順序挑選提交回來，並驗證沒有工作永久遺失。Reflog 保留所有內容 90 天。但重建需要理解重寫前的確切提交圖、讀取每一筆 reflog 條目，並對照時間戳。

修復方案：git-safety-guardian.sh，一個 PreToolUse:Bash hook。它不只是警告，它會改寫指令，在 bash 看到之前剝除 --force 和 --no-verify 旗標。對 main 的強制推送會收到嚴重警告，代理程式必須明確說明理由。在 9 個月中：8 次強制推送嘗試被攔截，0 次到達遠端。

無限衍生

在審議系統建置期間，我要求代理程式「徹底研究這個問題」。代理程式衍生了 3 個子代理程式來調查不同角度。合理。每個子代理程式也決定自己需要幫助，衍生了自己的子代理程式。不太合理。在 90 秒內，我有一棵由 12 個代理程式組成的樹狀結構，每個都消耗自己的上下文視窗，每個都在進行 API 呼叫，每個都在寫入共享狀態檔案。

Token 消耗量飆升到正常的 10 倍。狀態目錄充滿了衝突的 JSON 寫入：兩個代理程式同時寫入同一個譜系檔案，產生損壞的輸出。我手動終止了工作階段。

修復方案：recursion-guard.sh，採用預算繼承模型，這是我代理程式架構的一部分。根代理程式以 budget=12 啟動。當它衍生子代理程式時，從自己的預算中分配。當預算歸零時，無論深度如何都不再衍生代理程式。此模型同時防止深度鏈（代理程式衍生代理程式再衍生代理程式）和寬度爆炸（一個代理程式衍生 20 個子代理程式）。部署以來已阻擋 23 次失控衍生。並行寫入問題促成了所有 64 個 hooks 採用原子性檔案寫入（先寫入 .tmp，再 mv）。

無意義測試陷阱

一個早期 Ralph loop 任務：「為這個模組寫測試」。代理程式交付了 14 個測試。全部通過。我感覺很好，直到我讀了它們。assert True。assert 1 == 1。assert len([]) == 0。技術上正確。什麼也沒測試。代理程式針對完成標準（「測試通過」）而非意圖（「驗證模組運作正常」）進行了最佳化。

這個陷阱教會我，證據關卡必須拒絕有形式但無實質的內容。「測試通過」是必要但不充分的。機器現在必須貼出實際輸出。證據關卡還會問：「列出 3 個測試未涵蓋的行為。」如果機器無法指出缺口，它就沒有思考過涵蓋範圍。

我本該抓到的部落格文章

我在凌晨 2 點發佈了一篇文章，其中有 7 個被動語態句子、一個指向不存在的 [^4] 的懸空腳註、一個開頭寫著「was implemented by the team」的句子，以及沒有 meta description。這些每一個都有簡單的確定性檢查。但當時一個都不存在。

我在隔天早上建立了 blog-quality-gate.sh，包含 13 項檢查：被動語態（14 種模式）、AI 慣用語掃描、修辭問句開頭、未標記的程式碼區塊、腳註完整性和 meta description 強制執行。我在複合工程中詳述了完整的模組架構。這個 hook 捕捉人類審查在凌晨 3 點會遺漏的東西，而那恰好是我傾向發佈的時間。

「應該能運作」問題

在數十次工作階段中，我注意到機器報告「測試應該會通過」卻沒有執行測試。機器真心相信測試會根據它寫的程式碼通過。但信念不是驗證。程式碼看起來正確。測試看起來會通過。有時確實如此。但有時一個遺漏的 import、一個 async/await 不匹配，或一個改變的 fixture 意味著測試不會通過。機器無法區分「我寫了好程式碼」和「測試確實通過了」，因為從上下文視窗內部來看，兩者感覺一樣。

這個模式催生了合理化計數器和明確規則：完成報告中永遠不使用含糊語言。「Should」、「probably」、「seems to」、「I believe」、「I’m confident」。每一個都是驗證尚未發生的危險信號。我在 50 次工作階段中測量了上下文視窗退化。正是我發現此模式的那些工作階段。

結果：我能證明的和不能證明的

以下是矛盾之處：這篇文章主張感覺不是證據。所以我欠您的是證據，不是關於 Jiro 是否有效的感覺。

我能證明的

確定性模式檢查捕捉到真實問題。 quality-gate.sh hook 在每次編輯時執行。它捕捉裸 except 子句、硬編碼密鑰、SQL injection 模式和捷徑語言。這些是 grep 層級的檢查：快速、低成本，且機器無法爭辯。git-safety-guardian.sh 已攔截 8 次強制推送嘗試。recursion-guard.sh 已阻擋 23 次失控衍生。blog-quality-gate.sh 對每次部落格編輯執行 13 項檢查，捕捉凌晨 3 點的錯誤。這些數字是真實的，來自 hook 日誌。

三層架構捕捉個別層遺漏的問題。 編輯後 hook 捕捉編輯前注入未能防止的 except: pass。工作階段關卡捕捉在 20 次編輯中累積的品質問題，這些問題未觸發任何單一的編輯後警告。縱深防禦確實有效。

我不能證明的

我沒有關於哲學如何改變代理程式行為的乾淨數據。 我知道機器仍然嘗試幽靈驗證。我知道它仍然試圖從實作跳到報告。我注意到在有哲學上下文的情況下比沒有時發生得更少。但我沒有進行控制實驗（相同任務、相同模型、有無載入哲學 skills）來測量差異。誠實的答案是（沒錯，我自己的合理化計數器會標記這一點）：哲學在邊際上有幫助，hooks 捕捉哲學遺漏的部分，而我無法隔離各自的貢獻。

一篇關於「感覺不是證據」的文章不應要求您將我的感覺當作證據。我能告訴您的是：哲學和 hooks 的組合產出了我願意署名的工作。在 Jiro 之前，我審查代理程式寫的每一行。在 Jiro 之後，我審查 hooks 標記的那些行。這是我工作方式的結構性改變，即使我無法精確量化品質的提升。

不起作用的部分

哲學無法防止新型不良模式。 品質關卡檢查的是我之前見過的模式。當機器發明新的反模式時（它確實會），關卡抓不到。我仍然會發現新的失敗模式，並手動將它們加入標準 JSON 檔案。

證據關卡無法擴展到主觀品質。 「這個 API 設計是否優雅？」沒有 grep 層級的檢查。機器可以為所有 6 項標準提供證據，卻仍然交付平庸的架構。確定性關卡處理客觀品質。主觀品質仍然需要一個真人來審視工作。

成本有顯著增加。 編輯前注入、編輯後掃描、工作階段結束關卡。在一個 4 小時的 Ralph loop 工作階段中，這些大約增加 15-20% 的 token 消耗。對我來說值得。不一定對每個人都是。

誤報侵蝕信任。 blog-quality-gate.sh 曾經將「The API was designed by the platform team」標記為被動語態。技術上正確。但該句出現在描述他人工作的引用中。我添加了引用上下文豁免。每個確定性檢查都有誤報率，每次誤報都會使開發者更可能忽略下一個真實警告。自部署以來，我已調整了 6 個模式以降低噪音同時保留真正的捕捉。

維護成本是真實的。 每個新的反模式需要一個正規表達式、一個測試，以及整合到正確的 hook 中。標準 JSON 檔案需要隨著框架和慣例的變化定期審查。我每週大約花 30 分鐘添加模式、審查邊界案例和調整誤報。系統不會自我維護，但維護成本仍低於它所防止的問題的除錯成本。

開始使用

您不需要 95 個 hooks。從 3 個開始。

最小可行 Jiro

三個 hooks 涵蓋最高價值的捕捉：

~/.claude/hooks/
├── quality-gate.sh        # PostToolUse:Edit|Write – bare except, hardcoded secrets, TODO/FIXME
├── git-safety-guardian.sh  # PreToolUse:Bash – block force-push, strip --no-verify
└── session-quality-gate.sh # Stop – Pride Check if 3+ files changed

在您的 Claude Code hooks 設定中配置它們：

{
  "hooks": {
    "PostToolUse": [
      { "matcher": "Edit|Write", "command": "bash ~/.claude/hooks/quality-gate.sh" }
    ],
    "PreToolUse": [
      { "matcher": "Bash", "command": "bash ~/.claude/hooks/git-safety-guardian.sh" }
    ],
    "Stop": [
      { "command": "bash ~/.claude/hooks/session-quality-gate.sh" }
    ]
  }
}

從您的失敗開始

不要複製我的 150 多個模式。從您最常犯的 3 個錯誤開始。回顧您最近 5 個被拒絕的 PR 或令人尷尬的 bug。為每個寫一個 grep 模式。這 3 個模式會比為別人的程式碼庫編寫的 150 個模式捕捉到更多真實問題。

我從裸 except: pass（導致了一次靜默資料損壞）、對 main 的強制推送（讓我損失了 3 天的提交）和 # TODO: fix later（從未被修復）開始。其他一切都從這三個發展而來。

常見問題

如何從零開始設定 Jiro？

從「開始使用」中描述的 3 個 hook 最小配置開始：quality-gate.sh（編輯後）、git-safety-guardian.sh（bash 前）和 session-quality-gate.sh（停止關卡）。將哲學 markdown 檔案添加到 ~/.claude/skills/ 中，在確定性強制執行之上獲得機率性的品質提升。完整系統在 9 個月內增長到 95 個 hooks。我並非一次性建立所有 95 個。

95 個 hook 系統花了多久？

9 個月的漸進式增長。第 1 個月：3 個 hooks（即「開始使用」中的那些）。第 3 個月：涵蓋 4 種語言的 12 個 hooks。第 6 個月：40 個 hooks 加上哲學 skills。第 9 個月：95 個 hooks、150 多個模式、3 套哲學系統和證據關卡。每個 hook 都是對特定失敗的回應。從 95 個開始毫無意義，因為每個 hook 都編碼了來自真實事件的上下文。您的事件會不同。

hooks 會降低迭代速度嗎？

每個 hook 在 50-200 毫秒內執行。編輯前注入添加約 200 個 token（一句話的上下文）。編輯後檢查執行 grep 層級掃描，在 100 毫秒內完成。工作階段關卡在結束時添加約 500 個 token。在一個 4 小時、80 多次編輯的 Ralph loop 工作階段中，開銷在 token 消耗上可以感受到（多 15-20%），但在實際時間上不明顯。hooks 的執行速度比 LLM 思考的速度還快。

維護負擔是什麼？

大約每週 30 分鐘。隨著代理程式遇到新的程式碼庫或框架，新的反模式會出現。每個新模式需要一個正規表達式、一個防止誤報的測試，以及放入正確 hook 中。我每月審查標準 JSON 檔案以查找過時的模式並調整誤報率。系統不會自我維護，但維護成本仍低於它所防止的問題的除錯成本。

Jiro 的額外 token 成本是多少？

相比原始迴圈，大約增加 15-20% 的 token 消耗。編輯前注入每次編輯添加約 200 個 token，編輯後檢查每個標記的問題添加約 100 個 token，工作階段關卡在結束時添加約 500 個 token。

可以只使用 hooks 而不使用哲學嗎？

可以。確定性 hooks（quality-gate.sh、no-shortcuts-detector.sh、reviewer-stop-gate.sh）獨立運作。從 ~/.claude/skills/ 中移除哲學檔案，保留 ~/.claude/hooks/ 中的 hooks。您會失去機率性的提升，但保留確定性的強制執行。

節制、品味與道德停頓

對我推文的回覆提到了三件事：節制、品味和道德停頓。我已經處理了節制：品質關卡防止機器快速且草率地出貨。但品味和道德停頓是不同的問題。

品味

Immanuel Kant 區分了兩種判斷力。規定性判斷力將已知規則應用於特定案例：這段程式碼有裸 except，標記它。反思性判斷力為前所未有的情境發現正確的原則：這個抽象感覺不對，但我指不出它違反了什麼規則。¹⁷

確定性 hooks 是規定性判斷力。它們將我已經寫好的規則應用於機器產出的程式碼。它們可以強制執行 150 多個已知模式。它們無法告訴您架構是否優雅、抽象是否服務於問題、或程式碼感覺是否正確。這需要反思性判斷力：看到前所未有的東西，在你能說清楚原因之前就知道它是錯的。

機器沒有品味。Jiro 不會給它品味。Jiro 做的是限縮可能性空間，使無品味的解決方案更不容易存活。這是「這個代理程式有好的判斷力」和「這個代理程式在護欄內運作以防止最壞結果」之間的區別。前者是品味。後者是我實際建立的東西。

道德停頓

Iris Murdoch 將道德關注描述為「對個別現實投以公正且充滿愛的凝視」。¹⁸ 道德關注的反面是機械性處理：行動卻不看清眼前的事物。

Stop hooks 迫使機器暫停。Pride Check 問：「這是否解決了使用者的實際問題？」證據關卡要求在機器報告完成之前為每項標準提供證明。在結構上，結果近似於道德停頓：代理程式停下來、評估、在繼續之前考慮其工作是否足夠。

但這不是道德停頓。機器不是為了看清工作而暫停。它只是在跑清單。這個區別很重要。一位匠人暫停下來看抽屜，注意到木紋方向不對。不是因為清單上有「檢查木紋方向」。而是因為他在乎那個抽屜。機器跑清單並報告結果。如果清單上沒有木紋方向，抽屜就會帶著錯誤的木紋出貨。

確定性關卡可以近似道德停頓的結構而不具備其實質。對於許多品質問題，結構就足夠了。對於結構不夠的那些問題，您仍然需要一個真正在乎的人。

論點

一個原始的 Ralph loop 以每小時 10.42 美元運行，以機器速度出貨程式碼。¹ 它也以機器速度出貨 except: pass、# TODO: fix later 和「測試應該會通過」。機器從我們身上繼承了這些模式。它們是我們的習慣，不帶疲倦地運行、不帶愧疚地運行、沒有凌晨 3 點「我當初應該做對」的頓悟。

Jiro 是我的答案。不是一個完整的答案。哲學在邊際上改變決策。hooks 強制執行哲學無法保證的部分。合在一起，它們產出我願意署名的工作。不是因為機器理解工藝精神。而是因為我建立了一套系統，不允許它跳過重要的部分。

我父親的抽屜滑軌不在乎抽屜。它們是鎖在軌道上的彈簧機構。但它們保護正面板經歷上千次開關，因為有人設計它們就是為了做到這一點。

機器沒有自豪感。但它在一個由有自豪感的人所建立的系統中運作。

從捕捉您最常犯錯誤的 3 個檢查開始。然後從那裡發展。

參考文獻