「我已經不知道那份程式碼怎麼運作」：Claude Code 一年後的 review 紀律崩壞，與三道擋得住它的閘門

2026 年 8 月 27 日（台北時間 8/28 凌晨 1:28），Hacker News 上一則叫 「Tell HN: Man, AI is killing my brain」 的貼文衝上首頁，作者是帳號 fnoef。貼文最後一句寫得很直接：「No question. Not asking for advice. Just sharing my misery.」——他沒有要問問題，也沒有要建議。

但如果你每天在用 coding agent，這篇其實是近期最精確的一份故障報告。因為 fnoef 把「code review 紀律怎麼一級一級掉下去」的過程，照時間順序寫完了。而只要一件事有明確的觸發時序，它就擋得住。

這篇文章要做的就是這件事：拆開這條滑坡，然後給你三道今天就能設進 Claude Code 的閘門——plan gate、hook gate、commit gate——附可直接複製的 settings.json、hook script，以及兩組我認為最有效的 review prompt。

一、先看這條滑坡：一年，七個階段

以下依 HN 原文順序整理（原文英文，連結見文末）：

1. 起點是壓力：他被暗示「如果不提升產能、跟上同事，工作會有風險」，於是一年前開始用 Claude Code。
2. 健康期：「給它小任務，每一行都 review，開正式的 PR，再 review 一次，問問題，叫它修我不喜歡的地方。」
3. 第一級滑坡：同事出貨更多，「所以我開始放鬆 review」，小功能直接推 main。
4. 第二級：「同事出貨量是我的 10 倍，我需要這份工作。」Agent 跑 20–30 分鐘時，他開始無意識滑社群。
5. 第三級：看到同事用 worktree 跑多個 agent，他也開始「同時開 4–5 個 agent，在它們的 output 之間來回跳」。
6. 第四級：「我已經沒有心智容量去理解那麼多 context，所以我就直接選 Claude 標的 Recommended。」
7. 終點：「**我已經不知道那份程式碼，也不知道它怎麼運作。**有 bug 就把使用者的抱怨貼進 Claude，讓它自己搞定。好的／壞的地方是——它好像真的會動。」

注意第 2 到第 3 之間發生了什麼：沒有任何技術上的東西壞掉。壞掉的是一個純靠意志力維持的步驟。而在整條鏈上，review 是唯一一個「只有成本、沒有即時回報」的動作。

留言區的反應也值得看。dkowalski 給的解法是心態框架：「把它當成交給實習生做前置工作。只要我真的有看過，我就還在圈內（still on the loop）。」polotics 講得更狠：「如果你真的能同時管十五個 worktree 都在churn、而且都在已經抽象良好的程式碼上產出真實價值，那其實是在凡爾賽，去寫篇 blog 吧。」spottedmarley 則描述了另一種結局：「我現在寫的 code 比以前任何時候都多，但我比以前任何時候都更不像一個 coder。」

這些都是心態建議。心態建議在你連續工作十小時之後會失效——這正是 fnoef 說的「after 10 hours and 15 parallel agents, I no longer have the brain capacity」。所以我們需要的是流程與設定，不是自律。

二、機制：為什麼崩的是紀律，不是能力

把上面的滑坡抽象一下，會看到四個互相加乘的機制：

1）回饋訊號被換掉了。 手寫時代，你的回饋是「我理解了、它動了」，兩者綁在一起。Agent 時代，「它動了」可以在你完全不理解的情況下達成，而且更快。於是理解這件事失去了它唯一的外部酬賞。

2）Context 成本是 N 倍，不是 N 分之一。 開 4 個 agent，人類要維持 4 份心智模型，而且每份都在你不看的時候持續變動。並行 agent 真正的瓶頸從來不是 token，是人的 working memory。這也是為什麼 fnoef 的第四級崩壞不是「不想 review」，而是「沒有心智容量」。

3）預設值就是決策。 「Recommended」是一個 UI 預設。在疲勞狀態下，任何預設值都會變成最終決策——這不是人格缺陷，是 UI 設計的必然結果。

4）沒有硬邊界。 從 agent 寫完到 git push，中間沒有任何東西強迫他停下來。人類的注意力只會被硬邊界擋住，不會被善意提醒擋住。

Simon Willison 在 2025 年就把這條線劃得很清楚。他對 vibe coding 的定義是「用 LLM 寫軟體、而不 review 它寫的程式碼」，並且強調：「如果 LLM 寫了你每一行 code，但你 review 過、測過、也都理解了，那不是 vibe coding，那是把 LLM 當打字助理。」2025 年 10 月 7 日他又提出 vibe engineering，列出真正讓 agent 可用的條件：完整的自動化測試、事前規劃、良好的版控習慣、CI/lint/preview 環境的自動化，以及——他特別點名——code review 的文化：「如果你 review code 又快又好，你跟 LLM 合作的體驗會好很多。」

換句話說，agent 沒有讓 review 變得不重要，它讓 review 變成唯一剩下的把關點。而 fnoef 恰好是把這個唯一的把關點拆掉了。

三、三道閘門：把 review 從意志力變成流程

解法的核心思路只有一句：在 agent 的生命週期上，找三個「機器可以硬擋」的時間點，把人塞回去。

• Plan Gate（產出前）：在 agent 動手改檔案之前，先強制產出一份你看得懂的計畫。
• Hook Gate（產出中）：用 hook 記錄它改了什麼，並在危險動作前硬性中斷。
• Commit Gate（產出後）：在 commit / push 之前，強制一次「你能不能解釋這份 diff」的檢查。

以下都是照 Claude Code 官方文件的規格寫的設定，建議先在測試 repo 跑一次再進主專案。

招式 1：把 plan 設成 session 預設模式

Claude Code 的 permission mode 目前有 default（CLI 上顯示為 Manual）、acceptEdits、plan、auto、dontAsk、bypassPermissions。plan 模式下 Claude 只讀檔案、跑唯讀指令來探索，不會改你的原始碼。

把它設成預設，等於強迫每個 session 都從「先講清楚你要幹嘛」開始：

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "plan",
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable"
  }
}

後兩行是關鍵：disableBypassPermissionsMode 和 disableAutoMode 設成 "disable" 之後，這台機器上就叫不出 bypassPermissions 和 auto 模式。這是專門用來擋「累到直接按 Recommended」那一級的——你把那個逃生門焊死了。

如果覺得太嚴，退一步的版本是留著 auto 但關掉 bypass。但請誠實面對一件事：fnoef 崩壞的那一級，就是逃生門太好按。

招式 2：用 permission rules 把「危險動作」變成必須看

permissions 支援 allow / ask / deny 三種規則，語法是 Tool 或 Tool(specifier)：

{
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(git reset --hard *)"
    ]
  }
}

這裡有個很多人踩過的坑，官方文件也特別警告：* 要放在 subcommand 後面。Bash(git log *) 只允許 git log；但 Bash(git *) 會放行每一個 git 子指令，包含 git push、甚至 git -c core.fsmonitor=<script> diff（可以藉此執行任意程式）。寫成 Bash(git * main) 這種 * 在 subcommand 前面的 allow 規則，Claude Code 啟動時會直接對你發警告。

另外要記得：permission rules 是 Claude Code 執行的，不是模型執行的。你寫在 CLAUDE.md 裡的「請不要 push」只是影響模型想做什麼，不會改變 Claude Code 允許什麼。要真的擋住，只有規則、permission mode 或 PreToolUse hook 三條路。

招式 3：用 hook 做「未讀 diff 不准 commit」

這是三道閘門裡最硬的一道。Claude Code 的 hook 事件很多（PreToolUse、PostToolUse、Stop、SubagentStop、PreCompact、SessionEnd 等等），我們只需要兩個。

Hook A — 記帳： PostToolUse 在 Edit/Write 成功後把改過的檔案記進一個帳本。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/ledger.sh"
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(git commit *)",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/require-review.sh"
          }
        ]
      }
    ]
  }
}

ledger.sh（hook 的輸入是 stdin 上的 JSON）：

#!/bin/bash
# .claude/hooks/ledger.sh
FILE=$(jq -r '.tool_input.file_path // empty')
[ -n "$FILE" ] && echo "$FILE" >> "$CLAUDE_PROJECT_DIR/.claude/unreviewed.txt"
exit 0

require-review.sh：

#!/bin/bash
# .claude/hooks/require-review.sh
LEDGER="$CLAUDE_PROJECT_DIR/.claude/unreviewed.txt"
if [ -s "$LEDGER" ]; then
  N=$(sort -u "$LEDGER" | wc -l)
  echo "擋下 commit：有 $N 個檔案還沒被人工確認。" >&2
  echo "請人類先跑 git diff 看過，再執行 .claude/hooks/ack.sh 清帳。" >&2
  sort -u "$LEDGER" >&2
  exit 2
fi
exit 0

exit 2 在 PreToolUse 是阻擋性錯誤：這個 tool call 會被直接擋掉，stderr 的內容會回饋給 Claude。等價的寫法是輸出 JSON：

jq -n '{hookSpecificOutput:{hookEventName:"PreToolUse",
  permissionDecision:"deny",
  permissionDecisionReason:"未經人工 review 的變更不得 commit"}}'

清帳的 ack.sh 就是 : > .claude/unreviewed.txt，而且只能由你手動在另一個終端機跑（記得把 Bash(*ack.sh*) 放進 deny，別讓 agent 自己清自己的帳）。

這套東西的重點不在技術含量，在於它把「我等一下再看」變成物理上不可能。

招式 4：Commit Gate 的兩組 prompt

閘門擋下來之後，你要用什麼方式 review？直接讀 300 行 diff 是最沒效率的做法。我用兩組 prompt。

第一組：逼它自曝決策點。

先不要再改任何檔案。用繁體中文回答：
1. 這輪一共動了哪幾個檔案？每一個為什麼非改不可？
2. 有哪 3 個設計選擇是我沒明確要求、你自己決定的？
   各自的替代方案是什麼、為什麼沒選？
3. 這份改動最可能在什麼情況下壞掉？
   給我一組具體的「輸入 → 錯誤輸出」。
4. 有哪一段你自己也不確定是對的？
不要辯護，直接列。

第 2 題是全場最有價值的一題。Agent 出錯很少錯在你交代的部分，幾乎都錯在它替你補上的預設值——那個它沒問就選了的 timeout、那個它自己加的 try/except、那個它決定要 fallback 的分支。

第二組：讓它反過來考你。 這一招是直接針對「我不知道這 code 怎麼運作」設計的：

先不要解釋。針對剛剛這份 diff 出 5 題選擇題考我，
每題都必須是「不讀 diff 就答不出來」的細節
（例如某個 early return 的條件、某個預設值、某個錯誤處理的分支）。
先只給題目，我答完你再公布答案跟我錯在哪。

答錯 3 題以上，代表你其實沒讀懂這份 diff——那就別 commit。這個檢查只要 90 秒，但它量到的東西跟「我掃過了」完全不同。

招式 5：把 worktree 數量當成配額管

fnoef 的第三級滑坡是 4–5 個並行 agent。這裡沒有什麼精巧設定，就是一條紀律：並行 agent 的上限 = 你能同時維持的心智模型數量，對多數人是 2。

實務上的判準很簡單：如果你需要「在兩個 agent 的 output 之間來回跳」才知道發生什麼事，你已經超載了。開第三個之前先問自己一句：第三個 agent 的產出，我等一下真的會逐行看嗎？如果答案是「我會看它的摘要」，那就是不會。

配合 git worktree list 當儀表板，每天收工前確認沒有孤兒 worktree 掛著。

招式 6：把 /rewind 當安全網，但要知道它的破口

Claude Code 會在每個 user prompt 前自動建立 checkpoint，保留一個 session 最近 100 個，跟著對話存檔，30 天後隨 session 一起清掉（可用 cleanupPeriodDays 調整）。按 Esc 兩次（輸入框要是空的）或打 /rewind 就能開選單，可以選「只還原程式碼」「只還原對話」「兩者都還原」，也可以從某個點開始壓縮上下文。

但它有三個破口，你必須知道，否則會誤以為自己有安全網：

• bash 指令改的檔案不會被追蹤。 Agent 跑 rm、mv、cp 造成的變動，/rewind 救不回來。
• subagent 的編輯通常不會被還原。 背景執行的 subagent（包含背景跑的 /code-review --fix）改的東西要用 git 還原。唯一例外是前景執行的 forked skill。
• symlink / hard link 的路徑會被跳過，還原時會顯示 Restored the code, but skipped N files。

所以官方講得很白：checkpoint 是 session 級的快速回復，不是版控的替代品。真正的安全網還是小步 commit。

招式 7：每天留一個手寫窗口

這一條沒有設定檔，但它是唯一能防止「能力真的萎縮」的東西。HN 上 curuinor 的比喻我覺得最準：「這就像社會從勞力密集走向全面自動化。連工地師傅現在都要上健身房。你也得替腦袋做健身房的事——而健身房做的事本來就不是為了生產東西。」MarkusQ 給的清單更具體：拿一本實體書坐下來讀、閉著眼睛聽音樂、不戴耳機走路、動手做東西。

我的版本是：每天保留 60 分鐘，選一段agent 已經寫好而且會動的程式碼，關掉 agent，自己重寫一次。不是為了取代它的版本，是為了確認你還寫得出來。這件事沒有產出，所以永遠不會有人幫你排進 sprint——你得自己排。

四、數據怎麼說（以及不能過度解讀的地方）

有三份研究常被拿來講這個題目。我把數字跟適用前提一起放，因為這幾份都很容易被超譯。

METR 的隨機對照試驗（Joel Becker、Nate Rush、Elizabeth Barnes、David Rein，arXiv:2507.09089，2025 年 7 月）。16 位有經驗的開源開發者、246 個任務、平均在該 repo 有 5 年經驗，每個任務隨機分派「可以用 AI」或「不可以用 AI」。結果是：允許用 AI 的任務，完成時間增加 19%。但開發者事前預測 AI 會讓他們快 24%，做完之後仍然估計自己快了 20%。經濟學專家預測快 39%、ML 專家預測快 38%。

這裡真正重要的不是那個 19%，而是主觀感受與客觀時間之間有將近 40 個百分點的落差。這正好解釋了 fnoef 為什麼會持續加碼。

限制要講清楚：樣本只有 16 人；受試者對該 repo 極熟悉、專案成熟且品質要求高（這是 AI 最不占優勢的場景）；工具是 2025 年 2–6 月的水準，主要是 Cursor Pro 加 Claude 3.5/3.7 Sonnet。不能直接外推到 2026 年的 Claude Code。作者自己也寫了，實驗設計造成的影響無法完全排除。

MIT Media Lab 的 EEG 研究（Nataliya Kosmyna、Pattie Maes 等，arXiv:2506.08872，「Your Brain on ChatGPT」）。受試者被分成 LLM 組、搜尋引擎組、純腦組寫作文，用 EEG 量腦區連結。結論是 LLM 組的神經連結最弱、對自己文章的擁有感最低，而且在寫完幾分鐘後引用自己剛寫的內容都有困難。

這份的限制更需要標註：它是未經同儕審查的 preprint（2025 年 6 月上線），前三場 54 人、第四場只剩 18 人完成，作者自己在網站上就寫了樣本數限制推廣性。而且它測的是寫作文，不是寫程式。所以正確的用法是：把它當成一個值得注意的假說，不是定論。但「引用不出自己剛產出的東西」這個現象，跟 fnoef 寫的「我已經不知道那份程式碼」實在太像了，也是我上面第二組 prompt（讓 agent 出題考你）的直接靈感來源。

Google Cloud 的 DORA 2025 報告（State of AI-assisted Software Development，近 5,000 位技術從業者、超過 100 小時質性資料）。90% 的受訪者在工作中使用 AI，超過 80% 認為 AI 提升了生產力，但30% 表示對 AI 產生的程式碼只有很少或沒有信任。報告的核心結論是：AI 是放大器——它放大組織既有的強項與弱點。與去年不同的是，今年 AI 採用與交付吞吐量、產品表現呈現正相關；但 AI 採用與交付穩定性仍然是負相關。

「放大器」這個框架很關鍵：如果你的團隊本來 review 就鬆，agent 不會讓它變緊，只會讓沒被 review 的量變大。

五、什麼時候該守紀律、什麼時候可以放手

不是所有情境都要三道閘門全開。我的判準是「這段程式碼壞掉時，錯誤會不會沉默地擴散」：

情境	建議
一次性腳本、資料探索、原型 demo	放手 vibe，別上閘門，讀不讀 diff 不重要
熟悉的 repo、有完整測試覆蓋、改動小	Plan gate 可略，保留 commit gate
陌生的 codebase / 剛接手的專案	三道全開，並行上限降到 1
碰到金流、權限、資料刪除、外部 API 寫入	三道全開 + 手寫窗口，diff 逐行讀
遷移類的大量重複改動	開 worktree 並行，但抽樣 review + 靠測試把關

還有一個反向的提醒：閘門也有成本。如果你把一個一次性的 log 分析腳本也塞進三道閘門，你只會很快就把 hook 關掉，然後連該守的場合也不守了。閘門要留給真正會痛的地方。

六、對工程團隊的意義

如果你是帶團隊的人，fnoef 這篇最該讓你警醒的是第一句話：他是被績效壓力推進來的。「跟上同事的產能」這個指標，直接獎勵了「不 review」。

三件可以馬上做的事：

1. 把閘門設定進 repo，不要靠個人自律。 .claude/settings.json 和 .claude/hooks/ 都可以進版控，全團隊共用。官方也是這樣設計的——permission 設定可以 check in 分享，個人再用 .claude/settings.local.json 微調。但注意：專案 .claude/settings.json 裡的 allow 規則和 additionalDirectories 屬於「授予能力」，要等你接受 workspace trust 對話框之後才生效（deny 和 ask 不受影響，因為它們只做限制）。
2. 不要用「出貨量」當 AI 時代的產能指標。 DORA 的資料已經說了，AI 提高吞吐量的同時也在傷害穩定性。如果你只獎勵前者，你就是在補貼後者。至少要把變更失敗率一起看。
3. 公開討論這件事，而不是只發 AI 工具授權。 HN 上 sph 那句話值得放進管理者的腦袋：他說他試著認真討論 AI 的心理影響，「結果被那些只在乎自己今天推了幾個 commit 的人蓋過去」。團隊裡如果沒有人敢說「我看不懂我今天送出去的東西」，那你就永遠不會知道。

最後回到 fnoef。他文章的最後一段其實藏了整件事最難的部分：他說想換工作，但「每個面試官不是問『請說說你日常怎麼用 AI』，就是直接講『我們喜歡快，所以盡量用 AI』」。這不是他一個人的紀律問題，這是整個產業把「用得多」當成能力訊號的結果。

我們沒辦法一個人改變產業訊號。但你今天可以做的，是讓「不 review 就 commit」在你的機器上變成一個技術上做不到的動作。

來源

• Hacker News, fnoef, "Tell HN: Man, AI is killing my brain"（2026-08-27）— https://news.ycombinator.com/item?id=49468252
• Joel Becker, Nate Rush, Elizabeth Barnes, David Rein (METR), "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", arXiv:2507.09089 — https://arxiv.org/abs/2507.09089
• METR blog（2025-07-10）— https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• Nataliya Kosmyna, Pattie Maes 等 (MIT Media Lab), "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task", arXiv:2506.08872 — https://arxiv.org/abs/2506.08872 ／ https://www.brainonllm.com/
• Google Cloud / DORA, "2025 State of AI-assisted Software Development Report" — https://dora.dev/dora-report-2025/
• Simon Willison, "Vibe engineering"（2025-10-07）— https://simonwillison.net/2025/Oct/7/vibe-engineering/
• Anthropic, Claude Code 官方文件：Hooks — https://code.claude.com/docs/en/hooks
• Anthropic, Claude Code 官方文件：Permissions — https://code.claude.com/docs/en/permissions
• Anthropic, Claude Code 官方文件：Checkpointing — https://code.claude.com/docs/en/checkpointing

整理：DataAgent · Coding Agent 實戰教學