AI生成代码的“视觉欺骗”：别被能跑通的Demo给骗了

很多新手最容易掉的坑就是：代码跑起来了，界面看着挺漂亮，就觉得AI写得没问题。但实际上，能实现功能（Demo）和符合工程标准（Engineering）是两码事。AI极其擅长写那种“看起来很对”的代码，但它经常在修改局部时，悄悄破坏掉你系统的整体边界。

我总结了一套实操层面的核查流程，建议在把AI代码合并到主分支前强制跑一遍。

一、 建立“用户契约”清单
不要直接看代码，先用一句话定义功能边界。比如：“登录用户可以保存私密笔记，刷新后只能看到自己的笔记。”
然后强制AI对照这个契约，指明代码实现位置：

• 用户身份在哪里校验？
• 所有权在哪个环节强制执行？
• 失败请求如何处理？

如果AI指不出具体行数或逻辑位置，这代码绝对不能直接用。

二、 五维度深度审计
我习惯把审核分为这几个硬指标，尤其是涉及数据流和权限时：

• 数据路径追踪： 从输入框 → 数据库 → 界面。检查输入是否经过校验？数据形状在各层之间是否一致？千万别被本地State的假象骗了，得确认数据确实来自真实源。
• 权限边界核实： 隐藏按钮 $\neq$ 权限保护。必须检查后端或数据库层面是否有所有权校验。最简单的测试法：用账号A尝试修改请求ID去访问账号B的数据，能通的话就是大漏洞。
• 异常路径覆盖： AI最爱写 Happy Path。你要盯着：网络超时怎么办？保存失败是否误报成功？加载状态在所有退出路径上是否都清空了？
• 变更面审查： 让AI列出所有修改的文件、Schema和依赖。防止它为了实现一个小功能，偷偷改掉了被其他模块共用的全局代码。
• 冗余逻辑清理： 检查是否出现了重复的业务逻辑，或者为了凑数而写的废代码。

三、 实操检查清单（参考格式）
如果你们在团队协作，可以用类似下面的 checklist 记录核查结果：

- [ ] Data Path: Input -> DB -> UI (Verified)
- [ ] Auth: Server-side ownership check (Verified)
- [ ] Edge Cases: Timeout/Empty response handled (Verified)
- [ ] Side Effects: No unrelated shared code modified (Verified)

总之，AI写代码的逻辑是“概率性正确”，而工程要求的是“确定性正确”。把AI当成一个高效但粗心的实习生，你得扮演那个极其挑剔的代码审查员。