Codex 避免密钥泄露：做项目时不要把密钥写进代码

用 Codex 处理客户项目时，真正危险的往往不是它写错一行代码，而是你把不该进入上下文的内容交给了工具：API key、数据库连接串、Webhook secret、云服务 token、账号恢复码、生产环境日志、客户真实用户数据。这些内容一旦进入提示词、补丁、提交记录或截图，就可能变成后续很难清理的风险。

这篇是草稿，只做学习和流程参考，不构成法律意见或安全审计结论。适合配合 模板库、Proposal 生成器、报错解释器 使用：先把客户需求拆成可验证的小任务，再决定哪些材料可以给 Codex，哪些必须先脱敏或由客户自己操作。

适合谁

适合准备用 Codex 辅助处理客户代码、配置报错、部署说明和小型自动化脚本的新手。你不一定要独立负责复杂系统，但需要愿意保存操作记录、阅读 diff、跑验证命令，并在看到权限和密钥问题时主动停下来。

也适合正在建立 AI 工具实践 SOP 的人。你可以把本文当作开工前检查框架，先判断材料是否脱敏，再用工具辅助分析，而不是把客户项目原样塞进上下文。

不适合谁

不适合想直接接触客户生产密钥、后台账号、真实数据库、支付配置或隐私数据的人。只要任务要求你代替客户完成授权、登录或高权限变更，就不应该用“AI 可以帮我做”来跳过确认流程。

也不适合把 Codex 输出当成最终安全结论的人。密钥安全需要授权、记录、复核和必要时的轮换，不能只靠一次自动分析判断。

先分清什么算密钥

新手最容易漏掉的是“看起来不像密码”的敏感内容。除了明显的 API_KEY、SECRET、TOKEN，还要把数据库 URL、私有仓库地址、.env 文件、服务账号 JSON、OAuth client secret、邮件 SMTP 密码、对象存储签名、支付回调密钥、CI/CD 凭证都当成高风险材料处理。

还有一类是“组合后才危险”的信息：服务器 IP 加登录用户名、内部接口地址加请求样例、错误日志加用户邮箱、截图里露出的管理后台路径。这些不一定单独造成事故，但不应该被随手复制到 AI 对话、公开 issue、演示视频或交付文档里。

风险提醒：项目前的三条底线

第一，不要让客户把完整生产密钥发给你。你可以让客户提供脱敏后的错误信息、测试环境变量名、最小复现代码，或者让客户在自己的控制台中完成授权动作。需要登录、绑定、开通、付款、授权、重置密钥的事项，先记录为待确认项，不要替客户直接操作。

第二，不要把 .env、日志和配置文件整包交给 Codex。可以复制字段名、错误码、脱敏后的片段和必要的上下文。比如把 DATABASE_URL=postgres://真实内容 改成 DATABASE_URL=<redacted>，保留变量名和报错位置，删掉实际值。

第三，所有涉及生产环境、账号权限、真实用户数据、支付配置和安全漏洞的操作，都要暂停并人工确认。Codex 可以帮助整理检查清单和说明文档，但不能代替你判断是否有授权、是否符合平台规则、是否适合新手接。

具体步骤

1. 先保存客户原始需求，但不要把敏感附件直接导入工具。
2. 列出项目会接触的材料：仓库、报错、截图、配置、日志、后台权限、部署平台。
3. 用文本替换把真实密钥改成 <redacted>，只保留变量名、文件路径、报错行号和复现步骤。
4. 运行 git status，确认工作区状态，避免把客户已有改动混进你的交付。
5. 只让 Codex 读取和任务有关的文件，不把整个项目无限制丢给工具。
6. 修改后看 diff，重点检查 .env、配置、日志、测试数据和文档里有没有真实敏感内容。
7. 跑项目已有检查，例如 lint、build、测试、内容检查或页面 smoke test。
8. 交付时写清楚做了什么、如何验证、哪些权限动作仍需客户自己确认。

给 Codex 的提示词模板

请只分析下面脱敏后的报错和文件片段。
不要要求真实 API key、数据库密码、账号密码或生产环境 token。
如果需要密钥、登录或授权，请把它列为“需要客户确认的事项”，不要继续编造。
请输出：
1. 可能原因
2. 需要检查的文件
3. 可以本地验证的步骤
4. 不能在没有授权时执行的动作

这段提示词的重点不是“让 AI 更聪明”，而是给它一个边界：能解释、能拆解、能建议验证步骤，但遇到授权和真实密钥要停下来。

提交前必须检查什么

提交前至少做一次敏感词和文件类型扫描。可以先用仓库已有脚本；没有脚本时，最少手动搜索 key、secret、token、password、.env、private、credential。这不是完整安全扫描，只是最后一道粗筛。真正高风险项目仍应让有经验的人复核。

还要检查提交历史。新手常以为“删掉文件就没事”，但密钥可能已经进入 git 历史。如果发现真实密钥曾经提交过，正确做法通常是立即通知客户轮换密钥，并记录发生范围；是否清理历史、如何清理，要根据项目流程和客户要求处理。

什么时候应该拒绝或暂停

如果客户要求你直接使用生产账号、导出真实用户数据、处理支付密钥、关闭安全校验、读取无关私密信息，或者不给授权说明却要求你进入后台，就不要继续推进。可以礼貌回复：为了保护项目和账号安全，需要先确认权限范围、测试环境和验收方式。

项目不是比谁更敢点按钮，而是比谁能把边界讲清楚。密钥安全做得好，不会显得你“不专业”；相反，它会让客户知道你是在认真保护项目。

继续阅读

CTA：如果你想按步骤执行，可以看 Codex 密钥安全检查清单。如果已经出现泄露风险，先看 常见错误和修复顺序。项目前拿不准能不能做，可以用 项目边界判断 和 报价计算器 把风险写进范围说明里。

免责声明

本文只用于 AI 工具实践流程学习和草稿复核，不构成法律意见、安全审计、合规建议或对具体项目的承诺。真实客户项目应以客户授权、平台规则、项目合同和专业复核为准；需要注册、授权或高权限操作的事项，应先记录并由客户确认。