三个让我 AI Coding 稳如老狗的 Skill

说句不好听的。

我之前用 AI 写代码，就是在更快地制造垃圾。

代码是写得更快了。
bug 也来得更快。

一个线上问题，AI 改完，更炸。
我才意识到——

AI 最大的毛病，不是不会写

是太爱乱写。

你还没说清楚问题，它已经给你改完三处代码了。

而且改得特别自信。

这才是最要命的地方。

我后来没有换模型。

只是加了三个"规矩"。

这三个 Skill，基本决定了你用 AI 是在玩，还是在干活：

• superpower：不准一上来改代码
• gsb：不准一口气说完
• gls：写完必须自检

一个真实案例：订单数对不上

不讲概念，直接讲一次真实工作流。

场景：
页面显示订单数 785，SQL 查出来 868。
典型线上问题——数据对不上。

第一步：superpower — 先把 AI 按住

大多数人第一反应：

然后 AI 开始改 where、改 join，给你一个"看起来更对"的版本。

最后你发现：更乱了。

我现在的做法是，上来直接限制它：

这是订单数量不一致的 bug。

不要修改 SQL，不要给修复方案。

只做三件事：
1. 列出所有可能原因
2. 分析当前 SQL 风险点
3. 给排查路径

你会明显感觉到变化。

AI 开始老老实实干这些事：

• 对比 count SQL 和列表 SQL
• 检查 join 是否导致重复
• 看状态过滤是否有差异
• 检查是否有逻辑删除字段

它不会再乱改代码了。

一句话：

第二步：gsb — 把问题拆开

这时候 AI 给你一堆"可能原因"。

问题来了：太多，不知道先查哪个。

我继续压它：

按步骤排查：

Step 1：检查 count 和 list SQL 是否一致
Step 2：检查 join 是否导致重复
Step 3：检查过滤条件
Step 4：检查状态 / 逻辑删除

每一步给：SQL + 验证方法 + 判断标准

在"join 是否重复"这一步，它给你：

SELECT o.id, COUNT(*)
FROM order o
LEFT JOIN order_item i ON o.id = i.order_id
GROUP BY o.id
HAVING COUNT(*) > 1;

你一跑：

直接定位——有重复。

一句话：

第三步：gls — 不准交垃圾

问题找到了：join 导致重复统计。

AI 给你修复 SQL：

SELECT COUNT(DISTINCT o.id)
FROM order o
LEFT JOIN order_item i ON o.id = i.order_id;

很多人到这里就结束了。

我会再来一轮：

对这个 SQL 做自检：

1. 性能风险
2. 是否有更优方案
3. 边界问题
4. 是否影响其他统计

AI 开始自己推翻自己：

• DISTINCT 在大表性能差
• 可以用子查询优化

然后给你更稳的版本：

SELECT COUNT(*)
FROM (
  SELECT o.id
  FROM order o
  GROUP BY o.id
) t;

一句话：

说句难听的

现在很多人还在讨论：Claude 还是 GPT，哪个模型更强，要不要开 Pro。

说实话，这些都不是重点。

真正拉开差距的，是：

没有的话：

AI 是加速I器
加速你犯错

有的话：

AI 是执行器
替你干活

我已经不太关心模型更新了。

我更关心的是：

如果你现在还在：

• 每次都从头问 AI
• 每次都重复解释
• 每次结果都不稳定

那问题不在 AI。

在你。

更多深度内容与完整文章，欢迎关注我的微信公众号：SamLai 效率研习社

主要分享：

AI 编程与开发效率

技术趋势与工程思考

实用工具与工作流