vibe-coding-prompt-template：把 AI 寫程式的流程，從「隨興」變成「有合約」
Templates and workflow for generating PRDs, Tech Designs, and MVP and more using LLMs for AI IDEs
秒懂
- 它是什麼？
- 這是一套以 Markdown 提示詞與 npx CLI 組成的開源工作流，目標是讓開發者在 AI IDE 裡從點子走到可驗證的 MVP。它的核心判斷是：文件先行、合約驅動，但代價是流程本身需要紀律。
- 適合誰用？
- 這套工作流適合單人開發者或小型團隊，尤其是那些已經在用 Claude Code、Cursor 或 Gemini CLI，卻苦於 AI 常常偏離需求、寫出無法驗證的程式碼的人。它不適合需要嚴格合規、或團隊成員不願遵循文件流程的組織，因為所有效益都建立在「先寫文件、再寫程式」的紀律上。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 6 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的不是「寫不出程式」，而是「不知道要寫什麼」
多數 AI 編碼工具的使用者痛點是：AI 能吐出程式碼，但吐出來的東西常常不是你要的。這個 repository 的出發點很直接，README 開頭就寫著「Your AI can write code. This workflow helps you decide what to build, check what works, and recover when it breaks.」換句話說，它假設程式碼生成已經不是瓶頸，瓶頸在於需求定義、技術選型與驗證方式。目標使用者是採用 Claude Code、Cursor、Codex 或 Gemini CLI 的開發者，尤其是初學者，Topics 裡就列了 beginner-friendly。它把開發流程切成五個步驟：Deep Research、PRD、Tech Design、Agent files、Build。前三個步驟可以在任何聊天工具裡完成，不需要先開 repository。這對還在評估點子的人來說，降低了起步門檻，你不需要一個既有的專案才能開始。
從提示詞到 CLI：文件與執行之間的分工
這個專案同時提供兩種使用路徑。第一種是純手動：把 part1-deepresearch.md、part2-prd-mvp.md 這些檔案的內容複製貼上到 ChatGPT、Claude.ai 或 Gemini，按順序執行。第二種是透過 npm 套件 vibeworkflow，在專案內執行 npx vibeworkflow，CLI 會檢查現有專案狀態，然後分流到「開始新專案」「繼續既有專案」或「東西壞了」三條路線。這個分流機制是關鍵，它讓工具不只是靜態的提示詞集合，而是能感知專案當下處境的動態流程。README 提到 Quick、Guided、Deep 三種規劃深度，讓提問數量跟專案規模成比例，避免小專案被過度盤問。另外還有 /vibe-change、/vibe-debug、/vibe-verify 這類斜線指令，從 0.3.0 版開始可用，代表 CLI 不只是產生文件，也參與變更與除錯的迴圈。
實際啟動：從 npx 到產生 AGENTS.md
最快的啟動方式，README 寫得很清楚：在 Claude Code、Cursor、Codex 或 Gemini CLI 的專案資料夾裡，直接說「Run npx vibeworkflow and follow its instructions.」。這個指令會觸發流程，接著工具會檢查資料夾裡有什麼。如果偏好自己掌控，可以手動複製提示詞。第一階段是 Deep Research，打開 part1-deepresearch.md，把全部內容貼進聊天工具，AI 會問你幾個關於點子的問題，你回答後它產生一份研究文件，建議存成 research-[YourAppName].md。第二階段是 PRD，把 part2-prd-mvp.md 的內容貼在同一個對話串或新對話，接續研究輸出。重點是：如果開新對話，必須先把研究文件內容貼回去，否則 AI 會失去上下文。文件產生後，進入執行階段，用 npx vibeworkflow 或手動貼上提示詞，生成 AGENTS.md 與 agent_docs/ 目錄，之後才開始寫程式。整個流程刻意把「思考」與「執行」分成兩個階段，文件是兩者之間的橋梁。
合約版本：v3.0.0 之後的轉變
這個專案的版本演進透露了設計哲學的轉變。v3.0.0 的釋出名稱是「The Contracts Release」，v3.1.0 則是「The Agent-First Release」。合約這個詞不是修辭，它指向 AGENTS.md 與 agent_docs/ 的角色：這些檔案不是寫給人看的備忘錄，而是寫給 AI agent 看的介面契約。AGENTS.md 告訴 agent 專案的規則、結構與驗證方式，agent_docs/ 則存放更詳細的技術脈絡。v2.4.0 叫「Audit & Hardening」，暗示先前版本可能缺乏檢查機制，這個版本補上了稽核與強化。從時間軸看，2026 年 4 月到 8 月之間，專案從稽核導向轉向合約導向，再轉向 agent 優先，代表作者認為未來的執行主體是 AI agent，而非人類逐步操作。這個方向對應了 AI IDE 的發展趨勢，但同時也意味著：如果你的工具鏈不支援 AGENTS.md 這類 agent 設定檔，這套工作流的後半段會失去著力點。
真正的限制：流程依賴紀律，而非工具
這套系統最脆弱的環節不是程式碼，而是人。Deep Research 要花 20 到 30 分鐘，PRD 要 15 到 20 分鐘，這些時間成本在 README 裡有明確標示。對一個只想趕快做出 prototype 的人來說，這個前置時間可能無法接受。更根本的問題是：提示詞的品質取決於使用者回答問題的品質。README 反覆強調「Answer them truthfully in the chat」，但這正是最難自動化的部分。如果使用者在研究階段隱瞞了限制，或對競爭對手一無所知，AI 產出的研究文件會反映這個盲點。另外，流程要求把研究與 PRD 文件存檔、在對話之間搬移內容，這在單一聊天工具裡可行，但一旦換工具或對話遺失，整個脈絡就斷了。CLI 的 npx vibeworkflow 緩解了部分問題，但手動路徑的使用者必須自己維護文件的連續性。這不是工具的缺陷，而是以提示詞為核心的方法論先天上的限制。
替代方案：從規範式到對話式的光譜
要評估這套模板的價值，可以對比兩類替代做法。第一類是完全不使用結構化提示詞，直接在 AI IDE 裡用自然語言描述需求，讓 agent 自由發揮。這種做法彈性高、起步快，但結果不可預測，正是這個專案試圖解決的問題。第二類是採用更嚴格的規範框架，例如要求所有需求寫成使用者故事或正式規格，再交給 AI 執行。這類做法嚴謹，但學習成本高，對小型專案可能過度工程。vibe-coding-prompt-template 落在兩者之間：它提供結構，但不強制特定格式，PRD 與 Tech Design 的產出仍然是對話式的，只是有先後順序。真正的差異在於它把「合約」文件放在程式碼之前，而且這些文件是給 AI 看的，不是給人看的。相較之下，傳統的 spec-driven 開發文件是給人看的，AI 只是執行者。這個轉變是這個專案最值得注意的設計選擇，也是它與既有方法論最大的不同。
維護成本與授權：MIT 背後的長期考量
從 repository 的活動來看，最後一次 push 是 2026 年 9 月，v3.1.0 在 2026 年 8 月釋出，顯示作者仍在積極維護。但維護成本對使用者而言，不只是上游的更新頻率。真正的成本在於：每當 AI IDE 的行為改變，或新的模型推出，這些提示詞可能需要調整。提示詞是脆弱的，它們依賴特定模型的回應模式，Claude 與 Gemini 的表現可能不同，README 雖然標榜支援多種工具，但沒有提供各工具的相容性矩陣。此外，AGENTS.md 的格式是否被所有 IDE 支援，也是需要驗證的問題。授權是 MIT，這表示你可以自由修改、商用、甚至再散佈，沒有 copyleft 的包袱。但這也意味著沒有保證，如果作者停止維護，你需要自己接手。對一個以提示詞為核心的專案來說，fork 的門檻很低，因為 Markdown 檔案沒有編譯依賴，這算是低風險的採用決策。實際採用前，建議先跑一次 npx vibeworkflow 在一個測試專案上，確認產出的 AGENTS.md 確實被你的 IDE 讀取，再決定是否投入完整流程。
編輯結論
這套工作流適合單人開發者或小型團隊，尤其是那些已經在用 Claude Code、Cursor 或 Gemini CLI，卻苦於 AI 常常偏離需求、寫出無法驗證的程式碼的人。它不適合需要嚴格合規、或團隊成員不願遵循文件流程的組織，因為所有效益都建立在「先寫文件、再寫程式」的紀律上。採用前應先確認：你的專案是否願意花 20 到 30 分鐘做 Deep Research，並接受 AGENTS.md 與 agent_docs/ 成為專案的一部分。若你只是想要快速產生程式碼、不打算維護需求文件，這套模板會變成多餘的負擔。
社群筆記