如何请求Codex代码审查：寻找错误的提示词与验证检查

摘要： 好的代码审查请求说明比较哪些修改、寻找什么问题。出现审查意见，并不意味着错误已经确定，应同时核对依据与复现条件。

1. 在“请审查”中补充比较对象

开始审查时，应指定读取一个文件、查看未提交变更，还是比较基准分支与当前修改。范围不同，包含代码与判断标准也不同。审查结束后，宜在结果中确认实际采用了什么比较范围。

OpenAI官方代码审查文档区分检查Git检出变更的/review，与处理pull request的Code Review流程。官方将本地/review说明为报告有优先级意见、但不修改工作文件的审查流程。具体选项请在自己使用的应用、CLI与IDE中确认。

2. 先询问实际行为，再看风格

如果同时评价缩进与变量名，重要缺陷可能混在轻微偏好中。假想购物车修改，可依据“数量为0是否删除”“是否可能按旧价格付款”等行为确定审查范围。

还需区分原有问题与本次变更新增的问题。发现问题位于修改行附近，并不能证明由该修改造成。要求审查结果包含发生条件、代码依据、用户影响与本次变更的关系，更容易判断。

3. 可直接应用的审查提示词

현재 브랜치의 장바구니 변경을 지정한 기준 브랜치와 비교해 주세요.
이번 변경으로 생길 수 있는 동작 오류와 회귀를 우선 검토해 주세요.
특히 수량 0, 중복 클릭, 응답 실패 상황을 살펴봐 주세요.
이 요청에서는 코드를 수정하거나 PR 댓글을 게시하지 마세요.
각 지적에 파일 위치, 발생 조건, 근거, 예상 영향을 포함해 주세요.
확인된 사실과 추가 검증이 필요한 가능성을 구분해 주세요.
검토 범위와 직접 확인하지 못한 부분도 알려 주세요.

基准分支必须指定仓库实际名称。不知道是否使用main时，不能照搬示例。尚不了解仓库，可先请求说明可用分支与当前变更，再确定范围。此示例是请求模板，并非特定项目实际审查结果。

4. 将一条意见转化为可验证任务

例如收到“重复点击可能添加商品两次”的意见，应先询问在哪种状态发生。可查看按钮是否已禁用、服务器是否处理重复请求，以及复现所需时机。区分它是未读取周边代码的推测，还是存在具体路径。

중복 추가 지적의 재현 조건을 확인해 주세요.
관련 호출부와 중복 방지 처리가 있는지 살펴보고
현재 코드에서 가능한 경로와 아직 확인하지 못한 조건을 설명해 주세요.
결함이 확인되면 최소 수정안과 필요한 검증을 제안해 주세요.

审查与修改目标不同。确认问题后再委托修改，可减少不必要变更。多条意见中有些被证实基于错误假设时，应在后续请求写明，避免重复相同推测。

5. 审查结束后的检查清单

• 比较范围： 确认是所需分支或变更集合。
• 代码依据： 检查当前文件对应位置是否与意见一致。
• 复现条件： 区分正常与错误输入，确认实际是否可能发生。
• 验证结果： 分开已执行测试与尚未确认的行为。
• 最新状态： 审查后代码变化时，确认旧意见是否仍适用。

以PR评论分享时，也应重新检查代码位置与依据。官方文档说明，对话中审查，与实际发布评论或批准、合并，是不同操作。先将意见整理为草稿，可减少把未确认可能性当成确定缺陷传递的情况。

6. 使用/review前阅读变更范围

本地审查先读取仓库状态，可减少对象错误。以下命令用于查看Git仓库当前变更与分支。如果输出文件包含他人工作中的修改，应区分是否纳入审查。当前可见的全部变更，并非都由Codex创建。

git status --short
git diff --stat
git diff --cached --stat
git branch --list

官方CLI文档的/review介绍了选择基准分支、未提交修改、特定提交与自定审查标准的流程。CLI未提交变更审查包括staged、unstaged与untracked文件。因此不能认为已暂存文件会遗漏，或新文件不会审查。应阅读所用界面的范围，并在结果保留选择范围。

希望查看的对象	选择标准	特别注意事项
当前修改中的工作	未提交变更	是否包含其他工作者修改
整个功能分支	与实际基准分支比较	基准是否最新且符合意图
一组修改	特定提交	是否还需要前后提交背景
调查特定风险	明确相关路径与审查标准	是否遗漏调用位置就下结论

不知道基准分支时，不要猜名称，应先阅读仓库分支列表与团队工作方式。确定审查对象后再运行/review。阅读意见前先确认范围，更容易了解意见比预期多或少的原因。

7. 用假想代码审查数量0错误

以下是假想审查练习代码。假设购物车政策为“数量0则删除项目”，并非真实项目运行代码或已发现缺陷。产品数量政策不同，结论也不同，应与要求一起阅读。

function normalizeItem(input) {
  return {
    productId: input.productId,
    quantity: input.quantity || 1
  };
}

此示例中，||可能将0变成默认值1。只阅读代码即可说明该转换，但要得出实际购物车保存错误的结论，必须确认函数何时调用。数量0请求若通过专门删除路径处理，不进入该函数，可能不影响用户删除操作。此区别是审查中区分推测与缺陷的关键。

가정한 요구사항: 수량 0 요청은 항목을 삭제합니다.
normalizeItem의 기본값 처리와 실제 호출 경로를 함께 검토하세요.
0이 1로 바뀌는 경로가 삭제 요청에서 도달 가능한지 확인하세요.
다른 계층에서 0을 처리한다면 해당 근거를 제시하세요.
도달 여부를 확인할 수 없다면 결함으로 확정하지 말고 필요한 자료를 적으세요.

也可预先确定预期意见形式。不是“默认值运算符不好”，而是写明条件，例如“数量0删除请求进入此函数的路径中，会被规范为1，可能导致项目残留”。修改建议应区分0、缺失值、负数与正常正数。仅将||换成其他运算符，并不代表实现完整数量政策。

8. 将意见分为事实、假设与验证计划

审查句子的依据层级不同。“该函数将0改为1”是对示例代码行为的解释；“删除请求进入该函数”需要确认调用路径；“用户商品残留”是产品整体结果，还需保存与响应路径。区分依据层级，可了解在哪个阶段需要额外资料。

项目	良好报告内容
发生条件	数量0请求经过规范化函数时
代码依据	对应文件、函数与调用路径
预期行为	当前要求规定的删除处理
确认方法	数量0请求后检查保存结果或响应
剩余条件	其他层级是否处理删除等

리뷰 지적을 다음 항목으로 다시 정리해 주세요.
발생 입력, 기대 동작, 코드 근거, 사용자 영향, 이번 변경과의 관계.
직접 실행한 재현이 있으면 명령과 결과를 적으세요.
실행하지 않았다면 코드 해석과 검증 계획으로 표시하세요.
호출부나 요구사항이 부족한 지적은 필요한 자료를 구체적으로 남기세요.

优先级也应根据影响判断。阻止正常订单或错误保存数据，应优先于变量命名偏好。但措辞描述严重影响，并不证明严重缺陷已确定。需同时检查可复现性、实际使用路径与受影响输入。小重构收到推测全服务故障的报告时，宜重新请求连接依据。

意见错误时，不应只说“已有处理”，应记录哪个路径与验证反驳该假设。例如删除请求单独处理、不调用此函数，应关联相应代码与测试。也可补充要求或调用结构说明，避免下次重复误解。

9. 延续至修改后复审与PR分享

缺陷确认后，只修改必要部分并执行相关验证。数量示例除0外，还需检查值缺失与正常正数，以发现默认值变化的副作用。将测试预期改成符合当前代码前，应重新确认产品政策。修改后，也需检查旧审查位置与说明是否仍符合最新文件。

확인된 수량 0 결함을 최소 범위로 수정해 주세요.
값 누락·0·정상 양수 입력의 기존 정책을 구분해 주세요.
관련 테스트를 실행하고 변경된 동작과 보존한 동작을 보고하세요.
수정 후 동일 경로를 다시 검토해 새 문제나 빠진 조건을 찾아 주세요.
아직 확인하지 못한 통합 동작은 별도로 표시하세요.

分享至PR时，应以验证事实整理草稿，而非直接粘贴意见。好的评论简短连接触发输入、预期结果、当前代码产生不同结果的原因与需确认验证。未执行的复现不能写成“已确认”。下一模板可按验证程度调整。

수량 0 요청이 이 정규화 경로를 거치면 기본값 1로 바뀔 수 있습니다.
현재 요구사항은 0에서 삭제하는 동작이므로 호출 경로를 확인해 주세요.
[검증한 근거 또는 아직 필요한 검증]을 기준으로
0과 값 누락을 구분하는 처리 및 관련 사례 추가를 제안합니다.

官方Code Review指南区分对话中审查，与实际评论发布、提交审查。阅读草稿，确认文件位置与最新diff一致后再分享。审查后加入修改提交时，应重新阅读变化范围，不能直接将旧结果作为最终判断。重要的是理解实际变更，优先解决可确认缺陷，而不是意见数量。

10. 常见问题

没有意见就说明代码安全吗？ 只表示在已审查范围未发现问题，不能解读为证明所有环境与输入的行为。

Codex审查可替代人工吗？ 可帮助理解变更与寻找遗漏案例，但了解服务要求与运营背景的负责人应能作最终判断。

测试通过也需要审查吗？ 测试检查已编写案例；审查遗漏案例或目的与代码不一致，则回答其他问题。重要修改宜同时阅读两种结果。

官方来源与确认日期： OpenAI官方文档：代码审查。2026年10月3日确认。使用命令与功能前，请确认当前环境与权限。