Vercel CI Beta 怎麼用？AI 寫程式更快後，測試如何只跑受影響的任務？
Vercel CI Beta 依 Turborepo 任務圖選擇受影響檢查。解析官方內部二至六倍加速口徑、GitHub 私有專案限制與 CPU 分鐘計費。
Vercel CI 處理的是程式代理加速提交之後的等待。代理可以很快送出修改，但程式送上去後，團隊仍要等測試跑完，才能知道能不能合併。當一天出現更多拉取請求，持續整合就可能成為新的排隊點。
持續整合通常簡稱 CI，意思是每次程式更新後，自動執行測試、格式或型別等檢查。10 月 28 日，Vercel 發布這項服務的 Beta，主張只執行這次修改真正影響的任務。
它讀取 Turborepo 的任務依賴圖，判斷哪些工作要跑、哪些可以從快取取回，再把需要執行的任務分到各自的運算資源。處理的是程式改完以後的回饋速度，而不是替代理寫出正確程式。
Vercel 表示，自家專案從推送到 CI 通過的等待時間縮短二至六倍。這是公司的內部成績，不能推成你的專案必然得到相同倍數，也不是本刊的獨立效能測試。
目前服務仍在 Beta，文件列出只支援 GitHub、Linux 與非公開儲存庫等限制。團隊還要確認工具版本與實際執行任務的運算費用，不能只看一行設定就認為導入已完成。
因此，起點是盤點原有檢查如何相依，而不是先把全部流程換掉。任務圖能準確反映程式變更，少跑檢查才有機會同時保住速度與回饋品質。
Vercel CI 為什麼要跟上程式代理的提交速度？
一次看似很小的程式修改，也可能觸發原有工作流程的整套檢查。對人手修改較少的專案，這段等待可能還能接受，當多個代理同時提交時，重複工作就更容易累積。
CI 的用處，是把每次修改放進一致的檢查環境。它可以發現型別錯誤、測試失敗或格式不符，讓審查者先知道基本狀態，而不必每次重新手動執行相同指令。
但「每次都要得到可信結果」不等於「每項任務都要從頭執行」。如果某項工作的輸入沒有變，前一次結果仍適用，就有機會從快取取回，將資源留給真的受影響的部分。
官方公布的二至六倍，量的是自家專案從 git push 到 CI 通過的整段時間。git push 是把本機程式變更推送到遠端儲存庫，這個時間包含的工作，會隨專案與配置不同。
因此，不能把倍數直接當成某一個測試執行速度的提升，也不能由此保證自己的專案省下多少時間。官方提到近八百萬次任務，範圍也包含自家專案與先前的非公開測試。
這些數字說明服務已有一段使用經驗，卻沒有消除導入比較的必要。要縮短等待，先得知道哪些工作真的依賴這次變更，再看目前等待發生在什麼地方。
Turborepo 任務圖，決定重跑與快取的邊界
Vercel CI 的選擇依據，是 turbo.json 裡宣告的任務與依賴。Turborepo 可以理解為管理多個程式套件與工作順序的工具，任務圖則把哪些工作要先完成、哪些工作依賴它們連起來。
團隊在想執行的任務上加上 ci 標記，服務就能依變更選擇相應工作。輸入沒有改變的任務可以從 Remote Cache 取回，其餘任務才進入執行，遠端快取預設開啟。
分開運算，不代表忽略先後順序
每項真正需要執行的任務，都有自己的運算執行個體，但仍要等依賴完成。假設測試必須先取得套件建置結果，就不能因為有獨立機器而提前跳過這個步驟。
另一方面，互不依賴的工作就不必全部擠在同一條依序執行的管線裡。這是任務圖可以改善等待的地方，實際能並行多少，仍要看程式本來如何組織。
例如一個共用套件同時供網站與管理介面使用，修改共用套件時，下游檢查可能都受影響。若只改了獨立文件，所需任務又可能不同。這是假設的結構說明，不是本刊量測過的專案。
以共用套件為例，若網站的檢查實際依賴它，任務設定就應保留這條關係。否則團隊原本想驗證的跨套件影響，未必能從檔案位置直接看出來。導入時讀懂任務圖，也是重新核對程式結構的一次機會。
因為服務依宣告判斷，未列清楚的輸入與依賴也會影響判斷品質。少跑任務只有在略過理由成立時才有價值，不能把任務數下降直接當成測試品質提升。
官方也把安裝相依套件放在每次執行的共同步驟，並跨更新保留相應快取，減少每項任務各做一遍。這與任務本身的結果快取不同，觀察時應分清省掉的是準備還是檢查。
先接入一組檢查，再比較既有流程
Beta 的一行標記，是既有任務設定上的入口，不代表完全省去接入條件。官方文件要求 Turborepo 2.11.7 以上與 Vercel CLI 64.3.1 以上，既有專案也要確認版本。
儲存庫必須先連到團隊的一個 Vercel 專案，再顯式啟用 CI，才會開始執行。只是把設定檔提交上去，不能直接當成服務已被啟用或每項檢查都已接好。
已經使用 Turborepo 的團隊，可以沿用任務定義。單一套件專案也能加入 turbo 套件與 turbo.json 使用，不需要為了這項服務，刻意把程式拆成很多套件。
官方提供設定 Skill，讓程式代理協助挑選初始任務、配置服務並開出拉取請求。拉取請求可以理解為把修改提出來供審查，產生設定與開請求，不等於團隊已核准切換正式檢查。
目前可用範圍還有幾項實際限制：基礎執行環境只有 Linux，程式來源只有 GitHub，不支援公開儲存庫，而且只能由推送程式觸發。
同一儲存庫至少要連到一個 Vercel 專案，也不能把專案分散連到多個 Vercel 團隊。若原流程依賴其他程式平台、特定作業系統或不同觸發方式，這些需求要先處理。
比較穩妥的導入方式，是先選原本就熟悉的一組檢查，對照新舊流程處理同一批變更的結果。這是導入建議，不是服務要求所有團隊照做的額外規則。
對照時還要記下快取是否已有內容。第一次準備新環境與重用既有輸入的後續執行，本來可能做不同數量的工作。若只挑一次很快的重跑，就無法說明團隊每天遇到各類修改時會花多少時間。
當結果有差異，要先追查任務是否確實被選中、所需輸入是否相同，再談誰比較快。新舊結果對得上之後，再切換必要檢查，才看得清少跑任務有沒有漏掉原本的回饋。
任務分開執行，失敗也要回到具體改動
把等待時間縮短，還需要讓代理知道哪個任務失敗、後面擋住了什麼。否則測試雖然更快結束，代理仍可能花很多時間在混在一起的紀錄裡尋找原因。
Vercel CI 提供儀表板、命令列與 MCP 入口。MCP 是把工具能力提供給代理呼叫的一種方式，讓代理不只等待最後狀態，也能查詢任務與執行紀錄。
官方列出的命令可以列出近期執行、查看其中任務、取得某項任務的錯誤輸出，或跨近期紀錄搜尋文字。這有助於分清是剛才修改造成錯誤，還是相同檢查先前已反覆不穩定。
假設一項共用套件建置失敗，下游測試因此尚未執行。代理應先看上游錯誤，不應把尚未得到結果的測試當成已通過，也不必對每個被阻擋的任務分別亂改程式。
若某項結果從快取取回，也要知道它對應的任務與輸入。快取可以避免重做，卻不會憑空補上專案沒有配置的檢查，所以綠勾的意義始終受檢查範圍限制。
服務會在 GitHub 拉取請求回報檢查結果，團隊可用分支保護規則阻擋失敗時合併。這把回饋接到既有審查流程，但人工需求判斷與重要修改的驗收仍有自己的責任。
因此，CI 回報可以協助代理修正，是否准許合併仍取決於團隊設好的檢查。加速的目標應是更快取得可解釋的結果，而非只讓介面更早顯示通過。
CPU 分鐘怎麼算：快一點不一定花得更少
Vercel CI 依使用的 CPU 數與執行時間計費，不能只用牆上經過幾分鐘估帳。多顆 CPU 同時工作，可能縮短等待，但也會累積各自的使用量。
官方把一個 CPU 執行一分鐘定義為一個 CPU 分鐘。每個執行個體依要求的 CPU 數乘上運行時間，時間包含停止前的清理，向上計至下一秒，最少一秒。
計費文件的例子是八個 CPU 執行兩分三十秒，合計二十個 CPU 分鐘。這個例子說明計算方式，實際 CPU 配置和用量仍依各項任務決定。
Pro 列出的價格為每 CPU 分鐘 0.0035 美元，Enterprise 另議。依前述例子計算，單項工作是 0.07 美元，仍未包含同次執行的啟動準備與其他工作成本。
準備步驟預設使用四個 CPU，每項任務預設兩個 CPU，配置可以調整。因此，若只看到某項測試的時間下降，還不能直接推出整次執行的費用也以相同比例下降。
從快取還原或因不受變更影響而略過的任務，不會真的執行，也不使用該任務的 CPU 分鐘。這解釋為什麼任務選擇與快取，都可能影響成本，但幅度仍取決於原來有哪些重複工作。
也可以用一組純假設數字看取捨：兩個 CPU 跑五分鐘是十個 CPU 分鐘，八個 CPU 跑兩分半則是二十個。後者等待較短、計費量卻較高。這只是算術示例，不表示增加 CPU 後，真實任務一定會按這個比例加速。
官方發布文說 Beta 對各方案開放，專用定價頁則列 Pro 與 Enterprise。Hobby 使用者不能自行把缺少一行專用價格，解讀成免費無限執行，應以帳號實際可用狀態與方案說明確認。
比較成本時，要同時看任務資源、準備步驟與快取，而不是只比某一條最快紀錄。這樣才看得出增加並行，究竟改善等待、增加費用，還是兩者同時發生。
哪些團隊適合先試，哪些功能仍要等？
已採用 Turborepo、GitHub 私有專案與 Linux 檢查的團隊，比較容易拿現有流程做對照。若程式代理正在大量提交，且很多檢查重複執行，這項服務處理的問題會更直接。
第一輪比較可以固定一組變更，保留推送到取得結果的時間、實際執行任務，以及使用量。遇到少跑的任務，就確認它是因輸入未變、快取命中，還是配置漏列。
第一輪也不必立刻移除舊流程的所有檢查。先在一組已知任務上比較結果，才能看出新平台接入造成的差異。若同時重寫測試、調整套件邊界又更換執行方式，出現不同結果時，就很難指出是哪一項變化造成。
如果原本沒有完整測試，換一個執行平台也不會讓缺少的行為自動被驗證。團隊仍需要定義哪些修改應觸發什麼檢查，讓任務圖反映真正想守住的品質。
官方把進階可觀測性、推送前的分散式執行，以及更細的測試選擇列為往正式開放前的計畫。這些方向不能當成 Beta 已經保證具備的共同功能。
把既有測試的可信度保住，才是加速 CI 後仍能讓人放心審查的條件。對程式代理來說，更快而且能追查的回饋，比單純多送幾次修改更有意義。
延伸閱讀：【Vibe Coding】AI 生出網頁卻只能自己看？Vercel 免費部署完整教學指南
延伸閱讀：Vercel Virtual Models 教學：同一個模型名稱，如何管理團隊 AI 設定？
常見問題
Vercel CI 會替專案自動寫好所有測試嗎？
它負責選擇、執行和回報已配置的任務，沒有保證替專案補齊測試覆蓋。設定 Skill 能協助接入，但測試是否反映需求，仍要由團隊確認。
單一套件專案也能用嗎？
官方表示可以加入 turbo 套件與 turbo.json 使用，仍需符合目前 Beta 的 GitHub 私有儲存庫、Linux、工具版本與專案連線等條件。
二至六倍代表我的費用也一定減少嗎？
這是 Vercel 自家專案推送至 CI 通過的時間改善。你的費用還受 CPU 配置、真正執行的任務與快取影響，應分開比較使用量和等待時間。
如果你想追蹤 AI 程式代理如何接上測試與部署，歡迎免費訂閱 AI 郵報。
