夜雨聆风导语
InfoQ中文在2025年发过一篇讨论Vibe Coding的文章，它的核心观点是：在AI编程工具得到普及之后，程序员真正的护城河不再是“会写代码”，而是“知道该让AI写什么”。我看完这篇文章之后，脑子里冒出来的是另一句话：AI编程工具正在制造一种新型技术债——不是代码烂，而是你压根不知道代码里埋了什么雷。
我每天都在运用AI来写代码。借助Cursor完成补全工作、借助Claude Code来搭建架子、借助Copilot生成测试代码。我一直觉得这样的做法可以称之为效率。
直到上个月线上出了一个并发故障。Claude Code接连给出三个方案，结果全都是错的。我盯着那段代码——也就是三个月前AI帮我写的，当时还“验收通过”了——发现自己连那段逻辑为什么会写成这样都想不起来了。注释是AI加的，变量名是AI起的，异常处理也是AI设计的。我原本以为自己审查过。结果根本就是随便看了一遍。
那两天我意识到：我欠的并不是技术债。所谓的技术债，就是你明明知道存在问题，却选择先将其欠下来。我欠的其实是“理解债”——我根本就不知道这些代码存在问题。 代码库里堆满了这类我曾经“验收”过但并未真正“理解”的代码。每一段都像是一颗不知道什么时候就会引爆的雷。
一、编程思维的"用进废退"
你有没有这种感觉：以前接手别人的代码会感到烦躁，现在接手自己的代码也同样会感到烦躁。
以前看自己三个月前写的代码，骂归骂，好歹能顺着逻辑回忆起来。现在看三个月前AI帮你写的代码，是真的想不起来。因为当初那个逻辑就不是你推出来的，是AI替你推的，你只是点了点头。
Anthropic在2025年发布过一篇题为《How AI Impacts Skill Formation》的论文，开展了一项随机对照实验：运用AI辅助的开发者，其技能测试得分比纯手写代码组低了17%。这并非感觉上变差了，而是可以被测量到的下降情况。真正令人担忧的并非17%这个数值，而是你出现了退化却都未曾察觉。AI依旧在帮你开展工作，功能依然可以正常上线，bug也能够被修复。只不过修复这些bug的同样是AI，你也就变成了AI与AI之间的传话者。
科学家早就发现过谷歌效应：人会更快速地忘掉那些知道能在网上搜到的信息。搜索引擎至少不会替你去思考。AI编程工具就会这样。它会把思考完的结果，包装成你自己的判断再还给你。你以为那是你的判断，但其实不是。
类似的事在计算器普及之后也发生过。长期依赖计算器的人，心算能力以及数感会出现下降的情况。当然，心算和编程思维有着本质的区别——心算被替代之后几乎没有场景需要你去进行心算，但编程当中“从零构建逻辑链”在排查bug、设计架构的时候仍然是不可替代的。问题恰恰就在这里：这个能力不可替代，但你正在把它外包出去。
InfoQ那篇文章运用了一个比喻：用AI写代码，就好比请健身教练帮你去举铁。铁被举起来了，但是你自己的肌肉并没有得到锻炼。三个月之后你自己需要举铁的时候，你就连杠铃有多重都不知道了。
该图片由ai生成
二、长期依赖AI之后的"认知技术债"
经济学当中有一个“生产力J曲线”理论，这个理论是由MIT的Erik Brynjolfsson所提出的：在新技术引入的初期，生产力不但不会马上上升，反而会先出现下降的情况，之后才会实现反弹。旧有的工作方式被打破了，而新的工作方式还没有建立起来。
AI编程工具正在经历一模一样的J曲线。而下降期的部分缘由，就是认知技术债的积累——你以为AI在替你省时间，实际上你把理解代码的时间挪到了后面。你花时间去理解AI生成的代码在干什么，但理解别人写的代码和当初自己写是两回事。理解自己写的靠回忆，理解AI写的靠从零推理。后者慢得多，也更容易出错。
这个现象目前还没有统一的学术命名，我把它称作“认知技术债”。
代码技术债指的是你清楚这段代码之后需要偿还，但先暂时欠着。认知技术债指的是你根本不知道这段代码当中存在债务。 AI帮你写好之后，你完成了验收，那么债务也就被埋进去了。等到问题爆发的时候，你连排查的起点都找不到，因为那段代码的逻辑链并不是在你脑子里构建的。AI并不具备对你业务上下文的长期判断力。
阿里云通义灵码的相关文章当中有一个行业共识：AI编程工具最适宜"重复性高、创造性低"的工作。其问题在于——代码库里这两类代码是长在一起的。AI帮你写了样板代码，顺手也帮你做了几个逻辑判断。你验收的时候觉得"差不多"。这几个"差不多"，就是埋在你系统里的认知技术债。
AI生成的代码不是替你省时间，而是把时间挪到了后面。 你现在不花时间去理解，三个月后就得花双倍的时间去排查。系统还是你的系统。但你已经不是它的主人了。
该图片由ai生成
三、借助AI的相关方式，来决定你是实现进化还是走向退化
说到这里，你或许会产生疑问：那我是不是应该少使用AI？
说起来，问题其实并不在于工具本身，而在于该如何去使用它。AI可以帮你处理掉样板代码、重复配置这类体力工作，让你腾出精力去做架构设计以及性能优化，这对于你的能力提升是有好处的。但问题在于，大多数人把本来该自己完成的核心动作也一并外包了出去。
InfoQ那篇文章提到，AI写的代码有一个特性——“还可以”。不是好，也不是差，就是“还可以”。我跑去Github翻了几个热门项目：tinyhumansai/OpenHuman，超过24000颗星，属于本地化AI助手；obra/superpowers，超过20万颗星，属于Agentic Skills框架；colbymchenry/codegraph，曾单周增长超过14000颗星，属于代码预索引。这三个项目的共同点在于星数都比较高，折射出开发者对于“让AI执行得更好”的巨大需求。但它们都在增强AI的执行力，没有哪个在增强AI的判断力。判断力还是需要你来完成的。“会用AI写代码”这件事本身在快速贬值，真正拉开差距的是你使用AI的姿势。
Anthropic那篇论文识别出了6种AI交互模式，以下英文名称来自论文原文，分别是AI Delegation、Progressive AI Reliance、Generation-Then-Comprehension、Iterative AI Debugging、Hybrid Code-Explanation、Conceptual Inquiry。其中有3种涉及“认知参与”，也就是你还在动脑的情况，能够保留学习效果。另外3种是“让AI去干，你在一旁看着”的模式，对应的能力下降会最明显。翻译过来就是：那些“AI生成代码之后不进行检查，直接提交”的人，能力下降得最为明显。那些“先自己设计方案，再让AI生成内容，之后逐行审查并修改”的人，能力下降的幅度会明显更小。还有一类是“让AI生成多个方案，自己进行比较并选出最优方案”的情况，几乎不会出现能力下降的问题。
这是全文最值钱的地方：AI本身不会伤害你的编程思维。真正伤害你的，是“验收”这个动作。
验收：看起来没问题，过了。审查：我脑子里有一个独立标准，拿AI的输出跟它做对比。 验收和审查的区别，就是你欠认知技术债和攒认知资产的区别。
该图片由ai生成
四、给你四条行动建议
下面这四条建议，每一条都对应着论文的核心发现，也就是“认知参与”能够保留住学习效果。这并不是“我觉得应该这样做”，而是经过实验证明这样做确实是有效的。
1.先自己拆问题，再让AI写代码。
大多数人的情况其实是反过来的。你不会随便就相信Stack Overflow上一个三无用户给出的答案吧？那凭什么就直接相信AI给出的内容呢？自己先把问题拆解清楚、把方案想明白，让AI来做实现层的体力活。AI其实是加速器，而不是替身。 这条内容对应论文的核心发现：在AI介入之前先建立起自己的认知框架，是三种“认知参与”模式共同的前提。
2.AI给你的代码，注释需要你自己写。
不是改写AI的注释，而是从零开始进行撰写。要把这段逻辑为什么要这样设计、边界在哪里以及和其他模块之间是如何耦合的，都写清楚。要是写不出来的话，就说明你没有真正理解。没有理解就不要提交。每一行你自己所撰写的注释，都是在偿还认知方面的技术债。这条内容对应论文当中的Hybrid Code-Explanation模式，也就是代码由AI来撰写，而解释则是由你来完成。解释的整个过程，其实就是实现理解的过程。
3.定期做代码走读。
每月挑选一个AI协助完成的关键模块，关掉AI之后不看注释，试着去复述它的逻辑、边界条件以及耦合关系。要是复述不出来，那你就找到了欠下的认知技术债。现在就去偿还，要比等到线上出问题之后再处理便宜一百倍。 这对应的就是Conceptual Inquiry模式，也就是不满足于“代码能跑”，还要追问“为什么这样写”。
4.遇到难题的时候，先不要去询问AI。
我们已经太习惯随时可以获取到答案了。AI让这个情况变得更加严重——就连“等待答案”这个动作都快要消失了。大脑也越来越不愿意在一个棘手的bug上多停留哪怕一秒钟。其实解法十分简单：先自己思考一会儿，在那种不太舒服的状态里多待上一会儿。 这并不是在浪费时间，而是在训练你的大脑能够进行深度思考。
该图片由ai生成
五、关于"AI让编程民主化"
我清楚有人会提出反对意见：AI确实降低了编程门槛，非技术人员也可以借助Vibe Coding做出可以运行的原型。这难道不是一件好事吗？
这确实是好事。但“写出来了”和“写得对、能维护、能演化”其实是两回事。甚至因为AI生成代码的同质化，“能维护”的门槛反而变得更高了。
举个具体例子。AI在处理错误的时候，倾向于运用相似的异常处理模式，也就是把try-catch包一层，打上一段日志，再把异常抛出去。要是你系统当中的十个模块都使用了这种模式，单独去看每一段代码其实都不会有什么问题。但如果在某个特定场景下，这种模式同时出现了失效的情况，就好比日志级别设置不对，导致关键信息被吞掉，这个时候你需要去排查的就不是一段代码，而是十段看起来几乎一模一样，但各自又存在微妙差异的代码。每一段代码都是你已经验收过的，却没有一段是你真正理解透彻的。
更麻烦的是，你自己写的烂代码，哪怕再烂，你也清楚它烂在哪里——你当时偷了懒、绕了路、打了补丁，这些“偷懒的痕迹”本身就是排查的线索。AI生成的代码并没有这些痕迹。它看起来“合理”，但你对它没有直观的认知。 排查自己的烂代码依靠回忆，排查AI的“合理代码”则要依靠从零开始的推理。后者要慢得多，也更容易出现遗漏。
所以这两件事可以同时成立：AI让更多人能够“写出来”。但“写得对、改得动、撑得住”的能力，还是得靠你自己去练习。前提是你主动去使用它，而不是让它替代你。
该图片由ai生成
写在最后
InfoQ那篇文章的结尾有一个判断：程序员和AI之间存在一个根本区别——程序员可以在没有任何外部输入的情况下，从零开始产生原创性的解决方案。随着AI越来越强，“能独立思考”反而成了最值钱的东西。
所以这篇并不是劝你不要去使用AI，而是在使用AI的同时，不要让自己的编程大脑只剩下“按回车键”这一项能力。哪怕你Cursor、Claude Code、Copilot用得再熟练，拆解问题、追踪bug、设计架构这部分的能力，还是要自己保留下来。这样AI才会成为你的加速器，而不是拐杖。
我自己也还在练习当中。这件事并没有终点可言。
参考文献
Anthropic：《How AI Impacts Skill Formation》，Judy Hanwen Shen & Alex Tamkin, 2025
https://www.anthropic.com/research/how-ai-impacts-skill-formation
Github：obra/superpowers（204k+ Stars，GitHub全球排名#19）
https://github.com/obra/superpowers
Github：tinyhumansai/OpenHuman（24k+ Stars）
https://github.com/tinyhumansai/openhuman
Github：colbymchenry/codegraph（曾单周增长14k+ Stars，星数波动较大，以GitHub实时数据为准）
https://github.com/colbymchenry/codegraph
Erik Brynjolfsson："生产力J曲线"理论相关文章
InfoQ中文：Vibe Coding相关深度文章
阿里云开发者社区：通义灵码 AI 编程工具相关技术文章
