超越基礎：Claude Code 進階用法（第 2/4 段）

🧑‍🏫 這段在講怎麼讓 Claude Code 更懂你的專案：與其換更強的模型，不如在它做錯時馬上給回饋，用「提醒」取代「禁止」。後半段講 AI 一次能看的內容有上限，加上快取的成本結構，客製化並不是越多越好。想自己調教 Claude Code 的人，看完就會知道哪些做法會在背後悄悄浪費錢和空間。

• 11:50 Claude 預設沒有 LSP、沒有 code completion，只有 edit tool，必須逐字寫出要取代的字串和新內容。講者比喻這連 Vim 都還沒有，像在用 ED
  ↳ Claude 預設沒有 LSP（背景幫程式即時抓錯的服務），也沒有 code completion（自動補完）。它只能用 edit tool，逐字寫出舊內容和新內容來替換，比 Vim 還原始，像上古的 ED 編輯器。
• 12:20 做客製化時要思考：VS Code、code completion、紅色波浪線，換成 agentic 版本會長什麼樣子
  ↳ agent 是會自己動手做事的 AI。客製化時可以先想人類寫程式靠哪些輔助，例如 VS Code 編輯器、自動補完、紅色波浪線，再問：給 agent 用的版本該長什麼樣子？
• 12:54 紅色波浪線的作用是推你一下、但不擋住你，也可以忽略，只是提醒你再想一次。agent 也需要類似的機制
  ↳ red squigglies 就是紅色波浪線，像 Word 打錯字時出現的底線。它提醒你「這裡怪怪的」，但不擋你繼續打，確定沒錯也可以不理。agent 也需要這種輕輕的提醒。
• 12:54 Post tool use hooks 很適合做這件事，就是 agent 的紅色波浪線（hooks 之後會細講）
  ↳ hooks 是在特定時機自動執行的小程式。Post tool use hooks 會在 Claude 每用完一次工具（例如改完檔案）後觸發，拿來回報問題，就等於 agent 的紅色波浪線。
• 13:27 可以在裡面跑 linters；Claude Code 支援 LSP 連線。這類回饋都能拿來提醒 Claude
  ↳ hook 裡可以跑 linter，也就是自動檢查程式寫法、抓常見錯誤的工具。Claude Code 也能連上 LSP。這些檢查結果都能回報給 Claude，提醒它哪裡可能有問題。
• 13:27 例子：generated file。harness 層級不能硬擋 Claude 編輯它，比較好的做法是提醒它「這是生成的檔案」
  ↳ generated file 是程式自動產生、不該提交進專案的檔案。harness 是包在模型外面、負責執行工具的那層程式，不適合在這層硬擋 Claude 去改，比較好的做法是提醒它「這是自動生成的」。
• 13:58 Claude 改 generated file 可能只是想試試看。收到提醒後，它很可能會記得還原，並把修改放到正確位置；就算忘了，通常也會停下來復原
  ↳ Claude 去改這種檔案，可能只是想先試試效果。收到提醒後，它多半會記得改回來，把修改放到真正該改的地方；就算一時忘了，通常也會停下來自己復原。
• 13:58 要讓 agent 更熟悉你的 codebase，最快的方法不是換更聰明的模型，而是讓 feedback loop 更緊密
  ↳ 想讓 agent 更懂你的專案，最快的方法不是換更聰明的模型，而是讓 feedback loop 更緊密。feedback loop 就是「做完、馬上知道對錯、立刻修正」這個循環。
• 14:28 這些大多是你本來就有的腳本（當初為了讓人類開發者編輯 codebase 而準備的），只要正確接上就好，不必重新發明輪子
  ↳ 這些檢查工具你多半早就有了，是當初為了讓人類工程師好改程式而寫的腳本。只要把它們正確接給 Claude 用就好，不必重新做一套。
• 14:28 工具分兩種：用來彌補智能不足的工具，以及隨智能提升而更有價值（scale with intelligence）的工具
  ↳ 工具分兩種：一種是補模型不夠聰明的拐杖；另一種叫 tools that scale with intelligence，意思是模型越聰明越能善用、價值也越高的工具。
• 14:59 紅色波浪線屬於第二種：它是可以被推翻的提醒。你知道它判斷錯了，就可以繼續做下去
  ↳ 紅色波浪線屬於第二種。它只是提醒，可以被推翻：模型越聰明，越能判斷「這次提醒是誤判」，然後照自己的判斷繼續做。
• 15:29 反例：硬性禁止 Claude 使用沒在別處定義過的變數。理論上錯誤會變少，但會逼 Claude 照特定順序寫程式，結果不會好，也無法隨智能提升
  ↳ 反例是硬性規定「沒定義過的變數不准用」。看起來能減少錯誤，卻會逼 Claude 照固定順序寫程式，結果反而變差；模型再進步，也一樣被這條規則綁住。
• 15:29 講者問 Claude 有哪些工具不該給它，Claude 回答「我不喜歡你們拿走我的工具」
  ↳ 講者問 Claude 哪些工具不該給它，Claude 回答「我不喜歡你們拿走我的工具」。這呼應前面的看法：拿走工具、硬性限制，通常不是好方向。
• 16:00 AGI-pilled 的做法是挑選隨智能提升的工具：模型越強，這些工具對模型越有用
  ↳ AGI-pilled 指深信 AI 會一直變強的思維。照這個思路，就該優先挑會隨模型變強而更好用的工具，這樣模型一升級，你的設定也跟著發揮更大作用。
• 16:30 Claude Opus 4.7 的 context window 通常約 1 million tokens
  ↳ context window 是模型一次能看到的內容上限，就像它的工作記憶。Claude Opus 4.7 通常約 100 萬個 token；token 是模型計算文字用的小單位。
• 17:02 context window 的大小其實沒有在成長。模型進步很多，但 context window 大小相對固定，所以 context engineering 要面對的是一個固定目標
  ↳ 模型能力進步很多，context window 卻沒什麼在變大。context engineering 就是規劃要把哪些資訊放進去，而它面對的是一個大小固定的空間。
• 17:35 讓輸出變好的手段是 in context learning，所以每一項客製化都必須以某種形式進入 context window
  ↳ 模型靠 in context learning 變好用，也就是從你放進對話的資料現學現用。所以不管是規則還是工具說明，任何客製化最後都得進到 context window 裡才會生效。
• 17:35 不能把整個 codebase、Wiki 或所有內部文件都塞進 context window，要想辦法在對的時間放進對的資訊
  ↳ 你不可能把整個專案的程式碼、Wiki、所有內部文件都塞進去，只能在需要的時候，放進剛好需要的那些資訊。
• 18:08 比喻：像在 Arduino 上跑 NPM。記憶體很少，只能放最重要的東西，而且要用最精簡的版本，留空間給真正的工作
  ↳ 這就像在 Arduino（記憶體很小的電路板）上跑 NPM（很龐大的套件管理工具）：空間很少，只能放最重要的東西，還要用最精簡的版本，把空間留給真正的工作。
• 18:38 「Don't pay for what you don't use」，講者說這句原本出自 C++，就是 zero overhead abstraction principle。在這裡它不是加分項，不能靠多丟算力解決
  ↳ 「用不到的東西就不該付出代價」這句話，講者說出自 C++，叫 zero overhead abstraction principle。他強調這在這裡是硬性要求，不能靠多砸算力解決。
• 19:08 context window 大小看起來已經到極限、不會再變大，所以要更有效率地把資訊放進模型，唯一的辦法就是不為用不到的東西付出代價
  ↳ 既然 context window 看起來不會再變大，要更有效率地把資訊交給模型，唯一的辦法就是不讓用不到的東西佔位置、花成本。
• 19:38 直覺上會想用快取的做法（例如 L1 cache 把最近沒用到的東西移出），但還有另一個限制：KV cache，它很大程度決定了算下一個 token 的成本
  ↳ 直覺會想學電腦的快取，把最近沒用的東西移出去。但還有 KV cache 這個限制：模型會把讀過的前文算好存起來重複使用，它很大程度決定了算下一個 token 的成本。
• 20:10 如果改動 prompt 很前面的內容，從那裡以後整個 context window 都變成 uncached tokens，每個 token 的成本是十倍
  ↳ 如果改到 prompt 很前面的內容，從那裡之後的全部內容都得重算，變成 uncached tokens（沒用到快取的 token），每個 token 的成本是十倍。
• 20:10 所以不能從 tools block 移出沒用到的工具、換進新工具，因為那樣會讓後面整段 cache 失效
  ↳ 所以不能把前段工具清單裡沒用到的工具拿掉、換新的進來。只要一動到前面，後面整段快取都會失效，成本馬上暴增。
• 20:46 早期的 agentic 客製化有些採用類似 LRU cache 的做法。在 32,000 token context window、token 都很貴、KV caching 還不夠有效率的年代比較合理，但現在這些條件都不成立了
  ↳ 早期有人用 LRU cache 管理客製化，也就是把最久沒用的東西踢掉。當時 context window 只有 32,000 token、token 很貴、KV 快取也不夠有效率，這樣做合理；現在這些條件都不成立了。
• 21:18 為了省一點 context window 而付大量昂貴 token 並不划算。穩定、共用的內容放在最前面，每個任務會變動的資訊放在靠近尾端，要移出時成本才低
  ↳ 為了省一點空間卻付一大堆昂貴的 token，並不划算。穩定、共用的內容放最前面；每個任務才會變動的資訊放在後面，要移出時成本才低。
• 21:18 這個問題很複雜，離解決還很遠，是 Claude Code 團隊每天都在思考的事
  ↳ 這個問題很複雜，離解決還很遠，是 Claude Code 團隊每天都在思考的事。
• 21:49 用大規模軟體工程和 monorepo 的角度檢視 plugin 抽象：每一種如果有 10,000 個、100,000 個會怎樣
  ↳ monorepo 是把整間公司的程式碼放在同一個大倉庫；plugin 是 Claude Code 的擴充套件。講者從這種大規模的角度檢驗 plugin 設計：每種東西如果有一萬、十萬個，還撐得住嗎？
• 21:49 現在已經有公司的 monorepo 裡有數萬到數十萬個 skills，因此碰到了擴展上的瓶頸
  ↳ 這不是空想。已經有公司的 monorepo 裡有數萬到數十萬個 skills（寫給 Claude 的做事說明包），因此碰到了擴展上的瓶頸。
• 22:19 要檢視的四個 plugin primitives：MCP、skills、hooks、agents。plugin spec 還有其他客製化點，這次不談
  ↳ 要檢視的四種 plugin primitives，也就是外掛最基本的積木：MCP、skills、hooks、agents。plugin 規格裡還有其他客製化方式，這次不談。
• 22:51 這些思考在不同的客製化方式之間大多通用
  ↳ 接下來對這些積木的分析思路，大多能通用在不同的客製化方式上，不必每一種都從頭想起。
• 22:51 關於 MCP，最重要的是：它設計於 agents／LLMs 簡單得多的年代，最初主要是給 chat bots 用的
  ↳ MCP 是讓 AI 連上外部工具和資料的標準介面。它最關鍵的背景是：設計於 LLM（大型語言模型）還簡單得多的年代，一開始主要是給聊天機器人用的。
• 23:22 chat bot 通常跑在 serverless 環境、不在 container 裡，沒辦法存取你電腦上的檔案、執行指令或使用 CLI
  ↳ 聊天機器人通常跑在 serverless 環境，也就是雲端需要時才執行、沒有自己固定的機器，也不在 container（隔離的執行空間）裡，所以碰不到你電腦的檔案，也不能下指令或用 CLI（命令列工具）。

根據影片，如果改動了 prompt 很前面的內容，之後的 context window 會變成 uncached tokens，這些 token 的成本大約是多少？