当AI程序员开始"自作主张"：斯坦福大学揭开真实开发场景中AI编程助手的神秘面纱

这项由斯坦福大学主导的研究发表于2026年4月，论文编号为arXiv:2604.20779v1，归档于cs.AI领域。有兴趣深入了解的读者可通过该编号在arXiv平台查询完整论文。

**研究背景：一个被忽视的大问题**

每天都有数以百万计的软件开发者在使用AI编程助手写代码。这些工具声称能大幅提升效率，各大科技公司的报告也充满了令人振奋的数字。然而，有一个核心问题长期以来几乎无人能够回答——这些AI助手在真实工作场景中，到底表现如何？

这不是一个无关紧要的问题。当我们说"AI助手帮我写了代码"，背后藏着很多值得追问的细节：这些代码最终真的被用上了吗？程序员在过程中需要纠正AI多少次？AI写出的代码安全可靠吗？以前，这些问题的答案要么来自经过精心设计的实验室测试，要么来自企业自己发布的宣传材料，两者都难以真实反映开发者的日常体验。

斯坦福大学的研究团队决定彻底改变这一局面。他们构建了一个名为SWE-chat的数据集，收录了来自真实开源项目、由真实开发者与AI编程助手进行的完整对话记录。这是同类数据集中第一个同时包含完整人机对话、AI工具调用轨迹，以及精确到每一行代码的"这行是人写的还是AI写的"归属信息的数据集。截至2026年4月，数据集已收录来自200多个公开GitHub仓库的近6000个编程会话，超过6.3万条用户指令，以及35.5万次AI工具调用，总计270万个记录事件。

**一、数据是如何收集的——给代码装上行车记录仪**

要理解这项研究的价值，得先弄清楚数据是怎么来的。研究团队借助一个名为Entire.io的开源工具完成了数据采集工作。这个工具的运作方式有点像给汽车装行车记录仪——开发者在自己的电脑上安装这个工具后，工具会自动在后台静默记录每一次与AI编程助手的对话，包括开发者输入了什么、AI回应了什么、AI调用了哪些工具（比如读取了哪个文件、执行了什么命令），以及最终提交到代码库的是哪些内容。

更精妙的是，这个工具还会将对话记录与git版本控制系统深度集成。简单来说，git是程序员用来追踪代码变更历史的工具，每一次代码修改都会留下记录。Entire.io通过在git提交节点插入钩子程序，能够在代码被正式保存时，精确标注出哪些行是人类写的、哪些行是AI写的。这就像在每篇文章的每一行旁边，都标注了"作者：张三"还是"作者：AI助手"。

参与数据采集的开发者需要主动选择加入，并将自己的会话日志推送到公开的GitHub分支。研究团队通过查询GitHub代码搜索接口，自动发现并下载这些公开的记录。这套流程完全自动化、持续运行，数据集因此成为一个"活的"数据集，会随时间不断扩充。从2026年1月到4月，累计用户提示数量呈现出陡峭的上升曲线，增长速度相当惊人。

当然，这种采集方式也有其局限性。参与的开发者都是主动选择使用Entire.io的早期采用者，他们不一定代表所有程序员群体。此外，如果开发者完全放弃了AI生成的代码，这个会话根本不会被提交到代码库，也就不会出现在数据集中。这意味着数据集可能略微高估了AI的成功率。研究团队在论文中坦诚指出了这些局限，体现了相当的研究严谨性。

**二、三种不同的人机协作模式——从"完全自己来"到"完全交给AI"**

数据分析揭示了一个非常有趣的规律：在这6000个会话中，人类和AI之间的分工方式呈现出极端的两极化分布，中间状态相对稀少。研究团队据此将所有会话归纳为三种截然不同的编程模式。

第一种模式被称为"人类主导编程"，占所有会话的22.7%。在这些会话中，最终提交到代码库的代码全部由人类自己编写，AI更像是一个聪明的参考工具，被用来解释代码、排查问题、或者处理版本控制操作，而不是直接生成代码。

第二种模式叫做"协作编程"，占36.5%。在这里，人类和AI共同贡献了最终提交的代码，AI负责其中超过0%但不足99%的部分。两者各司其职，相互配合。

第三种模式最引人注目，叫做"氛围编程"（vibe coding），占40.8%。在这些会话中，超过99%的最终代码都由AI生成，人类更像是一个监督者和验收者，而不是真正意义上的代码编写者。这个词源于编程社区，描述的是那种几乎把所有代码生成工作都甩给AI、自己只管提需求和审查结果的工作方式。

令研究团队印象深刻的是，氛围编程的比例在短短三个月内翻了一番——从2026年初的约20%增长到4月份的超过40%。换句话说，越来越多的开发者正在将代码生成的控制权整体转让给AI。这是一个正在加速发生的趋势，而不是某种边缘现象。

从整体数字来看，所有提交到代码库的代码中，55.8%是由AI撰写的。但如果只看中位数，这个数字是73.3%，说明在更多的会话中，AI承担了大部分甚至绝大多数的代码生成工作。这两个数字的差异，恰恰说明了那种双峰分布的存在：许多会话几乎全是人写的，另一批会话则几乎全是AI写的，中间状态反而不多。

**三、开发者到底在用AI做什么——超出你想象的用途多样性**

在研究团队对所有用户提示的意图进行分类后，一个出乎意料的发现浮出水面：开发者最常向AI提出的请求，并不是"帮我写这个功能"，而是"帮我理解这段代码"。

具体来看，26.6%的提示被归入"其他"类别，说明编程场景的多样性难以简单归类。在明确分类的请求中，理解现有代码或程序行为是最常见的单一意图，占所有提示的19.0%。创建新代码以13.4%排在第二位。日常开发任务同样占据相当比例：git版本控制操作占13.4%，调试排错占13.0%。代码重构占9.2%，编写测试占4.0%，设置系统连接占1.0%。

这个分布揭示了一个被现有AI基准测试严重忽视的现实：真实世界中的开发者并不主要把AI当成代码生成机器，他们更多地将其用作代码理解工具和日常工作助手。然而，几乎所有的AI编程能力评测（如SWE-bench等知名基准）都聚焦于"能否修复这个bug"或"能否实现这个功能"，对AI在代码理解、版本控制辅助等任务上的能力测量几乎是空白。

在AI的工具调用层面，数据同样很有启发性。AI每次响应用户请求时，往往会连续执行多个操作。从工具类型分布来看，读取文件（19.8%）和编辑文件（19.6%）是最常见的两类操作，合计约占所有工具调用的四成。git相关命令（11.9%）、grep搜索（10.1%）和构建命令（8.0%）也是高频操作。

从时间顺序来看，AI在处理一个请求时有固定的行为模式：在对话开始时倾向于使用读取、搜索和git等信息收集工具，随着工作推进，文件编辑、写入和构建命令的比例逐渐增加。这就像一个认真的工匠，先把图纸看清楚，再动手施工。

**四、用户的行为习惯——为什么AI总是挨骂**

研究团队不仅分析了AI的行为，还对用户的互动风格进行了系统分类。他们将每个会话中的用户归入四种"行为人格"之一。

最常见的人格是"挑剔专家"，占所有会话的39.7%。这类用户技术能力强，目标清晰且稳定，但对执行细节极度讲究。他们会针对AI输出的每一个细节给出精确的纠正意见，但整体方向不会变化——就像一个对厨师有很高要求的食客，要求改火候、换调料，但始终点的是同一道菜。

排在第二位的是"模糊请求者"，占33.5%。这类用户倾向于给出笼统的指令，把大量决策权交给AI，也不太会对细节进行纠正。他们的典型提示是"帮我把这个做好"之类的宽泛表述。

"其他"类型占19.9%，通常是会话太短或行为模式不明显导致无法归类。

"善变者"是最少见的类型，只占7.0%。这类用户会在会话进行到一半时改变整体目标，要求AI推倒重来。前面看的一个典型例子是：用户先让AI隐藏一个命令行指令，AI按要求完成了，然后用户说"我想了想，干脆把这个命令彻底删掉"。

一个特别值得关注的细节是，就算在氛围编程会话中，挑剔专家依然是最常见的用户类型，比例达到47%。这说明即便把代码生成工作全权交给了AI，大多数开发者仍然保持着对输出结果的高标准要求，远没有完全"放手"。

另一个对比鲜明的观察是：现有的AI编程基准测试往往在一开始就给出完整详尽的问题描述，假设用户的需求是清晰而完整的。但真实场景中，用户更多时候是在看到AI的第一次输出之后，才开始清晰化和细化自己的要求。这是测试环境和真实环境之间的一个根本性差异。

**五、AI的效率真相——超过一半的代码被扔掉了**

这是整篇论文中最让人清醒的部分。研究团队设计了一套精密的指标体系来衡量AI生成代码的实际效用，核心发现是：所有AI生成的代码中，只有44.3%最终进入了用户提交的版本，其余55.7%都被丢弃了。

研究团队对"丢弃"的原因做了进一步拆解。最主要的浪费来源是"人类删除"——AI生成了代码，但用户直接决定不提交这些代码，比例高达42.2%。其次是"人类改写"，用户觉得AI的代码方向对了但具体实现不满意，自己动手改掉，占9.3%。还有"AI自我改写"，这发生在用户反馈后AI将自己之前的代码重写的情况，占6.6%。

在三种编程模式之间，效率差异也相当悬殊。协作编程模式下，AI生成的代码只有38.2%的编码效率（即考虑了AI的自我改写开销后，最终进入提交的比例），代码存活率为44.1%。氛围编程模式下，存活率看上去更高，达到59.0%，但这很可能部分反映的是用户审查力度的降低，而非AI质量的提升。

成本和时间方面，氛围编程的开销远超协作编程。以每100行最终提交代码为基准，氛围编程消耗的token数（AI处理信息量的计量单位）约为协作编程的3倍，美元成本的中位数为0.13美元，协作编程只需0.05美元，人类主导编程需要0.07美元。时间上，协作编程是最高效的，每100行提交代码只需4.8分钟，而氛围编程需要12.6分钟，人类主导编程需要8.6分钟。在用户自己花费的提示字符数（可以理解为沟通成本）上，氛围编程同样是最高的。

协作编程在所有维度上都是最高效的工作模式。这个发现颇具讽刺意味：当前业界正在大力推动的全自主AI编程趋势，恰恰是效率最低的工作方式。研究团队明确指出，这并不是在论证不应该使用AI，而是在揭示当前AI的运作方式存在大量可以改进的空间。

**六、安全危机：AI写的代码有多不安全**

研究团队对所有代码提交进行了安全扫描，使用的是Semgrep这款开源静态分析工具。这个工具能够在代码中识别已知的安全漏洞模式，比如SQL注入（黑客通过特殊输入操控数据库的攻击方式）、命令注入（通过恶意输入让程序执行危险命令）、路径遍历（绕过限制访问不该访问的文件）等。

扫描结果令人担忧。以每1000行提交代码引入的新漏洞数量为指标，人类主导编程模式引入了0.08个新漏洞，协作编程引入了0.14个，而氛围编程引入了0.76个——大约是人类主导编程的9倍，是协作编程的5倍多。

有人可能会说，AI写的代码量更多，所以引入漏洞的绝对数量多是正常的。但这里的统计已经是每1000行的比率，排除了代码量的影响。换句话说，AI在氛围编程模式下写出的代码，本身就更容易存在安全问题。

研究团队还观察到，氛围编程也修复了更多漏洞（每1000行0.52个，相比人类主导的0.04个），这反映出AI处理的代码改动中安全相关内容更多。但无论在哪种模式下，新引入的漏洞数量都多于修复的漏洞数量，而氛围编程中这一差值最大。

从漏洞类型来看，最常见的是JavaScript路径拼接未做安全处理，其次还有不安全的格式字符串、缺失完整性校验、操作系统命令注入和SQL注入等。这些都是程序安全性中的经典问题，理论上每个有经验的开发者都应该规避，但AI在没有明确约束的情况下显然并不能可靠地做到这一点。

论文中提供了一个具体的Python代码漏洞例子：AI生成了一个函数，直接将用户传入的参数拼接进shell命令字符串并用`shell=True`执行，这是一个教科书级别的命令注入漏洞——任何人只要传入特殊字符，就能在服务器上执行任意命令。

**七、谁在掌控局面——AI独立作业越来越久，用户反推越来越多**

研究团队对会话中的"控制权交接"进行了深入分析，揭示了一个有趣的动态格局。

从AI主动暂停的角度来看，在所有Claude Code的会话轮次中，AI只在1.1%到2.6%的轮次中主动停下来向用户提问寻求澄清。氛围编程模式下，这个比例更低。换句话说，AI几乎从不说"我不确定，你的意思是...吗？"它更倾向于自己做决定、继续执行。

与此形成鲜明对比的是，用户的干预频率要高得多。在所有轮次中，用户在AI仍在工作时直接打断（硬中断）的比例为3.3%到6.0%，这个数字在整个数据收集期间保持稳定，不随时间变化。打断最常发生的时机，是AI刚刚完成规划准备进入执行阶段、进行git操作或编辑文件的时候——这些都是用户觉得"等一下，不对"的关键节点。

更普遍的是软性反推，也就是在AI完成一轮输出后，用户在下一次提示中对AI的输出进行纠正、拒绝或报告问题，而不是直接打断。总体来看，所有轮次中有39%到41%包含了某种形式的用户反推，而且这个比例在三种编程模式下几乎相同。

用户反推被分为三种子类型：纠正（用户指出AI的方向或理解有误，提供正确信息）是最常见的，其次是失败报告（用户反映AI的代码不能正常运行），拒绝（用户明确表示不接受AI的输出，要求重来）相对较少。

从时间趋势来看，AI的单轮工作时长在悄悄增加。中位数仍然不到1分钟，90百分位数不超过7分钟，但最顶端的0.1%已经超过了100分钟。这意味着AI正在变得更加自主，能够在没有人类干预的情况下工作更长时间——但这种自主性的增加，并没有伴随着更少的错误或更高的代码质量。

**八、多数会话成功，但失败案例很有价值**

对所有会话进行综合成功率评分的结果显示，90%的会话获得了50分以上的评分（满分100分），说明AI在大多数情况下还是能够完成用户的基本需求的。会话成功率的总体均值为82分，中位数为82分。有趣的是，人类主导编程模式的平均成功率略低于协作和氛围编程，这可能是因为在人类主导模式下，AI主要承担辅助理解和解释的角色，这类任务本身更难评判是否成功。

研究团队对评分最低的50个会话进行了人工审查，发现了几类典型失败模式。最常见的是用户在AI给出有效输出之前就中止了会话。还有一类是AI经过大量搜索工具调用后依然无法找到相关代码，陷入死循环。有会话因为AI被提示词中提到的使用配额耗尽而强制中止（"你的额外使用量已耗尽，凌晨1点重置"）。也有AI能够诊断出问题所在，但拒绝实际修复的情况。还有AI将任务转给子代理但什么也没执行的情况。

这些失败案例中有一个印象深刻的例子：用户请AI修复历史列表卡片动画出现缓慢的问题，具体是容器动画太慢。AI在第一次和第二次回应中都修改了单个卡片的动画参数，用户两次指出错了，请AI先弄清楚哪个参数控制容器动画再修改。会话最终在没有任何提交的情况下结束，评分只有10分。

**总结：一面镜子，照出真实的AI编程**

归根结底，SWE-chat这个数据集和基于它的分析，做了一件非常简单但极有价值的事情：把AI编程助手从测试台搬到了真实的工作桌上，如实记录下发生的一切。

这幅图景既有令人鼓舞的部分——超过一半的提交代码由AI完成，大多数会话最终达成了用户目标——也有需要认真对待的隐患：超过一半的AI生成代码被丢弃，氛围编程模式下代码安全漏洞率是人类编程的9倍，而AI几乎从不主动寻求澄清。

对于普通用户来说，这项研究的最直接启示是：和AI协作写代码，保留自己的判断和介入，效果往往比完全放手给AI更好、更安全、成本也更低。完全的"氛围编程"在效率和安全性上都付出了相当大的代价。

对于研究者和工具开发者来说，这项研究指出了几个明确的改进方向：让AI学会在适当的时候主动寻求确认，而不是一路闷头执行；设计出能反映真实协作过程的评测基准，而不是继续用精心设计的单轮问题来评估多轮交互工具；以及从真实的人机互动数据中训练能模拟用户行为的模拟器，降低评估成本。

SWE-chat是一个会持续更新的活数据集，研究团队承诺定期发布新数据，随时间追踪AI编程行为的演变。这意味着我们终于有了一面持续更新的镜子，能够看清AI编程工具在现实中真正的样子——而不仅仅是实验室条件下最好的模样。对这个领域感兴趣的读者，可以通过arXiv编号2604.20779查找原论文，数据集和代码也以开源形式对外开放。

---

Q&A

Q1：SWE-chat数据集是什么，它和以前的AI编程数据集有什么不同？

A：SWE-chat是斯坦福大学构建的真实开发者与AI编程助手的对话数据集，包含近6000个真实会话。它最大的不同在于同时拥有三项其他数据集都缺失的内容：真实用户提示、完整的AI工具调用轨迹，以及精确到每行代码的人类与AI归属标注。之前的类似数据集（如SWE-smith、CoderForge等）只有AI自动化轨迹，没有真实用户参与，也无法区分哪行代码是谁写的。

Q2：氛围编程为什么被认为效率更低，不是AI做了更多工作吗？

A：氛围编程中AI确实写了更多代码，但问题在于大量代码被浪费了。以每100行最终提交代码为基准，氛围编程消耗的token是协作编程的约3倍，美元成本是协作编程的2.6倍，耗时也接近协作编程的3倍。协作编程的效率更高，因为人类的实时参与帮助AI少走弯路，减少了无效代码的生成量。

Q3：AI写的代码为什么比人写的代码更容易出现安全漏洞？

A：研究通过Semgrep安全扫描发现，氛围编程每1000行引入0.76个新漏洞，是人类主导编程（0.08个）的约9倍。原因在于AI在生成代码时往往优先满足功能需求，不会像有经验的人类开发者那样自动规避常见安全陷阱，比如直接拼接用户输入执行shell命令。而且AI几乎不会主动说"这里有安全风险"，错误只能等用户检查时才会被发现。