Caching、harness 與 advisor：在 GitHub 規模下用 Claude 打造產品（第 1/2 段）

🧑‍🏫 GitHub 產品長分享他們每天大量呼叫 Claude 的實戰心得。重點是怎麼靠 prompt caching 大幅壓低成本，以及新模型推出時怎麼用數據決定要不要換。值得看的原因是有真實數字，還打破了「長 context 一定比較貴」的直覺。

• 00:58 講者是 GitHub 的 Chief Product Officer Mario Rodriguez，這次是他再度來到 Code with Claude 大會
  ↳ 講者是 GitHub 產品長 Mario Rodriguez，這是他第二次到 Code with Claude 開發者大會演講。內容是大公司的第一手經驗，不是紙上談兵。
• 01:29 他要分享 GitHub 在這個平台上運行 Copilot 和所有 inference 時最重要的做法
  ↳ Copilot 是 GitHub 的 AI 寫程式助手。inference 指模型每次收到問題、算出回答的過程。他要講的是 GitHub 大量呼叫 Claude 時最關鍵的做法。
• 01:29 GitHub 的願景：為開發者提供最好的工具，藉此推動人類進步
  ↳ GitHub 把自己定位成替工程師做工具的公司。他們相信工具好用、工程師做事快，整個社會的進步也會跟著加速。
• 01:59 客戶想達成的成果：讓開發者保持 flow、讓團隊提升 velocity、用現有人力做到更多，而且要能規模化
  ↳ flow 指工程師專心、不被打斷的狀態。velocity 指團隊交付成果的速度。客戶要這些，而且要整間公司都做得到，不是只有少數人。
• 01:59 要做到規模化，需要效率（efficiency）和信任（trust）；幾乎每個產品決策都建立在這幾個支柱上
  ↳ efficiency 是用更少的錢和資源做到同樣的事，trust 是大家敢放心使用。GitHub 做產品決定時，幾乎都會回頭檢查有沒有顧到這兩點。
• 03:03 GitHub 對平台送出的訊息量高達數十億，長期累計可能到數兆；做法幾乎每週都在變，所以他分享的是「關鍵心得」，不說是最佳實踐
  ↳ 量大到這種程度，任何小改動都會被放大。做法也變得很快，這週有效的方法下週可能就改了，所以他只說是心得，不說是標準答案。
• 03:03 分享分成三部分：一、prompt caching；二、advisor model（advisor 與 critic 兩種角度）；三、新模型推出時怎麼做決策
  ↳ prompt caching 下面會解釋。advisor model 是讓模型在適當時機給建議的機制，critic 則是負責挑錯的角色。第三部分講新模型出來時怎麼選。
• 03:33 沒有 prompt caching 不至於活不下去，但花的錢會多非常多；效率只要提升 1% 就差上百萬，他比喻成高頻交易
  ↳ prompt caching 是把每次重複送出的開頭內容存起來，下次直接沿用，不用重算，所以比較便宜。量這麼大，省 1% 就是上百萬，跟高頻交易一樣錙銖必較。
• 04:04 GitHub 和 Anthropic 合作開發相關能力，目標是在對的時間，讓客戶用到對的 inference、對的智慧程度
  ↳ 兩家一起開發功能，目的是讓使用者在需要時用到剛好夠聰明的模型。簡單的事不必動用最貴的，難題才派最強的上場。
• 04:04 新模型推出得很頻繁，可能週六早上 5 點接到電話說週二要上線；得決定哪個模型當預設才能讓開發者保持 flow，以及怎麼 route 到合適的智慧程度
  ↳ 模型更新又快又突然，GitHub 得很快決定預設用哪一個。route 是把不同請求自動分派給適合的模型，這也要一併決定。
• 04:35 Anthropic 上週推出一個 dashboard（GitHub 先拿到預覽），可以看 cache hit ratio 和送到 Messages API 的訊息數量
  ↳ dashboard 是一眼看數字的監控面板。cache hit ratio 是送出的內容有多少比例用到已存的 cache。Messages API 是開發者用程式呼叫 Claude 的入口。
• 05:07 有數據才能做決策，這是第一步；還沒看過這個 dashboard 的人應該去看看
  ↳ 沒有量測就只能用猜的。先看到自己的 cache 命中率和用量，才知道問題出在哪、改了之後有沒有效果。
• 05:37 GitHub 自己的 dashboard 會比較不同模型的差異（delta），例如左邊 Opus 4.6、右邊 4.7，再下一欄是兩者的差
  ↳ delta 就是差值。把新舊模型的數字並排，再算出差多少，換模型之前就能看清楚哪裡變好、哪裡變差。
• 05:37 新模型推出時（有時在 EAP 階段就拿到），會先跑一組 benchmark，例如 terminal benchmark 2，也有自家的 benchmark，然後才上線
  ↳ EAP 是正式發表前讓合作夥伴搶先試用的計畫。benchmark 是標準化的測驗題庫，用來幫模型打分數。公開的和自家的都要跑，過關才上線。
• 06:08 上線後持續追蹤數據，大約 30 天內（有時更快）完成針對該模型的所有優化
  ↳ 上線不是結束，實際使用後才看得出問題。所以他們會邊看數據邊調整，大約一個月內把針對新模型的調校做完。
• 06:08 要規模化運作，cache rate 必須在 90% 以上，通常是 94～96%；如果只有 70%，通常代表有 bug
  ↳ cache rate 就是 cache 命中率，GitHub 要九成以上才算正常。只有七成時，通常不是模型的問題，而是自己程式寫錯，讓 cache 一直用不到。
• 06:38 cache rate 太低時，就要改呼叫模型的方式、組 prompt 的方式和整個 end-to-end 流程
  ↳ end-to-end 指從使用者按下送出到拿回答案的整條流程。命中率低時，就要檢查呼叫方式、prompt 的排法和整條流程，逐一修改。
• 06:38 要把預設模型從 4.6 換成 4.7，必須先了解 cache rate 差多少；這個例子差 1.3%，對 GitHub 來說影響很大
  ↳ 換新模型不能只看聰不聰明，也要看命中率會不會掉。1.3% 看起來很小，但乘上 GitHub 的用量，就是一大筆錢。
• 07:10 就 input 來說，命中 cache 的成本只有 10%，差了 10 倍；一直讓 cache 失效，就等於付 10 倍的錢
  ↳ token 是模型計算文字的單位。input 是送進模型的內容，output 是模型寫出來的內容。input 命中 cache 只收一成費用，一直沒命中就等於多付 10 倍。
• 07:40 要把 dashboard 上的紅字變成綠字靠的是苦功：50% 到 70% 還算容易，70%→80%→90% 以上需要大量工程投入
  ↳ 命中率在前段比較好改，越往上越難。每多幾個百分點，都要花大量工程師時間去找原因、改流程。
• 08:11 心得一：prefix 裡不要放任何動態內容。曾經在 system prompt 放了 UUID，因為一直被重設，整個 cache 都失效了
  ↳ prefix 是每次送出時放在最前面的固定內容，system prompt 是給模型的基本指令。UUID 是每次都不同的隨機編號，放進開頭就讓 cache 全部白費。
• 08:11 cache 的層級順序：system → tools → conversation → 最後送出的訊息；system prompt 要盡可能保持穩定
  ↳ cache 是從頭開始比對的，前面只要一變，後面全部失效。所以越前面的內容越要固定，最常變動的要放到最後面。
• 08:42 心得二：tools。如果動態載入 tools、改到 tools 的 prefix，整段對話的 cache 都會失效
  ↳ tools 是提供給模型使用的功能清單，例如搜尋、讀檔。它排在很前面，對話中途才加入或修改，後面整段對話的 cache 都要重來。
• 09:12 你會大量實驗 skills 和 tools，所以要有很多 regression test，確保沒有影響到 tools
  ↳ skills 是替模型加上的專門能力。regression test 是改完東西後，自動檢查舊功能有沒有被弄壞。常換 skills 和 tools，就要靠它確認沒動到 tools 那段。
• 09:12 心得三：cache affinity。像 Copilot 這種多模型的 harness，客戶可能 Opus→GPT→OSS 模型→再回到 Opus，要確保下一次呼叫 Opus 時仍然有正確的 cache affinity
  ↳ harness 是包在模型外面的那套程式，負責組 prompt、呼叫工具。Copilot 讓人切換不同模型。cache affinity 是切回 Opus 時，仍能接上之前存的 cache。
• 10:13 破除迷思：客戶常問 long context 會不會比較貴？GitHub 的答案是不會
  ↳ long context 指一次放進很長的對話或資料。多數人直覺認為塞越多越貴，但 GitHub 實測後發現不一定。
• 10:13 模擬測試：用同一個模型，較小的 context window 讓平均 compaction 次數變成較大 context window 的 3 倍
  ↳ context window 是模型一次能讀的最大內容量。compaction 是內容塞滿時，把舊對話摘要壓縮、騰出空間。window 小，壓縮次數會變成 3 倍。
• 10:43 input 和 output token 價格差 5 倍，例如 Opus 是 $5／$25；每次 compaction 都要摘要，會產生 4,000 個 output token
  ↳ 模型寫出來的字比讀進去的貴 5 倍，Opus 是每百萬 token 輸入 5 美元、輸出 25 美元。每壓縮一次，模型就要寫出約 4,000 token 的摘要。
• 10:43 compaction 越多，output token 暴增，cache 也會明顯失效，所以反而更貴
  ↳ 壓縮越頻繁，要付的高價 output 越多。而且摘要換掉了舊內容，前面存的 cache 也用不上，等於兩頭多花錢。
• 11:13 結論：context window 較長不代表花更多錢；關鍵是了解 compaction 怎麼做，並依情境替使用者適當管理
  ↳ window 大小不是省錢的關鍵。重點是搞清楚什麼時候壓縮、怎麼壓縮，並依使用情境替使用者管理好。
• 11:13 建議：instrument 你的 cache rate、建 dashboard（至少用 Anthropic 提供的那個），並投入做模型推出前後的 delta 比較
  ↳ instrument 指在系統裡加上量測，把數字記錄下來。先有監控面板，再固定比較換模型前後的差異。
• 11:43 在 cache rate 還沒拉上來之前，其他效率優化都不重要；從 50 幾拉到 70、90，需要大量工程時間
  ↳ 命中率是最大的成本槓桿。這個沒顧好，其他地方省再多都補不回來，而且拉高命中率本身就要花很多工程時間。
• 11:43 要按 surface 分開量測：VS Code、CLI、雲端 coding agent、IntelliJ、mobile；可以共用 harness，也可以個別調整
  ↳ surface 指產品的不同使用入口。VS Code 和 IntelliJ 是寫程式的編輯器，CLI 是打指令的介面，另外還有雲端 agent 和手機。各入口要分開量命中率。
• 12:14 目標是清楚掌握每次上線後到底是退步還是進步
  ↳ 每次改版都要有數字證明結果是變好還是變差，不能憑感覺判斷。
• 12:44 prompt caching 做好之後，下一步是讓對的智慧在對的時間給到使用者；Anthropic 和 GitHub 合作開發 advisor model，由 Anthropic 的 Brad Adams 接著介紹
  ↳ 省錢的基礎打好之後，下一步是讓使用者在對的時候用到對的模型能力。下一段由 Anthropic 的 Brad Adams 介紹 advisor model。

根據 Mario Rodriguez 的說法，GitHub 的 prompt cache rate 如果只有 70%，通常代表什麼？