问题——“会写”与“能用”之间仍隔着工程化鸿沟 软件开发场景中——大模型生成代码已较为普遍——但“能生成界面”不等于“能稳定交付”；从实际使用反馈看，部分模型面对简单页面或单文件脚本可快速输出可运行结果，但一旦进入在线商城、支付结算、权限登录、并发库存等真实业务，常出现状态丢失、交互逻辑不一致、移动端适配不完整等问题。更典型的是“修一处、坏一片”：对购物车数字更新、结账按钮显示等问题的修复往往呈现反复回归，表现出对系统整体依赖关系把握不足。 在遗留系统维护上，差距更为直观。面对“偶发性重复扣款”等跨模块问题，有的模型倾向于依据局部报错信息给出补丁式修改，短期看似缓解，但可能引发新的支付失败或边界条件异常。相较之下，工程能力更强的模型通常会先追问关键需求与约束，要求补充完整流程代码与日志，再对调用链、并发控制、事务一致性等进行系统梳理，从根因下手给出可验证的修复方案。 同时，工具使用与自主排障能力正成为新的分水岭。部分先进模型可在获得授权后调用开发环境：浏览目录结构、读取关键文件、查阅技术文档、运行测试并根据结果迭代修复，形成接近工程师工作流的闭环；而能力较弱的模型更多依赖用户“喂信息”，缺少主动定位问题、补齐证据链和反复验证的机制。 原因——训练目标、数据结构与能力评测导向决定“上限” 业内分析认为，造成差异的核心在于训练和评测目标不同。一类模型更强调在标准化题目、算法竞赛、排行榜测评中取得高分，因而在“有标准答案”的代码题上表现亮眼，但在需求不明确、约束多变、需要跨文件理解与多轮验证的工程任务中容易失真。另一类模型更侧重学习真实开发过程中的“工程知识”：代码审查、缺陷单、版本迭代、单元测试、回归测试、持续集成等，以此形成面向交付的系统思维。 差异还体现在对长上下文与复杂依赖的处理能力上。真实项目往往涉及多模块、多语言、多环境配置以及历史遗留逻辑，模型若难以在较长文本范围内保持一致理解，就容易出现“局部合理、整体不通”。此外，能否将自然语言需求转换为可执行的技术拆解，并在修改后通过测试验证，决定了其从“代码生成器”迈向“研发助手”的速度。 影响——软件生产方式加速演进，能力差距将放大效率分层 在数字经济背景下，软件已成为各行业运营底座。大模型编程能力若停留在演示层，将更多用于教育、原型验证和简单自动化；若具备工程化闭环能力，则可能明显提高开发效率、缩短交付周期、降低维护成本，并推动中小企业更快实现数字化改造。 此外，能力差距也可能导致企业应用效果分化：一上，模型输出若缺少测试与审计，可能引入安全隐患、合规风险和质量波动；另一方面，掌握工具链、数据治理与评测体系的团队，将更容易将模型转化为稳定产能，形成新的竞争门槛。对行业而言，如何让“可用、可靠、可控”成为主流，将直接影响大模型核心业务系统中的落地深度。 对策——以工程数据、评测体系和工具生态补齐短板 受访观点认为，提升编程能力不能仅靠“生成更多代码”，关键在于构建面向工程交付的能力体系。 一是夯实高质量工程数据供给。应更多引入真实软件工程过程数据，包括缺陷定位与修复记录、代码审查意见、测试用例与覆盖率信息、版本变更说明等，并在合法合规前提下推进数据脱敏、标注与结构化，形成可持续的训练与迭代基础。 二是完善面向交付的评测标准。建议从“答题式评测”转向“任务式评测”，以真实项目为载体，考核需求澄清、架构设计、跨文件修改、回归测试通过率、鲁棒性与安全性等指标，减少对单点得分的依赖，引导研发资源投向真正影响生产力的能力。 三是强化工具链与工作流集成。推动模型与代码仓库、构建系统、测试平台、缺陷管理系统等安全对接，在权限控制、操作审计、可追溯记录诸上建立规范，使其具备“读—改—测—复盘”的闭环能力，同时避免“黑箱式改动”带来的治理难题。 四是重视安全与合规底线。对支付、医疗、政务等关键系统，需建立更严格的代码审计、依赖扫描、数据隔离与人机协同机制，明确责任边界，确保在提效同时守住安全红线。 前景——从“生成能力竞赛”走向“工程能力竞速” 综合来看，大模型在编程领域的竞争正从“谁写得快、写得像”转向“谁更能交付、谁更可控”。随着企业对稳定性、可维护性、可解释性要求提升，具备工程化能力的模型与平台将获得更广阔应用空间。对国内产业而言，若能在真实工程数据、任务评测体系和工具生态协同上形成合力，有望加速缩小差距，并在行业应用、国产化替代与软件生产方式变革中占据主动。
技术差距的存在既是挑战,也指明了发展方向。缩小与国际先进水平的距离,关键在于从追求表面指标转向注重实际能力,从模仿跟随转向自主创新。只有真正理解工程化思维的本质,将技术研发根植于实际应用场景,国产人工智能才能在全球竞争中站稳脚跟,为数字经济发展提供坚实支撑。这需要企业、科研机构和政策制定者共同努力,更需要时间积累和持续投入。