开发人员在使用AI助手编码时会犯哪些错误?

像Copilot、Claude和Cursor内置模型这样的AI助手改变了代码编写的速度。但对代码审查的严谨程度要求并未改变。我看到的AI辅助编码造成的大多数损害来自一些可重复的习惯，而不是来自模型本身。

不读就接受建议

最严重的问题是，因为补全看起来合理且能编译，就按tab接受它。合理≠正确。我看过有人接受了一条被建议的SQL查询，它在重构时偷偷删除了WHERE子句，那个人接受它是因为变量名匹配了。如果你不是以读同事pull request的速度阅读助手给你的每一行代码，那么你就会发布你不理解的东西。把每个建议当作一份来自速度快但对你代码库约定一无所知的初级开发人员的初稿。

用它处理安全敏感的代码

AI助手是在大量公开代码上训练的，其中很多代码内部就有安全问题。要求一个快速文件上传处理器，你经常会得到没有扩展名检查、没有大小限制、用字符串拼接而不是os.path.join或安全库调用构建路径的东西。auth也是一样的故事：助手喜欢建议把JWT存储在localStorage中，或用==而不是常数时间比较来比较密钥。这都不是恶意的，只是训练数据中统计上常见的做法。对于任何涉及身份验证、文件I/O、反序列化或SQL的东西，要么自己写逻辑，要么把AI的输出通过你对任何新代码都会提的威胁建模问题：恶意输入会怎样，这个调用失败会怎样，还有谁能到达这个端点。

让它编造依赖和API

模型以完全的自信幻想包名和函数签名。这就是"slopsquatting"问题——攻击者注册模型经常建议的假包名，所以未经验证的pip install或npm install可能会下载根本不是你的日志库的东西。在添加助手推荐的任何依赖之前，检查它是否真的存在于PyPI或npm上，检查它的下载计数和最后发布日期，如果足够小就略过源码。同样的谨慎也适用于API调用：如果助手引用了你不认识的方法，在假设它存在之前查一下真实的文档。

丧失对自己代码的心智模型

当你自己写代码时，你建立了一份心智地图，说明为什么每部分存在。当你在一个会话中接受大块AI生成的代码时，那份地图很快就变淡了。然后三周后出现了一个bug，你在调试你从未真正写过的、也不完全记得的代码。修复的办法不是避免AI生成的代码，而是放慢速度，在合并之前，把每一块向自己或队友解释一遍。如果你不能解释一个函数做什么和为什么这样做，就还不要合并它。

跳过测试，因为代码