夜雨聆风👋 大家好，我是带娃搞技术、做副业的 Go 后端程序员 Tim！
用 AI 编程工具（Claude Code、Codex 这些）大概两三个月，我发现一个很有意思的现象——
身边开始用的人，慢慢分成了两种：
一种人思路越来越清晰，判断越来越准，AI 对他们来说像外挂大脑，碰到难题跟它聊一聊，思路就通了。
另一种人好像离了 AI 就不会干活了。写个简单函数都要先问 AI，改个变量名都要它给建议。AI 不在的时候，整个人停摆。
同样一个工具，差距在哪？
一、教练模式 vs 拐杖模式
我观察下来，本质区别就一句话。
第一种人的用法是："这个事我想这么做，你觉得有没有问题？"
第二种人的用法是："这个事你帮我想想怎么做。"
看到了吗？前者是自己先有判断，让 AI 来挑战、补充、优化。后者是把问题直接扔给 AI，等它出答案。
前者你在主导，后者 AI 在主导。
我把第一种叫教练模式，第二种叫拐杖模式。
拐杖模式：你不会走路，AI 扶着你走。你省力了，但你的肌肉没练到。哪天 AI 不在，你连站都站不稳。
教练模式：AI 在旁边看着你练，给你纠正姿势、调整节奏、指出盲点。你流汗了，但你的肌肉在长。哪天教练不在，你照样能自己练。
怎么判断自己在哪个模式？三个信号：
1. **打开 AI 之前，你脑子里有没有一个大概的思路？** 如果每次都是空白状态等它给方向，那你在依赖。
2. **AI 给的结果，你是直接用了，还是经过了自己的判断？** 直接复制粘贴的次数越多，依赖越深。
3. **离开 AI，你能不能把同样的事做出来？** 如果不能，说明你的能力长在 AI 身上，不是长在自己身上。
我自己也踩过这个坑。有一段时间写技术文档严重依赖 AI，它不给我开头，我都不知道怎么动笔。后来刻意练习：自己先写一版初稿，哪怕只有框架，再用 AI 优化。半个月后就好多了。
二、AI 是"工程同事"，不是"代码售货机"
有了正确的心态，再看怎么用 AI 干活。
很多人把 AI 当成代码自动售货机——输入需求，输出代码，完事。但真正用下来你会发现，最有价值的用法不是让它"替你写代码"，而是让它"帮你把小任务推进一轮"。
什么叫合适的任务？不是"帮我优化一下项目"这种愿望，也不是"重构一下代码"这种大而散的要求。而是边界相对清楚、结果可以检查的任务。比如：
"这个接口偶尔超时，先定位调用链，看看有没有重复请求，不要直接改全局请求封装。""这个组件状态太乱，先整理重复逻辑，保持外部行为不变。"
这些任务里都有三个要素：目标、限制、验收方式。目标告诉它要解决什么，限制告诉它不要乱碰，验收方式告诉它做完以后怎么交代。
我自己的体会是，用 Claude Code 写撸毛脚本的时候，给的任务越清楚，它一次搞定的概率越高。如果我自己都说不清要什么，它给出来的东西往往也要反复改。
所以用 AI 之前，先多写两句限制条件，往往比事后多改半小时更划算。
三、"我先来"原则
用了一段时间以后，我给自己定了一条原则，就三个字：我先来。
不是"AI 你先写一个我看看"，是"我先想清楚方向，你再帮我展开" 不是"AI 你觉得哪个好"，是"我倾向 A，你帮我看看有没有盲点" 不是"AI 帮我出一份完整的"，是"我把框架搭好，你帮我填血肉"
先有判断，再用 AI。不是用 AI 来代替判断。
这也是为什么我一直在推 Superpowers 这种 Skill 套件——它本质上就是在帮 AI 建立工程工作流，而不是让它自由发挥。后面有机会可以单独写一篇，聊聊 Superpowers 到底是怎么改变我用 AI 的方式的。
工具用久了，人会变形。
AI 编程工具特别有意思，它像一面镜子——你用它的方式，会反过来塑造你的思维方式。你让它出方案对比，它就帮你做分析。你直接要答案，它就帮你把思考这件事省了。
省了一次两次没关系，省了一年两年，你的思考能力就是另一个故事了。
所以我的建议很简单：先有自己的判断，再让 AI 挑战它。而不是反过来。