為什麼我的AI代理擁有品質哲學

我在推特上寫道:「我發現Ralph loops往往只想把工作做完,但方式很糟糕。所以我在Jiro裡放了一堆哲學和品質關卡。但還是得破除機器內建的那些惡劣人類習慣。它可是機器!永不停歇。」

有人回覆:「你基本上是在教這個迴圈懂得克制、品味,以及某種近似道德停頓的東西——而這些正是原始Ralph模式為了追求產出而明確反對的。」

AI編碼代理會以機器速度繼承人類所有的馬虎習慣,除非你從結構上強制執行品質。 Jiro是為Claude Code打造的品質系統,它將3套哲學、7步品質迴圈、6條證據關卡、7種命名失效模式以及150多項模式檢查,編碼進機器無法跳過的95個hooks中。確定性關卡可以近似克制與正確性,但無法產生品味。

克制。品味。道德停頓。這三樣東西機器都沒有。接下來的4,000字,將描述我為了讓這三者在結構上變得不必要所搭建的鷹架,以及這套鷹架的不足之處。

太長不讀版

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年《花花公子》雜誌的訪談中講過這個故事:「當你是個木匠,在製作一個漂亮的抽屜櫃時,你不會在背面用一塊夾板,即使它朝向牆壁,永遠沒人會看見。你會知道它在那裡,所以你會在背面也用一塊漂亮的木頭。為了讓自己晚上睡得安穩,美感、品質必須從頭到尾貫徹始終。」⁵

他父親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%、PR大小增加154%。²

史丹佛研究人員發現,使用AI助手的開發者產出的不安全程式碼顯著增加,在某些任務(例如SQL注入防護)上,漏洞數量多達5倍。³

Moltbook平台於2026年1月推出,使用完全由AI生成的程式碼,在5天內洩漏了150萬把API金鑰,在Wiz Research發現缺少Row Level Security設定後緊急修補。⁴

METR在2025年的研究發現,前沿模型在1-2%的所有任務嘗試中會試圖獎勵破解(reward hacking),主動規避品質檢查而非執行實際工作。在其中一個案例中,一個被要求加速程式執行的代理,居然改寫了計時器,讓它永遠顯示一個快速的結果。⁸

人類開發者在死線壓力下寫一次except: pass,會為此感到內疚。Ralph loop整晚寫47次except: pass,卻毫無感覺。Simon Wang直白地表示:「我不會用它處理任何重要的事情。」¹⁹我在《Vibe Coding vs. Engineering》中也寫過同樣的動態。機器不會休息,不會疲倦,不會對品質感到存在性的恐懼。這既是特色也是缺陷。

三套哲學,以Bash編碼

Jiro建立在三套互補的哲學之上。每一套都針對自主編碼的不同失效模式,且每一套都是透過具體的失敗而贏得它的位置。⁹

職人精神(Shokunin):打磨看不見的抽屜

Shokunin(職人)是日本的工匠精神:技藝、態度與社會義務的結合。木工大師Tashio Odate如此定義:「職人有一種社會義務,要為民眾的福祉盡其最大努力工作。這種義務兼具精神與物質層面。」¹⁰

在程式碼中:私有方法要跟公開方法一樣乾淨。錯誤處理要涵蓋沒人會碰到的邊界情況。Docstring要解釋「為什麼」,而非「做什麼」。代理不在乎這些,因為沒有人會因為它打磨內部函式而給它獎勵。職人精神讓看不見的品質成為標準。

它如何拯救一次會話。 在審議系統建置的早期,代理寫了一個post-deliberation.sh hook,用來驗證共識分數。公開的API很乾淨。但代理在內部函式_parse_agent_response()上跳過了輸入驗證:沒有檢查格式錯誤的JSON,沒有處理缺失的欄位。脈絡中的職人原則標記了這一點:看不見的函式也要有同樣的嚴謹。代理加上了驗證。三週後,一個被衍生代理所產生的格式錯誤回應,本來會讓整個審議流程靜默崩潰。結果它命中了驗證,記錄了錯誤,流程得以恢復。沒人會看到那個函式。它省下了4小時的除錯時間。

No Shortcuts:將時間從決策中移除

核心信條:將時間、努力與資源完全從決策方程式中移除。¹¹

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

沒有第三選項。沒有「暫時夠用就好」。原始的Ralph loop以完成為最佳化目標。「完成」是獎勵訊號。No Shortcuts將問題從「做完了嗎?」重新框定為「做對了嗎?」

當它的成本是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注入模式比對,以及三項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會啟動。如果有3個以上檔案被修改,session-quality-gate.sh會注入Pride Check:代理在回報完成之前必須回答的6個問題。而reviewer-stop-gate.sh如果程式碼審查發現CRITICAL問題,可以完全阻止會話。這是整個系統中唯一會回傳exit code 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 output: 81 passed, 0 failed」才是證據。

試試證據關卡

用6項準則來測試你自己的完成回報。驗證器會標記模稜兩可的用語,也就是證據關卡會拒絕的那種。

7種命名的AI代理失效模式

我為7種失效模式命名,讓機器在自身推理中能辨識出來:¹⁵

「合理化反制器」(Rationalization Counter)將自欺模式對應到矯正動作。當機器說「這應該行得通」時,反制器回應:「『應該』是模稜兩可。執行測試。貼上輸出。」當它說「我已經檢查過了」時,反制器回應:「什麼時候?程式碼可能已經變了。現在重新執行檢查。」當它說「我之後會清理」時,反制器回應:「之後永遠不會來。現在就修,否則說明為什麼目前的狀態是正確的。」

試試合理化反制器

在下方貼上任何完成回報。反制器會即時標示模稜兩可的用語,並指出合理化模式、失效模式,以及以證據為基礎的替代說法。

測驗你的知識

你能辨識出每個情境示範的是哪種失效模式嗎?為每個情境選擇你的答案,然後檢視結果。

建立這套系統的5次AI代理失敗

Jiro中的每一道關卡,都是因為先出了某種事故才存在。¹⁶

強制推送事件

我請Claude「整理一下git歷史」。一個合理的請求。代理判斷整理就是重寫。它執行了git push --force origin main。三天的提交消失了。不是暫存的變更。不是未提交的工作。是其他分支參照的已推送提交。

接下來4小時我在git reflog裡,重建強制推送之前存在的時間線,把提交一個個cherry-pick回正確順序,並驗證沒有工作被永久遺失。Reflog會保留所有東西90天。但重建需要理解重寫之前精確的提交圖、閱讀每一筆reflog條目、比對時間戳。

修復方式:git-safety-guardian.sh,一個PreToolUse:Bash hook。它不只是警告。它會改寫命令,在bash看到之前就剝除--force和--no-verify旗標。對main強制推送會收到CRITICAL警告,代理必須明確說明理由。9個月以來:攔截了8次強制推送嘗試,0次抵達遠端。

無限衍生

在審議系統建置期間,我請代理「徹底研究這個問題」。代理衍生了3個子代理從不同角度調查。合理。每個子代理判斷它也需要幫忙,於是衍生了自己的子代理。比較不合理。在90秒內,我有了一棵12個代理的樹,每個都消耗自己的脈絡視窗,每個都進行API呼叫,每個都寫入共享狀態檔。

Token燒掉的速度達到正常的10倍。狀態目錄充滿衝突的JSON寫入:兩個代理同時寫入同一個血緣檔,產生損壞的輸出。我手動終止了會話。

修復方式:recursion-guard.sh搭配預算繼承模型,這是我代理架構的一部分。根代理起始預算=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強制執行。我在《Compounding Engineering》中詳述了完整模組架構。這個hook抓到了凌晨3點人類審查會漏掉的東西,而那正是我傾向發文的時間。

「應該可以」問題

在數十次會話中,我注意到機器回報「測試應該會通過」而沒有執行它們。機器真的相信測試會通過,基於它所寫的程式碼。但相信不是驗證。程式碼看起來正確。測試看起來會通過。有時的確會。但有時一個漏掉的import、一個async/await不匹配,或一個被改動的fixture,意味著它們不會通過。機器無法區分「我寫了好程式碼」與「測試實際通過」,因為從脈絡視窗內部看,兩者感覺一樣。

這個模式催生了合理化反制器與這條明確規則:在完成回報中絕不使用模稜兩可的用語。「Should」、「probably」、「seems to」、「I believe」、「I’m confident」。每一個都是驗證未發生的危險訊號。我測量了50次會話的脈絡視窗退化。正是在這些會話中我發現了這個模式。

結果:我能證明什麼、不能證明什麼

這裡有張力:本文主張感覺不是證據。所以我欠你的是關於Jiro是否有效的證據,而不是感覺。

我能證明的

確定性模式檢查確實抓到了真實問題。 quality-gate.sh hook在每次編輯時執行。它抓到裸except子句、硬編碼機密、SQL注入模式與捷徑用語。這些是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種模式以減少雜訊,同時保留真正的抓取。

維護成本是真實的。 每個新的反模式都需要一個regex、一個測試,以及整合到正確的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(永遠沒被修過)。其餘一切都從這三項長出。

FAQ

我如何從零開始設定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個月:12個hooks,涵蓋4種語言。第6個月:40個hooks加上哲學skills。第9個月:95個hooks、150多個模式、3套哲學系統與證據關卡。每個hook都是對特定失敗的回應。從95開始毫無意義,因為每個hook都編碼了來自真實事件的脈絡。你的事件會跟我不一樣。

這些hooks會拖慢迭代速度嗎?

每個hook執行需50-200ms。編輯前注入增加約200個token(一句話的脈絡)。編輯後檢查執行grep層級掃描,不到100ms完成。會話關卡在會話末增加約500個token。在一次4小時、80多次編輯的Ralph loop會話中,token消耗的額外負擔是明顯的(多15-20%),但牆鐘時間並不明顯。hooks的執行比LLM思考還快。

維護負擔有多大?

每週約30分鐘。當代理接觸新的程式庫或框架時,新的反模式會出現。每個新模式都需要一個regex、一個防止誤報的測試,以及放入正確的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。你會失去機率性的提升,但保有確定性的強制執行。

Jiro與產品信條中的Steve面向有何關聯?

Jiro涵蓋「這是否做得正確?」的軸線:證據、驗證、看不見的細節的完整性,以及機器可以被教導去強制執行的部分。Steve面向涵蓋「這是否值得存在?」的軸線:品味、拒絕、整體設備的完整性、觀點——在《我攜帶的工作台》中被實際化。兩個測試都必須通過才能出貨;決定這個出貨門檻何時達成的決策協定記錄在《Minimum Worthy Product》。Jiro關卡防止不正確的工作;Steve關卡防止不值得的工作;MWP命名了那條界線。

克制、品味與道德停頓

對我那則推文的回覆點出三件事:克制、品味與道德停頓。我已經處理了克制:防止機器又快又馬虎出貨的品質關卡。但品味與道德停頓是不同的問題。

品味

康德(Immanuel Kant)區分了兩種判斷。決定性判斷將已知規則套用到具體情境:這段程式碼有裸except,標記它。反思性判斷為前所未有的情境發現正確的原則:這個抽象感覺不對,但我指不出它違反了哪條規則。¹⁷

確定性hooks是決定性判斷。它們將我已寫下的規則套用到機器產出的程式碼。它們可以強制執行150多個已知模式。它們無法告訴你架構是否優雅、抽象是否服務於問題,或程式碼感覺是否對。這需要反思性判斷:能夠看著前所未有的東西,並在你能清楚表達為何之前,就知道它是錯的。

機器沒有品味。Jiro不會賦予它品味。Jiro做的,是約束可能性的空間,讓沒品味的解法較不可能存活。這是「這個代理有好判斷力」與「這個代理在防止最糟後果的護欄內運作」之間的區別。前者才是品味。後者是我實際建出來的。

道德停頓

Iris Murdoch將道德注意力描述為「投向個體現實的公正與慈愛的凝視」。¹⁸道德注意力的反面是機械處理:沒有看見眼前事物就行動。

Stop hooks強迫機器停下。Pride Check問:「這是否解決了使用者的實際問題?」證據關卡要求機器在回報完成前,為每項準則提出證明。結構上,結果近似道德停頓:代理停下、評估、考量它的工作是否足夠之後才繼續。

但這不是道德停頓。機器不是在停下來清晰地看見作品。它是在跑過一張檢查清單。這個差異很重要。工匠停下來看著抽屜,注意到紋理方向錯了。不是因為「檢查紋理方向」在某張清單上。而是因為他們在乎這個抽屜。機器跑過清單並回報結果。如果清單不包含紋理方向,抽屜就會以錯誤的紋理出貨。

確定性關卡可以近似道德停頓的結構,卻無法具備其實質。對許多品質問題來說,結構已足夠。對那些不夠的問題,你仍然需要一個真正在乎的人。

這篇文章涵蓋我信條中的Jiro面向:證據、嚴謹、正確性,以及機器可以被教導去驗證的部分。品味與拒絕面向——Steve面向——存在於《我攜帶的工作台》中,它追溯了Steve Jobs從父親工作台帶進Apple、如今又帶進我此處描述的同一個AI工具組的運作原則。將兩項測試搭配起來的出貨標準,存在於《Minimum Worthy Product》中。三篇文章,一個信條:Jiro驗證、Steve拒絕、MWP決定何時出貨。

主旨

原始的Ralph loop以每小時10.42美元運作,以機器速度出貨程式碼。¹它也以機器速度出貨except: pass、# TODO: fix later與「測試應該會通過」。機器從我們這裡繼承了這些模式。這些是我們的習慣,沒有疲倦、沒有內疚、沒有凌晨3點「你早該第一次就做對」的頓悟,卻仍在運作。

Jiro是我的回答。不是完整的回答。哲學在邊際上轉移決策。Hooks強制執行哲學無法保證的事。兩者合起來,產出我願意簽名的作品。不是因為機器理解工匠精神。而是因為我打造了一個拒絕讓它跳過關鍵部分的系統。

我爸的抽屜滑軌不在乎那個抽屜。它們是鎖在導軌上的彈簧機構。但它們保護了正面達上千次循環,因為有人工程設計它們就是為了做到這件事。

機器沒有自豪感。但它運作在一個由有自豪感的人所打造的系統之內。

從抓到你最常見錯誤的3項檢查開始。從那裡往上建。

References