把 ChatGPT 預約系統搬到 Hostinger 與 LINE 通知完整教學
- 小步
- 2天前
- 讀畢需時 13 分鐘
原本使用 ChatGPT Sites 建立的預約系統，已經可以讓顧客填寫預約資料、產生預約編號，也能從管理後台查看紀錄。
但當老闆提出新的需求，希望顧客完成預約後，自己的 LINE 可以立即收到通知，系統就不能只負責顯示頁面和保存資料。
這次，我會使用 Codex 調整原本的專案架構，把系統改成可以執行 Node.js 後端程式的版本，再透過 GitHub 部署到 Hostinger，並加入 MySQL 資料庫、管理員登入與 LINE 預約通知。
這篇文章會補充影片中沒有逐項展開的設定方式，帶大家從原始專案開始，完成整套搬遷與測試流程。
本文為 Hostinger 合作內容。文章中的流程、畫面與除錯紀錄，皆來自這次預約系統的實際測試。
搭配影片觀看
影片連結 👉 https://youtu.be/9XX8AFtoIzA
為什麼原本的系統需要搬家？
原本使用 ChatGPT Sites 建立的預約系統，並不是完全沒有後端功能。
顧客送出資料後，系統已經可以：
驗證預約內容
產生預約編號
保存顧客資料
在管理頁面顯示預約紀錄
只是這些資料處理與保存工作，原本都是由 ChatGPT Sites 提供的執行環境協助完成。
當系統要再加入 LINE 通知時，顧客送出預約後，網站背後還需要執行更多工作：
接收預約資料
驗證必要欄位
產生預約編號
將資料寫入資料庫
使用 LINE 的連線資料呼叫 API
將通知傳送給指定的管理者
回傳預約成功畫面
因此，這次需要把系統整理成一套可以自行管理後端程式、資料庫與外部 API 的架構。
GitHub 已經有程式碼，為什麼還需要 Hostinger？
GitHub 主要負責保存與管理程式碼。
它可以記錄每次修改、管理不同版本，也能讓 Hostinger 取得最新的專案內容。
但是，顧客送出預約後，GitHub 不會主動幫我們執行：
接收表單資料
寫入資料庫
驗證管理員登入
呼叫 LINE API
傳送預約通知
系統也不能只放在自己的電腦上執行。
不然電腦關機或網路中斷後，顧客送出的預約就無法正常處理。
所以，我們需要一個能夠持續對外提供網站、執行 Node.js 後端程式、連接資料庫，並保存私密設定的主機環境。
這次 Hostinger 負責的是：
提供顧客使用的預約網站
執行 Node.js 後端程式
提供 MySQL 資料庫
保存資料庫密碼與 LINE Token
從 GitHub 取得新版程式
完成網站建置與部署
開始之前，需要準備什麼？
這次操作需要先準備：
一個已經可以使用的預約系統
預約系統所在的 GitHub Repository
可協助修改專案的 Codex
支援 Node.js Web App 的 Hostinger 方案
一個 LINE 官方帳號
LINE Developers 的管理權限
預計接收通知的 LINE 個人帳號
另外，建議不要直接修改原本可以使用的版本。
正式開始前，可以先建立一個新的 Git 分支，專門保存 Hostinger 與 LINE 通知版本。
這次實作使用的分支名稱為：
feature/hostinger-line重要提醒：資料庫密碼、管理員密碼、Session Secret、LINE Channel Access Token 與 LINE User ID，都不應直接寫進程式碼或上傳到 GitHub。
第一階段：使用 Codex 調整專案架構
原本的專案是在 ChatGPT Sites 的環境中執行。
現在要搬到 Hostinger，就需要先確認專案中有哪些功能依賴原本的平台，並把它整理成可以自行部署、由 Node.js 執行的版本。
這個階段不需要重新設計網站。
原本的：
顧客預約頁面
預約成功畫面
管理後台介面
預約操作流程
都可以先保留下來。
主要需要修改的是網站背後的執行方式。
先請 Codex 分析，不要立刻修改
不建議一開始就直接叫 Codex「把專案搬到 Hostinger」。
比較安全的方式，是先讓 Codex 以唯讀方式檢查專案，整理目前的架構、平台依賴、修改計畫與風險。
以下是依照這次操作流程整理的教學版提示詞，可再依自己的專案調整。
展開查看完整提示詞
請先以唯讀方式檢查目前的專案，不要修改任何檔案。 這個專案原本是在 ChatGPT Sites 的環境中執行， 現在預計搬到 Hostinger 的 Node.js Web App。 請協助分析： 1. 目前使用的前端、後端、資料庫與登入架構。 2. 哪些檔案或套件依賴 ChatGPT Sites、Cloudflare Worker 或原平台功能。 3. 要改成標準 Node.js／Next.js 執行方式，需要調整哪些內容。 4. 原本的預約頁面、成功畫面與管理後台介面需要保留。 5. 預約資料之後要改存 Hostinger MySQL。 6. 管理後台要改用自行管理的帳號、bcrypt 密碼與 Session。 7. LINE 通知之後再加入，這個階段先不要實作。 請先輸出： - 現有架構分析 - 需要替換的平台依賴 - 建議修改順序 - 可能風險 - 每個階段的測試項目 先不要修改程式，等我確認計畫後再執行。 |
確認計畫後，再開始修改
確認 Codex 的分析方向沒有問題後，再請它執行第一階段。
展開查看完整提示詞
請依照剛才確認的計畫，開始進行第一階段。 目標是將原本依賴 ChatGPT Sites 的專案， 整理成可以在 Hostinger 以 Node.js 執行的版本。 請保留： - 原本的預約頁面 - 預約成功畫面 - 管理後台主要介面 - 原本的操作流程 這個階段先完成： 1. 調整成標準 Node.js／Next.js 執行架構。 2. 移除或停用只適用於原平台的執行方式。 3. 確認 Production Build 可以成功。 4. 整理 Hostinger 需要的建置與啟動設定。 5. 完成測試後，將修改 Commit 到目前的功能分支。 請不要加入 LINE 通知。 |
每個專案的檔案結構不一樣，因此不要看到某個教學刪除特定檔案，就直接照著刪除。
真正需要確認的是：
這些檔案是否只適用原平台
移除後是否會影響預約頁面
Production Build 是否成功
API 路由是否仍可正常執行
第二階段：將程式部署到 Hostinger
完成專案架構調整後，就可以先把程式部署到 Hostinger。
這時候資料庫與管理後台可能還不能正常使用，但可以先確認：
Hostinger 能否讀取 GitHub 專案
正確的分支是否已連接
專案能否完成建置
網站是否可以透過臨時網域開啟
步驟一：設定 GitHub 存取權限
先到 GitHub 確認 Hostinger 是否有權限存取這個 Repository。
若 Repository 是 Private，必須在 GitHub 的應用程式授權設定中，允許 Hostinger 存取指定的專案。
 |  |
 | |
 |
步驟二：在 Hostinger 建立 Node.js Web App
進入 Hostinger 後台後：
點擊左側的「網站」
點擊「添加網站」
選擇「部署網路應用」
測試階段先使用臨時網域
選擇透過 GitHub 繼續
選擇預約系統所在的 Repository
選擇 Codex 修改完成的功能分支
確認設定後開始部署
本次專案的建置設定
本次專案使用的主要設定為：
套件安裝：npm ci
建置指令：npm run build
啟動指令：npm run start:hostinger
Node.js：22.x啟動指令會先執行資料庫 Migration，再啟動 Next.js。
若 Hostinger 已經正確辨識 Next.js 專案，部分欄位可能會自動完成，不一定需要手動填入所有內容。
第一次部署完成，只代表程式已經放到 Hostinger。資料庫、環境變數與管理員登入仍需要繼續設定。
建立 MySQL 資料庫
接下來要建立預約系統使用的 MySQL 資料庫。
之後顧客送出的預約資料，不會再保存到原本的 Sites 環境，而是寫入 Hostinger 的 MySQL。
進入網站的控制面板後：
找到資料庫相關功能
建立新的 MySQL 資料庫
輸入資料庫名稱
輸入資料庫使用者名稱
設定一組安全密碼
完成建立
建立完成後，請先記錄：
Database Name
Database User
Database Password
建立保存預約紀錄的資料表
剛建立的 MySQL 還是一個空的資料庫，裡面沒有保存預約紀錄的資料表。
影片中採用的方式，是將 Codex 準備好的 SQL 指令，貼到資料庫管理工具中執行。
設定八個基礎環境變數
完成資料庫後，回到 Hostinger 網站控制面板，找到「環境變數」功能。
在還沒有加入 LINE 通知前，這套系統需要八個基礎環境變數：
DB_HOST
DB_PORT
DB_NAME
DB_USER
DB_PASSWORD
ADMIN_USERNAME
ADMIN_PASSWORD_HASH
SESSION_SECRET前面已經有記錄了DB_NAME及DB_USER，DB_PORT及DB_HOST比照下圖輸入。
除了DB相關的環境變數，另一個是後台管理的部分，可以依照下面的步驟得到變數資料👇
管理後台設定
ADMIN_USERNAME
管理員登入後台時使用的帳號。
可以自行設定，但不要使用過於容易猜測的名稱。
ADMIN_PASSWORD_HASH
這裡不能直接放管理員的明文密碼。
系統使用 bcrypt 保存密碼雜湊，登入時會將使用者輸入的密碼與雜湊值進行比對。
在 Windows PowerShell 中，可以使用專案提供的指令產生：
$env:ADMIN_PASSWORD='在這裡輸入暫時使用的管理員密碼'
npm run auth:hash-password
Remove-Item Env:ADMIN_PASSWORD將輸出的 bcrypt hash 複製到 ADMIN_PASSWORD_HASH。
不要把原始密碼或輸出的雜湊值寫進程式碼。
SESSION_SECRET
用來保護管理後台登入 Session 的隨機字串。
本次專案要求至少 32 個字元，建議使用密碼產生器建立較長的隨機內容。
將預約資料改存到 MySQL
資料庫與環境變數完成後，接下來要請 Codex 調整程式。
這次主要要把原本的資料保存方式，改成：
顧客送出預約
Node.js API 接收資料
驗證必要欄位
產生預約編號
寫入 Hostinger MySQL
從資料庫讀回剛建立的紀錄
回傳預約成功結果
可以將需求整理後交給 Codex。
展開查看完整提示詞
請開始處理預約資料的保存方式。 目前 Hostinger 已經完成： - 建立 MySQL 資料庫 - 建立預約資料表 - 設定 DB_HOST - 設定 DB_PORT - 設定 DB_NAME - 設定 DB_USER - 設定 DB_PASSWORD 請將原本依賴 ChatGPT Sites／D1 的資料庫連線， 改成 Hostinger MySQL。 需求： 1. 保留原本預約表單與成功畫面。 2. 保留原本的預約編號產生方式。 3. 成功寫入 MySQL 後，再回傳預約成功。 4. MySQL 寫入失敗時，不可以顯示假成功。 5. 確認中文姓名、聯絡方式與備註可以正確保存。 6. 不要將資料庫密碼寫進程式碼。 7. 完成後執行測試、Lint 與 Production Build。 請先說明預計修改的檔案，再開始執行。 |
重新處理管理後台登入
原本在 ChatGPT Sites 中使用的平台登入方式，搬到 Hostinger 後不能直接沿用。
因此需要重新建立：
管理員帳號
bcrypt 密碼驗證
登入 Session
登出功能
未登入時的重新導向
可以使用以下教學版提示詞：
展開查看完整提示詞
請將原本依賴 ChatGPT Sites 的管理後台登入， 改成可以在 Hostinger 執行的管理員登入方式。 目前已經設定： - ADMIN_USERNAME - ADMIN_PASSWORD_HASH - SESSION_SECRET 需求： 1. 管理員密碼使用 bcrypt 比對。 2. 不保存或記錄明文密碼。 3. 登入成功後建立安全 Session。 4. 未登入時開啟管理後台，必須導向登入頁。 5. 登出後清除 Session。 6. 保留原本管理後台的主要介面與功能。 7. 管理後台要能讀取 MySQL 中的預約紀錄。 8. 完成後測試正確與錯誤的帳號密碼。 9. 執行測試、Lint 與 Production Build。 請先說明修改計畫，再開始執行。 |
管理員密碼一直登入失敗時
這次實測時，管理員登入也曾經發生錯誤。
可以依序檢查：
ADMIN_USERNAME 是否與輸入內容完全相同
ADMIN_PASSWORD_HASH 是否完整貼上
bcrypt hash 是否有正確前綴
複製時是否多了空白或換行
是否誤把明文密碼放進 ADMIN_PASSWORD_HASH
修改環境變數後是否重新部署
Hostinger 實際執行的是否為最新版本
如果仍然找不到原因，可以請 Codex 加入不輸出機密內容的診斷資訊，只檢查：
變數是否存在
字串長度是否合理
bcrypt 前綴是否正確
帳號是否符合
bcrypt 比對是否成功
不要直接把密碼或完整雜湊值輸出到 Log。
第三階段：加入 LINE 預約通知
完成 MySQL 與管理後台後，就可以加入這次最重要的 LINE 通知。
這個階段需要：
建立 LINE 官方帳號
啟用 Messaging API
取得 Channel Access Token
取得接收通知者的 User ID
將資料加入 Hostinger 環境變數
請 Codex 修改預約 API
測試 Push Message
建立 LINE 官方帳號
先建立一個用來傳送預約通知的 LINE 官方帳號。
這個帳號的用途，是讓系統以官方帳號的身分，主動傳送訊息給指定的管理者。
建立後，請先讓預計接收通知的個人 LINE 帳號加入官方帳號好友。
加入官方帳號好友，不代表所有好友都會自動收到每一筆通知。程式會把訊息傳送給環境變數中指定的 User ID。
啟用 Messaging API
在 LINE Official Account Manager 中啟用 Messaging API，並連接 LINE Developers 的 Provider 與 Channel。
接著需要取得兩項資料：
LINE Channel Access Token
接收通知者的 LINE User ID
LINE Developers
加入 LINE 環境變數
這次實際程式使用的兩個環境變數為：
LINE_CHANNEL_ACCESS_TOKEN
LINE_TARGET_USER_IDLINE_CHANNEL_ACCESS_TOKEN
填入 Messaging API 使用的 Channel Access Token。
LINE_TARGET_USER_ID
填入預計接收預約通知的個人 LINE User ID。
設定完成後，請重新部署網站。
請 Codex 加入 LINE Push Message
這次需要的是系統主動把預約通知傳送給管理者，因此使用 LINE Push Message API。
不需要建立接收顧客訊息的 Webhook。
可以將需求交給 Codex：
展開查看完整提示詞
請為目前的預約系統加入 LINE 新預約通知。 Hostinger 已經設定： - LINE_CHANNEL_ACCESS_TOKEN - LINE_TARGET_USER_ID 需求： 1. 顧客預約資料成功寫入 MySQL 後，才傳送 LINE。 2. 資料庫寫入失敗時，不可以呼叫 LINE。 3. LINE 通知內容包含： - 預約編號 - 顧客姓名 - 聯絡方式 - 預約項目 - 預約日期 - 預約時段 - 備註 4. 使用 LINE Push Message API。 5. 不需要新增 Webhook。 6. 設定合理的逾時時間。 7. LINE 發送失敗時，不要刪除或回滾已建立的預約。 8. LINE 發送失敗時，顧客仍然看到預約成功。 9. Log 不可以輸出 Token、User ID 或完整顧客資料。 10. 加入 LINE 未設定、HTTP 錯誤、網路錯誤與逾時測試。 11. 執行測試、Lint 與 Production Build。 請先唯讀檢查目前的預約 API， 說明預計修改的位置與執行順序， 等我確認後再修改。 |
LINE 通知常見錯誤
錯誤一：LINE notification is not configured
Log 出現：
LINE notification is not configured通常代表程式沒有讀到其中一個必要環境變數。
請檢查：
LINE_CHANNEL_ACCESS_TOKEN 是否存在
LINE_TARGET_USER_ID 是否存在
變數名稱是否完全相同
是否把變數加到正確的網站或應用程式
更新後是否重新部署
這次實測時，就是因為環境變數加錯位置，導致程式無法讀取。
錯誤二：LINE API 回傳 401
Log 出現 HTTP 401，通常代表授權資料不正確。
請檢查：
是否使用正確的 Channel Access Token
Token 是否複製完整
是否誤貼 Channel Secret
Token 是否屬於目前使用的 Messaging API Channel
Token 前後是否多了空白
這次實測的 401，是因為貼入了錯誤的 Channel Access Token。
錯誤三：兩個帳號都加入好友，為什麼只有一個收到？
因為目前程式只會將訊息推送到 LINE_TARGET_USER_ID 指定的帳號。
其他加入官方帳號好友的人，不會自動收到這筆預約通知。
若需要多位管理者同時收到，程式需要改成：
保存多個 User ID
依序向每個 User ID 傳送通知
或重新設計成傳送到指定群組
目前這個教學版本先以單一管理者為主。
第四階段：重新部署並測試完整流程
Hostinger 與 GitHub 第一次建立連線後，後續更新就不需要重複手動上傳所有程式檔案。
Codex 修改完成後：
將變更 Commit
Push 到 GitHub
確認 Push 的分支正確
等待 Hostinger 重新建置
查看 Deployment Log
開啟臨時網域測試
為什麼 LINE 失敗時，預約仍應該成功？
這次程式設計有一個很重要的原則：
先成功保存預約資料，再嘗試傳送 LINE 通知。
LINE 通知是預約完成後的附加程序。
如果資料已經成功寫入 MySQL，但 LINE 剛好因為網路、Token 或 API 問題發送失敗，不應該把已建立的預約刪除，也不應該再次新增一筆相同資料。
正確的執行順序是：
驗證預約內容
↓
寫入 MySQL
↓
讀回已建立的預約
↓
嘗試傳送 LINE
↓
回傳預約成功因此，即使 LINE 發送失敗：
顧客仍然取得預約編號
MySQL 中仍保留預約紀錄
管理後台仍能看到資料
系統可以在 Log 中記錄通知失敗
這樣才不會因為一個附加通知功能，影響最重要的預約資料。
這次搬遷後，系統改變了什麼？
完成搬遷後：
原本的前台預約頁面保留下來
顧客不需要重新適應新的操作方式。
後端改成 Node.js 執行
系統不再依賴原本的 Sites 執行環境。
預約資料改存 MySQL
資料庫、帳號與連線資訊可以自行管理。
管理後台重新建立登入機制
使用環境變數、bcrypt 與 Session 保護預約紀錄。
加入 LINE 即時通知
顧客完成預約後，指定管理者可以立即收到訊息。
GitHub 與 Hostinger 建立部署流程
Codex 修改完成並 Push 到 GitHub 後，Hostinger 就可以重新建置與部署。
使用 AI 搬遷專案時的幾個提醒
這次雖然大量使用 Codex 協助修改程式，但不代表把需求一次丟給 AI，就可以完全不用檢查。
比較安全的做法是：
先請 AI 分析現有架構
確認哪些功能依賴原平台
將搬遷拆成不同階段
每個階段完成後單獨測試
檢查 Git Diff 與修改檔案
執行測試、Lint 與 Production Build
部署後再跑一次完整流程
AI 說「已完成」，只代表程式修改工作已經執行。
真正能不能使用，仍然要透過：
實際部署
資料庫紀錄
管理員登入
LINE 通知
完整回歸測試
才能確認。
最後總結
這次的重點，不是重新做一個預約網站。
而是把原本使用 AI 建立的系統，整理成一套可以正式部署、保存資料、管理登入，並串接外部服務的完整架構。
當 AI 做出的網站開始需要：
接收顧客資料
保存正式紀錄
建立管理後台
連接外部 API
執行自動通知
長時間穩定運作
就需要進一步考慮後端程式、資料庫、環境變數與主機部署。
透過 Codex、GitHub 與 Hostinger 的搭配，原本建立在 ChatGPT Sites 上的預約系統，也可以逐步整理成一套真正能夠持續上線運作的工具。
留言