封面图：Codex 使用技巧详细教程（网站特色图可单独上传）
Codex 使用技巧详细教程（从基础到高级）
面向网站发布的图文教程：安装入口、提示词模板、代码审查、权限安全、CLI 配置、AGENTS.md 与自动化工作流
建议分类：保姆级教程 / AI 使用技巧教程 / AI 编程与开发工具
更新日期：2026-05-17｜适合人群：开发者、独立站站长、自动化脚本用户、AI 编程新手
文章导读
很多人第一次接触 Codex 时，会把它理解成“更会写代码的 ChatGPT”。这个理解不算错，但不够准确。当前的 Codex 更像一个可以读项目、改文件、运行命令、解释 diff、辅助审查和沉淀团队规则的 AI 编程智能体。它的核心价值不是替你随手生成几行代码，而是把一个工程任务拆成计划、修改、验证、审查和交付几个可控环节。
本文按“基础到高级”的路线来写：先说明 Codex 是什么、有哪些入口；再讲安装与第一次使用；随后给出高成功率提示词模板；最后进入项目规则、权限安全、CLI 配置、代码审查、自动化和常见问题排查。读完后，你可以把 Codex 用在真实项目中，而不是只停留在演示级别。
建议阅读方式：
- 只想快速上手：重点看第 3～5 节。
- 想提升生成质量：重点看第 6～7 节。
- 要用于真实项目或团队：重点看第 8～10 节。
- 担心安全与费用：重点看第 11～12 节。
图 1：Codex 完成一次工程任务的标准闭环
一、Codex 是什么
Codex 是 OpenAI 面向软件工程场景推出的编码智能体。它可以读取代码库、理解项目结构、编辑文件、运行命令、解释报错、生成测试、提出代码审查建议，并帮助你完成从需求到合并的开发流程。和传统代码补全工具相比，Codex 更强调“任务完成”和“工程闭环”。
你可以把 Codex 理解为四类能力的组合：
- 代码理解：快速解释陌生项目、模块调用关系、报错原因和业务流程。
- 代码修改：按你的目标修改文件、生成新功能、修复 Bug 或完成重构。
- 命令执行：在权限允许范围内运行测试、构建、lint、格式化和脚本。
- 审查交付：输出 diff 说明、测试结果、风险点和下一步建议。
| 重要概念 本文中的 Codex 指 OpenAI 当前的编码智能体产品与工具链，包括 Codex App、Codex CLI、Codex IDE 扩展和 Codex Web/Cloud 等体验，不是早期单纯的代码生成模型概念。 |
Codex 与普通聊天式 AI 编程的区别
| 对比项 | 普通聊天式 AI 写代码 | Codex 工作方式 |
| 上下文 | 通常依赖你复制粘贴代码片段 | 可以直接读取项目目录、相关文件和运行结果 |
| 修改方式 | 给出代码片段，需要你手动复制 | 可在项目中直接编辑文件并生成 diff |
| 验证方式 | 多数情况下只提供理论建议 | 可以运行测试、构建和命令，基于真实反馈迭代 |
| 任务粒度 | 适合单点代码生成或解释 | 适合 Bug 修复、功能开发、重构、审查和迁移 |
| 风险控制 | 主要靠人工判断 | 可结合沙箱、审批模式、受保护路径和人工 diff 审查 |
二、Codex 的主要使用入口
你可以根据工作习惯选择不同入口。新手建议先从 Codex App 或 IDE 扩展开始；喜欢终端和自动化的人可以使用 CLI；希望把任务交给云端并行处理时，可以尝试 Codex Web/Cloud。
| 入口 | 适合场景 | 特点 | 推荐人群 |
| Codex App | 管理多个项目、多个线程、审查 diff、跨任务切换 | 桌面端集中工作台，适合长任务和并行任务 | 独立开发者、团队负责人、产品型开发者 |
| Codex CLI | 终端内读代码、改文件、运行测试、脚本化自动任务 | 最适合工程化、自动化和高级配置 | 后端、运维、脚本用户、AI 工程化用户 |
| Codex IDE 扩展 | 在 VS Code、Cursor、Windsurf、JetBrains 等编辑器中边写边改 | 结合打开文件、选中代码、编辑器上下文使用 | 前端、全栈、日常写代码用户 |
| Codex Web/Cloud | 把任务委托给云端环境、后台并行处理、连接 GitHub 仓库 | 适合长任务、PR、代码库问答和远程工作 | 团队协作、需要多任务并行的用户 |
| 移动端远程连接 | 离开电脑后继续查看线程、审批操作、调整方向 | 通过 ChatGPT 移动端连接运行 Codex 的主机 | 经常移动办公的开发者 |
三、使用前准备：不要直接在主分支上试错
Codex 能力越强，越需要你给它一个安全、可回滚、可验证的工作环境。第一次使用前，建议先完成以下准备。
准备清单
- 确认已经安装 Git，并且项目处于版本管理中。
- 在新分支中操作，例如：feature/codex-test 或 fix/codex-login-bug。
- 准备项目启动、测试、构建命令，例如 npm test、pnpm build、pytest、go test ./…。
- 不要把 .env、密钥、数据库密码、生产凭据暴露给不必要的任务。
- 先让 Codex 只读分析项目，再决定是否允许写入和运行命令。
# 建议的安全起步流程
git status
git checkout -b feature/codex-first-task
# 先让 Codex 解释项目结构，不要马上让它大改
codex
推荐的项目目录约定
| 文件 / 目录 | 用途 | 建议 |
| README.md | 项目基本说明 | 写清启动、测试、构建、部署方式 |
| AGENTS.md | 给 Codex 的项目规则 | 写清代码风格、禁止事项、测试要求和提交规范 |
| .codex/config.toml | 项目级 Codex 配置 | 只在可信项目中使用，避免把危险配置提交到公共仓库 |
| tests / __tests__ | 测试目录 | 让 Codex 修改后必须运行相关测试 |
| .env.example | 环境变量示例 | 提供变量名与说明，不放真实密钥 |
四、基础入门：第一次让 Codex 完成任务
初学者最常犯的错误，是一上来就输入“帮我优化这个项目”“帮我修复所有问题”。这类要求太大、边界太模糊，Codex 可能会改太多文件，最终你很难审查。更好的做法是：先让 Codex 读项目，再让它制定计划，最后限定一个小任务执行。
第一步：让 Codex 了解项目
请先只读分析这个项目，不要修改文件。
请输出：
1. 项目技术栈
2. 主要目录结构
3. 启动命令和测试命令
4. 你认为最重要的 5 个文件
5. 后续修改时需要注意的风险点
第二步：给出明确的小任务
任务：修复登录页在密码为空时没有提示的问题。
上下文：项目是 React + TypeScript，登录页文件可能在 src/pages/Login.tsx。
要求：
– 只修改登录表单相关代码。
– 保持现有 UI 风格不变。
– 如果项目已有表单校验工具，优先复用。
– 修改后运行相关测试或至少运行类型检查。
输出：
– 修改了哪些文件
– 为什么这样改
– 如何验证
第三步：让它先计划再执行
如果你担心 Codex 一次性改太多，可以先明确要求：“先给计划，不要动文件；我确认后再执行”。这一步非常适合陌生项目、生产项目或涉及支付、登录、权限、数据库迁移的功能。
先不要修改文件。请先阅读相关代码，并给出修复计划：
– 可能涉及哪些文件
– 每个文件准备怎么改
– 有哪些风险
– 需要运行哪些测试
等我确认“开始修改”后再执行。
五、基础技巧：让 Codex 更稳定的 8 个习惯
| 习惯 | 错误写法 | 推荐写法 |
| 一次只做一个目标 | 帮我把项目优化一下 | 请修复注册页邮箱格式校验问题，只修改注册表单相关文件 |
| 先读再改 | 直接帮我改 | 先分析相关代码并给计划，我确认后再修改 |
| 提供验收标准 | 做好就行 | 提交前必须通过 npm test，并说明手动验证步骤 |
| 限制改动范围 | 全项目随便改 | 不要改数据库结构，不要改公共组件以外的文件 |
| 让它解释 diff | 改完告诉我 | 按文件列出改动原因、影响范围和回滚方式 |
| 要求小步提交 | 一次做完所有功能 | 先完成 API 层，再做 UI 层，最后补测试 |
| 善用错误日志 | 运行失败了，修一下 | 粘贴完整报错、命令、环境、最近改动和期望结果 |
| 保留人工审查 | 自动合并 | 只生成修改，最终由我审查 diff 后提交 |
图 2：高成功率 Codex 提示词的五层结构
六、中级技巧：Codex 提示词模板大全
Codex 的提示词不需要写得花哨，但必须结构清楚。最实用的格式是：任务目标 + 项目上下文 + 修改边界 + 验收标准 + 输出格式。下面给出可直接复制的模板。
模板 1：项目理解模板
请只读分析当前项目，不要修改任何文件。
请输出：
1. 技术栈与包管理器
2. 入口文件与核心模块
3. 启动、测试、构建命令
4. 目录结构说明
5. 适合交给 Codex 的 5 个任务建议
6. 风险较高、不建议自动修改的区域
模板 2：Bug 修复模板
任务：修复【具体 Bug】。
现象：【用户看到的问题】。
复现步骤：
1. …
2. …
期望结果：【正确结果】。
实际结果：【错误结果】。
限制：
– 尽量最小改动。
– 不改变现有 API 契约。
– 不修改无关 UI。
验收：
– 添加或更新测试。
– 运行相关测试并汇报结果。
– 输出根因分析和修改说明。
模板 3：新功能开发模板
任务：新增【功能名称】。
业务目标：【为什么要做】。
用户流程：【用户如何使用】。
涉及页面 / 接口：【列出已知文件或路径】。
功能要求：
– …
– …
边界：
– 不做支付逻辑。
– 不改数据库字段，除非先给迁移方案。
验收标准：
– 页面显示正确。
– 接口异常有提示。
– 测试或类型检查通过。
请先给实现计划，我确认后再修改。
模板 4：代码重构模板
任务：重构【模块 / 文件】。
目标：提高可读性和可维护性，但不改变外部行为。
要求：
– 保持函数签名兼容。
– 保持现有测试通过。
– 每一步改动尽量小。
– 如果发现行为不一致，立即停止并说明。
输出：
1. 重构前的问题
2. 重构方案
3. 修改文件列表
4. 验证结果
5. 可能的回归风险
模板 5：代码审查模板
请审查当前分支相对 main 的改动。
重点关注：
– 逻辑 Bug
– 安全风险
– 性能问题
– 类型错误
– 测试缺失
– 可读性和可维护性
请按严重程度输出：高 / 中 / 低。
每条建议包含：问题位置、原因、影响、建议修复方式。
不要直接修改文件，先输出审查报告。
七、实战场景：从基础到高级怎么用
场景 1：快速读懂陌生项目
当你下载一个开源项目、接手旧项目，或者准备改别人写的代码时，先让 Codex 给你做“项目地图”。这比直接问“这个项目怎么运行”更有效。
请像资深工程师接手项目一样，帮我梳理当前代码库：
– 主要模块和数据流
– 用户请求从入口到输出经过哪些文件
– 哪些目录最值得先读
– 哪些地方风险最高
– 我想新增一个会员下载功能，大概会涉及哪些模块
场景 2：修复报错
把命令、完整错误、你已经尝试过的方法都给 Codex。不要只说“报错了”。如果错误来自终端，尽量保留原始日志。
我运行 npm run build 时失败，错误如下：
【粘贴完整错误日志】
请你：
1. 判断根因
2. 找到相关文件
3. 给出最小修复方案
4. 修改后重新运行构建
5. 如果失败，继续根据新错误迭代，但不要修改无关文件
场景 3：前端页面微调
前端 UI 任务要尽量提供截图、设计描述、页面路径和样式约束。不要让 Codex 自由发挥，否则它可能会改变整体视觉风格。
请调整首页卡片区样式：
– 卡片间距稍微加大
– 标题字号提升一级
– 移动端保持一列布局
– 不改变配色和文案
请先定位相关组件，再最小改动实现。完成后说明 CSS / Tailwind 类名的变化。
场景 4：生成测试
请为 src/lib/price.ts 中的价格计算逻辑补充测试。
要求：
– 覆盖正常价格、折扣、免费、异常输入、小数精度。
– 不改变原函数行为。
– 如果发现函数本身有 Bug，先报告，不要直接改。
– 运行相关测试并输出结果。
场景 5：自动生成文档
请根据当前项目代码，更新 README.md。
内容包括：
– 项目简介
– 本地启动步骤
– 环境变量说明（不要写真实密钥）
– 常用命令
– 部署注意事项
– 常见错误排查
要求：先读取 package.json、目录结构和现有 README，再给修改计划。
图 3：用 Codex 做代码审查与迭代的闭环
八、高级技巧：AGENTS.md 项目规则
当你反复在同一个项目使用 Codex 时，不应该每次都重复说明项目规则。更好的方式是把长期规则写进 AGENTS.md，让 Codex 每次开始工作前读取。AGENTS.md 可以理解为“给 AI 工程师看的项目说明书”。
AGENTS.md 适合写什么
- 技术栈和包管理器：例如 pnpm、Next.js、TypeScript、Prisma。
- 代码风格：命名规则、组件拆分方式、状态管理约定。
- 测试要求：修改后必须运行哪些命令。
- 禁止事项：不要改生产配置、不要提交密钥、不要改数据库迁移。
- 输出要求：每次完成后必须说明修改文件、验证命令和风险。
AGENTS.md 示例
# AGENTS.md
## 项目背景
这是一个 WordPress + Next.js 组成的 AI 教程网站项目，主要用于发布 AI 工具教程和付费下载页面。
## 技术栈
– 前端：Next.js + TypeScript + Tailwind CSS
– 后端：WordPress REST API
– 包管理器：pnpm
## 修改规则
– 优先做最小改动，不要重写无关模块。
– 不要修改 .env、密钥、生产域名和支付回调地址。
– 涉及支付、登录、下载权限时，先给计划，等待确认后再改。
## 验证要求
– 修改 TypeScript 文件后运行 pnpm typecheck。
– 修改 UI 后说明桌面端和移动端检查点。
– 修改 API 逻辑后补充或更新测试。
## 输出格式
每次任务完成后输出：修改文件、核心逻辑、验证结果、风险点、下一步建议。
| 高级建议 AGENTS.md 不要写得像长篇小说。最实用的内容是“项目约定 + 禁止事项 + 验收命令 + 输出格式”。它应该帮助 Codex 减少误改，而不是让它背诵项目历史。 |
九、高级技巧：CLI 配置与权限控制
Codex CLI 的优势是可配置、可脚本化、适合工程自动化。对于真实项目，最重要的不是“让 Codex 权限最大”，而是让它在合适范围内高效工作。
常见 CLI 命令
# 安装 Codex CLI
npm i -g @openai/codex
# 启动交互式会话
codex
# 升级到最新版
npm i -g @openai/codex@latest
# 以较安全的方式运行：允许项目内写入，敏感操作需要审批
codex –sandbox workspace-write –ask-for-approval on-request
config.toml 基础示例
# ~/.codex/config.toml
model = “gpt-5.5”
approval_policy = “on-request”
sandbox_mode = “workspace-write”
[profiles.deep-review]
model = “gpt-5.5”
model_reasoning_effort = “high”
approval_policy = “on-request”
sandbox_mode = “read-only”
[profiles.fast-fix]
model = “gpt-5.3-codex”
approval_policy = “on-request”
sandbox_mode = “workspace-write”
权限模式怎么选
| 模式 | 适合场景 | 风险 | 建议 |
| Read-only | 陌生仓库、审查、解释代码 | 低 | 新项目第一步优先使用 |
| Auto / workspace-write | 项目目录内常规开发、修 Bug、补测试 | 中低 | 日常推荐，配合 diff 审查 |
| on-request + network | 安装依赖、联网查询、调用外部服务 | 中 | 每次审批前看清命令 |
| Full Access / danger-full-access | 隔离虚拟机、一次性实验环境、完全可信任务 | 高 | 不要在生产机器和陌生仓库中随意使用 |
图 4：Codex 权限安全金字塔
十、高级技巧：把 Codex 变成可复用工作流
当你掌握基础用法后，真正节省时间的是把重复任务流程化。例如每次发布前自动检查、每次改动后生成变更说明、每次出现报错后自动定位根因。
工作流 1：提交前代码审查
请审查当前分支相对 main 的改动。
要求：
1. 先读取 diff。
2. 按高 / 中 / 低风险列出问题。
3. 对每个问题给出修复建议。
4. 不要直接修改，除非我回复“开始修复”。
工作流 2：测试失败自动定位
请运行项目测试。如果测试失败：
1. 先总结失败用例。
2. 定位最近相关改动。
3. 判断是测试过时还是代码错误。
4. 给出修复计划。
5. 等我确认后再改。
工作流 3：功能开发分阶段执行
- 阶段一：只读分析需求相关文件，输出计划。
- 阶段二：只改数据层或 API 层，运行测试。
- 阶段三：改 UI 层，做手动检查清单。
- 阶段四：补充测试和文档。
- 阶段五：输出合并说明、风险点和回滚方案。
十一、安全注意事项：别把 AI 编程变成生产事故
Codex 可以运行命令和改文件，这意味着它既能提高效率，也可能放大错误。真实项目中，安全策略应该默认保守。
必须遵守的安全规则
- 不要在生产服务器上直接给 Codex 高权限。
- 不要让 Codex 接触真实支付密钥、数据库密码、用户隐私数据。
- 涉及 rm、迁移数据库、批量改文件、网络访问、部署命令时必须人工审批。
- 所有变更都通过 Git diff 审查后再提交。
- 陌生仓库先只读分析，不要直接运行 install 脚本或高风险命令。
- 处理客户项目时，先确认数据合规、保密要求和团队规范。
敏感文件保护建议
| 文件类型 | 风险 | 建议 |
| .env / .env.local | 泄露 API Key、数据库密码、支付密钥 | 只提供 .env.example，真实密钥不要暴露给任务 |
| 数据库迁移文件 | 可能导致结构破坏或数据丢失 | 先给迁移方案，再由人工执行 |
| 支付回调代码 | 可能影响订单、退款、会员权限 | 必须人工审查，并在测试环境验证 |
| 部署脚本 | 可能影响线上服务 | 不要自动部署生产环境 |
| 用户数据导出 | 涉及隐私与合规 | 脱敏后再分析，避免上传敏感数据 |
十二、费用与用量：怎样更省额度
Codex 的用量和定价会随产品策略调整。写教程或给用户做培训时，不建议写死具体价格；更稳妥的方式是说明“以官方价格页和账户内显示为准”。在实际使用中，影响消耗的主要因素通常包括上下文长度、推理强度、任务持续时间、工具调用次数、是否多线程并行等。
省额度的实用方法
- 把大任务拆成小任务，不要一次让它“全面重构”。
- 先让 Codex 定位相关文件，不要让它扫描整个大型仓库。
- 明确禁止修改无关文件，减少无效探索。
- 把固定规则写进 AGENTS.md，减少每次重复说明。
- 让它先给计划，确认方向正确后再执行。
- 低风险小改用普通推理，高风险重构再提高推理强度。
十三、常见错误与排查
| 问题 | 可能原因 | 解决方法 |
| Codex 改了太多文件 | 任务边界不清、没有限制范围 | 要求最小改动；指定只修改相关文件；先计划再执行 |
| 修改后项目跑不起来 | 未运行测试、依赖或环境不完整 | 提供启动命令和错误日志；让 Codex 按新日志迭代 |
| 生成代码不符合项目风格 | 缺少项目规则 | 在 AGENTS.md 写入命名、目录、组件、测试约定 |
| 一直问我要权限 | 审批模式较严格或命令越界 | 确认命令是否必要；必要时临时调整权限，不要直接全放开 |
| 理解错需求 | 提示词缺少业务背景和验收标准 | 补充用户流程、边界条件、反例和成功标准 |
| 消耗过快 | 上下文过大、任务过长、多线程并行 | 缩小任务范围，关闭不必要线程，先做定位再修改 |
| 无法访问依赖或外部服务 | 网络权限受限或环境缺少配置 | 说明是否允许联网；使用测试环境；不要暴露真实密钥 |
十四、从新手到高手的学习路线
| 阶段 | 目标 | 练习任务 | 通过标准 |
| 入门 | 会让 Codex 读项目和解释代码 | 让它梳理一个小项目结构 | 能说清入口、核心文件、启动命令 |
| 基础 | 会让 Codex 修小 Bug | 修复一个表单校验或样式问题 | 改动小、测试通过、diff 可读 |
| 中级 | 会写高质量任务提示词 | 新增一个小功能并补测试 | 需求、约束、验收标准清晰 |
| 进阶 | 会做代码审查和重构 | 审查分支 diff，重构一个模块 | 能发现风险并保持行为兼容 |
| 高级 | 会配置 AGENTS.md、权限、工作流 | 建立项目规则和自动审查流程 | 团队可复用，安全可控 |
十五、可直接复制的万能提示词
你是我的资深软件工程协作助手。请按照以下流程处理任务：
【任务目标】
{写清楚要完成什么}
【项目上下文】
{技术栈、相关文件、错误日志、业务规则}
【修改边界】
– 只修改与任务直接相关的文件。
– 不要修改 .env、部署脚本、支付配置和数据库迁移，除非先征得确认。
– 优先最小改动，不重写无关模块。
【执行流程】
1. 先只读分析相关代码。
2. 输出计划，说明会改哪些文件。
3. 等我确认后再修改。
4. 修改后运行相关测试或类型检查。
5. 输出 diff 总结、验证结果、风险点和下一步建议。
【验收标准】
{写清楚测试命令、页面表现、接口返回、边界条件}
FAQ：Codex 使用常见问题
Q1：Codex 适合完全不会编程的人吗？
可以用于学习和辅助，但不建议完全依赖它直接改生产项目。零基础用户应先从解释代码、生成小脚本、修改简单页面开始，并保留人工确认。
Q2：Codex 会不会自动把代码发到网上？
通常不会自动发布，但如果你授予网络、Git、部署脚本等权限，就可能执行相关命令。因此必须看清审批提示，不要在生产环境随意放开权限。
Q3：Codex 和 GitHub Copilot、Cursor 有什么区别？
Copilot 更偏代码补全和 IDE 辅助，Cursor 是 AI 编辑器体验，Codex 更强调可以在项目中完成任务、运行命令、生成 diff、配合 CLI/App/Web 形成工程闭环。实际选择取决于你的开发习惯。
Q4：为什么 Codex 有时会改错？
常见原因是需求不明确、上下文不完整、没有验收标准、项目规则缺失或权限过大。解决办法是先让它只读分析，明确范围，再小步执行。
Q5：Codex 能直接做大型重构吗？
可以辅助，但不建议一次性全量重构。大型重构应拆成模块，先补测试，再逐步迁移，并在每一步审查 diff。
Q6：AGENTS.md 必须写吗？
不是必须，但强烈建议真实项目使用。它能把项目约定固定下来，减少 Codex 误解你的技术栈、命名规范和测试要求。
Q7：用 Codex 前一定要会 Git 吗？
建议至少会 git status、git diff、git checkout -b、git add、git commit。Git 是你回滚和审查 AI 改动的安全底线。
Q8：Codex 能连接数据库或服务器吗？
技术上可以在你授权和环境允许的情况下访问，但生产数据库、线上服务器、支付系统都属于高风险范围，必须使用测试环境和人工审批。
Q9：Codex 适合写 WordPress 插件或自动发布脚本吗？
适合。你可以让它分析现有插件结构、生成短代码、修复 REST API 报错、编写 Python 自动发布脚本，但涉及账号密码和支付回调时要格外谨慎。
Q10：怎样判断 Codex 的结果是否可靠？
看三个标准：改动范围是否符合预期、测试或构建是否通过、diff 是否能解释清楚。只要其中一个不满足，就不要合并。
参考资料与更新说明
本文根据 OpenAI 官方 Codex 产品页、帮助中心和开发者文档整理，适合作为网站教程发布。由于 Codex 的客户端、功能、计费和计划权益可能持续调整，正式发布前建议再次核对官方页面。
| 资料 | 链接 |
| OpenAI Codex 产品页 | https://openai.com/codex/ |
| Using Codex with your ChatGPT plan | https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan |
| Codex App 文档 | https://developers.openai.com/codex/app |
| Codex CLI 文档 | https://developers.openai.com/codex/cli |
| Codex Web / Cloud 文档 | https://developers.openai.com/codex/cloud |
| Codex IDE extension 文档 | https://developers.openai.com/codex/ide |
| AGENTS.md 自定义说明文档 | https://developers.openai.com/codex/guides/agents-md |
| Codex 安全与审批文档 | https://developers.openai.com/codex/agent-approvals-security |
| Codex Changelog | https://developers.openai.com/codex/changelog |
免责声明
本文为工具使用教程，不构成安全、法律、商业或财务建议。涉及生产环境、客户代码、支付系统、服务器、数据库和用户隐私数据时，请遵守团队安全规范和相关法律法规，并由具备权限和经验的人员最终审核。
