VkingAI
返回博客
·AI工具

Cursor 帮我改代码，然后我差点被自己坑了

用 AI 编程助手时踩的一个真实坑：它'优化'代码后引入了逻辑错误，但 Review 时完全没看出来。

#Cursor#AI编程#代码审查

事情是这样的

上周二下午，我在修一个 bug——某条数据查询返回结果比预期少了约 15%。排查了一小时，决定让 Cursor 帮我看看查询逻辑。

我把相关 SQL 和 Node.js 代码粘贴进去，说："帮我优化一下这段查询，提升可读性。"

三秒后，Cursor 给了一个"重构版本"，把原来嵌套的子查询改成了 JOIN，还顺手加了一些注释。我扫了一眼，逻辑看起来没问题，直接提交了。

然后线上报警了。

问题出在哪

重构后的查询确实更"干净"，但它把一个 LEFT JOIN 偷偷改成了 INNER JOIN。

原来的查询是：

SELECT u.id, u.name, o.order_count

FROM users u

LEFT JOIN orders o ON u.id = o.user_id

AND o.status IN ('active', 'pending')

WHERE u.created_at > '2024-01-01'

Cursor 改成了：

SELECT u.id, u.name, COUNT(o.id) as order_count

FROM users u

INNER JOIN orders o ON u.id = o.user_id -- 这里！

WHERE u.created_at > '2024-01-01'

GROUP BY u.id, u.name

两个问题叠加：

  • LEFT JOIN → INNER JOIN，导致没有订单的用户直接被过滤掉了

    • 2. 加了 GROUP BY 但没注意去重逻辑，某些用户被重复计数

    我 Review 代码的时候，脑子里还在想"AI 生成的注释挺专业的"，完全没注意到 JOIN 类型变了。

    教训

    **AI 改代码时，永远不要只看"表面逻辑"，要关注类型变化。**

    特别是 JOIN 类型、NULL 处理、聚合方式——这些 Cursor 最喜欢"顺手优化"的地方，恰恰是最容易出错的地方。

    现在我的流程变成了：

  • 让 Cursor 先解释它改了什么（不只是展示结果）

    • 2. 自己逐行对比 diff，重点看 JOIN 类型和 NULL 值变化

    3. 跑一遍测试用例，特别是边界情况

    另外，给 Cursor 的提示词也要加一条："不要改变 JOIN 类型，不要引入聚合，保持原有语义。" 这点很重要——不指定约束的话，它真的会"优化"掉你的业务逻辑。

    延伸思考

    用 AI 写代码和用 AI 读代码是两件事。读的时候你能停下来思考，写的时候它太快了——快到你会下意识信任它的输出。

    慢一点，看一眼 diff，比事后线上报警强得多。