说句不好听的。
我之前用 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 是否重复"这一步，它给你：
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;
你一跑：
直接定位——有重复。
一句话：
gsb 让 AI 从"给答案"
变成"带你查问题"
第三步：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;
一句话：
gls 让 AI 不只是写代码
而是对结果负责
说句难听的
现在很多人还在讨论：Claude 还是 GPT，哪个模型更强，要不要开 Pro。
说实话，这些都不是重点。
真正拉开差距的，是：
你有没有一套稳定的"工作方式"
没有的话：
👉 AI 是加速器
👉 加速你犯错
有的话：
👉 AI 是执行器
👉 替你干活
我已经不太关心模型更新了。
我更关心的是：
这套流程，能不能复用
能不能让别人也跑起来
如果你现在还在：
- 每次都从头问 AI
- 每次都重复解释
- 每次结果都不稳定
那问题不在 AI。
在你。
更多深度内容与完整文章，欢迎关注我的微信公众号：SamLai 效率研习社
主要分享：
AI 编程与开发效率
技术趋势与工程思考
实用工具与工作流
