# AI Coding生成的代码能交付吗？一张业务单的验收方法

AI生成了列表、详情、接口和SQL，页面也能提交。接下来该不该交付？

我们的判断是：先检查这张单据的数据和状态能否经得住重开、换人和重复操作，再看页面是否漂亮。对于有金额、明细和审批的企业功能，第一次提交成功只是验收的开始。

下面以设备维修申请教学开发为例。它在隔离环境里完成了一次正式提交及多人审批，随后补做了两项负向接口检查。本文不再复述开发步骤，而是打开实际代码，说明审稿人应该追问哪些问题，以及哪些结论还不能从已有记录中得出。

![AI Coding业务单据验收地图](https://developer.qcloudimg.com/http-save/yehe-12798805/a2e1e9916542414deb2d91966f8a95e0.png)

*代码审查围绕身份、数据、事务和流程展开，每条判断都应落到具体操作或实现。*

## 先写出验收目标，避免“看起来没问题”

这张维修单的业务目标很有限：申请人录入设备和维修项目，保存草稿，提交给负责人及财务，最后回查结果。它不处理维修执行、库存扣减或实际付款。

教学数据有两条明细，金额分别980元和300元，合计1280元，并带一个附件。验收时一直跟踪同一张单据，没有发现问题就重新申请一张“成功样例”替代。

![保存后的维修申请草稿](https://developer.qcloudimg.com/http-save/yehe-12798805/967522e7de2f372127c4299e22cb57c0.png)

*[实测·历史教程] 草稿是可以重新读取的数据对象，不能只验证表单在浏览器中暂时还保留输入。*

先给这张单据写一个简短的验收合同：谁可以编辑，什么状态可以编辑，哪些输入允许为空，金额谁计算，提交后谁处理，完成后怎样回查。没有这份约定，测试看到任何结果都可能被解释成“系统就是这样设计的”。

## 草稿与提交共用代码，不代表共用校验要求

实际服务把保存与提交分成两个入口，再进入同一套持久化逻辑。摘自`TutorialRepairBillServiceImpl.java`：

```java
@Override
@Transactional(rollbackFor = Exception.class)
public Long saveTutorialRepairBill(TutorialRepairBillSaveReqVO saveReqVO) {
    return persist(saveReqVO, false);
}

@Override
@Transactional(rollbackFor = Exception.class)
public Long submitTutorialRepairBill(TutorialRepairBillSaveReqVO saveReqVO) {
    return persist(saveReqVO, true);
}
```

`persist`在正式提交时调用`validateSubmit`，检查设备、故障、地点、日期以及有效明细。草稿可以不完整，提交不能绕过这些规则。

审查时不要只看前端星号。可以要求测试分别留下三种结果：不完整草稿能保存；重开草稿能恢复已填内容；相同内容直接提交时，被服务端按规则拦截。前端提示和服务端拦截是两份证据。

本课完成了草稿持久化和正常提交的操作验证。若准备转成生产功能，仍应补齐空字段、非法明细等输入组合的接口用例，不能因为代码里写了校验，就把所有分支都记为已测试。

身份和状态也必须由后端判断。实现读取当前登录用户，与已有单据制单人比较，并限制可编辑状态。教学补测中，非制单人修改、本人修改已通过单据均返回400，主表与明细未变化。

这里“未变化”很重要：只看到接口报错，还不能排除代码已经写入一部分数据。负向测试的验收对象同时包含返回结果与保存后的状态。

## 金额正确之后，再追问“哪一层算出来的”

页面实时汇总有助于填写，但服务端不能直接相信浏览器传来的总额。本课后端用`BigDecimal`重新计算每行数量乘单价，再累加预算。

实际计算顺序是每行保留两位小数、采用`HALF_UP`，然后把行金额相加。这个顺序是业务规则的一部分：先逐行舍入与先汇总再舍入，在存在更多小数位时可能得到不同结果。

![维修明细与预算金额](https://developer.qcloudimg.com/http-save/yehe-12798805/30975c4a1ad5948ce765a82b1c12c938.png)

*[实测·历史教程] 1280元证明本组正常输入的结果；不能据此宣称所有精度、边界和异常输入都验证完成。*

审查金额逻辑可以顺着四个问题展开：数量是否允许为零，单价能否为零，空白行是否参与计算，小计和总额是否由同一规则生成。

本课提交校验要求数量大于0，单价不小于0，并跳过没有业务内容的行。这与“所有单价必须大于0”不是同一条规则。若采购业务要求不允许零价，就应该改业务需求与校验，而不是由生成工具自行猜测。

后续可以在隔离环境补测小数边界、负数、空行以及客户端篡改总额。它们是建议增加的测试，不是这次教程已经跑过的结果。

## 主子表保存：一段很短的代码，可能决定后续扩展方式

这次源码审查中，值得单独拿出来看的是明细保存策略。`replaceItems`先删除原单明细，再重新生成有效行。下面节选两个关键动作：

```java
tutorialRepairBillItemMapper.physicalDeleteByBillId(billId);
```

```java
TutorialRepairBillItemDO itemDO = BeanUtils.toBean(item, TutorialRepairBillItemDO.class);
itemDO.setId(null);
itemDO.setBillId(billId);
itemDOs.add(itemDO);
```

这是一种整组替换方式。对本课这种没有外部明细引用的教学单据，理解和实现比较直接；但它不保留每次保存前的明细行ID。

如果以后采购收货、付款分摊或审计记录需要引用某一条维修明细，就要重新评估这种策略。不能仅因主表ID没变，便认为每条明细的身份也稳定。

这正是代码审查比页面验收多出来的价值。页面显示两行，保存后仍显示两行，视觉效果可能完全相同；但数据库里是更新了原行，还是删除后重建，对后续系统集成有明显影响。

审查人可以要求开发者说明三件事：明细有没有外部引用，行ID是否属于业务身份，历史变化是否需要追踪。如果答案不同，保存方式就可能需要从整组替换改为按行增删改。本文只分析当前实现，不把后者写成已完成能力。

## 有事务注解，还需要检查事务之外的动作

保存与提交入口标有`@Transactional`。在主路径里，服务先写主表、替换明细，提交时发起流程并写回实例ID，然后保存附件关联。

这给出了审查顺序，却不能单凭注解就宣布整个操作绝对原子。流程接口是否参与同一事务、附件关联与实际文件存储如何配合、异常是否向外抛出，都需要继续检查。

例如已有文件上传成功，业务保存失败，文件是否保留、关联是否恢复，属于附件生命周期问题。数据库事务不会自动替所有外部存储完成回滚。

![维修申请附件上传成功的真实画面](https://developer.qcloudimg.com/http-save/yehe-12798805/6b090b1ece7bcb79778c6a1441d7765d.png)

*[实测·历史教程] 这里显示文件上传成功，尚不能单凭此弹窗证明业务关联已保存；本课另核对了正常路径中的附件回显。失败与清理需要专门验证。*

同样，状态校验可以拒绝不允许修改的单据，但不能仅凭这一段代码推导并发重复提交已经解决。两次请求同时进入时是否会创建多个流程，需要看锁、幂等或其他并发控制机制，并在隔离环境验证。本课没有把并发压测记为通过。

把这些问题列出来，不是要求一次教学实现覆盖全部生产场景，而是防止“代码已经生成”变成省略设计讨论的理由。

## 首次打开的页面，和刷新后的页面要分别看

本课实际遇到过：审批接口已经返回两行明细，负责人第一次打开页面却看到空表。问题发生在表格挂载时序，修复限定在业务组件中，先写入表格数据选项，等挂载后再刷新。

`info/index.vue`还区分普通详情与审批内嵌详情的数据入口：

```typescript
const data = await (props.isApproval || props.processInstance
  ? getTutorialRepairBillForBpm(id)
  : getTutorialRepairBill(id));
formData.value = { ...data };
itemList.value = data.items || [];
```

同一个业务对象有不同入口，测试就应该覆盖这些入口。只在申请人页面看见明细，不能替负责人审批页面签收；刷新后正常，也不能覆盖首次加载失败。

![审批中心内嵌显示维修内容](https://developer.qcloudimg.com/http-save/yehe-12798805/002970f92c0f51baa7116231ad3e4abd.png)

*[实测·历史教程] 审批页应显示与原单一致的明细和附件。本课沿原流程继续复查，没有重新造单绕过加载问题。*

权限也要沿入口区分：普通详情、审批详情、列表可见范围分别有什么约束。当前教学记录证明了指定用户的正常操作及两项修改拒绝，不能推广为所有读取接口、租户与角色组合都安全。

## 用一张验收表，把已证明和待补测分开

代码审查完成后，可以交出下面这样的结果，而不是一句“已测试”。

| 检查项 | 本课证据 | 转为生产功能时继续补什么 |
|---|---|---|
| 正常保存与提交 | 同一单据、两行明细、一个附件 | 空值及非法明细输入组合 |
| 身份与状态 | 两类非法修改被拒绝，数据不变 | 更多角色、读取范围与租户组合 |
| 金额 | 980+300=1280；源码重算 | 小数边界、篡改输入及金额上限 |
| 主子表 | 已读到整组替换实现 | 外部行引用与历史追踪需求 |
| 审批展示 | 首次挂载问题修复并复查 | 不同入口和网络异常 |
| 一致性 | 正常流程结束后回写 | 并发提交、故障注入与附件失败 |

本课Java改动编译、前端格式与ESLint检查通过；没有完成全仓类型检查，也没有完整录制拒绝和撤回案例。把这些项目留在待办里，比给所有检查统一打勾更有助于下一位接手者。

## 宇擎建议：让AI产出代码，也产出可核验的说明

让AI Coding完成需求时，可以同时要求它列出：规则所在的方法、数据写入顺序、失败路径、外部副作用，以及尚未验证的用例。开发者据此对照实际代码，删掉没有实现的承诺，再挑最影响业务的场景运行。

对于需要快速开发标准业务单据的团队，这种方式可以把评审从逐行看所有文件，聚焦到身份、状态、金额、明细和集成边界。对于涉及资金、库存或跨系统副作用的功能，则不适合只凭一次顺利的教学演示决定上线。

AI生成代码之后，最有价值的问题往往不是“还能加多少功能”，而是：**这段实现依赖哪些假设，假设改变后，哪条数据或哪次操作会先出问题？** 把答案落实成验收表，代码才有清楚的交付边界。

我们的判断是：先检查这张单据的数据和状态能否经得住重开、换人和重复操作，再看页面是否漂亮。对于有金额、明细和审批的企业功能，第一次提交成功只是验收的开始。

AI Coding生成的代码能交付吗？一张业务单的验收方法

从真实维修单开发材料中检查草稿、服务端计算、明细替换、事务和审批回查，把AI代码评审落实为能够执行的验收表。

人工智能

AI代码交付验收需围绕数据持久性、状态权限、金额计算与流程一致性展开，重点验证草稿重载、非法操作拦截及明细整组替换逻辑。审批页面须独立测试首次加载与刷新场景，确认附件回显。事务注解不保证外部存储原子性，并发与失败回滚需补充测试。交付结论应区分已证证据与待补用例，明确业务假设边界。

文件存储

代码解释

数据库

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI Coding生成的代码能交付吗？一张业务单的验收方法-腾讯云开发者社区-腾讯云

AI Coding生成的代码能交付吗？一张业务单的验收方法

AI Coding生成的代码能交付吗？一张业务单的验收方法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐