上架与推广：内容、本地化、版本说明

1. 把上架页当作产品的一部分，而不是“走流程的表单”

开发者第一次走到 Store 时，常把上架页当作“又一个需要随便填点东西的长表单”。这就像在凌晨三点给仓库写 README：“以后再好好改”。剧透：通常很少会真的改。

对于 ChatGPT App，上架页是用户在点击“Try”或继续划走之前看到的第一项，有时也是唯一一项。名称、副标题、简短描述、使用场景列表、图标——这些都在充当一个微型落地页。

此外，上架页不仅影响人，也影响 ChatGPT 本身。 元数据（名称、类别、描述）参与发现机制（discovery）。 当模型决定针对某个请求向用户推荐哪个 App 时，它也会参考你在这里写的文本。

官方指南要求 App 的名称和描述清晰、准确，不得对功能产生误导。不要写“我们是能做一切的魔法 AI”或“某平台的官方客户端”，如果事实并非如此。

也就是说，这一步你在同时做三件事：

1. 向人解释你的 App 存在的意义。
2. 向 Store 与 ChatGPT 的算法暗示在什么场景下应该推荐你的 App。
3. 铺设信任基础：只承诺你确实能做到的内容，不玩魔法与黑暗模式。

2. ChatGPT App 上架页的骨架

具体的 Store 界面可能改变字段与外观，但逻辑骨架通常近似。以今天常见的带 UI 小部件的 ChatGPT App 为例，需要准备：

再提醒一次：官方指南要求名称与描述清晰诚实，不要冒充任何“官方客户端”。上表也把这些要求落到了具体字段上。

这些看起来有点官僚，直到你把自己放在用户的位置。你打开 Store，看见一堆卡片，你的注意力只有五秒。看着 GiftGenius，你想立刻搞清楚：

• 这个 App 是否符合我的任务？
• 它是否安全，不会对我的数据做奇怪的事？
• 它和普通的 ChatGPT 对话有什么不同？

你的上架页应该能回答这些问题。

3. 名称与副标题：如何避免自坑

好名称的标准

App 的名称承担多重角色：对话中会被提到（“打开 GiftGenius”），在搜索中会被输入，在列表里会被看到。因此理想的名称应当：

• 简短易记；
• 传达核心概念（GiftGenius → “与礼物和‘聪明’相关”）；
• 不侵犯他人的商标；
• 不做不可能的承诺，也不假装是某个平台的官方客户端。

我们前面提到的 OpenAI 指南明确禁止误导性的名字，包括暗示你没有的官方身份。

看看 GiftGenius 的一些示例。

在课程中我们继续使用 GiftGenius 作为主名称。如果你做自己的 App，不要害怕轻量品牌化：“TripTailor”“StockScout”“LegalChecklist”等都可以。

副标题：一句话定乾坤

副标题就是你的 one-liner。它会出现在 Store 的结果和 App 页面上。官方指南建议这类文本要清晰诚实地说明 App 的用途。

糟糕示例：

"面向一切任务的完美 AI 助手！"

优秀示例：

"在聊天中用 30 秒根据对方兴趣挑选礼物。"

优秀的副标题应当：

• 告诉用户将获得什么结果；
• 暗示上下文（在我们的例子中——“就在聊天里”）；
• 不要陷入技术细节（“分析 embedding 向量”没人关心）。

实践中不妨写 5–7 个版本，再用非技术读者的视角重读。如果你自己读出来都磕绊——就重写。

4. 描述：简短与长版，改前/改后

简短描述

简短描述通常由几句话组成，与副标题一起展示。它往往是懒得展开详情的用户最后一次被你吸引的机会。

结构：

1. 第一句——App 做什么。
2. 第二句——它与普通 ChatGPT 或其他 App 有何不同。

GiftGenius 的“修改前”示例：

"用于选礼物的 App。使用 MCP 和复杂后端以给出最佳结果。"

问题：

• 技术细节过多；
• 不清楚你比直接用 ChatGPT 好在哪里；
• 没有描述用户场景。

改写为：

"GiftGenius 可按对方兴趣、预算与场合挑选礼物。你在聊天中回答几个问题，App 就会给出带链接的具体创意。"

这里我们贴合真实的用户体验：“回答几个问题 → 看到创意”。这样的文本也能帮助 ChatGPT 更好理解你的典型场景。

长描述

长描述由更有意愿了解的用户阅读，但他们也不想看技术论文。一个实用模板：

1. 目标受众（如“总是最后一刻才想起要买礼物的人”）。
2. App 解决哪些问题（2–3 个核心场景）。
3. 与直接问 ChatGPT 相比有什么便利之处。
4. 数据与安全如何——非常简短，并指向政策页面。
5. 语言/地区限制（若有）。

以 GiftGenius 为例：

GiftGenius 适合总是在最后一刻才想起要准备礼物的人。
App 会询问你要为谁选礼、预算是多少、是什么场合，然后给出带描述和链接的备选清单。

与普通的 ChatGPT 对话不同，GiftGenius 会使用你的商品目录与最新价格，并在对话中记住历史挑选记录。

App 不会比推荐所需更久地存储你的会话。详情见我们的隐私政策。

重点是不要把描述写成架构术语的垃圾场。底层当然可能有 MCP、Agents、缓存、特性开关，但用户更关心场景：更快、更简单、更可靠。

5. 截图、视频、图标与外部视觉

文字部分讲完了。接下来是用户“看到”的内容：图标、可能的截图与短视频。

ChatGPT App 的视觉会出现在哪里

在 2025–2026 年，面向普通 GPT 的 ChatGPT Store 界面并不提供类似移动商店的“截图轮播”：主要是图标、名称、作者与启动提示语。

对带 UI 小部件的 ChatGPT Apps 也类似：主要“橱窗”在 ChatGPT 内部（App 首次启动、内嵌小部件等）。外部截图、视频与更宽的视觉呈现通常放在：

• App 的独立落地页；
• 文章/公告（“我们如何打造 GiftGenius”）；
• Product Hunt、GitHub README 等平台。

因此当我们说“为上架页准备截图和视频”，在实践中多半指你将从 Store、文档或社媒引导用户去看的外部资源。

App 图标

图标在成排的应用中出现时就不再是小事。基本原则：

• 简单形状，小圆形中也清晰可辨（128×128）；
• 尽量少文字，最好没有文字；
• 与背景有良好对比；
• 与 App 主题有视觉关联（礼物、购物车、图表分析等）。

对 GiftGenius，一个合理选项是简洁的礼盒图标，背景对比强，不要在上面小字写“GG”。

截图：展示什么

当你做落地页或介绍文章时，截图应展示：

• 主路径：用户提问 → 小部件显示推荐；
• “高光时刻”：筛选、选择，或（若有）Instant Checkout 集成；
• 尽量少的噪音：去掉个人敏感信息（PII）、用测试账号替代真实用户、界面保持干净。

一个好的实操方法是搭建单独的“演示目录”，用虚拟商品与规范化的名称，避免暴露内部标识与他人品牌。

短视频

用普通录屏工具即可录制 30–60 秒的 walkthrough：打开 ChatGPT，输入典型请求，展示 App 如何出现以及交互方式。本质上你是在重放 UX 模块中的某个 golden prompt。

GiftGenius 的脚本：

1. 用户输入：“需要给一位开发同事准备礼物，预算 $50”。
2. ChatGPT 推荐 GiftGenius。
3. 小部件出现，提出澄清问题，然后给出候选清单。

这样的影片同时适用于落地页和社交媒体帖子。

6. 上架页本地化：策略与陷阱

从视觉转到语言。即便 UI 和数据已经做了很好的本地化（第 9 模块我们已实践过），上架页有自己的坑。

为什么并不简单

你的 App 也许很好地本地化了 UI 与数据，使用了 openai/locale、_meta["openai/userLocation"] 等第 9 模块的技巧。但上架页依然是另一回事。

截至 2025–2026 年，ChatGPT Store 不会根据用户界面语言自动切换 App 的名称与描述。也就是说，你没有“内置”的多语言元数据机制：Store 只显示一组文本。

由此衍生出三种常见策略。

策略 1：通用英语（Universal English）

最简单与常见的做法——名称与描述都用英文。你可以在文本里明确列出 App 支持的语言：

"Supports English, Spanish, Russian."

优点：单一上架页，维护简单，多数技术受众能读。缺点显而易见：不习惯读英语的用户转化更差。

策略 2：混合命名

试图“两头兼顾”的办法：“GiftGenius | 礼物”。这样的名字英语用户与中文用户都能读懂。

优点：更多人能直觉理解 App 做什么。缺点：显得“嘈杂”，可能破坏 Store 的整体风格；而且长描述仍需选定一种语言。

策略 3：按语言拆分 App

适合较大的项目：把“GiftGenius (RU)”与“GiftGenius (Global)”做成不同的 App，共用 MCP 后端。

优点：

• 可以完全适配描述、启动提示语，甚至使用流程以匹配本地市场；
• 更好的 Store 内“SEO”：用中文写作的用户会看到易懂的名称与描述。

缺点：

• 使用统计与评价被分散到多个 App；
• 更多维护工作：每个 App 的发布、上架页与审核。

实操建议

对教学/PoC 级别的 App，通常 Universal English 足够，尤其主要受众是开发者。做真正的产品时，合理的折中是从一两种语言起步，保证高质量翻译，而不是一上来就用机器翻译“十国语言大杂烩”。

与本地化模块的衔接是：UI 与数据你已能灵活本地化。现在只需保证上架页文本不与用户实际看到的内容矛盾。比如 App 已经能正常用西班牙语工作，就不要在上架页写“只支持英语”。

7. 版本说明：别再写“我们做了改进”，要写对用户的价值

上架页是初次会面。之后 App 会演进，需要让用户知道变化——这就需要版本说明。

在 ChatGPT App 语境下，什么是版本说明

版本说明是对新版本变更的简要概述：新增了什么、修复了什么、提速了什么。传统商店会有“版本历史”标签。当前 ChatGPT Store 可能没有这一栏，因此版本说明通常放在：

• Store 控制台中新版本的描述里；
• 你的网站/博客/代码仓库；
• App 内部，如果你允许用户询问“有什么新变化”。

格式通常很简单：版本号、日期与关键变更列表。

为什么值得投入时间

首先，用户能看到 App 是“活的”：你在持续改进与修复。这会提升对你的代码与业务的信任。

其次，你自己有了时间轴：方便回查某功能何时加入，在支持或对内沟通时引用。

第三，版本说明是现成的轻量推广素材：一封邮件、一条社媒帖、一段短视频。

如何撰写：卖“收益”，而不是内部术语

来自移动商店的经验与产品写作建议可归结为一句话：用用户将获得的好处来描述变化，而不是你内部改了哪些实体。

不好：

"v1.1 — 重构了推荐算法，改进了 scoring，修复了一些 bug。"

更好：

"v1.1 — 对小众爱好人群的礼物匹配更精准。
当你提到桌游、手工或音乐时，GiftGenius 现在理解更到位。
还修复了一个偶发问题，会导致推荐列表有时被清空。"

连 bug 修复也可以表述为“可靠性提升”的用户收益。

GiftGenius 的示例

首次发布：

v1.0 — GiftGenius 首次发布
- 基于姓名、兴趣与预算的礼物推荐。
- 支持 USD/EUR。
- 界面本地化：EN、RU。

第二次发布：

v1.1 — 基于照片的推荐与按类型筛选
- 新增实验性工具：可上传对方的桌面照片，GiftGenius 将给出相关创意。
- 新筛选项 "digital-only gifts"——如果对方在异地会很方便。
- 加速目录检索，推荐列表打开更快。

这种格式很容易同时用于 Store 文本与“GiftGenius 有哪些新变化”的短帖。

8. 轻量推广计划：让自己看起来“有点懂营销”

再好的上架页与规整的版本说明也不会自动带来用户。你需要至少一个开发者也能完成的轻量推广计划。

完整的营销是另一个课程，但没有任何推广，即便是最好的 App 也会在 Store 里吃灰。我们需要一套你作为开发者确实能执行的最小动作。

在 ChatGPT 生态内的“内生推广”

首要的是：写得好的上架页本身就是推广的一部分。元数据与描述能够帮助 ChatGPT 在相关对话中推荐你的 App，Store 搜索也会更容易找到你。

由此带来一些实操要点：

• 在描述里提到典型场景（买礼物、准备报告等）；
• 不要用技术行话把上架页塞满——这只会吓跑用户；
• 避免“面向一切与所有人”的宽泛宣称，以免稀释“SEO”。

外部推广：落地页、社媒、社区

研究建议为 ChatGPT Apps 准备一个简易推广计划：

1. 做一段 30–60 秒的预览视频，展示关键场景。
2. 写一篇博客文章：“我们如何打造 GiftGenius”，配两张截图与高层级架构说明。
3. 在社媒（Twitter/X、LinkedIn、Telegram）发 1–2 条带链接的帖子，指向 App 或落地页。
4. 邀请 5–10 位熟悉的同事/朋友试用并给出坦诚反馈。

重要的是不要变成“群发型”营销：不要在推文里@所有人，也不要在所有群里刷屏。一个好规则是——每条内容都要提供实际价值（演示、架构解读、有趣案例的拆解）。

哪里发布版本说明

如前所述，Store 可能没有单独的版本历史页。因此将版本说明合理地“多处发布”：

• App 在 Store 的页面（若能添加新版本文本）；
• 你的网站（Changelog 专区）；
• 仓库的 README（若 App 为开源或部分开源）；
• 面向感兴趣用户的邮件列表或频道。

在这里，最好使用统一的“原始结构”，在代码或配置里定义，然后面向不同渠道渲染即可。

最简单的 TypeScript 示例：

// shared/releaseNotes.ts
export const releaseNotes = [
  {
    version: "1.0.0",
    date: "2025-02-01",
    changes: [
      "GiftGenius 首个公开版本",
      "按兴趣与预算选礼物",
    ],
  },
  {
    version: "1.1.0",
    date: "2025-03-10",
    changes: [
      "新增筛选项“仅数字礼物”",
      "加快目录搜索",
    ],
  },
];

这个数组既可用于小部件（回答“有什么新变化？”），也可用于你网站的 Changelog 页面生成。

9. 全景示例：GiftGenius 上架页草稿

把一切串起来，来起草我们的教学 App 上架页。

文本版本

名称：
GiftGenius

副标题：
在聊天中按兴趣与预算，在 30 秒内选出礼物。

简短描述：
GiftGenius 会询问对方、预算与场合等几个问题，并给出带描述与链接的创意清单。非常适合距离节日只剩一个晚上的时候。

长描述（精简版）：

GiftGenius 适合那些厌倦了在最后一刻苦思冥想礼物的人。
App 会询问你要为谁选礼、TA 的兴趣与你的预算，
随后给出带简短描述与购买链接的具体创意。

与直接和 ChatGPT 聊天不同，GiftGenius 会利用你的商品目录与最新价格，
并能在同一会话内记住挑选历史。

App 支持英文与俄文界面。
我们不会将你的数据用于训练第三方模型，并且仅在单次会话范围内保存挑选记录。
详情见我们的隐私政策。

启动提示语：

• “Help me find a birthday gift for a colleague who loves board games, budget $40.”
• “请为喜欢园艺的妈妈推荐礼物，预算不超过 3000 ₽。”
• “Suggest digital-only gifts for a friend who lives abroad, budget €50.”

图标： 极简礼盒，采用品牌色。

语言： EN、RU（在描述中明确；UI 已能通过 openai/locale 自动切换）。

链接：
Privacy Policy、Terms of Use、Support page——这些我们已在上一讲中完成。

示意图：从上架页到使用的用户路径

为便于理解——一张小图：

flowchart TD
    A[Store 中的 GiftGenius 上架页] --> B[用户阅读
名称与描述]
    B --> C{他是否理解
App 的价值？}
    C -- 是 --> D[点击 Try / 连接 App]
    C -- 否 --> E[继续浏览]
    D --> F[与 ChatGPT 的首个对话]
    F --> G[模型基于请求上下文
推荐 GiftGenius]
    G --> H[出现小部件
进入选礼流程]

一个好的上架页能提升用户走“是”这条路径的概率，并在 G 步就对 App 有大致预期。

10. 上架与推广中的常见错误

错误 №1：名称与副标题承诺了不存在的魔法。
“Ultimate AI that does everything” 很诱人，但会在两方面伤害你。用户期待的是万能助手，结果却是一个专用工具。Store 的审核也可能提问：这些表述是否符合实际行为与政策。指南明确要求用清晰准确、不夸大的表述。

错误 №2：描述被技术细节淹没。
“使用 MCP、Agents SDK、edge 层缓存”——这些在技术分享里很酷，但对上架页毫无帮助。用户关心的是场景与结果：更快、更省事、更可靠。把技术细节留给“我们如何实现”的博客文章。

错误 №3：忽视上架页本地化。
App 的 UI 与数据本地化做得很好，但上架页用蹩脚机翻，或者在一个不读英文为主的市场只放英文。结果你在用户第一次启动前就损失了转化。与其十种语言的“胡言乱语”，不如一两种语言的高质量文本。

错误 №4：图标与视觉“临时抱佛脚”。
细节过多、在小圆里难读的文字、或在众多图标里容易淹没的灰色图标。用户根本记不住这是你的 App。花几个小时打磨一个干净的图标与清晰的截图：它们会在文章、幻灯与社媒中长期复用。

错误 №5：版本说明只有“bug fixes and improvements”。
是的，大家都这么写，但你可以更好。如果一个月后连你自己都看不懂 1.3 版本改了什么，用户更不可能看懂。用用户收益来描述变化：哪里更快、哪里更稳、增加了哪些新场景。简洁，但要具体。

错误 №6：没有任何外部公告。
App 已经上架，但你谁也没告知。没有帖子、没有短视频、没有博客记录。结果只有搜索里偶然的用户看见你的 App。哪怕最小化的公告也能带来首批安装与反馈，帮助你快速改进。

错误 №7：上架页与 App 的真实行为不一致。
上架页写“App 不存储数据”，但保留策略配置却不是这样；或者承诺支持中文，但实际仍在 beta 且问题频出。这不仅会带来差评，也可能引发 Store 的质询。上架页文本应该跟随前面模块中讨论过的架构与安全设置，而不是“各走各的”。