---
title: "氛圍編程專案的結構性問題與4小時修復衝刺"
locale: zh-hant
category: how_to
category_name: "操作教學"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/vibe-coding-project-architecture-and-four-hour-rescue-sprint
published_at: 2026-07-30T13:43:49+09:00
---

# 氛圍編程專案的結構性問題與4小時修復衝刺

> 氛圍編程專案在發布前夕受阻，原因可能不在提示詞能力，而在於結構不明確、程式碼缺乏一致性，以及外部服務之間的邊界。4小時修復並非保證完成整個服務，而應理解為一場有條件的衝刺：固定範圍並重新實作核心流程，以建立可執行的基準線。

## Key Points

- 問題不在React、Next.js、Supabase本身，而是在沒有責任邊界與實作規則的情況下組合使用時，複雜度會迅速增加。
- AI不會自動保留整個儲存庫的設計意圖與營運條件，因此相同功能可能會以不同模式實作。
- Ruby on Rails透過慣例與整合式元件減少選擇，但不會自動解決付款、安全驗證與營運準備等問題。
- 4小時修復是在需求已確定、核心範圍狹窄、帳號與基礎設施已備妥，且由熟練人員執行時，才有可能完成的初期重建或穩定化工作。
- 要繼續修補現有程式碼或重新建置，不僅要考量程式碼狀態，也應一併比較資料遷移、外部整合、測試、團隊能力與發布風險後再做決定。

氛圍編程是指運用自然語言指示與 AI 編程工具，快速實作應用程式的工作方式。初期畫面與功能會迅速增加，但越接近發布，越容易暴露出認證、資料、付款、部署等橫跨多個層級的問題。

不能只用特定技術堆疊的缺陷或使用者的提示詞能力來解釋這種現象。核心在於：**由誰控制結構一致性**、**各組成要素的責任是否明確**，以及**是否有測試能驗證工作是否完成**。

## 氛圍編程專案為何會在後期卡住

### 畫面完成不等於服務完成

在開發初期，按鈕、輸入表單、清單等可見成果可以快速完成。但實際服務還需要下列不可見的條件。

- 權限檢查，確保使用者只能存取自己的資料
- 能承受重複請求與網路重試的資料處理
- 付款成功、失敗、取消、退款與 Webhook 驗證
- 輸入值驗證與錯誤復原
- 資料庫變更與既有資料遷移
- 密鑰管理、日誌、監控、備份與還原
- 即使部署後也能確保核心功能持續運作的自動化測試

僅憑畫面能夠運作，並不代表這些條件已經獲得滿足。後期發現的缺陷並非突然產生，很多時候是初期實作未經確認而逐漸累積的結果。

### AI 無法始終維持整個儲存庫的設計意圖

AI 編程工具會根據指定的檔案、對話脈絡、搜尋到的程式碼與指示產生變更方案。如果專案規則沒有文件化，就可能發生下列不一致。

- 在伺服器元件、API 路徑、瀏覽器程式碼中，以不同方式實作相同的資料查詢
- 在 Cookie、客戶端狀態、外部 SDK 中重複管理認證狀態
- 在畫面與伺服器中以不同方式撰寫相同的驗證規則
- 不從根本上解決錯誤，只是不斷增加例外處理或條件判斷
- 因找不到既有抽象層，而重複建立相似的函式與資料模型

在這種狀態下修正新錯誤時，某一層級的修改可能破壞其他層級的假設。使用者會覺得 AI 一直在原地打轉，但實際情況可能是缺乏一套讓 AI 遵循的單一結構與驗證標準。

## 正確理解 React、Next.js、Supabase 的組合

將 React、Next.js、Supabase 簡單定義為不良的拼裝式技術堆疊並不準確。每項技術都有廣泛使用的獨立角色與優點。

| 技術 | 基本角色 | 專案中需要決定的事項 |
|---|---|---|
| React | 用來建立使用者介面的函式庫 | 狀態管理、資料請求、元件邊界 |
| Next.js | 以 React 為基礎的全端 Web 框架 | 渲染方式、伺服器與客戶端邊界、快取與 API 結構 |
| Supabase | 提供 PostgreSQL、認證、儲存空間等功能的後端平台 | 存取政策、資料模型、工作階段處理、服務權限 |
| Ruby on Rails | 以伺服器為中心的整合式 Web 應用程式框架 | Rails 慣例下的模型、控制器、工作、郵件與部署結構 |

Next.js 不只是負責畫面的工具，也提供伺服器功能。Supabase 同樣不只是資料庫，還可包含認證與儲存空間等功能。問題會發生在使用多種功能時，沒有決定**權限與商業規則的最終責任歸屬**。

例如，若建立訂單的規則分散在瀏覽器程式碼、Next.js 伺服器路徑、Supabase 資料庫政策中，就很難追蹤錯誤。反之，如果規定寫入操作必須經過伺服器服務層，而資料庫政策則作為最後一道防線，那麼相同的技術堆疊也能穩定運作。

## Ruby on Rails 為何能成為替代方案

### 以慣例優先減少選項

Ruby on Rails 的代表性原則「慣例優先」，會透過框架的預設規則，統一需要反覆做出的結構性決策。模型、控制器、資料庫變更、工作、郵件、測試的位置與連接方式都相對可預測。

這種可預測性在 AI 編程中特別有用。遵循明確慣例，可降低 AI 以完全不同的模式加入新功能的可能性，也能讓人員更容易審查變更內容。

### 在單一體系中處理 Web 服務的常見功能

Rails 為資料庫存取、路由、伺服器端渲染、非同步工作、郵件、即時通訊、測試與部署提供官方元件及路徑。因此可以減少不同工具之間的連接處。

不過，它也有下列明確限制。

- 付款處理仍然需要 Stripe 等外部付款服務商。
- 管理員頁面不會自動完成並符合所有需求。
- 即使產生認證功能或透過函式庫進行設定，權限設計與安全審查仍是獨立工作。
- 複雜的即時介面或獨立的行動裝置 API 需要額外設計。
- 如果團隊沒有 Rails 經驗，就會產生學習與招募成本。

因此，Rails 並不是讓 AI 解決所有問題的工具，而是**縮小 AI 與人員應遵循之基本路徑範圍的選項**。

## 4 小時內能解決什麼

沒有普遍依據能證明，包含登入、付款、管理員功能、資料遷移、安全審查與正式環境部署在內的任意服務，都能在 4 小時內完成。現實的 4 小時目標如下。

- 掌握目前的結構與失敗點。
- 在維護修復與重新實作之間做出選擇。
- 讓一項最重要的使用者流程運作起來。
- 建立可測試的新基準線。
- 如果可行，部署到預備環境。
- 列出剩餘風險與後續工作。

### 可在 4 小時內重新實作的條件

符合的下列條件越多，就越有可能在短時間內重新實作。

1. 所需畫面與使用者流程已經確定。
2. 核心資料欄位與關係已整理完成。
3. 不必重新討論設計，可以參考既有畫面。
4. 可以立即存取儲存庫、網域、部署環境與外部服務帳戶。
5. 可以省略既有資料遷移，或只需遷移少量樣本。
6. 付款僅限於沙盒環境的基本成功流程等狹窄範圍。
7. 了解 Rails 與部署環境的工作人員會審查 AI 的輸出。

進行了數個月的既有專案之所以有幫助，原因也在於此。如果這段期間已具體化使用者流程、必要欄位、失敗案例與優先順序，就能減少探索時間。但這並不代表規劃會自動變得完美，只應重複使用已在既有專案中驗證的需求。

## 實戰 4 小時復原衝刺

| 時間 | 工作 | 最低交付成果 |
|---|---|---|
| 0:00~0:30 | 保存儲存庫與營運狀態、調查技術堆疊 | 備份、組成要素清單、機密資訊外洩檢查 |
| 0:30~1:00 | 確定核心流程與資料模型、決定修復或重新實作 | 一句話範圍、完成條件、風險清單 |
| 1:00~2:00 | Rails 基準線或既有專案的結構性修改 | 可執行的應用程式、資料模型、認證骨架 |
| 2:00~3:15 | 垂直實作核心使用者流程 | 從畫面到資料儲存皆已串接的一項流程與測試 |
| 3:15~3:45 | 外部整合的最低限度設定與預備環境部署 | 沙盒整合、部署 URL、環境變數設定 |
| 3:45~4:00 | 冒煙測試與交接 | 成功與失敗結果、未完成項目、後續工作順序 |

### 第 1 階段：保存原始內容

修改前，為儲存庫建立獨立分支或副本，並備份資料庫。不要在 AI 對話中貼上 API 金鑰、資料庫密碼、個人識別資訊。如果已經外洩，較安全的做法是撤銷該機密資訊並重新核發。

### 第 2 階段：以證據調查技術堆疊

不要只要求 AI 猜測技術堆疊，而應要求它確認下列資料。

- 記錄套件與版本的資訊清單及鎖定檔案
- 資料庫結構描述與遷移
- 處理認證與工作階段的檔案
- API 路徑與伺服器函式
- 部署設定、環境變數名稱、外部服務 SDK
- 自動化測試與持續整合設定

可使用的請求範例如下。

> 閱讀儲存庫，並將前端、伺服器、資料庫、認證、儲存空間、付款、部署、測試工具整理成表格。寫出作為各項判斷依據的檔案路徑，並標示商業規則重複的位置，以及可能違反伺服器與客戶端邊界之處。暫時不要修改程式碼，也不要輸出機密值。

### 第 3 階段：只選擇一項核心垂直流程

垂直流程是從畫面到伺服器邏輯與資料儲存均已串接的一條完整路徑。例如：

- 註冊會員 → 登入 → 查看個人資料
- 選擇商品 → 建立訂單 → 付款沙盒核准
- 管理員登入 → 撰寫文章 → 顯示於公開頁面

與其一次製作多個畫面，不如以成功、無權限、錯誤輸入等條件驗證一項核心流程，這樣能更快暴露結構性風險。

### 第 4 階段：用測試固定完成條件

如果只要求 AI 實作功能，可能會產生僅針對畫面上成功案例的程式碼。至少應透過自動化測試或可重複執行的檢查清單，固定下列條件。

- 正常使用者可以完成操作。
- 未登入的使用者無法存取受保護的資料。
- 即使輸入其他使用者的識別碼，也無法存取該資料。
- 錯誤輸入不會被儲存，並會傳回可理解的錯誤。
- 即使重複傳送相同付款或寫入請求，也不會重複處理。

### 第 5 階段：僅部署到預備環境

一般而言，將 4 小時衝刺中的部署視為預備環境驗證，而非正式環境定案，會比較安全。在接受真實使用者與付款之前，必須另外確認安全、資料遷移、備份還原、監控與事故應變。

## 決定修復既有專案或重新建置的標準

| 情況 | 維持並修復既有結構 | 考慮以 Rails 等重新實作 |
|---|---|---|
| 核心功能與測試 | 大多正常運作且已有測試 | 連核心流程都反覆故障 |
| 資料 | 正式環境資料很多，遷移風險高 | 沒有資料或遷移範圍很小 |
| 結構 | 責任邊界與模式大致一致 | 相同功能重複出現在多個層級 |
| 前端需求 | 複雜互動與既有 React 資產很重要 | 以伺服器為中心的 CRUD 與工作流程為主 |
| 團隊能力 | 有能力維運目前技術堆疊的人員 | Rails 慣例更適合團隊的工作方式 |
| 外部整合 | 已有多項穩定整合正在運作 | 整合處於初期階段或可以替換 |

不能只因檔案數量多或存在錯誤，就全面重寫。重寫可能會失去過去已解決的例外情況，並產生新的缺陷。最好先以兩種方式實作一項小型垂直流程，再比較開發速度、可測試性、程式碼可理解性與部署風險。

## 發布前需另外確認的項目

即使已建立 4 小時基準線，仍可能留下下列項目。

- 權限模型與 Rails 安全設定審查
- 付款 Webhook 簽章、防止重複、取消與退款處理
- 正式環境資料遷移，以及筆數與總計驗證
- 資料庫備份與實際還原測試
- 錯誤追蹤、日誌保存、可用性監控
- 負載測試與成本估算
- 個人資料處理、使用條款與相關法律審查
- 無障礙功能、瀏覽器與行動裝置環境檢查
- 發生事故時的復原程序與負責人指定

## 結論

氛圍編程專案的後期停滯，不能只用 AI 的編程能力來解釋。在自由度較高的架構中，如果沒有制定規則、責任邊界、測試與維運標準，AI 建立的局部解法就很容易彼此衝突。

Ruby on Rails 可透過慣例與整合式結構降低這種自由度，成為實用的替代方案。但將所有專案都改用 Rails 重新建置並不是正確答案。應先根據證據調查目前的技術堆疊，確定核心流程，再將 4 小時用作**驗證結構並建立可復原基準線的時間，而不是製作完整成品的時間**。

## FAQ

### 為什麼氛圍編程專案一開始很快，到了後期卻會變慢？
因為初期有許多工作是在建立肉眼可見的正常流程，但後期則會集中處理權限、資料一致性、失敗復原、付款、部署與安全性等需要串聯多個層級的問題。如果缺乏架構規則與測試，AI 加入的局部修改會與既有程式碼衝突，速度可能因此進一步下降。

### 使用 React、Next.js、Supabase 的組合，就一定會變成義大利麵式程式碼嗎？
不是。這三項技術都是各自具有明確角色的工具，熟練的團隊可以用它們打造穩定的服務。問題在於，未先界定資料存取、驗證、業務規則與錯誤處理的責任，就在多個層級重複實作相同功能。

### 改用 Ruby on Rails 後，就不再需要任何外部服務了嗎？
不是。Rails 能以一致的體系處理資料存取、工作處理、郵件、即時通訊、測試與部署，但支付業者、郵件傳送基礎設施、雲端託管與監控等外部服務仍可能有其必要。

### 真的能在 4 小時內重新製作整個應用程式嗎？
無法普遍保證。如果需求與資料模型已確定、核心流程非常精簡、外部帳戶與部署環境已準備就緒，且由熟練人員審查 AI 的結果，就有可能建立可執行的基準版本或小型 MVP。達到營運等級的安全性、付款例外處理、資料遷移與故障應對，通常需要額外時間。

### 有哪些跡象顯示應該放棄既有程式碼並重新編寫？
如果核心業務規則重複出現在多個位置、小幅修改持續破壞不相關的功能、沒有自動化測試，而且目前資料量仍少，使遷移成本較低，就可以考慮重新實作。如果營運資料與穩定的外部整合很多，或目前的架構已有測試，漸進式修復可能更安全。

### 該如何讓 AI 調查目前專案的技術堆疊？
應要求 AI 讀取套件檔案、鎖定檔案、資料庫結構描述、驗證程式碼、API 路徑、部署設定與測試檔案，並將各項技術的角色與依據檔案整理成表格。最好要求它不要直接修改程式碼、不要輸出機密值，並標示重複的業務規則與可能違反邊界的情況。

### 在 4 小時的復原作業中，最先應實作什麼功能？
應選擇一個最能代表服務價值的核心使用者流程。不應只製作畫面，而要一路串聯驗證、伺服器端驗證、資料儲存與失敗處理，並測試正常使用者與未獲授權使用者的情況，才能快速判斷架構是否合理。

### 使用 Rails 就能自動解決安全性問題嗎？
不是。Rails 提供多項安全性預設值與防護功能，但無法自動防止權限遺漏、機密資訊外洩、存在漏洞的外部整合與錯誤的部署設定。應遵循框架的安全指南，並另行審查各應用程式的權限與資料流程。

## Sources

- [學習 React](https://react.dev/learn)
- [Next.js 文件](https://nextjs.org/docs)
- [Supabase 文件](https://supabase.com/docs)
- [Rails 信條](https://rubyonrails.org/doctrine)
- [Ruby on Rails 指南](https://guides.rubyonrails.org/)
- [Active Job 基礎](https://guides.rubyonrails.org/active_job_basics.html)
- [Action Mailer 基礎](https://guides.rubyonrails.org/action_mailer_basics.html)
- [Action Cable 概覽](https://guides.rubyonrails.org/action_cable_overview.html)
- [Ruby on Rails 安全指南](https://guides.rubyonrails.org/security.html)
- [Rails 應用程式測試指南](https://guides.rubyonrails.org/testing.html)

## Images

![開發者站在糾結的系統連線與井然有序的分層架構之間](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDI0OSwicHVyIjoiYmxvYl9pZCJ9fQ==--671c6671ab2b4dd55a12c8db4a32cd95021e1402/ai-ff797ac5.webp)
![開發人員修復連接崩裂懸崖與穩固平台的橋梁，周圍有安全與部署圖示](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDI1NSwicHVyIjoiYmxvYl9pZCJ9fQ==--dd1b9b18b3b924f01625710e0b4bafd8fbbd0002/ai-74d32191.webp)