vibecode-pro-max-kit：把規格驅動流程塞進 Claude Code 與 Codex 的提示層工具包

它要解的不是程式碼問題，是代理的失憶

README 開頭第一句就是「Your AI forgets. This remembers.」。這句話界定了專案範圍：它不改善模型能力，也不做程式碼生成，而是處理長流程中代理丟失上下文、跳過規劃直接產出程式碼的現象。專案自稱是給 vibecoders、產品負責人與 CEO 使用的 spec-driven coding harness，主語言是 JavaScript，授權 MIT。

目標使用者輪廓相當清楚。如果你用 Claude Code 或 Codex 做多階段功能開發，卻常在第二、第三輪對話後發現代理已經偏離原始需求，這個 kit 針對的正是那個場景。反過來說，如果你的工作是一次改一行、跑完就結束，整套七階段閘門帶來的儀式成本大於收益，README 自己也提供 Quick Fix 與 Fast Mode 這類輕量路徑來繞開重流程。

需要先講清楚的是，我沒有安裝或執行過這個專案。以下所有關於行為的描述都來自 README、release notes 與 repository 結構，不是實測結果。

七階段閘門與 RIPER-5：流程如何被寫死

核心機制是 RIPER-5 plan-first workflow，把開發切成七個帶閘門的階段：Research、Spec、Innovate、Plan、Validate、Execute、Update-Process。閘門的意義在於階段之間不能直接跳過，代理必須先產出該階段的產物才能進入下一階段。README 對這件事的說明是這套流程「stop the agent from jumping straight to code」。

其中 Spec 階段的定位值得單獨看。README 要求使用者在任何設計之前，用簡單的 user stories 陳述要建什麼，並稱這是「the cheapest place to catch a misunderstanding」。後續每個階段都要回頭對照這份 SPEC。這個設計把驗收標準前移到最便宜的位置，而不是等到程式碼寫完才發現方向錯了。

流程之外還有兩層自我修正機制。PVL 是 plan-check-fix 迴圈，EVL 是 test-check-fix 迴圈，各自最多跑 10 次。另有一個叫 vc-autoresearch 的可重用迴圈，可以指向 plans、tests、specs、docs 或 evals。這些迴圈是代理自動進行的，不是人工觸發。

10 次這個上限是硬約束，也是成本來源。每次迴圈都是一輪模型呼叫，如果你的任務本來就模糊，迴圈可能在同一個問題上反覆打轉直到觸頂。README 沒有說明觸頂後的行為是放棄、升級給人、還是帶著未解問題繼續，這一項在採用前值得確認。

autopilot 與 /goal：無人閘門的實際代價

專案描述裡寫著 autopilot loops with 0 need for human gate。README 的對應設計是 autopilot mode，分 quick、fast、full 三條路線，用一句話就能從任一階段啟動全程無人執行。搭配的 /goal 是一段可複製貼上的區塊，作用是讓代理一個階段接一個階段跑下去不停，並且能在新的 session 裡接續同一輪執行。

接續能力靠的是寫到磁碟的進度筆記。README 說 progress notes 每個階段都會寫入磁碟，所以執行能撐過記憶重置，從中斷處精確接回。這是整套設計裡最具體的機制：流程狀態不放在對話上下文裡，而是外部化成檔案。

但 0 human gate 是雙面刃。無人閘門意味著規格誤解、架構選擇錯誤、可行性判斷失準這三類問題都會被自動往下帶，直到某個 validator 或測試擋下來，或者一路帶到 Execute 階段才爆開。README 另外提到 feasibility probes 會給出 VIABLE 或 NOT-VIABLE 的判定，以及 intent clarification 會在需求模糊時先問幾個尖銳問題。這兩個機制是對無人閘門的補償，但它們的觸發條件在提供的材料裡沒有細節。

換句話說，這個 kit 把「人在迴圈裡」換成了「規則在迴圈裡」。規則寫得好不好，決定了無人執行是效率還是災難。

安裝、更新與那條 curl

README 說安裝是 one-command install，用一行 curl 把 kit 放進任何專案，會偵測新使用者與回訪使用者，並且 never overwrites your files。完整的指令字串在提供的 README 內容中被截斷，因此這裡不複製。實際安裝前請直接到 repository 的 README 取用原文指令。

生命週期指令包含 install、setup、update、publish，README 說各是一條指令。更新走的是 vc-update。從 release notes 可以看到這個指令近期有兩次行為調整：v3.2.3 讓 vc-update 在版本相同的安裝上也執行 adaptive migration；v3.2.4 修掉 install.sh 的 data-loss 問題，做法是把內容目錄的處理延後交給 vc-update。v3.2.5 則是 Windows 安裝指引。

這三個版本號連在一起看，訊息比單獨看任何一個都清楚。v3.2.4 的修正標題直接寫著 data-loss fix，代表在此之前 install.sh 對內容目錄的處理會造成資料遺失。一個安裝腳本曾經有資料遺失缺陷，而修法是把它移出安裝路徑、交給更新指令處理。這不必然是現在的風險，但它說明安裝與更新路徑的邊界在這一系列版本中才剛穩定下來。

實務上的推論是：升級前先備份，並且在非主要工作目錄上試跑一次 vc-update。README 沒有提供 dry-run 選項的說明，所以驗證方式只能靠實際執行後的檔案比對。

驗證靠的是 36 個 validator，不是模型判斷

README 提到 36 validators，描述為 mechanical correctness checks，用途是守住 kit 自身的結構、在出貨前攔住漂移。同一段強調這些檢查「not opinions」。

這個區分是專案設計上最值得肯定的一點。多數 AI 流程工具把品質判斷交給模型，結果是驗證本身也變得不可靠。把 kit 結構的檢查降級成機械式規則，等於承認模型不適合驗證自己的輸出格式。

但範圍要說清楚：這 36 個 validator 檢查的是 kit 自己的結構，不是你的應用程式碼品質。README 沒有把它們描述成通用 lint 或測試框架。如果你期待它們替你抓出業務邏輯錯誤，方向就錯了。另外 README 也提到 CI 走 validate.yml，但同樣沒有細節。

文件在這塊偏薄。validator 的具體清單、失敗時的輸出格式、能不能單獨執行某一個 validator，在提供的材料裡都看不到。這是採用前應該翻 repository 目錄確認的部分。

15 個 agent、33 個 skill、10 個 hook：規模的另一面

kit 內含 15 個 agent、33 個 skill、10 個 hook，README 說這些都是 out of the box 接好的。skill 採分層組織並自動探索，代理在每個步驟會找到對應工具。另有 smart strategy picker，在每個階段前權衡單一 agent、多 agent 或協同團隊，附上成本估計，選最便宜且能滿足需求的方案。

規模本身不是品質證明。15 與 33 這兩個數字真正的問題是：它們各自的職責邊界在哪裡、重疊多少、維護者要花多少心力讓它們保持同步。33 個 skill 若沒有清楚的分層規則，自動探索反而可能挑錯工具，而 README 只說「organized in clear layers」，沒有給出分層的判準。

有一項設計意圖很明確且合理：smart model use，README 說昂貴的模型只負責寫程式碼，其餘工作交給較便宜的模型。這在成本上是有意義的切分，因為規劃與檢查的 token 消耗往往不亞於寫碼本身。

至於 self-improving project memory，README 說它在 setup 時學習你的程式庫，並在每個功能出貨後更新自己的共享筆記。這個機制聽起來是解決文件過期的合理方向，但「學習」的實際內容與更新時機在材料中沒有可驗證的細節，我不會把它當成已確認的能力。

什麼情況下不該用它

第一個不該用的情況是短命任務。一行修正、臨時腳本、拋棄式原型，這些都不需要七階段閘門。README 提供了 Quick Fix 與 Fast Mode 來處理，但如果你連選路線的時間都想省，直接開一個新對話更快。

第二個情況是提示層檔案不能進版控的團隊。這個 kit 的產物是指令檔、agent 定義與 hook，它們會落在專案目錄裡。如果你的 repository 有嚴格的檔案白名單，或法遵要求所有進版控的內容都得經過審查，這套東西會撞上流程。

第三個情況是對可重現性要求極高的環境。整個 kit 的行為取決於代理是否讀取並遵守這些指令檔。README 說它支援 Claude Code、Codex、Cursor、Windsurf、Copilot 等，但「支援」在提示層工具裡的含義通常是「檔案放得進去」，而不是「行為一致」。不同代理對同一份指令的遵守程度會不一樣，這點材料裡沒有比較。

最後，如果你的瓶頸是模型能力不足而非流程缺失，這個 kit 幫不上忙。它管的是順序與記憶，不是推理品質。

對照組：Spec Kit 與純 CLAUDE.md 的差異

最直接的替代方案是 GitHub 的 Spec Kit，同樣走規格驅動路線，同樣把規格當成流程起點。兩者的差異在強制力來源。Spec Kit 以 CLI 指令與範本檔案為主，流程步驟由使用者主動呼叫；vibecode-pro-max-kit 則把流程寫成代理的常駐指令與 hook，加上 autopilot 與 /goal 這類無人執行的路徑。前者是工具，後者是環境。

第二個對照組更貼近現實：一份手寫的 CLAUDE.md 加上幾條專案慣例。這是多數團隊實際在用的做法，成本為零，彈性最大。差別在於它沒有閘門、沒有 PVL 或 EVL 迴圈、沒有進度筆記寫回磁碟、也沒有 36 個結構 validator。當你的專案只有一個開發者和一份程式碼庫時，手寫 CLAUDE.md 通常夠用；當專案有階段依賴、多人協作、或需要跨 session 接續時，缺口才會顯現。

值得注意的是，vibecode-pro-max-kit 的價值集中在「流程狀態的外部化」。這是它與前兩者最實質的差別，也是判斷要不要採用的核心問題：你的專案是否真的需要把流程狀態從對話中抽離出來。

MIT 授權與維護成本

授權是 MIT，寬鬆，可商用，可修改，可再散布，只需保留著作權聲明與授權條款。這裡不提供法律意見，涉及公司內部規範時請自行確認。

維護成本要分兩塊看。第一塊是 kit 本身的升級，由 vc-update 負責，而 v3.2.3 與 v3.2.4 的 release notes 顯示這條路徑仍在調整中，包含版本相同時也執行 adaptive migration 這種行為。這意味著升級不是無感的，你可能需要檢查每次更新後專案目錄的變化。

第二塊是流程負擔。七階段、雙迴圈、多 agent 策略選擇，這些都會消耗模型呼叫次數。smart model use 把寫碼留給昂貴模型、其餘交給便宜模型，是成本控制手段，但沒有改變「流程本身要花錢」這件事。PVL 與 EVL 各 10 次的上限是天花板，不是平均值。

README 沒有提供任何成本估算數字，我也沒有實測，所以無法給出可引用的金額。能確定的是：這個 kit 的成本結構與你的任務複雜度直接相關，越模糊的需求越容易把迴圈推向觸頂。

編輯結論

這個 kit 適合已經固定使用 Claude Code 或 Codex、而且痛點明確落在「代理忘記上下文、跳過規劃直接寫碼」的團隊；不適合只需要一次性小修改、或不想讓提示層檔案進入版控的人。採用前先確認三件事：install.sh 與 vc-update 對既有內容目錄的處理方式是否符合你的備份策略、你的代理是否真的會讀取這些指令檔、以及 PVL 與 EVL 各 10 次迴圈在你的模型計費下會產生多少成本。若這三點都能接受，它換來的是一份寫在磁碟上、可被版本控制的流程契約。

官方來源

1. Issues
2. License: MIT
3. README
4. Releases
5. withkynam/vibecode-pro-max-kit on GitHub