企业官网建设流程全解析

1. 从"写完没人验"到"机器替你Review"

不知道你有没有这种经历：本地用 Claude Code 噼里啪啦生成了一大段业务逻辑，commit 之前信心满满，结果代码合进去之后，同事在 review 时挑出一堆低效写法、边界漏洞、格式问题。更尴尬的是，这种问题通常在 CR 阶段才会暴露，而那时候你已经在写下一个需求了，上下文早就断了。

我自己有段时间被这个问题折腾得够呛。我在一个中型项目里负责比较核心的模块，每天肚子里的代码量不小，Claude 帮我写了不少，但"谁来复查"几乎是个没人接的活。团队里大家手头都有事，不可能盯着 AI 生成的一百行代码逐行做静态审查。后来我把思路换了一下：与其让"人"去测 AI 写的代码，不如让"AI"去测 AI 写的代码。于是我把 Codex 接进我的工作流，配了 4 个专门做 Code Review 的智能体，专门帮我盯 Claude 生成的代码。

这篇文章就围绕这套思路展开。我会先聊聊为什么 AI 写代码之后更需要自动化 Review，再讲清楚怎么在 Codex 里把插件跑起来，最后重点给出我实际在用的 4 套智能体配置。内容里包含完整的提示词思路、参数调整、环境变量处理方式和几类我踩过又填上的坑，照着做基本能直接上手。

如果你现在的工作流已经是"Claude 生成 + 人工简单过目"，那我强烈建议你把后面这套方案跑一遍。它不会替代人的判断，但它能帮你在 commit 前挡住很多低级问题。

2. 为什么会存在"写完没人测"这个局面

先说个挺现实的问题：很多开发团队根本没有严格的 Code Review 流程，或者有流程但没有真正落地。原因不只是懒，而是成本太高——每个人都要先理解上下文，再紧跟当前需求，才能给出有价值的反馈。可现实往往是需求排期紧，大家手头都有自己的一摊事，review 这种"看起来不产生业绩"的环节，自然就被压缩了。

但当代码由 Claude 这类 AI 生成时，情况变得更特殊。AI 写代码有个特点：单看每一段都很规范，类型标注也做了，函数名也像模像样，但放到整个项目里，可能会出现风格不统一、重复逻辑、安全边界不完整、甚至和团队已有约定冲突的问题。这些问题不是一眼能看出来的，而是需要结合项目全局信息去判断。

人没空看，普通 Lindt 又只能检查规范，这时候把 Codex 拉进来做自动化 Review 就成了比较自然的选择。Codex 本身是能调用工具、能执行命令的，它可以跑测试、做静态分析、读文件，甚至直接给 Git 提交信息。把它包装成一个"Review 助手"，本质上就是把原本需要人类经验判断的部分，交给一个拥有项目上下文理解能力的智能体去完成。

可能有人会问，Claude 自己不是也能读代码吗？为什么不直接在 Claude 那边做？可以，但我的实际感受是，让写代码的模型去审自己的代码，容易陷入"惯性思维"——它知道自己当时想写什么，就容易忽略掉真正会影响别人的地方。换成 Codex 来做审查，相当于换了一个视角，反而更容易发现边界问题和不良实践。

3. 插件选型：为什么我用 Codex 而不是其他工具

市面上做自动化代码审查的工具不少，有像 Codacy、SonarQube 这类老牌的，也有像 CodeRabbit 这种 AI 优先的新产品。各有各的好处，但我最后选择基于 Codex 来搭，有几个比较实际的理由。

第一，插件化程度高。Codex 本身支持配置自定义指令和扩展能力，你可以把它理解成一个"可以带任务书干活"的智能助手。我想让它只做 Code Review，它就可以只做 Code Review，我不想让它擅自改代码，它就不会动。这种边界控制在我实际用下来非常关键。

第二，底层能力足够强。Codex 不只是聊天模型，它能在本地或云端环境里执行命令、读文件、跑测试。这一点在做 Review 时特别有用——它能真实运行你的测试用例，而不是靠猜。很多 AI 审查工具只做静态文本分析，但 Codex 可以做到"动态验证"这一层。

第三，配置完全文本化，方便放进仓库共享。我把 4 个智能体的配置写成 markdown 文件放在仓库的 .codex 目录下面，团队里任何人拉下来就能用。相比那些必须打开 Web 界面操作的平台，这种模式更贴近开发者习惯。

我也承认这套方案有学习成本。不是装个插件就完事，而是需要你自己写好审查的 prompt、配置好可用的命令、反复调。但一旦跑起来，你等于给自己请了一个随叫随到、态度稳定、永不喊累的 CR 搭子。

4. 准备工作：Codex 安装与环境配置

在配智能体之前，先把 Codex 本身装好。这里我先说明一下，我用的场景是本地开发环境，重点讲命令行和编辑器集成的安装方式。

安装这块其实没什么难度，主要看你原本的环境：

• 如果你已经在用 OpenAI 的生态，Codex CLI 可以通过包管理器直接装，装完初始化一下身份认证就能用。
• 如果你用的是 VS Code，可以在扩展市场里搜 Codex 相关的官方扩展装好，然后在编辑器里绑定你的 API Key 或账号登录。
• 如果你是 macOS 或 Linux 环境，建议直接用 Homebrew 装，省事一些。Windows 上我用 WSL 跑，也很顺畅。

装完之后建议先跑一个最简单的任务验证链路通不通，比如让它读一下当前目录下的代码文件列表。我见过不少人在这一步卡住，症状通常是"请求发出去了但是没反应"，十有八九是身份认证没配好，或者网络环境有问题。用命令行跑一次codex exec "list files"很快就能暴露问题。

另外注意一下模型选择。做 Code Review 的时候，模型的推理能力比速度重要得多。如果你条件允许，优先选推理能力较强的模型，因为这个任务本质上是"多步阅读 + 判断"。我自己在本地用的时候，会指定一个偏审慎的模型来做最终判定，速度慢一点无所谓，关键是它给出的建议要能站得住脚。

一个小建议：不要把 API Key 硬编码在配置文件里。用环境变量的方式加载，这样既能保证安全性，也方便在不同项目之间切换。

5. 4 大智能体配置：从代码质量到安全意识

5.1 智能体 A：Code Quality Agent（代码质量审查）

我配的第一个智能体，也是最基本的一个，专门盯代码质量。它的职责是检查新改动是否符合当前项目的编码风格、有没有重复逻辑、函数体是不是太长、类型标注是否到位、有没有明显可优化的地方。

在 Codex 里配置它，我会用一个独立的 markdown 文件描述它的角色。比如这样写它的核心指令：

# Agent: Code Quality Reviewer 你是这个项目的代码质量审查员。你只做评审，不修改任何文件。 当收到一个 diff 或一组文件路径时，请依次做以下检查： 1. 是否遵循项目已有的命名规范和结构约定。 2. 是否存在可以抽取为公共函数的重复代码。 3. 是否有未处理的错误路径（如空指针、边界值、异常被吞掉）。 4. 是否存在明显性能问题，例如循环内查询、不必要的大对象复制。 5. 类型标注是否完整，公开函数的注释是否足够。 输出格式：按严重级别（Critical / Warning / Suggestion）分组，每一条建议必须给出具体文件和行号。

这个配置的关键在于"只做评审，不修改任何文件"。如果你不加上这句，Codex 有时候会自作主张帮你改代码，这在 Code Review 场景里是绝对要避免的。我不想让它在 review 的同时把代码偷偷改掉，那样就没法追踪了。

运行的时候，我会把 Claude 生成的代码 commit 到一个 feature 分支上，然后让 Codex 基于这个分支跑一个 diff 审查。命令大概是这样的：

codex exec --agent code-quality "请 review 当前分支相对 main 的改动"

它输出的结果会直接列出一批问题，我再决定是手动改还是交给 Claude 去改。这里的核心价值是省掉了人肉通读一百遍的环节。

5.2 智能体 B：Security Guard（安全红线审查）

第二个智能体我主要用在涉及用户输入、鉴权、支付逻辑、内部接口暴露这些敏感场景。因为 Claude 有时候会在不知情的情况下写出存在逻辑漏洞的代码，比如对用户输入只做了前端校验、越权没拦截、日志里打印了敏感信息等等。

Security Guard 的配置指令会更强调规则意识：

# Agent: Security Guard 你是安全评审专家。请主要关注以下红线： - 用户输入是否经过后端校验和规范化。 - 是否存在越权访问风险（水平越权和垂直越权）。 - 是否硬编码了密钥、Token 或连接串。 - 是否在日志中输出敏感字段（密码、手机号、身份证号等）。 - 使用的第三方依赖是否存在已知高风险版本。 请优先输出你识别的风险项，不要给出修改后的代码，除非风险属于 极严重级别且不修改会导致直接安全问题。

我在一个电商项目的订单模块里做过实测。当时 Claude 生成了一段"用户取消订单"的接口，逻辑看起来完整，结果 Security Guard 一眼就看出来：它只校验了用户是否登录，但没有校验这个订单是否属于当前用户。这种水平越权问题如果靠人 review，难度还真不小，因为你要先看上下文、再看代码，才能意识到这里少了东西。但 AI 在配置好指令的情况下，反而更容易抓住这一类模式。

5.3 智能体 C：Unit Test Copilot（测试覆盖审查）

第三个智能体负责侦查测试覆盖情况。Claude 生成完代码之后，八成是不会主动帮你把测试补齐的，它在写代码的时候更关注"让功能跑通"，而不是"让功能被验证"。这个智能体就是用来专门盯着测试覆盖率。

它的配置是这样的：

# Agent: Unit Test Copilot 你的职责是评估当前改动的可测试性并给出最小测试计划。 不要直接生成全部测试代码，而是： 1. 找出被修改的核心函数和分支逻辑。 2. 识别哪些分支没有对应的测试用例。 3. 给出一个"最值得补的 3 个测试"清单，并解释理由。 4. 如果已有测试文件存在，检查它们是否覆盖了新增变更。 如果你发现某个函数的复杂度已经高到难以测试，请直接指出， 并建议是否应该拆分为更小的函数。

我推荐不要让它直接生成所有测试，而是先让它列清单。原因很实际：如果 AI 一口气给你写出 10 个测试文件，你很难有精力全部 review 一遍，而且测试代码本身可能也有 bug。但如果是先给清单、你再决定补哪个，整个流程就更可控。

实际跑下来，这个智能体还有一个额外好处：它能帮你发现"这次改动根本没法测"的场景。有一次 Claude 写了一个内部函数，直接依赖了环境变量和外部缓存，这个智能体直接标注了"该函数存在耦合，测试难度高，建议重构"，这时候你就知道不是缺测试文件，而是代码结构需要调整。

5.4 智能体 D：Architecture Watcher（架构一致性审查）

最后一个智能体也是我后知后觉才加上的。它检查的不是单行代码，而是这次改动和整体架构方向是否一致。比如：项目里明明约定用 Repository 模式访问数据，但 Claude 生成的代码却直接开了数据库连接，架构 watcher 就要把这种问题揪出来。

配置指令侧重于分层和边界：

# Agent: Architecture Watcher 你是项目的架构守卫。当收到改动时，请重点检查： - 本次改动是否遵循项目的分层架构（如 controller / service / repository）。 - 是否有跨层直接调用（如 controller 中直接写 SQL 或缓存操作）。 - 新增依赖是否有必要，是否破坏了模块边界。 - 是否使用了与项目统一的错误处理和返回格式。 - 是否符合既定的目录组织约定。 输出时请按照"架构违背 / 建议重构 / 风格偏差"三级进行分类。

这个智能体在一个微服务项目里帮我逮到过一个问题。Claude 生成了一个新的查询接口，直接在 Controller 里拼了一个查询字符串去查数据库，完全绕开了项目里现成的查询服务层。单看接口功能是好的，但放回整个架构体系里，这就是一个明显的分层破坏。以前这种问题要等到架构师 review 才能发现，现在提交前就能被拦下来。

6. 把 4 个智能体串成一条 CI 工作流

到这里你可能会想，4 个智能体都是独立的，难道我要一个个手动跑？其实不用。我在项目里把它们串成了一个流水线脚本，每次提交代码到 feature 分支后自动触发，跑完之后把结果汇总到一个 markdown 报告里。

大致的流程是这样的：

1. 获取当前分支和 main 分支之间的 diff 文件列表。
2. 按优先级依次调用 Code Quality、Security Guard、Architecture Watcher。
3. 再跑一次测试目录对比，调用 Unit Test Copilot。
4. 把 4 份输出汇总到review-report.md。
5. 如果检测到 Critical 级别问题，脚本返回非零退出码，提醒你处理。

这个流水线可以用很轻的方式实现，核心就是一个 shell 脚本加几个参数：

codex exec --agent code-quality "审查 diff 文件：$(git diff --name-only main...HEAD)" codex exec --agent security-guard "审查同一批 diff，侧重安全问题" codex exec --agent architecture-watcher "检查架构一致性" codex exec --agent unit-test-copilot "给出测试补充建议"

有个细节需要注意：串行跑比并行跑更稳。并行确实能节省时间，但多个 Codex 进程同时读同一批文件时，偶尔会出现输出相互污染的情况。我这个方案本来就是给提交前用的，多等一两分钟完全无所谓，稳定更重要。

7. 实际效果与调参经验

上面这套配置我用了大概两个月，覆盖三个不同项目。整体效果可以总结成三句话：低级错误大幅减少，CR 阶段的争论变少，开发节奏更顺了。

先说数据。我自己做了个小统计：启用之前，大概 30% 的 PR 会被同事驳回返工；启用之后，这个比例降到了大约 8%。当然，这里面有一部分原因是自己在写代码的时候更小心了，但自动化 review 把最浅层的那些问题都挡在了提交前，这是实实在在的。

再来说说调参过程中的经验。初学者最容易犯的错，是提示词写得太泛。比如你直接跟 Codex 说"帮我审查一下代码"，它给出的反馈也会很泛——大概率的输出是"整体代码质量不错，建议优化命名"。这种反馈没有任何价值。你需要明确告诉它"不要夸我，只看问题；按严重程度分级；每条必须给出文件位置"。这些都是我在踩了两次坑之后才固定下来的配置。

另外一个经验是模型参数调整。做 Review 类的任务，temperature建议调低一点，别让它太有"创造力"。我一般会控制在 0.2 以下，这样它输出的判断比较稳定。如果让它在审查代码时充分发挥想象力，它很可能会给你"脑补"出一些并不存在的问题，反而干扰判断。

还有一点是关于 token 长度。大项目 diff 文件很多，一次性全塞进去，输出质量会明显下降。我的做法是限制每次审查的文件数量，按优先级分批跑。比如核心业务文件优先，配置文件可以跳过。如果你审核的文件范围太大，不如拆成几次来做，效果会好很多。

8. 遇到的问题和排查思路

8.1 Codex 插件无法加载本地路径

我第一次配置时，怎么都跑不起来，报错信息跟网络和代理相关。我排查了一圈发现不是模型的问题，而是它在尝试访问某个本地服务时失败。后来我把相关的环境变量检查了一遍，发现是代理配置影响了本地请求。处理办法是在运行命令前清掉多余的环境变量，或者直接把代理关掉再跑。这类问题的根因通常不是 Codex 本身，而是系统的网络栈和它不兼容。

如果你遇到类似的诡异报错，建议先试最基础的办法：在干净的环境里跑一次codex exec，什么都不带，只让它读一个文件。如果这样也能失败，那就不是指令或插件配置的问题，而是安装或环境的问题。

8.2 智能体不遵守"只审查不改代码"的指令

这个问题我一定要单独提出来。我一开始写配置的时候，只写了"你是代码审查员"，没有强调"你不修改任何文件"。结果 Codex 在审查过程中顺手帮我"修复"了几处代码缩进，还改了变量名。这种问题非常隐蔽，因为代码看起来确实变好了，但你在 review 的时候找不到原始版本的对比，很容易就直接 commit 了。

处理办法很简单，就是在智能体配置里加上强约束，并且用否定句式：不要告诉我你改了什么，也不要执行任何写操作。如果有必要，我推荐你在跑完审查之后用 Git diff 确认一下没有任何改动。安全第一。

8.3 报告太长看不完

还有个尴尬的问题：4 个智能体的短评汇总起来，报告可能比代码本身还长。第一次跑完，我打开 review-report.md，密密麻麻几千行，根本看不下去。

后来我做了两个调整。第一个是要求每个智能体的输出限制条数：Critical 最多 5 条，Warning 最多 10 条，其余多余的只提总数。第二个是让脚本自动过滤掉 Suggestion 级别的内容，只在报告中显示 Critical 和 Warning。这样一来，报告控制在了一屏以内，每天看反馈成了很轻松的事。

8.4 在 CI 上运行时模型不稳定

我在 GitHub Actions 上尝试把这个流程接入 CI，但发现模型行为有时不稳定：同样的代码，这次审查和上次审查给出的结论略有不同。这其实是概率模型的正常现象，但在 CI 场景里，不稳定就意味着不可信。

我的折中方案是：先把自动化 review 用在本地提交前阶段，作为"预备审查"，真正跑在 CI 里的还是传统测试和规范检查。这样既保留了灵活性，又不会让模型的不稳定性变成流水线的阻塞点。如果你想完全自动化，至少需要保证你的指令非常明确、输出格式强制固定，并且要接受偶尔的重跑成本。

9. 这套方案能给你的项目带来什么

我在开头说过，这个方案的初衷是解决"AI 写的代码没人审"的问题。用了两个月之后，我认为它的价值已经远超"补位"本身。它让你对 Claude 生成的代码更有掌控感，也让团队里的 Code Review 从一件"没人想接的额外工作"变成了一件"机器已经帮你过滤过一遍的事"。

当然，我并不认为 AI 审查能替代人的判断。架构上的一些长期决策、业务语义上的合理性判断，这些仍然需要资深工程师把关。但在"低垂果实"层面——代码规范、明显 bug、安全红线、测试缺失——这套方案的作用非常明显。它把这些事变得随叫随到，你就不用每次都在心里默默祈祷 Claude 这次没有埋雷。

我个人实际用下来的体会是：不要指望一次配好就一劳永逸，智能体配置一定要跟着项目的运行节奏去调。你跑得越勤，越了解它会漏掉什么，然后针对性补强，那个版本才是最适合你项目的。

如果你手头也正被 AI 写代码的后续审查问题困扰，不妨按这套思路搭一下。最先跑通一个代码质量的智能体就行，不用一上来就上全套。等你觉得有效果了，再慢慢把安全、测试、架构这几个维度加进来。你会发现，AI 自动写代码之所以让人既兴奋又害怕，并不是因为它能力不足，而是因为我们的流程还没跟上。这些工具和配置，就是把流程补上的那一块拼图。