OpenAI API Key 获取教程：创建、充值与安全配置

1. 登录平台，选对组织和项目

打开 platform.openai.com，注册或登录账户，并按页面提示完成初始设置。OpenAI 快速入门指南提供了直达 API 密钥管理页的链接。

可以把账户理解为员工通行证，把**组织（organization）理解为公司，把项目（project）**理解为分配给某个应用的房间。密钥就是软件进入这个房间所需的凭证。

先在组织切换菜单中选定目标组织，再选择已有项目。如果你是组织所有者，也可以在项目菜单中点击 Create project（创建项目），填写信息后新建项目。用 website-test 这样的名称，更容易看出项目用途。具体操作见 OpenAI 项目管理指南。

如果是公司业务，请让所有者将你加入对应项目。不要因为浏览器里已经登录了个人账户，就把客户的集成接到个人账单下。

2. 创建项目的 OpenAI API Key

在组织设置中选定项目，打开 API Keys（API 密钥），点击 + Create new secret key（创建新密钥）。这样创建的密钥会关联到当前选中的项目。操作说明见项目密钥指南。

自己做首次测试时，使用归属于个人用户的项目密钥即可。如果页面要求命名，可以填入 local-test 这类容易辨认的名称。权限选择 Restricted（受限），只启用应用需要的操作。默认选项 **All（全部）**允许完整访问；**Read Only（只读）**则仅允许读取操作。详见 API 密钥权限说明。运行下文的测试时，需要允许创建 Responses，对应的权限名是 api.responses.write。详见 Responses 写入权限说明。

密钥生成后，立即复制并妥善保存。OpenAI 只在创建时显示完整密钥，之后无法再次查看原值；如果丢失，只能创建新密钥替换。详见 API 密钥查找与管理指南。

设置密钥有效期，并记录由谁负责更换。组织策略可能要求设置到期时间，也可能限制可创建的密钥类型。如果某个选项不可用，请向管理员确认策略。详见 OpenAI 生产环境指南。在测试转为持续运行的服务之前，先制定 API 密钥到期与轮换计划。

什么情况下更适合用服务账户？

对于已部署的应用或团队定时工作流，我会使用服务账户（service account）：它代表软件，而不是某位成员。组织或项目所有者可以在目标项目的 **Members → + Service account（成员 → 添加服务账户）**中创建，并立即保存生成的密钥。请为它使用独立项目，因为服务账户不能直接添加到 Default 项目。详见服务账户设置说明。

创建完成后，到项目的 API Keys 设置中检查访问权限。服务账户的创建窗口与个人用户密钥的创建窗口不同，不提供相同的权限设置选项。详见权限差异说明。这样做的实际好处是：即使团队成员变动，应用密钥的归属仍然清楚。

3. 配置 API 计费、充值和支出上限

**ChatGPT 计费与 API 计费是分开的。**购买 ChatGPT 订阅，并不等于已经配置了 API 付款。打开目标组织的 API 计费概览，由组织所有者管理计费。详见 OpenAI 计费说明。

新的 API 账户采用预付费计费。进行 OpenAI API 充值时，先点击 Add payment details（添加付款信息），完成付款设置，选择首次购买的额度并确认。结账前要检查 Use auto-reload（启用自动充值）：OpenAI 表示，这个选项默认开启。如果只是做一次手动充值测试，可以关闭它；如果需要自动充值，就明确设置触发阈值和每月自动充值上限。购买的额度可能需要几分钟才会到账。详见预付费设置说明。

模型的当前费率以 OpenAI 价格页为准；估算应用预算时，可以结合本站的 OpenAI API 定价指南阅读。

要在超限时停止请求，必须开启强制限制

进入 Project settings → Limits → Spend → Edit spend limit（项目设置 → 限制 → 支出 → 编辑支出上限），填写 Monthly spend limit（每月支出上限），开启 Enforce a hard limit（强制执行硬性上限），然后保存。操作需要管理该项目设置的权限。再设置一个低于上限的支出提醒，给负责人留出处理时间，避免等到服务停止才发现。详见支出上限设置说明。

硬性上限的执行存在延迟，因此最终记录的支出可能略高于设置金额。组织级硬性上限计算的是该组织下所有项目的合计支出。预付费账户也可能因停止服务的延迟而超出余额；手动购买额度则不受自动充值上限约束。详见硬性上限的执行机制和预付费计费机制。

正式上线前，请阅读 OpenAI API 硬性支出上限指南，并确定服务因超限中断时，谁有权提高上限。

4. 安全保存密钥，让应用按需读取

将密钥保存在专门存储凭证的密钥管理系统中，或通过名为 OPENAI_API_KEY 的环境变量传给服务器。环境变量是一项有名称的设置，运行中的程序可以读取它，无须把密钥直接写进源代码。详见生产环境密钥存储指南。

不要把常规 API 密钥放进网页 JavaScript、移动应用、代码仓库、截图或客服消息中。浏览器和移动端代码会到达用户设备；密钥应由服务器保存，请求也应由服务器发起。给团队成员分配各自的访问权限，不要共用某个人的密钥。详见 API 密钥安全指南。

**如果某个工具要求粘贴密钥：**先确认你愿意让该厂商接收这项凭证，再使用其文档指定的凭证输入框。我的建议是为这项集成单独建项目，使用受限密钥，设置支出上限，并指定负责人。普通文本框、聊天消息或来路不明的“密钥检测器”，都不适合用来排查连接问题。向厂商确认它需要哪些权限，以及密钥会保存在哪里。

5. 用一次 curl 请求验证配置

在电脑上的 Bash 中运行以下命令。curl 是用来发送网络请求的命令行工具。前几行会提示输入密钥，但不会回显，也不会把密钥原值写进你输入的命令；设置的环境变量只在当前 shell 会话中有效。

read -r -s -p "OpenAI API key: " OPENAI_API_KEY
printf '\n'
export OPENAI_API_KEY

curl https://api.openai.com/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-6-astra",
    "input": "Reply with a short greeting."
  }'

这里使用了 OpenAI 文本生成示例中的请求结构和模型。Responses API 是接收输入并返回模型输出的接口。授权请求头携带密钥，JSON 请求体指定模型和指令。这次调用会产生 API 用量，因此计费和模型访问权限都必须提前配置好。

成功响应中会有一个 output 数组，其中的消息包含 output_text 内容。到这里查找问候语，不要假定文本一定在数组的第一项。如果返回的是 error 对象，就根据其中的消息和错误码，按下文排查。详见响应结构说明。

测试结束、不再需要密钥时，运行 unset OPENAI_API_KEY，清除当前 shell 中的变量。部署应用时，应在托管环境中配置密钥，而不是每次重新打开终端输入。

API 密钥不能用？先检查这些问题

不要一报错就重新创建密钥。先看错误信息，很多故障与密钥本身无关。

429 响应既可能是速率限制，也可能与支出上限或余额有关。反复重试不会增加额度，也不会改变已经设置的上限。详见 OpenAI 错误码说明和密钥权限说明。

API 密钥泄露后，立即撤销

如果密钥出现在公开代码仓库、截图或消息中，就应按已经泄露处理。删掉眼前这份内容，并不能让别人已经拿到的副本失效。

1. **撤销泄露的密钥。**在正确的项目中打开 API 密钥页面，删除该密钥。依赖它的应用可能会停止工作，直到你完成替换。详见密钥删除说明。
2. **创建新密钥，更新受影响的应用。**先测试新密钥，再确认已部署的进程确实在使用它。
3. **检查用量和账单。**排查异常请求；如果怀疑密钥遭到滥用，联系 OpenAI Support。OpenAI 建议，只要怀疑泄露，就立即轮换密钥。详见泄露处置指南。
4. **修复泄露源头。**从代码和日志中移除密钥，纠正导致泄露的存储或分享方式。如果账户本身也可能被入侵，请修改密码、退出其他会话，并报告未经授权的活动。详见账户恢复步骤。

这套配置适合哪五个场景？

这套配置的价值，是让每项集成都有明确的负责人和预算。下面按见效快慢，列出团队可以直接采用的场景。

密钥能用，只能证明请求可以执行。它不能证明提示词足够可靠、厂商能妥善处理凭证，也不能证明某个自动化流程应该获得客户数据的访问权限。这些仍然需要从产品和运营角度单独判断。

围绕接入流程，可以做哪两类功能？

**最值得考虑的方向，是为需要客户提供 OpenAI 密钥的软件内置连接向导。**DataForSEO 估算，“how to get openai api key”在美国的月搜索量为 1,000。这个数据反映了接入过程中的阻力，并不代表能获得多少付费客户。工具厂商可以购买或自行开发一套引导式项目检查清单、安全的凭证输入框、明确的测试按钮，以及容易看懂的结果反馈。最小版本应直接放进需要连接的产品里。难点在于厂商也能自己做，因此价值必须体现在减少客服负担和持续更新操作说明上。

**错误解释器适合作为客服辅助功能，但独立需求较弱。**同一次查询中，“openai api key not working”在美国的月搜索量估算仅为 10。自动化工具厂商或实施服务商可以提供一个表单，接收已脱敏的错误码和消息，再解释用户应当处理凭证、余额、权限，还是请求频率。初版需要的是一张持续维护的判断表，无须接收或保存用户的密钥。难点是测得的搜索量较小，而且不少工具本来就会展示这些错误。我会把它放进新用户接入流程，而不是单独做成付费产品。

这些数字来自为本指南查询的 DataForSEO 关键词概览，范围是美国的英语搜索。它们衡量的是搜索次数，不是独立用户数，也不是购买意愿。

**下周一就做这件事：**选定一项集成，指定负责人，创建项目，设置支出控制，并保存一份已去除密钥的成功测试结果。这些信息，才是给下一位维护者的实用交接材料。

如果需要帮助将这项集成投入生产，可以查看 AI 生产系统服务，了解相关的运行与维护工作。