一年前的开发者还在问"你用AI吗"，现在变成了"你怎么用、为什么用"。一位工程师的自省火了：他从IDE里的代码补全，发展到用AI做架构设计、原型验证、重构优化—— workflow彻底换了一遍。
但他发现不对劲。有时候用AI不是为了提效，纯粹是想避开思考的摩擦感。这让他意识到：AI用法分"模式"，每种模式暗藏的认知代价完全不同。
三种AI使用模式：支持型、混合型、风险型
支持型模式的认知代价最低。AI帮你扩展思路，但决策权在你手里。比如用AI生成多个实现方案，自己评估选哪个。
混合型模式省时间，但用得糙会压缩理解深度。典型场景：让AI直接给一段能跑的代码，自己没吃透就合并进去。短期交付快了，长期可能埋下技术债。
风险型模式表面高效，实则让AI接管了太多推理链条。最危险的信号是：你描述需求→AI输出结果→你直接提交，中间几乎不过脑子。频繁这么干，长期理解力会被悄悄削弱。
四种认知原型：从"AI扩脑"到"AI代脑"
基于这三种模式的使用习惯，作者梳理出四类开发者画像：
第一类，AI扩展思维但不替代所有权。AI是外接大脑，最终判断和代码责任全在自己。这是最健康的用法。
第二类，大体健康，但要警惕"混合型模式"悄悄蔓延。偶尔图快让AI代劳小段逻辑，次数多了就变成依赖。
第三类，效率数字好看，但理解深度在下滑。能交付，但讲不清底层原理，debug时开始发慌。
第四类，AI已经主导了太多推理路径。需求进去、代码出来，人在中间的角色越来越像传声筒。
作者强调这不是科学分类，只是个自我觉察的框架。他自己在代码交付的不同阶段设计了一套"反思练习"，用来对冲AI模式带来的认知代价。
一个值得警惕的类比
他把AI比作第一部智能手机：变革性、极好用、强大到需要刻意建立使用边界——比如睡前放卧室外，偶尔不带它散步，留点独处思考的空间。
这个类比戳中了不少人。智能手机改变的是注意力分配，AI改变的是认知分配。两者都需要"防沉迷"机制，但AI的侵蚀更隐蔽：它不是在抢你的时间，是在替你做决定。
作者现在的核心问题变成：AI在帮我思考得更清楚，还是在我察觉之前，已经悄悄替换了我的推理？
你日常用AI写代码时，最顺手的是哪种模式？最近一次让你警觉的"AI代劳"是什么时候？
热门跟贴