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

说句不好听的。

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

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

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

问题不在模型烂。
问题在我压根没控住它。

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

是太爱乱写。

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

而且改得特别自信。

这才是最要命的地方。

我后来没有换模型。

只是加了三个"规矩"。

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

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

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

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

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

第一步：superpower — 先把 AI 按住

大多数人第一反应：

帮我看看 SQL 哪里错了

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

最后你发现：更乱了。

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

这是订单数量不一致的 bug。 不要修改 SQL，不要给修复方案。 只做三件事： 1. 列出所有可能原因 2. 分析当前 SQL 风险点 3. 给排查路径

你会明显感觉到变化。

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

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

它不会再乱改代码了。

一句话：

superpower 不是让 AI 更聪明
是让它别乱来

第二步：gsb — 把问题拆开

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

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

我继续压它：

按步骤排查： Step 1：检查 count 和 list SQL 是否一致 Step 2：检查 join 是否导致重复 Step 3：检查过滤条件 Step 4：检查状态 / 逻辑删除 每一步给：SQL + 验证方法 + 判断标准

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

SELECTo.id,COUNT(*)FROMorderoLEFTJOINorder_item iONo.id=i.order_idGROUPBYo.idHAVINGCOUNT(*)>1;

你一跑：

直接定位——有重复。

一句话：

gsb 让 AI 从"给答案"
变成"带你查问题"

第三步：gls — 不准交垃圾

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

AI 给你修复 SQL：

SELECTCOUNT(DISTINCTo.id)FROMorderoLEFTJOINorder_item iONo.id=i.order_id;

很多人到这里就结束了。

我会再来一轮：

对这个 SQL 做自检： 1. 性能风险 2. 是否有更优方案 3. 边界问题 4. 是否影响其他统计

AI 开始自己推翻自己：

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

然后给你更稳的版本：

SELECTCOUNT(*)FROM(SELECTo.idFROMorderoGROUPBYo.id)t;

一句话：

gls 让 AI 不只是写代码
而是对结果负责

说句难听的

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

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

真正拉开差距的，是：

你有没有一套稳定的"工作方式"

没有的话：

👉 AI 是加速器
👉 加速你犯错

有的话：

👉 AI 是执行器
👉 替你干活

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

我更关心的是：

这套流程，能不能复用
能不能让别人也跑起来

如果你现在还在：

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

那问题不在 AI。

在你。

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

主要分享：

AI 编程与开发效率

技术趋势与工程思考

实用工具与工作流