擁有更強的模型之後

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

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 可能在幾代模型後就被跑到接近滿分，無法再告訴我們模型在哪裡有問題。升級模型的同時，也要重新建立自己對它的認識。

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

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

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

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

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

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

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

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

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

這也呼應我一直在想的工程師角色變化。寫 code 仍然存在，工程師的工作範圍正在往外延伸。能不能定義對的問題、提供足夠的上下文、建立可驗證的 loop，並判斷 AI 的能力邊界，會決定更強的模型最後能產生多少實際價值。

下一次拿到更強的模型，可以先暫時關閉一部分舊設定，挑一個以前覺得太困難的任務，替它準備可以自行驗證的環境，再觀察它實際做到哪裡。每個人面對的問題不同，親自跑過的結果，才會成為下一輪真正有用的經驗。

資料來源：

Y Combinator：Boris Cherny - Building Claude Code https://www.youtube.com/watch?v=qyPCVqFUyDo

Claude Code 官方文件：How Claude Code works https://code.claude.com/docs/en/how-claude-code-works

Claude Code 官方文件：Automate work with routines https://code.claude.com/docs/en/routines