Codex代码审查怎么用？从读仓库到测试验证的完整工作流

RAOY的AI笔记

357人浏览 · 2026-08-11 14:17:49

RAOY的AI笔记 · 2026-08-11 14:17:49 发布

Codex代码审查怎么用？从读仓库到测试验证的完整工作流

摘要：本文整理一套可复用的 Codex 代码审查流程，包括审查范围确认、风险定位、最小修改、测试验证和人工复核。示例使用 Python 与 pytest，所有产品信息均以官方公开资料为准。

Codex 可以阅读代码库、修改文件并运行命令，但“能改代码”与“能完成可靠的代码审查”是两回事。如果一开始只说“帮我检查项目”，它通常会给出一份范围很大的建议，真正影响线上行为的问题反而容易被淹没。

更稳妥的做法是把代码审查拆成几个小任务：先了解仓库，再限定范围；先复现问题，再修改代码；最后用测试和 git diff 检查结果。本文适合已经有一个可运行项目，希望了解 Codex 代码审查怎么用的开发者。

Codex代码审查适合做什么

OpenAI将 Codex 定义为用于编写、审查和交付代码的编码智能体。官方开源仓库也说明，Codex CLI 可以在本地计算机中运行，并提供编辑器、桌面端和网页端等使用方式。不同入口的界面有所差别，但代码审查的基本方法相同：明确任务、读取上下文、执行检查、查看差异。

Codex比较适合处理下面几类工作：

阅读陌生仓库，梳理主要模块和调用关系；
检查一个 Pull Request 或指定提交的代码差异；
根据报错和测试结果查找可能的缺陷；
为现有逻辑补充单元测试；
检查异常处理、边界条件和类型错误；
在明确授权后修改文件，并运行项目已有的检查命令。

它不应该代替最终审核人。涉及权限、支付、数据库迁移、生产配置、密钥和用户数据时，自动修改必须经过人工复核。

准备一个可复现的审查示例

下面是一段计算折扣价格的 Python 代码：

# price.py
def final_price(price: float, discount: float) -> float:
    return price * (1 - discount)

代码看起来很短，但没有处理这些输入：

price 为负数；
discount 小于 0；
discount 大于 1；
传入字符串或 None；
浮点结果是否需要统一舍入。

如果直接让 Codex “优化代码”，它可能同时修改参数类型、异常类型、返回精度和调用方式。改动过大，很难判断哪一处是必要修复。代码审查的第一步应该是限制范围。

第一步：只读仓库，不立即修改

第一次提示词可以这样写：

请先阅读当前项目，不要修改文件。

任务：
1. 找到 final_price 函数及其调用位置；
2. 检查现有测试是否覆盖价格和折扣的边界值；
3. 列出可能改变现有行为的风险；
4. 给出建议检查的文件清单。

输出时请区分：已从代码确认的事实、需要进一步验证的判断。

这里特意写了“不要修改文件”。先得到文件清单和风险说明，能避免工具在不了解项目约定时直接重构。

拿到结果后，重点核对三个问题：

它找到的是不是真正被业务调用的函数；
项目是否已经在上层完成参数校验；
修改异常类型或返回值后，会不会影响现有调用方。

第二步：要求它先复现问题

没有复现步骤的修复很难验证。第二轮提示词可以继续限定任务：

先不要修改 price.py。

请为 final_price 补充最小测试，用例至少覆盖：
- 正常折扣；
- discount 等于 0 和 1；
- discount 小于 0；
- discount 大于 1；
- price 为负数。

先运行测试并记录当前失败结果，再提出修改方案。
不要删除或改写已有测试。

假设项目使用 pytest，测试文件可以写成：

# test_price.py
import pytest

from price import final_price


def test_final_price_normal_discount():
    assert final_price(100, 0.2) == 80


@pytest.mark.parametrize("discount", [0, 1])
def test_final_price_boundary(discount):
    assert final_price(100, discount) in (0, 100)


@pytest.mark.parametrize("discount", [-0.1, 1.1])
def test_final_price_rejects_invalid_discount(discount):
    with pytest.raises(ValueError):
        final_price(100, discount)


def test_final_price_rejects_negative_price():
    with pytest.raises(ValueError):
        final_price(-1, 0.2)

运行测试：

pytest -q

当前代码不会抛出 ValueError，相关用例应当失败。失败结果就是后续修改的验证依据。

第三步：只允许最小修改

确认失败用例后，再让 Codex 修改实现：

根据刚才的失败测试修改 final_price，只处理已经覆盖的输入边界。

限制：
- 不改函数名和参数顺序；
- 不引入第三方依赖；
- 不修改无关文件；
- 保留现有正常输入的返回行为；
- 修改后运行 pytest -q；
- 最后列出改动文件和测试结果。

一种可能的修改如下：

def final_price(price: float, discount: float) -> float:
    if price < 0:
        raise ValueError("price must be non-negative")
    if not 0 <= discount <= 1:
        raise ValueError("discount must be between 0 and 1")
    return price * (1 - discount)

这段代码还没有解决所有问题，例如字符串输入会触发 TypeError，金额计算也可能需要 Decimal。这些内容没有出现在当前验收范围里，不应该顺手扩大修改。

第四步：用git diff检查真实改动

测试通过不代表修改一定正确。继续检查文件差异：

git status --short
git diff -- price.py test_price.py

审查 git diff 时可以按下面的顺序看：

是否出现任务范围之外的文件；
原有函数签名有没有变化；
异常类型和错误信息是否符合项目约定；
测试是不是只验证实现细节，而没有验证业务行为；
是否有被误删的注释、类型标注或兼容逻辑。

还可以让 Codex 对自己的差异再做一轮只读审查：

请只审查当前 git diff，不再修改文件。

按严重程度列出问题：
- 会导致错误结果或兼容性问题；
- 缺少的边界测试；
- 可读性建议。

每条问题必须给出对应文件和代码位置。没有证据的问题不要列出。

“每条问题给出文件和位置”能够减少空泛建议，也方便开发者逐项核对。

第五步：根据项目类型补充检查命令

pytest -q 只覆盖测试。真实项目通常还有格式、类型和静态检查。

Python项目常见检查：

pytest -q
ruff check .
mypy .

Node.js项目常见检查：

npm test
npm run lint
npm run typecheck

命令必须以项目真实配置为准。仓库没有 mypy 或 typecheck 脚本时，不要为了凑流程临时引入新工具。先检查 pyproject.toml、package.json、CI配置或项目README中已经使用的命令。

一份可以复用的Codex代码审查提示词

下面的模板适合检查指定模块或 Pull Request：

请审查【文件、目录或提交范围】，先不要修改代码。

项目目标：
【说明这段代码负责什么】

重点检查：
1. 会导致错误结果的逻辑问题；
2. 空值、越界、并发和异常处理；
3. 与现有接口或调用方的兼容性；
4. 测试遗漏；
5. 安全与敏感数据风险。

约束：
- 只基于仓库中能够确认的信息；
- 每条问题标出文件、位置和触发条件；
- 区分确定问题与待验证风险；
- 不做与本次任务无关的重构；
- 先给审查报告，等我确认后再修改。

验证方式：
【填写项目已有的测试、lint、构建命令】

提示词里最有用的内容不是“你是一位资深工程师”，而是审查范围、禁止修改项和验收命令。任务边界写得越清楚，最后的差异越容易检查。