Developer Mode vs Store

1. 引言

在前面的课程中，我们已经讨论了什么是 ChatGPT App，它由哪些层组成，以及它与旧式插件和基于 OpenAI API 的简单机器人有何不同。现在进入第二个重要主题——这种应用的生命周期。

如果你有几年构建 Web 服务的经验，“lifecycle” 这个词并不可怕。任何产品都有一条朴素的路径：“本地开发 → 发布到 staging → 发布到 production → 有时全崩 → 修好”。在 ChatGPT 生态和 App 的世界里也类似，但有一些差异：平台内部出现了 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 就像指向你 dev 服务器的“动态快捷方式”，ChatGPT 会按这个 URL 去调用。

如何启用 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 则是官方 4S 店。这里会出现用户、评分、上架页规则和审核。

进入 Store 后发生了什么变化

首先也是最重要的：你的 App 成为“产品”。它会有上架页：名称、描述、图标、分类，有时还有对话的起始提示。ChatGPT Store 会基于这些元数据来搜索和推荐你的应用，模型本身也会据此理解你的 App 适用于哪些场景。

第二个关键点——审核与政策。在 App 出现在 Store 之前，它会被检查是否符合安全、内容与 UX 的要求。这意味着：

• 不能偷偷收集多余的个人数据；
• 不能承诺 App 做不到的事情；
• 不能超出允许的内容分类范围。

关于政策与沙盒我们会在后续课程详谈，但现在就应该把 Store 当作只应提交相对“规矩”的 App 版本的地方。

第三点——对稳定性的责任。在 Dev Mode 里，宕机是你的问题；在 Store，你的 App 被期望具备合理的可用性、合适的延迟，并且没有组件里的“红色死亡屏”。在后续模块中，我们会在这个语境下讨论 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 中的应用发布，而不是网站更新。你的组件和 mcp-tools 会在每次应用发布时被缓存。而审核可能需要 2 周时间。所以不要抱着“先上 production，再去补测”的想法。你提交审核的应该是已经充分测试且稳定的应用。

5. 组织维度：个人账号 vs 公司

我们已经把 App 分成了 dev 与 production 分支，并看了它在 Store 中的映射。生命周期的另一个重要维度是它“组织上”归属何处。

最简单的情况是，你以个人身份在自己的 ChatGPT Plus 中开发 App。此时 Dev Mode 仅属于你，Store 也挂在你的账号下。流程相对简单：为自己而做，上架，惠及他人。

但很多时候，ChatGPT Apps 运行在企业场景中。这时会出现更多角色。有组织管理员决定哪些 Apps 对员工可用、哪些需要屏蔽、哪些只开放给试点群组。你的 App 可以只对某个公司公开，甚至只对公司内特定部门开放，而不是面向全世界。

在这种场景下，生命周期可能是这样：起初 App 只是团队内的 dev 项目，然后出现“内部 production”——例如只对销售部开放试点。只有在一切顺利后，你才会决定把 App 投递到全球 Store，使之成为对外产品。

这对架构很关键，因为你需要把 App 设计得既能作为内部工具，也能作为公共产品。有时这意味着要有特性开关、“仅内部使用”的模式，以及独立的认证设置。

6. 实战示例：GiftGenius 的生命周期

为避免上述内容流于抽象，我们来看一个虚拟的 App——GiftGenius：一个礼物推荐助手，它会在接下来的课程中持续出现。

阶段 1：Dev Mode 中的想法与粗糙原型

你决定实现 GiftGenius：一个 App，会询问用户送礼对象、预算与兴趣爱好，然后基于你的商品目录给出备选。

第一步你会：

1. 启动一个简单的 Next.js 项目，提供最小化的组件。
2. 在 ChatGPT 中开启 Developer Mode，并添加你的 dev 服务器 URL。
3. 进行若干测试对话：例如让 GPT “帮我给一位游戏玩家挑选 50 美元以内的礼物”，观察它如何调用你的 App、如何渲染组件，以及 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 会在相关请求中推荐它，你也开始收集真实反馈、观察使用情况并考虑扩展。

现在每一次代码变更都不再是“我马上补个功能”这么简单了。这是一轮小型发布。你需要考虑向后兼容、规划迁移，尽量先修改 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 来展示所有 Apps 的状态，避免把草稿和 Store 中的产品搞混。

在后续模块中，我们会持续回到这个生命周期模型：当我们配置隧道与 Vercel 部署、设计 MCP 服务器与 Agent 场景、构思商业流程以及准备 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 中说明当前 App 身处何处，以及进入下一阶段需要做什么。

错误 4：把政策与审核留到最后一刻。
有的团队“把 App 当网站来做”，直到提交审核前一天才想起政策、权限与 Store 的要求。结果发现必须重做数据采集与存储、重写描述并收紧权限。最好从一开始就把这些边界放在心上，在 Dev Mode 中就以诚实、最小化的权限来试验。

错误 5：没有区分内部与外部使用的策略。
如果 App 最初作为企业内工具开发，而后又希望对外发布，很容易混淆目标受众。在公司内部可以容忍不那么“光鲜”的 UX 和更复杂的流程；在对外的 Store，用户会期待更高的易用性。若不清楚当前处于哪种模式，就会导致对外的 App 看起来像内部管理工具，而内部试点又被拖慢，因为你过早地考虑全球上架。

错误 6：没有把 Dev Mode 和可观测性打通。
Developer Mode 非常适合调试，但需要善用这一优势。如果你不看日志，也不记录 ChatGPT 在 dev 环境中发给你的 App 的具体请求，那么到了 production 可能会遇到意外。应把 Dev Mode 用作研究模型和用户真实行为的场所，而不仅是“看看组件能不能编译”。