AI 生成代码的速度很快，但生成完成并不等于交付完成。尤其在业务逻辑稍复杂的页面里，代码可能编译通过，却在某些输入条件下出现错误。因此，我会把测试要求和开发需求一起交给 AI，而不是等到功能写完后才临时补测。

以表单校验为例，测试清单应覆盖正常输入、必填项为空、只有空格、超长文本、接口失败和重复点击等情况。对于纯函数，可以先写简单的单元测试；对于页面交互，则需要在模拟器或真机上实际操作。

下面是一个轻量断言示例，用来说明如何把业务规则转成可重复检查的测试。实际工程中应使用项目配置支持的测试框架组织用例。

代码示例

function assertEqual<T>(actual: T, expected: T, message: string): void {

 if (actual !== expected) {

   throw new Error(`${message}: expected=${expected}, actual=${actual}`)

 }

}

assertEqual(

 validateForm({ name: '', location: '图书馆', description: '' }),

 '请填写物品名称',

 '名称为空时应校验失败'

)

assertEqual(

 validateForm({ name: '  ', location: '图书馆', description: '' }),

 '请填写物品名称',

 '名称只有空格时应校验失败'

)

assertEqual(

 validateForm({ name: '保温杯', location: '图书馆', description: '' }),

 null,

 '合法表单应通过校验'

)

我还会要求 AI 为每个功能列出成功路径和失败路径，并指出哪些情况无法仅靠静态代码检查确认。例如，图片上传是否真的成功、页面在小屏设备上是否溢出、网络异常时按钮是否恢复，都需要运行验证。

如果 AI 修改了原本已经正常的模块，最好重新跑一遍相关回归测试，而不是只检查新增功能。测试清单能把“我觉得应该没问题”变成具体可重复的验证步骤，也能帮助团队在代码评审时快速判断改动是否完整。

更进一步，可以把复现步骤、预期结果和实际结果一起提供给 AI，让它辅助定位问题；修复后再将这个场景加入回归用例，避免同一类问题再次出现。