随着人工智能的快速发展，许多人对AI辅助编程工具寄予厚望，认为它们将极大提升软件开发的速度和效率，特别是在开源社区，AI也被视为变革生产力的利器。然而，最近一份由Metr发布的研究报告却令人深思，它指出当经验丰富的开源开发者使用AI工具处理自己熟悉的代码库时，完成任务所需时间反而比禁止使用AI时显著延长。这种违反直觉的现象激发了对背后原因的深入探讨。在理解这一现象之前，我们需要先跳出对编码速度的传统思考，转而关注软件开发的核心本质。彼得·瑙尔（Peter Naur）在他的经典论文《编程作为理论构建》中提出，编程不仅仅是书写代码这么简单，更重要的是开发者通过编程活动形成对系统的心智模型或“理论”。他认为，真正的编程成果其实是程序员对相关事务的深刻理解和洞察，这种心智模型既支撑编码过程，也为日后维护、调试和持续开发提供关键支持。
这一点在开源社区尤其明显。开源项目通常由开发者长期维护，他们对代码的理解往往深入细致，心智模型十分成熟。Metr的研究参与者正是这些经验丰富的开源贡献者，他们在处理熟悉项目时，应有较高的内在工作效率。然而，当他们借助当前AI工具时，却出现了近20%的效率下降。为何会出现这种现象？关键在于AI工具并不能完整获取和利用这些开发者深厚的心智模型。虽然开发者可以通过文本或代码片段向AI展示部分上下文，但复杂的系统知识往往无法被有效编码和传递。
心智模型本身极为丰富且动态，依赖于反复的实践、调试和思考，这些细节难以通过短暂对话或有限信息传递给AI。将软件开发任务部分交给AI，在某种程度上就像是试图外包一项高度认知的工作：好比让别人根据简短的说明去哄孩子入睡，结果往往事与愿违。AI缺乏对整体系统的全面理解，也无法像人类那样主动提问或辨别信息重要性，这使得它生成的代码虽然看似合理，但往往不符合开发者真正意图或项目的深层逻辑。与此同时，使用AI工具需要花费额外时间在梳理和转化信息上，这种信息转换过程本身就成为瓶颈。更耐人寻味的是，开发者在使用AI时普遍高估了自己的效率提升，认为AI帮助他们写代码更快，尽管实际数据反映出相反的结果。这种认知偏差可能源于AI生成代码带来的即刻满足感或“假象效率”，但长远来看，却削弱了开发者对代码的深入理解。
这一点对软件维护和扩展极为不利。不同于某些企业环境中，开发者可能面对的是不熟悉的遗留系统，且仅需尽快产出可用功能，AI在这种“快速搬运”型工作中有明显优势。AI能够迅速“吃透”陌生代码，辅助生成实用的变更，极大缩短入门时间，对业务交付产生正面效果。然而开源作品则更注重代码的可持续性和深层把控，开发者希望长期掌握系统全貌，这种“快速产出优先”的思维方式并不适合。研发过程中建立心智模型是实现高质量软件的基石，没有这个过程，即使AI帮忙加速，也难以保障系统的稳定和逻辑连贯。从更广义的角度看，AI与人类开发者的合作还远未达到理想状态。
未来的AI工具若要真正提升经验丰富开发者的生产力，必须在理解、交互及学习能力上实现质的飞跃。它们需要具备主动提问的能力，更好地分辨信息优先级，更能辅助构建开发者的心智模型。单纯的代码生成已不足以满足复杂软件开发的需求。面对当前AI工具的局限，开发者需保持理性审视。在参与深度项目开发时，应有意识地亲自编写核心代码，强化对系统的理解。AI工具可作为辅助手段，用于简化重复性任务或帮助初学者快速入门，但不可替代对软件本质的洞察。
对于组织管理层而言，应根据团队的性质和项目特点合理引入AI工具。鼓励团队成员培养和维护代码心智模型，抵制因过度依赖自动生成代码带来的长期风险。总结来看，彼得·瑙尔的编程观点深刻揭示了为何当前AI在资深开源开发者中表现不佳的根本原因。软件开发不仅是写出正确运行的代码，更是一种认知活动，构建和运用复杂的心智模型。AI工具现阶段难以胜任这一认知角色，甚至可能成为负担。未来技术的推动方向，应当着重在人机协作的智慧融合上，帮助开发者更高效地构建并利用心智模型，而非简单自动化编写代码。
只有如此，AI才能真正成为提升软件开发生产力的助力，而非拖累。
