Vibe Coding 對 傳統編程，對 無代碼同規格驅動開發

如果你可以透過使用結果去判斷好壞，Vibe coding 係最快攞到可運作第一版本嘅方法，例如原型、內部工具同小型應用程式。對於大型、長期運作或高風險嘅軟件，而且必須有人理解每一行程式碼，傳統編程仍然係正確嘅選擇。無代碼就適合簡單嘅應用程式，全部都可以安安樂樂咁留喺某一個供應商嘅平台入面。至於規格驅動開發，即係先寫好計劃，再由 AI 去實作，就係用 AI 建置認真項目時嘅中間路線。

以下會講解每種方法點運作、花費幾多時間同風險，並提供一個簡單嘅選擇方法。如果你需要先了解基本定義，可以先睇 咩係 vibe coding。

四種方法一覽

Vibe coding

你用日常語言描述應用程式，AI 負責寫同運行程式碼，你就根據預覽畫面去引導方向。你係靠實際使用嚟測試，而唔係靠閱讀程式碼。

優點： 速度快，試新意念成本低，而且明白問題嘅人可以直接塑造產品。AI 應用程式建置工具亦會處理資料庫、託管同發布，所以整個流程都喺同一個地方完成。

缺點： 睇唔到嘅嘢，就判斷唔到。權限檢查、秘密資料處理同程式碼結構，喺畫面上都係睇唔見嘅。應用程式愈大，冇經審閱嘅程式碼就愈難安全地修改。

適合嘅情況： 應用程式嘅價值喺畫面上一眼睇得出、風險唔大，而且你寧願今日有一個可以運作嘅東西，都唔想下個月先有一個完美嘅。我哋嘅 vibe coding 例子 列出咗常見嘅項目。

傳統編程

由開發人員或者團隊去寫程式碼、審閱、測試同部署。現時 AI 助手經常都係其中一部分，但每一項改動都要由人去閱讀同負責。

優點： 完全理解同掌控。有人可以解釋系統點解咁運作，一年後安全地修改，亦可以通過審計。

缺點： 費時同成本高。一個簡單嘅預約應用程式，自由工作者可能要幾個星期先做得完。新意念要慢慢測試，而非開發人員每一次改動都要靠其他人。

適合嘅情況： 軟件要大規模處理金錢、健康或法律資料、要連接大量整合，或者服務數以百萬計嘅用戶，又或者需要由團隊長期維護好多年。我哋嘅指南 聘請開發人員定用 AI 建置 會分析當中嘅取捨。

無代碼

視覺化建置工具讓你用方塊組裝應用程式：呢度拖一張表，嗰度加一個表格，然後喺選單入面設定規則。全部都由供應商負責運行。

優點： 標準模式可以預期，通常有良好嘅內置託管同權限功能，而且唔使擔心程式碼。

缺點： 你要喺供應商設定嘅限制之內建置。當你需要方塊唔支援嘅功能，你就會卡住，或者要付錢搵變通方法；而且要離開呢個平台，通常要重新建置。

適合嘅情況： 你嘅應用程式屬於標準類型（目錄、簡單入口網站、表格工作流程），而且你樂意留喺該平台上。我哋喺 無代碼 對 AI 應用程式建置工具 詳細比較咗呢點。

Vibe coding 同無代碼嘅分別

人哋經常混淆兩者，因為兩者都唔需要你寫程式碼。分別在於底層。無代碼應用程式係某個平台嘅設定組合。Vibe coding 應用程式則係真實專案入面嘅真實程式碼，所以你幾乎可以要求開發人員可以建置嘅任何功能，之後更可以匯出。代價就係，冇嘢阻止 AI 建置出不安全嘅東西，而無代碼平台固定嘅方塊通常可以防止呢種情況。

規格驅動開發

隨住 AI 程式碼代理愈嚟愈好，好多開發人員發現，純 vibe coding 對於正式生產工作嚟講太鬆散。規格驅動開發加入咗結構：你（通常都有 AI 協助）寫一份規格，包括需求、設計決定同任務清單，然後代理逐項任務去實作，而你就按照規格審閱結果。而家有開源工具包同一啲 AI 編程工具，已經內置呢套流程。

優點： 計劃喺程式碼出現之前已經經過審閱，所以大錯誤可以及早發現。每項改動都可以追溯到某項需求。相比自由咁同 AI 傾偈，佢更能夠應付較大嘅程式碼庫。

缺點： 起步較慢，而且如果冇人持續更新，規格就會同程式碼脫節。審閱大量 AI 寫嘅改動好消耗精力，而且仍然需要一個看得懂程式碼嘅人。

適合嘅情況： 你正在借助 AI 為一個真實產品開發真實功能，並且需要佢容易維護。

為非開發人員而設嘅輕量版本

你唔需要一個正式框架，都可以借用呢個概念。開始傾偈之前，先寫一頁紙，描述第一版本嘅內容：邊個會用、有咩畫面、資料、規則，以及乜嘢唔包括喺內。然後叫 AI 提供一個計劃，批准之後先至讓佢開始建置。喺 Mythex 入面，Plan 模式就係做呢件事。我哋嘅 點樣用 vibe coding 建置應用程式 教學，就係由頭到尾都採用呢個方法。

點樣揀

回答以下四條問題：

1. 你可以透過使用嚟判斷嗎？ 如果可以，vibe coding 就適用。如果正確性取決於你睇唔到嘅計算、合規或安全問題，就要加入審閱。
2. 如果出錯會點？ 壞咗嘅習慣追蹤器只係麻煩；壞咗嘅薪金工具就係危機。風險愈高，就需要愈多結構。
3. 佢會用幾耐？ 一個為期一個月嘅推廣頁面，可以用 vibe coding 做完就擱置。用上好多年嘅系統，就需要有人理解嘅程式碼。
4. 邊個會去修改佢？ 如果永遠都係你自己，傾偈就夠用。如果會有團隊去改，你就需要可讀嘅程式碼同書面記錄嘅決定。

兩者並非互相排斥

今時今日最常見嘅路徑就係混合使用。先用 vibe coding 做原型，了解人哋真正想要咩。有咗用戶之後，就要放慢步伐：喺建置之前先計劃較大嘅改動，安排程式碼審閱，並且加入測試。如果產品持續增長，開發人員就會用傳統工具接手當中部分工作。

令呢條路徑成為可能嘅，正正係你擁有程式碼。揀一個容許你睇到同帶走程式碼嘅工具。喺 Mythex 上，程式碼編輯器同終端機由一開始就有（免費方案係唯讀），而 Pro 方案就加入編輯、匯出同 GitHub 同步功能，所以由「感覺」過渡到經審閱嘅程式碼時，唔使由頭再嚟。我哋嘅 點樣審閱 AI 生成嘅程式碼 指南會講解呢一步，而 vibe coding 工具比較 就會列出邊啲工具會俾你程式碼。

如果你想先試吓快速嘅一端，可以喺 AI 應用程式建置工具 開一個專案，睇吓 vibe coding 可以行到幾遠，然後先至需要更多結構。

常見問題