該是重新檢視你的 Claude Code system prompt 了：從 Boris Cherny 的 YC 訪談談起

昨天，Y Combinator 上傳了一場訪談，由 Managing Partner Diana Hu 訪問 Claude Code 創作者 Boris Cherny。整場談了 Opus 5、Claude Code、長時間運作的 agent 與 AI 時代的工程師。內容不少，但可以用一個角度把它串起來：拿到能力更強的模型之後，我們原本使用 AI 的方法也要重新檢查。

刪掉 80% 的 system prompt

Boris 提到，Claude Code 團隊在 Opus 5 發布時，刪除了超過 80% 的 system prompt。每次有新模型，他們都會重新做 ablation：先移除原有指令，再一行一行加回去，確認每一行是否仍然有作用。他甚至建議 Claude Code 使用者，每隔一段時間可以暫時移除 CLAUDE.md、skills 與 hooks，看看新模型在沒有這些設定時會怎麼做。

為什麼要這樣做？因為這些設定很多是為了修正舊模型的問題。模型當時不會主動讀測試、不懂專案慣例，或者經常在某個步驟失敗，我們便增加一條指令。累積久了，system prompt 看起來像一份完整的最佳實務，裡面其實混合了專案必要規則，以及為舊模型增加的補救規則。新模型可能已經自然具備那些能力，原本的指令反而限制它處理問題的方法。

Boris 建議的順序是：先移除、實際使用、觀察失敗，再補回必要的規則。只有當模型反覆在同一個地方出錯，才增加對應的指令。這個做法讓 system prompt 從「預先寫好所有可能用到的規則」，變成根據實際行為持續校正的設定。

所以模型升級不只是把名稱從上一版換成下一版。工具、system prompt、skills、hooks，甚至原本用來評估模型的 eval，都需要重新跑過一輪。模型能力進步得很快，舊 eval 可能在幾代模型後就被跑到接近滿分，無法再告訴我們模型在哪裡有問題。升級模型的同時，也要重新建立自己對它的認識。

順手做一件事：按「變動頻率」重排你的 prompt

既然都要重審 CLAUDE.md 了，這裡補一個實務技巧：穩定不變的內容放上面、會變動的內容放下面。

Prompt caching 的機制是前綴比對（prefix matching）——只要前面的內容完全一致，就能命中 cache；只要前面任何一行變了，後面全部視為新內容重新計算。所以：

• 放上面（盡量不動）：system prompt、工具定義、專案規則、coding style 這些長期穩定的段落。
• 放下面（允許常變）：當前任務描述、今日日期、動態注入的上下文、暫時性的提醒。

如果你習慣把「本週待辦」或常改的臨時規則寫在 CLAUDE.md 最上面，每改一次，整份設定的 cache 就全部失效，token 成本與延遲都會增加。趁這次重新 ablate 的機會，把內容按變動頻率排序，是幾乎零成本的優化。

給模型更困難的任務

第二個建議是給模型更困難的任務。很多人使用 AI 時，會把每個步驟寫得非常細，要求它先做一、再做二、最後只能用某種方法完成。Boris 認為現代模型更適合接收高一層的任務描述：說清楚目標、限制與完成條件，讓模型自己規劃方法。

訪談裡有兩個例子：

1. Bun：Zig 改寫成 Rust。 Bun 團隊讓 Claude 把超過十萬行、原本以 Zig 撰寫的 JavaScript runtime 改寫成 Rust。這項工作持續 11 天，過程中有人引導，大量分析、實作與修正由 dynamic workflow（動態工作流）調度多個 AI agent 完成。
2. Claude 桌面版：Electron 改寫成原生 Swift。 Boris 提供 macOS runner，要求 Claude 同時執行兩個版本、截圖、逐像素比較，沒有符合就繼續修改。受訪時，這個工作階段已經持續超過兩週。

這兩個案例都有一個共同點：模型知道如何檢查自己的成果。Bun 有完整測試套件，桌面 App 有可以反覆比較的畫面。模型每完成一輪，都能取得明確回饋，判斷目前結果和目標之間還有哪些差異，再開始下一輪。

Loop 與 eval 比 prompt 更值得花時間

這也是 loop 與 eval 在現在變得更有意義的原因。Loop 必須讓模型經歷執行、觀察、判斷與修正，重複同一段 prompt 並不會自然形成這個過程。Eval 的用途也延伸到執行過程，持續提供方向，讓模型知道哪些部分已經完成、哪些部分還需要處理。如果沒有測試、畫面比較、資料檢查或清楚的成功條件，模型運作兩週也可能只是反覆產生無法驗證的結果。

Prompt 當然仍然有作用，只是工作重心正在改變。以前我們花很多時間研究某個詞該怎麼寫、步驟要怎麼排列；現在要多想一層：模型能取得哪些工具與上下文、如何看見執行結果、失敗時會收到什麼訊號，以及什麼條件代表工作真的完成。模型的自主能力提高之後，loop 與 eval 會直接影響這份能力能否用在真實工作上。

不要聽 LinkedIn influencers

Boris 在訪談中半開玩笑地說，不要聽 LinkedIn influencers，也不要看 Twitter，因為不存在一個能讓所有人成為 AI 高手的神奇技巧。外部經驗可以視為試驗方向，最後仍要回到自己的任務、資料、限制與驗證結果。

AI 工具變化很快，一個在六個月前有效的技巧，今天可能已經沒有必要。別人的 system prompt、skills 或工作流程，也可能只是為了解決他的模型版本與工作場景。看完 KOL 分享後親自跑一次，保留有效的部分，移除沒有作用的部分，才會形成適合自己的方法。對 AI 的理解很難只靠閱讀累積，它需要持續實驗。

CS 學生現在還應該學什麼

訪談最後談到 CS 學生的學習。Boris 從國中使用 TI-83 計算機開始學程式，先用 BASIC 寫數學解題工具，遇到更困難的 calculus 問題後再去學 assembly。他學習技術的方式一直圍繞著一個想解決的具體問題。

他的建議是，CS 學生仍然要學 computer science，也要學會把技術放進真實世界，包括產品設計、商業判斷、data science、和使用者交談，以及創業與產品開發。當 coding 的執行工作逐漸交給 agent，定義問題、理解使用者、判斷結果是否正確，以及決定什麼東西應該被做出來，都會成為工程工作的一部分。

下一次拿到更強的模型時

把整場訪談濃縮成一份 checklist：

1. 暫時關閉一部分舊設定（CLAUDE.md、skills、hooks），觀察新模型的原生行為。
2. 先移除、實際使用、觀察失敗，再補回必要規則——只補「反覆出錯」的地方。
3. 重排 prompt：穩定內容放上面盡量不動，變動內容放下面，吃滿 prompt cache。
4. 挑一個以前覺得太困難的任務，替它準備可以自行驗證的環境（測試、畫面比較、資料檢查）。
5. 重跑你的 eval——如果舊 eval 已接近滿分，它已經無法告訴你模型的邊界在哪。

每個人面對的問題不同，親自跑過的結果，才會成為下一輪真正有用的經驗。