企业官网建设流程全解析

1. 为什么把“Codex 扫 6 个 Java 商城”当成一个严肃测试

这件事的起因很实际：团队想引入 AI 辅助 Code Review，但我不能拿线上商业系统直接当小白鼠，于是决定用一堆开源 Java 商城来做基准测试。Java 商城不是随便选的，它几乎是 Java 后端技术能力的集合体：登录认证、权限模型、商品中心、购物车、订单、库存、支付回调、退款、优惠券、定时任务，再到 Redis 缓存、MQ 异步、微服务拆分，一应俱全。把 6 个风格不同的商城丢给 Codex，本质上是让它在最短时间内完成一次“代码体检”，看看它能发现什么，会漏掉什么，以及它给出的建议能不能直接落地。

可以说，这个动作的真正目的不是“验收 AI 工具”，而是回答一个技术管理者都关心的问题：当一份代码交到我手上时，我能不能先用 Codex 做一轮快速初筛，再由人来补位，从而把有限精力集中在真正需要判断的地方。Codex 在这个场景里不是那种只会聊天的模型，而是能够读取项目文件、搜索代码、定位调用链、提出修改建议的编码智能体，所以它的表现会有很强的工程参考价值。

需要先声明边界：我做的只是静态代码分析，不启动 MySQL、Redis，也不跑单元测试。6 个项目全部来自开源社区，本地保管，只看工程结构和源码语义。这样做的好处是结果可复现，坏处是会少掉运行时问题，例如内存泄漏、慢 SQL、缓存穿透这些必须靠压测才能暴露的内容。因此下文所有结论都限定在“纯静态扫描”这一前提下。

1.1 我为什么选 Java 商城作为试金石

选 Java 商城，是因为它同时具备“业务复杂度”和“工程复杂度”。一个能跑通全链路的商城，Controller、Service、Mapper、Domain、Common 这些分层基本都是齐的，订单和库存还牵扯事务与并发，支付回调牵扯安全验签，后台管理牵扯越权防护。这意味着 Codex 要处理的问题类型非常密，远比扫一个 CRUD 学生项目有价值。

另一个原因是为了“横向对比”。如果我只看一个商城，Codex 的结论可能在某个技术栈下恰好特别好看或特别难看，只有把单体、微服务、老 SSM、前后端分离、多商户这些形态都铺开，才能观察到它能力的坡度。比如我预期它在 Spring Boot 单体项目上表现最好，因为这一类的公开代码和语料最多；事实也差不多，但其中有不少细节偏差，后面我会展开。

1.2 技术负责人真正关心的三个问题

第一，新接手的人能不能快速看懂这个项目。架构边界清不清楚、模块依赖复不复杂、启动入口好不好找，这决定新人的上手成本。第二，代码里面有没有明显的地雷。权限校验是不是只做了前端、SQL 是不是存在拼接、库存扣减是不是存在超卖、支付回调是不是直接改订单状态，这类问题一旦上线就是事故。第三，如果要做重构，从哪里动刀最划算。不是把所有代码都重写，而是先用最低成本解决最高风险的问题。

这三个问题对应的能力，恰好是 Codex 最容易让人产生幻觉的地方。因为它能很快读完代码，所以它看起来“懂”项目；但懂多少、懂到哪个层级，只有把它输出的诊断结果和人工复审对照之后才敢说。整个测试的乐趣也在这里：看它在耗时一小时后交出的报告，到底有多少能直接进入我的待办池，有多少需要划掉。

1.3 这次测试的边界和前提

我固定了扫描流程，避免 6 个项目之间因提问方式不同而不可比。流程是：先让 Codex 读 README 和构建文件，梳理模块结构；再让它按统一检查清单过一遍关键代码；最后针对它自己列出的 Top 问题，要求给出具体修复方案。所有交互都通过命令行终端完成，部分逻辑复杂的地方会要求它引用具体文件和行号。

由于 Codex 不同版本的模型能力和工具调用能力有差异，我这里不强调具体模型代号，只说表现。如果你手头的 Codex 版本确实比我新，那么参考结论时只要抓住“它能做初筛，但需要人确认”这个主线即可，具体输出格式可以按你项目的实际情况调整。

2. 先把 Codex 和 6 个商城项目准备好

工欲善其事，必先利其器。这里说的准备不只是装一个工具，还包括怎么挑选测试样本，以及怎么把“检查什么”这件事结构化。下面是我的具体做法。

2.1 安装 Codex CLI 的完整步骤

Codex 的官方 CLI 安装方式比较灵活，最常见的做法是通过 npm 全局安装。前置条件是开发机有 Node.js 18 以上和 git，并且能正常连通 OpenAI 官方服务。我这里只说官方标准流程，不讨论其他途径，避免把环境问题变成安全风险。

npm install -g @openai/codex codex --version

安装完成后，第一次使用需要做鉴权。最省事的方式是执行codex login，用浏览器完成登录；也可以把 API Key 写入环境变量：

export OPENAI_API_KEY="你的key"

如果你在一个团队里使用，建议不要在命令行里直接粘贴密钥，而是把密钥交给密钥管理服务，本地通过环境变量注入。我惯用的做法是在项目根目录建一个.env.example，只写变量名不写真实值，真实值放本机。同时提醒一句，千万不要把.env文件提交到 git 里，这类问题在工程里太常见了。

安装和登录之后，先用一个小目录试运行一下，确认它能读文件再开始扫商城。试运行命令可以是：

codex exec "看一下当前目录结构，然后告诉我这个项目大概做什么"

这里有一个我自己踩过的点：如果你在旧的终端会话里安装了 npm 包，可能还要重新打开终端或者执行hash -r才能让codex命令生效。另外，如果你遇到提示ignoring unrecognized configuration setting，多半是配置文件名或配置键写错了，先检查~/.codex下面的配置文件，不要一上来就怀疑网络或授权。

2.2 如何挑选 6 个有代表性的商城项目

我从开源社区挑了 6 个 Java 商城，筛选标准是“技术栈有差异，业务完整度够高，代码量在合理范围”。太小的商城没有扫描价值，太大的项目又会拖慢整个过程。最终清单大概是这样的：

实际执行时，我用的是git clone --depth 1做浅克隆，只保留最近一次提交，这样既省磁盘又省扫描时间。克隆完成后，把所有项目放在同一级目录下，并且给每个目录写一个简单的project-note.md，说明这个项目大概属于哪种风格、重点想测试什么。这个文件对 Codex 理解上下文很有帮助。

2.3 给 Codex 定“检查清单”

如果你直接问 Codex“这个商城项目有什么问题”，它会给你一份泛泛的、看起来都对但又没什么用的报告。因此我把检查清单写成了独立的 Markdown 文件codex-review.md，内容按严重程度分成了 P0 到 P2 三级：

• P0：可直接导致线上事故的问题，比如支付回调未验签、越权查询、SQL 注入、未加锁扣库存。
• P1：会造成数据不一致或严重可维护性问题，比如事务边界错误、重复代码、大事务、状态机混乱。
• P2：风格和规范类问题，比如命名不统一、魔法值、日志打印不规范、接口返回结构混乱。

清单里还加了一条硬性要求：每个问题必须给出文件路径和大致行号，并且给出“为什么是问题”的简短解释。这样做的目的，是逼着 Codex 回到代码现场，而不是靠记忆给你列十条 Java 最佳实践。检查清单文件本身很小，但它是整个扫描过程里最重要的那个旋钮。

把检查清单放在项目根目录还有一个额外好处：Codex 在读取项目时可能会自己发现这个文件，从而把回答方式自动收敛到清单要求。实测下来，这个操作能明显减少“正确的废话”。

3. 让 Codex 开始扫描：我的实操流程与提示词

准备阶段结束之后，进入真正有意思的部分。整个过程分三轮，每一轮的目的都不同。第一轮是让 Codex 建立全局视角，第二轮是按照检查清单查问题，第三轮是要求它给出可操作的修复路径。

3.1 第一轮：让 Codex 先梳理系统架构

我的第一条指令不是“找出所有漏洞”，而是先让 Codex 理解项目。因为如果它连模块边界都没搞清楚，后面所有排查都容易陷入局部细节。典型提示词是这样的：

请先不要写代码。请阅读当前项目的 README、pom.xml 或 build.gradle 以及启动类， 梳理出这个项目的模块划分、启动入口、核心业务流程、用到的中间件， 然后输出一份不超过 500 字的架构摘要。

执行下来，Codex 基本能在两三分钟内给出不错的架构概览。它会把“商品、订单、用户、支付”这些核心模块点出来，也会提“使用了 Redis 作为缓存、RabbitMQ 作为异步消息”等中间件。多数情况下，这份摘要可以直接作为技术负责人向下一个接手者交代的底稿。不过也有例外，个别老项目因为注释太少、命名太乱，Codex 会猜错业务模块，这时候需要人工纠正。我的经验是不要跳过这一步，第一轮本质上是在给它打“项目上下文”的底。

3.2 第二轮：按检查清单做代码审计

有了第一轮的底，第二轮就可以放开了。我输入的长提示词类似下面这个模板，大家可以直接抄：

我准备对这个 Java 商城项目做一次静态代码审查。 请你严格按照项目根目录的 codex-review.md 检查清单执行。 重点关注 controller、service、mapper、domain 下的代码， 对每个发现的问题都用以下格式输出： [级别] 文件路径:行号 - 问题描述（原因 + 影响 + 修复建议） 不要输出空泛的最佳实践，只输出你能在代码里找到依据的问题。 最后按 P0/P1/P2 统计数量。

这一轮耗时最长，有的项目 5 万行代码可能需要十几分钟。执行时我会盯着输出，发现它跑偏就立即打断并且补充上下文。比如它突然只盯着一个工具类讲，我会追加一句“库存和订单链路还没看，继续检查 order 和 stock 相关代码”。这种“人机协同”的节奏，比完全放养要高效得多。

它生成的报告往往是列表形式，直接打印在终端里。我会让它顺便生成一份review-report.md写到项目目录，方便后续对比。这里有一个安全提示：如果 Codex 需要写文件，请看清楚它的操作意图再批准，不要盲目给它所有权限。我不建议使用任何绕过安全确认的参数，保持默认审批流程更稳妥。

3.3 第三轮：让 Codex 提出优化方案

在拿到完整问题清单后，我不让它一次性解决所有问题，而是只挑 Top 10，让 Codex 按“影响面”排序，并给出最小成本方案。提示词示例：

从刚才的审查报告里挑出最值得优先处理的 10 个问题。 按风险从高到低排序，对前 3 个问题分别给出： 1. 当前代码存在的问题； 2. 最小改动方案； 3. 改动涉及哪些文件； 4. 方案存在什么取舍。 其他 7 个问题只需要给一句话修复建议。

这个阶段最能体现 Codex 的工程感。它不是单纯把代码改成更好看，而是会考虑改动范围。比如在修 SQL 注入时，它会建议把${}改成#{}，同时提醒你要检查排序字段是否在白名单内，因为它知道排序字段不能直接参数化。这种细节说明它的训练数据里确实包含了大量真实的 Java 修复场景。

4. Codex 扫完后的结果：能发现什么，会漏掉什么

六份报告交上来之后，我做了横向汇总。这一步是整篇文章最值得看的地方，因为它直接回答“它能替技术负责人做到哪一步”。

4.1 六张诊断结果的横向对比

我先把六个项目的结论整理成一张表，方便对比：

这里的“有效”是我人工复核后的结果，不是 Codex 自己判定的有效。从我的体验看，Codex 在 Spring Boot 单体项目上的表现最像“一个读过很多代码的初级顾问”，而在老 SSM 项目中它偶尔会把过时的写法当成当下问题，比如对 JSP 里的 Java 代码片段大肆批判，这不算错，但对维护老项目的团队没有增量价值。

4.2 它发现的 5 类高价值问题

第一类，越权问题。多个项目里出现了“通过 id 直接查询订单，不校验订单属于当前登录用户”的代码，这在后台管理接口里尤其常见。Codex 能发现它，是因为它可以从 Controller 到 Service 的参数传递链上看到没有调用当前用户校验。第二类，MyBatis 动态 SQL 拼接。这个真不是段子，${orderByClause}、${keyword}在老旧项目里到处都是，Codex 对这类问题异常敏感。第三类，事务边界错误。它会指出@Transactional加在私有方法上其实不生效，或者被同类内部方法调用导致注解失效。第四类，库存扣减无并发保护。它虽然不一定能给出分布式环境下的最终方案，但至少能指出“先查后改非原子”。第五类，硬编码密钥。数据库密码、短信 app secret、支付公钥出现在application.yml里，它一眼就能看出来。

这些问题的共同点是：它们都是模式化问题，在公开代码和主流教程里反复出现，所以 Codex 很容易识别。换句话说，它强在“经验模式匹配”，而不是“业务推理”。

4.3 它产生的误报与“正确的废话”

最影响使用体验的是误报。最典型的是把“返回统一结果对象”误判成接口设计有问题。有些商城为了兼容老前端，Controller 里用 Map 直接返回，Codex 会反复说“建议定义 DTO”，但实际上那些接口可能已经被大量调用，贸然改反而风险更高。另一个常见的空话是“建议使用 Optional 避免空指针”，可它对业务代码里 Optional 用在一旁、核心判空逻辑还是写不对没有任何帮助。

误报的根本原因是缺少团队上下文。它不知道你们的接口规范、不知道这类遗留代码是不是已经准备下线、也不清楚 DTO 体系正在重构。这也是为什么我不建议把 Codex 的报告直接丢给老板或者客户看，它是给技术负责人用的草稿，不是最终评审意见。

5. 一个典型例子：订单扣库存的并发问题，Codex 能查到哪一步

只有把镜头拉到单个代码片段，你才能真正看清楚 Codex 的思维方式。下面这个例子是我从某个商城项目里简化出来的，但它很好说明了“查到哪一步”和“卡在哪一步”。

5.1 给 Codex 看的代码段

假设有这样一个下单方法：

public boolean createOrder(Long userId, Long skuId, Integer num) { Stock stock = stockMapper.selectBySkuId(skuId); if (stock.getAvailable() < num) { return false; } stock.setAvailable(stock.getAvailable() - num); stockMapper.updateById(stock); orderMapper.insert(buildOrder(userId, skuId, num)); return true; }

表面上看，这段代码逻辑完整：查库存、判断库存、扣减、建单。但懂并发的人一眼就能看到，它没有解决超卖，也没有处理扣减失败的判断。我把这段代码单独丢给 Codex，只告诉它“这是订单创建的一部分”。

5.2 Codex 的输出与修复建议

Codex 很快就指出三件事：第一，selectBySkuId和updateById之间不是一个原子操作，多个线程同时进入时都会看到足够的库存。第二，updateById即使影响行数为 0，方法照样返回成功，所以在极端情况下订单建了但库存没扣成功。第三，如果createOrder方法加了@Transactional，数据库万一出现死锁，整个方法会回滚，但前提是异常没有被try-catch吞掉。它给出的修复建议也很具体：

int rows = stockMapper.deductStock(skuId, num); if (rows == 0) { return false; } orderMapper.insert(buildOrder(userId, skuId, num)); return true;

对应的 Mapper 语句是：

UPDATE stock SET available = available - #{num} WHERE sku_id = #{skuId} AND available >= #{num}

这个方案其实就是乐观锁思路的变体，用“影响行数”来判断库存是否充足。Codex 能在没有业务说明的情况下给出这个方案，说明它不是只会背概念，而是真的能把“条件更新”和“行数校验”组合起来。

5.3 我踩过的坑：上下文窗口与局部视野

但接下来发生的事更有意思。当我只给它这一个方法时，它给出的建议里有半句是“可以考虑在方法上使用 synchronized”。如果这是一个单机应用，这方案勉强能用；可在商城这种必然要多实例部署的系统里，synchronized根本锁不住不同进程。于是我在同一个会话里补充了项目上下文：应用采用多节点部署，库存数据存在 MySQL，订单服务通过负载均衡分发请求。Codex 随即修正了答案，改口说需要引入分布式锁或依赖数据库条件更新，并解释了synchronized只在单 JVM 内有效。

这个细节给了我很大启发：Codex 的局部扫描结果高度依赖你给了它多少上下文。它不会主动去读部署配置或运维文档，除非你在提示词里点名。技术负责人用它做审查时，最好的方式不是给它一个空目录，而是先把“这个项目是单体还是微服务、有没有多实例部署、用的什么数据库隔离级别”这些背景告诉它，它才能少闹笑话。

6. Codex 在 Java 项目上的局限性

前面讲了它能做到什么，这一部分专门说它的短板。只有把边界画清楚，“替技术负责人做到哪一步”这个问题才有可执行答案。

6.1 业务语义理解

代码里最难读出来的东西不是语法，而是“为什么这么写”。比如一个下单接口里有一套积分抵扣逻辑，Codex 能看出它计算了积分，但看不出“积分是否允许透支”是运营规则。如果团队规定“新用户首单可以赊积分”，这段逻辑可能在配置文件或状态枚举里，Codex 很容易把这种刻意的宽松判成漏洞。同理，“只允许在每天 0 点到 2 点之间取消订单”这种规则，如果代码里没有直接写清楚，它可能完全忽略。所以它的定位是“代码级体检”，不是“业务逻辑审计”。

6.2 多模块联动分析

微服务商城项目里，Codex 最明显的问题是“局部很强，整体很弱”。它能告诉我order-service里的某个接口没做幂等，但不会主动把payment-service的回调、stock-service的补偿任务、消息队列的消费重试串成一条完整的分布式事务链路来审查。换句话说，分布式系统的很多问题出在服务与服务之间的契约上，而 Codex 默认的工作方式是一次只看一个仓库或一个模块。如果你想让它做跨服务审查，就得手动把相关服务的目录都挂进来，并在提示词里画清楚调用顺序。

6.3 安全规则和团队规范

Codex 不知道你团队的“红线”。有的团队规定所有数据库写操作必须通过 Service 层，不允许 Repository 直接暴露给 Controller；有的团队规定日期字段一律用 Long 时间戳，不用 LocalDateTime；有的团队规定所有外部接口都要做签名校验。这些约束通常只存在于内部约定里，代码本身看不出来。如果不在扫描前把这些规则写入AGENTS.md或检查清单，Codex 就只会按通用最佳实践回答，可能给你不合适的重构建议。

把团队规范写进项目根目录的AGENTS.md是我用过最有效的方式。Codex 在读取项目时如果发现这个文件，会在回答时把这里的规则当作最高优先级。你可以把“禁止返回用户密码字段”“所有删除操作必须逻辑删除”“Mapper 不允许写多表联合查询”等等直接列进去，效果比每次都在提示词里重复强调好很多。

6.4 运行时问题不是它的菜

最后说一个边界：Codex 做的是静态分析，它看不到流量，也测不出性能。慢 SQL 要看执行计划，缓存命中率要看监控，线程池有没有打满要看日志和压测。它最多能通过代码推断出某个查询可能会全表扫描，但那是基于表结构的推测，不是真实运行结论。所以我在测试报告里特别标注“运行时问题仍需人工或压测平台覆盖”。

7. 我的最终判断：它能替技术负责人做到多少事

这节的标题用了“做到多少事”，而不是“替代多少”，因为在我测完之后，答案已经很清楚：它不可能替代技术负责人，但能让负责人省掉至少一半的机械性工作。

7.1 可委托给 Codex 的事

第一块是“第一遍全量扫描”。凡是模式化、重复性高的检查，比如硬编码密钥、SQL 拼接、明显的越权路径、事务注解失效，Codex 都能做，而且做得比人快。第二块是“代码解释和新人培训”。新同事接手一个商城项目时，可以让 Codex 先出一份模块说明，再由资深工程师补充业务背景，这个组合我试过，新人理解速度明显更快。第三块是“生成修复补丁和单测草稿”。Codex 能直接给出改动后的代码，虽然不一定完美，但至少能让人工评审从一个可运行的起点开始。

7.2 必须由负责人亲自把关的事

第一是“问题定级”。Codex 会给出 P0/P1/P2，但它是按通用严重程度排的，不是按你公司的业务优先级排的。对一个正在促销的商城来说，库存扣减的并发问题可能比某个管理后台的越权问题更紧急；每个团队有自己的存量风险和发布节奏，这个排序只有负责人能做。第二是“妥协与取舍”。有些问题的最优解是重构，但近期不能动，Codex 不会帮你算这个改动的回归成本。第三是“误报仲裁”。它说的不一定对，需要负责人拿业务上下文做最终裁决。

7.3 把 Codex 接入日常 Code Review 的落地建议

如果想把 Codex 用起来，我的建议不是让它自动给 MR 打 block，而是先做“前置扫描”。每次提交代码前，本地跑一次 Codex，只输出高置信度问题；开发者自行修复后再提交，人工评审者看到的就是一份已经过滤过一遍的代码，负担会小很多。具体落地时，可以先在 CI 里加一个 Codex 检查步骤，但不要把它的意见当作门禁，而是作为评审参考。

我还习惯让它输出置信度字段：

每个问题额外输出一个 confidence 字段：high/medium/low。 如果 confidence=high，说明可以直接自动修复或人工快速确认； 如果是 low，请说明为什么把握不足。

这个小改动会非常有效。因为 Codex 在confidence=high时通常真的很有把握，而low往往会指向需要人思考的地方。真正好的工作流不是“让 AI 决策”，而是“让 AI 把高确定性的东西先干完，把低确定性的事交还给人类”。这和带一个实习生有点像：你让他先做一版初稿，你再做判断，而不是把初稿当成终稿。

扫完六个 Java 商城之后，我个人对 Codex 的定位更清晰了。它不是技术负责人的平替，而是“一个读过海量代码但没在你的业务里待过一天的高级实习生”。它能替你跑腿，能帮你把代码里那些藏在角落的模式化问题翻出来，但它不会知道你真正的业务优先级，也不会替你扛责任。最后分享一个我一直在用的小技巧：每个季度用同一组商城项目重跑一遍扫描，观察 Codex 新版本的误报率和准确率变化，这样你就能判断工具值不值得升级，也能让团队的评审规范跟着工具一起迭代。工具在进化，但负责人要做的判断，永远在工具之上。