Need
微件框架
Default options
Why it's needed
有状态微件的稳妥默认选择，尤其适合 UI 需要筛选器、表格或多步骤交互的情况。
Codex use case
将您的应用带入 ChatGPT
将您的使用场景转化为目标明确的 ChatGPT 应用。
Difficulty 高级
Time horizon 1 小时
围绕一个具体目标端到端构建 ChatGPT 应用：定义工具，为 MCP 服务器和可选微件搭建脚手架，在 ChatGPT 中连接该应用，并持续迭代，直至核心流程正常运行。
最适合
- 围绕用户目标规划首个 ChatGPT 应用
- 在避免过度构建的前提下，为 MCP 服务器、工具元数据和可选微件搭建脚手架
- 在本地 HTTPS 测试与 ChatGPT 开发者模式验证之间快速迭代
Contents
将您的应用带入 ChatGPT
将您的使用场景转化为目标明确的 ChatGPT 应用。
围绕一个具体目标端到端构建 ChatGPT 应用：定义工具，为 MCP 服务器和可选微件搭建脚手架，在 ChatGPT 中连接该应用，并持续迭代，直至核心流程正常运行。
高级
1 小时
围绕一个具体目标端到端构建 ChatGPT 应用：定义工具，为 MCP 服务器和可选微件搭建脚手架，在 ChatGPT 中连接该应用，并持续迭代，直至核心流程正常运行。
高级
1 小时
相关链接
最适合
- 围绕用户目标规划首个 ChatGPT 应用
- 在避免过度构建的前提下，为 MCP 服务器、工具元数据和可选微件搭建脚手架
- 在本地 HTTPS 测试与 ChatGPT 开发者模式验证之间快速迭代
技能与插件
- 规划工具、接入 MCP 资源，并遵循当前的 ChatGPT 应用构建流程。
- 在 Codex 编写代码或提出架构建议之前，先获取 Apps SDK 的最新官方指南。
- 通过精选技能和官方 Vercel MCP 服务器，将 Vercel 生态系统指南引入 Codex。
| Skill | Why use it |
|---|---|
| ChatGPT Apps | 规划工具、接入 MCP 资源，并遵循当前的 ChatGPT 应用构建流程。 |
| OpenAI Docs | 在 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。
- 明确说明身份验证、部署和测试要求。
输出：
- 工具规划
- 建议的文件树
- 黄金提示词集
- 风险和待解决问题
您将构建什么
每个基于 MCP 的插件都由三部分组成：
- 一个 MCP 服务器，负责定义工具、返回数据、实施身份验证，并向 ChatGPT 指明所需 UI 资源的位置。
- 一个可选的 Web 组件，可在 ChatGPT iframe 内呈现。您可以使用 React 构建它，也可以使用纯 HTML、CSS 和 JavaScript。
- 一个模型，根据您提供的元数据决定何时调用插件工具。
Codex 最适合负责与这些部分相关的重复性工程工作：
- 规划工具接口及其元数据。
- 搭建服务器和微件的脚手架。
- 配置本地运行脚本。
- 分轮次、有针对性地添加身份验证和部署变更。
- 编写验证循环，证明插件可在 ChatGPT 中正常运行。
为何 Codex 非常适合这项工作
- 基于 MCP 的插件可清晰拆分为服务器、可选 UI 和由模型驱动的 工具调用。
- 当任务明确、范围清晰且 易于验证时，Codex 的提示效果最佳，这与插件构建工作非常契合。
- 技能和
AGENTS.md为 Codex 提供所需的可复用指令与项目规则，使其始终以项目实际情况为依据。
要进一步了解如何安装和使用技能，请参阅我们的 技能文档。
使用方法
前提条件
- 从一个核心用户目标入手，而不是试图把整个产品移植到聊天中。
- 预先选定技术栈：服务器使用 TypeScript 或 Python，微件使用 React，或使用纯 HTML、CSS 和 JavaScript。
- 确定开发期间使用的 HTTPS 路径，例如
ngrok或 Cloudflare Tunnel。 - 部分设置仍使用较旧的术语来指代 MCP 服务器连接。在 本地测试期间，请将这些标签视为指代已注册的服务器。
- 先确定插件要实现的一个具体目标，并让 Codex 提出 3 至 5 个工具，为每个工具提供清晰的名称、说明、输入和输出。
- 确定 v1 是否可以只返回数据，还是需要微件；然后在添加依赖项之前，依照代码仓库的现有模式搭建 MCP 服务器和可选微件的脚手架。
- 通过 HTTPS 在本地运行 MCP 服务器，在 ChatGPT 开发者模式中连接它，并用一小组直接、间接和负向提示词对其进行测试。
- 持续改进元数据和状态处理方式，以及
structuredContent和_meta载荷，直到核心读取流程能在 ChatGPT 中可靠运行。 - 仅在特定于用户的数据或写入操作确有需要时，才添加 OAuth 2.1，同时不要因此增加匿名或只读流程的复杂性。
- 准备一个带有稳定
/mcp端点的托管预览版本，验证流式传输和 UI 资产托管，并在分享或提交插件之前审查发布检查清单。
建议的提示词
适合此工作流的优质提示词都具备以下要素：
- 一个明确的目标：说明插件应帮助用户在 ChatGPT 中完成什么。
- 具体的技术栈：说明服务器应使用 TypeScript 还是 Python，以及微件应使用 React 还是保持轻量。
- 明确的工具边界：让 Codex 提出或构建一小组工具，每个工具只负责一项工作。
- 身份验证要求：说明首个版本能否采用匿名模式，还是需要关联账户和写入操作。
- 本地开发路径：说明您希望通过哪种隧道或托管路径在 ChatGPT 中进行 HTTPS 测试。
- 验证步骤：告诉 Codex 要运行哪些命令、测试哪些提示词，以及要反馈哪些证据。
不要使用一个庞大的提示词，要求一次性完成规划、实现、身份验证、部署、提交和完善。应改为将工作拆分成较小的里程碑。
先规划插件，再搭建脚手架
在此代码仓库中，使用 $chatgpt-apps 和 $openai-docs 为 [use case] 规划一个基于 MCP 的插件。
要求：
- 从一个核心用户目标入手。
- 提出 3-5 个工具，名称、说明、输入和输出均应清晰。
- 建议 v1 是否需要微件，还是可以先仅返回数据。
- MCP 服务器优先使用 TypeScript，微件优先使用 React。
- 明确说明身份验证、部署和测试要求。
输出：
- 工具规划
- 建议的文件树
- 黄金提示词集
- 风险和待解决问题
搭建首个可运行版本
使用 $chatgpt-apps 和 $openai-docs，为这个基于 MCP 的插件搭建首个版本。
技术栈：
- TypeScript MCP 服务器
- React 小组件
- Vite 构建
- 使用 ngrok 实现本地 HTTPS
约束：
- 保持插件功能精简：仅包含一个读取流程和最多一个写入流程。
- 为模型返回简洁的 structuredContent，并将仅供小组件使用的数据保留在 _meta 中。
- 确保工具处理程序具有幂等性。
- 添加依赖项前，优先复用代码仓库中的现有模式。
验证：
- 启动本地服务器
- 说明如何在 ChatGPT 开发者模式下连接 MCP 服务器
- 列出用于测试的确切提示词
仅在核心流程正常运行后添加身份验证
使用 $chatgpt-apps 和 $openai-docs，为这个插件的 MCP 服务器添加身份验证。
要求：
- 尽可能让只读工具支持匿名访问。
- 仅在需要访问用户专属数据或执行写入操作时添加 OAuth 2.1。
- 使用 Auth0 或 Stytch 等现有身份提供商。
- 为权限范围、Token 检查和开发者模式测试流程编写文档。
输出：
- 身份验证流程摘要
- 服务器更改
- 所需环境变量
- 端到端测试计划
为插件的部署和审查做好准备
结合使用 $chatgpt-apps、$openai-docs 和 @vercel，为此插件做好托管预览准备。
要求：
- 提供一个稳定的 HTTPS /mcp 端点。
- 确保 /mcp 上的流式响应继续正常工作。
- 正确托管小组件资源。
- 添加一份发布准备检查清单，涵盖元数据、工具提示、隐私和测试提示词。
输出：
- 部署计划
- 预览 URL 或托管步骤
- 审查清单
- 剩余风险
发布准备情况
- 插件只帮助用户完成一项易于理解的具体任务。
- 工具集保持精简，且元数据、输入和输出均有明确定义。
- MCP 服务器可端到端正常运行并返回简洁的
structuredContent，仅供小组件使用的数据则保留在_meta中。 - 如有需要，小组件可在 ChatGPT 中正确呈现。
- 本地 HTTPS 测试闭环可通过 ChatGPT 开发者模式正常运行。
- 一小组直接、间接和负例提示词通过测试，且对话流程和工具有效载荷均符合预期。
- 仅在用户专属数据或写入操作确实需要时才添加身份验证。
- 在分享或提交插件之前，部署计划和发布准备审查涵盖元数据、工具提示、隐私和测试提示词。
常见误区
- 要求 Codex 将整个产品移植到 ChatGPT 中。更好的做法：让 Codex 围绕用户的一项核心任务，构建三到五个工具和一个用途单一的小组件。
- 一开始就给出一个大而全的实现提示词。更好的做法：将工作拆分为规划、搭建脚手架、身份验证、部署和审查几个阶段。
- 在工具契约尚未明确时就编写 UI。更好的做法：先规划工具接口和响应模式，再构建小组件。
- 没有以官方文档为依据。更好的做法：将
$chatgpt-apps与$openai-docs配合使用，确保脚手架符合当前的插件指南。 - 把元数据留到最后才考虑。更好的做法：尽早编写工具说明和参数文档，再基于这些内容重新执行一组提示词测试。
- 在验证匿名或只读路径可行之前就添加身份验证。更好的做法：先让核心工具流程正常运行，再只为确有需要的工具添加 OAuth。
- 尚未在 ChatGPT 中测试就宣布插件已经完成。更好的做法：在开发者模式下连接 MCP 服务器，检查工具有效载荷，并验证实际 对话流程。
Tech stack
Need
Default options
Why it's needed
Need
托管
Default options
Why it's needed
支持快速部署、预览环境和自动 HTTPS，并提供清晰的 MCP 端点托管路径。
