跳到主要内容
返回使用场景

Codex 使用场景

将你的应用带到 ChatGPT

将你的使用场景转化为面向 ChatGPT 的专注型应用。

高级1 小时集成代码
在 Codex app 中尝试官方来源

概览

端到端构建一个聚焦的 ChatGPT 应用成果：定义工具、搭建 MCP 服务器和可选的小组件、在 ChatGPT 中完成连接，并持续迭代直到核心流程可用。

适合场景

  • 围绕某个用户结果规划第一个 ChatGPT 应用
  • 搭建 MCP 服务器、工具元数据和可选小组件，同时避免过度构建
  • 从本地 HTTPS 测试到 ChatGPT 开发者模式验证，进行紧凑的迭代闭环

先规划应用，再开始搭建

使用 $chatgpt-apps 和 $openai-docs，为这个仓库中的 [使用场景] 规划一个 ChatGPT app。

要求：
- 从一个核心用户结果开始。
- 提出 3-5 个工具，包含清晰的名称、说明、输入和输出。
- 建议 v1 是否需要 widget，还是可以先从纯数据开始。
- MCP server 优先使用 TypeScript，widget 优先使用 React。
- 点出认证、部署和测试要求。

输出：
- 工具方案
- 建议的文件树
- 黄金提示词集
- 风险和待确认问题

建议推理强度：中

你将构建什么

每个 ChatGPT 应用都由三个部分组成：

  • 一个 MCP 服务器，用于定义工具、返回数据、强制执行身份验证，并将 ChatGPT 指向任何所需的 UI 资源。
  • 一个可选的 Web 组件，在 ChatGPT iframe 中渲染。你可以使用 React 构建，也可以使用原生 HTML、CSS 和 JavaScript。
  • 一个模型，根据你提供的元数据决定何时调用应用的工具。

当 Codex 负责这些部分周边重复性的工程工作时，它最有价值：

  • 规划工具接口和元数据。
  • 搭建服务器和小组件。
  • 连接本地运行脚本。
  • 以聚焦的方式分阶段添加身份验证和部署变更。
  • 编写验证闭环，证明应用可在 ChatGPT 中正常工作。

为什么 Codex 非常适合

  • ChatGPT 应用天然清晰地拆分为服务器、可选小组件，以及由模型驱动的工具调用。
  • 当任务明确、范围清晰且易于验证时，Codex 提示效果最佳，这与应用构建工作高度匹配。
  • Skills 和 AGENTS.md 为 Codex 提供了所需的可复用说明和项目规则，帮助它保持与上下文一致。

如需了解如何安装和使用 skills，请参阅我们的skills 文档。

如何使用

前提条件

  • 从一个核心用户结果开始，而不是试图把整个产品搬进聊天界面。
  • 提前选定技术栈：服务器使用 TypeScript 或 Python，小组件使用 React 或原生 HTML、CSS 和 JavaScript。
  • 确定开发期间要使用的 HTTPS 路径，例如 ngrok 或 Cloudflare Tunnel。
  • 当前文档通常使用 app 一词，但一些较旧的页面和设置仍然使用 connector。在本地测试时，可以把它们视为同一个配置对象。
  1. 从一个范围狭窄的应用结果开始，让 Codex 提出三到五个工具，并为每个工具提供清晰的名称、描述、输入和输出。
  2. 决定 v1 是否可以保持为纯数据型，或是否需要小组件；然后在添加依赖之前，优先基于现有仓库模式搭建 MCP 服务器和可选小组件。
  3. 在 HTTPS 后面本地运行应用，在 ChatGPT 开发者模式中连接，并使用一组简短的直接、间接和负向提示进行测试。
  4. 持续迭代元数据、状态处理、structuredContent 和 _meta 负载，直到核心读取流程在 ChatGPT 内可靠运行。
  5. 仅当用户特定数据或写操作确实需要时再添加 OAuth 2.1，同时尽可能保持匿名或只读流程简单。
  6. 准备一个托管预览版本，提供稳定的 /mcp 端点，验证流式传输和小组件资源托管，并在共享或提交应用前检查发布清单。

推荐提示词

适用于此工作流的高质量提示词通常都具备相同的要素：

  • 一个明确的结果：说明应用应帮助用户在 ChatGPT 中完成什么。
  • 一个具体的技术栈：说明服务器使用 TypeScript 还是 Python，以及小组件使用 React 还是保持轻量。
  • 明确的工具边界：让 Codex 提议或构建一小组工具，并确保每个工具只负责一项任务。
  • 身份验证预期：说明第一版是否可以匿名使用，还是需要账户关联和写操作。
  • 一条本地开发路径：说明你期望在 ChatGPT 中进行 HTTPS 测试时使用的隧道或托管路径。
  • 验证步骤：告诉 Codex 要运行哪些命令、测试哪些提示词，以及需要回报哪些证据。

避免使用一个巨大的提示词，一次性要求完成规划、实现、身份验证、部署、提交和打磨。应将工作拆分为更小的里程碑。

先规划应用，再开始搭建

搭建第一个可运行版本

仅在核心流程可用后再添加身份验证

为部署和审核准备应用

发布就绪

  • 应用有一个对用户而言显而易见的、范围狭窄的结果。
  • 工具集保持精简，并具备明确的元数据、输入和输出。
  • MCP 服务器端到端可用，并返回简洁的 structuredContent，仅将小组件专用数据保留在 _meta 中。
  • 小组件（如果需要）能在 ChatGPT 中正确渲染。
  • 通过 ChatGPT 开发者模式进行的本地 HTTPS 测试闭环可用。
  • 一组简短的直接、间接和负向提示能够按预期通过，并产生正确的对话流程和工具负载。
  • 仅在用户特定数据或写操作需要时才添加身份验证。
  • 在共享或提交应用前，部署计划和发布就绪审核应覆盖元数据、工具提示、隐私和测试提示词。

常见陷阱

  • 让 Codex 把整个产品移植进 ChatGPT。更好的做法：要求一个核心用户结果、三到五个工具，以及一个范围狭窄的小组件。
  • 一开始就使用巨大的实现提示词。更好的做法：将工作拆分为规划、搭建、身份验证、部署和审核几个阶段。
  • 在工具契约尚不清晰前就编写 UI。更好的做法：先规划工具接口和响应 schema，再构建小组件。
  • 跳过官方文档作为依据。更好的做法：将 $chatgpt-apps 与 $openai-docs 搭配使用，让脚手架遵循当前的 Apps SDK 指南。
  • 把元数据当作事后补充。更好的做法：尽早编写工具描述和参数文档，然后用一组提示词反复验证它们。
  • 在证明匿名或只读路径可行之前就添加身份验证。更好的做法：先让核心工具流程运行起来，再只为真正需要的工具添加 OAuth。
  • 在未在 ChatGPT 中测试之前就宣布应用完成。更好的做法：在开发者模式下连接应用、检查工具负载，并验证真实的对话流程。