什麼是 Staging 環境？上線前先測試

Staging 環境係你應用程式嘅私人副本，盡量設定得同正式版一樣，等你喺真正用戶見到改動之前先喺度測試。佢用自己嘅資料庫、測試資料同測試 API 金鑰，所以喺嗰度出現嘅壞功能或者壞資料改動，都唔會影響團隊以外嘅任何人。當改動喺 staging 睇落冇問題，你先會將佢發佈去 production——即係客戶用緊嘅正式版應用程式。

用 AI 建造嘢時點解 staging 重要

用 AI 建造令改動變得好快。你幾分鐘內就可以加一個功能、重寫一個頁面，或者改你嘅資料結構。咁快當然好，但如果一個睇落冇問題嘅改動，悄悄噉搞壞咗結賬流程，或者一個「小清理」刪咗一欄客戶資料，咁快就變成問題。

喺改動正式上線之前有一個地方去檢查，可以幫你：

• 喺客戶之前搵到問題。 每次大改動之後，都試吓註冊、付款同其他重要流程。
• 用接近真實嘅設定測試。 Staging 應該同 production 行為一樣——同一套技術棧、相近嘅設定——咁問題會喺嗰度出現，而唔係之後先出現。
• 保護真實資料。 資料庫改動、匯入同大量編輯，都可以先喺測試資料上排練。
• 展示進行中嘅工作。 客戶或者隊友可以審閱改動，而唔需要公開。

日常比喻

諗吓劇院嘅綵排。

• Development 係排練室：演員試台詞、停、重來、嘗試新嘢。
• Staging 係彩排：full 戲服、真正舞台、真正燈光——即係一切都同首演夜一樣，只係冇付費觀眾。
• Production 係首演夜。錯誤會喺所有人面前發生。

大部分你唔想喺首演夜先出現嘅問題，都會喺彩排時出現：一次換服裝太慢，或者一個燈光提示錯咗。呢個正正就係 staging 嘅工作。

三種常見環境

每個環境主要分別喺於設定：連接邊個資料庫、用邊套金鑰、喺邊個網址運行。所以好嘅應用程式會由環境變數同 secrets讀取呢啲設定，而唔係將數值硬寫入代碼。咁同一份代碼就可以喺每個環境用唔同設定運行。

實例：更改預約應用程式嘅取消規則

你經營一個有付費客戶嘅髮型屋預約應用程式。你想將規則改成客戶可以喺開始前 24 小時取消，而唔係 48 小時，而且退款要自動處理。

1. 喺 development 建造。 你向 AI 建造工具提出改動要求。佢更新取消邏輯，同埋對付款服務商嘅退款呼叫。

2. 發佈去 staging。 Staging 運行同一份代碼，連接到一個 staging 資料庫（有測試預約），並用付款服務商嘅測試模式金鑰。

3. 測試真實流程。 你同同事：

• 預約一個明天嘅測試時段，喺 30 小時前取消——應該退款；
• 試吓喺 10 小時前取消——應該被拒絕，並顯示清楚嘅訊息；
• 喺付款服務商嘅測試 dashboard 確認退款有出現；
• 確認確認電郵寫嘅係 24 小時，而唔係 48 小時。

4. 搵出問題。 喺 staging 你發現規則用嘅係伺服器嘅時區，而唔係髮型屋嘅時區，所以截止時間差咗一個小時。你修好佢，再測試一次。

5. 發佈去 production。 到呢一刻，改動先至會到達真實客戶——而時區問題已經被捉到。

如果冇 staging，第 4 步就會喺真實客戶嘅退款上發生。

重要術語

常見誤解

• 「Staging 可以同 production 共用資料庫。」 呢個係最危險嘅捷徑。一個刪除或者改動紀錄嘅測試，會直接影響真實客戶。要畀 staging 自己嘅資料庫。
• 「喺 staging work 咗，就唔可能喺 production 壞。」 Staging 只係減低風險，並唔係消除風險。真實流量、真實資料同外部服務仍然可以令你意外。要保留可以還原嘅方法。
• 「Staging 一定要好貴。」 佢可以好細。佢需要同 production 相同嘅設定，唔使同樣大小。
• 「喺 staging 用真正嘅付款金鑰，會更貼近實際。」 要用服務商嘅測試模式。貼近實際唔等於用真錢。
• 「Staging 只係大團隊先需要。」 「先喺一個安全嘅地方測試」呢個概念，就算一個人做都有用。儀式感嘅程度可以按風險大小調整。
• 「Staging 應該公開，等人試用。」 要保持私人或者有保護，並且阻止搜尋引擎索引佢，免得有人誤會佢係真正嘅應用程式。

要求你嘅 AI 建造工具做咩

• 「將每個環境專屬嘅設定——資料庫、API 金鑰、網站網址——都由環境變數讀取。」
• 「加一個 seed script，喺非正式資料庫填入貼近實際嘅測試資料。」
• 「喺我話正式推出之前，都用付款服務商嘅測試模式。」
• 「呢個改動上線之前，列出我應該測試嘅流程，同每個流程應該出現咩結果。」
• 「呢個改動會唔會影響現有資料？先俾我睇 migration。」
• 「確保非正式版本嘅網站唔會被搜尋引擎索引。」

想睇逐步設定方法，可以睇點樣設定 staging 環境。當發佈變得頻密，將代碼→staging→production 嘅路徑自動化，就係 CI/CD 嘅用途。

Mythex 嘅發佈前測試

Mythex 冇一個獨立嘅「staging 對 production」開關；發佈之後你會得到一個即時公開網址，docs 亦都清楚咁講（多服務應用程式）。但佢畀你嘅係一條清晰嘅界線，分開建造同上線：

• Preview 喺你建造嗰陣，喺一個私人雲端沙盒度運行你嘅應用程式。改動會先喺嗰度出現，而唔係即時應用程式。
• Share 會建立預覽連結，等客戶或隊友可以審閱進行中嘅工作，唔需要 Mythex 帳戶，亦唔使你發佈。連結會顯示沙盒當下嘅狀態，包括建造中途嘅改動，而且你隨時可以刪除。
• Publish 會為項目拍一個快照並部署。喺你再次發佈之前，即時應用程式都會維持原樣。
• Checkpoints 會喺每次 agent 成功完成一輪之後儲存，所以如果改動出錯，你可以還原項目檔案。

將 Preview 當成你嘅彩排：上線前付款服務商都保持測試模式，並且每次發佈前都行一次主要流程。當有真實客戶參與，喺測試任何會寫入或者刪除資料嘅嘢之前，先問吓 agent 你嘅 Preview 用緊邊個資料庫同金鑰。如果你需要一個獨立、有自己資料庫嘅 staging 設定，可以叫 agent 為你嘅項目解釋你嘅選擇，或者——如果你用緊 Pro——將項目匯出，或者同步到 GitHub，然後喺你自己控制嘅基礎設施上運行。

常見問題