agent 改完一段程式碼只要幾十秒，接著它說「我在等測試跑完」，然後五分鐘過去了。你開了三個平行的工作區想加快進度，第三個 dev server 起來時記憶體就滿了。如果你每天都在用 coding agent，這兩個畫面應該不陌生。
2026 年 10 月 17 日，我在 Vue Conf Taiwan 2026 現場聽了 Evan You（尤雨溪）的演講。前半段是 Vue、Vite 與 VoidZero 的近況，後半段他把題目拉高：今天的 JavaScript 工具鏈都是為人設計的，換成 agent 來用，哪些前提要從頭想過。後半段講的幾乎就是上面那兩個畫面。
這篇是我聽完的整理：先記前半的重點，再花多一點篇幅談後半，最後寫我們團隊怎麼看。內容是我的轉述與摘要，不是逐字引述；版本與發布狀態我對照過官方公告，查不到公開資料的會標明是現場所述。他說還不能公開的東西，這裡只寫「他預告了」。
一、框架在 AI 時代的處境：語料紅利與 API 穩定
他的第一個觀察是：一個框架成為主流之後，在 AI 時代會自己持續成長，因為模型的訓練資料裡已經有大量語料。早期的模型還會把 Vue 2 和 Vue 3 的寫法混在一起，現在主流模型已經不會。他現場給的數字是 Vite 每週下載量超過兩億次（Cloudflare 2026 年 6 月的收購新聞稿引用的是超過 1.3 億），Vue 稍少，但也穩定成長。
第二個觀察比較反直覺：模型偏好精確、沒有歧義的 API，不在意寫起來繁瑣。Vue 過去為了開發者體驗加了很多簡寫，例如 v-on 的縮寫，從模型的角度看，這些方便反而增加 token 用量和判斷負擔。好在 Vue 的語料夠多，這件事目前對模型不構成問題。
由此推出的取捨是 API 穩定優先。訓練資料永遠落後，每改一次 API，所有用 AI 寫程式的人都會經歷一段 AI 還在寫舊寫法的陣痛期。所以框架作者現在發布重大改動要更謹慎，每一個改動都要值得那段陣痛。
講到這裡你可能會想，那 Vue 4 呢？以下是現場所述，我沒有找到對應的官方公告：Vue 4 目前唯一確定的事情是移除 CommonJS 的發佈檔，因為這是 breaking change，照 SemVer 只能升主版號；不會有 Vue 2 到 3 那種程度的改動，而且可能和 3.6 同時發正式版。
3.6 寫這篇時還在 RC 階段。它的 Vapor Mode 沿用同一套 API、逐元件選用，他現場展示的 benchmark 效能贏過 Svelte 和 Solid；響應式系統的底層換成 alien-signals，作者是 core team 成員 Johnson。據他現場的說法，Johnson 整理了一套比較各家 signals 實作行為正確性的測試，alien-signals 是唯一全部通過的實作。
這一節的判準是：對人和對 AI 都永遠有用的只有兩件事，正確性與效能。 簡寫和語法糖的價值，在 agent 寫大部分程式碼之後正在下降。
二、VoidZero 加入 Cloudflare 之後
Cloudflare 在 2026 年 6 月宣布收購 VoidZero，Vite、Vitest、Rolldown、Oxc 都維持 MIT 授權。他說對開源部分完全沒有影響，最大的差別是不必再為開源工具的商業化煩惱，可以專心做開源，並且接手 JavaScript 生態裡一些沒人願意承擔的工作。
今年陸續發布的東西如下，版本與日期我對照過官方公告：
| 項目 | 狀態 |
|---|---|
| Vite 8（2026-03） | 打包改用 Rolldown、編譯用 Oxc，他說這為 Rust 化畫上句點 |
| Vite+ 1.0（2026-09） | linter、formatter、test runner、dev server、bundler 收進同一個工具，並管理 Node.js 與套件管理器版本，附本機 task cache |
| Vitest 5（2026-09） | 底層跑的是 Vite，間接拿到上面的效能提升 |
| oxlint type-aware linting（2026-07） | 宣告 stable |
| React Compiler 的 Rust 版（2026-08，實驗性） | 原本的 Rust 移植停滯，Oxc 團隊接手並放進 Oxc；現場所述比原版更快 |
Vite+ 管版本這件事他舉了自己的例子：換新電腦時只先裝 Vite+，進專案跑 vp install，它會先下載該專案要求的 Node.js 和套件管理器版本再安裝依賴，切到別的倉庫也會自動換成對的版本。我們自己用 vp env 管版本時踩過一個「pin 了卻沒生效」的坑，寫在 Vite+ 的 vp env：pin 了版本卻沒生效。
Roadmap 上可以公開的有這幾項。Vite 的 bundle dev 解決超大型專案的問題：上萬個模組代表瀏覽器一次收上萬個請求，瓶頸在瀏覽器的網路層，不在 Vite，先 bundle 成幾十到一百多個請求就好得多。這個功能從 Vite 8.1 起以實驗性的 bundled dev mode 提供。Rolldown 的 chunking 則要重新學 Webpack：純 ESM 為了維持語義正確，共用模組必須各自拆成獨立 chunk，大型專案可能切出上千個；Webpack 的做法是允許小模組在多個 chunk 裡重複一份，犧牲一點正確性換來少得多的請求數。他說當年偏好 Rollup 那種乾淨的純 ESM 產物，回頭看 Webpack 的很多取捨是有道理的，Rolldown 正在把其中一些概念引回來。
其他還有：第四季在 Vite 與 Rolldown 原生支援 import attributes；和一位 Atlassian 工程師合作，用 SIMD 加速 Oxc parser，現場所述驗證過可以再快三倍、lexer 部分已完成；Vite+ 會從本機 task cache 擴充到 remote cache，讓隊友和 CI 共用，這一項在 1.0 公告裡也列為之後的版本。另外他預告近期會有新消息，當時還不能透露。
三、Void：把部署步驟拿掉，agent 就能一次做完
Void 原本規劃為 VoidZero 的付費平台，定位接近 Vercel 的競品。加入 Cloudflare 後沒必要再做一份商業複製品，他在現場宣布框架和平台已經一起開源。以下功能都是他現場的介紹，我還沒有自己動手驗證。
框架本身是一個 Vite plugin，裝上之後 Vite 就變成全端應用，有自己的 pages router，可以搭配 Vue、React、Svelte、Solid，共用同一套路由與型別。它最大的特點是從程式碼推導需要的伺服器資源：程式碼裡寫 import db，本機開發時用 SQLite 模擬；部署時它先在你的 Cloudflare 帳號裡建好 D1 資料庫，每次部署前把 migration 跑完。資料庫層強制用 Drizzle，從 TypeScript 寫的 schema 一路推導出 query、頁面 props、actions 與表單驗證的型別。import db 這類 SDK 功能不綁 Void 自己的框架，Nuxt、SvelteKit 等以 Vite 為基礎的框架也能用。
他講了一個例子：團隊裡一位非技術背景、負責營運的成員，第一次手動設定各項資源來部署應用，花了三小時沒有成功；改用 Void 之後，一個給 agent 的 prompt 就部署出能用的應用。他的結論是：把瑣碎的手動部署步驟拿走之後，agent 做事就能 one-shot。
平台開源的另一個用途是公司自架：部署在自己的 Cloudflare 上，每個 app 的登入自動接公司的 SSO，例如只有公司信箱能存取。這對團隊內部用 vibe coding 快速做小工具很實用，不用每做一個就重新處理驗證和存取控制。
四、後半：為 agent 重新設計工具鏈的七個原則
他先描述背景。今年初 Opus 4.6 發布時，他明確感受到 agent 產出的程式碼品質已經超過大多數工程師手寫；到 Opus 5.5，他說自己大概不會再手寫程式碼了。使用方式也在變：從 IDE 裡按 tab 補完，到在 CLI 叫 agent 修 bug，到丟一份 design doc 讓 agent 連續工作十幾小時，再到一台電腦同時跑三四個 session，甚至在雲端跑幾十上百個平行 agent。
他也提到這對開源的衝擊。MIT 授權的專案過去不怕被拿走，因為大家信任的是持續維護，而 fork 之後重寫和維護的成本都很高。AI 讓照著現成實作重做一份的成本大幅下降，這道靠維護信任建立的護城河正在變淺。他沒有給答案，只說這讓他重新思考開源該怎麼做。
然後回到工具。他的大前提是：人有偏好，工具要讓人寫得開心；agent 不在乎程式碼醜不醜，只在乎一致性、寫錯時有沒有編譯器糾正、結果能不能驗證。底下是他列的原則，我按他的順序轉述。
驗證速度決定 loop 效率
agent 的本質是一個 loop：tool call、驗證、下一步。模型本身不確定，所以每一步都需要工具驗證才能往下走。agent 寫程式其實很快，慢是慢在驗證：測試要跑五分鐘，agent 就空等五分鐘。
flaky 與 slow test 要在工具層根除
測試隨機失敗時，agent 會重跑好幾遍，最後回報「這個測試有時過有時不過，原因不明」。同一個測試花了好幾倍的時間，結論還是不確定。
設定只留事實，拿掉偏好
Prettier 出現前，大家為分號、空格、換行吵了好幾年，最後發現都不重要。下一代工具的選項應該只剩事實，例如檔案放在哪、要不要裝某個 plugin；要不要加分號這種問題根本不該是選項。
Codebase Understanding as a Service
仔細看 agent 的 tool call，它還在大量用 grep 做文字搜尋。工具鏈手上有 parser 和 module graph，回答「這個函式在哪些地方被用到」「這個模組被誰引用」可以比 agent 自己找快上百倍，應該提供一級的 API 給 agent。
Runtime observability 不靠看畫面
按了按鈕發生什麼事、CSS 有沒有載入，很多 agent 會起一個真的瀏覽器，用 Playwright 或 computer use 去看。工具鏈可以在頁面裡注入 JavaScript，直接把這些狀態用 API 交給 agent。
常駐 daemon，共享 parse 結果
即使 Rolldown、oxlint、Vitest 本身很快，每次從 CLI 呼叫都是從頭 parse、transform、resolve 同一批檔案。更好的模式是一個常駐行程把整個倉庫的 module graph 留在記憶體裡，lint、bundle、format 都是對同一份 graph 查詢，任務之間共享工作，做到真正的增量。
平行 worktree 之間共享不可變的 project graph
平行 agent 多半各自開一個 worktree，起三個 Vite dev server 記憶體就不夠。如果 project graph 是不可變的，可以像 immutable data structure 那樣在 worktree 之間做 structural sharing，相同的檔案只佔一份記憶體，每個 worktree 只為自己改過的部分付出額外成本。
他最後說，這些原則需要拋開既有的設計思路重新架構，他正在做一個還不能公開的專案，預計今年稍晚或明年初介紹。
五、我們怎麼看
我們每天同時跑好幾個平行的 agent session，每個各自在一個 worktree 裡工作。聽後半段的感覺是，他列的七點幾乎每一點我們都直接付過代價。
最直接的是驗證迴圈。我們的經驗和他說的一樣：agent 一輪改動很快，真正花時間的是等型別檢查、等測試、等 build。驗證慢不只是慢，還會改變 agent 的行為，它會開始猜「應該過了」，或者把等待時間拿去做沒被要求的事。flaky test 更糟，一個隨機失敗的測試會讓 agent 重跑、懷疑自己、最後交回一個不確定的結論，這種失效模式我們在 讓 AI 寫程式時，真正會出事的四個地方 也寫過類似的例子。
worktree 的資源成本我們也撞過。平行開工區最先撐不住的是記憶體和 dev server 的連接埠，我們目前的做法是限制同時存在的工作區數量、做完就收回，屬於管理層面的止血；他說的在工作區之間共享不可變的 graph，是從工具層把成本本身拿掉，方向不同。
grep 和截圖這兩點，我們的感受是「agent 拿到的證據品質」問題。用文字搜尋判斷「沒有人用這個函式」，搜不到不等於不存在；用截圖判斷畫面對不對，看得到的只有渲染結果，看不到狀態。工具鏈能直接回答結構化問題、直接交出 runtime 狀態，agent 的結論才有可信的依據。
設定只留事實這一點，對應的是我們寫規則的方式。早期我們的規則有很多「視情況判斷」，結果每個 agent 判斷都不一樣；後來改成只寫事實，能機械檢查的就交給 gate 擋，不留給 agent 自己判斷。這和他說的「Prettier 的教訓」是同一件事：選項越少，結果越一致。
最後是部署 one-shot。我們把網站部署在 Cloudflare 上，部署流程裡每多一個要手動補的步驟，agent 就多一個卡住、回頭問人的地方。Void 從程式碼推導資源的做法，是把這些步驟從流程裡整個刪掉，而不是寫更長的部署說明。
講到這裡你可能會想，這些不都是工具作者的工作嗎？一般團隊能做什麼？能做的不少。把測試跑快、把 flaky test 修掉或隔離、把手動步驟寫成可執行的指令、把「要記得」的規則改成會失敗的檢查，這些都不需要等下一代工具鏈。我們已經把上面幾點列為接下來的工程方向，順序就照他講的：先處理驗證速度，因為其他每一點的收益都要乘上它。
判斷標準只有一條：agent 等待驗證的時間，是不是比它寫程式的時間還長？ 如果是，你該優化的不是 prompt。