你的舊提示詞正在拖累 Claude——Anthropic 的 Lance Martin 這麼說

Anthropic 技術團隊成員 Lance Martin 指出，多數正在跑 Claude 的團隊根本沒站在成本與品質的前沿上——他們落在前沿內部，原因是可修正的錯誤設定；而幾項 Claude Code 技能就能同時救回效能與支出。這場演講大致上是這些技能的實用導覽，以及背後的原則：稽核過時的提示、修正提示快取命中率、設計可攀登的評估（eval），以及針對品質或成本執行自主爬山（hill climbing）迴圈。標題主打的提示稽核只是五個主題中的第一個，大約佔開場五分鐘；整場的主體、以及 40 分鐘問答的大部分，都在談評估設計、爬山與長時間執行的代理框架（agent harness）。

Martin 的視角來自 Anthropic 內部的應用 AI（Applied AI）工作；他說這些指令在內部與客戶端都已廣泛使用。讀者讀完應該帶走一份具體的操作清單：該跑哪些指令、該剔除哪些反模式、如何安排提示結構以命中快取、如何避免爬山過擬合，以及為什麼「強模型搭低強度」在成本上往往勝過「弱模型搭高強度」。

過時的提示儀式現在既燒錢又傷品質

Martin 的第一個、也最簡單的槓桿是提示債：提示就像程式碼一樣會累積雜物，而那些在早期模型世代有幫助的儀式，如今在尖端模型上反而幫倒忙。他點名該剔除的具體反模式：「think step by step」、像「double check your work」這類驗證儀式、像「be maximally thorough」這種加碼用心的指令，以及告訴代理該怎麼想、在哪裡想的牽手式草稿區。尖端模型本來就會思考、會自行決定何時思考，也會驗證自己的工作；這些指令大多隻是在燒 Token。第二種失敗模式是規則互相矛盾——較舊、較弱的指令遵循模型會默默丟掉兩條衝突規則中的一條，仍能運作，但尖端模型會被矛盾搞混。

解法是一道指令，不是重寫。在 Claude Code 中，checkup prompt audit 會稽核 Claude Code 的設定（技能、提示），claude api prompt audit 則針對呼叫 API 的程式碼；兩者連結到同一個底層技能，掃描工作目錄並自動移除反模式。Martin 說這在 Anthropic 內部與 Twitter 上都已流行起來。

他用一份約 50 張工單的合成客服評估來示範，模擬從 Opus 4.8 遷移到 Opus 5.5，並逐一注入各項反模式。光是遷移本身就帶來一些成本與效能節省；在此之上再跑提示稽核，兩個軸向都進一步改善，因為它剔除了那些讓 Opus 5.5 多花大量 Token 的加碼指令與驗證儀式。

「提示會像程式碼一樣累積債務。」

提示快取幾乎是免費的節省，而多數框架都做錯了

快取是第二個槓桿，用 Martin 的說法，這最接近白撿的錢：快取 Token 的計費大約是基準費率的十分之一（他提醒定價因模型而異，要查定價頁），而且速度更快。問題在於快取是嚴格的字首比對——字首只要改一個位元組就失效——所以多輪代理必須設計成讓字首在各輪之間保持穩定。

他給出一個安排提示結構的標準分層，讓穩定素材放在最前面：

Claude Console 會為 API 應用揭露提示快取命中率的診斷資訊，Martin 說 Anthropic 對 Claude Code 的命中率「非常、非常虔誠地」追蹤，因為它直接決定經濟效益。該跑的指令是 claude api 的快取診斷，它會找出重新安排提示以提高命中率的機會，也會檢查強度設定與提示。他的團隊拿一組內部基準搭配預設框架來跑，發現有機會把成本砍掉多達 72%，而效能沒有明顯變化——因為那些框架根本沒正確使用快取。

好的評估必須可攀登，代理才可能在其上改進

Martin 在評估設計上花最多時間，因為它決定了一切下游工作：Claude 非常擅長自我修正，會在結構良好的評估上爬山，但前提是這個評估設計得可以攀登。他列出好評估應具備的四個性質，並以尖端、中型、小型模型（Opus、Sonnet、Haiku）的分數對「每次嘗試 Token 數」曲線來說明：

• 模型等級往上跳，效能隨之提升。
• 提高思考量，效能隨之提升。
• 前沿仍留有餘裕——評估尚未飽和。
• 每次執行的變異低。

他最常見到的失敗，是沒有任何模型能解出的模糊任務，這會製造出還有餘裕的假象。團隊於是燒掉大量 Token 預算，朝著一個根本不存在的天花板爬山。claude api build eval 技能刻意對資料存放位置不表意見——它可以指向任何追蹤（tracing）方案——並帶使用者從原始追蹤紀錄建立評估集：展示資料、草擬評分器，並依這些原則對評分標準做基本檢查。Martin 提到有一篇搭配的部落格文章談這套實務。

爬山有效，但過擬合才是預設的失敗模式

一旦有了可攀登的評估，claude api hill climb 就會自主執行這個迴圈。Martin 的主要警告是對評估分佈過擬合：因為某一題需要 OCR 就加一個 OCR 工具的框架，或是針對評估範例中特殊措辭微調過的提示，在基準上看起來很棒，上線後卻毫無作用。他稱這是主要顧慮，也提到花大錢爬山卻換不到任何生產效益的挫折感。

這個技能的主要防線是經典的訓練／測試切分。它在決定要改什麼時只看訓練集，而且每一輪都並排檢查測試集與訓練集的表現——訓練集進步而測試集持平，就是過擬合的早期訊號。他明說這並不完美，人應該留在迴圈裡。

他的實作範例就是 claude api 技能本身；這個技能讓 Claude 認識 Anthropic 的 SDK 與 API，且必須緊扣檔案。在以該檔案建成的評估上，這個技能起初只拿 66%。他讓 Claude Code 取得技能文本與檔案，放手讓它針對失敗反覆迭代；它找到了正確的技能文本，大幅改善。他的結論是：以文字為基礎的介面——提示與技能——是爬山的最佳起點，因為它們與模型行為明顯耦合、修改成本又低，不過提示同時也是最容易被過擬合的東西。

他也提醒爬山不保證收斂。這個技能有備援機制：若連續數輪停滯，它會把剩下的失敗分群並找出原因，而原因往往是模糊或有問題的評分範例，而非模型能力限制。在他自己的成本案例中，爬山停滯後，它把案例分群、找出模糊的案例並改寫。

降成本爬山找到砍 90% 且效能更好的解

同一個迴圈也可以指向成本而非品質。在「效能持平的前提下降低成本」的指令下，爬山器會搜尋模型、強度與提示的各種組合。在同一個客服基準上，從 Opus 4.8 搭高強度與基準提示出發，它先換到 Opus 5.5 搭低強度（效能提升、成本小降），再換到 Fable 搭低強度（效能再升、成本大降），接著微調提示把效能補回來——最終成本約降 90%，效能還明顯改善，全程自主完成。

背後的直覺——Martin 說技能已把這點內建——是強模型搭低強度往往更省 Token、因此比弱模型搭高強度更便宜：更聰明的模型需要更少的思考 Token 就能得到更好的答案。他提到自己那次執行中，Haiku 4.5 搭低強度出現明顯退步，因此被當作資料點剔除。由於降成本爬山即使在飽和的評估上也有效——此時效能已無關緊要——對基準已經頂到上限的團隊來說，這是個有用的工具。

「先從低強度試起，你隨時可以再往上調……非常、非常聰明的模型，但不用太用力。這往往就是甜蜜點。」

關於強度的語意，他澄清強度不是硬性的 Token 上限，而是「該想多用力」的指引。簡單問題上，即使最大強度也不會爆量；但在前沿問題上——尤其是困難的程式任務——超高或最大強度可能產生巨大的 Token 差異，結果卻差不多，因為模型做了更多驗證工作。

長時程代理需要把大腦與手腳解耦

Martin 以框架設計連結到任務時長的上升來收尾。他引用 Anthropic 自家的量測曲線：Claude Opus 3 大約能自主工作四分鐘，那個階段只撐得起自動補全與聊天；到 2025 年，模型已達到一到兩小時的人類等效工作，這正是 Claude Code 起飛的區間；而目前的模型已超過一到兩天，超出量尺能測的範圍。在那樣的區間裡，設計問題轉向長時間無人看管執行下的安全性與可靠性。

他主張的架構——背後是 Claude Managed Agents API 以及他四月寫的一篇工程部落格——是把大腦與手腳解耦。框架是大腦；沙箱是手腳，程式碼在此執行、動作在此發生。工作階段日誌是獨立於兩者之外、僅可追加的物件，因此若框架或沙箱在執行中途掛掉，系統可從日誌復原，並由協調器啟動替換品。機密永遠不會直接交給 Claude——它們存放在工具箱層的保險庫裡，代理可以引用 API 金鑰卻看不到內容，這在代理連續跑好幾天時至關重要。

flowchart TD
    O["協調器"] --> H["框架（大腦）"]
    O --> S["沙箱（手腳）"]
    H --> L["工作階段日誌（僅可追加、可復原）"]
    S --> L
    H --> V["保險庫（機密，僅引用不暴露）"]
    H --> T["工具"]

他指向最近與 CJ 合寫的一篇部落格，內容是打造一個定期更新上下文的排程代理——從指定來源抓取並寫入 Slack——跑在 Anthropic 基礎設施上，具備安全的機密儲存與記憶。入門路徑是 claude api managed onboard 加上該部落格連結，會啟動教學。

問答：評估工藝、評分規準，以及人還在哪裡重要

問答才是大部分操作細節所在。談到自動化評估設計，Martin 同意 Hamel Husain 的公開批評：技能應在分析之前先讓使用者看到原始資料；他說他已經開了 PR，要加入一個資料檢視階段。他偏好的分工是：由人決定什麼重要、為什麼重要，Claude 像線上評估器一樣掃描追蹤紀錄以標出可能的失敗，人再審查這些案例，然後把它們晉升進評估集。

談到評分開放式輸出，他給了一套具體的評分規準做法：建立一套人能套用的規準；避免任意的 0–5 或 1–10 量表，改用明確的二元分類器（多個二元判斷，而非一個模糊量表）；確認 Sonnet、Opus、Fable 評分一致；並跑重複實驗確認變異低。在問題允許時，他最偏好成對比較，因為比較兩份產出比替單份打分更容易、雜訊也更少——他舉生成式 UI 的評估為例，以成對比較評分再彙總成 Elo 評分。出於成本考量，他也建議用較便宜的模型當評分器。

談到評估分佈，他警告不要用對抗式取樣——把某個特定模型失敗的案例晉升進來——因為模型智慧是崎嶇不平的，某個模型的失敗口袋，下一個模型可能輕而易舉就解掉，結果做出一個形狀對應到錯誤山谷的評估。案例應該從第一原理、直覺與生產資料晉升。至於資料集大小與切分，他交給技能的啟發式規則，並說他沒有仔細研究集合大小的效應；在極小樣本的情況下，主要風險是過擬合與不具代表性。

問答的其他重點：

• 何時該建評估： 取決於任務的重要性，而不是這份工作是個人用途還是生產用途。一位財務專業人士若把自己工作流程的一部分自動化、且產出會對外分享，就該建一個；個人行事曆助理可能不需要。
• 可觀測性工具： 他拒絕背書特定廠商（他先前在 LangChain 工作），並指出小規模時可以自己打造，而且 Claude 很擅長便宜地做出客製化的資料檢視介面。
• 誰負責評估： 在 Anthropic 並沒有按團隊劃分——擁有產品的人就有權建評估，而這些技能把門檻降得夠低，現在許多非工程職位也在做。
• 多輪評估： 代理通常需要；build-eval 技能可以吃進追蹤紀錄並形塑評估，而關於該評整個軌跡還是隻看最終結果，目前有幾種相互競爭的哲學。
• 上下文工程： 他認為價值最高的可靠性技巧，是 RLM 式的做法——把上下文物件與框架分離，讓模型去詢問一個獨立、可復原的上下文儲存。用一般的訊息歷史，一次壓縮事件就會摧毀被摘要掉的內容；用獨立物件，代理永遠可以回頭查詢。
• 評估意識： 他認為這裡的實務顧慮是過擬合，而不是模型知道自己正在被測；不過他提到 Anthropic 對評估意識有更廣泛的發表。
• 自動研究： 爬山的直覺——明確、可驗證的目標加上自主迭代——與自動研究工作背後是同一個直覺；這個技能瞄準的是以評估為基礎的爬山，但也可以改造成針對 nanoGPT 風格 repo 的損失值這類目標。
• 多目標爬山： 可行（成本、效能、速度），但多一個目標就讓搜尋更難；他建議一次只改一件事。
• 生產迴圈： 他背書的模式是：線上評估器替已部署的追蹤紀錄打分，低分者晉升到離線評估集，對這些案例爬山，通過後再變成回歸測試——這個迴圈現在已有幾家追蹤廠商產品化。
• 模型升級與評估： 如果一個建得好的評估在模型進步時沒有顯示效能上升，該質疑的是評估，不是模型。讓評估對最強的模型仍夠難，是反覆出現的挑戰。

整場的貫穿主線是：前沿能力通常已經存在，只是被設定擋住——過時的提示、壞掉的字首快取、無法攀登的評估、撐不過一天長時間執行的框架——而最便宜的勝利來自修好鷹架，而不是買更大的模型。尚未化解的張力是過擬合：讓爬山變容易的那些文字介面，也讓提示很容易被調成只在基準上贏的形狀，而訓練／測試切分只是緩解，不是保證。值得追蹤的是 build-eval 技能的待上線變更（Martin 說資料檢視階段已在 PR 中），以及託管代理模式是否會成為多日自主工作的預設框架。