导语

Anthropic随机对照实验显示，使用AI辅助的开发者技能测试得分比纯手写组低17%。问题不在工具本身，而在于开发者正在把”审查”降级为”验收”。本文提出”认知技术债”概念，分析其与代码技术债的本质区别，并给出四条基于实验验证的实操建议。

1. 问题背景

InfoQ中文在2025年发表过一篇讨论Vibe Coding的文章，核心论点是：AI编程工具普及后，程序员的护城河不再是”会写代码”，而是”知道该让AI写什么”。本文在此基础上提出一个更具体的判断：AI编程工具正在制造一种新型技术债——问题不在于代码质量，而在于开发者对代码中潜在风险的无感知。

笔者日常开发中使用Cursor进行代码补全、Claude Code搭建项目框架、Copilot生成测试用例。这类工作流在行业中已被广泛定义为”效率提升”。

近期一次线上并发故障暴露了一个被忽视的问题：Claude Code连续返回三个方案，全部错误。故障代码是三个月前由AI生成并经”验收通过”的。排查过程中发现，注释、变量命名、异常处理均由AI设计，开发者实际上仅完成了表层浏览而非实质性审查。

由此引出本文的核心概念区分：

代码技术债（Code Technical Debt）：开发者明确知晓问题存在，选择延后处理。
理解债（Comprehension Debt）：开发者对代码中存在的问题完全无感知。代码库中存在大量通过”验收”但未被”理解”的代码模块，每一段都构成潜在的故障点。

2. 编程思维的”用进废退”：实验证据

2.1 Anthropic随机对照实验

Anthropic于2025年发表的论文《How AI Impacts Skill Formation》（作者：Judy Hanwen Shen、Alex Tamkin）提供了可量化的实验数据：

实验设计：随机对照试验（RCT）
核心发现：使用AI辅助的开发者在技能测试中得分比纯手写组低17%
关键说明：实验中AI的使用方式为”辅助”而非”全自动生成”，换言之，即便在相对保守的AI使用强度下，可测量的能力下降已经发生

值得警惕的不是17%这个数值本身，而是能力退化过程的无感知性。AI持续承担代码生成和bug修复工作，开发者在此过程中退化为AI模块之间的信息传递节点。

2.2 谷歌效应与AI编程工具的差异

“谷歌效应”（Google Effect）已被心理学研究证实：人类会加速遗忘那些确认可通过搜索引擎获取的信息。但搜索引擎与AI编程工具存在本质差异：搜索引擎不替代思考过程，而AI编程工具将思考结果封装为”用户自己的判断”返还。开发者基于这些判断参与评审、撰写技术方案、进行技术讨论，但这些判断的原始来源并非自身推理。

2.3 计算器类比及其局限性

计算器普及导致心算能力和数感下降，这一现象已被多项研究证实。但该类比存在关键局限：心算被替代后几乎没有必须使用心算的场景，而编程中的”从零构建逻辑链”能力在故障排查、架构设计等场景中仍不可替代。问题正在于此：该能力不可替代，但正在被系统性外包。

InfoQ文章中的类比值得引用：使用AI写代码相当于请健身教练代为举铁——铁被举起，但肌肉未得到训练。三个月后需要独立完成时，连杠铃的重量都无法判断。

3. 认知技术债：概念定义与机制分析

3.1 生产力J曲线理论

MIT经济学家Erik Brynjolfsson提出的”生产力J曲线”理论指出：新技术引入初期，生产力不会立即上升，反而先经历下降阶段，之后才反弹超过原有水平。原因在于旧工作方式已被打破，新工作方式尚未建立。

AI编程工具正在经历相同的J曲线过程。下降期的部分成因在于认知技术债的积累：开发者误以为AI在节省时间，实际上是将理解代码的时间成本后移。理解他人编写的代码与理解自己编写的代码依赖不同的认知机制——前者靠回忆，后者靠从零推理。后者速度更慢，错误率更高。

3.2 概念定义

认知技术债目前尚无统一的学术命名。本文将其定义为：

代码技术债：开发者明确知晓需偿还的债务，选择暂时拖欠
认知技术债：开发者对代码中存在的债务完全无感知。AI完成代码生成，开发者完成验收，债务被埋入系统。故障发生时，排查起点无法定位——代码的逻辑链并非在开发者大脑中构建

3.3 行业共识与结构性缺陷

阿里云通义灵码相关技术文档中存在一个行业共识：AI编程工具最适用于”重复性高、创造性低”的工作。该判断本身正确，但忽略了代码库中两类代码的耦合性。AI生成样板代码时，同时完成了若干逻辑判断。开发者在验收阶段判定为”差不多”，这些”差不多”的逻辑判断即构成系统中的认知技术债。

AI生成的代码并非节省时间，而是将时间成本后移。当前不投入时间理解，三个月后需投入双倍时间排查。系统仍属于开发者，但开发者已丧失对系统的实际掌控。

4. 使用模式决定结果：验收与审查的区分

4.1 问题的核心不在工具

AI处理样板代码和重复配置，使开发者能够将精力集中于架构设计和性能优化，这对能力发展具有正面价值。问题在于大多数开发者将本应自己完成的核心动作也一并外包。

InfoQ文章指出AI生成代码的特征为”还可以”——不是好，也不是差，就是”还可以”。GitHub上三个代表性项目的星数数据反映了开发者对”让AI执行得更好”的强烈需求：

tinyhumansai/OpenHuman：超过24000颗星，本地化AI助手
obra/superpowers：超过20万颗星，Agentic Skills框架
colbymchenry/codegraph：曾单周增长超过14000颗星，代码预索引

三个项目的共同特征：均增强AI的执行力，未增强AI的判断力。判断力仍由开发者承担。”会用AI写代码”这一能力本身正在快速贬值，真正拉开差距的是使用方式。

4.2 6种AI交互模式与3种认知参与模式

Anthropic论文识别了6种AI交互模式（英文名称来自论文原文）：

AI Delegation
Progressive AI Reliance
Generation-Then-Comprehension
Iterative AI Debugging
Hybrid Code-Explanation
Conceptual Inquiry

其中3种涉及”认知参与”（Cognitive Engagement），即在AI辅助过程中开发者仍在进行主动思考，能够保留学习效果。另外3种属于”AI执行，开发者旁观”模式，能力下降最为显著。

实验数据的核心结论：AI本身不损害编程思维。损害编程思维的是”验收”这一动作。

验收：表面检查通过即放行
审查：开发者脑内存在独立标准，将AI输出与该标准进行比对

验收与审查的区分，即认知技术债与认知资产的区分。

5. 实操建议

以下四条建议均对应论文的核心发现——”认知参与”能够保留学习效果。非主观建议，而是经过实验验证的有效方法。

建议一：先自行拆解问题，再使用AI生成代码

多数开发者的使用顺序相反。Stack Overflow上未经认证用户的答案不会被直接采信，AI输出同理。正确顺序为：自行拆解问题、明确方案，再使用AI完成实现层工作。AI定位为加速器而非替身。该建议对应论文的核心发现：在AI介入前建立自身认知框架，是三种”认知参与”模式的共同前提。

建议二：AI生成的代码，注释自行编写

非改写AI注释，而是从零编写。需写清逻辑设计原因、边界条件、模块间耦合关系。无法写出即表明未理解。未理解不应提交。每一行自行编写的注释都在偿还认知技术债。该建议对应论文中的Hybrid Code-Explanation模式——代码由AI生成，解释由开发者完成。解释过程即理解过程。

建议三：定期执行代码走读

每月选取一个AI协助完成的关键模块，关闭AI，不查看注释，尝试复述逻辑、边界条件和耦合关系。无法复述即找到了欠下的认知技术债。当前偿还比线上故障后偿还成本低百倍。该建议对应Conceptual Inquiry模式——不满足于”代码能跑”，追问”为什么这样写”。

建议四：遇到难题时，先不使用AI

当前信息获取习惯使开发者随时有答案可查。AI加剧了这一问题——”等待答案”的动作正在消失。大脑越来越不愿在困难bug上停留。解决方案：先自行思考，在不适状态中停留。非浪费时间，而是训练大脑的深度思考能力。

6. 关于”AI让编程民主化”的讨论

AI确实降低了编程门槛，非技术人员可通过Vibe Coding生成可运行原型。这是积极发展。

但”写出来了”与”写得对、能维护、能演化”是两个不同层次的问题。AI生成代码的同质化反而提高了”能维护”的门槛。

具体案例：AI处理错误时倾向使用相似的异常处理模式（try-catch包裹、日志记录、异常抛出）。当系统中十个模块均使用该模式，单独检查每段代码均无问题。但在特定场景下该模式同时失效时（如日志级别配置错误导致关键信息丢失），需排查的不是一段代码，而是十段外观几乎一致但各有微妙差异的代码。每段代码均已被”验收”，但无一段被真正理解。

更严重的问题在于：自行编写的低质量代码，开发者知晓其低质量的具体位置——偷懒、绕路、打补丁的痕迹本身构成排查线索。AI生成的代码没有这些痕迹。它外观”合理”，但开发者对其缺乏直觉。 排查自己的低质量代码依赖回忆，排查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 编程工具相关技术文章