什麼是測試環境（Staging）？上線前先測試
測試環境是 App 的私人副本，盡可能與正式版本相近，讓你在真正的使用者看到變更之前先行測試。它使用自己的資料庫、測試資料與測試用 API 金鑰，因此測試環境中的功能出錯或資料變更錯誤，都不會影響團隊以外的任何人。當變更在測試環境中看起來沒問題時，你就會將它發布到正式環境，也就是客戶使用的線上 App。
用 AI 建站時，為什麼測試環境很重要
用 AI 建置 App 讓變更變得非常快速。你可以在幾分鐘內新增功能、重寫頁面，或調整資料結構。這種速度很好，直到某個看似沒問題的變更悄悄破壞了結帳流程，或某次「小幅清理」刪除了一欄客戶資料為止。
在變更上線前先檢查的地方可以幫助你：
- 在客戶發現之前抓出問題。 每次重大變更之後，都要測試註冊、付款與其他關鍵流程。
- 使用接近真實的設定進行測試。 測試環境應該表現得像正式環境，使用相同的技術堆疊與相近的設定，這樣問題才會在那裡出現，而不是之後。
- 保護真實資料。 資料庫變更、匯入與大量編輯，都可以先用測試資料演練。
- 展示進行中的工作。 客戶或同事可以審閱某項變更，而不必讓它公開。
日常生活的比喻
想像劇院的彩排。
- 開發是排練室：演員練習台詞、停下來、重來、嘗試各種做法。
- 測試是總彩排：穿上戲服、在真正的舞台上、用真正的燈光，一切都與正式演出時相同，只是沒有付費觀眾。
- 正式環境是首演之夜。錯誤會當著所有人的面發生。
大多數你不希望在首演之夜出現的問題，都會在總彩排時浮現：換裝花太多時間、燈光提示錯誤。這正是測試環境的工作。
三種常見環境
| 開發 | 測試 | 正式 | |
|---|---|---|---|
| 用途 | 建置與實驗 | 發布前的最後檢查 | 線上運行的 App |
| 使用者 | 你或你的開發人員 | 團隊、測試人員、客戶 | 真實使用者 |
| 資料 | 範例或假資料 | 測試資料或清理過的副本 | 真實客戶資料 |
| API 金鑰 | 測試金鑰 | 測試金鑰（例如付款服務的測試模式） | 正式金鑰 |
| 穩定性 | 經常壞掉，這是正常的 | 應該穩定 | 必須穩定 |
| 網址 | 本機或私人預覽 | 私人或有密碼保護的網址 | 你的公開網域 |
各環境之間的主要差異在於設定：連接哪個資料庫、使用哪些金鑰、位於哪個網址。這就是為什麼良好的 App 會從環境變數與機密資料讀取這些設定，而不是寫死在程式碼中。如此一來，同一份程式碼就能在每個環境中以不同的設定運行。
實例：修改美容預約 App 的取消規則
你經營一個有付費客戶的美容院預約 App。你想把規則改成客戶可以在前 24 小時取消，而不是 48 小時，並且退款自動完成。
1. 在開發環境中建置。 你請 AI 建置工具進行這項變更。它會更新取消邏輯，以及呼叫付款服務商的退款功能。
2. 發布到測試環境。 測試環境執行相同的程式碼，連接到測試資料庫（含測試預約），並使用付款服務商的測試模式金鑰。
3. 測試真實流程。 你與同事：
- 預約一筆明天的測試服務，並在 30 小時前取消，應該會退款；
- 嘗試在 10 小時前取消，應該會被拒絕，並顯示清楚的訊息；
- 在付款服務商的測試後台確認退款有出現；
- 確認確認信寫的是 24 小時，而不是 48 小時。
4. 找出錯誤。 在測試環境中你發現規則使用的是伺服器的時區，而不是美容院所在的時區，因此截止時間差了一小時。你修正後再次測試。
5. 發布到正式環境。 只有到這時，變更才會送達真正的客戶，而時區錯誤已經被抓出來了。
如果沒有測試環境，第 4 步就會在真實客戶的退款上發生。
關鍵名詞
| 名詞 | 意思 |
|---|---|
| Environment（環境） | 你的 App 的一份運行副本，擁有自己的設定、資料與網址。 |
| Production（正式環境，prod） | 真實使用者所依賴的線上環境。 |
| Staging（測試環境） | 接近正式環境、用於最後測試的副本。 |
| Development（開發環境，dev） | 變更最先被建置與嘗試的地方。 |
| Preview environment（預覽環境） | 為單一變更建立的短期 App 副本，通常是自動建立的。 |
| Deploy／release（部署／發布） | 將某個版本的程式碼放入某個環境。 |
| Rollback（還原） | 在發布出現問題後，回到先前可正常運作的版本。 |
| Environment parity（環境一致性） | 測試環境與正式環境的相似程度。越接近，就越有用。 |
| Seed data（種子資料） | 載入非正式資料庫中用於測試的範例資料。 |
常見迷思
- 「測試環境可以共用正式資料庫。」 這是最危險的捷徑。會刪除或修改紀錄的測試，會直接影響真實客戶。測試環境應該有自己的資料庫。
- 「如果在測試環境能正常運作，正式環境就不會壞。」 測試環境能降低風險，但無法消除風險。真實流量、真實資料與外部服務仍然可能帶來意外。請保留還原的方法。
- 「測試環境一定要很花錢。」 它可以很小。它需要的是與正式環境相同的設定，而不必是相同的規模。
- 「為了更貼近實際，在測試環境使用正式付款金鑰。」 請使用服務商的測試模式。貼近實際不代表使用真實的錢。
- 「測試環境只適合大型團隊。」 「先在安全的地方測試」這個概念，即使只有一個人也很有用。儀式感的多寡可以依風險程度調整。
- 「測試環境應該公開，讓大家都能試用。」 請保持私人或加上保護，並阻止搜尋引擎建立索引，以免有人誤把它當成真正的 App。
向你的 AI 建置工具要求什麼
- 「讓每一項與環境相關的設定（資料庫、API 金鑰、網站網址）都從環境變數讀取。」
- 「新增一個種子腳本，在非正式資料庫中填入貼近真實的測試資料。」
- 「在我決定正式上線之前，使用付款服務商的測試模式。」
- 「在這項變更上線前，列出我應該測試的流程，以及每個流程應有的結果。」
- 「這項變更會影響現有資料嗎？請先給我看遷移內容。」
- 「確保非正式版本的網站不會被搜尋引擎建立索引。」
如需逐步設定，請參閱如何設定測試環境。當發布變得頻繁時，將從程式碼到測試環境再到正式環境的路徑自動化，正是 CI/CD 的用途。
在 Mythex 中發布前測試
Mythex 沒有獨立的「測試 vs 正式」切換開關；發布後會得到一個公開的即時網址，文件也明確說明了這點（多服務 App）。它提供的是建置與正式上線之間清楚的界線：
- **預覽（Preview）**會在私人雲端沙盒中運行你的 App，供你在建置時使用。變更會先出現在這裡，而不是你的正式 App。
- **分享（Share）**會建立預覽連結，讓客戶或同事即使沒有 Mythex 帳號，也能審閱進行中的工作，而你無須發布。連結顯示的是沙盒當下的狀態，包括建置中途的變更，而且你隨時可以刪除它。
- **發布（Publish）**會為專案建立快照並部署。在你再次發布之前，正式 App 維持原樣。
- **檢查點（Checkpoints）**會在 Agent 每次成功完成一輪工作後儲存，因此如果變更出錯，你可以還原專案檔案。
請把預覽當成你的彩排：在上線之前讓付款服務維持測試模式，並在每次發布前走過關鍵流程。一旦涉及真實客戶，在測試任何會寫入或刪除資料的功能之前，請先請 Agent 確認你的預覽使用哪個資料庫與金鑰。如果你需要一套完全獨立、擁有自己資料庫的測試環境，請請 Agent 說明你的專案可用的選項，或者（在 Pro 方案中）匯出專案，或將它同步到 GitHub，並在你自己控制的基礎設施上運行。
常見問題
用白話來說，什麼是測試環境？
測試環境是 App 的私人副本，盡可能與正式版本相近，讓你在真正的使用者看到變更之前先行測試。如果那裡出了問題，團隊以外的人都不會受到影響。
測試環境和正式環境有什麼區別？
正式環境是真正的使用者與真實資料所依賴的線上 App。測試環境則是預演用的副本，設定與正式環境相同，但使用獨立的測試資料與測試金鑰，讓你可以安全地嘗試變更。
測試環境會使用和正式環境相同的資料庫嗎？
不應該。測試環境應該有自己的資料庫，裡面放的是測試資料，或是經過清理的正式資料副本。如果共用資料庫，一次測試就可能改動或刪除真實客戶的紀錄。
小型 App 需要測試環境嗎？
不一定需要完整的測試環境。單人專案通常只要有私人預覽、檢查清單，以及能夠還原的能力就夠了。一旦涉及真正的客戶、付款或團隊，一個能獨立測試變更的地方就變得非常有價值。