AI Coding生成的代码能交付吗一张业务单的验收方法AI生成了列表、详情、接口和SQL页面也能提交。接下来该不该交付我们的判断是先检查这张单据的数据和状态能否经得住重开、换人和重复操作再看页面是否漂亮。对于有金额、明细和审批的企业功能第一次提交成功只是验收的开始。下面以设备维修申请教学开发为例。它在隔离环境里完成了一次正式提交及多人审批随后补做了两项负向接口检查。本文不再复述开发步骤而是打开实际代码说明审稿人应该追问哪些问题以及哪些结论还不能从已有记录中得出。代码审查围绕身份、数据、事务和流程展开每条判断都应落到具体操作或实现。先写出验收目标避免“看起来没问题”这张维修单的业务目标很有限申请人录入设备和维修项目保存草稿提交给负责人及财务最后回查结果。它不处理维修执行、库存扣减或实际付款。教学数据有两条明细金额分别980元和300元合计1280元并带一个附件。验收时一直跟踪同一张单据没有发现问题就重新申请一张“成功样例”替代。[实测·历史教程] 草稿是可以重新读取的数据对象不能只验证表单在浏览器中暂时还保留输入。先给这张单据写一个简短的验收合同谁可以编辑什么状态可以编辑哪些输入允许为空金额谁计算提交后谁处理完成后怎样回查。没有这份约定测试看到任何结果都可能被解释成“系统就是这样设计的”。草稿与提交共用代码不代表共用校验要求实际服务把保存与提交分成两个入口再进入同一套持久化逻辑。摘自TutorialRepairBillServiceImpl.javaOverrideTransactional(rollbackForException.class)publicLongsaveTutorialRepairBill(TutorialRepairBillSaveReqVOsaveReqVO){returnpersist(saveReqVO,false);}OverrideTransactional(rollbackForException.class)publicLongsubmitTutorialRepairBill(TutorialRepairBillSaveReqVOsaveReqVO){returnpersist(saveReqVO,true);}persist在正式提交时调用validateSubmit检查设备、故障、地点、日期以及有效明细。草稿可以不完整提交不能绕过这些规则。审查时不要只看前端星号。可以要求测试分别留下三种结果不完整草稿能保存重开草稿能恢复已填内容相同内容直接提交时被服务端按规则拦截。前端提示和服务端拦截是两份证据。本课完成了草稿持久化和正常提交的操作验证。若准备转成生产功能仍应补齐空字段、非法明细等输入组合的接口用例不能因为代码里写了校验就把所有分支都记为已测试。身份和状态也必须由后端判断。实现读取当前登录用户与已有单据制单人比较并限制可编辑状态。教学补测中非制单人修改、本人修改已通过单据均返回400主表与明细未变化。这里“未变化”很重要只看到接口报错还不能排除代码已经写入一部分数据。负向测试的验收对象同时包含返回结果与保存后的状态。金额正确之后再追问“哪一层算出来的”页面实时汇总有助于填写但服务端不能直接相信浏览器传来的总额。本课后端用BigDecimal重新计算每行数量乘单价再累加预算。实际计算顺序是每行保留两位小数、采用HALF_UP然后把行金额相加。这个顺序是业务规则的一部分先逐行舍入与先汇总再舍入在存在更多小数位时可能得到不同结果。[实测·历史教程] 1280元证明本组正常输入的结果不能据此宣称所有精度、边界和异常输入都验证完成。审查金额逻辑可以顺着四个问题展开数量是否允许为零单价能否为零空白行是否参与计算小计和总额是否由同一规则生成。本课提交校验要求数量大于0单价不小于0并跳过没有业务内容的行。这与“所有单价必须大于0”不是同一条规则。若采购业务要求不允许零价就应该改业务需求与校验而不是由生成工具自行猜测。后续可以在隔离环境补测小数边界、负数、空行以及客户端篡改总额。它们是建议增加的测试不是这次教程已经跑过的结果。主子表保存一段很短的代码可能决定后续扩展方式这次源码审查中值得单独拿出来看的是明细保存策略。replaceItems先删除原单明细再重新生成有效行。下面节选两个关键动作tutorialRepairBillItemMapper.physicalDeleteByBillId(billId);TutorialRepairBillItemDOitemDOBeanUtils.toBean(item,TutorialRepairBillItemDO.class);itemDO.setId(null);itemDO.setBillId(billId);itemDOs.add(itemDO);这是一种整组替换方式。对本课这种没有外部明细引用的教学单据理解和实现比较直接但它不保留每次保存前的明细行ID。如果以后采购收货、付款分摊或审计记录需要引用某一条维修明细就要重新评估这种策略。不能仅因主表ID没变便认为每条明细的身份也稳定。这正是代码审查比页面验收多出来的价值。页面显示两行保存后仍显示两行视觉效果可能完全相同但数据库里是更新了原行还是删除后重建对后续系统集成有明显影响。审查人可以要求开发者说明三件事明细有没有外部引用行ID是否属于业务身份历史变化是否需要追踪。如果答案不同保存方式就可能需要从整组替换改为按行增删改。本文只分析当前实现不把后者写成已完成能力。有事务注解还需要检查事务之外的动作保存与提交入口标有Transactional。在主路径里服务先写主表、替换明细提交时发起流程并写回实例ID然后保存附件关联。这给出了审查顺序却不能单凭注解就宣布整个操作绝对原子。流程接口是否参与同一事务、附件关联与实际文件存储如何配合、异常是否向外抛出都需要继续检查。例如已有文件上传成功业务保存失败文件是否保留、关联是否恢复属于附件生命周期问题。数据库事务不会自动替所有外部存储完成回滚。[实测·历史教程] 这里显示文件上传成功尚不能单凭此弹窗证明业务关联已保存本课另核对了正常路径中的附件回显。失败与清理需要专门验证。同样状态校验可以拒绝不允许修改的单据但不能仅凭这一段代码推导并发重复提交已经解决。两次请求同时进入时是否会创建多个流程需要看锁、幂等或其他并发控制机制并在隔离环境验证。本课没有把并发压测记为通过。把这些问题列出来不是要求一次教学实现覆盖全部生产场景而是防止“代码已经生成”变成省略设计讨论的理由。首次打开的页面和刷新后的页面要分别看本课实际遇到过审批接口已经返回两行明细负责人第一次打开页面却看到空表。问题发生在表格挂载时序修复限定在业务组件中先写入表格数据选项等挂载后再刷新。info/index.vue还区分普通详情与审批内嵌详情的数据入口constdataawait(props.isApproval||props.processInstance?getTutorialRepairBillForBpm(id):getTutorialRepairBill(id));formData.value{...data};itemList.valuedata.items||[];同一个业务对象有不同入口测试就应该覆盖这些入口。只在申请人页面看见明细不能替负责人审批页面签收刷新后正常也不能覆盖首次加载失败。[实测·历史教程] 审批页应显示与原单一致的明细和附件。本课沿原流程继续复查没有重新造单绕过加载问题。权限也要沿入口区分普通详情、审批详情、列表可见范围分别有什么约束。当前教学记录证明了指定用户的正常操作及两项修改拒绝不能推广为所有读取接口、租户与角色组合都安全。用一张验收表把已证明和待补测分开代码审查完成后可以交出下面这样的结果而不是一句“已测试”。检查项本课证据转为生产功能时继续补什么正常保存与提交同一单据、两行明细、一个附件空值及非法明细输入组合身份与状态两类非法修改被拒绝数据不变更多角色、读取范围与租户组合金额9803001280源码重算小数边界、篡改输入及金额上限主子表已读到整组替换实现外部行引用与历史追踪需求审批展示首次挂载问题修复并复查不同入口和网络异常一致性正常流程结束后回写并发提交、故障注入与附件失败本课Java改动编译、前端格式与ESLint检查通过没有完成全仓类型检查也没有完整录制拒绝和撤回案例。把这些项目留在待办里比给所有检查统一打勾更有助于下一位接手者。宇擎建议让AI产出代码也产出可核验的说明让AI Coding完成需求时可以同时要求它列出规则所在的方法、数据写入顺序、失败路径、外部副作用以及尚未验证的用例。开发者据此对照实际代码删掉没有实现的承诺再挑最影响业务的场景运行。对于需要快速开发标准业务单据的团队这种方式可以把评审从逐行看所有文件聚焦到身份、状态、金额、明细和集成边界。对于涉及资金、库存或跨系统副作用的功能则不适合只凭一次顺利的教学演示决定上线。AI生成代码之后最有价值的问题往往不是“还能加多少功能”而是这段实现依赖哪些假设假设改变后哪条数据或哪次操作会先出问题把答案落实成验收表代码才有清楚的交付边界。