精通 Claude Code：從提示到可程式化工程

對許多人而言，Claude Code 被用作高階自動完成——一種在輸入提示後接受建議的工具。然而，隨意使用與將 Claude Code 視為可程式化代理之間有巨大的差異。當內化後，該工具會從一個提示後等待的聊天機器人轉變為具備記憶、自訂指令以及隨時間累積價值的專案設定的自主系統。

要超越基礎，必須停止逐行指導模型，而開始委派任務。核心哲學，由 Boris Cherny 與 Anthropic 團隊倡導，是 給予 Claude 檢驗自身工作的方式。透過建立確定性的回饋迴路——例如執行測試套件或 lint 指令——Claude 能夠自行迭代，直至解決方案真正可行，從而使輸出品質提升 2 至 3 倍。

策略工作流程：探索、規劃、執行

高效能使用者避免直接跳入程式碼。相反地，他們遵循有紀律的順序：

  1. 探索： 使用 Plan 模式（Shift+Tab 兩次）進行唯讀探索。追蹤資料流並在不修改檔案的情況下了解模型。
  2. 規劃： 產生技術計畫。對於複雜變更，常見的高階使用者模式是讓一個 Claude 工作階段撰寫計畫，然後由第二個全新的工作階段以「資深工程師」的身分審查，以消除上下文偏見。
  3. 執行： 只有在計畫經過審核（並可能透過編輯器中的 Ctrl+G 進行微調）之後，才開始實作。

在整個過程中，精確性是關鍵。與其描述模組，不如直接引用（例如 @src/auth/login.py）。當發生錯誤時，直接將其導入會話：cat error.log | claude。

使用 .claude 目錄進行工程記憶

Claude Code 採用分層設定系統，將專案特定需求與個人偏好分離。此系統透過 .claude/ 目錄管理。

CLAUDE.md 的角色

CLAUDE.md 是專案代理記憶的核心。它會在每個工作階段開始時載入。最有效的 CLAUDE.md 檔案簡潔且聚焦於建置指令、型別檢查流程以及專案特有的「陷阱」。

對於累積工程效益而言，一個關鍵習慣是讓 Claude 撰寫自己的規則。當模型犯錯時，提示應為：「更新 CLAUDE.md，使你不再重複此錯誤。」 隨著時間推移，這會將檔案轉變為代碼庫中所有架構怪癖與常見陷阱的精選清單。

透過 CLAUDE.local.md 進行個人化

雖然 CLAUDE.md 透過 git 共享，CLAUDE.local.md 則為私有。這是匯總 PR 評審回饋的理想位置。透過記錄人類審查者的重複挑剔，你可以確保 Claude 在未來的迭代中套用這些特定偏好，實質上自動化你在專案中的專業成長。

擴展專業：技能與子代理人

技能作為可重用的專業知識

技能是可重用專業知識的單位，定義於 .claude/skills/<name>/SKILL.md。與簡單指令不同，技能可以捆綁模板、參考文件，以及內嵌的 shell 指令（使用 ! 前綴）。

技能的主要優勢包括：

  • 漸進式揭露： 初始僅載入說明；完整指令僅在呼叫技能時載入。
  • 明確控制： 使用 disable-model-invocation: true 可確保高影響力的技能（如部署用的 /ship）僅在使用者明確呼叫時執行。

子代理人用於上下文隔離

子代理人在其獨立的上下文視窗中執行，允許它們處理大量資料（例如閱讀五十個檔案）而不污染主會話。這對於 Writer/Reviewer 模式 特別有力：Session A 實作功能，然後 pr-review 子代理人在全新上下文中評估工作，避免實作偏見。

透過模型上下文協議 (MCP) 獲得系統感知

MCP 將 Claude 從編碼代理轉變為具系統感知的代理。透過連接外部伺服器，Claude 能直接從終端與 GitHub、Sentry、Linear 與 Figma 等工具互動。

一種進階實作是使用 Obsidian MCP 的 三層記憶體架構：

  1. 熱儲存： 每日會話日誌，捕捉原始進度。
  2. 溫儲存： 專案特定的筆記與目標。
  3. 冷儲存： 長期的架構決策紀錄（ADRs）與可重用的知識原子。

進階指令與自動化

除了基本互動外，幾個未被充分利用的指令能顯著提升生產力：

  • /rewind：將會話還原至先前的檢查點，避免在路徑走入死胡同時污染上下文。
  • /goal：設定確定性的完成條件（例如「test/auth 中的所有測試通過」）。結合 auto-mode 與 /focus，使用者可設定短期目標並離開，直至目標達成。
  • /batch：將任務分散至多個 git 工作樹的平行代理，實現大規模遷移且手動負擔最小。

批判性觀點與權衡

雖然生產力潛力很高，社群對「代理」方法仍有分歧。一些開發者認為維護 .md 檔案與協調子代理人的開銷會產生「意外複雜度」，且 AI 應該本身就能理解程式碼庫，而不需要如此手把手的協助。

另一些人則指出「SaaS 鎖定」的風險，即專案的智慧被困在特定工具的設定中。亦有明顯的張力在於生成速度與模型品質之間；許多高階使用者偏好較慢且更審慎的 Opus 輸出，而非較小且較快的模型，以減少修正所花的時間。

最終，轉變是從 使用 工具到 操作 系統。最成功的使用者是將設定——規則、技能與驗證迴路——視為主要工程任務，將執行交由代理的人。

Sources