代码生成之后，我如何做编译、接口验证和验收

从 2025 年 12 月开始开发 HAOVP 后，Codex 逐渐参与代码实现、局部重构、测试补充、问题排查和文档整理。但代码生成完成，只代表得到了一份待验证的变更，不代表功能已经完成。

在这套协作里，我负责需求理解、技术与架构决策、任务拆解、上下文组织、代码审查、测试判断、前后端联调和最终验收。Codex 可以加快实现，但是否接受一项变更，仍要由我根据代码、构建和运行结果判断。

先确认生成代码解决的是正确问题

开始看代码前，我先回到需求本身：

输入是什么
正常结果是什么
哪些请求必须拒绝
会修改哪些数据
失败时怎样回滚或补偿
与哪些服务和前端页面有关

如果任务定义不清楚，即使代码能够编译，也可能实现了错误的规则。比如“公开资料接口”不等于整个用户模块都可以匿名访问；“统计消息降级”也不等于消息失败时所有数据都已完整更新。

因此，我会先检查变更是否符合业务边界，再判断实现细节。

阅读差异，而不是只看最终文件

AI 可能一次修改多个文件。直接打开最终代码容易漏掉无关改动，我更习惯先看差异：

git status
git diff --stat
git diff

检查重点包括：

• 是否只改了任务需要的模块；
• 公共 DTO 或接口签名是否影响其他服务；
• 是否意外删除原有校验；
• 异常是否被静默吞掉；
• 事务边界是否扩大；
• 是否引入硬编码地址、密码或测试数据；
• 日志是否泄露 Token 和个人信息；
• 新增依赖是否真的需要。

命名和代码风格也要与项目现有习惯一致，但格式正确不能代替逻辑正确。

编译是第一道机械检查

代码审查后，我先让项目完成编译和打包：

mvn clean package

具体是否运行全部测试要按项目当前状态决定。构建至少能发现：

• 类型、导包和方法签名错误；
• 模块依赖不完整；
• 接口修改后调用方没有同步；
• 资源文件或配置无法加载；
• 测试代码不能编译。

但“BUILD SUCCESS”只说明构建过程完成，不说明接口权限、数据库副作用和跨服务调用正确。

前端也需要独立检查：

npm run build

类型检查和生产构建能够发现一部分接口字段、组件属性和路由问题，却仍不能代替浏览器中的真实交互验证。

确认运行的就是刚构建的代码

4 月验收中，我发现部分容器运行的是旧 JAR，与本地源码不一致。这让我把版本核对放到接口测试之前：

源码状态
    -> 新 JAR
    -> 新镜像
    -> 重新创建的容器
    -> 启动日志和版本信息

只重启容器不会重新编译代码；只生成 JAR 也不会自动替换镜像。若运行版本不明确，后面的成功与失败都无法准确归因。

接口验证同时覆盖允许和拒绝

功能接口不能只测成功路径。以认证和权限为例，我会同时验证：

• 合法身份能够完成操作；
• 缺少必要校验信息时被拒绝；
• 普通用户不能调用内部管理接口；
• 资源所有者与非所有者得到不同结果；
• 被禁用账号不能继续登录；
• 无效或过期状态得到明确响应。

用例是否通过，要比较实际结果和预期，而不是机械要求 HTTP 状态全部为 200。

boolean passed = actualHttp == expectedHttp
        && businessStateMatches()
        && sideEffectMatches();

这是通用判断结构，不对应真实验收脚本。

响应正确还要检查副作用

接口返回成功只是表面结果。写操作还要检查：

• 数据是否写入正确表；
• 外键和资源归属是否正确；
• 事务失败时是否回滚；
• 重复请求是否产生重复数据；
• 派生计数是否只更新一次；
• 异步任务失败后是否留下可追踪记录；
• 后续查询能否读回刚才的变更。

4 月验收中出现过跨服务返回值判断、收藏数锁等待、审核身份透传、外键指向和 MyBatis 映射等问题。这些问题有些接口可以返回，有些代码也能编译，只有结合数据和业务前提才会暴露。

分批验收比一条长脚本更容易定位

HAOVP 后端验收最终分为三批：认证与用户、内容评论推荐、后台管理。三份结构化结果分别记录 29、63 和 23 个用例，合计 115 个，均符合预期。

分批的价值在于：

• 每批可以独立准备数据；
• 某个请求失败不会让全部结果失去意义；
• 修复后可以只重跑相关链路；
• 模块之间的前置依赖更清楚；
• 结果可以用 JSON 再次统计。

这个 115/115 只代表当时单机 Docker Compose 环境中的 115 个预设用例符合预期。它不等于全部接口、所有参数、高并发、多节点故障和前端交互都已经验收。

失败时先判断是哪一层

接口失败后，我不会立即让 AI 再改一次代码，而是先定位层级：

需求或测试前提错误
源码逻辑错误
构建产物过期
容器或配置未更新
网关与权限规则错误
跨服务调用错误
数据库约束或事务问题
消息、缓存或对象存储异常

例如，评论置顶失败曾与测试身份和资源关系有关；旧 JAR 则是运行版本问题。若不先分层，AI 很容易根据错误现象继续修改无关代码。

我会把日志、最小复现步骤和已经确认的事实组织成上下文，再让 Codex 辅助分析或实现局部修复。最终仍要重新审查差异、构建和复测。

修复后要防止只验证原错误

修复一个失败用例后，至少要检查三类结果：

• 原失败是否消失；
• 相邻正常功能是否仍然正常；
• 权限、事务和数据边界是否被放宽。

例如调整公开接口白名单后，不仅要看公开查询是否成功，还要确认写接口和内部管理接口仍受保护。修改异步回写后，也不能只看响应变快，还要检查主记录和派生计数是否一致。

这就是回归验证。没有回归，局部修复可能只是把问题移动到另一个路径。

AI 输出也要经过安全检查

发布前我会扫描：

• 数据库连接、内部域名和 IP；
• 账号、密码、Token 与密钥；
• 测试用户和资源 ID；
• 本地绝对路径；
• 日志中的请求正文和认证头；
• 默认凭据和示例配置。

即使这些值来自现有文件，AI 在整理代码或文档时也不应该把它们带进公开内容。发现默认凭据时，应转为环境变量或密钥注入，并进行轮换。

我怎样判断可以验收

我会按一条连续证据链判断：

需求边界明确
    -> 代码差异经过审查
    -> 后端与前端构建通过
    -> 运行版本与源码一致
    -> 正向和负向接口符合预期
    -> 数据副作用正确
    -> 相关链路完成回归
    -> 敏感信息已清理
    -> 未覆盖范围已记录

其中任何一项缺失，都应该明确为待验证，而不是为了结束任务直接标记完成。

最终责任为什么不能交给生成工具

Codex 不知道所有隐含业务规则，也无法仅从局部代码判断生产数据、权限关系和部署环境。它生成的实现可能语法正确，却使用了错误前提；它给出的测试也可能只覆盖自己刚写的代码路径。

我需要对以下判断负责：

• 需求是否被正确理解；
• 技术方案是否适合当前项目；
• 修改范围和风险是否可接受；
• 测试是否覆盖关键边界；
• 结果是否足以支持结论；
• 是否仍有需要公开说明的限制。

代码生成之后，真正的工程工作才进入审查、构建、运行、验证和验收阶段。AI 可以缩短实现和排查时间，但只有把每个结论接到可重复的证据上，生成的代码才会成为项目的一部分，而不是一段看起来完整的答案。