Boris Cherny：Claude Code 創造者如何使用 AI Agent？從 13 項實戰技巧到不再親手寫程式的未來

2026 年 2 月，Claude Code 創造者 Boris Cherny 在接受 Lenny Rachitsky 訪談時透露，從 2025 年 11 月開始，他就沒有再親手修改過任何一行程式碼。他每天仍然能提交 10 到 30 個 Pull Request（PR），而實際程式碼交由 Claude Code 完成。更值得注意的是，他並不懷念過去親手編寫程式的日子，反而認為自己從來沒有像現在這麼享受程式設計。

這不是一位不懂程式設計的人，第一次使用 AI 寫程式的故事。Boris 曾在 Meta 擔任工程師、參與大型程式碼庫的品質管理，也撰寫過《Programming TypeScript》。他擁有傳統軟體工程的深厚背景，卻成為最積極改變自己工作方式的人之一。

2026 年 1 月，他在 X 分享 13 項個人的 Claude Code 使用技巧。同月底，他又分享從 Claude Code 團隊其他工程師身上整理出的 10 項方法。再往後，他在訪談中描述，自己的工作已經從直接下 Prompt、同時管理數個 Agent，進一步演變成建立 Loop，讓 Agent 持續自主處理任務。

這些內容值得長期保存的地方，不只是「AI 提高了多少倍生產力」，而是他實際如何安排工作、設定工具、驗證成果，以及隨著模型進步，不斷拋棄舊有的操作習慣。

編輯說明： 本文是依據 Boris Cherny 多場訪談與公開分享整理的人物專題，並非逐字稿。涉及工具與模型版本的設定，均代表受訪者當時的做法；本文的操作示例不是他的原始 Prompt，也不代表現在所有版本均完全相同。

一、Boris Cherny 是誰？Claude Code 如何誕生？

Boris 在電腦歷史博物館的訪談中回憶，他約 13 歲開始在 TI-83 計算機上寫程式。最初是想在數學考試中取得好成績，後來逐漸開始編寫方程式求解工具，甚至接觸 Z80 組合語言。對他而言，寫程式一直是一種把問題轉變成可執行方法的能力。

2024 年，他加入 Anthropic Labs，開始探索大型語言模型能夠創造的新產品。當時的程式設計輔助主要仍以自動補全、生成片段為主；工程師往往還是得把模型產生的程式碼貼回開發環境，自己動手修改與執行。

Boris 最初建立的 Claude Code 原型，其實只是一個能呼叫模型 API 的終端機聊天程式。他選擇 CLI，不是因為預先認定終端機是未來，而是因為這樣最快，不需要先開發圖形介面。之後，他把 Bash 這類工具交給模型，觀察模型會如何使用。

有一次，他問 Claude：「我現在正在聽什麼音樂？」模型沒有現成的音樂播放器專用介面，卻自行寫出 AppleScript，透過電腦查詢目前播放的歌曲。這個經驗讓他理解，模型只要獲得足夠通用的工具，便可能自行找出解決方法。

Claude Code 的重要設計理念因此不是替每一項操作預先安排按鈕，而是讓模型能夠讀寫檔案、使用命令列、呼叫工具，並根據目標採取行動。

二、從親手寫程式，到讓 Claude 完成所有程式碼

Claude Code 最初的能力並不突出。Boris 說，早期他更常用它執行 Git 指令、Bash 工作與簡單自動化，因為模型當時還不能可靠地完成複雜程式碼。他並沒有因為自己正在開發 Claude Code，就假裝它從一開始便無所不能。

但模型能力快速進步。他逐漸把更多程式設計任務交出去；到了 2025 年 11 月，他突然發現自己已經好幾個星期沒有親手改過程式碼，甚至曾因為很久沒有使用 IDE 而將它解除安裝。

在 Lenny’s Podcast 中，他說每天能提交 10 到 30 個 PR；而在之後的 Sequoia 訪談中，他提到曾有一天測試極限，提交大約 150 個 PR。這些數字是他在不同時間分享的個人經驗，不是一般工程師應有的績效標準，也不代表每個 PR 的規模相同。

他現在更常做的事情，是提出需求、討論架構、檢查計畫、管理執行中的 Agent，以及確認結果是否達到要求。在這套工作方式裡，創造軟體仍然需要判斷力，但親手輸入程式碼已經不是必要條件。

三、Boris 本人的 13 項 Claude Code 使用技巧

2026 年 1 月 2 日，Boris 公開了自己的工作配置。他形容這套設定其實相當「普通」，沒有大量神奇的客製化。他強調不存在人人適用的唯一正確方式；Claude Code 團隊成員彼此也有完全不同的習慣。以下保留當時的工具名稱與具體做法，並在必要處說明使用條件。

技巧 1：五個終端機 Session 平行工作

Boris 會在終端機開啟五個 Claude Code 分頁，編號 1 到 5，每個分頁執行一項相對獨立的任務。不同任務可能分別是開發功能、修復 Bug、分析現有程式碼、補上測試，或整理文件。系統通知會告訴他哪個分頁需要輸入，他不必一直盯著某個任務結束。

實際操作概念： 如果同時修改同一個 Repository，必須使用獨立 Checkout 或 Worktree 隔離修改。否則多開 Session 只是增加檔案衝突。Boris 當時偏好多個獨立 Checkout；他後來分享的團隊技巧則有大量使用 Git Worktree 的案例，兩者不可混為同一個設定。

例如，分別準備 project-feature/、project-bugfix/ 等工作目錄，各自在其中開啟 Claude。等工作完成，再透過 Git Review 與 Merge 整合成果。

技巧 2：另外使用五到十個雲端 Session，並從手機發起任務

除了本機終端機，Boris 還會在 claude.ai/code 同時執行約 5 到 10 個 Session。他分享過使用 & 交接背景工作，並透過 --teleport 等工作階段功能在執行環境之間切換。這些指令與功能會隨版本演進，實際使用應以當時官方文件為準。

他也會在早上或其他空檔，直接使用手機的 Claude App 發起任務，稍後再回來檢查結果。這種工作方式讓開發者不再被固定桌面工作站綁住；重要的不是手邊是否有完整 IDE，而是 Agent 能否持續處理已經交辦的工作。

技巧 3：優先使用能力最強的推理模型

在 2026 年 1 月公開配置時，Boris 表示自己所有工作都使用 Opus 4.5 Thinking。這不是因為模型最便宜、反應最快，而是因為強模型較容易一次完成複雜任務，工具使用更穩定，所需的人工修正也較少。

如果一個便宜模型需要反覆補充 Prompt、重跑測試、人工追查錯誤，最終耗費的時間可能高於較強模型一次完成工作的成本。Boris 的衡量標準是完成整個任務所付出的總成本與時間，而非只看單次 Token 費用。這是他當時的個人偏好，不應改寫成所有工作必須永遠使用最昂貴模型的通用定律。

技巧 4：團隊共用 CLAUDE.md，把可避免的錯誤轉成規則

Claude Code 團隊把共同的開發規範放在 Repository 裡的 CLAUDE.md，交由 Git 管理。當 Code Review 發現模型重複犯下可以避免的錯誤，便把真正值得長期遵守的指引整理進文件，讓未來的 Agent 和同事都能受益。

Boris 在 Y Combinator 訪談中透露，自己的個人 CLAUDE.md 當時只有兩項工作習慣：建立 PR 時啟用 Auto-merge；把 PR 發送到團隊內部指定頻道以取得審查。其他內容由團隊共用文件管理。

他同時警告：規則不是越長越好。如果 CLAUDE.md 變得龐大、重複，甚至相互衝突，可以重新整理，只在模型真的需要時才補回規則。模型越聰明，過去必須寫明的許多提示可能不再必要。

技巧 5：在 GitHub PR 中直接呼叫 Claude

Boris 不會把 AI 的使用限制在終端機。在團隊整合的 GitHub PR 討論裡，他可以標記 Claude，要求它修正問題、更新文件，或把反覆出現的錯誤轉成團隊規範。當時使用的標記樣式與 Action 配置屬於團隊整合細節，不應認定所有 GitHub 專案安裝完便能直接使用相同標記。

核心思路是：讓 AI 出現在原本就發生工作的地方。 如果 Code Review 已經指出問題，最有效的下一步不是再將整段討論複製到另一個聊天視窗，而是直接在 Review 流程中交給 Agent 處理，並由正常的審查機制確認。

技巧 6：重要任務先使用 Plan Mode

Boris 年初相當倚重 Plan Mode。在 Y Combinator 訪談中，他說當時約 80% 的工作階段先從規劃模式開始。先讓 Claude 讀取現有程式碼、理解需求、比較方案，並討論如何驗證；等計畫成熟後，再讓它實際修改程式碼。

他的操作不只是按下某個按鈕，而是把設計決策與程式實作暫時分開。例如，先請模型釐清會影響哪些模組、資料表是否需要遷移、如何回復，以及測試如何判定成功。確定方向後才交付執行，減少做完才發現規劃錯誤的浪費。

但 Boris 也預測，未來 Claude 應該能自動判斷何時先規劃。這反映一個持續變動的實務經驗，而不是「他已經完全放棄 Plan Mode」。

技巧 7：把重複操作整理成 Slash Commands

Boris 把每天重複的步驟做成自訂 Slash Commands，當時放在 .claude/commands/ 並簽入 Git。例如他經常使用 /commit-push-pr，把檢查狀態、Commit、Push 與建立 PR 這一串工作整合起來。

他也會用 Bash 預先取得 git status 等資訊，減少模型來回查詢。對於固定且可程式化的資料，先由指令直接產生結果，再交給模型判斷，比讓模型每次重新推理整段程序更有效率。

這個路徑屬於當時的 Claude Code 設定方式；後續自訂命令與 Skills 的機制已持續整合。應保留歷史操作細節，同時在真正套用時查核目前版本。

技巧 8：使用 Sub-agent 封裝專業工作

Boris 會使用 code-simplifier，在主要程式碼完成後再檢查能否簡化；也會使用 verify-app，依照事先準備的測試指示檢驗應用程式。這些是他公開提過的具體例子，不應擴張成每個人都需要安裝同名的官方內建 Agent。

Sub-agent 的價值，是讓不同工作擁有獨立的上下文與職責。主 Agent 可以負責產品功能，另一個專責測試，第三個專責閱讀架構或檢查重複程式碼。當工作可以獨立分解時，這有機會增加產出與品質；當任務高度耦合時，過多 Agent 也可能增加協調負擔。

技巧 9：使用 PostToolUse Hook 自動格式化

Boris 的團隊用 PostToolUse Hook，在 Claude 執行寫檔、改檔工具後自動呼叫程式碼格式化命令，例如專案中的 bun run format。這讓模型不必反覆為縮排與格式規則花費額外推理，也減少 CI 因格式問題而失敗。

實務上 Hook 應限制作用範圍、確認指令存在，並避免在每次編輯時執行昂貴或危險的全專案操作。這個技巧的精髓是：可由固定程式可靠完成的步驟，交給確定性的工具；需要理解與判斷的部分，再交給模型。

技巧 10：用 /permissions 預先放行安全操作

權限確認會中斷長時間工作，但 Boris 並非主張在一般主機上完全停用權限機制。他會透過 /permissions 預先允許已確認安全的常見命令，部分團隊設定則放在 .claude/settings.json 分享。

若有必要執行長時間、無人值守的工作，則可考慮在隔離 Sandbox 中採用較寬鬆的授權。一般工作目錄的細緻授權，和經隔離驗證的自動化環境，是兩種不同情境。 不應為了方便就對正式網站、正式資料庫或主機全面取消保護。

技巧 11：讓 Claude 直接使用 Slack、BigQuery 和 Sentry

Boris 會讓 Claude 透過 MCP 或 CLI 使用原本工作上就有的系統，例如 Slack、BigQuery 的 bq CLI，以及 Sentry 錯誤資訊。需要分析某個 Bug 時，不必先手動登入每一套工具、截圖、複製所有日誌，再把資料交給 Claude。

Agent 可以直接取得授權範圍內的資料，閱讀相關程式碼、查詢指標、追蹤錯誤，再提出處理方案。工具權限與敏感資料的使用仍應遵守組織規範；這不是鼓勵 Agent 不經授權存取資料。

技巧 12：長時間工作交由背景 Agent 或 Hook 完成驗證

當任務耗時較長，Boris 會要求 Claude 完成主要工作後，再啟動驗證 Agent，或者使用 Stop Hook 觸發後續檢查。也曾分享類似 Ralph Wiggum 的持續迭代做法。

例如，修完功能後再跑整合測試；如果測試失敗，Agent 應先分析失敗原因並重新修正，而不是只回報「程式碼已經寫完」。背景工作也應有中止條件、最大重試次數及資源限制，避免無限重跑。

技巧 13：最重要的是讓 Claude 能驗證自己的成果

Boris 特別強調，想讓 Claude Code 產出更好的結果，就應該提供它驗證工作的方式。他分享過讓 Claude 使用瀏覽器實際測試網頁、檢查操作畫面，以及根據結果再次修改的做法；其他專案也可以使用測試程式、API、編譯器或模擬器。

他曾估計，好的驗證回饋可能讓成果品質提高兩到三倍。這是一項個人經驗性的評估，不能視為適用任何任務的保證數值。

判斷 Agent 是否有完成工作，不能只看它口頭說「完成了」。如果它能拿到真實測試結果，就可以持續比較目標和實際表現，直到通過檢查。這是把聊天工具變成可靠工作系統的重要一步。

四、Claude Code 團隊的 10 項進階工作方法

2026 年 1 月 31 日，Boris 公開整理了另外十項技巧，並明確說明它們來自 Claude Code 團隊其他人的經驗，不是他自己所有方法的延伸清單。這個區別值得保留：真正重要的是學會如何挑選適合自己環境的方式，而不是把全部設定照單全收。

團隊技巧 1：三到五個 Git Worktree，同時開不同 Session

團隊不少工程師使用三到五個 Worktree，同時讓不同 Claude 各自修改一份獨立的工作目錄。這讓功能開發、Bug 修復和測試分析可以平行進行，而不互相覆蓋未提交的檔案。

例如在具備 Git 的專案內執行：

git worktree add ../myproject-search -b feature/search

然後切換到新目錄啟動 Claude。其他任務另建 Worktree。整合前仍應正常 Review、測試與 Merge，並留意資料庫、共享服務和建置輸出不一定會隨 Worktree 自動隔離。

團隊技巧 2：卡住就重新規劃，甚至讓第二個 Claude 審查第一個計畫

Claude 已經走錯方向時，持續追加「再修一次」可能只會把錯誤設計變得更複雜。團隊有工程師會回到 Plan Mode，重新釐清問題；也有人啟動第二個 Claude，讓它以資深工程師視角審查第一個 Claude 的計畫。

第二個 Agent 擁有獨立上下文，較有機會指出第一個 Agent 未質疑的假設。它並非一定會更正確，但可以提供另一種檢查角度。

團隊技巧 3：讓模型整理自己的錯誤，更新 CLAUDE.md

當使用者糾正 Agent 後，可以要求它判斷這個錯誤是否會再次發生，以及是否值得留下可執行的規則。只有重複性、團隊通用的教訓才放進 CLAUDE.md；一次性的個別偏好不應擴張成全域限制。

部分團隊成員另將細節放入 Notes 文件，讓核心 CLAUDE.md 保持短小清楚。這和 Boris 個人極簡配置並不矛盾，兩者都是在避免上下文被規則淹沒。

團隊技巧 4：把反覆出現的流程做成 Skills

團隊有成員為技術債掃描、資料分析或工作資訊彙整建立 Skills。例如技術債 Skill 可要求模型找出重複程式碼與待整理區域；資料分析 Skill 可以提供查詢入口、資料欄位說明與驗證方式。

有些流程會結合 Slack、GitHub、Google Drive 或 Asana，讓 Agent 能依照既定方式收集近期資料。這不代表每個連線都可以跳過授權或使用者確認，而是將已批准的操作方法變成可複用能力。

團隊技巧 5：直接把錯誤日誌和 CI 交給 Claude 調查

與其先由工程師手動蒐集所有錯誤證據，不如讓 Claude 在授權範圍內自行閱讀 CI、測試結果與相關日誌。團隊會要求它定位失敗、重現問題、提出修復，並再次執行測試。

Boris 曾說，自己排查記憶體洩漏時仍沿用傳統方式研究 Heap Dump，但另一位工程師直接要求 Claude 分析，Claude 自己寫出輔助工具，最後更快找出問題。這提醒經驗豐富的工程師，也需要重新估計模型現在的能力。

團隊技巧 6：要求 Claude 證明改動有效，而不是宣稱完成

另一項團隊方法是讓 Claude 提出可以獨立檢查的證據：修改前後的比較、能重現的測試、通過的 CI、畫面實測或數據結果。對於看似完成但品質普通的修正，也可以要求它重新評估：既然已經知道真正原因，是否能用更簡潔的架構一次解決？

這不等於要求 Agent 為了漂亮而無止境重構，而是建立清楚的通過條件，避免只靠模型的自我評分。

團隊技巧 7：終端機與環境設定，讓多 Session 更容易管理

團隊有人特別喜歡 Ghostty 的渲染效果、色彩與 Unicode 支援，但這只是部分成員的偏好，不是 Boris 本人要求所有人更換終端機。不同人也會使用 tmux、具備顏色區分的終端機分頁、或替每個 Worktree 設定簡短別名。

/statusline 可以客製 Claude Code 的狀態列，讓開發者隨時看到目前分支、上下文使用量等資訊。對同時管理多個 Session 的人來說，清楚知道自己在哪個環境工作，比追求特定終端機品牌更有幫助。

團隊也分享語音輸入的做法。有人發現口述需求比打字快，能自然提供更多背景，尤其適合解釋難以簡短描述的功能。訪談中的 macOS 快捷操作是當時的例子，不表示 Windows 必須使用同一種快捷鍵。

團隊技巧 8：利用 Sub-agent 平行研究，保持主 Agent 上下文乾淨

對於複雜錯誤或陌生程式碼庫，團隊會直接在需求後面加上「use subagents」，鼓勵 Claude 將適合獨立處理的調查工作交給其他 Agent。例如，讓不同 Agent 分別調查日誌、程式碼路徑、架構設計和替代方案，最後彙整結果。

這樣能讓主 Agent 的 Context Window 保持集中，而不必把所有中間調查過程塞在同一個對話。Boris 在 Y Combinator 訪談中也談過獨立上下文視窗（Uncorrelated Context Windows）的價值。

原始團隊分享還提到以 Hook 將特定權限請求交給另一個模型檢查的構想，但這不是可直接複製的萬用安全機制。實際落地仍應使用經測試的官方 Hook 事件、限定環境權限，且不可讓模型自行繞過網站或資料庫的正式授權。

團隊技巧 9：以 CLI／Skill 執行 SQL 與數據分析

Boris 說，自己已經不再需要親手寫 SQL；團隊則有 BigQuery 相關 Skill。需要資料分析時，可以請 Claude 透過 bq CLI 查詢資料、比較不同假說，並檢查結果，而不是先寫好所有 SQL 再讓它解讀。

這種方式適合有明確資料來源、權限控管及可檢查查詢結果的環境；不限 BigQuery，其他能透過 CLI、API 或 MCP 操作的資料系統也可採用。Agent 產生的 SQL 不應未經審核就對正式資料執行刪除、更新或其他破壞性操作。

團隊技巧 10：用解說、HTML 圖解與間隔複習學習新系統

團隊會使用 Claude Code 幫助學習陌生技術，例如透過 /config 中當時可用的 Explanatory 或 Learning 輸出模式，讓 Claude 在修改程式碼時說明原因；也可以要求它產生 HTML 簡報、ASCII 架構圖，或用問答方式協助理解新協定與複雜程式碼庫。

另一種做法是建立間隔複習（Spaced Repetition）Skill：使用者先說出自己理解的內容，再由 Claude 提問、補充盲點，並保留適合下次複習的重點。這些方式讓 AI 不只是替工程師工作，也能幫助工程師掌握原本陌生的領域。

這在大型團隊的新進人員訓練也有價值。新人不必每個小問題都先打斷資深工程師，而可以要求 Claude 閱讀有權限存取的程式碼和文件，解釋專案背景。這能提升效率，但成效仍依賴資料品質、存取權限及對答案的查核。

五、從多個 Session 到 Loop：讓 Agent 持續自主工作

到了後期的 Sequoia 訪談，Boris 描述的工作模式已經比年初的五個終端機更進一步。他說自己很大一部分工作是從手機上的 Claude App 管理，常有五到十個主要 Session，同時每個 Session 又可以調用許多 Agent。

他在該場訪談提到，當時可能有數百個 Agent 同時運作，夜間深度任務甚至可能涉及數千個 Agent。這些是他在特定時間的個人描述，不是 Claude Code 的標準規模，也不表示這樣的併發數對一般使用者具有成本效益。

比數字更重要的，是他開始大量使用 Loop：讓 Agent 按照固定時間或特定週期，自動反覆執行工作。

Loop 1：自動維護 Pull Request

Boris 有 Loop 負責查看自己的 PR，修復 CI 失敗、重新整理分支、執行 Rebase 等工作。這些操作在傳統流程中需要工程師反覆檢查，但排程化之後，Agent 可以持續處理。涉及程式合併或正式部署，仍應按專案既有審核規範執行。

Loop 2：主動維持 CI 健康狀態

另一個 Loop 專門檢查 CI。如果發現不穩定的 Flaky Test，便研究其原因，嘗試修復或提出處理建議。這讓品質管理從「有人報錯才修」轉向「持續觀察、發現、驗證與改善」。

Loop 3：定期整理使用者回饋

Boris 還安排 Loop 每 30 分鐘收集社群平台上的回饋，將意見分類整理。他不必每次手動要求 Claude 重新閱讀所有留言，便能持續掌握哪些問題正在累積。

在 Acquired Unplugged 的訪談中，他把這個演進描述得很清楚：先是 IDE 裡親手寫程式；接著改為透過 Prompt 指揮 Claude；再後來同時管理多個 Claude；現在連 Prompt Claude 的工作也逐漸交給 Loop。他自己的工作開始變成設計這些會持續執行的 Loop。

他也提到 Routines：與本機排程 Loop 有類似概念，但可以在伺服器端持續工作，即使筆電關閉也不必停下。是否使用這類能力仍取決於當前產品方案、權限及可用功能，不能把不同時間的名稱視為永遠一致。

六、舊程式碼與既有工具，如何變成新的槓桿？

Boris 在訪談中談過，能閱讀完整程式碼庫的 Agent，讓過去已經寫好的模組變成新的槓桿。開發者不需要每次都從空白開始向模型描述所有架構。

例如，可以指定某個曾經做得很好的模組，要求新功能採用相同的命名慣例、錯誤處理方式與設計原則。模型擅長從已存在的範例辨識模式，因此歷史程式碼庫不只是維護負擔，也可能成為未來實作的參考資料。

Boris 同樣看重既有 CLI、API 與 MCP。Claude Code 不需要自己發明資料庫、版本控制或所有外部系統的操作介面；只要能安全地調用成熟工具，便有機會完成複雜工作。

當他在電腦歷史博物館談到 Agent 時，將其與普通聊天機器人的關鍵差異放在「能採取行動」上：不只是回覆文字，而是會操作工具。這個觀點也解釋了為什麼他特別重視工具使用、驗證和自動化。

七、最新提示詞觀念：清楚交代目標、投入程度與驗證

2026 年 10 月，Boris 再次分享如何與 Claude 溝通。他認為模型能力變強後，大部分工作不必再使用過度複雜或指令性極高的 Prompt；就像交辦任務給同事一樣，直接說清楚要求即可。

他強調三個要點：要完成什麼、希望投入多少心力、如何確認它做對了。 這個觀念與他年初把「能驗證工作」列為最重要技巧的說法前後一致。

例如，以下是一個依照這三個原則整理的示例，並不是 Boris 原封不動說過的 Prompt：

請為網站新增站內搜尋功能。這是正式產品功能，請充分研究目前的 WordPress 架構，選擇簡潔且方便維護的做法。完成後請測試桌面與手機操作、錯誤情況、權限以及搜尋結果，提供實際測試證據，再告訴我是否可以發佈。

這段要求沒有指定每一步必須使用什麼指令，卻交代了目標、投入程度和驗證標準。它讓 Agent 自己決定方法，人類仍負責定義什麼才算成功。

這與年初的 Plan Mode 是否矛盾？

表面上看，Boris 年初有八成工作從 Plan Mode 開始，後來卻主張不必過度詳細指定每個步驟。實際上，兩者反映的是模型能力與工作方式的進化。

模型還不穩定時，人類需要明確規劃，再緊盯執行；模型能力提高後，Agent 應該能夠自行判斷什麼時候需要規劃、何時需要調查、何時需要驗證。這不代表重要任務可以取消所有審核，而是減少沒有必要的人工微觀管理。

八、AI Agent 開始自己發現問題、修復並改善產品

Boris 的 Loop 與工具使用方式展示了下一個階段：人類不再需要每一次都主動發現問題，再交代 Agent 執行。Agent 可以在經授權的資料來源裡持續觀察錯誤日誌、測試結果、產品指標與使用者回饋，找出可能需要處理的事情。

發現問題後，它可以閱讀程式碼、分析原因、提出修正、執行測試，再根據真實結果繼續改進。這是一個「觀察 → 分析 → 修復 → 驗證 → 再觀察」的循環。

Boris 在 Y Combinator 訪談中甚至提到，Claude 有時會透過 git blame 找到過去修改某段程式碼的工程師，再透過 Slack 詢問背景資訊，取得答案後繼續工作。這表示 Agent 的能力已經延伸到跨系統協調，而不只是單機產生程式碼。

但值得注意的是，持續自主並不等於無限制授權。當 Agent 需要修改正式系統、發布內容或操作敏感資料時，仍應設置可追蹤的權限、操作紀錄與必要的審核門檻。這些控制是否有效，是現實環境中 Agent 能否真正可靠營運的關鍵。

九、為六個月後的模型打造產品

Boris 在 Y Combinator 訪談中反覆強調 Anthropic 的一個原則：不要只為今天的模型開發產品，而應考慮六個月後的模型可能做到什麼。

Claude Code 最初對寫程式幫助有限，所以 Boris 先用它操作 Bash 和 Git。等到模型足夠強大，他便讓它處理整個功能。等它能穩定執行較長的計畫，他就減少人工介入。再往後，Loop 與 Sub-agent 讓它能持續自主工作。

這也是為什麼他對過度複雜的框架保持警覺。開發者今天為了修補模型不足而建立的大量規則，下一代模型可能根本不需要。對他而言，持續試驗模型真正的新能力，比死守一套過時的工作流程重要得多。

他還很重視「潛在需求」（Latent Demand）。例如最早的使用者自行建立 Markdown 檔案，再要求 Claude 閱讀，這成為 CLAUDE.md 的產品線索；使用者反覆要求「先規劃、不要直接寫程式」，後來才逐步形成 Plan Mode。好的功能不一定來自一開始就畫好的宏大藍圖，也可能來自觀察使用者原本正在設法完成什麼。

十、軟體工程師如何變成 Builder？

Boris 認為，隨著程式實作成本下降，傳統軟體開發的職務界線會逐漸模糊。在 Claude Code 團隊中，除了工程師，產品經理、設計師、資料科學家及其他角色，也已開始利用 Claude Code 產生能投入工作的程式與工具。

他使用「Builder」（創造者）來形容這種新的工作角色。真正重要的能力不再只是精通哪一種程式語言，而是能否提出值得解決的問題、理解使用者需求、選擇正確方向，再利用 Agent 完成產品。

在 Sequoia Capital 訪談中，Boris 舉了會計軟體的例子：如果寫程式變得相對容易，真正最適合開發會計產品的人，可能是極度了解會計工作的一流會計師。因為深厚的領域知識與對真實問題的理解，可能比輸入程式碼的速度更難取代。

這不意味專業工程師會立刻消失，而是工程師的價值可能更多轉向架構設計、系統判斷、產品品質與跨領域整合。新的創造者未必有傳統工程職稱，卻可能憑藉特定領域的專業，做出原本需要委託整個開發團隊才能完成的工具。

十一、Boris Cherny 對未來的想像

Boris 喜歡把軟體開發的變化，放進更長的技術史裡觀察。在 Sequoia 的訪談中，他以印刷術推動讀寫能力普及作為比喻：過去文字與書籍掌握在少數人手中，後來逐漸變成社會普遍使用的能力。他認為創造軟體也可能經歷類似的普及，而且速度可能更快。

當會計師、木匠、水電工、設計師或研究人員都能利用 Agent 為自己開發工具，軟體將不再只是專業工程師製造、其他人購買的商品，也可能成為人們每天根據需要自行創造的能力。

Boris 本人的工作經驗，就是這種變化最直接的例子。他從親手撰寫程式，進化成透過 Prompt 指揮 Claude；接著同時管理多個 Agent；如今還透過 Loop 建立持續工作的系統。這個過程沒有讓他失去創造軟體的樂趣，反而讓他感覺自己更接近真正想完成的事情。

當程式碼不再是創造軟體最大的門檻，真正重要的能力，將是知道自己想創造什麼，以及如何利用 AI 將它實現。

參考訪談與資料

本文是 Boris Cherny 的觀點與使用經驗整理，並非逐字稿。涉及產品功能、指令、模型版本、工作階段及 PR 數量，均以相關發言發生當時為準。任何實際操作都應再對照目前版本的官方文件與環境權限。

• Boris Cherny：個人 Claude Code 工作配置（2026 年 1 月 2 日）（另開新分頁）
• Boris Cherny：來自 Claude Code 團隊的技巧（2026 年 1 月 31 日）（另開新分頁）
• Y Combinator《Inside Claude Code With Its Creator Boris Cherny》（另開新分頁）
• Lenny’s Podcast《Head of Claude Code: What Happens After Coding Is Solved》（另開新分頁）
• Acquired Unplugged《Boris Cherny: Claude Code & the Future of Engineering》（另開新分頁）
• Sequoia Capital：Boris Cherny《Coding Is Solved》訪談（使用者先前保存之中文逐字稿）
• Computer History Museum：《Anthropic’s Boris Cherny, Creator of Claude Code》（使用者先前保存之中文逐字稿）
• Boris Cherny 2026 年 10 月提示詞觀點相關報導（另開新分頁）