Slack弹出一条消息，团队里的开发把代码片段扔过来审阅。格式工整，命名规范，连注释都写得像教科书。我批了几条反馈，对方秒回："哦，这不是我写的，ChatGPT给的。"
盯着屏幕愣了五秒。不是反对用AI，是那句回复里找不到任何"人"的痕迹——没写过，没看懂，甚至没试过。他成了传话的信使，不是解决问题的工程师。
复制粘贴是最隐蔽的偷懒
流程大家都熟。卡壳了，把报错丢进对话框，AI吐出一坨代码，粘贴，运行，工单状态改成"已完成"。
表面看效率拉满。但有个关键环节被跳过了：你的大脑没参与。
编程不经大脑，本质上不是编程，是誊抄。誊抄不会让你变强，只会让你的时薪越来越接近复印机。
我见过太多这种路径依赖。一个中级开发遇到异步回调问题，第一反应不是翻文档、画流程图，而是直接把函数体喂给AI。拿到答案后也不拆解逻辑，像接收快递一样签收代码。三个月后面试被问到Promise原理，支支吾吾答不上来——那些代码他"用过"几十次，但从没"理解"过一次。
AI生成的代码有个致命盲区：它只对平均场景负责，不对你的具体上下文负责。
你的数据库连接池配置、团队的异常处理规范、遗留系统的兼容包袱——这些AI一无所知。它给的是通用解，你直接粘贴就成了特制bug的培养皿。上周生产环境崩掉的那次，根因就是一段"看起来没问题"的AI代码，没处理你们三年前埋下的边缘case。
工程师思维到底是什么
不是会写代码，是会把模糊的问题拆成可执行的步骤。是面对报错时先问"为什么"而不是"怎么修"。是理解每一行代码的代价——时间、内存、维护成本。
AI可以当你的草稿纸，但不能替你思考。区别在哪？
草稿纸上的推导过程是你亲手写的，错一步你能看见，能回溯，能纠正。直接复制答案，你得到的是结果，丢掉的是过程。而过程才是训练思维的唯一素材。
有个测试方法：删掉AI给的代码，你能不能用自己的话把需求重新描述一遍？能不能在白板上画出数据流？能不能列出三种可能的实现方案并比较优劣？
做不到的话，你不是在使用工具，是被工具使用。
把AI用对姿势的3个原则
第一，先动手再开口。卡壳至少15分钟再求助AI，这段时间你的大脑在建立问题模型。哪怕最后没解出来，你也摸清了陷阱在哪，AI给答案时你能判断靠不靠谱。
第二，强制复述。拿到代码后，关闭对话框，用注释逐行解释这段代码在干什么。解释不通的地方，就是你的知识黑洞。
第三，故意改错。把AI给的变量名改成你们团队的命名规范，把错误处理改成项目统一的模式。这个"翻译"过程逼你理解每个部分的职责。
说白了，AI应该是你的 rubber duck（橡皮鸭调试法里的那只鸭子），替你出声而已，思考的主体必须是你。
那个Slack对话的后续：我让那位开发把代码逐行讲给我听。讲到第三行就卡住了。我们一起画了状态机图，他自己发现了两处AI没考虑到的竞态条件。那周他提交的代码量少了40%，但线上bug归零。
他后来跟我说，那15分钟的讲解比过去三个月的复制粘贴学到的都多。
你现在手头有没有一段"来自AI"的代码？关掉编辑器，拿张纸，不查资料，试着写出它的输入输出和边界条件。写不出来的部分，就是你付给AI的隐形学费——而且越欠越多。
热门跟贴