Developer Mode vs Store

1. 前言

在前面的講座中，我們已經談過什麼是 ChatGPT App、它由哪些層構成，以及它與舊時代的外掛或單純基於 OpenAI API 的機器人有何不同。現在我們轉向第二個重要主題——這類應用的生命週期。

如果你做過幾年的 Web 服務，「lifecycle」這個詞不會讓你害怕。任何產品都有一條原始的路徑：「在本機寫好 → 發到 staging → 發到 production → 有時全壞掉 → 修好」。在 ChatGPT 生態與 App 中也大致如此，但有些細節不同：多了 ChatGPT 內部的 Dev Mode，以及一個獨立的實體——Store。

務必要清楚區分兩個層面：

1. 你的程式碼實際部署在哪裡：本機的 Next.js 伺服器、Vercel、某個 Kubernetes 叢集等等。那是你的世界，你在那裡說了算。
2. ChatGPT 如何看見你的 App：它是一組中繼資料、URL 與權限的集合，既可以在 Developer Mode 中連接，也可以整理成成品在 Store 上架。那已經是 OpenAI 的世界，有自己的規則、審核與使用者。

本講專注於第二個層面。我們會沿用你熟悉的環境模型（dev / staging / prod），但用 ChatGPT 的視角來看。目標是讓你隨時能回答幾個問題：目前是哪些程式碼在跑我的 App？誰看得到它？如何安全地做實驗？在 Store 中「更新 App」到底意味著什麼？

2. Developer Mode：ChatGPT 內部的私人沙盒

先從開發者最喜歡的地方開始：一個你可以盡情搞壞，且幾乎不會傷害到任何人的沙盒。

Developer Mode 是 ChatGPT 的一種特殊模式，你可以直接透過 URL 連接自己的 ChatGPT Apps，不用經過審核，不必把 App 發佈到 Store，也不會對全世界可見。它的精神很像瀏覽器中的 localhost:3000，只是發生在 ChatGPT 的世界裡。

概念上長什麼樣

最容易的想像方式如下：

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["App 的 Dev 組態 (URL + 中繼資料)"]
    AppServer["你的 App 伺服器 (Next.js + Apps SDK)"]

    User -->|聊天中的請求| ChatGPTCore[GPT]
    ChatGPTCore -->|需要 App| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/工具| ChatGPTCore
    ChatGPTCore --> User

作為開發者，你會在 Developer Mode 的設定裡對 ChatGPT 說：「這是我的 App，這是它的 URL，這是它的名稱與能力。」ChatGPT 便會把這個 URL 視為你的應用來源。只要你沒有把 App 送上 Store，基本上只有你（以及你加入為開發者的團隊成員）能看見它。

連線的技術細節（HTTPS 通道、Vercel 等等）我們之後會再談。此處最重要的觀念是：Dev Mode 就像是 ChatGPT 會呼叫的、指向你 dev 伺服器的一個「動態捷徑」。

如何啟用 Developer Mode

為了讓您能夠將本地伺服器「連接」到 ChatGPT 介面，您需要在設定中啟用相應的開關。

• 點擊連結 https://chatgpt.com/#settings/Connectors/Advanced 或進入 Settings -> Connected apps -> Advanced。
• Developer Mode - ON

一旦您這樣做，Create App 按鈕就會出現。

Dev Mode 與 production 有何不同

差異很像一般 Web 中 dev 與 production 環境的不同，但也有一些平台特有的地方。

首先是可見性。在 Dev Mode 中，你的 App 通常不對一般 ChatGPT 使用者開放。僅你本人，或你組織內擁有相應權限的人可以看到。可以放心做實驗，不必怕路人撞見半壞的 UX。

其次是穩定性與實驗。在 Dev Mode 中，你可以兩分鐘改一次程式，啟動本機伺服器、把它關掉、重開通道。ChatGPT 會盡量依據你提供的 URL 連線，但如果你偶爾回傳 500 或暫時不回應，它也不會介意——這本來就是 dev。

第三是權限與政策。在 Dev Mode 中嘗試不同組態會比較容易。但要記得，即便在 dev 模式，內容政策與基礎安全也不會被關閉：ChatGPT 不會允許你突然變成「面向所有人的『駭客 App』」。不過此時還不會套用 Store 的完整審核要求：你可以尚未準備完美的上架頁或漂亮圖示等。

最後，在 Dev Mode 通常更容易診斷問題點。你可以快速調整邏輯、觀察 ChatGPT 對你的伺服器發出的請求，並修正行為，而不必考慮「用戶遷移」。

我們已把 Dev Mode 當作應用的私人沙盒來看，也稍微瞄到了 Store。接下來把這些整理成一個清楚的「狀態機」，描述 App 的生命週期。

3. ChatGPT App 的狀態：從草稿到下架

現在把它整理成你的 App 的「狀態機」。我們大致討論四個主要狀態：Draft / Dev-only、Under review、Published，以及 Paused/Removed。

生命週期的狀態機

試著用圖示表示：

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / 草稿
    Review: Under review (Store)
    Published: 在 Store 中，對使用者可見
    Paused: Paused / Removed

    Draft --> Review: 送審
    Review --> Draft: 被退回 / 返回調整
    Review --> Published: 通過
    Published --> Paused: 暫停 / 下架
    Paused --> Draft: 在 dev 模式繼續開發
    Draft --> Published: 無需 Store 的內部發佈 (僅組織內)

在 Draft 狀態下，你的 App 僅作為 dev 資源存在。你可以把它接到 Developer Mode 嘗試各種功能，但不需要把它放到 Store。

當你認為 App 準備好給人看時，你會把它送「審核」——也就是 Under review 狀態。在這個階段，OpenAI（或你組織的內部審核系統）會檢查它是否符合政策、是否穩定、是否具備基本安全，以及 UX 是否合理。

如果一切順利，App 會進入 Published：它會出現在 Store，或（在企業場景中）對你公司的使用者可見。從這一刻起會有真正的使用者湧入，你對程式與組態的任何變更都需要更謹慎地規劃。

如果你暫時不希望 App 對外開放，可以把它切到 Paused/Removed。Paused 狀態下，它對新使用者隱藏，但可能仍服務已開始的會話，或完全關閉——細節取決於平台實作與設定。

4. Store：當你的 App 變成產品

Developer Mode 是你的私人車庫；Store 則是正式的經銷展示中心。這裡開始會有使用者、評分、上架規則與審核流程。

進入 Store 後有何改變

第一點、也是最重要的一點：你的 App 變成「產品」。它會有上架頁：名稱、描述、圖示、分類，有時還有啟動對話的提示。ChatGPT Store 會依這些中繼資料搜尋與推薦你的應用，而模型本身也會更理解你的 App 在哪些情境下相關。

第二點是審核與政策。在 App 出現在 Store 之前，會先檢查它是否符合安全、內容與 UX 的要求。這代表：

• 不得悄悄蒐集過多的個人資料；
• 不得宣稱 App 做不到的事；
• 不得超出允許的內容類別。

關於政策與沙盒我們會在之後詳細說明，但現在就把 Store 想成一個你只會帶「相對成熟」版本的 App 去的地方。

第三點是對穩定性的責任。在 Dev Mode 玩壞了，影響的是你自己；但在 Store 中，大家期待你的 App 具備合理可用性、延遲在可接受範圍，且不會在 widget 中頻繁出現「死亡紅畫面」。稍後的單元我們會在這個脈絡下談 SLO、指標與 Store 的審核。

版本：dev 與 production

常見問題：「如果我更新了程式碼，使用者會看到什麼？」在 ChatGPT Apps 的世界，同時思考兩個「分支」會很有幫助：

• dev 分支：連接到 Developer Mode，可能指向緊鄰你 IDE 的 dev 伺服器；
• production 分支：與 Store 已發佈的組態關聯，並指向穩定的 URL。

從架構角度，你甚至可以在專案中用一個小小的 TypeScript 類型來表達：

type AppStage = 'dev' | 'production';

interface ChatGPTAppConfig {
  id: string;
  stage: AppStage;
  endpointUrl: string;
}

const giftGeniusDev: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'dev',
  endpointUrl: 'https://dev.giftgenius.example.com',
};

const giftGeniusProd: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'production',
  endpointUrl: 'https://app.giftgenius.example.com',
};

在真實情況下，組態並不是由你的程式碼保存，而是由 ChatGPT 平台管理；但類似的結構有助於你牢記：那是同一個 App 的兩個不同「映像」。

ChatGPT App 的發佈更像在 Apple App Store 發版，而不是更新網站。你的 widgets 與 mcp-tools 會在每次應用發佈時被快取。而審核可能需要 2 週。所以別想「先發到 production 再去那裡測」。你應該送審一個已完整測試且穩定的應用。

5. 組織脈絡：個人帳號 vs 公司

我們已把 App 分成 dev 與 production 分支，並看了這在 Store 中如何呈現。生命週期的另一個重要維度是它在組織上的「歸屬」。

最簡單的情況，是你以個人身分、在自己的 ChatGPT Plus 內開發 App。此時 Dev Mode 完全屬於你，Store 也掛在你的帳號下。事情相對單純：為自己做，發佈出去，造福世界。

但很多時候，ChatGPT Apps 會存在於企業場景。這時會有幾個額外角色：組織管理員負責決定哪些 App 對員工可用、哪些需要封鎖、哪些只能給試點群組使用。你的 App 可能不是對全球公開，而是只對某家公司，甚至公司內的特定部門。

在這個場景下，生命週期可能這樣演進：一開始 App 只是團隊內的 dev 專案；接著有一個「內部 production」——例如只對業務部門開放做試點；最後，如果一切順利，你才決定把 App 送到全球 Store，把它做成外部產品。

對架構設計而言，這意味著你需要把 App 設計得既能當內部工具，也能作為公開產品。有時這代表需要功能旗標、只對內部開放的模式，以及獨立的身分驗證設定。

6. 實作情境：GiftGenius 的生命週期

為了避免以上內容過於抽象，我們來看一個假想的 App——GiftGenius：你的選禮助手，它會伴隨我們一路學習。

階段 1：想法與 Dev Mode 粗略原型

你決定做 GiftGenius：一個 App，會詢問使用者禮物要送給誰、預算多少、收禮者的興趣為何，然後用你的商品目錄提出建議。

第一步，你會：

1. 啟動一個簡單的 Next.js 專案，帶有最小化的 widget。
2. 在 ChatGPT 中開啟 Developer Mode，並在那裡加入你的 dev 伺服器 URL。
3. 進行一些測試對話：請 GPT「幫我替一位玩家朋友選 50 美元以內的禮物」，觀察它如何呼叫你的 App、如何渲染 widget、UX 長什麼樣。

此時你不必考慮 Store、審核或漂亮的圖示。目標是先證明給自己與團隊看：這個想法可行，而 ChatGPT 平台能否支持所需的情境。

階段 2：強化原型與內部「Alpha」

當你確信基本情境可行，就進入「強化」階段。你會：

• 把邏輯整理得更有結構；
• 開始思考 App 真正需要哪些權限與資料；
• 檢查 App 在錯誤情境下的表現（例如商品目錄未回應時）。

仍然是在 Dev Mode，但不再是你一個人：你把同事加為開發者或測試者，讓他們也能把 App 接到自己的 ChatGPT。在這個階段，生命週期仍圍繞 Draft：你會快速更新程式、嘗試不同的 UX 模式、在團隊內部討論回饋。

階段 3：準備進入 Store 與送審

這一步你下定決心：「是的，GiftGenius 已經夠體面，可以給外部使用者看了。」焦點從程式碼轉向產品包裝：

• 撰寫清楚且誠實的 App 描述；
• 設定權限：說明 App 要存取哪些資料、為什麼；
• 確認 UX 不會誤導，且 App 不會做出不切實際的承諾。

這是從 Draft 轉到 Under review 的時刻。你把 App 送審，它會在中間狀態待一陣子。可能你會收到意見：需要補充隱私政策、修正文案、縮減權限。你再回到 Draft，修改後重新送出。

階段 4：發布與「真正的上線生活」

審核通過後，你的 GiftGenius 會進入 Published 狀態。使用者可以在 Store 找到它，ChatGPT 也會在相關請求中推薦它，你開始收集真實回饋、觀察使用情況並思考擴展。

從現在起，每次改動程式都不再只是「我來快速補個功能」；而是小型的發版。你需要思考 backward compatibility，設計遷移流程，盡量先改 dev 版本、驗證通過後，再更新 production 組態。

必要時你可以暫時把 App 切到 Paused，例如發現重大漏洞或後端扛不住負載。但理想狀態是持續演進 Published 分支，同時別忘了用 dev 環境做實驗。

7. 開發者如何思考環境：dev、staging、production + Dev Mode

以 GiftGenius 為例，我們走過從 Dev Mode 的概念到已發佈的 App。現在把它整理成你熟悉的環境劃分——dev/staging/production——並看看它們如何對應到 Dev Mode 與 Store。

最常見、也最直觀的一張心智矩陣如下：

本質上，Developer Mode 會貼合你的 dev 或 staging 基礎設施：你發布一個臨時 URL，ChatGPT 用它來測試。相對地，Store 的組態會指向成熟的 production URL。

未來在談到部署到 Vercel 與通道設定時，這張矩陣會被落地為一連串具體步驟。但現在先記住一個簡單原則：務必知道 ChatGPT 當前的請求落在何處——是在你的 dev 沙盒，還是在對使用者開放的生產環境。

8. 一小段關於生命週期的程式碼

為了把以上內容連回你熟悉的 TypeScript 思維，我們寫個簡單的型別，反映 App 的生命週期，不在平台層，而在你自家的工具鏈層。可以把它放到版本庫，避免遺漏不同狀態。

type AppLifecycleState = 'draft' | 'under_review' | 'published' | 'paused';

interface LifecycleSnapshot {
  id: string;
  name: string;
  state: AppLifecycleState;
  lastDeployedAt: Date | null;
  devUrl?: string;
  prodUrl?: string;
}

const giftGeniusLifecycle: LifecycleSnapshot = {
  id: 'giftgenius',
  name: 'GiftGenius – 禮物挑選',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

這樣的物件不會直接送到 ChatGPT，但能幫助團隊保持一致的上下文。你甚至可以做個簡單的 CLI，顯示所有 App 的狀態，避免把草稿與 Store 中的版本搞混。

在接下來的模組中，我們會不斷回到這個生命週期模型：設定通道與 Vercel 部署、設計 MCP 伺服器與代理情境、規劃商務流程，以及準備 Store 審核。把 Dev Mode 與 Store 想成一個系統的兩極：前者是做實驗的沙盒，後者是成熟產品的展示櫃。

9. 使用 Dev Mode 與 Store 時的常見錯誤

錯誤 1：「直接上 Store，再慢慢處理」。
有時大家想盡快「搶占市場」，在半成品階段就把 App 丟進 Store。這幾乎保證換來負評、低使用率，還會在審核時被追問。更健康的做法是先在 Developer Mode 迭代幾輪，收集同事與朋友的回饋，穩住基本 UX，再去 Store。

錯誤 2：混用 dev 與 production 環境。
常見情境：你把 Dev Mode 指到與 production 相同的 URL，接著驚訝於為何「幾個小小的除錯改動」會被真實使用者看到。就像一般 Web 服務一樣，dev 與 prod 的 URL 必須嚴格區隔。若在 ChatGPT App 組態裡設定的是 production URL，就別拿來做「晚上快速實驗」。

錯誤 3：沒有清楚掌握狀態。
當開發者不清楚 App 目前處於哪個狀態（Draft、Under review、Published、Paused），就會發生怪事：有人以為 App 已在 Store，另一個人還當它是本機原型。至少在專案的 README 裡寫清楚目前狀態，以及下一步要做什麼。

錯誤 4：把政策與審核留到最後一刻。
有些團隊把 App 當「只是個網站」來做，直到送審前一天才想到政策、權限與 Store 要求。結果發現資料收集與儲存需要大改、描述要重寫、權限得縮減。最佳做法是從一開始就把框架放在心上，並在 Dev Mode 中用誠實且最小化的權限來實驗。

錯誤 5：沒有為內部與外部使用制定不同策略。
若一開始 App 是公司內部工具，後來想把它做成公開產品，容易搞混目標受眾。公司內部容得下不那麼「亮眼」的 UX 與較複雜的流程；而在對外的 Store，使用者期待更友善的體驗。若搞不清現在處於哪個模式，結果往往是公開版本看起來像內部管理工具，而內部試點卡關，因為你太早在意全球上架。

錯誤 6：沒有把 Dev Mode 與可觀測性串起來。
Developer Mode 非常適合除錯，但要善用這個優勢。如果你不看日誌，也不記錄 ChatGPT 在 dev 環境對你的 App 發了哪些請求，將來在 production 可能會遇到驚喜。把 Dev Mode 當成研究模型與使用者真實行為的場域，而不只是「確認 widget 能編譯」。