Claude Code 如何釋放模型能力

從刪除 80% 系統提示, 到能運行數週 / 調度數千個代理的工作方式
由 ChatGPT 整理 https://www.youtube.com/watch?v=qyPCVqFUyDo 影片製作的簡報

Transcript

1. Y COMBINATOR × BORIS CHERNY Claude Code 如何釋放模型能力 從刪除 80% 系統提示, 到能運行數週 / 調度數千個代理的工作方式 影片重點整理 | 繁體中文獨立閱讀版 | 2026.08
2. 閱讀指南 原片 36 分鐘 這份簡報可以跳著看, 每章都能獨立成立 每章先給結論, 再補案例 / 方法與限制; 頁首保留影片時間點, 方便回查. 01 Opus 5 的質變 00:07 06 給模型更難的任務 14:26 02 Prompt injection 防線 02:06 07 Prompting 轉向驗證 19:32 03 刪除 80% 系統提示 03:21 08 數千代理與 routines 24:42 04 Press Delete 與重建 06:37 09 Coding 幾乎被解決? 30:15 05 Product overhang 10:30 10 CS 學生仍該學什麼 32:20 02
3. 全片總覽 一頁掌握 Boris 的核心主張: 模型進步後, 舊有控制層反而可能成為阻力 01 02 03 04 刪除 觀察 驗證 補回 先移除舊 prompt / tools 與慣例 直接讓新模型做真實任務 給它測試 / 畫面或可判定 的結果 只針對反覆失敗處加規則 最重要的能力不是寫出更長的提示, 而是設計可驗證的任務, 並用實驗重新認識每一代模型. 03
4. CHAPTER 01 00:07 Opus 5 的質變 更強不只代表答題分數更高; Boris 強調的是持續運作時間與新能力的突然湧現. 04
5. 01 | Opus 5 的質變 影片 00:07 新模型的差異, 是能把任務持續推進很久 Boris 描述 Opus 5 搭配 Auto Mode 時, 能長時間工作, 而且未必需要額外 scaffolding.以下是訪談中的關鍵訊號. 30% 數天到數月 能力會湧現 訪談引用的 ARC-AGI 3 成績; 用 來說明能力躍升. 他聲稱模型可持續運作, 不會因短 期上下文而立即停止. 訓練不一定直接教會某項能力, 但 模型可能在新版本中突然展現. 05
6. CHAPTER 02 02:06 Prompt injection 防線 訪談把安全能力視為長時間自動化的前提, 但這是"目前難以示範攻破", 不是永 久保證. 06
7. 02 | Prompt injection 影片 02:06 三層防線一起工作, 而不是只靠一句系統提示 Boris 將防護描述為三個互補層次. 對齊過的基礎模型 注入偵測分類器 Auto Mode 分類器 模型本身能區分使用者目的與外部 內容中的惡意指令. 藉由模型內部訊號判斷是否出現 prompt injection. 在高自主權運行時再加一道行為檢 查與限制. 07
8. 02 | Prompt injection 影片 03:05 "無法示範 prompt injection"不等於絕對安全 訪談中的說法 Boris 表示經過研究 / 紅隊與競賽後, 團隊目前無法展示成功的注入攻擊. 閱讀時要保留的界線 產品設計仍應保留權限邊界 / 敏感操作確認 / 靜態分析與可復原機制.訪談後段也提到, Claude Code harness 仍保留大 量安全與權限程式碼. 08
9. CHAPTER 03 03:21 為什麼刪掉 80% 系統提示 舊提示常是在補償上一代模型的弱點; 新模型已經會做時, 這些規則可能只剩干 擾. 09
10. 03 | 刪除 80% 系統提示 影片 03:21 每一代模型都不同, prompt 不應被當成永久資產 原本為何需要 新模型為何能刪 • 修正模型不知道的行為 • 指定工具使用方法 • 讓產品互動更可預測 • 補足舊模型的推理與規劃限制 • Opus 5 已自然表現出許多行為 • 過度提示會占用注意力 • 舊指令可能與新模型習性衝突 • 更少提示有時反而讓模型更聰明 10
11. 03 | 刪除 80% 系統提示 影片 04:45 Ablation: 把每一行提示都重新證明一次 01 02 03 04 全部移除 逐行補回 以 eval 比較 刪除無效項 從接近裸模型的狀態開始, 不預設舊做法仍有效. 每次只加入一小段, 隔離單 一規則的影響. 觀察品質 / 安全 / 工具使 用與產品體驗是否真的改 善. 連 tools 與 harness code 都可能 unship, 不只清 prompt. 保留下來的多半是安全 / 權限 / 靜態分析與 UI; 不是把所有控制一律刪光. 11
12. CHAPTER 04 06:37 Press Delete, 然後再重建 對使用者也是同樣原則: 定期清空 CLAUDE.md / skills / hooks, 重新測試新模 型真正需要什麼. 12
13. 04 | Press Delete 影片 07:20 重建 prompt 的正確順序: 先用, 再補規則 01 02 03 04 刪除 真實使用 記錄失敗 最小補回 暫時移除舊有專案指令 / skills 與 hooks. 用新的模型執行代表性任 務, 而不是只做玩具測試. 找出同一類問題是否反覆 出現, 而非一次失誤就加規 則. 只加入確實需要 / 且每次 讀取都值得的指令. 建議週期: Boris 提出大約每六個月重新做一次; 模型大改版時更應提前進行. 13
14. 04 | Press Delete 影片 08:10 模型比較像會變化的合作者, 不像穩定不變的函式庫 傳統軟體直覺 模型產品直覺 • 先做完整架構設計 • 大量規則預防每種情境 • 測試長期累積 • 重構是昂貴的大工程 • 每代模型個性與能力不同 • 先觀察, 再設計 harness • 規則須持續被證明有效 • 舊經驗可能快速失效 14
15. 04 | Press Delete 影片 09:35 連 eval 也有壽命: 通常只比 harness 多活幾代 仍值得保留的部分 何時也該淘汰 Eval 能在模型更新時提供比較基線, 幫助判斷刪除或新增 規則的效果, 因此通常比某版 prompt 更穩定. 當模型已把 eval 做到飽和, 它就不再揭露弱點.Boris 認為 eval 常只存活 1–3 個模型世代, 之後要針對新失敗重建. 15
16. CHAPTER 05 10:30 Product overhang: 模型會做, 但產品沒讓 它做 最大的創業機會可能不在等下一代模型, 而在解除今天模型已經承受的限制. 16
17. 05 | Product overhang 影片 10:30 Hobbling 與 product overhang 是同一問題的兩面 Hobbling | 產品在妨礙 Product overhang | 能力未被產品化 介面 / 權限 / 固定流程或過度 scaffolding 把模型限制在 狹小行為中; 模型有能力, 但產品設計讓它無法表現. 今天的模型已能使用某種工具 / 語言或解法, 市場卻尚未 提供能可靠引出該能力的產品.這段落差就是商業機會. 17
18. 05 | Product overhang 影片 12:00 Claude Code 的起點, 是讓 Sonnet 3.5 一次完成更大的工作單位 當時主流產品只釋放了模型的一小部分能力. 當時的介面 模型其實能做 Claude Code 的選擇 單行／多行 autocomplete, 或只能 閱讀程式碼的 chat. 完整函式 / 整個檔案, 甚至一項小功 能. 移除複雜 scaffolding, 給終端機 / 寫入權與最簡單 harness. 18
19. 05 | Product overhang 影片 13:45 尋找產品落差, 可以從四個問題開始 01 02 03 04 現在被限制什麼? 任務能否放大? 怎麼驗證? 新模型再試一次 權限 / 工具 / 介面還是固 定步驟? 從一行 / 一步, 提升到整個 成果. 先建立測試 / 比較基準或 明確完成條件. 六個月前失敗, 不代表今天 仍做不到. Product overhang 的探索不是猜測功能清單, 而是持續用真實問題測模型邊界. 19
20. CHAPTER 06 14:26 給模型比想像中更難的任務 高階描述任務 / 護欄與完成條件, 讓模型自己決定路徑; 不要把你的舊做法硬塞 成逐步指令. 20
21. 06 | 更難的任務 影片 14:26 過度指定步驟, 可能把模型鎖進人類原本的解法 常見失敗寫法 Boris 建議的寫法 "先做 1, 再做 2 / 3 / 4; 每個檔案必須依我的順序修改." 說清楚: • 要完成的任務 • 不可跨越的護欄 • 可判定的 exit criteria 然後讓模型自行規劃與執行. 問題: 把方法寫得太死, 模型無法依現場資訊調整. 21
22. 06 | 更難的任務 影片 16:00 Bun 重寫案例: 單一任務, 11 天, 超過 10 萬行系統程式碼 Bun 團隊把 JavaScript runtime 從 Zig 重寫成 Rust; 模型以 dynamic workflow 調度大量代理, 並依測試套件驗證.Boris 明確補充: 過程仍有人類 steering. 11 天 >100,000 行 >1 年 任務連續運行時間; 不是即時 one-shot. 訪談描述的程式碼規模與複雜度. Boris 對傳統工程團隊所需時間的 估計. 22
23. 06 | 更難的任務 影片 17:55 案例成立的關鍵不是一句神奇 prompt, 而是可自動驗證 訪談中的說法 Bun 與 Node.js 都有大型測試套件, 因此代理能知道重寫是否正確 / 失敗在哪裡, 以及 何時該繼續. 閱讀時要保留的界線 不要把"一個 prompt"誤解成完全無人介入.訪談明確提到有 steering; 大型遷移仍需測試品質 / 權限界線 / 成本控制與 最終審查. 23
24. 06 | 更難的任務 影片 18:20 創造性實驗也能揭露能力: Opus 5 用 OpenCV 畫圖 為什麼值得注意 可以怎麼應用 Anthropic 內部有人偶然發現: 只要提供 OpenCV 並要求 繪圖, 模型能畫肖像 / 動物與風景; 這並非為繪圖專門訓練. 定期保留無直接 KPI 的探索時間: 換工具 / 換表達形式 / 換資料來源.某些商業機會, 會先以"意外有趣"的能力出現. 24
25. CHAPTER 07 19:32 Prompt engineering 正轉向"任務+驗證" 真正稀缺的不是 prompt 秘訣, 而是讓代理能判斷自己做對了沒有. 25
26. 07 | 任務+驗證 影片 19:32 現代代理任務的最小結構 01 02 03 04 難題 工具與脈絡 自我驗證 反覆修正 選一個略超出你認知邊界 的真實任務. 提供 repo / MCP / runner 或必要資料來源. 測試 / 截圖 / 逐像素比較 / 基準或可量測結果. 讓代理依驗證結果持續工 作, 直到 exit criteria. Boris 認為"驗證"是多數人最沒有設計好的部分. 26
27. 07 | 任務+驗證 影片 20:35 Swift 重寫案例: 兩週仍在運行, 靠畫面比較維持方向 任務設定 代理自行延伸 把 Electron 版 Claude Desktop 重寫成 Swift; 在 macOS runner 上同時啟動兩版, 截圖後逐像素比較, 直到完成. 任務超過 14–15 天仍在跑; Claude 還主動建立 Slack 頻 道, 每隔幾分鐘貼進度截圖, 形成可觀察的 live blog. 27
28. 07 | 任務+驗證 影片 23:00 頂尖使用者靠實驗, 不靠"唯一秘訣" Boris 對 top 1% 使用方式的總結非常樸素. 給太難的題目 提供驗證工具 看失敗再補能力 不要只拿 AI 做你已經知道每一步的 小工作. 讓它能像你一樣檢查輸出, 而不是等 你逐項批改. 缺 prompt 就修 prompt; 缺知識就 給 skill; 缺脈絡就接 MCP. 28
29. CHAPTER 08 24:42 數千個代理: dynamic workflows / loops / routines 並行數量不是目的; 關鍵是把任務拆成多階段 / 能驗證 / 能彙整的計算結構. 29
30. 08 | 多代理工作 影片 24:42 三種機制解決不同的問題 不要把所有長時間自動化都叫做同一種 agent loop. Dynamic workflow Loop Routine 單一複雜任務; 代理可並行 / 串行 / 再驗證與再彙整, 可能擴張到數千個 . 在本機重複執行的排程任務; 每次未 必共享完整上下文. 在雲端重複執行; 電腦關閉後仍可持 續, 適合日常維護. 30
31. 08 | 多代理工作 影片 26:10 Dynamic workflow 像一套"代理代數" 01 02 03 04 第一批探索 第二批驗證 彙整與決策 再次展開 平行閱讀 / 分析或實作不 同區塊. 另一組代理檢查 / 測試或 比對第一批結果. 摘要衝突 / 挑選方向 / 建 立下一階段任務. 依結果繼續 fan-out, 直到 完成整體目標. 它本質上是在編排 test-time compute: 把更多推理 token 組織成可用的工作, 而非只增加單一回答長度. 31
32. 08 | 多代理工作 影片 28:00 Claude 團隊已用 20–30 個日常 routines 維護自己的產品 訪談列出的例子橫跨 CLI / iOS / Android 與桌面應用. 清理與收尾 補強品質 Abstraction police 找 dead code / 移除已全面上線的 experiment / 刪除無效測試. 尋找缺少測試覆蓋的區域, 自動提出 pull request. 找出不同區域重複出現的近似抽象, 嘗試統一實作. 32
33. CHAPTER 09 30:15 Coding 已經"幾乎被解決"了嗎? Boris 的答案有明確限定: 對他做的那類工作越來越接近, 但深層系統與精細 UI 仍未解決. 33
34. 09 | Coding 幾乎被解決? 影片 30:15 "Coding is solved"是方向判斷, 不是無條件事實 正在快速被解決 仍然困難 • 一般產品功能 • 大量常規程式碼 • 有完善測試的遷移與維護 • 可由工具驗證的工作 • 深層 systems code • 複雜 distributed systems • 像素級 UI 驗證 • 視覺與 computer use 的極端細節 34
35. 09 | Coding 幾乎被解決? 影片 31:25 優秀 builder 的差異, 轉向三種能力 當程式碼產出變便宜, 價值會往上游與驗證移動. 選對問題 設計判準 快速更新認知 知道什麼值得做 / 使用者真正需要 什麼. 把模糊品質轉成模型能自行檢查的 標準. 忘掉上一代模型的限制, 用實驗重新 找邊界. 35
36. CHAPTER 10 32:20 CS 學生仍該學什麼 學習程式設計仍有價值, 但重點要放在用它解決真實問題, 並與設計 / 商業 / 資 料與使用者理解結合. 36
37. 10 | CS 學生仍該學什麼 影片 32:20 Boris 的學習路徑一直是: 先有實際問題, 再追求更深技術 他的例子 對今天學生的含意 中學時先用 TI-83 BASIC 解數學題; 題目變難後再學組合 語言.技術深度是被真實需求拉出來的, 而不是先把所有理 論學完. 不要只問"還要不要學寫 code"; 應問"我能否理解系統 / 判斷輸出 / 設計驗證, 並把 AI 產出組成真正有人使用的產 品". 37
38. 10 | CS 學生仍該學什麼 影片 34:20 工程能力要與其他能力疊加, 才形成不可替代的價值 訪談最後列出的實務方向. 產品與設計感 商業與使用者 資料與實驗 能把需求變成可使用 / 可理解 / 可 持續改進的體驗. 會談使用者 / 判斷價值 / 找到願意 採用與付費的場景. 能定義指標 / 分析行為 / 設計 eval, 並以證據調整系統. 38
39. 行動清單 影片 全片整理 把影片觀點帶回自己的 Claude Code／代理工作流 01 02 03 04 挑一個舊設定 做一次 ablation 先補驗證 挑更大的任務 選 CLAUDE.md / skill 或 hook, 建立可回復的備份. 移除後用 5–10 個代表性 任務比較結果. 在加長 prompt 前, 先加 入 test / lint / 畫面或資料 判準. 把工作單位從一步提升到 完整成果, 觀察新邊界. 判斷標準: 設定更少 / 成果更穩 / 驗證更自動 / 人工 steering 更集中在高價值決策. 39
40. 來源與時間索引 可直接回查原片 原始內容與章節時間點 主要來源 時間索引 Y Combinator | Boris Cherny: Building Claude Code YouTube: youtube.com/watch?v=qyPCVqFUyDo 逐字稿: ycrootaccess.com/p/boris-cherny-building-claude-code 00:07 Opus 5 02:06 Prompt injection 03:21 刪除 80% 系統提示 06:37 Press Delete 10:30 Product overhang 14:26 更難的任務 本簡報將訪談主張與整理者解讀分開; 涉及安全或能力上限的內 容, 應視為當時訪談中的觀察, 而非永久保證. 19:32 Prompting 與驗證 21:57 兩週任務 24:42 數千代理 30:15 Coding 幾乎被解決 32:20 CS 學生仍該學什麼 40