Codex 代码审查：让 AI 先找风险，不急着改

先定目标

代码审查不是挑毛病，而是提前找风险

很多团队一听到代码审查，就想到开发同事互相看代码：命名好不好、写法优不优雅、有没有少写测试。对老板、产品经理和业务负责人来说，这个理解太窄了。真正有价值的代码审查，不是为了证明谁写得不够好，而是在上线前问一句：这次改动会不会让客户付不了款、员工看不到数据、旧链接打不开、权限被绕过、页面看似正常但实际没保存。

你可以把代码审查理解成上线前的风险体检。医生不会只看你衣服整不整齐，而是看关键指标有没有异常。代码审查也一样，重点不是把代码变漂亮，而是确认业务行为有没有变、边界条件有没有漏、测试有没有覆盖、上线后出了问题能不能发现和止损。

这篇教程训练的是一种工作能力：让 Codex 先做代码审查，帮团队找风险、分级、解释影响、列出检查项，而不是一上来就让 AI 改代码。读完后，你应该能带走一套代码审查工作产物：一份 P0-P3 风险清单、一份测试缺口表、一份上线前老板验收摘要，以及几段可以直接复制给 Codex 的审查模板。

真实困境

最危险的上线，往往不是大改版，而是小改动

真实工作里，很多事故不是来自惊天动地的大项目，而是来自一句轻描淡写的需求：按钮文案改一下、表单字段加一个、列表排序调整一下、登录判断顺手优化一下、优惠券规则补个条件。因为大家觉得小，所以审查少；因为审查少，所以隐藏风险更容易溜过去。

比如一个产品经理说：“注册页多加一个手机号字段。”听起来只是加字段，但后面可能牵连校验规则、老用户资料、隐私说明、短信发送、后台导出、客服查询、数据分析埋点。如果只看页面能不能显示，没看保存、权限、导出和异常状态，上线后就可能变成客服工单。

Codex 在这里的价值，不是替团队拍脑袋决定上线，而是帮你把“看起来小”的改动拆开：它到底改了哪些行为？谁会受影响？空值怎么办？旧数据怎么办？测试有没有覆盖？如果失败，用户会不会知道？这些问题一旦被问出来，小改动就不再靠运气上线。

错误做法

别让 AI 一边审查一边顺手改

很多人第一次让 Codex 看代码，会说：“帮我 review 一下，有问题就改。”这句话很顺口，但风险很高。因为审查和修改是两种不同工作。审查要保持观察者视角，先完整列出风险；修改要进入执行者视角，选择一个方案并改变代码。两件事混在一起，AI 很可能发现一个问题就动手修，修完又引入新的变化，最后你反而不知道原始风险是什么。

更稳的做法是分两轮。第一轮只审查，不写文件。让 Codex 输出行为变化、风险分级、测试缺口和人工确认项。第二轮由负责人决定哪些必须修、哪些可以接受、哪些需要延期。只有确认修复范围后，才让 Codex 做最小修改。

这不是降低效率，而是提高可控性。就像财务审计不会一边发现问题一边自己改账，代码审查也不应该一边发现风险一边自由改动。先把风险摊开，团队才有共同判断；先把判断做完，修改才不会越界。

• 审查阶段：只读、分析、归类、解释影响。
• 决策阶段：负责人判断哪些风险阻塞上线。
• 修改阶段：只修确认过的问题，避免顺手重构。
• 复查阶段：确认修复是否覆盖风险，没有扩大影响。

本质解释

代码审查的本质：检查行为变化，而不只是检查代码写法

对非技术读者来说，最重要的概念是“行为变化”。它的大白话意思是：用户、管理员、系统和数据在这次改动后会不会变得不一样。按钮换颜色是行为变化吗？通常不是核心行为。点击按钮后原来保存成功，现在可能保存失败，这就是行为变化。原来普通员工看不到财务数据，现在因为权限判断改错能看到了，这就是严重行为变化。

代码只是行为的原因，业务结果才是团队关心的后果。审查时，如果只盯着代码语法和风格，就可能错过真正的风险。比如一行条件判断写反了，代码看起来很短，但可能让所有未登录用户进入后台；一个默认值从 false 改成 true，看起来不起眼，却可能让通知重复发送。

所以你要训练 Codex 做的第一件事，不是评价代码漂亮不漂亮，而是复述这次改动改变了哪些业务行为。它要能说清楚：谁会看到变化，什么时候触发变化，数据会怎么变，失败时会怎么样，旧流程是否还在。只要行为变化讲清楚，后面的风险分级、测试设计、老板验收才有基础。

AI 分工

Codex 能查什么：线索、证据、边界和缺口

Codex 很适合做代码审查里的“材料整理”和“风险侦查”。它能读改动文件，比较前后差异，顺着函数和组件找调用关系，发现可疑的边界条件，查看有没有测试，推测哪些页面或接口可能受到影响。对团队来说，它像一名耐心的审查助理，能把散在各处的线索整理成一份风险清单。

它还擅长把技术线索翻译成工作语言。比如它看到权限判断被改了，可以提醒“这可能影响谁能看到某类数据”；看到错误处理被删了，可以提醒“失败时用户可能以为已经成功”；看到测试只覆盖正常输入，可以提醒“空值、重复提交、网络失败没有覆盖”。这类翻译对老板和产品经理很有用，因为大家讨论的不再是代码细节，而是上线风险。

但是你要给 Codex 明确任务。不要只说“review 一下”。你要要求它输出行为变化、风险分级、证据位置、测试缺口、上线建议和人工确认项。输出格式越清楚，它越容易把注意力放在真正要验收的东西上。

• 查行为变化：这次改动让系统表现哪里不同。
• 查影响范围：哪些页面、接口、组件、数据流程会受影响。
• 查边界条件：空数据、异常输入、权限不足、重复提交、网络失败。
• 查测试缺口：已有测试覆盖什么，漏掉什么。
• 查上线风险：是否会影响客户、数据、收入、权限、可用性。

责任边界

Codex 不能负责什么：承诺、取舍、上线决定

AI 可以帮你发现风险，但不能替负责人承担风险。它不知道公司今天的业务优先级，不知道这个客户是不是战略客户，不知道某个缺陷是否可以通过客服临时兜底，也不能对生产事故负责。它给出的“建议上线”只能作为参考，最终决定必须由人做。

AI 也不能替你确认事实。它可以根据代码推断“这个改动可能影响老用户”，但老用户真实数据长什么样、生产环境配置是否一致、第三方接口当前是否稳定、上线窗口是否合适，这些都需要人或真实系统来确认。尤其是支付、权限、财务、隐私、删除、批量操作这类场景，不能只靠 AI 的文字判断。

最稳的分工是：Codex 负责找证据、列风险、解释影响、提出检查建议；开发负责确认技术判断和修复方案；产品或业务负责确认业务取舍；测试负责验证关键路径；老板或技术负责人负责上线拍板。边界清楚，AI 才能成为放大器，而不是替罪羊。

开始前准备

审查前先准备四类材料

一次有效的代码审查，不能只把代码丢给 Codex。你至少要准备四类材料。第一类是业务背景：这次改动解决什么问题，面向谁，为什么现在要做。第二类是改动范围：PR、提交、分支、文件列表，或者明确“只看最近改动”。第三类是验收标准：什么叫成功，哪些场景必须正常。第四类是上线约束：什么时候上线，是否有回退方案，哪些风险不能接受。

没有背景，AI 容易把低优先级问题说得很严重，也可能忽略真正的业务命门。比如同样是页面加载慢，内部后台可以接受两秒，支付页可能一秒都嫌长。同样是文案错误，草稿页是 P3，合同确认页可能就是 P1。风险等级不是单看代码决定，而是由代码位置、业务场景和影响人群共同决定。

你不需要写很长的需求文档，一段清楚的背景就够。告诉 Codex：这是给谁用的，改动准备什么时候上线，最不能出什么问题，哪些文件只是顺带变化，哪些流程是核心路径。AI 有了这些上下文，审查结果就会更像工作报告，而不是泛泛而谈的代码点评。

第一步

先让 Codex 只读审查，输出一份风险草稿

第一轮审查的重点是“先看全貌”。你可以让 Codex 读取相关改动，但明确不要修改文件。它应该先概括这次改动做了什么，再列出可能影响的页面、接口、数据、权限和用户流程。这个阶段不追求马上修复，而是尽量把风险暴露出来。

好的风险草稿应该有证据。比如不要只写“可能有权限问题”，而要写“某个页面的权限判断从服务端移到客户端，业务影响是用户可能先看到不该看到的数据，建议确认服务端接口是否仍有权限校验”。这样的表达，老板能理解，开发也能定位。

如果 Codex 在第一轮就想改文件，你要把它拉回来：“先不要修，请先完成审查报告。”这个动作很关键。先让风险清单完整，再决定修改优先级。否则它可能把一个 P2 修得很漂亮，却漏掉真正阻塞上线的 P0。

我要让 Codex 做一次代码审查，请先不要修改任何文件。

业务背景：
[说明这次改动服务什么业务目标，谁会受到影响，是否准备上线]

本次审查范围：
[写清分支、提交、PR、文件范围，或说明只审查最近改动]

请按下面结构输出：
1. 这次改动一句话说明
2. 行为变化：用户、管理员、系统流程会看到什么变化
3. 风险列表：按 P0/P1/P2/P3 分级
4. 边界条件：空数据、异常输入、权限、并发、网络失败等
5. 测试缺口：已有测试覆盖了什么，还缺什么
6. 上线风险：是否可能影响旧数据、旧链接、支付、权限、SEO、性能
7. 需要人工确认的问题

要求：
只做审查，不修改文件；每个风险尽量给出文件路径或代码位置；不确定时明确写不确定。

第二步

用 P0-P3 分级，把风险变成可决策语言

风险不分级，团队就很难决策。有人会觉得“这个问题不优雅”，有人会觉得“上线会死”。P0-P3 的作用，是把讨论从情绪变成标准。P0 是绝对不能带上线的风险，比如资金损失、数据泄露、权限绕过、大面积不可用、错误删除。P1 是核心流程高概率出问题，上线后很可能紧急修。P2 是局部功能或边界条件问题，有绕行办法但需要排期处理。P3 是轻微体验、文案、样式或可维护性问题。

分级时一定要用业务影响解释，而不是只用技术严重性解释。一个代码写法不优雅，通常不是 P0；一个看起来很小的权限条件，却可能是 P0。一个后台筛选条件错了，如果只影响内部运营一天查数据，可能是 P2；如果导致客户看到错误账单，可能升到 P1 甚至 P0。

让 Codex 按 P0-P3 输出后，你再让负责人确认等级。AI 的分级是初稿，不是判决书。真正的价值是让所有风险有统一语言：哪些阻塞上线，哪些上线前必须修，哪些可以记录为后续优化。

• P0：不能上线，可能造成重大损失或不可接受后果。
• P1：建议阻塞上线，核心流程或重要客户会受影响。
• P2：可以评估上线，但需要明确绕行方式和后续修复。
• P3：不阻塞上线，记录为体验或维护优化。

请把审查发现按 P0-P3 分级。

分级标准：
P0：可能导致资金损失、数据泄露、权限绕过、大面积不可用、错误删除或无法回退。
P1：可能导致核心流程失败、重要客户受影响、上线后必须紧急修复。
P2：可能导致局部功能异常、边界条件出错、体验明显下降，但有绕行方式。
P3：文案、样式、小范围可维护性、轻微体验问题，不阻塞上线。

输出格式：
- 等级
- 风险标题
- 业务影响
- 证据位置
- 建议处理方式
- 是否阻塞上线

第三步

审查行为变化：页面正常不代表业务正常

很多上线事故有一个共同特点：页面看起来没坏，但业务已经变了。比如用户点了提交，按钮显示成功，但数据没有保存；管理员看到订单列表，但排序口径变了；客户收到了通知，但重复收到两次；表单能打开，但老用户资料无法编辑。页面正常，只说明表层没有崩，不能证明业务正确。

所以你要专门让 Codex 审查行为变化。它应该分别说明用户、管理员、系统数据和异常状态会发生什么变化。尤其要看静默失败：系统出错了，但用户没有看到错误；权限失败了，但页面仍显示成功；请求失败了，但前端状态提前更新了。这类问题最麻烦，因为上线后不一定马上报警，往往要等客户投诉才发现。

行为变化审查也能帮助产品经理写验收用例。比如“创建订单后，列表立刻出现新订单；刷新后仍存在；失败时显示错误；重复点击不会生成两笔订单”。这些句子比“测试订单功能”更清楚，也更容易交给 QA 或业务同事验证。

请只审查这次改动带来的行为变化。

请分别说明：
1. 用户会看到什么变化
2. 运营或管理员会看到什么变化
3. 系统数据会如何变化
4. 错误、空状态、加载中、权限不足时会如何表现
5. 旧流程是否仍然可用
6. 是否存在静默失败：页面看似正常，但数据没有保存或状态没有更新

请把技术判断翻译成业务语言，不要只说代码实现。

边界条件

边界条件就是“平时没事，一出事就暴露”的地方

边界条件的大白话解释是：正常情况以外的情况。比如没有数据、数据太多、字段为空、用户没权限、网络失败、重复点击、并发提交、时间跨月、手机号格式特殊、老数据缺字段、第三方接口超时。很多功能在正常演示时都没问题，但一遇到边界条件就出事故。

让 AI 审查边界条件时，不要只问“有没有 bug”。你要按业务场景追问。支付场景要问重复扣款、回调失败、金额精度、退款状态；权限场景要问未登录、低权限、离职账号、分享链接；内容场景要问空标题、重复 slug、旧链接、特殊字符；数据导入要问空行、重复行、格式错误、半途中断。

边界条件不是为了把测试做得无限大，而是为了找出最值得检查的异常。一个内部文案页面，不需要像支付系统那样审查每个失败分支；但只要涉及钱、权限、客户数据、删除、批量操作，就要把边界条件当成上线前重点。

测试缺口

测试缺口不是“没写测试”，而是“关键风险没人验证”

很多团队讨论测试时容易走偏：有没有单元测试、覆盖率多少、自动化够不够。对业务负责人来说，更直观的问题是：最关键的风险有没有被验证？如果一个支付改动有很多样式测试，却没有验证重复支付，那测试数量再多也不安心。如果一个权限改动只测了管理员，没有测普通用户，那核心风险仍然没覆盖。

Codex 可以帮你找已有测试，也可以帮你判断测试缺口。它应该先看项目里有没有测试文件、检查命令、端到端测试或脚本，再对照风险清单判断：哪些 P0/P1 风险没有测试，哪些边界条件只能手工验收，哪些需要补自动化，哪些今天上线至少要人工点一遍。

测试缺口的输出最好分成三层。第一层是机器能自动检查的，比如构建、类型、单元测试。第二层是人工要验证的，比如真实页面流程、表单保存、权限切换。第三层是业务负责人确认的，比如文案承诺是否准确、报表口径是否符合管理定义。这样测试就不再是开发一个人的事，而是上线共同责任。

请做一次测试缺口审查。

请先找已有测试、脚本和检查命令，再判断缺口。

输出格式：
1. 已有测试或检查：覆盖了哪些风险
2. 未覆盖风险：哪些关键路径没有测试
3. 建议补充测试：单元测试、集成测试、端到端测试、手工验收分别需要什么
4. 最小上线检查：如果今天必须上线，至少要人工验证哪些场景
5. 不能只靠 AI 判断的地方：需要负责人、QA、产品或业务方确认什么

上线风险

上线风险要问三件事：影响谁、能否发现、能否回退

代码审查最后一定要落到上线风险。一个问题是否阻塞上线，不只看它有没有 bug，还要看影响谁、能不能快速发现、能不能回退。如果只影响内部一个低频页面，且有人工绕行方式，可能可以记录为 P2。如果影响所有客户付款，且失败后没有告警，那就是必须阻塞的高风险。

让 Codex 审查上线风险时，要特别关注几类业务红线：支付和金额、客户数据、权限和隐私、删除和批量修改、旧链接和 SEO、核心转化路径、通知和消息、报表口径、登录和注册。这些地方一旦出问题，影响不只是代码，而是收入、信任、客服压力和团队信誉。

还要问回退。上线后如果发现问题，能不能关开关、回滚版本、恢复数据、暂停入口、临时隐藏功能？AI 可以帮你提出止损建议，但真正的回退方案需要团队确认。没有回退能力的改动，审查标准应该更高。

• 影响谁：全部用户、部分客户、内部同事、还是低频访客？
• 怎么发现：有监控、报错、日志、客服反馈，还是只能靠人肉检查？
• 怎么止损：能回滚、能关开关、能恢复数据、能暂停入口吗？
• 谁拍板：开发、产品、QA、老板或业务负责人是否都知道剩余风险？

老板验收

老板不看代码，也能验收一次代码审查

老板或业务负责人不需要读懂每一行代码，但必须能验收审查是否靠谱。最简单的办法是看审查报告有没有回答五个问题：这次改动做了什么？最严重的风险是什么？这些风险会影响客户、收入、数据还是团队效率？哪些风险已经被测试覆盖？剩下哪些需要人工确认或延期处理？

不要接受“已 review，无明显问题”这种汇报。它太空了，没有证据，也没有责任边界。更好的汇报应该像这样：“本次改动影响注册表单和后台用户详情。未发现 P0；有一个 P1 是老用户缺手机号时可能保存失败，建议修复后再上线；两个 P2 是错误提示不清楚和导出字段未同步；已有构建和表单测试通过，但还需要产品手工验证老用户编辑流程。”

老板验收的重点不是替开发做技术判断，而是确认风险有没有被说清，剩余风险有没有负责人，是否符合业务承受能力。只要报告能支持“上、不上、修完再上”的判断，它就是一份有用的审查结果。

请用老板或业务负责人的视角，给这次代码审查做一份上线前验收摘要。

请回答：
1. 这次改动解决了什么业务问题
2. 最重要的三个风险是什么
3. 哪些风险已经被测试或检查覆盖
4. 哪些风险还需要人工确认
5. 是否建议上线：可以上线 / 修完再上线 / 暂停上线
6. 如果上线后出问题，最可能出在哪里
7. 有没有回退或止损建议

要求：
不要只写技术名词；把影响说成客户、收入、数据、团队工作量、品牌信任这类业务语言。

案例一

案例一：优惠券功能上线前，AI 发现重复领取风险

一家电商团队准备上线新优惠券功能。产品经理的需求很简单：新用户可以领取一张满减券。开发完成后，页面演示正常，用户点击领取，页面显示成功，后台也能看到券记录。团队原本准备当天上线。

负责人让 Codex 先做只读审查。Codex 顺着领取按钮找到接口逻辑，发现正常领取路径有判断，但重复点击和并发请求没有明确防护。它把风险翻译成业务语言：如果用户快速点击多次，或两个请求同时到达，可能生成多张优惠券。这个问题如果发生，会直接影响营销成本，因此被标为 P1，接近 P0，建议上线前修复并补充测试。

人做了什么？产品确认每个新用户只能领一张，开发加了服务端唯一约束和重复请求处理，测试补了重复点击和并发场景。老板验收时不需要看实现，只看三件事：同一用户重复点击只得到一张券；失败时页面提示清楚；后台不会出现重复券。Codex 没有替团队决定上线，但它让一个演示时看不出来的风险提前暴露。

案例二

案例二：后台权限调整，AI 把技术问题翻译成数据泄露风险

一个 SaaS 团队调整后台菜单权限。开发同事认为只是把某个菜单从旧权限系统迁到新权限系统，页面能打开，管理员账号测试正常。但 Codex 审查时没有只看管理员，它追问了普通员工、部门主管、外包账号和过期账号的访问路径。

Codex 发现一个关键问题：前端菜单隐藏了入口，但后端接口仍可能返回数据。如果低权限用户知道接口地址，可能绕过菜单看到不该看的客户列表。它把这个问题标为 P0，因为影响客户数据和权限边界。这个判断不是因为代码复杂，而是因为业务后果不可接受。

团队最后做了两件事。第一，后端补服务端权限校验，不能只依赖前端隐藏菜单。第二，测试账号增加四类角色：管理员、主管、普通员工、无权限账号。上线前老板验收的是“低权限账号无论从页面还是接口都拿不到客户数据”，而不是“菜单看起来隐藏了”。

案例三

案例三：内容站改 slug，AI 提醒旧链接和 SEO 损失

一个内容团队想把教程 URL 改得更好看。编辑觉得 slug 只是文章地址的一小段，改完页面能打开就行。Codex 审查时先还原内容链路：slug 不只决定详情页路径，还可能被导航、学习路径、站内链接、搜索引擎收录和外部文章引用。

Codex 把风险列成业务语言：如果已发布文章直接改 slug，旧链接会 404，搜索排名可能受影响，外部分享链接失效，用户从历史邮件点击会打不开。这个问题不一定是 P0，但对内容增长网站通常至少是 P1 或 P2，取决于页面流量和是否有重定向。

人做的决定是：未发布草稿可以改 slug；已发布文章默认不改。如果必须改，要同时配置重定向、更新站内链接、检查 sitemap，并在上线后抽查旧链接。这个案例说明，代码审查不只属于后台系统。内容、SEO、链接稳定性，也同样需要上线前风险审查。

• 未发布内容和已发布内容要分开处理。
• 已发布 slug 是外部承诺，不是随便可改的文案。
• 改 URL 要同时考虑重定向、站内链接、搜索和分享入口。
• 上线后要抽查旧链接是否仍能到达新页面。

案例四

案例四：报表口径改动，AI 发现测试只覆盖了新数据

一个运营团队要调整月度报表，把“有效线索”的定义从“提交表单”改成“提交表单且手机号有效”。开发改完后，新创建的数据统计正常。但 Codex 做测试缺口审查时发现，测试只覆盖了新数据，没有覆盖历史数据和跨月数据。

这个风险的业务影响很实际：老板看月报时，可能发现本月线索突然下降，却不知道是业务变差还是统计口径变了；销售团队可能因为历史数据被重新计算而误判转化率。Codex 把它标为 P1 或 P2，取决于这份报表是否用于奖金、预算或经营会议。

团队最后补了三类验收：同一批历史数据在新旧口径下的差异说明，跨月报表的对比样例，以及报表页上的口径说明。这个案例说明，报表类改动不能只测试“算得出”，还要测试“算的口径有没有被业务理解”。

常见错误

新手做 AI 代码审查，最常见的十二个错误

第一个错误，是让 Codex 直接“有问题就改”，导致审查和修改混在一起。第二个错误，是只看代码风格，不看业务行为。第三个错误，是没有给业务背景，AI 不知道什么风险最严重。第四个错误，是没有 P0-P3 分级，所有问题堆在一起，团队无法决策。第五个错误，是把 AI 的上线建议当最终决定。

第六个错误，是只检查正常路径，不查空数据、权限、失败、重复提交和老数据。第七个错误，是只看自动测试是否通过，不看关键风险是否被覆盖。第八个错误，是把前端页面正常当成业务正常。第九个错误，是忽略日志、告警、回退和止损。第十个错误，是让 AI 顺手重构，扩大影响范围。

第十一个错误，是不保护别人改动，在多人协作时覆盖未完成工作。第十二个错误，是老板验收只听“没有明显问题”，不看证据和剩余风险。解决这些错误的方法并不复杂：先只读审查，再分级，再决定修复，再复查验证。

团队流程

把 AI 审查放进团队流程，而不是临时救火

Codex 代码审查最适合放在三个节点。第一个节点是开发自查：开发在提交前让 AI 先找明显风险和测试缺口。第二个节点是 PR 审查：团队评审前让 AI 生成风险初稿，节省人工找线索的时间。第三个节点是上线前检查：负责人只看 P0/P1、测试缺口、人工确认项和回退建议。

这三个节点的重点不同。开发自查更关注实现是否漏边界；PR 审查更关注影响范围和可维护性；上线前检查更关注业务风险和是否阻塞发布。不要把所有问题都压到最后一天。越早让 AI 找风险，修复成本越低。

团队落地时，可以约定一个简单规则：凡是涉及支付、权限、客户数据、批量操作、删除、报表口径、SEO URL、核心转化路径的改动，必须先跑一次 AI 审查模板。不是因为 AI 永远正确，而是因为这些地方不该靠记忆和经验漏检。

1. 开发提交前：让 Codex 做只读自查，先修明显问题。
2. PR 评审前：让 Codex 生成风险清单，供人工审查参考。
3. 上线前：让 Codex 输出老板验收摘要，确认剩余风险。
4. 上线后：记录漏掉的问题，更新团队审查清单。

检查清单

开始前检查清单：先确认审查有没有上下文

这张清单适合在你把任务交给 Codex 前使用。它解决的是“AI 看得太散”的问题。只要开始前上下文清楚，审查报告就会少很多空话，也更容易对齐团队真实风险。

如果你是老板或产品经理，可以把这张清单发给开发同事一起补全。如果你是开发者，可以在提交 PR 前自己补。重点不是写长文档，而是把影响范围和不能出错的地方说清楚。

检查清单

输出质量清单：一份合格审查报告应该长什么样

审查报告不是越长越好。一份合格报告应该让团队更容易决策，而不是把大家淹没在细节里。它要有摘要、有分级、有证据、有建议、有剩余风险。老板能看懂结论，开发能找到位置，产品能判断影响，测试能设计用例。

你可以用下面这张清单验收 Codex 的输出。如果报告没有行为变化、没有 P0-P3、没有测试缺口、没有人工确认项，就让它补，而不是直接进入修改。

模板库

五个可复制模板：从审查启动到老板验收

下面五个模板可以直接保存为团队提示词库。它们分别解决五个问题：怎么启动审查、怎么分级风险、怎么看行为变化、怎么找测试缺口、怎么给老板汇报。你可以单独使用，也可以按顺序跑一遍。

使用模板时，一定要补真实背景。比如“这是支付页”“这是内部报表”“这是内容站 URL”“这是客户数据导出”。同一个代码问题，在不同业务位置风险等级完全不同。模板负责提醒你问问题，背景负责告诉 AI 哪些问题最重要。

我要让 Codex 做一次代码审查，请先不要修改任何文件。

业务背景：
[说明这次改动服务什么业务目标，谁会受到影响，是否准备上线]

本次审查范围：
[写清分支、提交、PR、文件范围，或说明只审查最近改动]

请按下面结构输出：
1. 这次改动一句话说明
2. 行为变化：用户、管理员、系统流程会看到什么变化
3. 风险列表：按 P0/P1/P2/P3 分级
4. 边界条件：空数据、异常输入、权限、并发、网络失败等
5. 测试缺口：已有测试覆盖了什么，还缺什么
6. 上线风险：是否可能影响旧数据、旧链接、支付、权限、SEO、性能
7. 需要人工确认的问题

要求：
只做审查，不修改文件；每个风险尽量给出文件路径或代码位置；不确定时明确写不确定。

请把审查发现按 P0-P3 分级。

分级标准：
P0：可能导致资金损失、数据泄露、权限绕过、大面积不可用、错误删除或无法回退。
P1：可能导致核心流程失败、重要客户受影响、上线后必须紧急修复。
P2：可能导致局部功能异常、边界条件出错、体验明显下降，但有绕行方式。
P3：文案、样式、小范围可维护性、轻微体验问题，不阻塞上线。

输出格式：
- 等级
- 风险标题
- 业务影响
- 证据位置
- 建议处理方式
- 是否阻塞上线

请只审查这次改动带来的行为变化。

请分别说明：
1. 用户会看到什么变化
2. 运营或管理员会看到什么变化
3. 系统数据会如何变化
4. 错误、空状态、加载中、权限不足时会如何表现
5. 旧流程是否仍然可用
6. 是否存在静默失败：页面看似正常，但数据没有保存或状态没有更新

请把技术判断翻译成业务语言，不要只说代码实现。

请做一次测试缺口审查。

请先找已有测试、脚本和检查命令，再判断缺口。

输出格式：
1. 已有测试或检查：覆盖了哪些风险
2. 未覆盖风险：哪些关键路径没有测试
3. 建议补充测试：单元测试、集成测试、端到端测试、手工验收分别需要什么
4. 最小上线检查：如果今天必须上线，至少要人工验证哪些场景
5. 不能只靠 AI 判断的地方：需要负责人、QA、产品或业务方确认什么

请用老板或业务负责人的视角，给这次代码审查做一份上线前验收摘要。

请回答：
1. 这次改动解决了什么业务问题
2. 最重要的三个风险是什么
3. 哪些风险已经被测试或检查覆盖
4. 哪些风险还需要人工确认
5. 是否建议上线：可以上线 / 修完再上线 / 暂停上线
6. 如果上线后出问题，最可能出在哪里
7. 有没有回退或止损建议

要求：
不要只写技术名词；把影响说成客户、收入、数据、团队工作量、品牌信任这类业务语言。

复查闭环

修完以后还要复查：确认风险被消掉，而不是被挪走

代码审查发现问题后，很多团队会马上修。修是必要的，但修完还要复查。因为一个风险可能被真正解决，也可能只是从一个地方挪到另一个地方。比如为了防重复提交，前端把按钮禁用，但后端仍然没有唯一约束；为了修权限菜单，前端隐藏了入口，但接口仍然暴露数据；为了修报表口径，新数据正确了，历史数据却被误算。

复查时，让 Codex 回到原始风险清单，一条条确认：这个风险原来是什么，修复方案是什么，证据在哪里，是否补了测试，是否引入新行为变化。不要只让它看最新代码说“已修复”。要让它对照原始问题复核，这样才不会被表面变化带偏。

复查也要避免扩大范围。如果原始问题是重复提交，就不要顺手重构整个表单系统；如果原始问题是文案错误，就不要顺手改全局样式。AI 很擅长顺手优化，但团队上线最需要的是可控。先把阻塞风险消掉，再把优化放进后续计划。

课后练习

四个练习，把代码审查变成你的团队习惯

练习一：找一个最近的小改动，不让 Codex 修改文件，只让它输出行为变化和 P0-P3 风险清单。你的目标不是马上修，而是看它能不能把技术改动翻译成业务影响。

练习二：挑一个涉及表单、权限、报表或内容 URL 的改动，让 Codex 专门审查边界条件。要求它至少列出空数据、异常输入、权限不足、重复操作、老数据五类场景。然后你人工判断哪些值得上线前验证。

练习三：拿一份审查报告，让 Codex 转成老板验收摘要。你检查摘要里有没有业务目标、阻塞风险、测试缺口、人工确认项和上线建议。练习四：把团队上个月线上问题拿出来复盘，问 Codex：“如果当时用这套审查清单，哪个问题可能提前发现？”这会帮助你把清单改得更贴近团队真实事故。

1. 只读审查一个小改动，输出行为变化和 P0-P3。
2. 专项审查边界条件，把异常场景转成验收项。
3. 把技术审查报告改写成老板验收摘要。
4. 复盘一次历史线上问题，更新团队审查清单。

最后总结

让 AI 先找风险，人再决定怎么承担风险

Codex 代码审查的正确用法，不是让 AI 替你做最终判断，而是让它在你拍板前把风险尽量摆到桌面上。它能帮你读改动、找影响范围、发现边界条件、梳理测试缺口、把技术问题翻译成业务语言。它不能替你承诺上线，不能替你接受客户损失，也不能替你对生产事故负责。

这套流程的核心顺序很简单：先只读审查，再讲行为变化；先列风险，再按 P0-P3 分级；先看测试缺口，再做上线建议；先由人确认取舍，再让 AI 做最小修复；修完还要对照原始风险复查。顺序清楚，AI 才不会从审查助理变成失控执行者。

对老板来说，这篇教程的价值是让代码审查变成可管理的上线风险报告。对产品经理来说，它能把“页面能不能用”升级成“业务流程是否正确”。对开发者来说，它能提前发现漏掉的边界和测试。对团队来说，它能把一次次临时救火，慢慢沉淀成稳定的上线习惯。

• 代码审查的本质是上线前风险管理。
• AI 适合找线索和缺口，不适合替人拍板。
• 行为变化、边界条件、测试缺口、上线风险必须一起看。
• P0-P3 分级能让团队更快做取舍。
• 老板验收要看证据、剩余风险和人工确认项。