vibe-build

Vibe Build

一個完整的建構工作流程，由 AI 代理自主執行。使用者做產品決策；你做流程決策。永遠不要要求使用者解釋工作流程——遵循它。只在關於要建構什麼、偏好以及閘門批准時詢問使用者。

唯一規則

產品決策 = 使用者輸入。流程 = 你的。在問使用者任何事情之前，檢查是否屬於產品決策。如果不是，自己決定並繼續前進。

階段 0 — 引導（僅限新專案）

1. 確定技術棧。如果專案完全未定義，只問一個問題：「我們要建構什麼？（一句話就夠了）」。不要面談。
2. 自己研究技術棧：當前框架版本、推薦設定和標準專案佈局，使用網路搜尋和框架文件（使用專案的 documentation-lookup 能力或網路搜尋）。用 最多 5 行 總結決定——不要向使用者貼研究牆。
3. 在專案根目錄中使用 references/agentsmd-template.md 的模板撰寫 AGENTS.md。這是專案的憲法：後續每個階段在做結構性決定前都會讀取它，這樣使用者就不必重新解釋慣例。
4. 安裝專案所需的 臨時技能（最多 5 個），遵循 references/temp-skills.md。如果專案很簡單或你現有的技能已經涵蓋了，則完全跳過技能安裝。
5. 用 ≤ 15 行報告引導結果，呈現你提出的編號計畫，並在撰寫任何專案程式碼前 等待批准。

階段 1 — 規劃

• 產生一個編號的、有範圍的計畫。小任務你可以在一次會話中完成，明確推遲的項目留待後續。
• 獲得明確批准。如果使用者編輯計畫，編輯結果獲勝。
• 注意交錯：不要在計畫仍處於開放狀態時就開始建構。

階段 2 — 建構

• 在適合專案時遵循測試紀律：邏輯部分寫測試，一次性膠水程式碼手動檢查。不要為簡單的建構發明繁重的測試框架；也不要跳過那些錯誤會造成傷害的邏輯測試。
• 保持依賴最小化。每個依賴都是使用者繼承的負擔——除非有明確的回報，否則偏愛 stdlib/零依賴。
• 在每次結構性決定前檢查 AGENTS.md。以小的命名步驟提交，以便工作可以進行二分查找。

階段 3 — 驗證（在聲明「完成」之前）

執行專案，然後證明它有效：

• UI 存在 → 在真實瀏覽器中點擊瀏覽（使用 Playwright 或你的代理的瀏覽器工具），檢查主控台錯誤，驗證主要流程端到端。
• Web UI → 審查無障礙性和互動品質（焦點狀態、表單、深色模式、觸控）：如果有的話，使用設計指南審查技能，否則自行檢查。
• 觸及驗證、秘密、支付或使用者輸入 → 進行安全性檢查：輸入驗證、秘密處理（永遠不要提交秘密；使用環境變數替換）、最小權限預設值。
• 先有證據再有斷言：報告執行了什麼、通過了什麼，或者承認失敗並先修復。

階段 4 — 部署

• 「部署/推送上線/預覽連結」 → 透過專案文件指定的路徑進行部署。對於可部署到 Vercel 的專案，git-push 到連結的專案；當沒有登入時，回退到 vercel deploy --temporary 並傳回 URL。
• Pull requests：簡潔的內文——改變了什麼、為什麼、如何測試——不是差異敘述。
• 「完成」的提交意味著建構+測試在你剛剛收集的證據上通過。

階段 5 — 臨時技能衛生

臨時技能（階段 0 步驟 4）是專案範圍的。在專案結束時，或當某個臨時技能證明有廣泛用處時，建議將其提升到使用者的共享技能目錄（或刪除它）。永遠不要讓臨時技能悄悄變異為永久的全域安裝。

Token 節約（所有階段）

讀取最小足夠的檔案範圍；不要重新讀取你已經看過的整個檔案。完成一個階段後總結一次，而不是敘述每個步驟。偏好執行腳本和工具，而不是將它們的內容貼到對話中。讓技能按觸發條件懶加載——永遠不要將技能內容傾倒在對話中。

參考資料

• references/agentsmd-template.md — 在階段 0 步驟 3 期間閱讀並填寫。
• references/temp-skills.md — 在階段 0 步驟 4 期間，安裝任何臨時技能之前閱讀。