最近“振奮編碼”的說法層出不窮，
當你與 AI 代理交談時，網站服務的代碼瞬間出現。

但有一件事並沒有改變。

  • 要如何劃分伺服器

  • 要部署到哪裡

  • 如何進行回滾與管理

這依然是人類的責任。
AI雖然擅長生成“代碼”，但並不會替人類解決“運營階段的事故”。

在這篇文章中，我將特別強調階段環境(staging)的重要性，
並整理出在階段環境中應該檢查什麼。

dev-staging-prod 鏈接圖像

1. 雖然 AI 可以替我們編寫代碼，但部署依然存在

Commandbox 광고

如果你這樣告訴 AI 代理：

“用 Next.js 創建一個簡單的 TODO 網頁應用”
“請將這個 API 連接到 PostgreSQL”

代碼就會很快生成。
但 AI 並不會首先告訴你這些。

“現在不僅僅是 dev 伺服器，還要上傳到階段伺服器，
檢查與生產環境相同的數據庫/緩存/環境變數配置。”

因為如果發問和指令的人沒有這樣的經驗，
AI 也不會想到那個方向。

最後，很多初學者開發者會：

  1. 只在 dev 伺服器上運行良好

  2. 然後直接上傳到生產伺服器

  3. 因數據庫/緩存/環境變數/域名設置問題而出現故障 💣

之後才會體會到“啊...原來階段這麼重要”。

2. dev 直接進入 prod 的風險

“代碼打包成 Docker 映像，所以在哪裡都一樣吧？”
這看似合理，但實際運行時並不相同。

  • 看著哪個數據庫

    • dev: dev-db, prod: prod-db

    • 連接字符串、安全設置、賬戶權限、數據量都不同

  • 緩存/消息隊列

    • Redis、RabbitMQ、Kafka 等各環境專用的地址、認證、容量

  • 環境變數

    • NODE_ENV, API_BASE_URL, PAYMENT_PROVIDER_KEY …

    • 在 dev 中可能是空值或虛擬值，但在 prod 中使用實際的密鑰

  • 外部集成

    • 支付、短信、電子郵件、SSO、外部 API 等

    • dev 是 sandbox，prod 是實際環境

雖然 Docker 映像相同，但“環境”並不相同。
即使完成了一個 Web 應用的開發，
部署和運行完全是不同的領域。

因此，從 dev 直接跳到 prod，
其實和“功能測試在本地完成，直接讓真實客戶進行測試”是沒有區別的。

3. 為什麼階段環境必須存在？

Commandbox 광고

階段環境(staging)簡單來說是：

“與運行環境儘可能相似的彩排舞台”

。

  • 與 prod相同版本的應用程序

  • 幾乎與 prod相同的基礎設施配置

  • 但使用測試數據·域名·賬戶

如果沒有階段環境：

  • 在 dev 中運行良好的代碼會在 prod 中崩潰

  • 查找原因後會發現“環境差異”大多是原因

  • 每次都需要緊急修補→立即重新部署到 prod→再出現其他問題……

這樣的惡性循環會不斷重複。

相反，充分利用階段環境的話：

  • “這個變更在實際運行環境中會如何顯示”
    可以先目睹

  • 可以像實戰一樣排練基礎設置、安全設置、數據遷移

  • QA、策劃、設計師、業務負責人都可以預先確認
    運行前的畫面和功能

特別是對於初學者開發者來說：

  • 需要培養觀看整個運行環境的目光，而不是僅僅看自己的代碼，

  • 這個訓練正是在階段環境中進行的。

4. 在階段環境中必須檢查的內容

那麼，在階段環境中應該檢查什麼呢？
我們來一一整理。

4.1 環境變數和設置值

  • DATABASE_URL

  • REDIS_URL / CACHE_URL

  • API_BASE_URL

  • SECRET_KEY, JWT_SECRET_KEY

  • 外部 API 密鑰、webhook URL 等

需要文檔化“dev 與 prod 配置有何不同”
並檢查階段環境是否遵循與生產環境相同的模式。

檢查點

  • 階段環境的 env 文件或設置
    是否與 prod 的結構相同

  • 敏感信息是否妥善隱藏在環境變數/秘密管理工具中

  • 設置值是否沒有硬編碼

4.2 數據庫及數據遷移

  • 遷移腳本(prisma migrate, django migrate, migration.sql 等)是否在實際的 prod 中使用相似的數據結構能正確運行

  • 索引、唯一約束、外鍵約束是否發生錯誤

  • 虛擬數據是否會影響實際畫面和流程

檢查點

  • 階段環境中是否有適量的測試數據
    (在空數據庫中測試意義不大。)

  • 在階段環境中進行回滾策略的練習也是不錯的選擇。

4.3 認證·權限·會話

  • 登錄/註冊流程

  • OAuth/SSO(如 Google, Kakao) 集成

  • 根據權限(角色)展現不同的畫面/API 行為

檢查點

  • 階段環境中是否能以與實際運行相同的方式登錄
    (是否沒有臨時的 dev-only 登錄繞過邏輯)

  • 不同權限的賬號(管理員、普通用戶等)
    菜單/按鈕/操作是否能正常運作

4.4 外部集成: 支付、短信、郵件、通知等

  • 支付(gateway) → sandbox/測試模式

  • 短信/Kakao 通知 → 測試渠道

  • 郵件發送 → 測試郵件，注意不發送到真實客戶

檢查點

  • 在階段環境中是否使用實際的外部集成路徑
    (但必須是非真實客戶的測試賬號)

  • 檢查錯誤情況(支付失敗、超時等)處理情形

4.5 前端 + 後端的整合運作

在本地環境中前端和後端運行良好，但
當階段環境(實際域名/反向代理/SSL)介入時會出現其他問題。

  • CORS 設置

  • HTTPS/HTTP 混用

  • cookie 域名/secure 設置

  • 反向代理(Nginx, Traefik 等)的路徑路由問題

檢查點

  • 基於階段環境的 URL，每個頁面是否都能正常加載
    (確保沒有隱藏的僅限於本地的 URL)

  • 在瀏覽器開發者工具的 Network 標籤中
    確認是否有 CORS、301/302、4xx/5xx 錯誤

4.6 性能和資源使用量

起初性能問題不明顯，但
即使在階段環境進行些微的負載測試，也能提前發現問題。

  • API 響應時間

  • 數據庫查詢數量，N+1 查詢情況

  • 緩存失敗時的性能

  • 內存/CPU 用量

不必使用複雜的負載測試工具。

  • 在階段環境中以不同用戶角色同時進行幾次操作，

  • 並查看日誌中是否有緩慢部分，這樣做即可構成有意義的“迷你負載測試”。

5. 如何開始設定階段環境？

一開始不需要完美。
以小型服務為標準，可以這樣開始。

5.1 最小配置例

  • dev

    • 本地開發環境 (Docker compose、本地 DB 等)

  • staging

    • 部署到與生產環境相同的雲端/平台

    • 域名: staging.example.com

    • 獨立的 DB/緩存/存儲

  • prod

    • 實際客戶使用的運行環境

部署流程也可以很簡單：

  1. main 合併 → 自動部署到 staging

  2. 在階段環境中進行 QA/自檢

  3. 推送特定標籤(v1.0.0) → 部署到 prod

即使只有這些：

  • 可以徹底阻止“從 dev 直接跳到 prod”

  • 永遠養成經由 staging 的習慣。

6. 初學者應“過度”使用階段環境

大多數初學者開發者對階段環境不以為意。

  • “在 dev 中運行良好，怎麼會有問題……”

  • “不知道在階段環境中該檢查什麼……”

但實際上，實力差距主要在於如何穩定處理運行和部署，
而不僅僅是代碼質量。

  • 功能能良好運作固然重要，

  • 但服務不應中斷更為重要。

階段環境是一個安全裝置，將它們連接起來，
也是開發者學習“服務運營觀點”的最佳練習場所。

未來在創建新的網站服務時，可以這樣進行：

  1. 在設計階段就同時規劃 prod 和 staging

  2. 將部署自動化設計為staging → prod 的順序

  3. 對於重要功能，必須在 staging 測試
    “如同實際運行一樣”幾次後才上線至 prod

在 AI 能幫助我們生成代碼的時代，
設計和承擔部署及運營的能力將成為更大的差異點。
階段環境是培養那種能力的最實際工具。