API Key 是调用模型接口的凭证不是普通登录密码也不应该出现在截图、文章、仓库或聊天记录里。本文从个人使用和团队协作两个角度整理一份 Key 保存、权限拆分、环境变量配置和泄露处理清单。适合人群准备长期使用模型 API并担心 Key 泄露、权限混乱和账单不可追踪的个人或团队。本文只整理通用配置、接入和排查方法不展示真实密钥不做具体平台引导。配置时请以自己后台显示的信息为准。阅读前建议先明确目标你是要在本地工具里跑通一次还是要给团队搭一套长期稳定的调用流程。前者关注能否返回结果后者还要关注权限、日志、限流、成本和维护方式。下面按照真实操作顺序展开先确认入口和环境再检查凭证和模型最后用日志和状态码定位问题。这样新手照着做不容易跳步骤老手也能快速找到关键字段。为了让操作更容易复现正文会尽量把每个概念落到具体字段哪里填 Key哪里填 Base URL模型名从哪里复制失败时先看哪个状态码。读者照着做时可以把这篇文章当作一份检查表而不是单纯的概念介绍。先区分个人 Key 和团队 Key这一节围绕「API Key 安全保存」中的「先区分个人 Key 和团队 Key」展开。公开教程里不要展示真实 API Key、真实账号、余额、订单号或完整后台地址截图里出现敏感信息要统一打码。建议把每一步都当成可以验证的小任务而不是一整套配置一起复制。先跑通一个最小请求再扩大到真实项目这样更容易定位问题。如果这一步涉及多个工具建议只选一个最常用的工具先验证。等最小链路跑通后再迁移到第二个工具或第二个项目避免多个变量同时变化。个人 Key 不要共享围绕「个人 Key 不要共享」操作时重点是让配置链路可验证。先确认页面或工具里的现象再定位到具体字段最后用最小请求验证结果。实际执行时不要同时改 Key、Base URL、模型名和网络代理否则失败后很难判断是哪一项引起的。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。新手配置时不要一次改太多变量。先跑通最小请求再迁移到真实项目这样出错时更容易定位。团队 Key 要按项目拆分在「先区分个人 Key 和团队 Key」这个阶段不建议凭感觉反复试错。把工具名、模型名、接口地址、Key 分组和报错原文写到同一张表里排查会快很多。如果失败先回到上一个已经成功的状态再只改一个变量重新验证不要一路向后堆配置。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。如果编辑器支持预览发布前要确认图片没有堆到末尾代码块没有变普通段落标题层级没有丢失。完成「先区分个人 Key 和团队 Key」后做一次小范围复核标题里的问题是否在当前段落得到解释截图是否放在对应步骤附近代码块是否只保留必要字段参考链接是否只是补充资料。密钥页适合核对每个 Key 的权限和状态Key 不要写进公开内容这一节围绕「API Key 安全保存」中的「Key 不要写进公开内容」展开。新手配置时不要一次改太多变量。先跑通最小请求再迁移到真实项目这样出错时更容易定位。建议把每一步都当成可以验证的小任务而不是一整套配置一起复制。先跑通一个最小请求再扩大到真实项目这样更容易定位问题。如果这一步涉及多个工具建议只选一个最常用的工具先验证。等最小链路跑通后再迁移到第二个工具或第二个项目避免多个变量同时变化。截图统一打码在「Key 不要写进公开内容」这个阶段不建议凭感觉反复试错。把工具名、模型名、接口地址、Key 分组和报错原文写到同一张表里排查会快很多。公开写教程或发文章时截图只保留入口和字段名称真实敏感值统一打码避免后续泄露风险。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。如果编辑器支持预览发布前要确认图片没有堆到末尾代码块没有变普通段落标题层级没有丢失。仓库提交前检查如果这一步要交给团队执行最好附上一个最小验证命令和预期结果。别人接入时不需要理解全部背景也能判断自己是否配置成功。完成后把命令、截图和结果保存下来后续换机器、换项目或排查问题时会省很多时间。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。长期使用不能只看第一次是否成功还要看日志是否完整、权限是否可控、成本是否能复盘。完成「Key 不要写进公开内容」后做一次小范围复核标题里的问题是否在当前段落得到解释截图是否放在对应步骤附近代码块是否只保留必要字段参考链接是否只是补充资料。export OPENAI_API_KEYsk-xxxxxxxx环境变量优先于硬编码这一节围绕「API Key 安全保存」中的「环境变量优先于硬编码」展开。如果编辑器支持预览发布前要确认图片没有堆到末尾代码块没有变普通段落标题层级没有丢失。建议把每一步都当成可以验证的小任务而不是一整套配置一起复制。先跑通一个最小请求再扩大到真实项目这样更容易定位问题。如果这一步涉及多个工具建议只选一个最常用的工具先验证。等最小链路跑通后再迁移到第二个工具或第二个项目避免多个变量同时变化。终端临时变量如果这一步要交给团队执行最好附上一个最小验证命令和预期结果。别人接入时不需要理解全部背景也能判断自己是否配置成功。实际执行时不要同时改 Key、Base URL、模型名和网络代理否则失败后很难判断是哪一项引起的。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。长期使用不能只看第一次是否成功还要看日志是否完整、权限是否可控、成本是否能复盘。用户级长期变量长期使用时不只要看能不能跑通还要看日志、权限、限流、重试和成本是否能被复盘。临时成功不代表适合正式任务。如果失败先回到上一个已经成功的状态再只改一个变量重新验证不要一路向后堆配置。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。团队使用时建议把测试、生产、个人、项目拆开管理避免一个 Key 承担所有任务。完成「环境变量优先于硬编码」后做一次小范围复核标题里的问题是否在当前段落得到解释截图是否放在对应步骤附近代码块是否只保留必要字段参考链接是否只是补充资料。控制台概览适合观察整体账号状态$env:OPENAI_API_KEYsk-xxxxxxxx权限按最小范围开放这一节围绕「API Key 安全保存」中的「权限按最小范围开放」展开。长期使用不能只看第一次是否成功还要看日志是否完整、权限是否可控、成本是否能复盘。建议把每一步都当成可以验证的小任务而不是一整套配置一起复制。先跑通一个最小请求再扩大到真实项目这样更容易定位问题。如果这一步涉及多个工具建议只选一个最常用的工具先验证。等最小链路跑通后再迁移到第二个工具或第二个项目避免多个变量同时变化。只给必要模型长期使用时不只要看能不能跑通还要看日志、权限、限流、重试和成本是否能被复盘。临时成功不代表适合正式任务。公开写教程或发文章时截图只保留入口和字段名称真实敏感值统一打码避免后续泄露风险。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。团队使用时建议把测试、生产、个人、项目拆开管理避免一个 Key 承担所有任务。只给必要额度围绕「只给必要额度」操作时重点是让配置链路可验证。先确认页面或工具里的现象再定位到具体字段最后用最小请求验证结果。完成后把命令、截图和结果保存下来后续换机器、换项目或排查问题时会省很多时间。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。公开教程里不要展示真实 API Key、真实账号、余额、订单号或完整后台地址截图里出现敏感信息要统一打码。完成「权限按最小范围开放」后做一次小范围复核标题里的问题是否在当前段落得到解释截图是否放在对应步骤附近代码块是否只保留必要字段参考链接是否只是补充资料。.env *.local日志和账单要能追踪这一节围绕「API Key 安全保存」中的「日志和账单要能追踪」展开。团队使用时建议把测试、生产、个人、项目拆开管理避免一个 Key 承担所有任务。建议把每一步都当成可以验证的小任务而不是一整套配置一起复制。先跑通一个最小请求再扩大到真实项目这样更容易定位问题。如果这一步涉及多个工具建议只选一个最常用的工具先验证。等最小链路跑通后再迁移到第二个工具或第二个项目避免多个变量同时变化。按 Key 看消耗围绕「按 Key 看消耗」操作时重点是让配置链路可验证。先确认页面或工具里的现象再定位到具体字段最后用最小请求验证结果。实际执行时不要同时改 Key、Base URL、模型名和网络代理否则失败后很难判断是哪一项引起的。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。公开教程里不要展示真实 API Key、真实账号、余额、订单号或完整后台地址截图里出现敏感信息要统一打码。按项目做复盘在「日志和账单要能追踪」这个阶段不建议凭感觉反复试错。把工具名、模型名、接口地址、Key 分组和报错原文写到同一张表里排查会快很多。如果失败先回到上一个已经成功的状态再只改一个变量重新验证不要一路向后堆配置。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。新手配置时不要一次改太多变量。先跑通最小请求再迁移到真实项目这样出错时更容易定位。完成「日志和账单要能追踪」后做一次小范围复核标题里的问题是否在当前段落得到解释截图是否放在对应步骤附近代码块是否只保留必要字段参考链接是否只是补充资料。调用记录适合追踪异常消耗和失败请求公开文章、截图、群聊和代码仓库里都不要出现真实 Key。发现泄露后的处理这一节围绕「API Key 安全保存」中的「发现泄露后的处理」展开。公开教程里不要展示真实 API Key、真实账号、余额、订单号或完整后台地址截图里出现敏感信息要统一打码。建议把每一步都当成可以验证的小任务而不是一整套配置一起复制。先跑通一个最小请求再扩大到真实项目这样更容易定位问题。如果这一步涉及多个工具建议只选一个最常用的工具先验证。等最小链路跑通后再迁移到第二个工具或第二个项目避免多个变量同时变化。立即禁用旧 Key在「发现泄露后的处理」这个阶段不建议凭感觉反复试错。把工具名、模型名、接口地址、Key 分组和报错原文写到同一张表里排查会快很多。公开写教程或发文章时截图只保留入口和字段名称真实敏感值统一打码避免后续泄露风险。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。新手配置时不要一次改太多变量。先跑通最小请求再迁移到真实项目这样出错时更容易定位。重建并替换配置如果这一步要交给团队执行最好附上一个最小验证命令和预期结果。别人接入时不需要理解全部背景也能判断自己是否配置成功。完成后把命令、截图和结果保存下来后续换机器、换项目或排查问题时会省很多时间。这部分属于「API Key 安全保存」的基础环节做扎实之后后面的 SDK、自动化和团队协作才不会反复踩同一个坑。如果编辑器支持预览发布前要确认图片没有堆到末尾代码块没有变普通段落标题层级没有丢失。完成「发现泄露后的处理」后做一次小范围复核标题里的问题是否在当前段落得到解释截图是否放在对应步骤附近代码块是否只保留必要字段参考链接是否只是补充资料。发布前自检清单图片是否在正文对应位置正文图片应该跟随对应步骤出现不能全部堆到文章末尾。发布前打开预览确认 3 张图都能正常显示没有 404、空白或重复错位。标题和正文是否匹配标题写下载教程正文就要出现安装、配置和首次验证标题写排查清单正文就要围绕错误码、日志和权限展开。不要只为了标题吸引点击而牺牲正文兑现。代码块是否简短可读代码块只展示必要字段关系真实 Key、真实接口、真实账号信息都不要放进公开文章。公开教程用 sk-xxxxxxxx 这类占位值即可。参考链接是否只作为补充参考链接放在文末即可不要在正文里反复插入链接也不要把文章写成跳转引导。读者应该先从正文里读懂步骤再按需查看补充资料。教程文档参考https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg