← सभी गाइड पर लौटें

用 Codex 与脚本自动化代码审查、测试和发布的实战指南

先确定可自动化的工作流边界

Codex 最适合处理重复但需要理解上下文的开发任务，例如总结 Git 变更、检查潜在风险、生成测试建议、整理发布说明和分类 Issue。不要一开始就让 AI 直接合并代码；先把流程拆成“收集信息、调用模型、校验结果、执行后续动作”四步，才能稳定落地。

建议先选择一个低风险场景：每次提交 Pull Request 时，脚本读取 git diff 和测试结果，交给 Codex 生成结构化审查报告。报告只提出建议，不自动修改生产代码，团队可以快速验证输出质量。

第 1 步：配置 Codex 与 59API

创建 59API 账户后，在控制台生成 API Key。59API 提供与 Codex、Claude Code 和 OpenAI SDK 兼容的接口，可将 API Base URL 配置为 https://api.59api.com，并按控制台提供的兼容路径填写客户端设置。把密钥保存到本地环境变量或 CI 的 Secret 中，避免写入仓库。

• 设置 OPENAI_API_KEY 为 59API 控制台生成的密钥。
• 设置 Codex 或 SDK 所需的 Base URL，指向 59API。
• 在 .gitignore 中加入 .env，防止密钥被提交。
• 先用一个简单请求验证模型、网络和额度配置。

59API 适合需要频繁调用模型的自动化任务：按量付费、价格低，并提供原生官方质量的 Claude 与 GPT 模型，无需为了控制成本而牺牲输出质量。对于轻量分类可选更快的模型，复杂代码分析再切换到高能力模型。

第 2 步：编写可复用的审查脚本

在项目中创建 scripts/ai-review.sh。脚本第一部分用 git diff origin/main...HEAD 收集变更，再限制输入长度，例如只保留前 12000 个字符，避免一次请求携带大量无关内容。第二部分读取测试日志；如果测试失败，应把失败用例和错误栈一并放入提示词。

提示词要明确角色、输入和输出格式。例如要求：你是资深代码审查员；仅基于提供的 diff 判断；返回 JSON；字段固定为 summary、risks、test_suggestions、severity；severity 只能是 low、medium 或 high。结构化输出比自由文本更容易被脚本解析，也便于后续写入 PR 评论。

• summary：不超过三条，说明本次修改做了什么。
• risks：列出文件名、风险原因和修复建议。
• test_suggestions：给出可执行的边界测试场景。
• severity：用于决定是否阻断后续发布步骤。

如果使用 Codex CLI，可在脚本中调用其非交互执行模式，将提示词通过标准输入传入，并把最终结果写到 artifacts/ai-review.json。脚本结束前使用 jq 校验 JSON；校验失败时应保存原始响应并返回非零状态，而不是把不完整结果继续传给部署流程。

第 3 步：在 CI 中串联触发条件

在 GitHub Actions、GitLab CI 或其他流水线中，把脚本放在单元测试之后执行。推荐的顺序是：安装依赖、运行测试、生成 diff、调用 Codex、校验 JSON、发布 PR 评论。只有 severity 为 high 时才将任务标记为需要人工确认；不要让模型单独决定生产发布。

还可以增加缓存和去重：以提交 SHA 为键保存审查结果，同一提交重新运行流水线时直接读取已有报告。对于文档改动或锁文件改动，脚本可提前跳过模型调用，进一步减少成本和等待时间。

第 4 步：控制成本、权限和输出质量

为每类任务设置明确预算。简单标题生成、Issue 分类可使用低成本快速模型；跨文件重构建议、复杂测试分析再使用能力更强的模型。59API 同时支持多种 Claude 和 GPT 模型，便于在一个兼容接口下实现按任务路由，并可通过推荐返利降低长期使用成本。

安全方面，发送 diff 前应过滤 .env、私钥、访问令牌和客户数据；CI 使用最小权限 Token；审查报告不得直接执行其中包含的命令。每周抽样检查 AI 建议的准确率，记录误报类型，再更新提示词和跳过规则。准备开始时，可注册 59API，用一个 PR 审查脚本先完成最小闭环，再逐步扩展到发布说明、故障摘要和 Issue 分流。

मूल्य · दस्तावेज़