這篇導讀整理自 Anthropic 的原始影片。主講者 Boris 是 Anthropic technical staff 成員，也是 Claude Code 的建立者之一。影片標題說「30 分鐘掌握」，但它真正值得記下的不是某幾個快捷鍵，而是一套從個人 terminal 延伸到團隊工程系統的使用模型。
010. Claude Code 不是補完工具｜它把 terminal 變成 agent 工作台
Boris 一開場就先把 Claude Code 和早期 coding assistant 區分開來。過去的主流體驗是「補完」：補一行、補幾行，或根據游標附近上下文提供建議。Claude Code 的定位不同，它是 fully agentic 的 coding tool，目標是處理整個 feature、整個 function、整個檔案，甚至一個完整 bug 的探索、修改與驗證。
這個定位會改變使用者對工具的期待。若把它當 autocomplete，焦點會落在單次輸出是否漂亮；若把它當 agent，真正要設計的是它如何理解任務、探索 codebase、選工具、提出計畫、寫入檔案、執行測試、讀取錯誤，再回到下一輪修正。Claude Code 的產品形態是 terminal，但它想承接的是工程師完整的工作循環。
Boris 也特別強調，Claude Code 不要求使用者換掉既有工作流。它可以在 VS Code、Xcode、JetBrains、Vim、remote SSH、tmux 或任何 terminal 裡跑。這點看似只是相容性，實際上是產品哲學：如果 agent 要進入工程工作，它最好先貼近既有工具鏈，而不是要求團隊為了 AI 重建所有開發環境。
這也解釋了為什麼第一次打開 Claude Code 時，只會看到一個自由輸入的 prompt bar。它不是缺少 onboarding，而是刻意不像傳統 IDE plugin 那樣規定單一路徑。代價是新手會困惑：「我到底該問什麼？」Boris 的回答很實際：不要一開始就要求它改 code，也不要急著玩進階工具，先從 codebase Q&A 開始。
021. 先問 codebase｜最好的第一步不是讓 AI 寫 code
整場 talk 最可操作的建議，是把 Claude Code 的第一用途放在 codebase 問答。Boris 說 Anthropic 在 technical onboarding 會讓新人第一天就安裝 Claude Code，然後直接開始問 codebase 問題。過去新人需要不斷打擾 team members、讀文件、摸工具、翻程式碼；現在可以先把許多探索型問題交給 Claude Code。
他舉的問題很樸素：「這個 class 怎麼被 instantiate？」「這段 code 在哪裡被使用？」「這個 function 為什麼有 15 個 arguments？」好的地方在於，Claude Code 不只做文字搜尋。它會沿著呼叫點、使用範例、git history、GitHub issues 和 commit 脈絡往下挖，整理出接近內部 wiki 的答案。
這裡有兩個價值。第一，Q&A 讓新人更快建立 mental model。程式碼不是一堆檔案，而是有歷史、責任邊界與使用慣例的系統；能問 git history 和 issue，就能把「現在長這樣」連回「為什麼變成這樣」。第二，Q&A 是低風險的 prompt 練習。新手可以在不改檔、不破壞分支的情況下，理解 Claude Code 擅長什麼、需要多具體、哪些問題可以 one-shot，哪些要拆成多輪。
Boris 提到 Anthropic technical onboarding 從兩到三週縮到兩到三天。這是講者對 Anthropic 內部狀況的說法，不能直接推廣成所有公司都能同幅縮短；但作為方向，它點出一個合理的導入策略：先讓 agent 成為 codebase tour guide，而不是立刻變成自動開發者。
這也比「請 AI 幫我寫一個功能」更能保護團隊品質。對陌生 codebase 的第一次修改，最容易錯在不知道系統慣例、測試策略、歷史包袱和隱性約束。先問問題，等於先讓 agent 和人一起補齊背景，再談實作。AI coding 的第一步不是加速打字，而是降低理解成本。
032. 讓 agent 可靠交付｜探索、計畫、編輯、測試、迭代
當使用者熟悉 Q&A 後，下一步才是 editing code。Boris 說 Claude Code 其實只有一組很小的工具：編輯檔案、執行 bash、搜尋檔案等。它的能力不來自工具數量，而來自能把工具串成迴圈：探索程式碼、形成計畫、修改檔案、執行命令、讀取結果，再繼續修。
所以，大型任務的 prompt 不應該只寫「實作這個 30,000 行 feature」。Boris 建議先要求它 brainstorm、make a plan，並在寫 code 前先讓人批准。這句話的價值不在語法，而在流程控制：把 agent 的自由度分階段釋放。先讓它想，再讓人校準方向，最後才讓它動檔案。
他也提到一個常用指令「commit push」。Claude Code 會看 git log、理解 commit format、建立 commit、push branch，甚至開 pull request。這種能力不是因為產品把每個步驟都寫死，而是模型懂工程慣例，並能在工具允許下完成整個例行流程。換句話說，Claude Code 的強項不是單一步驟，而是把工程師熟悉的流程用自然語言包起來。
不過，可靠性不該只靠模型自信。Boris 最重要的補充是：給 Claude Code 一種檢查自己工作的方式。對後端可能是 unit test 或 integration test；對前端可能是 Puppeteer screenshot；對 iOS 可能是 simulator。只要它能觀察結果，就能迭代兩三輪，把初稿變成更接近交付品質的成品。
這是 AI coding 從 demo 走向 production 的核心差異。沒有 feedback loop 時，agent 只能憑生成時的推理猜測結果；有測試、截圖和工具輸出時，agent 才能把錯誤當作下一輪輸入。真正有效的 prompt，不只是「做什麼」，還要把「怎麼知道做對了」交代清楚。
043. 團隊工具才是槓桿｜CLI、MCP 與既有工作流
Boris 接著把視角從個人使用推到團隊工具。他把工具分成 batch tools 和 MCP tools。batch tools 可以是團隊本來就有的 CLI；如果不確定怎麼用，可以讓 Claude Code 先跑 --help。MCP tools 則讓 Claude Code 接上更結構化的外部能力。重點不是追逐最新整合，而是把團隊已經依賴的操作介面交給 agent。
這一點容易被低估。很多團隊導入 AI coding 時，會先問「哪個模型最會寫 code？」但真正影響日常效率的，常是 agent 是否能理解本地測試、內部部署腳本、資料查詢工具、issue workflow、設計文件和權限規則。若這些工具只存在人腦或 Slack 記憶裡，agent 就只能在表層工作；若它能被教會如何使用，agent 才能進入真實工程流程。
Boris 的建議是，如果某個工具常用，就把用法寫進 CLAUDE.md。這代表工具知識不再只靠每次 prompt 臨時重講，而是成為 repo 的共享 context。當團隊把「如何跑測試」「如何查 staging log」「哪些 command 可用」「MCP server 怎麼接」寫成可讀、可版本控制的指引，Claude Code 的品質會隨團隊知識庫一起提升。
這裡也要保留界線。把工具交給 agent，並不表示所有命令都應該自動允許。Boris 在 Q&A 裡說，bash safety 是 Claude Code 實作中最難的部分之一，因為 bash 既強大又危險；若每個 command 都要人工批准，效率會崩，但若放太寬，又可能改變系統狀態。Claude Code 因此需要 read-only 判斷、static analysis、allowlist、blocklist 和分層 permission。
這提醒我們，AI coding 的團隊化不只是加工具，也是加治理。工具越多，能力越大；能力越大，越需要清楚的 permission boundary。好的 setup 應該讓日常安全操作順暢，同時讓高風險操作停下來問人。
054. Context 是產品介面｜CLAUDE.md 不只是提示詞
影片中段談到 context，是我認為最值得團隊照抄的部分。Boris 說，工程師在 codebase 中工作時，腦中有大量背景：架構、歷史、慣例、重要檔案、常用 command、測試方式、style guide。Claude Code 若沒有這些，只能從檔案表面推理；若把這些 context 給它，它就能做出更貼近團隊的決策。
最簡單的入口是 project root 的 CLAUDE.md。它會在 session 開始時自動讀入，可以放常用 bash commands、MCP tools、architecture decisions、重要檔案與風格規則。Boris 也提醒要保持短，因為過長的 context 會吃掉模型注意力和成本，反而降低效果。
CLAUDE.md 的真正意義，不是「把 prompt 寫在檔案裡」，而是把團隊工作知識變成可共享介面。當一位工程師把某個操作流程整理好，其他人和 Claude Code 都能受益。這和傳統文件不同：它不是只給人看的 wiki，而是每次 agent 工作時會直接進入決策循環的 operational context。
Context 還可以分層。project context 針對特定 repo；local context 放個人偏好，通常不提交；nested CLAUDE.md 只在特定子目錄工作時載入；slash commands 封裝常見任務；MCP JSON 描述工具 server；enterprise policy 則由公司統一推出，用來設定允許或封鎖的操作。
這種分層很像工程組織本身。穩定、全公司適用、安全相關的東西放底層；專案慣例放 repo；個人偏好留在 local；臨時或具體任務用 @ mention 檔案補進來。好的 context engineering，不是把所有東西塞進最大 prompt，而是決定哪些資訊應該自動載入、哪些按需載入、哪些永遠不該載入。
065. SDK 把 Claude Code 推進流水線｜從聊天到 Unix-style utility
影片後段談 Claude Code SDK。Boris 說，使用 claude -p 時，其實就是在用 SDK；Claude Code 自己也建立在同一套 SDK 上。它可以收 prompt、allowed tools，並輸出 JSON 或 streaming JSON。這讓 Claude Code 不只是互動式 terminal assistant，也能被放進 CI、incident response 和自動化 pipeline。
這個轉變很重要。聊天介面適合探索，但工程系統需要可組合性。若 claude -p 可以像 Unix utility 一樣吃 stdin、吐 JSON，那它就能接 git status、log、Sentry CLI、GCP bucket 或其他資料來源，再把結果交給下游工具。AI 不再只是「人問一句、它答一句」，而是工程流水線中的智慧節點。
Boris 說 Anthropic 會在 CI 和 incident response 中使用這種方式。這些場景的共同點是資訊多、格式雜、需要快速形成判斷，但又最好能保留機器可讀輸出。JSON / streaming JSON 讓 agent 的推理結果能被程式處理，也讓後續自動化不必解析一段自由文本。
他最後還提到 power users 的平行工作模式：SSH sessions、tmux tunnels、多個 repo checkout、git worktree。這代表 Claude Code 的使用上限不是「一個人在 terminal 裡問一個 agent」，而是多個 isolated sessions 同時處理不同任務。當 agent 能用 worktree 隔離修改、用測試檢查結果、用 PR 回到人類 review，AI coding 才更像可管理的工程生產線。
當然，這也會帶來新的協調問題。平行 sessions 需要分支策略、任務切分、衝突處理、測試資源和 review 節奏。Boris 沒有把這些說成已解決，只是指出 Anthropic 內部 power users 已經往這個方向走。對一般團隊來說，合理起點可能不是一口氣開十個 agents，而是先讓一個 agent 在一個 worktree 裡完整走完探索、計畫、實作、測試、PR。
076. 這場 talk 真正教的是邊界管理｜自由度要配上 context 和 feedback
把整場 talk 串起來，Claude Code 的使用方式其實是一套邊界管理。第一層邊界是任務：先 Q&A，再改 code；大型任務先 plan，再批准。第二層邊界是工具：給 agent 足夠工具，但用 permissions 控制風險。第三層邊界是 context：把團隊知識放進 CLAUDE.md、slash commands、MCP JSON 和 policy，但避免把所有東西塞進 prompt。第四層邊界是驗證：用測試、截圖、simulator 或 pipeline output 讓 agent 能看見結果。
這也解釋了為什麼 Claude Code 選擇 CLI 而不是先做完整 IDE。Boris 在 Q&A 裡說，Anthropic 內部使用的 IDE 很分散，terminal 是共同分母；他也判斷模型進步很快，傳統 IDE layer 可能不值得過度投資。這句話帶有產品立場，但它讓 Claude Code 的設計更清楚：不是在既有 IDE 上加一個 AI 面板，而是把 agent 放進工程師所有工具都能觸及的最低共同介面。
對團隊而言，這場 talk 的可行 takeaway 很簡單。第一，讓新人用 Claude Code 問 codebase，先建立理解。第二，把常用命令、架構脈絡和工具用法寫進 repo 的 CLAUDE.md。第三，為 agent 提供可自我檢查的 feedback loop。第四，將高風險命令用 permission policy 管住。第五，當互動式使用穩定後，再把 claude -p 和 SDK 放進 CI、incident response 或週報整理等流水線。
這些做法看起來不炫，卻比「讓 AI 幫我多寫 code」更接近實際生產力。因為工程的瓶頸很少只是打字速度，而是理解、協調、驗證、回饋與風險控制。Claude Code 的價值，不在於把工程師從流程中移除，而在於把工程師已經知道的好流程，轉成 agent 能遵循、能檢查、能累積的工作介面。