企业官网建设流程全解析

把脏活累活丢给 Codex

代码审查这件事，说穿了就是个体力活。你要盯着 diff 看命名是否规范，检查空指针有没有漏网之鱼，还要在重复代码里找茬。这些工作不需要太多创造力，却极度消耗注意力。Codex 进入这个场景后，我第一件事就是把这类"脏活累活"丢出去。

实际用下来，Codex 对代码异味的识别相当敏锐。重复代码是最典型的例子——它能跨文件定位到逻辑相似的块，甚至能识别出"结构重复但变量名不同"的变体。命名规范方面，它不仅能检查是否符合驼峰或蛇形命名，还能结合项目上下文判断语义是否清晰。比如getData()这种模糊命名，它会建议改成fetchUserOrderSummary()这类带业务含义的表达。

潜在 NPE 的排查更让我意外。Codex 会沿着调用链向上追溯，标记出"这里可能返回 null 但没有校验"的点位。有一次它甚至发现了一个我都没注意到的场景：某个工具类的缓存方法在并发下可能返回空值，而调用方直接链式调用了.size()。

设计模式审查：能搭脉，但开不了方

说到设计模式，Codex 的表现要分两层看。识别层面，它能准确指出"这里用了策略模式但缺少上下文封装"，或者"工厂方法和构建者模式混用了，职责边界模糊"。这种诊断对于初级开发者尤其有价值，相当于有个资深同事在旁边随时提点。

但重构建议层面就明显保守了。它倾向于给出教科书式的标准实现，却容易忽略项目里的特殊约束。比如我们的订单系统为了兼容历史数据，策略模式的上下文必须带版本标识，Codex 第一次给出的建议完全没考虑这个点，直到我把 AGENTS.md 里的业务规则补充进去才调整过来。

我的做法是：让 Codex 先做模式识别和初步诊断，具体的重构方案必须结合人工判断。把它当成一个"能发现问题的实习生"，而不是"能拍板的技术负责人"。

嵌入团队 Review 流程的三种姿势

Codex 不是替代现有流程，而是嵌进去。我们团队摸索出三种用法：

前置过滤：提交到人工 Review 之前，先过一遍 Codex。它能在 30 秒内标出明显的风格问题和低级 bug，把人工审查的注意力解放出来聚焦架构层面。这个环节的通过标准我设得比较松——“无致命问题即可放行”，不追求一次性修干净。

并行审查：对于大型 MR，让 Codex 和人工同时开工。它负责逐行注释标问题，人工负责把握整体设计走向。最后对比双方的审查点，往往能找到互补的盲区。

事后复盘：每周抽几个典型 MR，让 Codex 重新审一遍已合并的代码。这种"马后炮"有意外的价值，能发现当时赶工期漏掉的技术债，也能校准团队对审查标准的理解是否一致。

这些坑，Codex 现在还填不上

用了两个月，我整理出一份仍需人工把关的审查清单：

• 业务语义正确性：它能检查语法，但理解不了"这里的折扣计算应该优先使用会员价而非活动价"这种业务规则
• 性能陷阱的上下文判断：能识别出 N+1 查询，但判断不了"这个接口的调用频率是否真的需要优化"
• 安全漏洞的深层逻辑：对 SQL 注入、XSS 等有明显特征的问题识别率不错，但对权限绕过、竞态条件这类需要业务上下文理解的场景容易漏检
• 架构一致性：单个文件的修改是否合理，它能判断；但这个修改是否破坏了模块间的依赖关系，需要人来看

设置 Review 通过阈值的心得

我现在的做法是分层设阈值，不搞一刀切：

这个阈值不是固定的，会根据项目阶段调整。新业务快速迭代时 L2 的修复率可以降到 60%，但 L1 的底线绝不松动。

偷懒的边界在哪里

说到底，Codex 让我"偷懒"的部分是机械劳动的替代，而不是责任的转移。我现在提交 MR 前的心态很清晰：Codex 审过的代码，我还是要快速扫一遍，但扫的重点从"找 bug"变成了"验证 Codex 有没有漏掉业务层面的坑"。

有个挺实际的收益是审查时间的重新分配。以前一个 500 行的 MR 可能要花 40 分钟仔细过，现在 Codex 先过一轮，人工审查压缩到 15 分钟，多出来的时间用来写测试或者做设计。这种"偷懒"不是消极应付，而是把人的注意力从低价值劳动里释放出来。

当然，前提是你得接受它偶尔会犯傻。有一次它建议我把一个工具类改成单例模式，却忽略了我们部署环境是多实例的——这种建议如果无脑采纳，反而引入问题。所以我的底线始终没变：Codex 是审查流程里的一个环节，不是终审法官。