AI是杠杆，不是拐杖
同样是用 AI 写代码，一年后，有人变得更强，有人变得更废。
区别不在工具，在用法。
杠杆和拐杖，表面像，本质反
杠杆和拐杖看起来很像：都是借助外力完成自己单独做不到的事。但有一个根本区别：
杠杆放大你已有的力量。拐杖补偿你缺失的力量。
用杠杆撬石头，你需要先有力气、找到支点、选好角度。你本身的判断力决定杠杆的效果——你越强，杠杆越有用。用拐杖走路，你不需要腿有力气，拐杖承担了腿应该承担的工作。长期的结果是：腿越来越不需要用力，越来越虚弱。
AI 工具，可以是任何一种。关键在于你是带着思考去用它，还是带着依赖去用它。
你在用哪种？一个简单的自测
有一个简单的方法可以判断自己处于哪种状态：
把 AI 拿走，你还能做吗？
- 能做，只是慢一点——你在用杠杆
- 做不了，或者质量差很多——你在用拐杖
再问深一层：六个月前你能做到的事，现在还能做到吗？如果答案是"不确定"，你可能已经在不知不觉中把杠杆换成了拐杖。
这个自测不是为了让你焦虑，而是为了让你清醒。工具的渗透是悄无声息的，等你意识到依赖已经形成，往往已经过了很长时间。
同一个场景，两种命运
以"写一个基于 Redis 的分布式锁"为例，来看两种用法的差距。
拐杖用法：打开 Cursor，直接输入需求，复制输出，跑通，提交。代码有了，但你不清楚为什么要用SET NX PX，不知道锁超时和业务超时怎么对齐，不知道如何处理可重入场景，也不知道客户端崩溃时锁会不会永远不释放。下次遇到分布式锁的问题，你还是得问 AI——因为你其实什么都没学到。
杠杆用法：动手之前，先在脑子里想清楚几个问题：分布式锁要解决什么本质问题？原子性怎么保证？锁的粒度怎么选？可能的竞态条件有哪些？把这些想清楚之后，再用 AI 生成初稿，对照自己的思路逐行 review，找出差异，搞懂每一处设计背后的原因。这个过程多花了二十分钟，但你真正理解了分布式锁的核心原理。下次遇到类似问题，你的判断力更强，AI 的辅助也会更精准。
一次看不出差距。一年后，天壤之别。
杠杆的前提：你得先有支点
阿基米德说过：“给我一个支点，我能撬动地球。”
注意，他说的是"给我一个支点"——他本身的力量、判断力、物理知识，是默认已经存在的前提。没有这些，支点只是一根棍子。
杠杆放大的是已有的能力，放大不了不存在的能力。
一个对系统设计一无所知的人，用 AI 生成架构图，得到的是一堆他看不懂、也无法评估好坏的输出。他无法判断这个架构在高并发下会不会有问题，无法识别单点故障，无法评估扩展成本。AI 给了他一张图，但他没有能力使用这张图。
一个有五年系统设计经验的人，同样用 AI 生成架构图，能在三分钟内找出潜在问题、提出改进方向，然后把省出来的时间用去思考更难的问题。
同样的工具，效果差十倍。这就引出了一个反直觉但真实的结论：
AI 对强者更有用，对弱者反而是陷阱。
强者用它加速，弱者用它掩盖弱点——而被掩盖的弱点，只会越来越弱。
什么时候该主动放下杠杆
杠杆不是越用越好，有三种情况你需要主动把工具放下：
学新东西的时候。学习的本质是在大脑里建立新的连接，这个过程需要你自己"想"和"试错"，没有捷径。用 AI 直接给答案，你跳过了最重要的部分——那个让你真正理解的挣扎过程。就像健身，让别人帮你举铁没有任何意义。
想搞清楚底层的时候。当你对某个系统有疑问，最好的方式是自己读文档、读源码、做实验、复现问题。AI 给的解释往往是正确的，但它给的是"标准答案"，不一定是你那个具体场景下你真正需要的那个角度。只有自己走一遍，才能建立真正属于你的理解。
做重要决策的时候。架构选型、技术路线、关键 tradeoff——这些判断必须经过你自己大脑的完整处理。你可以让 AI 帮你列出各方案的优缺点，但最终的判断必须是你自己做出的，因为只有你真正理解了业务背景、团队现状和风险边界，也只有你要对结果负责。
最后
工具是中性的。同一把锤子，可以建房子，也可以砸自己的脚。
用 AI 的时候，问自己一个问题：
我是在用它放大我的能力，还是在用它回避我的弱点？
前者越用越强，后者越用越空。每一次使用选择，都在悄悄塑造六个月后的你。
AI 是杠杆，不是拐杖。你得先有腿，才能谈放大。