devgo.cn想象一下这个场景：你的团队用 AI 编程助手，代码产出速度翻倍，但每周花在调试上的时间反而从 10 小时涨到 17 小时。更糟的是，当线上出问题时，没人能说清楚这段 AI 生成的代码到底干了什么。这不是某个团队的个别困境，而是一份覆盖 300 位资深工程负责人的调查揭示的普遍现状。
这份由独立研究机构 Coleman Parkes 代表 Undo 公司（一家专注 AI 根因分析的公司）进行的调查，专门针对负责关键任务软件（mission-critical software，即一旦出错会造成重大损失的软件系统，比如金融交易系统、医疗设备控制软件）的团队。受访者大多是 C/C++ 技术栈的工程负责人，他们所在的代码库有一个共同特点：代码必须被完全理解。在这些环境里，团队平均每周花 9.8 小时写代码，却要花 16.9 小时调试开发中或生产环境里发现的问题——调试时间占了平均工作周的 42%。
调查最核心的发现是：AI 编码代理（能自动生成代码的 AI 工具）把瓶颈从“写代码”转移到了“读代码”和“调试”上。过去，工程师写每一行代码时都带着对系统的理解，知道为什么这么写、会影响哪些模块。现在，AI 生成了大部分代码，工程师失去了这种天然的理解。结果就是缺陷更容易漏网，而当问题不可避免地出现时，没有人能把失败追溯到根因。
数据很能说明问题：35% 的 AI 生成代码在团队完全理解之前就进入了生产环境。80% 的受访者表示，编码代理在复杂代码库中难以解决难题。因此，大约三分之一的团队只敢在简单的代码库中用 AI 做理解和调试，面对复杂系统时还得靠额外的手段来建立信心。
更令人担忧的是其他高频问题：81% 的团队在过去六个月里至少经历过一次影响用户的生产事故（其中 14% 每月多次）；93% 的团队遇到过因 AI 幻觉（模型生成看似合理但实际错误的内容）导致的错误根因诊断（18% 每月多次）；91% 的团队遇到过严重缺陷或优化不佳的代码进入生产环境。
最反直觉的结论在这里：79% 的工程负责人承认 AI 代理确实能显著加快代码生成，但随之而来的调试负担意味着整体发布周期“并不比以前快”。Undo 的创始人兼 CEO Greg Law 总结得很到位：工程师们“花好几天试图解开哪里出了问题、为什么出错”，面对的是“几乎正确但不完全正确”的代码。AI 代理擅长快速写出大段代码，却不擅长调试这些代码。
为什么会出现这种“理解鸿沟”（comprehension gap）？核心在于 AI 编码工具改变了软件工程的认知负担结构。传统开发中，写代码的过程本身就是理解系统的过程——你在写一个函数时，会自然思考它如何被调用、边界条件是什么、与其他模块的交互方式。AI 生成代码把这一过程压缩了，你拿到的是结果，不是推理过程。这就像请了一个写作速度极快的代笔，但他写出来的文章你未必能完全理解，更别说修改和负责。
社区里已经出现了一些应对思路。测试优先的红绿循环（先写失败测试，再写代码让它通过，最后重构）被重新重视，因为它至少能验证 AI 生成代码的行为是否符合预期。还有人用自动化回退机制（当 AI 生成的代码无法通过测试时自动回退到上一版本）来控制风险。但这些方法都只是缓解，没有解决根本问题：AI 生成的代码需要被理解，而理解需要时间。
这个调查对普通开发者的启发很直接。如果你正在用 AI 编码工具，别被“代码生成速度”这个指标迷惑。真正要关注的是你的团队在调试和理解上花了多少时间。一个实用的做法是：对 AI 生成的代码设置更严格的审查门槛，尤其是那些涉及核心业务逻辑、并发处理、安全敏感的部分。另一个思路是让 AI 生成代码时附带更详细的注释和设计说明，甚至要求它解释为什么这么写，而不是只给结果。
最值得记住的一点是：AI 代理并没有改变软件工程的本质。软件工程从来不只是写代码，而是理解约束、做权衡、确保系统按预期工作。AI 加快了“写”的部分，但“理解”和“确保正确”的部分依然需要人来完成，而且这部分工作现在变得更难了。工具越强大，对使用者的理解能力要求就越高——这可能是 AI 编程时代最容易被忽视的悖论。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/news/2026/10/survey-complex-codebases-agents/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global