你有沒有想過，廚師在家自己煮飯的時候，到底都煮什麼？

2026 年 1 月 2 日，Claude Code 的創作者 Boris Cherny 發了一條推文，回答了 AI 版的這個問題：「造出 AI coding 工具的人，自己到底怎麼用這個工具？」結果這條推文直接炸了，累積了數百萬次瀏覽 (◕‿◕)

答案比你想的還要瘋狂 — 他不只是用 Claude Code 寫一般的專案，他是在用 Claude Code 寫 Claude Code 本身。過去兩個月，他寫的 code 已經 100% 由 AI 產出。

好，深呼吸，我們慢慢拆解。

一個人怎麼同時管 5 個 AI

Boris 的工作桌面大概長這樣：5 個 terminal tab 同時跑 Claude Code，旁邊 claude.ai/code 網頁版還開了 5 到 10 個。

這不是在炫技。你可以想像成餐廳廚房 — 一口鍋在煎牛排、一口在煮義大利麵、烤箱裡有蒜味麵包、旁邊還在擺盤甜點。每個 session 各做各的事：一個修 bug、一個寫新 feature、一個在重構。Boris 就像那個在廚房裡轉來轉去、不斷試味道的主廚，只是他試的是 code diff ┐(￣ヘ￣)┌

每個 local session 用 git checkout 隔離，不是 branch 也不是 worktree。他從 CLI 用 & 開遠端 session，然後用 --teleport 在不同環境間搬來搬去。

Clawd Clawd 歪樓一下：

5 個 Claude 同時跑聽起來很酷，但 Boris 在後續的討論中也提到，有些 session 會因為意外狀況被放棄 — 並非每次都能完美收尾。

就像你同時在蝦皮下了 5 筆訂單，總有一兩筆會被取消或延遲出貨。重點不是每個 session 都成功，而是你的 throughput 整體上去了。失敗的成本很低，成功的收益很高 — 這算盤打得精 (⌐■_■)

為什麼他只用「慢的」model

Boris 所有 coding 任務都用 Opus 4.5 with thinking。不用 Sonnet，不用更快的選項。

這違反直覺對吧？明明有更快的車，為什麼要開慢車？

原因很簡單：你有沒有過那種經驗，趕時間所以在巷子裡抄近路，結果迷路了繞更久？Boris 說 Opus 雖然每次回應慢一點，但品質更高、更會用 tools、來回次數更少。一次就對的東西，不用花三次修。加總起來反而更快。

這就是開高速公路 vs 鑽小巷子的差別 — 時速 80 一路直達，比時速 120 但走錯路快。

Clawd Clawd OS：

我自己在 gu-log 的翻譯流程也驗證了這件事 (◕‿◕)

用比較強的 model 一次把稿子寫到位，比用快的 model 寫完再來回修改，最後花的時間其實差不多，但品質差很多。Boris 這招不是偏見，是踩過坑之後的實戰經驗。

用筆記本「馴化」你的 AI

每個 Anthropic 團隊的 repo 裡都有一個 CLAUDE.md 檔案。你可以把它想像成一本給 AI 看的「班級公約」— 裡面寫著 Claude 之前搞砸過什麼、團隊的做事習慣、還有各種血淚教訓。

Boris 會在同事的 PR 上用 @.claude tag，把從那個 PR 學到的東西寫進去。他們的檔案已經累積了 2.5k tokens。

每次 Claude 搞砸一件事，你就寫進去。下次它讀到 CLAUDE.md 就會知道「喔對，上次這樣做出事了」。你沒辦法真的 fine-tune Claude，但你可以用 context 達到類似效果。這種「假裝在做 continual learning」的做法，聽起來很 hack，但還真的有效。

Clawd Clawd 忍不住說：

這根本就是養寵物的邏輯嘛 ╰(°▽°)⁠╯

狗第一次在沙發上尿尿，你記下來，下次看到牠靠近沙發就先帶出去。AI 搞砸一次 import 排序，你寫進 CLAUDE.md，下次它就不會再犯。

差別是狗可能會忘記，但 CLAUDE.md 不會。所以某種意義上，AI 比狗好訓練（別跟我的狗說這件事）。

不要一上來就讓 AI 亂寫

Boris 的做法分兩步：先進 Plan mode 跟 Claude 來回討論，討論到他滿意了，才切到 auto-accept 讓 Claude 去執行。

他原話是這樣的：「如果目標是寫一個 Pull Request，我會用 Plan mode，跟 Claude 來回討論直到我喜歡它的計畫。然後切到 auto-accept 模式，Claude 通常就能一次完成。」

你可以想像成裝潢房子 — 你不會直接叫師傅「開始打牆」，你會先看設計圖、討論動線、確認預算，全部 OK 了才開工。否則打掉重來的成本比多花半天討論貴十倍。

Clawd Clawd murmur：

這個「先 plan 再 execute」的模式其實不只適用於 AI ヽ(°〇°)ﾉ

我看過太多人用 Claude Code 的方式是直接丟一大段需求然後祈禱。結果 Claude 一頓猛操作，改了 15 個檔案，最後你才發現方向根本錯了。

Boris 的方法是：讓 AI 先說「我打算這樣做，你覺得呢？」你說 OK，它才動手。多花 2 分鐘 plan，省下 20 分鐘的 undo (⌐■_■)

把重複的事情變成一個按鈕

Boris 每天做 commit、開 PR、跑 simplification 這些事情，全部做成 slash commands 存在 .claude/commands/ 裡。

他的 /commit-push-pr command 一天跑幾十次。這個 command 會先用 inline bash 算好 git status 和相關資訊，丟給 Claude 的時候它已經知道所有 context 了，不用再花 3 個 tool call 去查。

Clawd Clawd 忍不住說：

這就像你把常用的通勤路線設成 Google Maps 的「最愛」— 每天早上不用重新輸入地址，一鍵出發 (◕‿◕)

聽起來是小事，但 Boris 一天跑幾十次。每次省 30 秒，一天就省了十幾分鐘。而且更重要的是省下了決策疲勞 — 你不用每次都想「我要先 git add 還是先 git diff」，command 替你記住了流程。

讓 AI 自己擦屁股

Boris 設定了一個 PostToolUse hook：

PostToolUse:
  matcher: "Write|Edit"
  hooks:
    - type: "command"
      command: "bun run format || true"

Claude 每次寫完或改完 code，formatter 自動跑一次。吐出來的 code 永遠是格式化好的，不用人工整理。

很多人抱怨 AI 寫的 code 格式亂七八糟，但其實問題不在 AI，在你沒幫它裝好水龍頭。你不會期待小孩吃完飯自己把碗洗乾淨，你會裝一台洗碗機。

Clawd Clawd 真心話：

這招的精髓在於：不要試圖教 AI 完美，要設計系統來接住 AI 的不完美。

Claude 有時候會忘記加 trailing comma，有時候 indent 會跑掉。與其每次提醒它「記得格式化」（它可能還是會忘），不如設一個 hook 自動收拾。系統設計 > 個體自律，這個道理在管理 AI 和管理人的時候都一樣 ┐(￣ヘ￣)┌

安全感不是靠「全部關掉」

Boris 不用 --dangerously-skip-permissions。他用 /permissions 把常用的安全指令加到白名單，像 bun run build:* 和 bun run test:*。

這是很重要的一課：很多人覺得 permission prompt 很煩，就直接全部跳過。但那就像你覺得門禁很煩，所以把大門焊死在打開的位置 — 你確實不用再刷卡了，但小偷也不用。Boris 的做法是「幫常客辦通行證」，不是「拆掉門」。

Clawd Clawd 偷偷說：

我看過有人在 GitHub 上推薦「第一步：加上 —dangerously-skip-permissions」，看得我頭皮發麻 (╯°□°)⁠╯

那個 flag 前面有 “dangerously” 三個音節不是裝飾用的欸。Boris 身為 Claude Code 的創作者都不敢全開，你是覺得你比他更了解風險嗎？

聰明的懶是設白名單，笨的懶是關安全機制。差別在於出事的時候你有沒有東西可以怪 (⌐■_■)

讓 Claude 自己 QA 自己

Boris 認為最有影響力的做法是建立驗證的 feedback loop。Claude 在 claude.ai/code 上用 Chrome extension 測試每個改動 — 真的打開瀏覽器、測 UI、看按鈕能不能按、流程順不順。發現問題就自己改，改完再測，直到功能正常、UX 體驗順暢。

以前是：人寫 code → 人測試 → 人發現 bug → 人修 → 人再測。現在是：AI 寫 code → AI 自己測 → AI 發現 bug → AI 自己改 → AI 再測。你只要在最後驗收就好。

Boris 說這個驗證流程可以讓最終結果的品質提升 2-3 倍。

Clawd Clawd 插嘴：

注意這邊的關鍵字：「feedback loop」。

Boris 不是說「讓 AI 測一次」，他是說「讓 AI 不斷測、不斷改、iterate 到好為止」。這跟你叫實習生改報告的邏輯一模一樣 — 你不會看一次就簽核，你會叫他改三次再來 ╰(°▽°)⁠╯

差別是 AI 不會在第三次的時候開始擺臭臉。

所以，27 個 PR 到底什麼概念

Boris 在回覆 Andrej Karpathy 時另外提到了這個數字（這來自他的後續回覆，不是原始推文）：

過去兩個月，我 100% 的 code 都是 Claude Code 和 Opus 4.5 寫的。昨天我 ship 了 22 個 PR，前天 27 個，每一個都是 100% AI 寫的。

Claude Code 的創作者，用 Claude Code，寫 Claude Code，一天 ship 27 個 PR。這聽起來有點像 AI 在改進自己的工具鏈 — 雖然嚴格說來是 Boris 在指揮，不是 AI 自主決定要改什麼。但產出的密度確實驚人。

而且這不是在實驗室裡跑 benchmark，這是真的在 ship 給全世界用戶用的 product。

延伸閱讀

Clawd Clawd 吐槽時間：

回到開頭的問題：廚師在家都煮什麼？

答案是：Boris 在家煮的東西，跟他在餐廳煮的一模一樣 — 他用自己的工具，做自己的工具，然後用做出來的更好的工具，繼續做工具。

數百萬人看這條推文，不是因為 Boris 講了什麼驚天動地的理論。是因為大家在 2025-2026 都在重新學怎麼寫 code — 以前的技能樹是「我會 React」，現在是「我會用 Claude Code 寫 React」。大家想知道高手怎麼點技能樹，而 Boris 直接把他的技能樹截圖給你看了 (◕‿◕)