English
主导航
Codex

Codex 用例

将你的应用接入 ChatGPT

将你的用例转化为 ChatGPT 中的专属应用。

难度 高级
时间周期 1h

端到端地构建一个聚焦于单一结果的 ChatGPT 应用:定义工具,搭建 MCP 服务器和可选小组件,在 ChatGPT 中连接它,并不断迭代直到核心流程正常运行。

适用场景

  • 围绕用户结果规划首个 ChatGPT 应用
  • 搭建 MCP 服务器、工具元数据和可选小组件,避免过度构建
  • 在本地 HTTPS 测试到 ChatGPT 开发者模式验证之间运行紧凑的迭代循环

目录

    ← 所有用例

    将你的应用接入 ChatGPT

    将你的用例转化为 ChatGPT 中的专属应用。

    端到端地构建一个聚焦于单一结果的 ChatGPT 应用:定义工具,搭建 MCP 服务器和可选小组件,在 ChatGPT 中连接它,并不断迭代直到核心流程正常运行。

    高级
    1h

    端到端地构建一个聚焦于单一结果的 ChatGPT 应用:定义工具,搭建 MCP 服务器和可选小组件,在 ChatGPT 中连接它,并不断迭代直到核心流程正常运行。

    高级
    1h

    适用场景

    • 围绕用户结果规划首个 ChatGPT 应用
    • 搭建 MCP 服务器、工具元数据和可选小组件,避免过度构建
    • 在本地 HTTPS 测试到 ChatGPT 开发者模式验证之间运行紧凑的迭代循环

    技能与插件

    • 规划工具,连接 MCP 资源,并遵循当前的 ChatGPT 应用构建流程。
    • 在 Codex 编写代码或建议架构之前,获取当前的官方 Apps SDK 指南。
    • 通过精心策划的技能和官方 Vercel MCP 服务器,将 Vercel 生态系统指南引入 Codex。
    技能 为什么使用它
    ChatGPT 应用 规划工具,连接 MCP 资源,并遵循当前的 ChatGPT 应用构建流程。
    OpenAI 文档 在 Codex 编写代码或建议架构之前,获取当前的官方 Apps SDK 指南。
    Vercel 通过精心策划的技能和官方 Vercel MCP 服务器,将 Vercel 生态系统指南引入 Codex。

    起始提示词

    使用 $chatgpt-apps 和 $openai-docs 规划此代码库中针对 [use case] 的 ChatGPT 应用。要求: - 从一个核心用户结果开始。 - 提出 3-5 个具有明确名称、描述、输入和输出的工具。 - 建议 v1 版本是否需要小组件,或者能否仅从纯数据开始。 - MCP 服务器首选 TypeScript,小组件首选 React。 - 指明身份验证、部署和测试要求。输出: - 工具计划 - 拟定的文件树 - 黄金提示词集 - 风险和待解决问题
    使用 $chatgpt-apps 和 $openai-docs 规划此代码库中针对 [use case] 的 ChatGPT 应用。要求: - 从一个核心用户结果开始。 - 提出 3-5 个具有明确名称、描述、输入和输出的工具。 - 建议 v1 版本是否需要小组件,或者能否仅从纯数据开始。 - MCP 服务器首选 TypeScript,小组件首选 React。 - 指明身份验证、部署和测试要求。输出: - 工具计划 - 拟定的文件树 - 黄金提示词集 - 风险和待解决问题

    构建内容

    每个 ChatGPT 应用包含三个部分:

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

    当 Codex 负责处理围绕这些部分的重复性工程工作时,它能发挥最大的作用:

    • 规划工具接口和元数据。
    • 搭建服务器和小组件。
    • 连接本地运行脚本。
    • 在专注的开发阶段中添加身份验证和部署更改。
    • 编写验证循环,证明该应用能在 ChatGPT 中正常运行。

    为什么 Codex 是理想之选

    • ChatGPT 应用本身就能清晰地拆分为服务器、可选小组件以及模型驱动的工具调用。
    • 当任务明确、范围界定清晰且易于验证时,Codex 提示词的效果最佳,这与应用构建工作非常契合。
    • 技能和 AGENTS.md 为 Codex 提供了保持工作聚焦所需的可复用指令和项目规则。

    如需了解有关如何安装和使用技能的更多信息,请参阅我们的 技能文档.

    如何使用

    前提条件

    • 从一个核心用户结果开始,而不是试图将整个产品移植到聊天中。
    • 预先选择技术栈:服务器端选用 TypeScript 或 Python,小组件选用 React 或纯 HTML、CSS 和 JavaScript。
    • 确定你在开发期间将使用的 HTTPS 路径,例如 ngrok or Cloudflare Tunnel.
    • 当前文档通常说应用,但一些较旧的页面和设置仍然说连接器。在本地测试期间,将它们视为相同的设置对象。
    1. 从一个聚焦的应用结果开始,要求 Codex 提出 3 到 5 个具有明确名称、描述、输入和输出的工具。
    2. 确定 v1 版本是否可以保持纯数据,或者是否需要小组件,然后在添加依赖之前使用现有代码库模式搭建 MCP 服务器和可选小组件。
    3. 在 HTTPS 后面本地运行应用,在 ChatGPT 开发者模式中连接它,并使用一个小型的直接、间接和负面提示词集进行测试。
    4. 在元数据、状态处理、 structuredContent,且 _meta 载荷上进行迭代,直到核心读取流程在 ChatGPT 内表现稳定。
    5. 仅在需要用户特定数据或写入操作时才添加 OAuth 2.1,同时在可能的情况下保持匿名或只读流程的简单性。
    6. 准备一个具有稳定 /mcp 端点的托管预览,验证流式传输和小组件资产托管,并在分享或提交应用之前审查发布清单。

    建议提示词

    适用于此工作流的优秀提示词具有相同的要素:

    • 一个明确的结果:说明应用应帮助用户在 ChatGPT 中完成什么。
    • 一个具体的技术栈:说明你希望服务器端使用 TypeScript 还是 Python,以及小组件应使用 React 还是保持轻量级。
    • 明确的工具边界:要求 Codex 提出或构建一小部分职责单一的工具。
    • 身份验证预期:说明第一个版本可以是匿名的,还是需要关联账户和写入操作。
    • 本地开发路径:指出你期望用于 ChatGPT 中 HTTPS 测试的隧道或托管路径。
    • 验证步骤:告诉 Codex 要运行什么命令,要测试什么提示词,以及要报告什么反馈。

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

    在搭建应用之前先进行规划

    使用 $chatgpt-apps 和 $openai-docs 规划此代码库中针对 [use case] 的 ChatGPT 应用。要求: - 从一个核心用户结果开始。 - 提出 3-5 个具有明确名称、描述、输入和输出的工具。 - 建议 v1 版本是否需要小组件,或者能否仅从纯数据开始。 - MCP 服务器首选 TypeScript,小组件首选 React。 - 指明身份验证、部署和测试要求。输出: - 工具计划 - 拟定的文件树 - 黄金提示词集 - 风险和待解决问题

    搭建首个可用版本

    使用 $chatgpt-apps 和 $openai-docs 搭建此 ChatGPT 应用的首个版本。技术栈: - TypeScript MCP 服务器 - React 小组件 - Vite 构建 - 通过 ngrok 实现本地 HTTPS 约束: - 保持应用聚焦:一个读取流程,最多一个写入流程。 - 为模型返回简洁的 structuredContent,并将仅限小组件的数据保留在 _meta 中。 - 使工具处理程序具备幂等性。 - 在添加依赖之前复用现有代码库模式。验证: - 启动本地服务器 - 解释如何在 ChatGPT 开发者模式中连接应用 - 列出要测试的准确提示词

    在核心流程正常运行后再添加身份验证

    使用 $chatgpt-apps 和 $openai-docs 将身份验证添加到该 ChatGPT 应用。要求: - 尽可能保持只读工具匿名。 - 仅针对特定用户数据或写入操作添加 OAuth 2.1。 - 使用现有的身份提供商,例如 Auth0 或 Stytch。 - 记录范围、令牌检查和开发者模式测试流程。输出: - 身份验证流程摘要 - 服务器更改 - 所需环境变量 - 端到端测试计划

    准备应用以供部署和审查

    使用 $chatgpt-apps、$openai-docs 和 @vercel 准备此 ChatGPT 应用以进行托管预览。要求: - 暴露稳定的 HTTPS /mcp 端点。 - 保持 /mcp 上的流式响应正常工作。 - 正确托管小组件资产。 - 添加包含元数据、工具提示、隐私和测试提示的发布准备清单。输出: - 部署计划 - 预览 URL 或托管步骤 - 审查清单 - 残余风险

    发布就绪

    • 应用具有一个明确且对用户显而易见的单一目标。
    • 工具集保持精简,并具备明确的元数据、输入和输出。
    • MCP 服务器可端到端运行并返回简洁的 structuredContent,为仅微件数据预留 _meta.
    • 小组件(如果需要)能在 ChatGPT 中正确渲染。
    • 本地 HTTPS 测试循环可通过 ChatGPT 开发者模式运行。
    • 少量正向、间接和负向提示词集合能通过测试,并产生符合预期的对话流程和工具载荷。
    • 仅在涉及用户特定数据或写入操作时才添加身份验证。
    • 在共享或提交应用之前,部署计划和发布就绪审查需涵盖元数据、工具提示、隐私和测试提示词。

    常见陷阱

    • 要求 Codex 将整个产品移植到 ChatGPT。更好的做法:仅针对一个核心用户目标,开发三到五个工具和一个单一功能的小组件。
    • 从庞大的实现提示词开始。更好的做法:将工作拆分为规划、脚手架、身份验证、部署和审查阶段。
    • 在工具契约明确之前编写 UI。更好的做法:先规划工具接口和响应 schema,然后再构建小组件。
    • 跳过官方文档基础。更好的做法:结合 $chatgpt-apps with $openai-docs 使脚手架遵循当前的 Apps SDK 指南。
    • 将元数据视为事后补充。更好的做法:尽早编写工具描述和参数文档,然后使用提示词集对它们进行测试。
    • 在验证匿名或只读路径之前添加身份验证。更好的做法:先让核心工具流程跑通,然后再为实际需要它的工具添加 OAuth。
    • 在 ChatGPT 内部测试之前就宣布应用完成。更好的做法:在开发者模式下连接应用,检查工具载荷,并验证真实的对话流程。

    技术栈

    需求

    小组件框架

    默认选项

    React

    为何需要它

    适用于有状态小组件的强大默认选项,特别适合 UI 需要筛选器、表格或多步交互的场景。

    需求

    托管

    默认选项

    Vercel

    为何需要它

    快速部署、预览环境、自动 HTTPS,以及通向托管 MCP 端点的清晰路径。

    需求 默认选项 为何需要它
    小组件框架 React 适用于有状态小组件的强大默认选项,特别适合 UI 需要筛选器、表格或多步交互的场景。
    托管 Vercel 快速部署、预览环境、自动 HTTPS,以及通向托管 MCP 端点的清晰路径。

    相关用例