最近 review 了一个订单模块的并发处理逻辑，代码不长，但涉及锁粒度、异步回滚和超时降级，凭眼睛扫一遍很容易漏掉时序上的边界情况。我决定先让 AI 把代码里的并发风险点标出来，自己再做判断。

为什么选这个场景试 AI

代码 Review 里有两类工作：一类是风格和规范检查，Lint 和静态扫描工具已经做得很好了，不需要 AI；另一类是逻辑隐患排查，比如共享资源竞态、锁超时后的状态不一致、异步回调里的上下文丢失。这类问题人检查起来费时，但边界条件相对明确，属于“高风险但可验证”的任务，正好适合让 AI 先筛一轮。

我把场景锁定在并发逻辑，还因为这类 Review 有一个好处：AI 的输出对不对，可以直接用并发测试和代码走查来验证，不存在“看起来合理但实际无法判断”的灰色地带。

三个模型看同一段代码，侧重点完全不同

我贴了一段脱敏后的订单状态流转代码（约 200 行，涉及 Redis 锁、异步回调、状态机切换），分别让三个模型做同一件事：“找出这段代码中潜在的并发风险点，按严重程度排序，给出复现条件和修复建议”。

DeepSeek 的输出最贴近实际工程。它标了 7 个风险点，其中有一条是关于 Redis 锁超时后状态机未回滚的问题——锁 30 秒过期，但后续业务处理花了 45 秒，锁释放后另一个请求进入，这时候前一个请求还没更新完状态。这个场景线上出过类似故障，说明模型确实捕捉到了时序漏洞。另外它在每条风险后都附了“复现条件”和“建议的修复方向”，没有直接给代码，这一点也合适——直接给代码反而不安全，因为模型不知道完整的上下文。

ChatGPT 的输出更结构化，用表格列出了风险等级、影响范围、触发概率，读起来很清晰。但它编了一个“线程池拒策略配置不当导致任务静默丢失”的问题，还给出了具体的 RejectedExecutionHandler 配置建议。这段代码里根本没有使用线程池，异步回调是走消息队列的。ChatGPT 的推理路径大概是：看到异步任务 → 假设用了线程池 → 进一步推断线程池可能没配置好。这就是在信息不足时的“合理推断”，但推断错了。

Claude 找到的风险点最多，有 11 条，覆盖了锁粒度过大、未捕获异常导致锁不释放、降级路径里的幂等校验缺失等。但有几条的前提条件和我们实际的技术栈不一致，比如它假设了 Redisson 的看门狗机制自动续期，而我们用的是 Jedis，没有续期逻辑。这 11 条里能直接用的大概 7 条，剩下的要么改前提条件，要么标记为不适用。

三个模型独立输出后放在一起对比，差异最大的点恰好是最需要人工细看的地方。比如“锁超时后状态不一致”这个问题，DeepSeek 和 Claude 都标了，但两家的复现条件和修复建议不完全一样——DeepSeek 提了在状态机上加个终态校验，Claude 提了在锁过期前主动检查业务处理进度。两种思路都能解决问题，但适用场景不同，最终选哪个还得人判断。

Prompt 里的四个关键约束

第一轮我的 Prompt 写得很随意：“帮我 review 这段代码，重点看并发问题”。三个模型给出的结果都比较宽泛，类似“注意锁的使用”“注意线程安全”这种说了等于没说的话。

第二轮加了几条约束后，输出质量明显提升：

角色：你是一个 Java 后端代码 Reviewer，对并发编程、锁机制和状态机设计有实操经验。
输入材料：一段已脱敏的订单状态流转代码，约 200 行。
技术栈约束：使用 Jedis 操作 Redis 单实例，没有 Redisson 的 WatchDog 机制。
异步机制：通过 RocketMQ 发送异步回调消息，未使用线程池。
任务：找出代码中潜在的并发风险点，按严重程度排序。
对每个风险点，必须包含：
- 复现条件（精确到时序和状态）
- 对业务的影响（具体到订单状态或金额，不能说“数据不一致”这种模糊描述）
- 修复方向（只说思路，不直接给代码）
限制条件：
- 不要引入输入材料和技术栈约束中未提到的中间件或机制
- 如果某个场景因为缺少信息无法判断，标注“信息不足，无法评估”
- 不要直接改写代码
验证要求：每一条风险点必须能通过并发测试或代码走查来验证。

真正起作用的约束是这四条：技术栈限制，明确说不用 Redisson、不用线程池，直接堵住了 ChatGPT 和 Claude 的假设偏差；输出可验证性要求，强迫模型把影响描述精确到具体业务状态，杜绝“线程不安全”“可能导致数据不一致”这类空话；信息不足时的处理方式，允许模型说“不知道”，而不是硬编；禁止直接改代码，这个约束在 Review 场景下很重要，AI 给的代码改动方案往往只考虑局部逻辑，和整体架构接不上。

怎么验证 AI 标的风险点

Review 类输出的验证比代码生成更难——你不能直接“跑一下看看”，而是要对每个风险点做推理验证。

我用了三步：

第一步：逻辑一致性检查。 逐条看模型标的“复现条件”在技术栈约束下是否成立。比如 Claude 提了“Redisson 看门狗续期失败导致锁提前释放”——我们没用 Redisson，这条直接排除。

第二步：并发测试验证。 对风险等级最高的 3 个问题，写了针对性的并发测试用例，用 JUnit 配合 CountDownLatch 模拟多线程竞态场景，看能否复现。DeepSeek 标的那条锁超时状态不一致，用两个线程加人工断点确实复现了，证明这个问题真实存在。

第三步：多模型交叉验证。 把三个模型的输出放在一起，对比差异。两个以上模型都标了的问题，优先级提升；只有一个模型标了的问题，检查它是否基于错误假设；三个模型都没标的问题，人再扫一遍确认是否有遗漏。

三步走下来，从 11 + 7 + 11 条原始风险点中，最终确认了 8 条有效问题，其中 2 条属于 P0 级别需要立即修，3 条 P1，3 条 P2。这个产出比单人 Review 漏掉的情况要少，但不是“交钥匙”级别的自动化。

代码 Review 场景下 AI 的适用边界

经过这次实践，我对“AI 辅助 Review 适合做什么”有了更清晰的判断：

适合做的： 并发时序分析、锁粒度和锁超时边界排查、状态机流转中遗漏的异常路径。这些任务的共同特点是边界条件相对明确，推理链条可以线性展开，输出结果可以比较明确地判断对错。

不适合做的： 架构合理性判断（微服务怎么拆、缓存策略选 Redis 还是本地）、需要完整业务上下文的任务（这段代码会不会影响某个特殊客户的流程）、风格和规范检查（工具比 AI 更快更准）。

风险最大的行为： 让 AI 直接给修复代码然后抄进去。模型看不到全量代码，它的改动方案往往在局部最优，全局可能引入更多问题。

常见误区

Q：AI Review 能替代人工 Review 吗？

不能。AI 适合做第一轮风险初筛，帮 Reviewer 把注意力集中在高风险区域。但它会漏问题，也会编造问题，最终判断必须靠人。

Q：为什么同一个代码三个模型输出差这么多？

因为它们在信息不足时的推理策略不同。DeepSeek 偏保守，信息不够就聚焦已明确的约束；ChatGPT 偏积极，会基于常见工程实践补充推断；Claude 覆盖面广但有时忽略技术栈限制。这种差异本身也是有用信息——差异越大的点越值得人工细看。

Q：公司代码可以直接贴给 AI 吗？

绝对不能。必须脱敏，替换掉真实业务字段、配置参数、内部 API 路径和域名。涉密逻辑建议抽象化描述后再提问。

Q：AI 标的问题怎么判断是不是真的？

两条原则：复现条件在你当前技术栈下是否成立，能否用并发测试或代码走查验证。满足不了这两条的问题，要么排除，要么标记为“待确认”。

总结

这次用 AI 辅助并发代码 Review 的实践可以总结成一条：把模型当成“风险点定位器”，而不是“评审意见签字人”。

从最小切口入手——选一个逻辑密度高但边界清晰的模块，用约束清晰的 Prompt 限定技术栈、输出格式和禁止假设的范围，让模型标出风险点并按严重程度排序。输出后走一条固定验证流程：逻辑一致性过滤 → 高优先级问题并发测试复现 → 多模型交叉对比差异 → 人工终审。三个模型各有所长，DeepSeek 在中文工程场景的推理最实际，ChatGPT 结构化工整但要防幻觉，Claude 覆盖广但需要过滤技术栈不匹配的部分。差异最大的地方就是最值得人工细看的地方。

所有贴给 AI 的代码必须脱敏，AI 输出的修复建议不能直接抄进代码库，最终评审结论和修复方案必须由人确认。安全边界不是限制 AI 的使用，而是让 AI 真正融入研发流程的前提。