摘要： Vercel 在 2026 年 11 月 6 日的 changelog 中宣布，Vercel CLI 現在可以在部署時替新專案設定到期時間，到期後專案會自動刪除。這解決的是一個很實際的問題：原型、demo、測試用的 app 堆在帳號裡沒人清。功能需要 CLI v65.12.0 或以上版本。
機制怎麼運作
用法是直接在 vercel deploy 後面加上 --delete-project-after 和一個時長：
# 一天後刪除這個新專案
vercel deploy --delete-project-after 1d支援的時長有五種：1h、1d、1w、2w、30d。執行時 CLI 會印出專案確切的到期日期與時間，所以你不會只記得「大概一天後會消失」，而是拿到一個明確的時間點。
如果後來發現這個專案其實想留下來，可以用 vercel project keep 移除到期設定：
vercel project keep my-project也就是說，這不是單向的自毀開關。先設一個短的到期時間當保險，專案被證明有價值時再保留，這個流程是官方支援的。
一個關鍵限制：只在建立時生效
這個 flag 只在 vercel deploy 建立新專案時才會生效。如果你對一個已存在的專案部署時帶上這個 flag，該專案的到期設定不會改變，CLI 只會印出一個警告。
這對習慣把 flag 寫進腳本或 CI 設定的人特別重要：同一條指令，第一次跑會建立一個會到期的專案，第二次跑（專案已存在）則什麼都不會改。不要指望用它來「延長」或「修改」既有專案的到期時間。另外，官方文件目前並沒有說明既有專案能否透過其他方式補設到期，也沒有提到專案刪除時自訂網域或其他設定會怎麼處理——這些是這次 changelog 沒有交代、部署前值得先確認的部分。
為什麼對 builder 有感
如果你做產品，帳號裡的 Vercel 專案數量往往反映的不是在線產品數，而是過去幾個月做過多少實驗。每個 demo、每個給客戶看的一次性 prototype、每個測試想法的小 app，都佔著一個專案名稱和一列 dashboard 空間，真正要清的時候卻沒有人記得哪個還活著。
這件事在 agent 部署的脈絡下更急迫。我在先前討論 Vercel 的 Agentic Infrastructure 三層架構時提過，部署者正在從人變成機器——當 agent 大量建立一次性部署，沒有自動回收機制，累積的雜訊只會更快。--delete-project-after 算是把清理責任從「事後人工」移到「建立時聲明」，這是正確的預設方向。
和既有行為的銜接
順帶一提，vercel deploy 的文件裡有一個容易被忽略的行為：新專案的第一次部署永遠是 production 部署，即使你沒有加 --prod。之後要部署到正式網域才需要明確加上 --prod。
把這兩件事放在一起看，會發現 CLI 對「第一次部署」的態度是一致的：它假定第一次部署就是要給人看的東西（所以是 production、所以可以設到期）。換句話說，Vercel 把一次性部署視為常態工作流的一部分，而不是需要特殊處理的例外。
下一步該做什麼
先把 CLI 升級到 v65.12.0 以上，然後在你最常用的 demo 部署腳本裡加上 --delete-project-after 1w。驗證方式很直接：部署一個測試專案，記下 CLI 印出的到期時間，到期後確認專案確實從 dashboard 消失。同時檢查你的 CI 設定——如果有任何對既有專案反覆執行這條指令的流程，記得處理那個警告，因為它代表 flag 被靜默忽略了。
參考來源
在 X 上查看原貼文