能力曲線（第 2/2 段）

🧑‍🏫 這段講的是：AI 模型每隔幾個月就明顯變強，一般團隊要怎麼跟上，而不是一直被舊做法綁住。講者先用 Bunn 一週內用 Rust 重寫、以及幾家客戶的案例說明模型進步到哪裡，再整理出三個具體做法：建立自己的評估測驗、把給模型的指示精簡化、放手讓模型多想也自己動手。常用 AI 工具的人都能從中學到怎麼判斷新模型好不好用，以及怎麼寫出更好的指示。

• 13:14 Bunn（字幕拼法）的創辦人 Jared 上週才決定要用 Claude 把整個 Bunn 改寫成 Rust
  ↳ Bunn 是一套軟體（依字幕拼法）。創辦人 Jared 上週才決定，讓 Claude 把整套程式改用 Rust 這種程式語言重寫：功能不變，底層全部換掉。
• 13:14 Bunn 的 test suite 幾乎 100% 覆蓋整個引擎。Claude 跑了整整一週，幾乎通過全部測試，PR 合併後 Bunn 就改成 Rust 寫的了
  ↳ test suite 是一整批自動檢查，確認程式的每個功能都正常。Bunn 的檢查幾乎涵蓋整個引擎，Claude 跑了一週幾乎全部通過。PR（提交修改的申請）合併後，Bunn 就換成 Rust 版了。
• 13:45 關鍵在於有能驗證整個軟體系統的東西：原本就有好的 test suite，再加上敢問、也真的去試「Claude 做得到嗎」
  ↳ 成功的前提是有辦法確認改完還是對的。Bunn 本來就有完整的測試當標準答案，而且團隊願意真的交給 Claude 試，沒有先假設它做不到。
• 13:45 Jared 本人不會 Rust，還是完成了這件事
  ↳ 主導的人自己不會 Rust 也辦得到。因為對不對主要交給測試判斷，他不必逐行看懂 Rust，也能確認成果可以用。
• 14:17 這種工作以前要花好幾個月，現在一個人靠多個 Claude agents 對著 test suite 反覆迭代，一週就做完
  ↳ agent 是能自己一步步把事做完、不用每一步都等人下指令的 AI。一個人同時開好幾個 Claude agents，照測試結果反覆修改、重跑，本來要幾個月的工作一週就完成。
• 14:17 long horizon agents 已經能完成個人要花數月的軟體專案，而且進步沒有放緩，工程師一個人能做的事比以前更多
  ↳ long horizon agents 是能連續工作好幾小時、不會做到一半跑偏的 AI。它們已經能完成一個人要做好幾個月的專案，進步也還沒放慢，所以一個工程師能做的事變多了。
• 14:48 客戶案例 Vercel：模型在規劃階段、動手之前，有時會先對系統程式碼寫證明（proofs）並驗證系統
  ↳ Vercel 的觀察：模型在規劃階段、還沒動手寫程式前，有時會先用嚴謹的邏輯推導（證明），確認系統設計成立，等於先驗算再動工。
• 14:48 客戶案例 Windsor（字幕拼法）：模型在最長的 agentic runs 中能維持推理，長時間（好幾小時）保持連貫的能力領先市場
  ↳ Windsor（依字幕拼法）的觀察：在跑最久的自動任務時，模型連續好幾小時推理仍然前後一致，不會做到後面忘了前面。他們認為這一點領先市場。
• 15:18 客戶案例 Shopify：Opus 4.7 在智能上有大幅躍進，尤其是程式碼品質，以及邊做邊驗證、修正自己成果的能力
  ↳ Shopify 的觀察：Opus 4.7（Claude 的一個模型版本）明顯變聰明，寫出來的程式品質更好，而且會邊做邊檢查，發現錯了就自己修。
• 15:18 每出一代新模型，客戶的回饋都集中在規劃、驗證、長時間工作這幾項能力變得更好
  ↳ 每次新模型推出，客戶說的進步都集中在同樣三件事：先想清楚再做、自己檢查對錯、能長時間做下去。這三項就是這一波進步的主軸。
• 15:49 要跟上這條曲線，重點不在單一模型（Opus 4.7 或 4.6），而在整體趨勢：每隔幾個月模型就明顯變聰明，開發應用的思維也該跟著改
  ↳ 重點不是哪一版模型比較強，而是每隔幾個月就明顯變聰明的整體趨勢。做產品時要預設模型會一直進步，不要只照現在這個版本的能力來設計。
• 15:49 講者歸納幾個模式，幫你把模型進步轉成自己的生產力、公司內部使用和終端客戶的好處
  ↳ 講者接下來整理幾個做法，目的是讓模型每次升級，都能直接變成你自己做事更快、公司內部更好用、客戶體驗更好。
• 16:30 模式一：evals 非常關鍵。有值得信任的高品質 evals，團隊就能最快用新模型迭代
  ↳ 做法一：evals 是評估測驗，用一組題目量模型在你的工作上表現好不好。有可靠的 evals，新模型一出來就能很快判斷要不要換。
• 16:30 第一步是先開始做。官方 engineering blog 有一篇怎麼建 evals 的指南；很多團隊誤以為 evals 是學術工作、要請研究員，所以不敢開始
  ↳ 第一步就是動手做。很多團隊以為 evals 是學術研究、要請研究員才做得了，所以遲遲不敢開始。其實官方工程部落格就有一篇教你怎麼建。
• 17:03 evals 就是 AI 時代的 unit tests 和 regression tests；用到 AI 的應用沒有 evals，就像沒有 unit tests
  ↳ unit tests 檢查程式的小功能對不對，regression tests 確認改版後舊功能沒壞。在 AI 產品裡，evals 就是扮演這個角色。沒有它，改了東西也不知道有沒有變差。
• 17:03 evals 要量你真正在意的東西：貼近真實流量，測你希望在 production 看到的行為
  ↳ 出題要從你真正在意的事出發：題目盡量像真實使用者會丟進來的內容，測的是你希望產品正式上線（production）後做到的表現。
• 17:34 常見錯誤：只用 SweeBench Verified、BrowseComp、TerminalBench 這類學術 benchmark，沒有測自己實際的使用情境
  ↳ academic benchmark 是業界公開的標準考卷，例如 SweeBench Verified、BrowseComp、TerminalBench。常見的錯是只看這些分數，但它們考的不一定是你的使用情境。
• 17:34 例子：做 finance agent 時，從客戶那邊收集失敗模式，看哪些成功、哪些失敗，再放進 eval
  ↳ 舉例來說，做財務用的 AI 助理時，去跟客戶收集實際用到失敗的案例，整理哪些成功、哪些失敗，再把這些真實案例變成考題。
• 18:06 要知道 eval 什麼時候飽和（saturated）：例如 Opus 4.7 已經拿到 90%，剩下 10% 不可能或不公平，這個 eval 就量不出模型進步了
  ↳ saturated（飽和）是指考卷已經考不出差別。例如 Opus 4.7 已經拿到 90%，剩下 10% 是不可能或不公平的題目，再強的模型分數也上不去。
• 18:37 早期測試常見的情況：客戶用已飽和的舊 eval 只看到約 1% 進步，就以為新模型不怎麼樣；再花一週測更難的任務，才發現是 eval 過時了
  ↳ 早期測試常見的誤判：用太簡單的舊考卷測新模型，只進步約 1%，就以為新模型不怎麼樣。等花一週改測更難的任務，才發現是考卷太舊。
• 18:37 要持續把標準拉高，eval 才量得出模型的進步
  ↳ 所以考卷要跟著模型一起升級，持續加入更難的題目，才量得出新舊模型真正的差距。
• 19:07 專門抓 regression 的測試可以接受 100% 通過；但用來衡量模型進步的 evals 要保持不飽和
  ↳ 兩種測試要分開看：用來防止功能退步的測試，全部通過是好事；用來比較模型強弱的 evals，則要保留答不出來的難題，才有鑑別度。
• 19:07 新模型出來就拿這些 evals 跑 benchmark：跑一個 script 看結果，比較好就換上，不用看 Twitter 風向或自己測好幾週
  ↳ benchmark 在這裡是指拿同一份考卷跑分比較。新模型一出，跑個程式看分數，比較好就換上，不用看社群網站風向，也不用自己摸索好幾週。
• 19:37 有 evals 的公司通常最快適應新模型，這是很大的競爭優勢，因為改善應用最有效的方法，往往就是換上最適合、最前沿的模型
  ↳ 有自己 evals 的公司通常最快換上新模型，這是很大的優勢。因為要讓 AI 產品變好，最有效的方法往往就是直接換成最新、最適合的模型。
• 20:08 模式二：scaffolding 要隨時間縮小。scaffolding 指 LLM 周圍的一切：prompts、tools、執行環境、skills，也有人叫 harness
  ↳ 做法二：scaffolding（也叫 harness）是包在模型外面的一切，包括 prompts（給模型的指示）、tools（它能用的工具）、執行環境和 skills（打包好的做事方法）。這一層應該隨時間變薄。
• 20:38 常見問題是「Frankenstein prompt」：每遇到一個失敗就加一行，最後累積 3,000 行，多半是為舊模型和可能已不再發生的失敗寫的
  ↳ Frankenstein prompt 是東拼西湊出來的指示：每出一次錯就補一行，最後累積到 3,000 行，多半是為舊模型的毛病寫的，那些錯現在可能早就不會發生了。
• 21:09 換新模型時要刪減 prompt，拿掉不必要的部分，描述你真正想要的結果，而不是繞過舊模型的怪癖和弱點
  ↳ 換新模型時要把 prompt 刪短，拿掉沒用的部分，直接寫清楚你想要什麼結果，不要一直留著專門繞過舊模型弱點的補丁。
• 21:09 例子：Claude 4 上線時調整 Claude.ai 應用，發現新模型比以前更會遵循指令，連團隊沒預期它會照做的 prompt 片段都照做了
  ↳ Claude 4 上線時，團隊調整 Claude.ai 才發現新模型更聽話了，連團隊沒預期它會認真照做的指示片段，它也照做了。
• 21:39 Claude.ai prompt 裡有個 citation 格式範例，但那個格式早就不用了。模型照著產生錯誤格式；只改幾個字元，整類錯誤就修好了
  ↳ 例子：Claude.ai 的指示裡留著一個早就不用的引用格式範例，模型就照著產生錯誤格式。只改了幾個字，這一整類錯誤就全修好了。
• 22:11 模型變聰明後要重新檢查 prompt：可能有 bug、有過時的指令，或該刪掉的東西，讓模型能自主工作
  ↳ 模型變聰明後，舊指示要重新檢查：有沒有寫錯的、過時的、該刪掉的地方，讓模型不被舊規則綁住，能自己判斷怎麼做。
• 22:11 建議：換新模型或改進應用時，縮小 scaffolding，稽核 prompt 和系統裡已經不相關的部分
  ↳ 建議養成習慣：每次換模型或改產品時，都順便把外層設計縮小，逐一檢查哪些指示和設定已經用不到了。
• 22:41 理想做法是用 Claude 或你的 evals 測試：system prompt 砍到最精簡，模型還能維持一樣的表現嗎
  ↳ 最理想的檢驗方式：把 system prompt（模型每次開始前都會先讀的基本指示）砍到最精簡，再用 Claude 或你的 evals 測，看表現有沒有維持。
• 22:41 模式三：給模型工作的空間。第一點是在適當時候讓模型思考；目前前沿模型基本上都是 reasoning models
  ↳ 做法三：給模型做事的空間。第一點是適時讓它先想再答。reasoning models 是回答前會先推理的模型，現在最頂尖的模型基本上都是這種。
• 23:15 reasoning models 能從 test-time compute 受益：讓它多用運算，對問題投入更多智能，結果會更好
  ↳ test-time compute 是模型回答時花多少運算資源去想。讓它多想一點，就像考試多給一點作答時間，結果通常會更好。
• 23:15 建議開啟 adaptive thinking（讓模型自己決定何時思考），並依應用調高 effort 參數
  ↳ adaptive thinking 是讓模型自己判斷這題要不要多想，effort 參數則是設定它要花多少力氣。建議打開 adaptive thinking，effort 再依用途調高。
• 23:46 對智能很敏感的用途（多數軟體工程、企業 agents），effort 設很高、通常是最高或接近最高，代價是用更多 token
  ↳ 很吃聰明度的工作，像多數寫程式任務和企業用的 AI 助理，effort 建議設在最高或接近最高。代價是 token（模型計算用量的文字單位）用得比較多。
• 23:46 第二點是讓模型自主運作。這可能有點可怕：你不希望它沒問你就刪掉 cluster 或把工作部署到 prod
  ↳ 第二點是讓模型自己動手，不用每一步都問人。這聽起來有點可怕，像是它沒問你就刪掉整組伺服器（cluster），或把東西直接部署到正式環境（prod）。
• 24:17 Claude Code 的 auto-mode：每次 tool call 都由 prompted classifier 判斷是否安全，可以自動核准，或需要人類核准
  ↳ Claude Code 的 auto-mode：模型每次要用工具做事，都先由另一個 AI 判斷器（classifier）檢查。安全的就自動放行，有風險的才請人確認。
• 24:17 Anthropic 幾乎每位軟體工程師都在用 auto-mode，只有需要核准、關鍵或危險的事才找人；這個模式也能用在你自己的應用
  ↳ Anthropic 幾乎每位工程師都在用 auto-mode，只有關鍵或危險的事才需要人點頭。這種先檢查、再放行的設計，也可以用在你自己的應用上。
• 24:47 第三點是 close the agent loop：讓 agents 幫你改進 agents，設計成 Claude 或 Claude Code 能檢查自己的輸出並迭代
  ↳ 第三點是 close the agent loop：設計成讓 AI 能自己檢查成果、自己修改，形成循環，甚至由 AI 來幫你改進其他 AI 助理。
• 25:18 例子：把 Claude Code 接上已有 evals 的 agent，問它怎麼改 prompt 和 tools 才能拿更高分；它能自己跑 agent、跑 eval，自主改進
  ↳ 例子：把 Claude Code 接上一個已經有 evals 的 AI 助理，問它怎麼改指示和工具才能拿更高分。它會自己跑助理、跑測驗，一輪一輪改進。
• 25:49 讓 Claude 能在你的系統上迭代，就接近自我改進，你只要下指示，不必親自處理每個細節
  ↳ 當 Claude 能在你的系統上反覆試、反覆改，就接近自我改進了。你的角色變成下指示、定目標，不必親自處理每個細節。
• 25:49 總結：適時思考、在受控下自主運作、closing the agent loop，就能做出比以前更有生產力的自主 agents
  ↳ 總結三件事：該想的時候讓它想、在有安全把關的前提下讓它自己做、讓它自己檢查和改進。做到這些，AI 助理能完成的工作會比以前多很多。

講者說，客戶用新模型跑 eval 只看到約 1% 的進步時，常見的真正原因是什麼？