OpenAI 发布指南：什么样的 ChatGPT 应用才算好应用

在 DevDay 上，我们推出了 ChatGPT Apps —— 一种将你的产品直接带入 ChatGPT 对话的新方式。本文基于该发布，为开发者、产品经理和设计师提供实用指导，帮助他们选择合适的用例，并设计出上线后真正有用的应用。我们将重点讨论如何将你产品的优势转化为清晰、范围明确的能力，让模型能够在众多不同的对话和用户意图中加以运用。如果你在寻找原始的技术工作流程，可以直接跳转到 Apps SDK 快速入门和开发者文档。

我们将涵盖：

ChatGPT 应用究竟是什么（以及不是什么）
应用真正增加价值的三种方式
如何为对话和发现而设计
如何判断你的应用是否真正有帮助
具体示例和截图建议

ChatGPT 应用究竟是什么

当团队构建他们的第一个 ChatGPT 应用时，出发点往往是：

“我们已经有一个产品了。把它带入 ChatGPT 吧。”

这通常始于拿现有的网页或移动端体验——屏幕、菜单、流程——并试图将其重塑为聊天形式。这是一种合理的直觉；多年来，“软件”一直意味着页面、导航和 UI 框架。

然而，为 ChatGPT 构建应用是一个不同的环境。用户不会“打开”你的应用并从主页开始。他们正在就某事进行对话，模型可以决定何时将应用引入该对话。他们是在某个时间点进入的。在那个世界里，最好的应用从外部看小得令人惊讶。它们不会试图重建整个产品。相反，它们允许用户在 ChatGPT 中使用应用时访问少数特定能力：即你的产品最擅长、模型可以在任何对话中复用的具体功能。

在 ChatGPT 之外，你的应用通常是目的地。用户：

点击你的图标
进入你的环境
学习你的导航和 UI 模式

大多数产品决策都源于这个假设：“我们拥有屏幕。”你可以大量投入布局、引导和信息架构，因为用户正在进入你的空间。

在 ChatGPT 内部，你的应用扮演着不同的角色：

它是模型可以调用的能力——用于获取上下文和视觉参与。
它出现在正在进行的对话内部。
它是模型可能编排的若干工具之一。

这意味着“价值单元”较少取决于你的整体体验，而更多取决于你能够在恰当时机帮助模型和用户完成的具体事项。

一个实用的定义：

ChatGPT 应用是一组定义明确的工具，可以执行任务、触发交互或访问数据。

这有几个含义：

你不需要移植每一个功能。
你不需要完整的导航层级。
你确实需要一个清晰、紧凑的 API：少量易于调用且易于构建的操作。

你可以这样想：你的 ChatGPT 应用是一个工具包，当用户遇到特定类型的问题时，模型会伸手去拿。这个工具包定义得越精确，在对话流程中就越容易使用。

一旦你将应用视为“模型可以编排的能力”，而不是“我们产品的迷你版”，设计决策就会变得更清晰。你开始问“我们能在这里帮上什么忙？”而不是“用户下一步该去哪里？”

真正增加价值的三种方式

对任何应用创意的一个简单筛选标准：

Know（知道）：它是否让用户能够处理他们在 ChatGPT 中原本看不到的新上下文或数据？
Do（做）：该应用是否代表用户采取真实行动？
Show（展示）：该应用是否以比纯文本更清晰、更可操作的 UI 呈现信息？

这适用于“严肃”的生产力应用，也适用于像游戏这样的“纯娱乐”应用。游戏可能无法帮助某人更快地完成报告，但它仍然做了基础模型自身无法做好的事情：维护有状态的游戏逻辑、跟踪进度、执行规则，或渲染游戏世界中有趣的视图。其价值在于愉悦感和参与感，但底层模式是相同的。

1）新的可知之事

你的应用在 ChatGPT 对话中提供新的上下文：

实时价格、可用性、库存
内部指标、日志、分析数据
专业化的、订阅受限的或小众的数据集
用户特定数据（账户、历史记录、偏好、权益）
传感器数据、实时视频流

在实践中，这通常意味着桥接到数据准确、最新且经过权限控制的系统。应用成为模型在你所在领域的“眼睛和耳朵”，能够以更高的权威性回答问题。

2）新的可做之事

你的应用代表用户采取行动：

在内部工具中创建或更新记录
发送消息、工单、审批、通知
安排、预订、下单或配置事项
触发工作流（部署、升级、同步数据）
玩互动游戏（应用规则、推进回合、跟踪状态）
在物理世界中采取行动（IoT、机器人控制等）

在这里，应用与其说是真相的来源，不如说是一双手。它接收用户的意图，并将其转化为你的团队已经赖以生存的系统中的具体变更——或者，就游戏而言，转化为游戏状态中的具体变更，使体验感觉一致且公平。正是在这里，你的应用以有意义的方式转变为一个智能体。

3）更好的展示方式

应用可以在 ChatGPT 对话中以 GUI 呈现信息，使信息更易于消化或更具可操作性：

候选清单、对比、排名
表格、时间线、图表
针对特定角色或特定决策的摘要
游戏状态的可视化或结构化视图（棋盘、物品栏、分数）

当用户在做选择或权衡时，这尤其有价值。应用可以为模型提供一种结构化的语言：具有列、行、分数和视觉效果的组件，与人们实际的决策方式相匹配——或者，在游戏中，与他们理解自己在世界中“身处何处”的方式相匹配。

如果一个应用没有在know/do/show中至少一项上明显有所推动，它往往会让人觉得它没有提供超出用户在 ChatGPT 中已能完成的价值。用户可能不会明确抱怨，但无论是用于工作还是娱乐，这都是错失了为用户提供更有意义价值的机会。

在这里你可以看到一个由应用增强的体验示例：

来自 ChatGPT 的示例回答

这个回答很有帮助，然而用户可能希望使用一个具有额外能力的应用，直接浏览真实房源，而无需更改上下文或离开对话。

find-homes 使用 Zillow 应用回答

借助 Zillow 应用，用户还获得了额外能力：搜索实时房源、按条件筛选，并查看丰富的房源详情——所有这些都无需离开聊天。

find-homes-zillow

用于丰富探索的全屏模式

find-homes-fs

这里的价值在于，你仍然能从模型获得丰富的上下文，同时还能获得一个能够动态响应你意图的增强应用体验。想询问某个特定区域的房源？在 Zillow 应用中，模型会调用 Zillow MCP 服务器上的工具，并重新渲染 UI 层。

选择能力，而不是移植产品

一个常见的初步想法是列出你产品的所有功能，然后问：“我们如何把这些带入 ChatGPT？”

理论上，这听起来很全面。但在实践中，它通常会产生一个庞大而模糊的界面，模型难以驾驭，用户也难以理解。如果你很难用一句话概括这个应用的功能，模型也会更难理解它。

更有效的路径：

列出核心待办任务 - 找出用户试图完成、而你的产品能帮助实现的具体任务或成果。这些正是你的产品存在的根本原因。从这里出发，能让你锚定在用户成果上，而不是功能清单上。
示例：
- 帮助某人选择一套住房。
- 将想法转化为精美的演示文稿。
- 将意图转化为愉悦的发现体验。
- 将原始数据转化为清晰、可分享的报告。
对于每项任务，问：

“如果没有这个应用，用户在 ChatGPT 对话中无法做什么？”

常见答案：
- 访问实时或私有数据。
- 在我们的系统中采取真实行动。
- 获得用户所需的结构化或可视化输出。
这正是你独特价值开始显现的地方。你不再思考“我们在技术上能暴露什么？”，而是思考“我们在哪里能提供独特的帮助？”
把这些缺口转化为少量命名清晰的操作。例如：
- search_properties – 返回结构化的候选房源列表。
- explain_metric_change – 获取相关数据并总结可能的驱动因素。
- generate_campaign_variants – 创建多个带有元数据的广告变体。
- create_support_ticket – 打开工单并返回摘要 + 链接。

这些操作：

足够具体，让模型能自信地选择
足够简单，能与对话中的其他步骤混合使用
直接与价值挂钩，而不是与你的整个产品版图挂钩

换一种思路：如果团队中有人问：“这个应用绝对需要做好的三件事是什么？”这些应该几乎与你的产品能力一一对应。

例如，ChatGPT 中的 Canva 应用可以生成完整的演示文稿草稿，用户可以进入全屏模式，这符合用户浏览幻灯片的预期，但更深入的逐页编辑仍然在完整的 Canva 编辑器中进行。

canva-app-fs

为对话和发现而设计

在你的 MCP 服务器中，你可以定义 description，为模型提供上下文，说明何时调用你的工具，以及具体调用哪些工具来执行特定任务。这有助于将用户意图映射到你的工具操作。

a) 模糊意图

帮我弄清楚该住在哪里。

一个好的应用响应会：

利用对话中已有的相关上下文。
如有需要，最多提出一两个澄清问题。
快速产出具体内容——例如，几个示例城市并附简短说明。

用户应该感觉进展已经开始，而不是被丢进一个多步骤的引导流程。如果他们必须回答五个问题才能看到任何有用的东西，很多人会直接放弃。

让我们看看 Canva 应用是如何处理这一点的：

构建一个完整的演示文稿需要上下文。Canva 应用会提出后续问题，引导用户梳理他们想要构建的内容。

canva-app-discovery

b) 特定意图

查找西雅图地区售价低于 120 万美元、靠近优质小学的三居室住宅。

在这里，应用不应让用户重复自己的需求。它应该：

解析查询。
调用正确的功能。
返回一组聚焦且有清晰结构的结果。

你仍然可以提供细化选项（“你更在意通勤还是学校评分？”），但它们应该像是可选的微调，而不是必需的设置步骤。

Canva 示例：

当用户意图变得明确并要求生成演示文稿时，模型清楚知道何时调用 Canva 以及调用哪项功能。

如下所示，该工具提供了几个选项，并在用户想要进一步细化时深入询问：

canva-app

c) 无品牌认知

你不能假设用户知道你是谁。

你的第一次有意义的回复应该：

用一句话说明你的应用的作用（“我拉取实时房源和学校评分，让你可以比较各种选择。”）
立即提供有用的输出。
提供明确的下一步（“让我按通勤、社区或预算来缩小范围。”）

把它当作冷启动问题：你要在一条或两条消息内介绍你是什么、你为什么有用以及如何使用你。

既要为模型构建，也要为用户构建

你在为两类受众设计：

聊天中的人
决定何时以及如何调用你的应用的模型运行时

大多数团队习惯于考虑第一类。第二类则较新。但如果模型无法理解你的应用做什么或如何使用它，你面向人类的体验就不会有多少运行机会。

还有第三个同样重要的维度：当模型调用你的应用时，有哪些用户数据流经你的应用。好的应用设计不仅在于清晰的功能，还在于对你请求什么以及你如何使用它保持克制。

清晰、描述性的操作和参数：让人一眼看出你的应用何时相关以及如何调用它。使用直白的名称（search_jobs、get_rate_quote、create_ticket），并明确哪些参数是必需的、哪些是可选的，以及如何格式化它们。含糊不清是路由的负担。
隐私源于设计：只要求你真正需要的字段。避免会捎带额外上下文的“blob”参数。优先使用最小化、结构化的输入，不要使用“把整个对话都发过来”之类的指令。
可预测、结构化的输出：保持 schema 稳定；包含 ID 和清晰的字段名。将简短摘要（“三个符合你预算和通勤时间的选项”）与机器友好的列表（[{id, address, price, commute_minutes, school_rating, url}, …]）配对。这让模型可以自然对话，同时保持对数据的精确掌控。
对不返回什么要有意识：不要“以防万一”而返回敏感的内部信息。让 token/密钥远离用户可见的路径。当不需要完整保真度时，进行脱敏或聚合。
明确说明你收集什么以及为什么：只请求完成工作所需的最少信息。当你需要敏感信息（例如账户访问权限）时，用一句话说明原因。设计操作和 schema，让发送了什么、发往哪里一目了然。

为生态系统而设计，而非封闭花园

在真实的 ChatGPT 会话中，你的应用很少是唯一参与其中的。模型可能会在同一对话中调用多个应用。

从用户的角度看，这是一个流程。从你的角度看，这提醒你是生态系统的一部分，而不是一个封闭的产品。

几个实际后果：

保持操作小而聚焦
- search_candidates、score_candidates、send_outreach
- 而不是一个单一的 run_full_recruiting_pipeline。
让输出易于传播
- 稳定的 ID、清晰的字段名、一致的结构。
- 避免把重要信息只藏在自由格式的文本里。
避免冗长、隧道式的流程
- 做好你分内的工作，然后把控制权交还给对话。
- 让模型决定下一步该由哪个工具来处理。

如果其他应用（或你自己应用的未来版本）能轻松地基于你的输出进行构建，你就为自己创造了从生态系统中其他地方的改进中获益的机会，而不是与它们竞争。

一份快速检查清单

一份你可以在构建之前或之后运行的简短检查清单：

1. 新能力
- 你的应用是否清楚地知道、能做或能展示新东西？
- 如果你目标场景中的用户发现它停止工作了，他们会注意到吗？
2. 聚焦的界面
- 你是否挑选了一小组能力，而不是克隆你的整个产品？
- 这些能力的命名和范围界定是否清晰地对应到真实的待办任务？
3. 首次交互
- 你的应用是否能优雅地处理模糊和具体的提示？
- 新用户能否从第一次有意义的回复中理解你的角色？
- 他们能否在第一轮就看到价值？
4. 对模型友好
- 操作和参数是否清晰明确？
- 输出是否足够结构化和一致，以便串联和复用？
5. 评估
- 你是否有一个小而周全的测试集，包含正面、负面和边缘案例？
- 你是否对应用提供的答案与没有应用时 ChatGPT 的答案之间的胜率有所了解？
6. 生态契合度
- 其他应用和用户能否合理地基于你的输出进行构建？
- 你是否愿意成为多应用链条中的一环，而不是整个旅程？

你不需要在每个维度上都做到完美才能发布。但如果你能对其中大部分问题回答“是”，你就不只是把产品放进了 ChatGPT，而是在你的领域里给了 ChatGPT 真正的杠杆——而这正是这些应用开始让人感到不可或缺的地方。