三任程序员接手过的1200行Python订单系统，没有注释，被我扔给了Claude 4.0和GPT-5o。
我的预期是让AI来一次高效的技术债清算。结果在30秒内，它们精准揪出了一个潜伏三年的SQL注入漏洞——用户输入的 order_id 直接拼进了f-string，对于AI来说，这就像在白纸上看到一个黑点。
但随后，两款模型都在15处不存在的问题上花了大量篇幅。它们一致强烈警告：订单库存更新缺少分布式锁，会有并发超卖风险。从代码看，AI没错，确实没看到Redis锁或Zookeeper。但它漏掉了一个关键背景：这个脚本跑在单实例Celery Worker上，上游队列配了 single-active-consumer。同一时间只有一个进程在处理订单，加锁纯属多余，还白白增加延迟。
这种“AI虚警”很容易把开发者带进过度修复的坑。就像之前有团队让AI清理旧代码，AI删掉了一些历史精度处理逻辑，结果引发了万分之一的结算误差。代码逻辑对，但业务历史没考虑。
为了测试适应性，我通过提示词注入了环境信息：单实例部署，重点关注内存和类型错误。然后让它们重构代码。Claude 4.0把1200行压到800行，加了Pydantic类型校验，70%的补丁能直接用。GPT-5o的代码更漂亮，但习惯性把同步调用改成asyncio，而老系统驱动不支持异步，导致一堆崩溃，复用率只有55%。Claude更保守，GPT更激进——后者在处理遗留系统时风险更高。
现在很多人用MCP协议让AI先读架构图再审查代码，想解决语境缺失的问题。但对于大多数团队，更现实的做法是：在AI审代码前，先告诉它部署环境、Python版本、并发模型；别让它一次找所有Bug，得分轮来，先扫安全漏洞，再查性能，最后才重构；最重要的是，让AI根据旧代码先生成测试用例，重构后一旦测试不通过，果断回滚。
2026年的AI在模式识别上近乎神级，但在业务理解上，还是个不懂常识的数学天才。它给你的不是答案，而是一份带噪音的嫌疑名单。最危险的不是它没发现Bug，而是它用极自信的语气，引导你为修一个不存在的问题，引入一个真实的回归Bug。
