共同開發的 AI 專案無法正常啟動

共同開發的 AI 專案無法正常啟動

承如《當我接手了一個夥伴用 AI 蓋好的專案》這篇文章說到：

我是一個比較偏向純前端的開發者。遇到不熟悉的後端語言、資料庫設定或是複雜的路由，我常常會陷入一種「不知該從何看起」的焦慮感。

持續在共同開發的模式下，在第一次合併程式後，啟動專案遇到了 backend-1 exited with code 255 這種報錯。無法立即判斷是哪裡錯誤了、沒有任何想法時，我試著把 AI 當成我的「除錯夥伴與導師」，展開除錯與學習過程。

提供完整的內容，而不是只給結果

如果只是把最後一行錯誤訊息貼給 AI，AI 對這個問題沒有邊際，就只能像瞎子摸象一樣，猜測是不是電腦記憶體不足或連線逾時。

我除了貼最後一行的結果，也把整個執行日誌（Log）提供給 AI。

當 AI 看到日誌訊息時，精準指出了問題的根本原因——資料庫的「版本紀錄（Migration）」出現了衝突與分歧（Multiple Head Revisions）。

不能只是 auto mode，而是問出背後的「為什麼」

AI 建議我去修改其中一份 Migration 檔案裡的 down_revision 欄位。

過去對於不理解的除錯，我的習慣通常是採用試誤法，把建議複製貼上後自己再去測試一遍。這次不照單全收 AI 的建議，而是先請 AI 向我解釋：「為什麼修改這個欄位就能解決問題？這背後的原理是什麼？」

透過 AI 的解釋，我才第一次真正搞懂了後端資料庫「版本控制」的運作邏輯：

【原本正常：單一線性的版本紀錄】  
[版本 1：初始資料庫] ──> [版本 2：新增功能 A] ──> [版本 3：新增功能 B] (最新 Head)  
▲ 資料庫紀錄與檔案一致，系統正常啟動。

【發生問題：兩個人同時開發，產生了平行分支（Multiple Heads）】  
                        ┌─> [版本 A：新增功能 A] ──> [版本 B：新增功能 B] (Head 1)  
[版本 1：初始資料庫] ──┤  
                        └─> [版本 C：新增功能 C] (Head 2)  
▲ 系統困惑：「資料庫到底要接在 Head 1 還是 Head 2 後面？」 ──> 報出 Exit Code 255

【修復方式：修改 down_revision 重新串接成一條直線】  
[版本 1] ──> [版本 A] ──> [版本 B] ──> [版本 C] (唯一最新的 Head)  
▲ 手動指定「版本 C 接在 版本 B 後面」，重新把線拉成單一歷史，系統成功啟動！

• 資料庫就像樹狀圖：每一次修改資料庫結構（新增欄位、修改表單），都會產生一張紀錄卡，並標記「我是接在誰後面」。
• 衝突的由來：當團隊裡有兩個人同時基於同一個舊版本開了新的修改卡時，資料庫就會出現兩條分歧的平行線（Multiple Heads）。這時候系統不是大人不能全都要，就會不知道該聽誰的，因而直接崩潰。
• 修改的意義：我手動將其中一張卡片的起點指定到另一張卡片後面，等於是把分歧的兩條線重新串成一條直線。

明白了這個原理後，我按照邏輯調整了檔案，系統立刻順利啟動，也讓我對後端資料庫的運作多一層了解。

切換分支再次卡關

就在我以為可以打包收工、切回同步主幹（Sync Fork）的分支時，卻又再次跳出了同樣的錯誤訊息。

查看日誌後發現寫著 Can't locate revision——因為剛剛我在測試分支時，資料庫已經被升級到了最新的紀錄，但切回主分支後，程式碼裡根本還沒有該檔案。

這其實是許多剛接觸 Docker 與後端開發時最常碰到的陷阱：為什麼 Git 程式碼已經切換回舊版本了，資料庫紀錄卻沒有跟著還原？

原因在於 Docker Volume 會將資料庫數據持久化儲存在本地硬碟中。Git 切換程式碼時，資料庫依然停留在剛才已 Migration 過的最新狀態，因而造成了「資料庫版號比程式碼還新」的版號不對稱問題。

有了前一次對原理的理解，我清楚知道當下的狀況，並能根據環境做出工程判斷：

• 最乾淨的做法（本地開發環境）：直接把本地的容器與資料庫資料清空重建（docker compose down -v），讓資料庫重新跟著主分支的紀錄一起回到原點。

• 保留資料的做法（測試或正式環境）：如果不希望清空測試資料，也可以直接連進資料庫，執行 SQL 指令更新 alembic_version 表單（例如 UPDATE alembic_version SET version_num = 'c3e2b8a4f1d5';），手動將版本號修回當前分支所擁有的 Head。

如何在協作中避免 Migration 衝突

經歷了手動修正 down_revision 與處理分支版號不對稱後，我也進一步思考：在 Fork + PR 的共同開發模式下，Migration 多頭衝突幾乎是常態，該如何從工作流上主動預防？

• 送 PR 前 Rebase upstream：在準備 Submit PR 之前，先拉取 upstream 最新主幹（git rebase upstream/main），確保自己的 Migration 檔是接在上遊最新的 Head 後面。

• 延後產出 Migration 檔：開發期間可在本地自由測試，準備提交 PR 之前，先刪除本地過渡用的 Migration 檔案，更新 upstream/main 後再執行一次 alembic revision --autogenerate 重新產出，確保版本紀錄乾淨無分歧。

建立專案除錯直覺

• 先釐清原理，再動手修正：遇到不懂的後端機制，把 AI 當成隨手可問的導師，問出背後的因果關係。
• 人機分工的核心：AI 負責加速問題定位與解釋運作機制；我們則負責理解原理、根據當下環境下判斷與驗收。
• 擴展技術視野：每一次踏實地踩坑與原理重建，都是把自己的技術視野往外擴展、建立對專案自主掌控感的過程。