最近我干了一件挺有意思的事把 6 个 Java 商城项目逐个丢给 Codex 做代码审查想看看它到底能不能替技术负责人扛活。我没用 IDE 插件用的是 Codex CLI 的只读模式不让它自动改码纯粹把整个仓库当输入让它以技术负责人视角输出审计报告。Java 商城这个题材特别合适它既有 CRUD、又涉及订单库存支付这类强业务逻辑还很容易藏着安全问题正好拿来压测 AI 的上下文理解和代码语义分析能力。这篇文章会把我用到的提示词、扫描流程、发现的问题清单、误报排查方法全部整理出来。适合以下几类朋友看手里管着多个 Java 项目却抽不出时间逐行 review 的负责人想尝试用 AI 做代码审计、但又担心“幻觉”的开发以及对 Codex 实际能力边界好奇的读者。先给结论Codex 能做一个很努力的初级审计员但离真正的技术负责人还差好几个量级。下面说说我是怎么得出这个结论的。1. 为什么拿 Java 商城来当试刀石1.1 商城项目为什么适合压测 Codex选项目的时候我刻意没有挑小众业务系统。Java 商城在面试题里虽然看起来是 CRUD 场景但真做起来复杂度一下子就会上来商品类目、SKU、库存、订单状态机、支付回调、优惠券、退款流程任何一块都够单独写一篇分析。商城项目的代码量通常在 1 万到 6 万行之间既有单体也有微服务版本还大量依赖 Spring Boot、MyBatis/MyBatis-Plus、Redis、MQ 这套 Java 生态。Codex 对这套生态的把握明显比冷门框架好拿它来测结论才更公平。还有一个隐性原因这类商城项目线上化程度高代码缺陷一旦被利用影响会很直接。我拿到的 6 个项目质量参差有相对规范的 Spring Boot 单体也有 SSMJSP 老项目还有一个微服务版本。把不同复杂度、不同风格的项目放在一起横向对比不是只看“能不能扫出问题”而是看它能不能判断问题的优先级和影响面这才接近技术负责人真正的视角。1.2 技术负责人的审查标准是什么动手扫之前我先给自己定了一套审查标准不然没法判断 Codex 输出质量。我分五个维度架构合理性、安全性、性能、可维护性、业务一致性。架构看模块边界、循环依赖、扩展点是否合理安全看认证授权、SQL 注入、越权、支付/订单操作性能看 N1 查询、缓存失效、锁范围可维护性看分层是否清楚、异常是否统一、重复代码多不多业务一致性看状态机、金额计算、幂等是否可靠。每个问题按 P0 到 P3 评级P0 必须立刻修P1 一个迭代内安排P2 进 backlogP3 先记录观察。这套标准还有另一个作用把 Codex 的输出变成可执行清单。如果只是让它“扫一下有问题没有”大概率会得到一堆泛泛而谈的建议比如“建议增加单元测试”根本没有落地点。我后来发现提示词里明确写出“P0/P1/P2/P3”和“必须包含文件路径和行号”结果的可复现性会好很多。技术负责人平时最缺的就是这种结构化信息而不是又一个需要二次加工的文档。1.3 工具选型为什么用 Codex 而不是静态扫描做 Java 代码审计传统套路是 SonarQube、SpotBugs、PMD、FindBugs 这一批。我并不是说它们没用事实上我依然会先用 SonarQube 跑一遍规则检查它能高效抓出字符串用比较、流未关闭这类机器规则问题。但技术负责人真正要审的往往是“这段业务逻辑在并发下会不会出事”“这里的表设计是否支撑后续扩展”这类问题需要理解业务语义规则引擎给不了。Codex 这类模型代理的价值恰好在这里。Codex 和普通网页版 ChatGPT 的区别在于它能访问工作目录里的整个仓库能看到 package、import 和调用链在 CLI 连续多轮对话时还能记住前面读过什么。我用的是只读模式让它扫描后输出审计报告但不允许直接改代码。原因很简单我先要看它准不准再决定是否信任它动手。SonarQube 覆盖面广但深挖不够Codex 深挖能力强但可能幻觉两者配合起来才是完整方案。2. 扫描前的准备与提示词设计2.1 环境准备先编译、再忽略、后扫描6 个仓库拿回来后我第一步不是急着让 Codex 开工而是先解决“能不能编译”的问题。Java 项目如果连 Maven/Gradle 依赖都拉不下来Codex 读再多源代码也没有运行上下文特别容易在配置建议上翻车。我两个命令轮着跑mvn -DskipTests clean package和gradle build -x test。有一个项目依赖缺失很严重我先把依赖仓库源换成了内网能访问的通用镜像源才跑通。这里不展开具体源地址不同内网环境差异很大但思路是一致的先让工程处于可以编译的状态再谈代码审查。然后处理忽略规则。我通常在会话开始时先告诉 Codex“忽略 target、node_modules、dist、*.log、.idea 目录。”如果这些目录被一起塞进上下文很快就吃掉大量 token还会把无价值代码块混进判断。实测下来带着 target 目录扫描时Codex 偶尔会把编译产物当作源码来理解出现一些莫名其妙的疑惑。先把仓库清理干净扫描结果会稳定很多。最后按依赖关系和代码规模排扫描顺序。我的排序原则是先单体、后微服务先小工程、后大工程先核心业务模块、后周边模块。这样就算某个项目中途请求中断损失也小还能积累一些“已知问题”用来校准后续提示词。整体扫描节奏越规律后面项目的产出越接近可复用状态。2.2 提示词设计把“扫代码”变成“做审计”提示词是整个扫描的核心。我用了一个比较固定的模板后面每个项目只调整关注点。你现在是一名有十年经验的 Java 技术负责人。请以代码审查的方式检查当前仓库。 本次只审查不修改任何文件。 重点关注 1. 安全性SQL 注入、越权、敏感信息泄漏、支付回调验签、文件上传。 2. 事务与并发Transactional 是否缺失、库存扣减是否安全、锁的使用。 3. 性能N1 查询、深分页、大对象传输、缓存失效。 4. 可维护性分层是否清楚、Controller 是否过重、异常处理是否统一。 对每个问题输出 - 文件路径、行号 - 问题描述 - 风险等级P0/P1/P2/P3 - 修复建议 如果某类问题不存在请直接说明“未发现”不要编造。拆开看每个句子都有作用。角色设定让它从“AI 聊天”切换到“审查者”“不修改任何文件”这条有效阻止它顺手改源码“重点关注”四条是我真正关心的维度不给它自由发挥输出字段强制结构化方便我直接转给团队成员“不存在就说明未发现”用来压幻觉虽然不完全有效但确实能降低编造问题的概率。实际扫描时我会按模块微调比如扫支付模块就补充“关注回调幂等和签名”扫订单模块就补充“关注状态流转是否安全”。有个很容易踩的坑一次性把整个项目丢进去让 Codex“全面审查所有代码”。它要么被上下文长度限制截断要么到后面开始模板化地重复前面问题。所以我在模板外还加了一句话“本次请重点审查 src/main/java/com/shop/modules/order 目录其他目录如果发现明显问题可以提出但不是重点。”这样一来输出质量会明显提升。2.3 控制上下文一次只扫一个模块Codex 类模型对上下文长度很敏感。不是说它读不完而是读得越长中后期生成的内容越容易“飘”。我印象最深的是一次让它在同一个会话里连续看订单、支付、商品、用户四个模块前两个模块的输出很精准后两个模块开始张冠李戴把商品模块的方法名安到用户模块头上。后来改成一次一个模块扫完一个就开新会话最多保留一份历史摘要作为参考准确率恢复正常。还有一个细节扫描时保持 git 工作区干净。如果存在未提交改动Codex 会把 diff 和全量文件同时理解进去有时会误把“新代码改动”当作“本来如此”给出“该行增加了事务但缺少回滚”这种误导结论。我在扫描之前会先git stash或者创建独立分支确保它看到的是一个稳定版本而不是开发到一半的中间状态。3. 六轮扫描实录从 SSM 到微服务3.1 A项目SSMJSP老代码的 XSS 和 SQL 拼接问题A 项目是 6 个里最“老”的SSM 框架页面层还是 JSP代码量约 3.2 万行数据库表四十多张典型的中型老商城。Codex 在这个项目里的第一反应挺不错JSP 页面直接用% request.getParameter(keyword) %回显搜索词的地方它几乎全标了出来并提示存在 XSS 风险。这类问题在 SonarQube 里也能通过规则扫到但 Codex 会把它串起来同时指出后端没有做统一输出编码一旦参数名被修改就可能形成一个可利用的越权路径。更让我意外的是它在 MyBatis XML 里发现了多处${...}字符串拼接。这类问题通常算初级错误但散落在多个 mapper 文件里人工很难全部盯到。Codex 给了一份清单我抽查了 5 处4 处真实存在1 处是误报把数据库字段误当成了用户可控参数。这个准确率已经能满足我的初步筛选要求。不过 A 项目里 Codex 对老框架的理解明显不足。比如它对jsp:include的页面复用建议偏理想化对 Spring MVC 的ModelAndView和 JSP 标签库的搭配理解也一般给出的“统一改成 Thymeleaf”建议完全不合理。这说明模型训练集中主流技术栈占主导遇到老框架时会露怯需要人来做技术栈适配判断。3.2 B项目Spring BootMyBatis-Plus业务代码里的精确打击B 项目是一个相对规范的 Spring Boot 2.x MyBatis-Plus 单体商城代码量 2.1 万行分层清晰。我对它期待最高因为这是 Codex 训练数据里最常见的组合。扫描结果也确实最接近“可交付”。最有价值的问题集中在两个地方一是 OrderServiceImpl 里库存扣减和订单插入不在同一事务二是 PayNotifyController 支付回调没有验签。我把 Codex 给出的输出简化后放下面。[ { file: src/main/java/com/shop/modules/order/service/OrderServiceImpl.java, line: 103, issue: 库存扣减逻辑与订单创建不在同一个事务中库存扣减失败后订单仍会写入。, risk: P0, suggestion: 在 createOrder 方法上增加 Transactional(rollbackFor Exception.class)并把库存扣减与订单插入放在同一数据源操作中。 }, { file: src/main/java/com/shop/modules/pay/controller/PayNotifyController.java, line: 66, issue: 支付回调接口未校验签名攻击者可伪造支付成功通知。, risk: P0, suggestion: 先对回调参数做签名校验再更新订单状态校验失败直接返回失败响应。 } ]人工复核时这两条结论完全准确。事务问题只要看方法调用栈就能确认验签问题看接入文档也能明白必须处理。Codex 没有把它当“模板答案”来敷衍而是明确指出“当前页面拿到订单号后直接改状态”说明它确实读懂了方法内部逻辑。不过它随后建议“引入 Redis 分布式锁来扣减库存”在我看来属于过度设计。单机并发不高时数据库乐观锁或版本号完全够用没必要额外引入一个分布式组件。技术负责人这时候得会做减法Codex 只会做加法。3.3 D项目微服务网关鉴权和分布式事务D 项目是 6 个里最复杂的Spring Cloud Gateway Nacos Feign接近 6.5 万行服务拆成 6 个业务模块。Codex 扫描时我把粒度切到服务级订单服务扫一次、支付服务扫一次、网关扫一次。它在这个项目里的亮点是发现了“网关鉴权形同虚设”的问题有些路径在网关层没有配置拦截规则但下游用户服务又以为网关已经做过认证结果出现了越权风险。这个问题的价值在于它不是孤立的代码 bug而是服务间协作定义不清晰造成的架构级风险。Codex 能把网关配置文件和 Feign 接口调用堆栈放在一起看说明它对跨文件引用有建模能力。它还发现了一个分布式事务隐患下单流程里先扣库存再调支付服务支付失败时没有本地消息表或事务消息补偿直接抛异常让前端重试。它给的修复建议是引入 Seata 或本地消息表方向我认同但落地成本和团队运维水平需要我来判断。另一方面Codex 在微服务项目里的幻觉也更频繁。比如它建议订单服务直接调用用户服务的数据库理由是“减少一次网络调用”。从性能看有点道理但完全破坏了微服务边界。这种建议不能采纳。我的经验是微服务项目里Codex 的架构建议要打五折再听因为它看得到局部性能问题却看不到团队边界和运维成本。3.4 其余 3 个项目的扫描结果与评分表C 项目用 JPA Redis代码量最小。Codex 扫出了几个缓存一致性隐患比如更新用户信息后没有主动淘汰 Redis 缓存。这类结论需要人工核对缓存逻辑才能落地。但它对 JPA 的懒加载和 N1 问题反应一般很多建议停留在“好像有道理但改下去容易出事”的状态。E 项目属于 Controller 直接操作 Mapper 的类型Codex 几乎没有放过任何一处直接给可维护性打了很低分这个判断和我的预期一致。但它没意识到这种代码往往是工期紧逼出来的技术债直接建议全面重构在真实业务里很难执行。F 项目是多商户模式Codex 敏锐发现了商户维度隔离不彻底的问题部分查询接口没有带 merchantId 条件A 商户能看到 B 商户的订单列表这是一条真正的 P0 级漏洞。为了避免空口评论我把扫描后人工复核的结果汇总成表。先解释统计口径核心问题数指经过人工去重、过滤掉明显误报后风险等级在 P0 和 P1 的有效问题数量人工复核通过率指 Codex 输出的问题里确实成立且有修复价值的比例综合评级是我基于五个维度加权后的主观判断并不同的人去扫可能有出入这里更多是展示方法。项目代号技术栈代码规模核心问题数(P0/P1)人工复核通过率综合评级ASSMJSP约3.2万行11约85%C-BSpring Boot MyBatis-Plus约2.1万行7约90%BCSpring Boot JPA约1.8万行4约75%B-DSpring Cloud 微服务约6.5万行13约80%BESpring Boot 混乱分层约2.4万行9约88%DFSpring Boot 多商户约4.8万行10约82%B-扫完整个样本集合后我明白了一个道理Codex 的“通过率”虽然不算低但真正影响效率的是那 10% 到 25% 的误报。你每信一条错误建议就要花 5 到 10 分钟去查证如果错误建议刚好落在不熟悉的模块还可能直接污染整体判断。所以后续引用 Codex 结果时我全部按“重要问题必须人工复核证据链”的方式来处理而不是拿它当最终结论。4. 排查 Codex 误报与稳定性问题4.1 遇到的三类误报怎么分辨真假先说误报。第一类是指向错误位置。它说 OrderServiceImpl:103 有问题但实际 103 行是空行或注释真实问题在旁边某一行。这类最常见通常不致命只要你愿意逐一打开文件核对。第二类是“张冠李戴”把 A 模块的方法行为安到 B 模块上原因通常是上下文过长后的记忆漂移。第三类是“合理但没必要”问题客观存在但修复价值极低比如建议把所有 if-else 改写成策略模式或者建议给只有两个请求的方法加缓存。这类建议看起来专业实际就是在新增复杂度。分辨方法就一个原则让 Codex 自己给证据。碰到模棱两可的建议我会追加一轮提示“请给出当前问题涉及的完整方法签名、调用链以及你判断它是 P0 的依据。如果你无法从仓库里找到证据请撤回该结论。”这种情况下Codex 通常会收敛很多相当一部分误报会自我修正因为推理时会重新注意到前面的源码。这一步很重要能省下大量人工排查时间。4.2 网络超时与上下文超限的应对扫描 6 个仓库的过程中我遇到几次请求中断主要是网络连接超时模型服务端没有在预期时间内返回结果Codex 提示请求失败。这时候我一般不重试原提示词而是先减小输入范围把模块继续缩小再发起扫描。如果仍然失败就把大模块拆成几个方法级的片段分别处理最后手工合并结果。不同网络环境下的表现会不一样重点是不要把偶发超时当成 Codex 能力不行换一种方式让任务继续下去。上下文超限是更常见的问题。解决思路很简单切会话。一个会话只负责一个模块并且在会话开始时就写明“本次只审查 xxx 包忽略其他目录”。为了减少信息丢失我会在每个新会话开头粘贴上一个会话的结论摘要比如“订单模块已发现 2 个 P0本次重点看商品模块”。这样 Codex 能顺着已知结果继续推进也不会把前面模块重复扫一遍。4.3 让 Codex 输出可直接落地的修复补丁只拿问题清单还不够理想状态下我希望 Codex 能给修复示例。实践中它确实能做到尤其是 B 这类结构规范的项目。我会在提示词末尾追加一句“对于 P0 和 P1 问题请给出修复示例示例用 Java 代码块描述不需要直接写入文件。”然后它会在每个问题后面给出方法级修改示例。这些代码不一定全对但只要人工改一改就能用比从零开始写高效很多。这里有一条安全红线不要让 Codex 自动改代码。我一开始测试时允许它修改结果它在一个老项目里把 MyBatis XML 的#{}改成了${}理由是“让 SQL 更灵活”。这种改法等于把 SQL 注入风险直接放大。所以我现在一律用只读模式扫描人工 review 之后再把补丁合并进去。代码审查工具可以激进但生产代码的合并权永远要留给人。5. 结论Codex 能替技术负责人做多少5.1 能做的把初审变成“半天完成”如果把技术负责人的代码审查工作拆成粗筛、深挖、决策、跟进四段Codex 至少能高质量完成粗筛和部分深挖。过去我对 6 个项目做第一轮风险初筛每个项目至少要一整天现在借助 Codex 可以先拿到带行号的问题清单再结合人工复核一个项目半天到一天就能完成初审。尤其是跨文件调用链分析比如支付回调到订单状态更新的链路人工翻阅可能要十分钟Codex 十几秒就能把相关方法列出来。另一个能替我做的是整理材料。技术负责人经常需要向上汇报质量风险Codex 生成的清单可以当作问题列表底稿只要按 P0/P1 重新排序、补上业务影响描述就能直接拿到项目会上讨论。这对我来说是真省时间。我还发现它适合做代码评审前的预审团队提 PR 后先让 Codex 扫一遍能避免一些低级问题占用 reviewer 的注意力。5.2 不能做的拍板、负责、背锅要说它能替代技术负责人我坚决摇头。技术负责人真正的权力是决定改不改、什么时候改、谁去改而 Codex 给的只是“应该改”。从“应该”到“做决定”之间隔着业务优先级、团队产能、线上风险、甚至跨部门协调。比如 D 项目那个分布式事务问题技术上引入 Seata 很标准但新增加一个基础设施组件需要运维评估、网络策略、监控告警这些根本不是 Codex 能拍板的。还有一层是责任。技术负责人可以对业务结果负责出了问题可以复盘改进Codex 的某个建议如果导致线上故障你没法让它承担责任。这不是能力问题是责任主体问题。它适合当参谋不适合当指挥官。此外Codex 很难理解“技术债其实是团队默契”。E 项目里那些混乱分层可能已经是团队在赶工期时达成的妥协直接去重构反而扰乱节奏。这种组织行为层面的判断模型目前完全看不到。5.3 我给团队的落地用法我现在实际的做法是把 Codex 扫描固化成提测流程的一环。流程大致是开发自测完成后先让 Codex 以“审查者”身份扫描变更模块生成 Markdown 报告开发者按报告自查不能确认的问题标注出来技术负责人只 review 被标注的部分和所有 P0。这个流程跑了一个多月最直接的好处是我不需要再花时间关注“有没有低级问题”这种重复劳动可以集中精力处理真正的风险和设计取舍。最终我的个人体会是Codex 不是来替你做决定的技术负责人它是来帮你把重复性工作吸干净的清扫机。你越是给它清晰的标准它越能靠近你习惯的审查风格你越是把责任直接甩给它它越会用幻觉回敬你。用之前想清楚边界用起来反而顺手。6. 一些零碎但重要的体感最后分享几个没有写进上面流程的细节。第一扫描结果用 git 管理每个项目生成一份codex-review-日期.md文件时间久了能看出同一个项目不同版本的质量变化这是一个很好的技术债观测指标。第二Codex 的“代码风格”输出受提示词影响极大如果提示词里写“请指出所有不规范命名”它会把整个项目的变量名都挑一遍基本没法用一定要把范围锁死在风险优先。第三我在给团队演示时发现大家更愿意看表格而不是长篇报告所以我会让 Codex 输出 summary 表格再人工补充说明效率比从头写文档高很多。这次扫完 6 个项目我最大的感受不是“AI 多厉害”而是“技术负责人这个角色真正值钱的部分恰好是 AI 最不擅长的那部分在信息不全时做取舍在资源有限时排优先级在团队紧张时顶住压力”。Codex 能帮我把“看清问题”这件事做得更快更全但“承担责任”这件事它永远接不了。工具就放在那里关键看你把它摆在流程的哪个位置。我自己已经把它固定在了 review 流程的最前面算是目前最顺手的一个用法。