第 03 模块 · 2 节

Codex 集成流水线实战

《Codex 生产级工程》03 CI/CD 流水线 · 本节时长 40 分钟

把 Codex 变成流水线里的一环

上一节打了 CI/CD 基础。这一节实战：把 Codex 集成进流水线——让它在 PR 时自动审查、自动跑测试，成为交付流水线里稳定的一环。

目标：让 Codex 不只是一个「人用的工具」，而是一个「自动跑在流水线里的环节」。

贯穿项目这一节把 deploy-bot 正式接进流水线：让它在流水线里扮演「自动审查 + 自动部署」的角色，PR 提交后自动跑起来。deploy-bot 从「后台脚本」正式变成「流水线的一环」，就在这一节落地。

Codex 在流水线里能干什么

场景	干什么
PR 自动审查	代码一提 PR，Codex 自动审一遍
自动跑测试	每次提交自动跑测试
生成建议	给出改进建议，辅助人评审

核心价值：把「人工审查」的一部分，变成「自动化质量关卡」。

对 deploy-bot，它除了审查，更核心的角色是自动执行部署。所以它在流水线里能干两件分工明确的事：一是审查改动质量，二是执行部署动作。

一个集成思路

以 GitHub Actions 为例，在流水线里加一个「用 Codex 审查」的阶段：

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test
      # 集成 Codex 审查（示意）
      - name: Codex review
        run: codex "审查本次改动，按必须改/建议改/可不改输出"
        env:
          ANTHROPIC_BASE_URL: $
          ANTHROPIC_AUTH_TOKEN: $

不同工具接入方式不同，以上为示意。关键是「把 Codex 当流水线里的一个步骤」。

对 deploy-bot，把这个思路扩展成「审查 + 部署」两阶段。以「部署 staging」为例（示意）：

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    needs: test          # 测试通过才进入部署
    steps:
      - uses: actions/checkout@v4
      - name: Run deploy-bot (staging)
        run: ./deploy.sh --env staging
        env:
          STAGING_KEY: $

具体 API 以你所用的 Codex / 平台文档为准。核心是把「deploy-bot 部署」当成流水线里一个有依赖顺序的步骤。

集成时的四个要点

1. 密钥用 Secret

模型的 Key 不能明文写在配置文件里，要用平台的 Secret 管理，流水线运行时才注入。

对 deploy-bot 更关键：staging 和 production 的密钥要分开存，分别用 secrets.STAGING_DEPLOY_KEY、secrets.PROD_DEPLOY_KEY，只在对应阶段注入。

2. 环境要自包含

流水线环境干净，Codex 需要的依赖、模型配置都要在流水线里配好。

deploy-bot 要用的工具（git、构建工具、部署 CLI）都要在 runner 上装好，别指望「本机有」。

3. 阶段顺序合理

测试先跑，通过了再让 Codex 审查，别让它在坏代码上白费功夫。

deploy-bot 的部署更要排在测试、构建之后——用 needs 声明依赖，确保坏代码根本走不到部署那一步。

4. 结果要能看

Codex 的审查结果，要能回到 PR 里给人看，而不是埋在日志里。

deploy-bot 的部署结果也一样：成功/失败、部署到哪、什么版本，要能回到流水线界面和 PR 里，让人看得见。

一个小步起步

别一次把流水线做复杂，先加一个最小环节：

先只加「自动跑测试」
跑通了，再加「Codex 审查」
稳定了，再加「自动部署」

先最小、再扩展，每次改动可回退。

对 deploy-bot 的接入也一样：先把部署 staging 接入流水线跑通，稳定后再加 production 门禁和更多自动环节。一次只加一层，出问题好定位。

常见坑：把 deploy-bot 的密钥写死在配置文件里

把 Codex / deploy-bot 集成进流水线时，最高危的坑是把密钥明文写进 .yml 或提交进仓库。

真实场景：图省事，你直接在 workflow 文件里写了模型的 Key 和部署密钥，还提交到了仓库。仓库是很多人能看的，密钥立刻泄漏，任何人都能冒充 deploy-bot 部署。

为什么：配置文件会进版本库、会被复制、会被人翻看。任何明文密钥都是「一次性就永久泄漏」的安全事故。

怎么破：一切凭据走平台 Secret，用 $ 在运行时注入；部署密钥 staging/production 分开；一旦发现明文密钥入库，立即作废并轮换，别想着「先删了就行」。

小结

目标：把 Codex 变成流水线里自动的一环
用途：PR 自动审查、自动跑测试、生成建议
四要点：Secret 管密钥、环境自包含、顺序合理、结果可见
小步起步：先测试，再加审查，最后部署

练习把 deploy-bot 接入流水线并跑通 staging 部署。①三步走：a. 在已有流水线后加一个「部署 staging」阶段，用 `needs` 让它依赖测试通过；b. 把 staging 密钥配到平台 Secret，运行时注入；c. 提交代码触发，确认 staging 真的被部署。②怎么判断做对了：改坏代码提交，部署阶段不会执行（被测试卡住）；staging 部署成功且结果在流水线界面可见；配置文件里搜不到任何明文密钥。③卡住了怎么办：部署阶段没跑，先确认前序阶段通过 + `needs` 写对；密钥注入失败，先检查 Secret 名和引用拼写；部署到 staging 不生效，先手动跑一次脚本排除脚本本身问题。

下一节，讲流水线的安全与失败恢复。

上一节 ← CI/CD 基础与主流平台下一节流水线安全与失败恢复 →

返回《Codex 生产级工程》大纲