1. 一次深夜 Review 翻车，逼我把 CodeX 请进 GitLab CI
上周五晚上，我盯着屏幕上一个 800 行的 Merge Request 发呆。三处未使用的 import、一个魔法数字 86400 藏在日期计算里连注释都没有、还有一段空 catch 把异常直接吞掉只留一行 log。我在评论框里打了又删，删了又打——这种一眼能看出的低级问题，难道要我一条条列出来贴在 MR 下面？更搓火的是，GitLab CI 跑了 15 分钟，最后因为一个 lint 错误挂了，同事被迫重新 push，整个合并拖到凌晨。
那天晚上我决定把 CodeX 塞进 GitLab CI，让机器先扫一遍，把所有"不需要人脑判断"的问题挡在门禁外，把真正需要业务上下文的问题留给人工 Review。不过在动手之前有个更现实的卡点：CodeX 底层模型请求默认直连它的官方供应商，而团队里每个人手上额度、Key、可用模型都不统一，CI 里不能每次都去蹭本地开发者的 Key。后来我把这一层的模型调用统一改成走 TaoToken——先到 TaoToken 创建 API Key，再把 Base URL 填成 https://taotoken.net/api，CodeX 在 CI 里发出去的模型请求就全部由 TaoToken 这个兼容通道接管了。整个过程不碰任何灰色操作，只是换一个更可控的 API 入口。
下面我把这套自动化代码审查流水线从零讲清楚，配置、截图、坑位都按实际能跑通的标准来。
2. Review 800 行 MR 的低级错误，让我彻底放弃人肉巡检
先摊开那个 800 行 MR 到底让我炸了什么。三处未使用的 import 其实 IDE 早就标黄了，但同事直接忽略；86400 这个数字，如果不是我花了五分钟比对 Git 历史里的日期处理逻辑，根本猜不到是 24 小时的秒数；空 catch 更好笑——异常被吞了，日志只打了条消息出来，线上数据错乱了都定位不到源头。这类问题有一个共同特征：它们不需要业务知识，纯粹是"代码规范层面"的问题，完全可以用工具自动识别。
当时我把这些内容在 MR 评论框里打了又删，是因为我意识到：即使我今天把这三条评论粘贴上去，同事明天还能给你写出新的魔法数字。人肉 Review 的带宽有限，它应该花在"这个逻辑在并发下会不会现形"这种问题上，而不是用来找没用的 import。
所以最终我设定的目标很明确：CodeX 在 CI 里担任门禁角色，只负责拦截语法、规范、安全、明显性能隐患层面的问题；严重问题直接 fail 流水线阻止合并，轻度问题以 MR 评论形式贴在讨论区。人工 Review 退居二线，专注业务架构和逻辑正确性。
现在想象一下，如果 CI 里没有 CodeX，你只能骂骂咧咧地写评论；有了 CodeX，你只需要在 .gitlab-ci.yml 里加一个 job，然后等着系统把问题清单送上门。
3. 用 Docker 跑 CodeX，填入 TaoToken 的 Key 和 Base URL
3.1 准备材料，先把一把团队共用的 Key 拿到手
要让 CodeX 在 CI 里发请求，你手里必须有一把"跑在服务器上"的 API Key，而不是你自己电脑上临时登录的凭证。打开官网 TaoToken 注册并创建 API Key，Key 创建后复制出来，形如sk-xxxxxxxx，你可以先放在本地环境变量里测试，之后再挪到 GitLab CI variables。生成 Key 的时候注意看下控制台的权限设置，建议只给「模型调用」相关权限，别把管理权限也挂在这把 Key 上。
同时你要从 TaoToken 的模型广场确认一个模型 ID。CodeX 走 OpenAI 兼容接口，所以模型 ID 必须填模型广场当时列表里的值，不要自己猜gpt-5或随便加日期后缀——填错了直接 404，CI 日志上只有一行 model not found，非常难排查。
3.2 .gitlab-ci.yml 里加一个 code-review Job
GitLab Runner 用 Docker executor，我们把 CodeX CLI 镜像拉起来，在 script 阶段运行 review 子命令。配置文件的要点我直接写出来：
code-review: image: registry.gitlab.com/codex/codex-cli:latest stage: test variables: CODEX_API_KEY: $TAOTOKEN_API_KEY CODEX_BASE_URL: "https://taotoken.net/api" script: - codex review --target-dir ./src --format gitlab-mr only: - merge_requests这里的CODEX_API_KEY和CODEX_BASE_URL是两个环境变量，CodeX CLI 在启动时会读取它们来决定用哪个供应商的模型接口。CODEX_API_KEY填的字符串来自 GitLab CI variables 里的TAOTOKEN_API_KEY，也就是你在 TaoToken 创建的那把 Key；CODEX_BASE_URL固定写成https://taotoken.net/api，注意这里api后面不要加/v1，加了反而可能触发路径拼接错误。
如果你用的是最新版本的 CodeX CLI，它可能已经改名成codex-exec或者需要你先执行codex login之类的交互命令。遇到这种情况，先本地codex --help确认子命令名称，别把旧的codex review硬套在新版本上。
3.3 你会踩到的第一个坑：CodeX CLI 不认识 Base URL
如果你直接抄网上的旧教程，把 Base URL 填成https://api.openai.com，代码就能跑；但一旦填成https://taotoken.net/api，有些版本的 CLI 会报Invalid base_url或API key not found。解决办法是确认 CodeX CLI 读取的是我们设置的环境变量名，而不是硬编码的官方地址。
实在不确定的时候，可以在 script 里先打印一下环境变量，确认 CI 里注入成功：
script: - echo $CODEX_BASE_URL - echo ${#CODEX_API_KEY} # 只打印 Key 长度，别打印 Key 本身从日志里看到https://taotoken.net/api和 51 位的 Key 长度，再继续跑 review。
4. codex-rules.yaml：把规则集从“什么都报”收敛成“只堵真问题”
4.1 默认规则太多，刷屏反而让团队失去嗅觉
CodeX 默认配置会盯住变量名长度、注释缺失、括号换行这类风格问题。一个 800 行的 MR 可以给你弹出两百条 warning，开发者看到满屏评论只会麻木，连真正该看的 SQL 注入告警也划过去了。我在第一周就被同事集体吐槽过，之后果断改掉默认规则。
我的处理方式是在项目根目录放一个codex-rules.yaml，把规则划分成两个严重级别：error 级直接 fail 流水线，warning 级只贴 MR 评论不阻塞合并。
4.2 规则文件书写标准
# codex-rules.yaml rules: - id: hardcoded-secret severity: error action: block pattern: "(?i)(api[_-]?key|secret|password)\\s*[:=]\\s*.+" message: "发现疑似硬编码密钥，请改用环境变量注入" - id: empty-catch severity: warning action: comment pattern: "catch\\s*\\([^)]*\\)\\s*\\{\\s*\\}" message: "空 catch 块：至少记录异常上下文或注释原因" - id: magic-number severity: warning action: suggest pattern: "[^A-Za-z_]\\d{3,}[^A-Za-z_]" message: "发现魔法数字 {match}，建议定义为具名常量并说明单位/用途"注意pattern这里用的是正则表达式，CodeX 会拿它去匹配 AST 或源码片段，不同版本的规则引擎支持的语法不完全一样。建议先本地建一个小目录，放几个故意有问题的文件跑一遍，确认这个正则在当前版本里能命中——否则你可能以为规则生效，实际它什么都没匹配上。
4.3 在 CI 里引用它
规则文件要跟着代码一起进版本库，而不是写在 Dockerfile 里。在 review 命令后面加--config ./codex-rules.yaml：
script: - codex review --target-dir ./src --config ./codex-rules.yaml --format gitlab-mr这样每次 MR 变更代码的同时审查规则也在版本控制里，有争议时可以直接发评论讨论，不用重新构建镜像。
5. 把审查结果贴回 MR 评论区，而不是埋进流水线日志
--format gitlab-mr输出的是 GitLab 原生支持的格式，但我不建议直接把这种格式塞到脚本里。更好用的做法是让 CodeX 输出 JSON，然后通过 GitLab API 把结构化评论一条条 POST 到 MR 的讨论区。
大致的 CI 步骤分成两段：
script: - codex review --target-dir ./src --format json > codex-report.json - | jq -r '.issues[] | select(.severity == "error") | "**error** [\(.file):\(.line)] \(.message)"' codex-report.json | while read -r line; do curl --header "PRIVATE-TOKEN: $GITLAB_API_TOKEN" \ --data-urlencode "body=$line" \ "https://gitlab.com/api/v4/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes" done先把 error 级评论贴上去，再贴 warning 级的建议。
这里有两个容易踩的坑。第一个是GITLAB_API_TOKEN必须放进 GitLab 项目的 CI/CD variables 里，千万不要直接写死在 .gitlab-ci.yml 中，否则 push 到仓库后 token 会被人抓取；第二个是curl传 body 一定要用--data-urlencode，不然评论里出现空格、换行、中括号都会被截断或解析失败。我最初就是没加--data-urlencode，导致一条完整评论只显示了前半句。
如果你不想在 CI 里多装一个 jq，也可以让 CodeX 直接输出 GitLab 原生的 MR 评论格式，然后整体作为一条 note POST 上去。缺点就是评论是一大段，不能按文件行号精确评论。我的建议是原始代码量不大的项目用这个省事方案，代码量大的还是走 JSON 解析，定位更精确，开发者点击评论能直接跳转到对应行。
6. 加 fail 逻辑，让流水线对严重问题说“不”
评论贴了，但开发者不修改怎么办？解决方案是让 CodeX 的审查结果直接参与流水线决策。在 script 里加一段判断逻辑：
script: - codex review --target-dir ./src --format json > codex-report.json - | if jq -e '.issues[] | select(.severity == "error")' codex-report.json > /dev/null; then echo "检测到 error 级问题，流水线失败" exit 1 fi - | jq -r '.issues[] | select(.severity != "error") | "**\(.severity)**: \(.message) at \(.file):\(.line)"' codex-report.json | while read -r line; do curl --header "PRIVATE-TOKEN: $GITLAB_API_TOKEN" \ --data-urlencode "body=$line" \ "https://gitlab.com/api/v4/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes" doneexit 1会让这个 job 进入 failed 状态，合并请求的“流水线必须通过”勾选就会生效，MR 直接无法合并。有一点值得留意：把hardcoded-secret这类规则设成 error 会让合并门槛明显变高，团队刚开始会不适，建议先从空 catch 和未使用的变量这类客观事实开始，然后逐步加码。
我在实际配置时用timeout: 10 minutes限制了这个 job 的时长，超时直接标记为 warning 而不是 fail。代码审查工具不该成为上线的瓶颈，如果它超时了说明项目规模太大或规则写得太复杂，这是另一个需要优化的问题，不该拿合并流程来惩罚开发者。
7. --diff-only 增量审查，把扫描时间从 5 分钟压到 30 秒
7.1 全量扫描的代价
项目变大后每次全量扫描都要花 5 分钟。开发者 push 一次等 5 分钟才能看到结果，这种体验基本等于没有反馈。CodeX 提供了--diff-only模式，只分析本次 MR 变更涉及的文件，而不是整个代码库。
script: - codex review --target-dir ./src \ --config ./codex-rules.yaml \ --diff-only \ --base-ref origin/main \ --format gitlab-mr--base-ref origin/main是告诉 CodeX 拿当前分支和 main 分支做 diff。注意这里的前提是你的分支和 main 之间没有大量冲突，否则 diff 计算出来的文件列表可能不准确，CodeX 会漏掉部分变更文件里的问题。
7.2 放在编译 job 的后面
--diff-only依赖源码能正确解析，如果代码编译失败，CodeX 的 AST 分析可能报一堆"文件不存在"的错，然后再给你贴十几条无效评论。所以这个 job 应当排在build或compile之后，等编译产物生成完毕再做静态扫描。用 GitLab CI 的 dependencies 或 needs 控制依赖关系：
stages: - build - test code-review: stage: test needs: ["build"] script: - codex review --target-dir ./src --config ./codex-rules.yaml --diff-only --base-ref origin/main --format gitlab-mr这样 push 一次普通改动，从流水线触发到看到 MR 评论大约 30 秒到 1 分钟。不过要提醒一句：如果本次 changes 里没有目标语言的关键源码文件，CodeX 可能输出"未发现符合规则的问题"，这是正常的，不是配置失败。
8. 验证一遍：push 一个 MR，看评论和 Token 消耗
配置完成后的验收动作很简单。本地新建一个分支，故意在源码里留一处空 catch 或魔法数字，push 到 GitLab，发起 MR。流水线自动跑完后，你应该能在 MR 讨论区看到类似"发现魔法数字 86400，建议定义为常量 SECONDS_IN_DAY = 86400"的评论。如果规则命中 error 级别，流水线状态显示 failed，合并按钮灰掉。
此时再打开 TaoToken 控制台 看用量列表，你会看到刚才 CodeX 在 CI 里发出去的模型请求已经记了一笔 Token 消耗记录，并且时间、模型 ID、请求次数都对得上。这个记录就是验证"CI 里的模型请求确实走了 TaoToken"的最直接证据，别只靠"它跑通了"就下结论。
如果评论没有出现，用我在 3.3 节里的方法先确认环境变量是否注入成功；如果报 401，说明 Key 配错了；如果报 404，大概率是模型 ID 填了不存在的名字，去 TaoToken 模型广场 核对。
9. 本地调试 CodeX 配置的脚本
CI 里调试codex-rules.yaml是件极痛苦的事，每次都要 push 触发流水线、等 job 排队、再翻日志。我把这个过程搬到了本地，用 Docker 模拟 GitLab Runner 环境：
#!/bin/bash # scripts/local-codex-review.sh docker run --rm \ -v $(pwd):/workspace \ -w /workspace \ -e CODEX_API_KEY=$TAOTOKEN_API_KEY \ -e CODEX_BASE_URL="https://taotoken.net/api" \ codex-cli:custom \ codex review --target-dir ./src \ --config ./codex-rules.yaml \ --diff-only \ --base-ref origin/main \ --format gitlab-mr注意这个命令假设你本地已经构建了一个带完整依赖的codex-cli:custom镜像。如果你没有那么做，也可以直接npm install -g @taotoken/taotoken，然后通过它提供的一套命令行来做联通性测试，taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m YOUR_MODEL_ID这样直接验证 TaoToken 的 API 通道是不是通的，避免把"网络不通"和"规则写错"混在一起排查。
10. 实践排障：CI 里最常见的三个报错
10.1 Authentication fails (401)
如果你确定 Key 没抄错，先检查环境变量名字。CodeX CLI 读的是CODEX_API_KEY还是OPENAI_API_KEY，不同版本差异很大。在 script 里加printenv | grep -i api打印启动过程的环境变量，确认 CI 注入实际生效。另一种可能是 GitLab CI variables 里把 Key 设成了protected，而当前分支不是受保护分支，导致变量根本没有传入 job。这种隐蔽问题（变量静默不注入）最好排查。
10.2 Model not found (404)
这个报错 99% 是模型 ID 写错。有人从 Coze 或者 GPT 商店里看到一个模型名就拿过来填，可在 TaoToken 模型广场上根本没有这个 ID。填 ID 之前一定去 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 模型广场的列表里复制完整的模型 ID，不要用你记在备忘录里的别名。
10.3 Exec format error 或者 /bin/sh: codex: not found
通常是镜像和架构不匹配，CI 用的 GitLab Runner 是 ARM64 或不同发行版，CodeX 的 CLI 版本不兼容。解决办法是用更适合的镜像标签，或者走npm install -g @taotoken/taotoken再通过taotoken cc命令完成同样的联通。CI 环境不稳定的情况下，提前在本地把 TaoToken 通道验证跑通，线上排查成本会小很多。
11. 我们的 MR 流程现在长这样
真正跑起来之后，整个流程是：开发者 push 代码 → GitLab CI 自动触发 → 编译 → 单元测试 → CodeX 增量审查（--diff-only + codex-rules.yaml）→ 严重问题直接 fail 流水线 → 非严重问题以评论形式贴在 MR 讨论区 → 人工 Review 只处理业务逻辑和架构问题。
这套流程跑通后，最直观的变化是：低级问题不会再出现在人工 Review 的视线里，类似 86400 的魔法数字会在 push 后 30 秒内就收到一条包含修复建议的评论，而不是几小时后在 MR 讨论区被吐槽。想在合并前确认关键问题是否拦住，直接去 模型对话页 用同一把 Key 发送一次测试请求对比模型行为；如果长期要写代码，可以看下 Coding Plan 套餐是否覆盖团队的使用量；Key 的创建和用量都统一在 控制台 API Keys 里管理。整个链路的网络和鉴权细节可以对照 Claude Code 接入文档 理解，虽然文档名字写的是 Claude Code，但里面的 Base URL 和 Key 规则同样适用于 CodeX 这类走兼容接口的工具。
昨天我看到那个经常写魔法数字的同事，把代码改成了const SECONDS_IN_DAY = 86400; // 24小时的秒数。在 MR 评论里提醒他的不是人，而是 CI 里那个默默扫变更文件的 CodeX job。它不会骂人，也不带情绪，只是在合并之前平静地说一句：这里有一个明显可以被消除的坏味道。
