開始進入開發系統之前，我們要來先想一下專案架構要怎麼做。

前後端分離

現在比較流行的架構是前後端分離。比較常見的方案是前後端個一個專案各自一個檔案。但這樣子分離的話對於 vibing code 比較難，畢竟你兩個專案都開著你要同時個別和他們說要做什麼，有點不太切實際又麻煩。

所以我打算前後端都放在一個資料夾裡面！

git 多專案

在git 專案 我們傳統一個專案只有一個專案 叫做 Single-repo（單一 repo）。一個 Git = 一個專案，我這次的專案想要做成這個樣子：

Health/
├─ frontend/    # Next.js
└─ backend/     # Nest.js

在 Git 的世界裡，最傳統的做法就是 Single-repo（單一 repo）：一個 Git 倉庫就代表一個專案。比如你做一個網站，那整個 repo 就只放那個網站的程式碼；如果你要做一個後端服務，那就另外開一個新的 repo。這樣做很直覺，管理起來也簡單明瞭。

不過，當專案開始變大，或者需要前後端一起開發的時候，可能就會開始考慮 Monorepo（單一倉庫、多專案） 的做法。像我這次的專案，就是一個 repo 裡放了 frontend（Next.js）和 backend（Nest.js）兩個專案。

把程式碼分兩個資料夾，難道就一定是 Monorepo 嗎？其實不然。這裡有一個很重要的差別：

• 如果資料夾只是拿來「收納檔案」──例如放圖片、放文件、放一些零散的工具程式碼，那它只是 子資料夾。
• 但如果每個資料夾本身就是一個「完整的應用程式」，裡面有自己的 package.json、有獨立的啟動和部署方式，那它就算是 子專案（sub-project）。

這次的專案我們先叫他 Health (健康管理），frontend/ 是一個完整的 Next.js 專案，可以自己跑起來；backend/ 也是一個完整的 Nest.js 專案，也能獨立啟動。這就是 多專案結構。

不過我這次用的 git commit 是前後端各自己分開始使用。雖然它們都放在 HealthJ 裡，但每個子專案都是一個獨立的 Git repo（用 multi-repo 的方式管理）。這樣做的好處是：

• 前端、後端可以完全獨立開發與發布。
• commit 紀錄不會混在一起，歷史乾淨清楚。
• 要整合時，只要拉最新的 submodule 版本即可。

這樣做對 Vibing code 有什麼好處？

其實最大的好處就是：可以一次打開前端和後端，讓 AI 同時讀，然後一次產生跨前後端的程式骨架。

傳統如果前端、後端分開在兩個 repo，AI 可能一次只能讀其中一邊，你要自己切換 context、分別下指令，再把程式碼手動對齊，過程中很容易卡在「欸，這邊 API 怎麼跟前端對不起來？」。

但我現在用的方式，是在 HealthJ 這個專案裡同時放 frontend/ 和 backend/，再加上它們各自有獨立的 commit 歷史。這樣一來：

1. AI 能一次理解全貌：它同時看得到前端頁面和後端 API，能幫我生成彼此呼應的程式。
2. 需求一次講清楚：我只要打一個 Prompt，例如「幫我做一個登入系統，後端要有 JWT 登入 API，前端要有 login page，成功後跳轉 dashboard」，AI 就能同時在兩個子專案裡生成程式骨架。
3. 同步省心：因為 commit 歷史是分開的，我可以在前端 repo commit「feat: add login page」，在後端 repo commit「feat: add login api」，兩邊清清楚楚。最上層 HealthJ 只是負責把它們關聯在一起，管理很單純。

那要怎麼設定 git 專案呢？

老實說，我也不太清楚。我最早是分別先開了兩個專案──一個是前端 (Next.js)，一個是後端 (Nest.js)，各自都有自己的 Git。然後再開一個資料夾把它們放在一起。然後直接跟 Cursor 說：

「我想要把它們變成同一個 Git 專案。」

接著它就幫我跑了一些終端機指令，處理 submodule 的初始化、commit 的設定……最後就真的把兩個專案合併成一個大專案了。

你可以看到差別，就是 Health這個專案，裡面會有前端(HealthRecord-FE)和後端(HealthRecord)的專案然後字體會變成藍色，後面還會多一個 S 標記。這個 S 就代表 Submodule（子專案），意思是說它不是單純的子資料夾，而是「一個可以獨立存在的 Git 專案」，只是被包含在 HealthJ 這個大專案裡。

也就是說：

• HealthJ = 主專案
• frontend、backend = 子專案（有自己 commit 歷史的獨立 repo）