AI写的代码，程序员到底怎么用？密苏里科技大学与德雷塞尔大学联合调查了三万五千条代码注释

这项由密苏里科技大学与德雷塞尔大学联合开展的研究，于2026年6月以预印本形式发布在arXiv平台，编号为arXiv:2606.06843。研究团队系统性地分析了GitHub上超过三万五千条与AI工具相关的代码注释，时间跨度从2022年12月（ChatGPT首次发布）延续至2026年3月，是目前规模最大、时间跨度最长的AI辅助编程实证研究之一。

说到AI写代码这件事，大多数人的印象可能是这样的：程序员问ChatGPT或者GitHub Copilot一个问题，AI吐出一段代码，程序员复制粘贴，完事儿。听起来既省事又高效，AI似乎成了一台自动代码打印机。

但现实真的是这样吗？

研究团队扮演了一次大规模的"侦探"，他们不去实验室里做模拟测试，也不让程序员填问卷，而是直接深入一线战场——真实的开源代码库。他们的侦查对象是一种特殊的"现场痕迹"：代码注释。程序员写代码时会顺手留下注释，当他们用了AI的建议，有时也会在代码旁边写上"这段是ChatGPT生成的"或者"Copilot建议的方案"。这些注释就像犯罪现场遗留的指纹，清晰地记录着人与AI协作的真实足迹。

顺着这些"指纹"，研究团队在12,944个代码仓库中挖掘出35,361条明确提及AI工具的代码注释，以及与这些注释相关联的代码块，再追踪后续修改这些代码的12,996次提交记录（commit），最终拼出了一幅关于"AI辅助编程真相"的完整图景。

一、寻找指纹：研究团队如何在GitHub的海洋里打捞数据

一个拥有数亿代码文件的平台上，如何找到那些明确提及AI的痕迹？研究团队设计了一套系统性的搜索方案，有点像同时撒出480张不同网眼大小的渔网。

他们组合了三类词语来构建搜索指令。第一类是16个AI工具的名称，涵盖ChatGPT、GPT、Copilot、Claude、Gemini、Llama等主流工具。第二类是6个表示"生成行为"的动词，比如generated（生成了）、suggested（建议了）、written（写了）、created（创建了）、authored（编写了）和assisted（协助了）。第三类是4个表示来源归属的连接词，如by、from、with、using。把这三类词语按照两种不同顺序组合，就得到了480条搜索指令，能够同时捕捉"ChatGPT generated"（ChatGPT生成了）和"generated by ChatGPT"（由ChatGPT生成）这两种写法。

这480条指令在GitHub代码搜索接口上执行后，共返回66,960个匹配文件，其中Python文件43,628个，JavaScript文件23,332个。然后是两轮筛选。第一轮确保关键词确实出现在注释里，而不是藏在代码字符串或变量名中。第二轮追溯每个文件的历史提交记录，确认这条注释最早出现的时间确实在2022年12月之后，由此确定"引入时间"。

最终保留的数据集包含35,278条注释及其关联代码块，分布在26,490个源代码文件中，来自12,944个不同的代码仓库。这些仓库里，超过8,300个的GitHub星标数为0，说明研究捕捉到的不只是那些知名的大型项目，还有大量普通开发者日常使用AI的真实场景。

在处理这批数据时，研究团队发现了一个有趣的"误伤"情况：有些注释里出现了"Claude"这个词，但说的其实是一个叫Claude的人，比如"written by Claude Pageau"。这类假阳性记录被逐一清除，最终共剔除了7,697条这样的干扰项，确保分析的每一条记录都是真实的AI使用痕迹。

二、读懂注释背后的故事：程序员用AI在干什么

光有数据还不够，还需要理解这些注释在说什么。研究团队在这里采用了一种"老师带徒弟"式的方法——先让人类专家手动理解500条样本，总结出规律，再把这套规律教给AI，让AI处理剩下的三万多条。

两位有六年以上编程经验的研究人员独立审阅了500条注释和对应的代码块，面对每一条记录，他们的核心问题是："这段代码在做什么，AI在这里扮演了什么角色？"他们从两个维度来标注每一条记录：一是任务类型（这段AI辅助的代码是在做什么），二是AI贡献类型（AI具体是怎么帮忙的）。

两人独立标注完成后，研究者用了一种专门衡量"两个评判者意见一致程度"的统计指标（Gwet's AC1）来检验结果，任务类型维度得分0.760，AI贡献类型维度得分0.657，均达到"高度一致"的标准，说明这套分类体系足够清晰，不同人看同一段代码会给出相似的判断。

有了这500条高质量的人工标注作为"样本答案"，研究团队让两个大型语言模型（gemma-4:31b和nemotron-3-super:120b）分别对全部数据进行分类，然后用一种叫做"Dawid-Skene期望最大化"的统计方法将两个模型的判断融合成最终标签——这套方法的核心思路是：当两个判官意见不一致时，根据每位判官过去的准确率来决定更信任谁。在100条保留用于验证的样本上，这套自动化流程与人工判断的一致程度达到了0.70和0.81，效果令人满意。

三、程序员真正拿AI做什么——任务图谱的全貌

经过上述分析，研究团队整理出了一份关于"AI辅助编程任务"的完整图谱，这份图谱里最突出的发现是：大多数时候，程序员用AI来写新代码。

在去掉那些标注不明确的情况后，25,193条有效记录中，有18,149条（72.04%）属于代码实现——也就是让AI直接生成能运行的功能代码，成为真实项目的一部分。一条典型的注释是"This function was created by Claude AI."，简洁明了地记录了一段功能代码的来源。这意味着，AI写代码这件事在GitHub上已经相当普遍，大量的生产级代码里都有AI的直接贡献。

排在第二位的是代码增强（4,039条，16.03%），这个数字比人工标注样本中的比例（4.96%）明显更高，说明在更大规模的数据中，用AI优化和改进已有代码的行为比想象中更普遍。对应的注释通常是这样写的："This function was generated using ChatGPT with the prompt: 'Improve the delete task function with better error handling and improved readability.'"。程序员不是把AI当成一次性工具，而是在迭代改进的过程中反复向AI寻求帮助。

测试（1,322条，5.25%）和文档（1,295条，5.14%）分列第三第四，证明AI不只是写功能代码，测试用例和代码注释文档同样是AI的常见输出。程序员会写下"Description: this file contains test cases generated by Copilot."这样的说明，直接把AI生成的测试文件纳入正式代码库。

相比之下，专门用AI识别和修复Bug的情况（388条，1.54%）在全量数据中其实并不多见——尽管在500条手工样本中这一比例达到6.45%，但扩展到全量数据时大幅下降，暗示程序员在专门调试问题时可能不太习惯在代码里留下AI归属的注释，或者这类使用发生在其他场合（如对话窗口）而不容易留下痕迹。

在AI的贡献方式上，研究团队同样归纳出了三种主要角色。最常见的是直接实现（82.13%），AI在这里就是一个"代码生成器"，直接产出可运行的代码，程序员采纳后放进项目里。"Validation fully written by Copilot based on error state names"这条注释是这类情况的典型代表，AI被视为真正的代码作者。

第二种角色是知识与概念支持（14.76%），这时AI扮演的更像一位随叫随到的顾问。程序员不是让AI直接写代码，而是向它请教——该选哪种算法？这个框架怎么用？有没有更安全的实现方式？一条注释写道："Using bcrypt for password hashing (ChatGPT suggested secure hashing practices)"，清楚地说明AI给出了安全建议，程序员根据建议做出了技术选型。在手动标注的50个此类案例中，有12个涉及算法选择或数据结构设计，8个涉及性能优化和调试，还有6个涉及语法、框架函数或API用法，其余则是更宏观的设计决策探讨。

第三种角色是制品生成（3.63%），AI在这里生成的不是代码本身，而是支撑开发工作的"周边材料"，比如配置文件、设备列表、文档模板等。"This is a ChatGPT generated list of devices"这条注释就是典型案例。

四、AI写的代码，程序员接下来做了什么

代码写进去，故事才刚刚开始。研究团队追踪了12,996次"首次修改提交"——也就是AI辅助代码被引入之后，第一次对同一代码块进行更改的提交记录。这些提交记录里的说明文字（commit message）就像每次手术的手术记录，记录着程序员对AI产出做了哪些调整。

研究团队用了一种叫BERTopic的方法来分析这将近一万三千条提交说明。这种方法先把文字转化成语义向量（可以理解为把文字的"意思"变成可以计算的数字），再用聚类算法把意思相近的提交说明归到一组，最终整理出8个主要行动类别。

出现最多的是功能集成与扩展（2,769条）。"feat: add chat management functionality with MongoDB integration"、"feat: enhance chat endpoint to accept both 'message' and 'prompt' fields for improved flexibility"这类提交说明说明，AI辅助代码被引入后，程序员随即开始在其基础上叠加新功能、扩展能力边界，而不是就此停手。这在一定程度上说明AI产出的代码是有用的——不然没人会在上面继续建设。

位居第二的是重构与清理（1,465条）。提交说明里频繁出现"remove redundant"（删除冗余）、"Clean up unused code"（清理无用代码）、"remove unused dependencies"（移除多余依赖）等表达，说明AI生成的代码往往带着一些"赘肉"，程序员需要手动瘦身。另一类重构说明则更有建设性，比如"Refactor backend state to use singleton instantiation pattern"，程序员把AI的实现方案改造成更符合项目整体架构风格的形式。

Bug修复与纠正性变更（1,304条）紧随其后，说明AI写的代码并不是一次就能正确运行的。"Authorization issue solved, error handling in progress"、"fixed a bug in the onmessage function"这类记录直接表明，AI辅助代码在实际使用中出现了问题，需要程序员介入修复。这个数字提醒人们，AI写的代码同样需要测试和维护，不能直接信任。

配置、依赖与环境管理（810条）这一类看起来与AI辅助代码的内容关系不大，更多是项目协作层面的动作，比如合并分支、解决冲突、集成拉取请求，说明AI辅助代码成功并入主干后，随之而来的是正常的团队协作流程。

此外，文档（709条）和测试与评估（432条）分别位列第五和第六，说明AI辅助代码引入后，程序员会补充文档说明，也会增加测试覆盖，体现出对代码质量的持续关注。数据、模式与管道处理（128条）和日志与监控（72条）则是更专项的技术性调整。还有1,028条提交说明过于简短或模糊（比如"first commit"或"intermediate commit"），无法判断具体做了什么，被归入杂项。

这幅后续修改的图景传递出一个清晰的信号：AI生成的代码被引入项目后，并不会就此"自行运转"。程序员持续扮演着审核者、改进者和维护者的角色，AI的产出更像是一份初稿，而非最终交付物。

五、三年来的变化轨迹：AI在程序员工作中悄悄转型

从2022年12月到2026年3月，这份数据还记录了一条时间轴，让研究团队得以观察AI辅助编程的使用习惯如何随时间演变。

从绝对数量来看，AI相关注释的增长速度相当惊人：2022年全年（其实只有12月）仅占总量的0.31%，2023年占7.80%，2024年占19.78%，2025年占52.41%，2026年前三个月已占19.69%。这条增长曲线几乎是一条急速上扬的抛物线，说明在开源社区里，程序员主动在代码里标注AI来源的行为正在快速扩散。

更耐人寻味的是使用方式的演变。研究团队对每个月各类任务和贡献类型的占比进行了时间序列分析，并用统计方法检验各类别是否存在显著的上升或下降趋势。

代码实现依然是最主导的任务类型（平均占比73.9%），但它的趋势线在统计上并不显著，既没有明显上升，也没有明显下降，处于稳定状态。与此同时，代码增强显示出统计上显著的上升趋势（每月增加约0.113个百分点，p=0.049），测试同样呈现显著上升（每月增加约0.097个百分点，p=0.004），Bug识别与修复也有显著的小幅上升（p=0.025）。相比之下，文档则出现了显著的下降（每月减少约0.151个百分点，p=0.008），说明随着时间推移，专门用AI生成文档的行为在相对份额上有所萎缩。

在AI贡献类型的维度上，直接实现依然主导（平均占81.4%），趋势稳定；知识与概念支持则呈现出统计上显著的上升趋势（每月增加约0.185个百分点，p=0.025），这是增速最快的类别；制品生成则显著下降（每月减少约0.181个百分点，p=0.006）。

把这些数字翻译成普通人能理解的语言：刚开始使用AI写代码的时候，程序员的主要用法是"你来写，我来用"，把AI当作代码打印机。随着时间推移，程序员越来越多地开始把AI当作"技术顾问"来使用——向它请教设计思路、讨论实现方案、探索最佳实践，而不只是要一段现成的代码。与此同时，用AI来打磨和改进已有代码的频率也在上升，说明AI越来越深入地嵌入到迭代开发的流程中，而不只是在"从零开始"的时刻才被召唤。

这种演变方式与技术扩散理论相吻合：新工具刚出现时，人们倾向于把它用在最简单、最安全的地方；随着信任和熟练度积累，才逐渐把它用到需要更多判断力的任务上。AI辅助编程似乎正在经历这样一个从"初级用法"向"成熟用法"的自然过渡。

六、这些发现意味着什么

研究团队从这些发现中提炼出了几个对整个软件开发行业颇具参考价值的启示。

关于知识留存的问题值得特别关注。当程序员用AI来讨论架构方案、权衡技术选型时，这些对话通常发生在聊天窗口里，结束后就消失了，不会自动记录到代码库里。代码里可能只留下一行"ChatGPT suggested this approach"，但究竟讨论了什么、有哪些备选方案、为什么最终选了这个方案——这些推理过程都不见了。如果三个月后换一个程序员来维护这段代码，他可能根本不知道这个设计决策背后的来龙去脉。研究团队建议，当AI辅助实质性地影响了某个设计或实现决策时，团队应当把推理过程简短地记录在拉取请求、Issue或设计文档里，填补这个信息断层。

关于如何衡量AI带来的生产力提升，这项研究也提供了一个新的视角。如果只用"AI生成了多少行代码"或者"从需求到第一版实现花了多少时间"来衡量AI的价值，那得到的结论很可能是失真的。因为这项研究清楚地表明，AI生成的代码在引入之后通常还需要重构、修Bug、增补测试——这些后续工作同样消耗开发者的时间和精力。真正合理的衡量方式应该覆盖代码从诞生到稳定运行的完整生命周期，把生成、集成、测试和维护的成本都纳入考量。

从更宏观的角度来看，AI辅助编程不应被理解为一次性的"生成动作"，而应被理解为一个持续演进的协作过程。AI给出初稿，程序员负责打磨、适配和维护——在这个过程中，人类的判断力和专业知识始终是不可或缺的核心要素。

说到底，这项研究讲的其实是一个关于"工具与使用者"的老故事：任何强大的工具在落地时都需要经历"适应期"，使用者会逐渐摸索出最适合自己的用法，工具与人的关系也会随着时间变得越来越有机。AI写代码也不例外。

它确实在改变程序员的工作方式，让许多重复性的代码工作变得更快，也让程序员得以把更多精力放在更需要创造力和判断力的事情上。但它没有让程序员变成"监工"，更没有让编程变成简单的"复制粘贴"游戏。恰恰相反，这项研究展示的是一幅人机紧密协作的图景——AI负责提供原材料，程序员负责雕琢、测试、改进，最终对代码质量负责。

这种模式对于那些担心"AI会取代程序员"的人来说或许是一个有说服力的反例：即使有了AI，程序员依然大量且持续地修改、优化、修复AI生成的代码，这本身就说明人类的专业判断力在软件开发中依然不可替代。

如果你对这项研究的原始数据和完整方法感兴趣，可以在arXiv平台上通过编号arXiv:2606.06843找到完整论文，研究团队也公开了所有标注指南、数据集和分析代码，供研究者复现。

Q&A

Q1：研究者是怎么在GitHub上找到程序员使用AI的证据的？

A：研究团队利用GitHub代码搜索接口，组合了AI工具名称（如ChatGPT、Copilot）、生成行为动词（如generated、suggested）和归属连接词（如by、with），构建出480条搜索指令，专门捕捉代码注释中明确提及AI的记录。筛选后保留了35,278条真实的AI使用痕迹，剔除了"Claude"是人名等干扰情况。

Q2：AI辅助写出来的代码质量怎么样，程序员会直接用吗？

A：研究发现AI生成的代码很少被直接使用而不做任何修改。在12,996条后续提交记录中，重构与清理（1,465条）和Bug修复（1,304条）非常普遍，说明AI产出通常需要程序员进行结构调整和问题修复。不过功能扩展（2,769条）是最多见的后续动作，说明AI代码的基础是被接受的，程序员在此基础上继续建设。

Q3：程序员用AI辅助编程的方式这几年有什么变化？

A：从2022年底到2026年初，让AI直接生成新代码始终是最主要的用法，但占比趋于稳定。与此同时，用AI优化改进已有代码和用AI请教技术概念的频率显著上升，说明程序员正在从把AI当"代码打印机"逐渐转变为把AI当"技术顾问"，使用方式越来越成熟多元。