审查Codex的修改：结合diff与执行结果进行检查

Codex修复功能并告知“修改完成”时，首先应查看实际文件差异。结果摘要有助于理解修改目的，但新增和删除了什么，需要在diff中核实。一起阅读改了几个文件、是否修改了与原问题无关的代码，以及验证测试涵盖什么范围，才能更好地判断是否接受结果。本文关注实际接收修改时的检查顺序，而不是一般的代码审查请求。

先核实比较对象是什么

diff是两个状态的差异，可以比较工作目录与暂存区，也可以比较两个提交或分支。同样是“查看修改”界面，基准不同，显示的文件也会不同。OpenAI的官方审查指南说明，审查界面反映仓库当前的修改状态，可能包含Codex之外的修改。因此，不应断定界面中的全部文件都属于本次AI工作。首先应了解比较的是哪个基准状态与当前状态。

使用终端时，可以通过Git只读命令分别查看范围。作为说明，git diff用于查看尚未暂存的修改，git diff --staged用于查看已暂存的修改。git diff HEAD可查看相对于最近提交的工作目录中已跟踪文件的修改。本文命令是说明检查方法的示例，并非在个人仓库执行后的结果。也应记住，新建且未跟踪的文件需另外查看状态列表。

根据文件列表比较预期范围

假设施工任务是“修复设置界面的选项保存错误”。设置界面、保存函数及相关测试发生修改，是自然的。但如果登录权限设置、整个样式文件乃至包版本都被修改，就需核实理由。包含看似无关文件，并不一定错误；可能为解决原问题而修改了公共函数。但必须能解释关联，才能确定审查范围。

不要只凭文件名判断作用，可以要求记录修改目的。例如：“请将各修改文件分类为解决问题直接必要的修改、验证用修改与其他修改，并说明理由。”大量格式整理可能掩盖真正改变行为的代码行。核实能否分开功能修正与格式变化，有助于下一步审查。对于用户已经修改的文件，也应阅读其目的，并与本次结果共同对照。

待检查的变化	应思考的问题	必要验证
修改条件语句	新条件改变了哪些输入的处理	比较正常、空值与边界输入
修改函数名称	调用它的其他文件是否也已修改	检查调用位置与构建
修改默认值	是否影响现有用户设置	比较已存数据与新数据
修改包	是否为本次修正所必需	核实兼容性、安装与锁定文件
新增测试	是否真正复现原错误	核实修改前失败与修改后结果

同时阅读红色删除行与绿色新增行

只看新增代码，很难知道以前保证的行为是否消失。应同时阅读删除行的作用，以及新行如何接替这一作用。diff的上下文行显示未修改的周边代码。如果上下文不足，应打开原文件与整个相关函数阅读。即使只修改一行条件语句，前面可能发生数值转换，后面可能进行异常处理。修改行数不能代表影响范围。

例如，假设JavaScript代码用if (!value)在没有值时提供默认值，该条件也可能把false或0当作需要默认值。如果改为仅检查null与undefined，false和0就会保留。这种修改是否正确，取决于实际要求。如果用户可以选择代表“关闭”的false，保留它可能必要；但若空字符串也应视为没有值，则需讨论额外条件。不要因为代码更短就判断正确。

制作不同输入的前后结果表

审查修改的条件时，分别检查不同输入比只使用一个正常值更好。对于假设的选项保存代码，应规定true、false、0、空字符串、null和undefined分别表示什么。此表是说明审查方法的示例，并非真实产品使用的值。只有先确定值的含义，才能判断旧代码与新代码的结果哪个符合要求。数据类型不同，即使屏幕显示相同值，也可能通过不同条件。

示例输入	业务含义示例	待审查条件
false	用户关闭功能	是否保留，而非被默认值覆盖
0	允许的最小数量	是否与缺失值区分
空字符串	用户清空值	是否定义了允许空值
null	明确表示不存在值	默认值或错误处理是否正确
undefined	未提供字段	是否符合缺失字段政策

了解测试通过的范围

看到“所有检查通过”时，应核实在什么状态下执行了哪些检查。如果安装阶段失败，测试未能开始，应与测试失败区分。仅相关单元测试通过，与在实际界面检查整个应用也不同。可以要求验证结果分别列出执行命令、检查对象、成功与失败，以及未执行项目。还应核实检查时间，避免把旧结果当作最后一次修改后的结果。

检查新测试是否只是重复当前实现，也很有帮助。如果把错误行为原样写成期望值，即使测试通过，原问题也未解决。对于说明用保存错误，应以用户可见结果为标准，检查“关闭选项后再次读取仍保留false”。如果能确认相同案例在修改前代码中失败，回归验证依据会更明确。但如果没有实际运行修改前状态，不应在报告中编造这种结果。

提出具体的后续请求

与其只说不喜欢整体结果，不如指出已经检查的行及影响。例如：“读取选项值的条件尚未说明空字符串政策。请核实当前输入定义，保持保留false和0的意图，仅整理空字符串处理。不要修改登录或包版本。重新记录相关输入表与验证结果。”这一请求缩小了剩余判断，而不是广泛委托新功能。

也应要求Codex的审查结果区分推测与实际复现。“可能发生”的意见，需要核实是否存在能够到达该位置的条件。如果能说明真正导致问题的输入与调用路径，就更容易判断修改。反过来，仅代码风格偏好不同的意见，可以与当前错误修复分开。审查结束后，应重新阅读后续修改的diff，核实是否新增了与初始问题无关的修改。

二进制或生成文件发生修改时

图像和文档等二进制文件，仅凭文本diff难以充分检查内容。应实际打开文件，查看尺寸、版式与内容是否按预期变化。锁定文件和自动生成文件，则需同时核实源配置与生成过程。不要因为变化行多就全部忽略，也不要仅因行多就认定全部危险。把变化与产生它的命令或源配置关联起来，便于整理审查对象。

文件重命名和移动也需检查。即使内容相同，文件移动仍可能影响相对路径或import路径。应检查文档链接、测试路径与部署配置是否引用旧位置。可以要求AI：“请将文件移动与内容修改分开说明，并核实引用旧路径的位置。”如果尚未验证移动后的行为，不应仅凭文件存在就写成完成。

接受结果前的最后检查

最终应核实原问题是否不再复现、应保持的行为是否仍然保留，以及实际修改文件是否与结果摘要一致。在进入提交或部署等下一步之前，也要阅读未能验证的项目。“审查完成”应表示检查了约定范围的结果，而不是保证不存在任何可能缺陷。判断是否接受代码修改，需要diff、输入案例与执行结果相互关联。

diff过长怎么办？ 先整理各文件目的，从真正改变行为的部分开始阅读。必要时，要求分离格式修改。 只看AI生成的修改就够了吗？ 用户修改与公共代码会共同运行，因此还应检查仓库当前状态。 检查通过，但界面不同，应看什么？ 比较检查环境与实际界面的设置、数据和构建是否相同，再补充遗漏的复现条件。

官方资料与撰写依据

• OpenAI代码审查指南
• Git官方git-diff指南

这是借助AI撰写的信息类文章。官方文档于2026年10月3日核查，以下示例为说明而设计，并不代表真实个人项目的执行成果或实测值。发布前会再次核实产品说明是否发生变化。

审查Codex的修改

1. 核实比较基准

→

2. 整理各文件目的

→

3. 同时阅读删除行与新增行

→

4. 核实不同输入的变化

→

5. 对照检查结果

这是自行制作的说明用流程图，并非实际产品界面或测量结果。