夜雨聆风现在让AI代写代码而自己跳过学习，实在是太容易了。漏洞虽然修复了，但你的认知模型却在原地踏步。 长此以往情况可能会变得更糟。 我们正悄悄用未来的能力换取眼前的速度，而工具并不会逼我们改变。
改变必须发自你的内心。
我们大多数人已经习惯了一种默认的循环。 你贴上需求文档或错误信息，模型交给你一个修复方案，问题症状随之消失。 然后你将代码发布上线。 在这个循环的某个角落，问题与解法之间那种混乱而真实的挣扎，彻底消失了。
我之前写过认知让渡的现象。 也就是AI审查员的判断悄然取代你自我判断的那一刻。 这其实是同一个循环的单人版本，只有你和模型。 模型速度更快，所以你放弃了在理解力上与它较量。
在成千上万次这样的小互动中，一旦脱离了AI的辅助，你实际能构建的东西每周都在退化。 这些瞬间在发生的那天，你根本感觉不到是个问题。
我并不排斥AI。 我每天都用这些工具，过去一年借助它们交付的成果比前几年加起来都多。 但我们使用它们的默认方式只为了一件事而优化：那就是完成任务。
这与我们在漫长职业生涯中保持敏锐、去驾驭这些工具的目标，截然不同。
各项研究正指向同一个结论
过去一年的多项研究，最终都得出了大致相同的结果。
Anthropic在2026年初进行了一项随机试验，让工程师学习一个新的Python库。 一半人使用AI辅助，另一半人则完全手写。 两组人完成任务的速度不相上下。 但在随后的理解测试中，AI组却遭遇了滑铁卢。
AI组的得分是50%，而手写组是67%，在代码调试环节差距更大。 有趣的是AI组内部的数据分层。 用AI来询问概念的工程师，得分超过了65%。 而直接复制粘贴生成代码的工程师，得分还不到40%。 决定结果的从来不是工具，而是你面对工具的姿态。
麻省理工学院一项关于大脑如何应对ChatGPT的研究，对比了不同方式的写作。 他们将大模型、搜索引擎和纯脑力写作的三个小组进行了对比。 脑电图显示，外部支持越多，大脑的神经连通性就越弱。 大模型组的大脑连通性最差。
写完文章后，83%使用大模型的用户背不出自己刚写的任何一行字。 研究人员将这种现象称为认知债务。 今天你省下的脑力，明天都要用批判性思维的衰退来偿还。
CHI 2026的一项研究补充了一个相关发现。 当人们在任务一开始就接触大模型时，模型会框定整个问题的思路。 即使剩下的工作都是人类自己完成的，这种最初的锚定效应也会导致更糟的决策。 操作的顺序，远比你使用AI的总量更重要。
不同的研究方法得出了相同的结论。 如果在没有主动学习意愿的情况下使用AI，它会悄无声息地毁掉你赖以生存的专业技能。
工具默认倾向于交付，而不是教学
如果你启动一个代码智能体并使用默认设置，一切都只为一个指标服务。 那就是把任务搞定。 模型写代码，你点击接受，然后循环往复。 工具绝不会停下来问你，你觉得问题出在哪，或者让你试着自己写前五行。
这就是目前产品设计的重心所在。 产品团队的绩效来自代码的合并和开发周期的缩短。 他们并不负责把你培养成更敏锐的工程师。 大家都想少敲几次键盘，所以工具把那些摩擦力都抹平了。
但问题在于，摩擦力恰恰是学习发生的地方。
少数几家公司试图打破这种阻碍学习的循环。 Anthropic为Claude推出了学习模式，采用苏格拉底式提问。 它会停下来让你自己写代码，然后再继续。 OpenAI和谷歌也推出了类似的功能。
但说实话，几乎没人把它们用在真实的生产环境中。 我们默默地把这些功能归类为学生专属，这是一个大错特错的偏见。 帮助大二学生学习React的功能，同样能帮高级工程师学习Rust。 你需要的，只是愿意再次把自己当成一个初学者。
既然AI能做，我为什么还要去懂？
这问题问得很合理。 对于某些工作，答案也许是：你确实不需要懂。 如果是样板文件、胶水代码，或者是用完即弃的脚本，那就交给AI吧。 花时间去死记硬背这些语法的机会成本太高了。
但在真正的软件开发中，完全做甩手掌柜会在几个关键时刻付出代价。
当系统崩溃
AI写的代码和人写的一样会出错。 把锅甩给智能体对调试问题毫无帮助。 团队里必须得有人懂底层架构。
当它一本正经地胡说八道
大模型依然会产生幻觉。 面对看似合理却漏洞百出的答案，唯一的防线就是你识破它的专业知识。 各种外围的辅助工具只能帮你解决皮毛问题。
当底层基础改变
代码是暂时的，但系统是长久的。 当框架更新或安全审查暴露出结构性问题时，你没法靠改写提示词来脱身。 你需要足够懂这个系统的工程师来完成迁移。
当你脱离大众需求
AI很擅长解决GitHub上被解决过一百万次的问题。 但你离主流需求越远，它的表现就越糟。 那些冷门、没有文档支持的硬骨头，才是体现高级工程师身价的地方，这需要极深的理解力。
当市场开始调整
只能靠AI写代码的人，正在进入一个重新评估专业价值的劳动力市场。 如果你用AI来逃避学习。 那你就是在用未来的核心竞争力，换取一个稍微轻松一点的工作日。
破局之道在于你如何提问
好消息是，制造认知债务的工具，同样能打磨出更顶尖的工程师。 区别就在于你如何向它们发问。
提问前先有自己的假设
在寻求修复方案前，先写下两三句你对问题的推测。 用模型的回答来验证你的判断，而不是直接取代你的思考。
先弄懂原理，再要代码
进入陌生领域时，你的第一句话应该是： 请解释这套逻辑，有哪些替代方案，各自的利弊是什么。 只有当你真正吃透了这些概念，再让它写代码。
遇到盲区时，开启学习模式
是的，这感觉慢吞吞的。 但这正是它的意义所在。
把AI的输出当成新人的代码提交
仔细读，挑毛病，打回去重做。 你会仅仅因为测试通过了，就让一个新人的代码上线吗？ 如果不会，在这里也请守住底线。
偶尔自己动手重构一下
拿一段模型写的代码，试着从零开始自己写一遍。 这是一次自我体检，能帮你摸清自己不知不觉退化了多少。
让模型当你的老师
当它写出一段精妙的代码后，问它用到了什么原理。 问它你需要看些什么资料，才能理解这种设计思路。 多问一句，你在这场对话里的收获就会截然不同。
这些都不是什么惊天动地的大动作。 它们只是你在使用日常工具时，稍微调整了一下姿态。
盯紧两个指标，而不仅是一个
我现在每天敲完代码，都会问自己一个简单的问题： 我今天学到新东西了吗，还是仅仅关了几个工单？
有时诚实的答案是，我只是清了工单，这没关系。 但如果连续几个月答案都是如此，认知债务就已经在暗中堆积了。
交付成果和个人学习是两个完全不同的指标。 你的老板和客户永远只关心第一个。 但第二个指标，只能由你自己负责。
我宁可只交付80%的活儿，但把该学的100%学透。 也不愿为了100%的交付而放弃学习。 几年下来，这两种选择会造就完全不同境界的工程师。
你不必在拥抱AI和持续学习之间做非此即彼的单选题。 但你必须刻意去建立一个兼顾两者的工作流。 因为默认设置只会带你走向平庸。
工具一直在那里，随时待命。 而你正准备扔给AI的下一个无聊任务，就是最好的起点。
