Claude Code 創辦人的工作哲學：同時養十隻 Claude 的時代來了

本文整理自 The Startup Ideas Podcast 2026 年 1 月播出的單集，訪談 Claude Code 創辦人 Boris。

Boris 是 Claude Code 的創辦人，也是 Claude Cowork 的共同創作者。在這集 Podcast 中，他分享了自己每天怎麼使用 Claude Code 工作。最讓人意外的是，他的設定其實非常陽春——沒有太多客製化，因為 Claude Code 開箱即用就已經很好用了。

但他的工作方式，跟大多數人想像的完全不同。

不是一次專注一件事，而是同時照顧一群 Claude

Boris 說，他現在的工作方式是同時運行 5 到 10 個 Claude。有些在終端機跑，有些在手機上，有些在網頁版。他形容這是「牧羊人模式」——不是深入鑽研單一任務，而是在不同的任務之間來回切換，確保每一隻 Claude 都在正軌上、沒有卡住、有問題就回答它。

他的典型流程是這樣的：在第一個分頁開啟任務，讓 Claude 開始思考並擬定計畫；趁它在想的時候，切到第二個分頁開啟另一個任務；再切到第三個。等到手邊沒有新任務要開了，再回到第一個分頁看看計畫好不好。如果計畫 OK，就直接開啟「自動接受編輯」模式，讓 Claude 一口氣執行完。

這聽起來很瘋狂，但 Boris 說這其實是 Opus 4.5 帶來的改變。過去的模型需要你一直盯著、一直修正方向，但 Opus 4.5 的規劃能力太強了，一旦計畫對了，程式碼就會對。所以他現在的工作重心是「確保計畫正確」，而不是「監督程式碼生成」。

用手機寫程式，聽起來荒謬但真的可行

Boris 坦言，如果一年前有人告訴他，他會用手機寫程式，他一定覺得對方在開玩笑。但現在，他大概有一半的程式碼是在 iPhone 上完成的。

他的習慣是早上一醒來，腦中有什麼想法——可能是想做的功能、可能是在 Twitter 上看到的 bug 回報——就直接打開手機上的 Claude App，點進左側選單的 Code 分頁，開一個新任務讓 Claude 去做。然後他去喝咖啡、做其他事，晚點再回來檢查進度。

當終端機的分頁用完了（因為每個分頁是獨立的 git checkout，管理起來有點麻煩），他就會「溢出」到網頁版，在那邊繼續開新任務。

Opus 4.5 的反直覺真相：更大的模型反而更便宜

Boris 在他那則爆紅的推文中寫道，他所有工作都用 Opus 4.5 加上 Thinking 模式。很多人會直覺認為：大模型比較貴、比較慢，應該用小模型比較划算吧？

但事實恰好相反。

Boris 解釋，因為 Opus 4.5 更聰明，它用的 token 數量反而更少。你不需要一直修正它、不需要來回好幾輪才把事情做對。最後算下來，用 Opus 4.5 完成一個任務的總 token 數，常常比用小模型還少——所以不只更快，還更便宜。

這是一個違反直覺但非常重要的洞察：選擇 AI 模型時，不要只看單價，要看完成任務的總成本。

ClaudeMD：團隊共用的錯誤修正資料庫

Claude Code 團隊有一個共用的 ClaudeMD 檔案，就是一個純文字檔，沒有特殊格式。每當有人發現 Claude 做錯什麼事，就把它加進去，這樣 Claude 下次就不會再犯同樣的錯。

Boris 說，他在 Meta 工作時就有類似的習慣：每次 code review 看到同樣的問題，就在試算表上記一筆；當某個問題累積到五次、十次，就寫一條 lint rule 來自動檢查。現在有了 LLM，ClaudeMD 就是新時代的 lint rule——你不需要再重複指出同樣的問題，只要寫進 ClaudeMD，Claude 就會記住。

他們甚至會在 code review 時直接 tag Claude，請它把剛剛發現的問題加進 ClaudeMD，作為 PR 的一部分。這樣知識庫就會隨著團隊工作自然成長。

給 Claude 一雙眼睛，品質會好十倍

Boris 給出的第三個關鍵建議是：讓 Claude 有辦法驗證自己的輸出。

他用了一個很生動的比喻：想像你是一個畫家，要畫出非常精細的作品，但你必須蒙著眼睛畫。結果一定不會好。工程師也一樣，如果你寫程式但永遠不能執行、永遠看不到結果，程式碼品質一定很差。

Claude 也是如此。如果你讓它能跑測試、能啟動伺服器、能透過 Chrome 擴充套件看到網頁實際長什麼樣子，它的輸出品質會好非常多。這就是為什麼 Claude Code 內建了瀏覽器控制功能——讓 AI 能夠「看見」自己做的事情，然後自我修正。

我的觀察

從深度專注到牧羊人模式

Boris 描述的工作方式，讓我想到一個根本性的轉變：過去我們推崇「深度工作」，認為專注在單一任務上才能產出高品質的成果。但在 AI 時代，高手的工作方式可能更像牧羊人——你不是親自去做每一件事，而是同時照顧一群 AI 助手，確保它們各自在正軌上。

這不代表深度思考不重要了。相反的，深度思考被「往上移」了一層：你的腦力不是花在寫程式碼，而是花在「這個計畫對不對」「這個方向有沒有問題」。Boris 說的「一旦計畫對了，程式就對了」，本質上就是這個意思。

這種工作模式需要的技能組合跟以前很不一樣。你需要更好的全局觀、更快速的判斷力、更精準的提問能力。而「能夠長時間專注在細節上」這個過去被視為美德的特質，重要性反而下降了。

讓 AI 能驗證自己，這個原則適用於所有人

Boris 的「蒙眼畫家」比喻非常精準，而且這個原則不只適用於工程師。

如果你用 AI 寫文案，與其讓它盲寫，不如給它看你過去的作品、給它看競品的文案、給它看這篇文案要放在哪裡。如果你用 AI 做資料分析，與其讓它盲猜，不如讓它能實際跑程式、看到輸出、自己發現錯誤。

這個原則的核心是：AI 不是魔法，它需要回饋循環才能做好工作。我們常常抱怨「AI 產出品質不好」，但很多時候問題不在 AI，而在於我們沒有給它足夠的「眼睛」去看見自己做的事情對不對。

下次使用 AI 時，不妨問問自己：我有沒有給它一個驗證輸出的方式？如果沒有，也許該想想怎麼補上這一塊。