畫面完成之後，資料去了哪裡？
用 AI 製作網站，往往很快就能看見成果：活動介紹、輸入欄位、報名按鈕，甚至連「報名成功」的畫面都有了。但使用者填寫的資料存在哪裡？重新整理後還找得到嗎？兩個人同時搶最後一個名額，系統會怎麼處理？
這些問題，都與前端、後端和資料庫如何串接有關。AI 可以協助建立程式、設定連線與排查問題；一般報名流程上線後，則由程式與資料庫執行，不必每次都呼叫 AI。理解這個差異，才能知道 AI 做出了什麼，以及哪些部分還需要驗證。
本文用一場假設的攝影工作坊，追蹤參加者「小林」的一筆報名。從填寫表單到查回紀錄，每一步都對應一項可以檢查的結果。
前端、後端與資料庫，各自負責什麼？
| 部分 | 主要工作 | 報名系統中的例子 |
|---|---|---|
| 前端 | 顯示資訊、收集輸入、呈現結果 | 活動頁面、姓名欄位、送出按鈕 |
| 後端 | 驗證資料、執行規則、處理請求 | 檢查截止日期、名額與重複報名 |
| 資料庫 | 保存紀錄、維護資料關係 | 活動資料、報名編號與報名狀態 |
API 是前後端交換資料的介面。可以把它想成有固定格式的服務窗口：前端按照約定提出請求，後端處理後，再回傳結果。API 契約則描述這個窗口接受哪些資料，以及會回覆什麼。
這些是責任上的區分，不一定代表三個不同網站。前後端可以放在同一個專案，也可以分開部署；重點是每部分的工作與存取權限清楚。
第一步：AI 先把需求轉成資料與規則
「幫我做一個報名網站」還不足以決定系統怎麼運作。我們需要先確定名額、截止日期、是否允許重複報名，以及送出表單後是立即取得名額，還是等待審核。
AI 可以協助整理活動編號、名稱、時間、名額與截止日期等活動資料，以及報名編號、姓名、Email、狀態與建立時間等報名資料。兩者透過活動編號建立關聯。
其中，「送出成功」與「報名確認」未必是同一件事。如果活動需要審核，保存成功後應顯示「待審核」，不能直接告訴小林已取得名額。AI 寫程式之前，先把這些語意釐清，往往比事後修補更有效。
這一步的交付物：一份欄位清單，以及報名成功、額滿、截止與重複報名時的處理規則。
第二步：約定前後端如何溝通
前後端串接需要共同遵守的資料約定，通常稱為 API 契約。以新增報名為例，可以先設計以下示意規格：
| 項目 | 示意約定 |
|---|---|
| 請求方式與位置 | POST /api/registrations |
| 輸入欄位 | eventId、name、email |
| 成功回應 | 報名編號與目前狀態 |
| 失敗回應 | 錯誤代碼與可理解的提示 |
POST 在這個例子中用來提交新增資料；JSON 則是一種常用的資料交換格式。欄位名稱、型態與必填條件都應明確。如果前端傳送 eventId，後端卻只讀取 activity_id，畫面再完整，也可能無法正常處理。
小林送出的資料，會包含活動編號、姓名與 Email。後端回覆的報名編號，則是系統建立的識別，不應由前端隨意指定。這讓查詢與追蹤有共同依據。
AI 可以依同一份契約產生兩端程式，也能比對欄位是否一致。契約改變後，程式與測試仍要一起更新。公開活動介紹與個人報名紀錄不應具有相同的存取方式；非公開端點需要逐次檢查權限。[1]
第三步：後端驗證後，才把資料寫進資料庫
前端即時提示「請輸入姓名」或「Email 格式不正確」，能改善操作體驗，但不能取代後端驗證，因為請求可以繞過畫面直接送出。[2]
後端應確認資料規格、使用者權限及報名條件，通過後才建立紀錄。資料庫也能提供約束：主鍵識別每筆報名，外鍵連結活動；若業務不允許同一識別對象重複報名，可設計適當的唯一性限制。[3]
但「先查名額，再新增報名」仍可能出錯。假設小林與另一位參加者同時查到最後一個名額，兩個請求都可能認為自己可以報名。
因此，名額檢查與紀錄寫入需要合適的交易及並行控制，例如鎖定相關紀錄，或使用有條件的原子更新。交易可以協助讓一組資料變更一起完成或回復；但只把程式包進交易，並不自動解決所有同時執行的問題。[4]
這一步的驗收：報名資料正確保存，名額不能因同時送出而超額，失敗時也不能留下只完成一半的狀態。
第四步：前端依據真實回應顯示結果
前端送出資料後，應進入等待狀態，再根據後端回應呈現結果。瀏覽器的 fetch() 是常見的 API 呼叫方式；收到 HTTP 錯誤狀態，不一定會自動進入例外處理，因此程式仍需檢查 response.ok 等回應資訊。[5]
| 畫面狀態 | 參加者需要知道什麼 |
|---|---|
| 處理中 | 系統正在送出資料，請稍候。 |
| 已完成 | 後端確認的報名編號與狀態，例如待審核。 |
| 需要處理 | 問題原因、保留的輸入內容，以及可採取的下一步。 |
如果小林按下按鈕，畫面只是直接切換為「報名成功」，卻沒有等到後端保存確認，這仍是展示流程。成功訊息應建立在真實結果之上。
第五步：處理重複請求與不確定結果
網路失敗不一定代表資料沒有寫入。後端可能已經保存小林的報名，但回應在傳回途中中斷。此時再次送出，可能產生第二筆紀錄。
一種做法，是為同一次提交建立請求識別碼，讓後端辨認重試，並回傳先前結果。這類設計常稱為冪等處理：同一次操作重複請求時，不產生重複的業務效果。它需要與儲存及並行控制配合，不能只在前端產生編號就算完成。
同一次操作重送，與同一個人重新發起另一筆報名，是不同問題。前者涉及重試，後者依活動規則判斷是否允許。若用請求識別碼，還應確認它屬於正確使用者，並避免相同識別碼被套用到不同內容。
通知寄送也要與報名狀態分開。資料保存成功但確認信未寄出時，可以安排補寄；不能因寄信失敗，就把已成立的報名當成不存在。
第六步：部署設定，讓各個部分連得上
程式在開發環境能運作，不代表正式環境已經設定完成。上線時需要確認 API 網址、資料庫連線、登入設定與必要憑證。資料庫密碼或高權限金鑰，不應放進會傳送到瀏覽器的前端程式。
如果前後端位於不同來源，瀏覽器可能需要透過 CORS 規則允許前端讀取回應。但 CORS 不是身分驗證，也不能取代後端權限檢查。[6]
可以把開發、測試與正式環境想成三套用途不同的工作場所。測試時能寫入的資料庫，不應因設定疏漏而變成正式客戶資料。每個環境的網址、權限與資料來源，都要核對。
AI 能協助找出設定差異、閱讀錯誤訊息與修正程式，但需要實際環境資訊與測試結果。只看程式碼，無法證明正式系統已成功連線。
如何驗收 AI 是否完成串接？
最直接的方法，是讓一筆測試資料完整走過系統：填寫表單、送出請求、後端驗證、保存紀錄、回傳編號，再重新查詢。小林關閉頁面後，仍應能透過適當的授權查回同一筆報名。
| 測試情境 | 應確認的結果 |
|---|---|
| 缺少必填欄位 | 提示問題，不建立不完整紀錄。 |
| 同一次操作重複送出 | 不重複建立報名。 |
| 活動已額滿或截止 | 依規則拒絕或轉為候補。 |
| 讀取別人的紀錄 | 後端拒絕未授權存取。 |
| 資料庫暫時無法使用 | 不顯示虛假的成功訊息。 |
| 請求逾時後重試 | 能確認結果，避免重複處理。 |
完成後，可以要求 AI 回報修改了哪些部分、實測哪些情境、尚未驗證什麼，以及出錯時如何追查。紀錄應能關聯請求與處理結果，同時避免把密碼、憑證或不必要的個資寫進錯誤日誌。
給 AI 的需求，怎麼寫得更完整？
可以用下面的方式描述任務，讓 AI 先整理規格，再實作與測試：
請製作攝影工作坊報名功能，先列出資料表、API 輸入輸出與業務規則。前端送出後，必須等後端確認資料保存，再顯示報名編號與狀態。請處理重複請求、額滿、截止、無權限與網路逾時情況。先在測試環境驗證，回報實際測試結果與未完成項目。未確定的規則請列出，不要自行補成已確認需求。
前後端串接的成果，是使用者的操作能按照規則，轉成正確、持久且可查詢的資料。AI 可以加快實作，但需求是否清楚、權限是否合理、結果是否經過驗證，仍決定了這套系統能否放心使用。