想象这样一个场景：你在和供应商开会，一切顺利。然后对方问了一个再正常不过的问题："这个功能具体是怎么实现的？"你卡住了。不是因为问题太难，而是因为——这个功能是你交付的，你负责的，但代码不是你写的。AI写的，你大致扫了一眼，跑通了，就上线了，然后继续下一个任务。
这不是虚构的假设。我亲身经历过。当时没出什么大事，我解释了一下，后来也找到了答案，但那种"自己不懂自己交付的东西"的感觉，非常不舒服。这种担忧是真实的，而且并不新鲜——关于AI最大的恐惧之一，就是它对我们学习能力和学习质量的影响。
我们已经在重度依赖AI了
这种依赖不是未来时，是现在进行时。新闻有人帮你总结，作业有人帮你解答，定制软件有人帮你写。这些确实都是非常好的应用场景。问题出在什么时候？出在三个具体的行为模式上：
- 读了AI的摘要，就再也不看原始来源
- 直接拿到答案，跳过了自己思考的过程，所以实际上没学到东西
- 接受了代码但不理解它，等出问题的时候，连从哪里开始排查都不知道
对开发者或IT从业者来说，这笔账迟早要还，而且会从三个方向同时找上门。第一，你对自己系统运作方式的了解会变浅。第二，你的排障能力会变慢、变浅。第三，你的代码库会悄悄变成一笔负债——因为你负责维护一个你解释不了的东西。这些后果不会在第一天就显现，但会在某一天集中兑现。
管理者的平行经验
这种转变，我其实经历过一个类似的版本，每一个从写代码转到带团队的管理者应该都有同感。当你从整天写代码变成整天管理写代码的人，你的产出会变少，少很多。你的技术手感也确实会钝一点。这是真的。
但与此同时，另一件事发生了：你开始锻炼不同的技能，而这些技能后来被证明非常重要——从架构层面理解一个系统，提出那个能帮别人解卡的问题，判断哪个风险才是真正的风险。你不再是打字最多的人，但你变成了理解更多的人。而且说实话，你"旧"的技能变成了新技能的基石。
对非技术岗位的人来说也是一样。你在自己领域的专业经验，在指导AI输出和检查质量时会变得极其有价值。所以目标不是"少用AI"，而是确保你换掉的是打字这件事，而不是理解和认知这件事。
我是怎么避免这个坑的
我让AI完成我几乎所有的编码工作，但我并没有感觉自己变钝了。我的做法是这样的：
让AI主动解释自己。我会有意识地追问很多"为什么"。有些提示词我几乎天天用："请把这个解释成我明天要在设计评审会上为它辩护的程度。""你考虑过哪些方案又放弃了哪些，为什么？""这个改动风险最大的部分是什么？""如果流量涨10倍，什么会先崩？"——这些问题任何一个都能让你学到东西，有时候甚至能帮你发现真实存在的问题。
遇到不懂的词就停下来。一个术语从眼前滑过，你发现自己没法定义它——停下来，问AI，或者自己去查。这个习惯很小，但很根本，而且非常有效。
热门跟贴