在 DevDay 上，我们推出了 ChatGPT 应用，让您能够以一种全新的方式将产品直接带入 ChatGPT 对话。本文在此次发布的基础上，为开发者、产品经理和设计师提供实用指导，介绍如何选择合适的用例，并设计出上线后能真正发挥作用的应用。我们将重点介绍如何把产品优势转化为清晰、范围明确的能力，让模型能够根据各种对话和用户意图运用这些能力。如果您想了解最初的技术工作流程，可以直接阅读 Apps SDK 快速入门和开发者文档。
我们将介绍：
- ChatGPT 应用究竟是什么，又不是什么
- 应用真正创造价值的三种方式
- 如何围绕对话和探索来设计应用
- 如何判断您的应用是否真的有帮助
- 具体示例和截图建议
ChatGPT 应用究竟是什么
团队构建第一个 ChatGPT 应用时，往往会从这样的想法出发：
“我们已经有了一个产品，把它带入 ChatGPT 吧。”
这通常意味着从现有的网页或移动端体验入手，尝试将其中的页面、菜单和流程改造成适合聊天的形式。这种直觉不难理解，毕竟多年来，“软件”一直意味着页面、导航和界面框架。
然而，为 ChatGPT 构建应用，面对的是一个不同的环境。用户并不是“打开”您的应用，然后从首页开始使用。他们正在围绕某件事展开对话，模型可以决定何时将应用引入其中。用户是在对话的某个时刻开始接触应用的。 在这种环境下，最好的应用从外部看往往小得出乎意料。它们不会试图重现整个产品，而是让用户在 ChatGPT 中使用应用时，能够获得几项 具体能力 ：也就是您的产品最擅长、模型又能在任何对话中复用的能力。
在 ChatGPT 之外，用户往往是专门来使用您的应用的。他们会：
- 点击您的应用图标
- 进入您的应用环境
- 熟悉您的导航和界面交互方式
大多数产品决策都基于这样一个假设：“整个屏幕由我们掌控。”用户既然选择在您的产品中完成操作，您就可以在布局、新用户引导和信息架构上投入大量精力。
而在 ChatGPT 中，您的应用扮演着不同的角色：
- 它是模型可以调用的一项 能力 ，既能提供上下文，也能提供视觉交互体验。
- 它出现在正在进行的对话 之中 。
- 它是模型可能编排使用的多个工具之一。
这意味着，价值的基本单位不再主要是您的整体体验，而是在恰当的时刻，您能帮助模型和用户完成的具体事项。
一个实用的定义是：
ChatGPT 应用是一组定义明确的工具，可以执行任务、触发交互或访问数据。
这意味着：
- 您不需要移植每一项功能。
- 您不需要一套完整的导航层级。
- 您 确实 需要一套清晰、精简的 API：包含少量易于调用、也便于在其基础上继续处理的操作。
您可以这样理解：您的 ChatGPT 应用就是一个工具箱，当用户遇到某类特定问题时，模型就会调用其中的工具。这个工具箱定义得越精确，就越容易在对话过程中使用。
一旦您把应用看作“模型可以编排的能力”，而不是“我们产品的迷你版”，设计决策就会更清晰。您会开始问“在这里我们能帮上什么忙？”，而不是“接下来应该让用户去哪里？”。
真正创造价值的三种方式
任何应用构想都可以用以下几个简单问题来筛选：
- 获取信息： 它是否让用户能够使用原本在 ChatGPT 中无法获取的新上下文或数据？
- 执行操作： 应用是否能代表用户采取实际行动？
- 呈现信息： 应用是否能通过比纯文本更清晰、更便于采取行动的界面来呈现信息？
这既适用于 “正经干活” 的效率应用，也适用于游戏等 “纯粹为了好玩” 的应用。游戏可能无法帮助用户更快地交付报告，但它仍然能做到基础模型单独难以做好的事情：维护有状态的游戏逻辑、跟踪进度、执行规则，或渲染有趣的游戏世界视图。它的价值在于带来乐趣和投入感，但背后的模式是一样的。
1）获取新的信息
您的应用可以在 ChatGPT 对话中提供新的上下文：
- 实时价格、可用情况、库存
- 内部指标、日志、分析数据
- 专业数据集、需订阅才能访问的数据集，或小众领域的数据集
- 特定用户的数据（账户、历史记录、偏好、权益）
- 传感器数据、实时视频流
在实践中，这通常意味着接入数据准确、及时且受权限控制的系统。应用成为模型在您所在领域的“眼睛和耳朵”，回答问题时也能更有依据。
2） 执行新的操作
您的应用可以代表用户执行操作：
- 在内部工具中创建或更新记录
- 发送消息、工单、审批、通知
- 安排日程、预订、下单或进行配置
- 触发工作流（部署、升级处理、同步数据）
- 进行互动游戏（应用规则、推进回合、跟踪状态）
- 在物理世界中执行操作（物联网、机器人控制等）
在这里，应用与其说是权威信息来源，不如说是一双执行操作的手。它将用户的意图转化为团队日常使用的系统中的具体变更；对于游戏，则是对游戏状态的具体变更，让体验保持连贯、公平。正是在这里，您的应用开始实质性地转变为智能体。
3）以更好的方式呈现信息
应用可以在 ChatGPT 对话中通过图形用户界面呈现信息，让信息更易理解，或更便于用户据此采取行动：
- 候选清单、对比、排名
- 表格、时间线、图表
- 面向特定角色或帮助做出某项决策的摘要
- 游戏状态的可视化或结构化视图（棋盘、物品栏、分数）
当用户需要做出选择或权衡时，这一点尤其有价值。应用可以为模型提供一种结构化的表达方式：通过包含列、行、评分和视觉元素的小组件，贴合人们实际做决策的方式；在游戏中，则贴合玩家理解自己在游戏世界中“身处何处”的方式。
如果应用在 获取信息、执行操作、呈现信息这三个方面都没有带来明显提升，用户往往会觉得，它并没有在 ChatGPT 已有能力之外提供额外价值。用户可能不会直接抱怨，但无论应用用于工作还是娱乐，这都意味着错失了为用户创造更有意义的价值的机会。
下面的示例展示了应用如何改善使用体验：
ChatGPT 的回答示例这个回答很有帮助，但用户可能希望使用具备更多能力的应用，无需切换上下文或离开对话，就能直接浏览真实房源。
使用 Zillow 应用时的回答
有了 Zillow 应用，用户还可以搜索实时房源、按条件筛选并查看丰富的房源详情，全程无需离开聊天。
全屏模式带来更丰富的探索体验
这里的价值在于，您既能继续获得模型提供的丰富上下文，也能获得更丰富、可根据您的意图动态交互的应用体验。想让它查找某个区域的房源？使用 Zillow 应用时，模型会调用 Zillow MCP 服务器上的工具，并重新渲染 UI 层。
精选能力，不要照搬整个产品
一个常见的初始想法是列出产品的所有功能，然后问：“我们如何把这些功能带入 ChatGPT？”
这听起来很周全。但在实践中，通常会形成一套庞杂且边界模糊的功能，模型难以选用，用户也难以理解。如果连您都很难用一句话概括应用的用途，模型理解起来也会更困难。
更有效的做法是：
-
列出用户要完成的核心任务： 明确用户希望完成、而您的产品能够帮助实现的具体任务或目标。这些正是产品存在的根本理由。从这里出发，您就能始终聚焦于用户想要的结果，而不是功能清单。
例如：- 帮助用户选择住房。
- 将想法转化为精美的演示文稿。
- 根据用户意图，提供愉悦的探索体验。
- 将原始数据转化为清晰、可分享的报告。
-
针对每项任务，问一问：
“如果没有应用，用户在 ChatGPT 对话中有哪些事情做不了？”
常见答案包括：
- 访问实时数据或私有数据。
- 在我们的系统中执行实际操作。
- 获得用户所需的结构化或可视化输出。
-
您的独特价值就从这里开始显现。您考虑的不再是“从技术上看，我们能开放哪些功能？”，而是“在哪些方面，我们能提供独有的帮助？”
-
将这些缺口转化为少量 命名清晰的操作。例如：
search_properties：返回结构化的候选房源列表。explain_metric_change：获取相关数据，并总结可能的影响因素。generate_campaign_variants：创建多个带有元数据的广告版本。create_support_ticket：创建工单，并返回摘要和链接。
这些操作具有以下特点：
- 足够具体，让模型有把握做出选择
- 足够简单，便于与对话中的其他步骤组合
- 直接对应用户价值，而非整个产品的功能版图
也可以换个角度思考：如果团队里有人问：“这个应用必须做好的三件事是什么？”那么这三件事应该与产品的能力几乎一一对应。
例如，ChatGPT 中的 Canva 应用可以生成一整份演示文稿草稿，用户还可以进入全屏模式，以符合预期的方式浏览幻灯片；但更深入的逐页编辑仍需在完整版 Canva 编辑器中完成。
围绕对话与探索进行设计
您可以在 MCP 服务器中定义 description，为模型提供上下文，说明执行某项具体任务时应在何时调用您的工具，以及具体应发起哪些工具调用。这有助于将用户意图与工具操作对应起来。
a）意图模糊
帮我想想住在哪里合适。
好的应用响应会做到以下几点：
- 利用对话中已有的相关上下文。
- 如有需要，最多提出一两个澄清问题。
- 快速给出具体内容，例如列出几个城市，并附上简短说明。
用户应该感觉事情已经开始推进，而不是被拉进了一个多步骤的新手引导流程。如果必须先回答五个问题才能看到有用的内容，许多人会直接放弃。
我们来看看 Canva 应用是如何处理这种情况的：
制作完整的演示文稿需要上下文。Canva 应用会通过追问，帮助用户梳理自己想要制作的内容。
b）意图明确
帮我查找西雅图价格低于 120 万美元、有 3 间卧室且靠近高评分小学的房源。
此时，应用不应要求用户重复已经说过的内容，而应：
- 解析查询。
- 调用合适的能力。
- 返回一组有针对性的结果，并以实用的结构呈现。
您仍然可以提供进一步细化的选项（“您更看重通勤还是学校评分？”），但这些选项应该让人感觉是可选的调整，而不是必需的设置步骤。
Canva 示例：
当用户意图变得明确，并提出生成演示文稿的请求时，模型就能准确知道何时调用 Canva，以及调用哪项能力。
如下所示，工具会提供几个选项；如果用户希望进一步调整，它也会继续深入了解需求：
c）不了解品牌
您不能假定用户知道您是谁。
您的首次实质性响应应做到以下几点：
- 用一句话说明您的应用有什么作用（“我会获取实时房源和学校评分，方便您比较不同选择。”）
- 立即提供有用的结果。
- 给出明确的下一步（“您可以让我按通勤、社区或预算进一步筛选。”）
可以将其视为一个冷启动问题：您需要在一两条消息内介绍应用 是什么 、 为什么 有用，以及 如何 使用。
同时面向模型和用户设计
您的设计面向两类对象：
- 参与聊天的用户
- 决定何时以及如何调用您的应用的模型运行时
大多数团队都熟悉如何为第一类对象设计。第二类则相对陌生。但如果模型无法理解您的应用能做什么、该如何使用，那么您为用户设计的体验就很少有机会发挥作用。
还有一个同样重要的维度： 模型调用您的应用时，哪些用户数据会流经应用。 好的应用设计不仅要有清晰的能力，还要严格把握请求 哪些数据 以及 如何 使用这些数据。
-
清晰且含义明确的操作和参数： 让模型一目了然地知道何时适合使用您的应用，以及如何调用它。使用直观的名称（
search_jobs、get_rate_quote、create_ticket），并明确说明哪些参数必填、哪些可选，以及各自的格式。含糊不清会增加路由选择的难度。 -
将隐私保护融入设计： 只将真正需要的字段设为必填。避免使用将额外上下文一并收集的“大包式”参数。优先采用最少量的结构化输入，不要使用“直接发送整段对话”之类的指令。
-
可预测的结构化输出： 保持模式稳定，包含 ID，并使用清晰的字段名。将简短摘要（“三个符合您预算和通勤时间要求的选项”）与便于机器处理的列表（
[{id, address, price, commute_minutes, school_rating, url}, …]）配对。这样，模型既能自然地交流，又能准确引用数据。 -
明确哪些内容 不应 返回： 不要抱着“以防万一”的心态返回敏感内部信息。不要让 Token 或密钥进入用户可见的路径。不需要保留完整细节时，应进行脱敏或汇总。
-
明确说明收集什么以及为什么收集： 只请求完成任务所需的最少信息。需要敏感信息或权限（例如账户访问权限）时，用一句话说明原因。在设计操作和模式时，要让人清楚地知道哪些数据会被发送到哪里。
面向生态系统设计，而非打造封闭产品
在实际的 ChatGPT 会话中，您的应用很少会是唯一参与的应用。模型可能会在同一段对话中调用多个应用。
对用户而言，这是一个连贯的流程。对您而言，这提醒您：您的应用是生态系统的一部分，而不是一个封闭的产品。
在实践中，这意味着：
-
让操作保持 小而专注
search_candidates、score_candidates、send_outreach- 而不是用单个
run_full_recruiting_pipeline包办一切。
-
让输出 便于传递给后续环节
- 使用稳定的 ID、清晰的字段名和一致的结构。
- 避免将重要信息仅放在自由格式文本中。
-
避免冗长、只能一路走到底的流程
- 完成您负责的部分，然后将控制权交还给对话。
- 让模型决定下一步应由哪个工具处理。
如果其他应用（或您自己的应用的未来版本）可以轻松利用您的输出继续工作，您就能从生态系统其他部分的改进中受益，而不必与之竞争。
快速检查清单
您可以在开发前或开发后使用这份简短的检查清单：
-
1. 新增能力
- 您的应用是否明确提供了新的信息、操作或展示方式？
- 如果应用停止工作，目标场景中的用户会察觉吗？
-
2. 聚焦的功能范围
- 您是否选择了少量能力，而不是照搬整个产品？
- 这些能力的命名和范围是否与用户实际要完成的任务清晰对应？
-
3. 首次交互
- 您的应用能否妥善处理模糊和具体的提示？
- 新用户能否从第一个有实质内容的回复中了解您的应用有什么作用？
- 他们能否在第一轮对话中感受到价值？
-
4. 对模型友好
- 操作和参数是否清晰、无歧义？
- 输出是否足够结构化且一致，便于串联使用和复用？
-
5. 评估
- 您是否准备了一套精心设计的小型测试集，涵盖正向、负向和边界用例？
- 与 ChatGPT 不使用该应用时的回答相比，您是否大致了解应用提供的回答的胜率？
-
6. 生态适配
- 其他应用和用户能否顺畅地利用您的输出继续工作？
- 您是否愿意成为多应用协作流程中的一环，而不是包揽整个流程？
您不必在每个维度都做到完美才能发布。但如果您对其中大多数问题都能回答“是”，那么您就不只是把产品放进 ChatGPT，而是在自己的领域中切实增强 ChatGPT 的能力。这也正是这些应用开始让人觉得不可或缺的原因。