近年来，代码生成类 AI 工具如雨后春笋，从GitHub Copilot 到 ChatGPT、Claude，再到Cursor等，广泛渗透到代码补全、文档生成、测试用例构造等开发环节。这些工具号称能大幅提升开发效率，然而，当前对 AI 编程效率的评估多停留在静态基准测试，聚焦单一任务，缺乏真实开发场景的复杂性。比如，某开发者在修复开源项目中的复杂 Bug 时，需同时处理多模块依赖、历史代码约束和性能优化，远非简单的代码补全所能涵盖。
本研究聚焦 AI 工具在真实开源项目维护中的实际效能，特别关注其对研发周期的加速效应。这不仅关系到开发效率，更与 AI 是否会在安全机制完善前快速超越人类研发能力密切相关，涉及技术失控风险的评估。
为确保结果科学严谨，我们采用随机对照试验（RCT）设计，邀请 16 位在大型开源项目（平均 2.2 万星，代码量超百万行）中活跃多年的资深开发者参与。实验基于他们熟悉的代码仓库，选取 246 个真实 issue，涵盖功能开发、Bug 修复和架构重构三种典型任务。
实验中，每个 issue 随机分配是否允许使用 AI 工具。允许时，开发者可自由选择生成式 AI（如 Cursor Pro 搭配 Claude 3.5 或 3.7 Sonnet）；不允许时，需完全依赖手动开发。每个任务约耗时 2 小时，开发者通过录屏记录时间，报酬统一为每小时 150 美元以确保投入。实验前后，开发者填写问卷，评估任务难度和 AI 对效率的主观影响。
为贴近真实场景，实验模拟了开发者日常工作：比如，修复一个分布式系统的 Bug，可能涉及调试跨模块调用、分析日志、优化性能，这些都需要深入理解项目上下文，而非简单调用 API。
结果出人意料：使用 AI 工具的开发者平均耗时增加 19%，效率不升反降。更令人关注的是，开发者并未察觉这一现象。实验前，他们普遍预期 AI 可提升 24% 效率；完成后，仍主观认为效率提升约 20%。这种认知偏差提示我们，仅凭直觉判断 AI 效果可能误导决策。
具体而言，AI 在大型工程任务中表现不佳，尤其在多模块依赖、复杂上下文场景下，其推理链条和状态保留能力不足。例如，某开发者在修复数据库连接池泄漏时，AI 生成的代码看似合理，却未考虑并发场景，导致反复调试耗时更长。
本研究结果有明确边界，不宜盲目推广：
换言之，本研究是 2025 年初 AI 在高复杂度开发场景中的效能快照，反映了当前技术水平的真实表现。
研究深入剖析了 AI 拖慢效率的几个关键因素，并结合场景加以说明：
这些问题表明，AI 需嵌入规范的开发流程（如代码审查、自动化测试），才能真正发挥潜力。
本研究与主流 AI 编程基准测试（如 SWE-Bench、RE-Bench）形成鲜明对比。后者常宣称 AI 能自动修复上千个 issue，表现优异。然而，基准测试通常假设问题输入明确、上下文完整，通过对比代码 diff 自动评分，忽略真实开发的多重复杂性。
真实开发中，任务往往涉及：
因此，AI 在基准测试中的 “高分” 难以直接转化为真实场景的效率提升，暴露了其在复杂任务中的 “看得懂、做得快、改得准” 三大短板。
本研究跳出理想化测试，聚焦 AI 在真实开发中的实际贡献，为评估 AI 失控风险提供了现实视角。尤其在 AI 被用于自身研发的场景下，理解其对技术演化速度的影响至关重要。
未来，我们计划：
通过持续研究，我们希望为 AI 工具的合理应用提供更清晰的指导，助力开发者在复杂工程中真正释放 AI 潜力。