AI 辅助研发中，为什么最终责任仍然在开发者

从 2022 年第一次接触 ChatGPT，到现在使用 Codex 辅助 HAOVP 开发，我对 AI 的使用已经从对话和学习，逐步走到代码理解、SQL 与接口分析、问题排查、需求拆解、代码实现、测试补充和文档整理。

工具能做的事情越来越多，但最终责任没有从开发者身上移开。相反，当 AI 可以一次生成更多代码、修改更多文件时，开发者需要判断的范围也更大。

我的 AI 使用方式是怎样变化的

这几年的变化并不是突然出现一套完整流程。

2022
    -> 对话、学习和了解生成式 AI

2023
    -> 学习、代码理解、问题分析和文档辅助

2024
    -> SQL、接口分析、代码排查和资料整理

2025
    -> 更稳定地用于需求拆解、联调、问题和文档

2025 年 12 月以后
    -> Codex 参与 HAOVP 的实现、重构、测试补充和排障

早期使用方式比较简单，不能把现在的工程协作流程提前放进 2022 或 2023 年。到 HAOVP 阶段，AI 才真正进入较完整的研发链路。

辅助实现不等于承担责任

在 HAOVP 中，我负责：

• 理解需求和确定业务边界；
• 做技术和架构决策；
• 拆分任务并组织上下文；
• 审查代码和修改范围；
• 判断测试是否充分；
• 完成前后端联调；
• 决定是否通过最终验收。

Codex 辅助：

• 生成或修改局部代码；
• 做局部重构；
• 补充测试结构；
• 分析错误和排查方向；
• 整理文档和部署说明。

这两组工作可以相互配合，但不能交换责任。AI 不会因为生成了代码，就自动理解所有业务后果；也不会因为给出测试，就自动证明测试覆盖了真正风险。

需求责任仍在开发者

AI 只能根据提供的上下文工作。如果需求中遗漏了权限、状态流转或数据边界，它可能生成一套内部自洽、业务上却错误的实现。

我需要先回答：

谁可以执行这个操作
操作前需要什么状态
成功后哪些数据变化
失败时怎样回滚
是否允许重复请求
与其他服务有什么关系
哪些信息可以公开

例如，“开放用户资料查询”不能被理解为取消整个用户模块的认证；“评论置顶”还要验证操作者身份和评论所属资源。上下文没有写清楚，代码看起来完整也可能放宽权限。

架构选择不能由局部代码决定

AI 很擅长根据局部目标给出实现，但架构选择需要知道全局约束。

把一次跨服务计数更新改成异步调用，可能缩短主请求，却引入失败补偿和重复计数；增加缓存可能降低查询压力，却多出一致性和失效问题；增加一个副本可能改善恢复能力，却不等于自动切换。

开发者需要判断：

• 这项数据是否要求强一致；
• 失败是否可重试；
• 是否能从明细重建；
• 运维复杂度是否可接受；
• 当前项目是否真的需要新组件；
• 方案有没有可验证的方法。

代码能运行，只是架构判断的一部分。

代码审查不能只检查语法

AI 生成的代码通常可以很快达到语法正确，但审查还要看：

• 事务边界是否合理；
• 远端调用是否放在本地事务中；
• 包装类型和值比较是否正确；
• 异常是否被吞掉；
• 日志是否包含敏感信息；
• 默认值是否会进入生产环境；
• 并发与重试是否幂等；
• 公共接口变更是否影响其他模块；
• 回滚和兼容方式是否存在。

4 月接口验收中出现的旧 JAR、状态码比较、锁等待、审核身份透传、外键和 MyBatis 映射问题，都说明编译通过并不足以证明实现正确。

测试设计不能只让 AI 自证

让生成代码的同一个上下文同时生成测试，很容易让测试沿着实现假设前进。如果实现和测试共享同一个错误前提，测试可能全部通过。

我会从业务结果反向设计用例：

正常请求是否成功
缺少必要条件是否拒绝
无权限身份是否拒绝
重复请求是否安全
事务失败是否回滚
异步失败是否可追踪
数据是否写入正确位置
后续查询是否与写入一致

还要有独立的负向用例和副作用检查。HTTP 返回 200 不是唯一判断，预期被拒绝的请求得到 400 或 403 也可能是正确结果。

通过率必须带上测试范围

HAOVP 的一轮后端验收中，三批共 115 个预设用例均符合预期。这个结果可以说明当时环境中的指定链路通过了这些检查。

它不能证明：

• 所有接口和参数组合都被覆盖；
• 前端全部交互已经验证；
• 高并发和长期运行稳定；
• 多节点故障切换成功；
• 消息、缓存、数据库和对象存储没有已知边界；
• 系统已经达到生产质量。

开发者对外说明结果时，需要同时说明环境、版本、用例范围和未覆盖部分。数字如果脱离口径，会比没有数字更容易误导。

运行环境也属于责任范围

源码正确不代表运行的是这份源码。旧 JAR 问题让我把版本链加入验收：

源码
    -> 构建产物
    -> 镜像
    -> 运行容器
    -> 实际流量入口

AI 修改代码后，开发者仍要确认构建成功、镜像更新、容器重建和接口行为对齐。否则测试的可能是另一份旧版本。

配置同样如此。Nacos、环境变量和本地配置有不同优先级，修改了一个未被加载的文件，运行行为不会变化。

数据安全不能交给自动生成

AI 可能从项目上下文中看到：

• 数据库连接和内部地址；
• 账号、密码、Token 与密钥；
• 测试用户和资源标识；
• 日志中的请求内容；
• 对象存储路径和桶配置；
• 本地绝对路径。

这些信息不能因为出现在仓库里，就自动进入代码示例、测试日志或公开文档。

开发者需要做敏感值扫描、密钥轮换和脱敏审核，也要控制提供给工具的上下文范围。真实生产数据不应该用于无必要的生成或调试。

AI 建议需要可验证

遇到问题时，AI 可以给出多个排查方向，但我会把建议转成可验证假设：

假设：运行容器使用旧 JAR
验证：核对源码、JAR、镜像和容器版本

假设：公开接口被认证规则拦截
验证：比较网关规则、服务安全配置和正负向请求

假设：消息发送失败导致统计缺口
验证：区分主表降级和每日统计，并检查消息与消费日志

假设只有经过证据验证，才能成为结论。不能因为解释听起来合理，就直接继续修改代码。

什么时候应该拒绝 AI 的方案

我会拒绝或重做以下方案：

• 需要虚构业务规则才能成立；
• 为了让接口返回成功而伪造数据；
• 把写操作失败包装成成功；
• 通过删除权限校验解决访问问题；
• 把密码、Token 或地址写进代码；
• 使用未经确认的生产数据；
• 通过无限重试掩盖依赖故障；
• 用复杂组件解决当前不存在的问题；
• 无法设计验证和回滚方法。

生成速度不是接受方案的理由。越容易生成大量改动，越要控制范围。

责任需要一条证据链

我会用一条证据链决定任务是否完成：

需求和边界明确
    -> 方案经过选择
    -> 代码差异经过审查
    -> 编译与测试通过
    -> 运行版本一致
    -> 接口和副作用符合预期
    -> 回归验证完成
    -> 安全与脱敏检查完成
    -> 未覆盖范围已记录

其中任何一环缺失，都只能标为待验证或部分完成。

这条链不是为了降低 AI 的价值，而是让 AI 产生的内容能够进入真实工程。没有审查和证据，生成结果只是候选答案；经过验证，它才成为可维护的代码、测试或文档。

最终责任意味着什么

最终责任不等于开发者必须亲手敲下每一行代码，而是开发者要能解释并承担每项决策：

• 为什么要这样实现；
• 哪些边界已经验证；
• 哪些风险仍然存在；
• 出错后如何定位和恢复；
• 对用户和数据会产生什么影响。

AI 可以帮助我更快地实现、比较方案和整理信息，但不能代替我确认事实、判断结果和承担后果。

到 6 月 20 日，我对 AI 辅助研发的理解已经很明确：工具能力会继续变化，开发流程也会继续调整，但需求、架构、代码、数据、安全和验收的最终责任仍然在开发者。只有责任边界清楚，AI 带来的效率才不会以失去可控性为代价。