近年来，诸如GitHub Copilot、Cursor等AI编程助手逐渐成熟，展现出辅助软件开发的潜力。然而，在企业级的软件工程实践中，现有AI要全面取代人类工程师仍面临诸多技术与模型能力上的障碍。本文将从软件开发各环节分析AI的表现能力与不足，并评估当前主流AI开发助手（如Cursor、Windsurf、Devin、Manus等）的应用现状和限制，探讨这些工具的能力边界以及在协作、推理、上下文管理等方面的差距，剖析AI模型在大型代码库和复杂系统场景下的处理能力与失败案例，最后汇总业界和学界对AI驱动软件工程瓶颈的认识。

AI在软件开发各环节的能力与不足
现代软件开发流程通常分为需求分析、架构设计、编码实现、测试验证和维护迭代五个阶段 。下面逐一分析AI在每个环节的能力表现及局限。

理解业务需求
在需求分析阶段，生成式AI可以发挥文本理解与总结的作用。对于给定的业务需求文档，AI模型能够提取其中的关键概念和关系，并帮助绘制业务流程，从而协助开发者理解需求 。例如，Claude等模型已被用于将产品经理与系统分析师的对话总结为概念模型，自动生成业务流程图，帮助识别遗漏的领域概念 。这些能力表明AI在处理明确描述的需求时有一定优势，尤其是总结大量文本、提炼要点和格式化输出方面。

然而，AI对业务需求的深层理解仍存在不足。首先，需求往往包含隐含假设和业务背景，当前的语言模型缺乏真实世界常识和领域知识的保障，可能无法领会需求背后的商业意图。例如，对于一句含糊的需求描述，模型可能生成与预期不符的解释或方案，需要人工校正。其次，AI缺乏主动澄清和追问能力（除非经过特定提示设计），面对不完整或矛盾的需求时可能给出自以为是的回答，导致误解需求。总体而言，在需求分析环节，AI更适合作为辅助工具：帮助梳理已有资料、生成初步的需求文档或用户故事，但关键决策和理解仍依赖人类业务分析师把关。

架构设计与模块划分
针对系统架构设计，AI模型可以参考已知的设计模式和架构范式提供建议。在设计阶段，开发者可以利用AI对概念模型进行扩展优化，让模型提出新的实体、属性或关联关系的建议，并自动生成可视化的模型图以供参考 。例如，对于一个典型的Web应用需求，AI可能建议采用分层架构或微服务，并列出可能的模块（用户管理、订单处理等），因为这些模式在训练语料中广泛存在。

但全局架构规划是AI目前的弱项。大型语言模型受限于有限的上下文窗口，难以在一次对话中考虑大型系统的所有组成部分 。这意味着模型无法像资深架构师一样通盘考虑性能、安全、可扩展性等各方面需求来设计架构。如果让AI一次性输出完整的复杂系统设计，往往会遇到不一致或遗漏。正如业界人士指出的，“上下文窗口长度有限……如果不能全局了解整个项目，就很难去设计架构和拆分模块” 。因此，当前AI在架构设计上更多扮演助手角色：提供通用模式参考、检查明显的不一致之处，而真正因地制宜的架构决策仍需架构师做出。

此外，模块划分需要对系统的职责边界有明确认知。AI虽然可以根据经验列出一系列模块名称，但哪些功能归属哪个模块、模块之间如何接口等细节，模型可能缺乏准确判断。如果需求有细微差异，AI给出的模块方案可能生搬硬套常见模式而不适用。因此，在模块划分环节，AI建议可供脑暴参考，但工程师通常需要根据实际情况进行调整，以确保模块边界清晰、耦合度低、满足业务和团队分工需求。

代码编写与实现
代码生成是当前AI在软件工程中最具实用价值的环节。以GitHub Copilot为代表的AI Coding工具能够根据开发者的自然语言描述或部分代码上下文，自动生成相应代码，大幅提升开发效率 。研究表明，使用Copilot的开发者编程速度提高了55%，手工编码量显著减少 。主流的大模型（如GPT-4、Code Llama等）已能胜任生成中小规模函数、补全样板代码、将伪码转为代码等任务，对于熟悉的编程语言和框架，其输出往往接近可用。这使得工程师可以将重复繁琐的实现工作交给AI完成，自己专注于更高层次的问题。

但在代码实现细节上，AI仍存在准确性和健壮性不足的问题。首先，模型生成的代码虽然语法上大多正确，但逻辑上可能偏离初衷或包含隐蔽的缺陷。模型基于统计相关性产出代码，缺乏真正理解，因而容易出现例如边界条件处理不当、异常未处理、资源泄露等问题。其次，对于复杂算法或新颖问题，AI可能给出错误方案。

例如要求AI实现一个特定性能优化算法，如果超出训练中见过的范畴，模型可能编造一个看似合理实则错误的实现。再次，AI对上下文依赖敏感：若所需用到的全局变量、类型定义等不在当前提示范围内，生成代码会出现调用不存在的接口或不匹配的数据结构。这在大型项目中尤为突出，稍有不慎AI生成的代码就与项目其他部分不兼容。

因此，在编码阶段，AI最适合处理局部性强、模式明确的任务，如CRUD操作、格式转换、标准算法实现等。开发者应当对AI生成的代码进行严格测试和审查，将其视为“初稿”，然后由人类工程师调试、优化后才能投入使用。如果完全不经过验证地采用AI产出代码，可能引入难以察觉的Bug和安全漏洞（后文将详述AI代码中的安全风险）。

测试与质量保证
在软件测试环节，AI也开始展现辅助能力。大型模型可以根据函数签名或代码逻辑自动生成单元测试用例，这对于开发者来说节省了编写重复测试代码的时间。一些研究致力于让AI生成更高覆盖率的测试集，以捕获代码中的潜在缺陷 。实践中，开发者可以让ChatGPT根据函数描述生成典型的输入输出测试，或让AI根据接口规范生成API的集成测试框架。这种基于描述生成测试的方法，能在一定程度上保证关键路径的正确性。

然而，AI自动生成的测试用例目前仍比较初级，存在不全面和不精准的局限。首先，模型往往倾向于测试正常路径：生成的用例大多针对预期的输入，而对异常输入、边界值、极端情况的覆盖不足。这导致生成的测试可能无法发现边界条件下的漏洞。其次，如果AI对被测代码理解有误，生成的断言可能检查错误的预期结果，甚至测试本身就是无效的。

再者，维护负担也是问题：如果需求变更导致代码修改，AI生成的大量测试用例需要更新，否则会出现不通过的情况，反而增加维护成本 。因此，目前AI生成测试用例主要适合作为参考补充，帮助开发者想到更多测试场景，但不能取代严谨的测试设计。对AI产出的测试仍需人工复核，必要时增删修改以确保覆盖充分且断言正确。除了生成测试，AI在静态代码审查方面也有所应用，例如通过大模型识别常见的错误模式或安全隐患，为代码质量保驾护航。但同样地，其检查结果需要人工确认以避免误报或漏报。

软件维护与迭代

软件的维护阶段包括代码重构、性能优化、修复生产Bug以及适应新需求的迭代开发。AI在这些持续工程活动中能提供一些帮助，但能力更有限。对于代码重构，开发者可以借助AI工具进行重命名、提取函数、调整结构等建议。例如让AI根据代码含义自动重命名变量和函数、更改函数划分，这在局部范围内（单个文件或函数内）有一定效果。

然而大规模重构（跨数十个模块调整接口）涉及全局一致性检查，AI难以确保一致修改。开发者常需要借助静态分析工具找到所有调用点，再配合AI生成修改建议，最终仍靠人工验证每处改动，以确保模块边界清晰、耦合度低、满足业务和团队分工需求。

在Bug排查方面，如果将错误日志、异常栈等信息提供给AI，模型有时能根据常见模式推测问题原因并给出修复思路。这在处理典型错误（如空指针引用、数据库连接超时）时比较有效。然而对于复杂业务逻辑错误，AI缺乏真实执行环境的反馈，仅凭代码静态分析能力有限，往往无法准确定位根因。实践中，工程师可能采用“AI+调试”结合：先自己定位大致范围，再让AI协助检查可能的逻辑分支和漏洞点，将人机优势结合。

主流AI开发助手在企业场景的应用现状和限制

工具名称	定位与类型	主要功能特点	局限性与不足
GitHub Copilot	云端AI编码助手（IDE插件）	从注释/上下文生成代码片段，智能补全 支持多种语言，深度集成VS Code等IDE环境	对持续对话支持有限，无法主动拆解复杂任务 有时生成代码不正确或不安全，需人工审校
Cursor	本地AI代码编辑器（VS Code分支）	实时代码自动完成（Next Line预测）、自然语言修改代码 高亮错误并建议修复，智能导航代码上下文	对大型复杂项目支持不足，扩展性受上下文窗口限制 只能在IDE中作用，无法独立执行多步骤任务
Windsurf	独立AI驱动IDE（Codeium出品）	“Cascade”项目构建器，可根据高层目标逐步生成多文件代码 支持跨文件编辑和上下文感知的代码建议 内置对话式助手，提供指导和解释	即时交互相对Cursor略有延迟 新兴产品，部分复杂场景下功能有待验证，仍需开发者监督
Devin	自主编程Agent（全栈AI工程师）	可自主运行完成编码、调试、部署等任务，强调“设置后忘记”式自动化 支持前后端和数据库操作，能学习项目最佳实践逐步提升	处理复杂后端配置等任务时速度较慢 输出质量不稳定，偶尔仍需人工介入审核
Manus	通用AI智能代理（多工具集成）	可调用浏览器、计算等工具完成检索和操作 具备自行开发小工具的能力（例如编写脚本辅助完成任务） 可将多个LLM模型组合使用，无缝切换以发挥各自优势	尚处于原型探索阶段，缺乏自有基础模型支撑 在企业实际环境中验证不足，可靠性和安全性有待观察

这些工具的能力范围与自动化边界
任务胜任类型： 当前AI开发助手最擅长的是细粒度的编码任务和重复性工作。如表所示，Cursor等可以即时提供代码补全、根据指令修改代码，在开发者实现具体功能时充当高效的“第二双手”。Windsurf等工具能够根据简要的任务描述产出初步的代码结构，适合构建简单应用原型或生成样板代码。Devin这类Agent善于处理结构化明确的任务，例如批量修复一类重复的错误、执行标准的部署流程 。总体来看，这些AI工具在有清晰目标或范式的任务上表现出色，包括：
代码片段生成：根据函数描述或注释生成实现代码，或根据上下文补全后续代码行，这是最经典的应用场景，AI能够学习大量开源代码模式来完成此类任务。
框架/配置样板：自动生成常见框架的标准代码，如创建一个React组件模版、Spring Boot配置代码等，让开发者免去查文档和手写样板的时间。
错误修复建议：当出现编译错误或简单运行时错误时，AI可以根据错误信息和代码上下文提出修改建议（例如缺少空指针检查等） 。
代码解释与文档：针对已有代码，AI能够用自然语言解释其功能，甚至生成简要文档或注释，方便接手陌生代码的工程师快速了解含义。

单元测试生成：如前文所述，AI可根据函数接口初步生成一些测试用例，为开发者提供测试思路。

然而，复杂创新性任务仍超出这些工具的胜任范围。例如，让AI独立完成一个从零开始的大型项目（涉及多模块、多团队协作）目前并不现实。即使是Devin号称“全自主”，在遇到需要综合多方面权衡的新问题时也往往力不从心，需要人类介入决策 。Manus具备调用工具和编写脚本的能力，看似更灵活，但对问题的分解和推理要求极高，在开放场景下能否正确拆解复杂任务仍未有充分验证。因此，这些AI的自动化能力有明确边界：明确规则内的任务可自动执行，超出经验范畴的创造性工作仍依赖人类。

人机协作方式： 不同工具在人机协作上体现出差异化设计。以Cursor和Copilot为代表的IDE插件采用紧耦合协作——在人类实时编码过程中提供片段建议，开发者随时决定是否接受或编辑AI产出。这种模式下，人保持对代码的掌控，AI充当辅助智囊，二者协同完成代码。相比之下，Devin的模式更偏向异步协作：开发者将任务描述委托给AI，AI自主完成后交付结果 。

开发者不参与中间过程，而是在结果出来后进行验收和调整。这种方式减少了人工干预频率，但对结果可靠性要求更高，一旦AI输出不符合预期，来回调整的成本也会上升。Manus这类通用Agent则尝试工具协同，它可以自动在浏览器查资料、调用计算资源验证，再产出结果 。从用户角度看，仿佛有一个会自己想办法解决问题的智能实习生，可以自主选择手段。这代表了一种更高级的协作形态：人只需提出目标，AI通过调用各类工具和服务来协助达成目标。

推理与规划能力： 传统的代码补全型AI几乎没有显式的推理过程，属于即时反应模式——给定输入立即预测下一步输出。这样虽快，但在需要多步推导时就捉襟见肘。为克服这一局限，新一代工具引入了一定的推理和规划机制。例如，Windsurf的Cascade功能本质上是让AI对开发任务进行步骤分解，一步步生成代码 。

这要求模型在生成过程中保留对整体任务的理解，规划下一步要实现哪个部分，再产出代码段，接着更新环境后再考虑下一步，类似逐层深入。这种链式思考能力使AI在复杂任务上成功率提升，因为它不会一下试图产出全局方案，而是模拟人类的逐步细化过程。同样，Devin在执行多阶段部署等工作流时也体现了一定的规划：如先克隆代码仓库、再安装依赖、再运行测试等顺序 。然而，总的来看，当前AI的推理能力仍相当有限，远未达到自主规划复杂项目的程度。很多时候，这些“推理”其实是预先模版化的流程，并非即时生发的通用智能推理。真正开放式的问题分解，AI往往需要提示或模板引导才能做到，而且深度有限。

上下文管理能力： 软件工程中上下文包括代码上下文（整个项目的代码库）、开发历史和会话上下文（与用户的交互历史）。各工具对上下文的管理能力差异显著。Cursor等IDE内工具依赖IDE本身提供的项目索引功能：例如Cursor可以在提示时检索相关文件内容，将其提供给模型，从而使生成代码考虑到项目内定义的函数或类型 。这使得在一个中小型项目中，AI能够“看到”相关的上下文，从而减少不一致。

例如当开发者请求修改某模块时，Cursor能定位到该模块文件并参考其中内容建议修改。这种局部上下文嵌入在IDE中较容易实现。但当项目规模很大时，即使IDE能索引上万行代码，也无法全部放入AI的提示窗口。由于模型的硬性上下文长度限制（常见为几千到几万token），它无法一次性加载整个大型代码库。这直接导致全局理解缺失。开发者常常发现，如果直接让ChatGPT编写一个大型系统的某个新功能，模型由于看不到相关模块定义，可能会编写出与现有模块不兼容的代码。例如，要求AI在一个已有微服务架构中添加新服务，它可能重复已有服务的部分功能或者调用并不存在的API，因为它并不了解系统中已有的服务清单。

一个解决方案是将任务分解并逐步提供上下文：实践者分享经验称，应将复杂任务拆成小步骤，每次只实现一个子功能，并提供当前最相关的代码上下文给AI，这样才能让模型在上下文窗口内完成子任务，再逐步叠加构建出复杂模块。这种人工干预式的分阶段开发，本质上是人为替AI管理上下文。然而，这也凸显了模型自身无法统筹长程上下文的局限——一旦缺少人工分段，AI直接面对庞大任务时往往无法实现或结果很差。可见上下文限制是AI处理大型代码库时最基本的障碍，它迫使我们采用片段式对话和迭代开发流程来弥补模型认知范围的不足。

大型代码库和复杂系统场景下的AI表现与失败案例
企业级软件通常规模庞大、模块众多，并涉及各种外部系统和依赖。这种真实工程环境对AI模型提出了严峻挑战：如何在不了解全局的情况下正确处理局部任务，并保持跨模块的一致性？ 当前的经验表明，大模型在这些场景中容易遇到上下文、协同和执行方面的失败，下面结合典型问题进行分析。

上下文窗口限制导致的认知不足： 正如前文所述，大模型一次能处理的上下文（输入+输出）是有限的。当代码库规模超过模型窗口时，AI无法一次读取所有相关代码。这直接导致全局理解缺失。开发者常常发现，如果直接让ChatGPT编写一个大型系统的某个新功能，模型由于看不到相关模块定义，可能会编写出与现有模块不兼容的代码。

例如，要求AI在一个已有微服务架构中添加新服务，它可能重复已有服务的部分功能或者调用并不存在的API，因为它并不了解系统中已有的服务清单。一个解决方案是将任务分解并逐步提供上下文：实践者分享经验称，应将复杂任务拆成小步骤，每次只实现一个子功能，并提供当前最相关的代码上下文给AI，这样才能让模型在上下文窗口内完成子任务，再逐步叠加构建出复杂模块 。

复杂依赖与环境配置问题： 企业系统常与各种数据库、中间件、第三方服务集成，部署在特定基础设施上。这些运行环境和依赖对代码有直接影响。AI由于不了解实际环境，可能生成不适用的配置或调用。例如，一个AI生成的数据库访问代码可能使用默认配置，但在企业环境中需要特殊认证方式，这种差异AI并不知晓，导致生成的代码在真实环境下无法运行。

又比如，AI可能不了解公司内部库的用法，把第三方库的示例代码套用上去，结果与内部接口不匹配。更棘手的是跨系统交互场景：假设有前端与后端协同的功能，如果让AI分别生成前端React代码和后端API代码，稍有不慎就会出现字段不一致、协议不匹配的情况——因为AI无法同时保证两个模块严格遵循同一契约。在实际测试中也发现类似现象：当让纯模型自动生成一个全栈应用时，就曾出现前后端连接不上的问题，最终不得不由人工调整接口定义来适配。

这属于AI在协同多个组件时的失败案例。它往往缺少全局的共享状态：人类工程师脑中会有一个整体模型，知道前后端需要匹配，而AI如果分别生成，除非通过精心的提示让其意识到对应关系，否则容易各自为政，导致对接失败。

跨模块一致性和引用问题： 在大型代码库中，修改一个模块可能需要同步修改许多相关模块。例如更改了某个核心数据结构的字段名，那么所有用到该结构的代码都要更新。AI如果只知道需要修改这一处，很可能漏掉其他引用。IDE的批量替换可以解决简单一致的替换问题，但涉及更复杂的级联修改（如函数参数变化，调用端逻辑也需改变）时，就需要深入理解每个调用场景。

AI当前缺乏可靠的机制来保证跨文件的一致修改。或许可以逐文件让AI检查并修改，但每次都需要人为提供上下文，过程繁琐且容易遗漏。再如，重构一个模块的实现，可能要求调整对应的单元测试、文档说明，这些上下游内容AI并不会自动想到去更新 unless 提示。协同一致性的缺失，使得AI进行跨模块变更时常留下不完整修改的问题，需要人工随后进行全面的Code Review才能发现并修正。

执行与调试反馈回路不足： 人类在开发复杂系统时，会频繁运行部分代码、测试验证假设，然后根据结果调整方案。这种试错反馈是工程的一部分。而当前多数AI助手缺乏直接从运行环境获取反馈的能力。一些先进代理（如Manus）尝试通过工具使用来弥补这一点，譬如让AI主动运行单元测试或执行生成的代码检查输出。但大多数代码生成过程，AI并不知道它写的代码最终运行结果如何。

一旦代码运行出错，仍需要人工介入将错误信息反馈给AI，然后模型可能给出修复建议。这种被动的单向流程效率低下，而且AI可能对复杂错误的分析并不准确。实际案例显示，在一个非 trivially 简单的bug上，如果AI的第一次修改未解决问题，它往往难以自主想出新策略，可能反复给出类似的错误改动。这时人必须亲自审查代码找出问题，再引导AI。即使像Devin这样强调自动调试的Agent，也被报道在遇到多层次的复杂任务时调试效率不佳，速度比人肉调试慢很多。这表明AI目前还不善于多步调试推理，缺少持续自省能力，很容易卡在某个误区无法自拔。

失败案例与经验教训： 综合上述，在真实大型项目中使用AI，经常出现一些典型失败案例：
功能不完整： AI生成的模块缺少某些关键功能，因为需求中的细节没被充分考虑。需要再次提示补充遗留部分。
集成错误： AI产出代码与现有系统接口不兼容，如函数签名不匹配、数据格式不符，导致集成测试失败。

隐蔽漏洞： AI看似完成了任务，但引入了安全漏洞或性能隐患，人眼未及时发现就可能埋下雷。如Copilot生成的代码中约35.8%存在安全弱点（涉及命令注入、弱随机数等常见漏洞），如果不经过严格审查，很可能将这些漏洞带入生产环境。

无限循环或停滞： 在少数尝试完全自动编程代理的案例中（类似AutoGPT之类的实验），AI有时会陷入逻辑死循环（例如不断微调某部分代码却始终无法满足条件）或卡住等待，从而无法完成任务。这凸显出自主Agent在没有人类干预时难以保证始终朝正确方向推进。

面对这些问题，工程团队逐渐总结出一些缓解策略：比如前述的任务拆解与迭代提示法、将AI生成的代码纳入正常的Code Review和测试流程、在安全敏感区域禁止直接使用AI生成代码或增加专门的安全测试等等。有些团队针对上下文问题开发了检索增强方案，在AI回答前自动检索代码库相关内容并附加在提示中，以减少遗漏。目前来看，要让AI可靠应对复杂工程，全流程仍需要人类引导和验证。AI的作用更像是一种高级的自动化脚手架，能快速搭建起结构和填充细节，但最后的连接加固工作，尤其在大型结构中，非人力不可。

AI驱动软件工程的瓶颈与展望
综上分析，无论在理解需求、设计架构还是编码测试上，AI都展现了一定能力，但也无可避免地暴露出诸多瓶颈。当前业界和学界对这些瓶颈已有相当共识，主要包括：
上下文与记忆限制： 大模型的有限上下文窗口使其无法掌握大型系统的全貌。缺乏长程记忆机制意味着模型在对话结束后无法保留对项目的认知，无法像人一样积累项目知识。这限制了AI在大型项目和长期维护中的作用。

推理和全局规划能力不足： 现有模型更多是模式匹配而非真正的因果推理，难以自主规划复杂任务的分解和执行顺序。当需要在高层做出架构决策、流程优化时，AI往往给不出有创见的方案。缺少全局观使其难以协调复杂工程活动。

需求语义理解不深： AI对于业务领域的语义和隐含需求理解力不及人类。例如模型可能漏掉需求中的关键约束条件，或者对模糊需求做出错误假设，导致输出与真实期望不符。领域知识和真实常识的缺乏是AI在需求阶段的瓶颈，需要借助知识库或进一步训练来改善。

输出正确性与可靠性： AI生成的代码不保证正确无误，常见问题包括逻辑漏洞、边界条件缺失和安全隐患。模型没有内置的“验证”能力，容易自信地输出错误结果。这在工程上要求人类进行全面测试和审计，限制了AI完全自主交付的可能。

自我调试与纠错能力有限： 人类程序员会根据运行结果不断调整代码，而AI缺少主动获取反馈和纠错的机制。一些先进的Agent尝试通过工具使用来弥补这一点，但总体效率仍然较低。

持续学习与模型更新问题： 软件工程是持续演进的过程，而当前AI模型更新成本高，无法频繁fine-tune来吸收新代码和风格。项目中新引入的约定、风格、最佳实践，AI如果没有见过就很难遵循。模型缺乏在线学习能力，导致适应性不足。

协作与信任障碍： 团队如何将AI融入开发流程仍在摸索。工程师需要新的技能与AI协同，如提示工程、结果评估等。管理者也关心如何评估AI产出的质量、追踪责任归属。一旦AI产出错误导致事故，责任如何划分？这些问题增加了全面信任AI的难度。因此目前AI更多作为辅助而非决策者，瓶颈在于人机协作机制尚不成熟。

安全与合规风险： AI生成代码可能带来安全漏洞、违反编码规范甚至版权问题（如果训练数据包含受保护代码片段）。企业对这些风险十分敏感。在没有完善的安全控制和法律保障前，很难让AI无监督地产生生产代码。这也是AI在企业大规模应用前必须克服的障碍之一。

尽管存在上述瓶颈，AI在软件工程领域的前景依然被看好。业界正从多个方向努力突破：模型方面，研发支持更长上下文、更强推理能力的新一代基础模型（如据传Google Gemini将支持百万级别token上下文）；工具方面，构建复杂的AI编程流水线，将需求->设计->编码->测试各环节的AI工具串联起来，并融入验证机制，形成人机混合开发流程；流程方面，探索“人担纲总设计师，AI负责具体实现”的新范式——工程师更多扮演协调者和审核者，让多个AI助手协同完成任务。

总的来说，AI取代人类完成企业软件工程尚有相当距离，目前的障碍既来自技术本身的限制，也涉及到工程实践和管理流程的调整。但可以预见，随着模型能力提升和开发范式演进，这些障碍将逐步被攻克。真正发挥AI长处、人类引导把关的协作模式，或将成为未来软件工程的新常态，让工程师从繁琐细节中解放出来，专注更具创造性和战略性的工作。在这一过程中，对当前瓶颈的清醒认识将有助于我们更好地定位AI的角色，稳步推进人机共创的工程新时代。