上周的事。
项目有个功能，前后端联动那种。我想着用Cursor写，应该能快不少。它确实快——我把需求往那一贴，30秒，代码出来了。
看了看，逻辑没问题，接口对得上，我就直接提交了。
第二天部署到测试环境。一跑，报错。
我愣了一下。看错误信息，是数据库连接的问题。但代码里明明写得没毛病啊？
排查了两个小时。
最后发现，Cursor生成的代码里，数据库配置用了一个我已经废弃的环境变量名。它不知道，因为它参考的是网上一个旧教程。我本地跑的时候，这个变量刚好有值，所以没发现问题。但测试环境是干净的环境，这个变量不存在，就炸了。
修复很简单，改一行配置的事。
但这件事让我开始反思。
AI编程工具确实强，它能帮你写80%的代码。但剩下那20%，你得知道它在写什么。
后来我给自己定了几个规矩：
第一，AI生成的代码，必须完整读一遍。不是走马观花，是逐行看。特别是配置、环境变量、依赖版本这些地方。
第二，本地测试环境要尽量接近生产环境。我这次踩坑就是因为本地有"历史遗留"，掩盖了问题。
第三，敏感信息坚决不让AI碰。数据库密码、API密钥这些，手动填。
第四，复杂逻辑让AI写，但架构设计自己来。它擅长翻译需求，不擅长理解业务上下文。
这几点说起来简单，但真用起来，需要克制。
AI写代码太快了，快到你容易忘记"自己才是负责人"这件事。它生成的代码就像外包团队交的作业——能用，但你得验收。
我现在用Cursor的流程是这样：
先让它出个框架，我看看结构对不对。对的话，再让它填细节。填完了，我自己做代码审查。审查完了，再测试环境跑一遍。跑通了，才敢部署。
比以前慢了点？也许。
但比以前稳多了。
那个坑之后，我没再因为AI代码在生产环境翻车过。
工具是好工具，关键是怎么用。