Claude Code 開發者建議：先問 codebase，再改碼
Claude Code 開發者 Boris 的實用階梯：先 codebase Q&A 再改碼；先計畫與自檢迴圈；用短 CLAUDE.md／MCP／企業設定共享脈絡；進階把 claude -p 當 Unix 工具、worktree 平行。
Claude Code 不是「再強一點的行級補全」。用它的人裡，有一半的挫折來自把舊工具的用法套在新物種上：一打開就丟三千行需求、一失敗就怪模型笨，或是期待它取代 IDE 與整套工作流。
Anthropic 技術團隊、Claude Code 開發者 Boris 的一場實用分享，幾乎不談歷史與理論，只給可跟做的順序。核心非常樸素：
先問程式碼庫，再改程式碼。
給工具讓它自己串；給回饋迴圈讓它自己迭代。
把團隊脈絡寫進可共享的設定，而不是每次重講。
本文整理那套階梯，並對齊「模型無狀態、狀態在 harness」的視角：你養的是環境與習慣，不是模型腦內的永久記憶。
它是什麼、不是什麼
| 舊世代 AI 寫 code | Claude Code |
|---|---|
| 一次補一行、幾行 | 代理式：整功能、整檔、整段 bug |
| 常綁死某一 IDE | 不強迫換工具：VS Code、JetBrains、Xcode、Vim、SSH、Tmux 都能用 |
介面刻意自由——有時只有一個提示列——因此新手會愣住：「我到底該輸入什麼？」產品選擇不強推單一工作流，因為工程師的用法本就不該被鎖死。代價是：你要自己建立階梯，而不是等精靈帶你。
實用的初次設定包括：Shift+Enter 換行、/theme、GitHub 整合（issue／PR 裡呼叫 Claude）、把常按「允許」的工具寫進規則，以及用系統聽寫說話下 prompt——具體得像在跟另一位工程師溝通，而不是寫謎語。
第一階：Codebase Q&A（強烈建議的起點）
Boris 對「第一次用、或帶團隊上手」的建議幾乎是硬規則：
不要一開始就改碼，不要一開始就上花俏整合。先問 codebase。
在 Anthropic，技術新人第一天就裝好 Claude Code，然後對 repo 提問。過去技術入職大約兩到三週；口述中，現在可壓到大約兩到三天——因為探索與「去哪裡找人問」的成本被大幅吃掉。
為什麼這樣設計也保護你
- 不做遠端程式碼索引、不把庫丟上遠端資料庫等你建完
- 宣稱不以你的 code 訓練生成模型
- 零等待索引：下載、啟動、立刻問
你仍掌控本機檔案；agent 是來探索，不是先把智慧財產送進黑盒倉庫。
值得問的問題類型
- 這段程式怎麼被呼叫？這個類別怎麼實例化？
- 答案應像 wiki／文件層級，而不只是 Command-F 字串命中
- Git 歷史：為什麼這函式有十五個參數、命名奇怪？——它會查 log、作者、關聯 issue（系統提示不必教「用 git」，模型自己會）
- GitHub issue 脈絡（搭配抓取）
- 站會用：「我這週交付了什麼？」——依使用者與 log 整理成可貼文件的清單
Q&A 真正訓練的是：提示詞邊界——什麼一次能成、什麼要兩輪、何時該自己進 REPL。摸清能力地圖之後，再進入編輯，翻車率會低很多。
第二階：改碼——少指定工具，多指定工作流
Claude Code 給的工具集刻意精簡：編輯、bash、搜尋等。你通常不必寫「請用 read 再 edit」；說清楚要完成的事，它會自己串。
三個高槓桿工作流：
1. 寫碼前先計畫（不必迷信模式名稱）
「先腦力激盪／擬計畫，給我過目，同意再寫。」
不必一定開啟某種正式 Plan UI——用自然語言下約束即可。一次丟巨大功能而不對齊意圖，有時會一次過、有時會完全不對；最便宜的修正是先對齊計畫。
2. 口令級交付
例如 commit、push、開 PR。模型會看歷史與 commit 風格，自行分支與推送。你要的是可審查的交付物，不是自己當人肉 git 手冊。
3. 自檢迴圈（效果往往最誇張）
當 agent 有辦法看見自己的產出時，品質會跳級：
- 跑單元測試並修到綠
- Puppeteer／模擬器截圖對設計稿迭代兩三次
原則：給回饋通道（測、截圖、日誌），它會自己收斂。領域不限前端——任何「可觀察結果」都能當迭代訊號。
把團隊既有 CLI 與 MCP 接上之後，新進人員進庫就能沿用同一套工具；常用指令與 MCP 用法再寫進共享 CLAUDE.md，跨 session 不必重教。
脈絡階層：寫一次，全隊吃紅利
工程師腦中的系統史、慣例與雷點，模型開箱沒有。注入方式很多，Boris 建議從共享專案脈絡開始——網路效應最大：
| 載體 | 用途 |
|---|---|
| 專案 CLAUDE.md（根目錄、簽入） | 每次 session 自動進上下文；團隊共用 |
| 本機 CLAUDE.md | 個人偏好與指令，不簽入 |
| 巢狀目錄 CLAUDE.md | 在子樹工作時按需載入 |
| 企業級政策 | 跨 repo 共用；可強制允許／封鎖指令與 URL |
斜線指令（.claude/commands） |
可重複流程；也能給 CI／GitHub Action 跑 |
| MCP 設定簽入 | 進庫即提示安裝；例如共享 Puppeteer 做 E2E |
CLAUDE.md 要短：常用 bash、風格、幾個核心檔案與架構決策。太長只消耗上下文，邊際效益差。
/memory 可檢視目前載入哪些層；# 記住某事時可選寫入哪一層記憶檔。
企業設定還能同時「除障」與「上鎖」：全員測試指令自動允許；禁止抓取敏感網域；員工無法用個人設定覆寫公司封鎖——下層不能推翻上層安全邊界。
小快捷鍵，大控制感
終端機產品難發現快捷鍵。幾個高頻：
- Shift+Tab：自動接受編輯（bash 仍可要求確認）——方向對或測試迭代時少點允許
- #：記住偏好／工具用法，併入 CLAUDE.md
- ! + 指令：本機執行 bash，輸出進入下一輪上下文
- Esc：安全中斷當前動作，改指示後繼續（不會弄壞 session）
- Esc 兩次：歷史；resume / --continue：接回 session
- Ctrl+R：看完整輸出（模型實際看見的上下文）
多模態常被忽略：拖曳、貼上或給路徑的設計稿圖片，再搭配 Puppeteer 迭代——終端機裡不好發現，但從一開始就支援。
進階：當 Unix 工具，而不是第二個 IDE
claude -p 與產品共用同一套 SDK：prompt 進、JSON／串流 JSON 出，可 pipe。CI、事件應變、從 Sentry／雲端 log 撈資料再摘要——把它當聰明的 Unix 濾鏡，而不是只能互動聊天。
重度使用者常見：SSH／Tmux 掛長 session；同一 repo 多份 worktree 或 checkout 平行多個 Claude。官方也在降低這條路徑的摩擦。方向很清楚：平行與管線化，比單一聊天窗堆更久更重要。
為什麼先做 CLI 而不是 IDE？
Boris 給兩個工程組織理由：Anthropic 內部 IDE 分裂（VS Code、Zed、Xcode、Vim、Emacs…），終端是最大公約數；以及近距離看模型進步速度——過度投資 IDE 殼層，可能很快折舊。這是產品賭注，不是貶低 IDE；重點是 harness 優先於 chrome。
內部約八成技術人員每天使用（口述）——含研究人員用 notebook 工作流——產品手感來自真 dogfood。
最難的產品問題：Bash 既危險又不可少
Q&A 裡，最難實作之一是 bash 安全與生產力的拉鋸：每條指令都手點批准會殺效率；完全放行又太危險。路線是唯讀分析、靜態判斷可安全組合的指令、分層 allow／block，並適配「不是人人都在 Docker 裡跑」的真實環境。
這再次印證 harness 文的命題：模型可以提出 tool call；是否執行由環境與政策決定。
可執行的一週階梯
- Day 1–2：只做 Q&A（結構、git 史、issue、本週交付）。
- Day 3：小改動；強制「先計畫再寫」至少一次。
- Day 4：接一個自檢通道（測試或截圖迭代）。
- Day 5：簽入短 CLAUDE.md；列出 3 個常用指令與 1 個 MCP。
- 之後：權限白名單、
#累積偏好；需要時把claude -p接進 CI。
帶團隊時，用同一階梯當 onboarding，比丟一份「提示詞大全」有效。
結語
Claude Code 的槓桿，不來自把工程師變成提示詞術士，而來自正確的使用順序與環境設計：用問答建立心智模型與提示邊界，用計畫與自檢約束代理式修改，用可共享的 md／MCP／政策把個人技巧變成團隊資產，再用 SDK 與平行 session 把互動升成基礎設施。
先問 codebase，再改碼。
先給回饋通道，再追求一次完美。
先寫短而共享的脈絡，再談個人奇技。
模型會繼續變強；會不會變成你團隊的預設同事，取決於你有沒有把階梯鋪好。
延伸閱讀
- Claude Code 為什麼有效：模型無狀態，狀態在執行環境
- 從 CLAUDE.md 到「做夢」：上下文工程如何把模型智力變成可用系統
- AI 加速的是軟體熵：用深度模組與戰略工程師救程式碼庫
- 從聊天框到本機執行：非工程師的 AI 飛輪
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。