一、问题：单点能力亮眼，长期工程能力仍显不足 近年来，智能编程工具代码补全、函数生成、单项需求实现各上进展迅速，一些公开测评的通过率也较高，由此引发“编程将被全面替代”的讨论；但软件开发的核心并不是一次性交付的代码片段，而是持续多年的系统演进：功能不断扩展、依赖持续叠加、接口频繁调整、历史兼容长期存。能否在连续迭代中保持稳定、避免引入隐患，才是工程能力的关键。 近期，研究团队推出EvoClaw基准测试，尝试把“时间维度”纳入评估。该基准从开源项目的历史演进中提取真实开发轨迹，并重构为多个“里程碑”任务链：后续任务必须在继承前序成果的基础上继续开发，同时处理接口兼容、依赖冲突、隐性约束等工程问题。测试覆盖多种主流编程语言和不同复杂度项目，部分项目跨度可达数百天。结果显示，多款主流模型在长链条任务中表现明显下滑，最高综合得分约38.03分；从“全链路完整解决”的比例看，最高也仅约13.37%。任务越靠后、依赖越长，完成效果越不稳定。 二、原因：软件开发是“连续依赖系统”，不是独立题目集合 研究人员指出，传统评测常以单个提交、单个缺陷或单个功能为单位，容易高估工具在真实工程中的表现。真实开发具有典型的“连续依赖”特征：今天的改动要兼容既有数据库结构，明天的优化不能破坏已上线功能；看似局部的修改，可能引发跨模块连锁反应。对智能编程工具而言，短板主要体现在以下上： 其一，“历史上下文”难以稳定继承。长周期工程中充满需求决策、架构约束、隐含假设和遗留约定，仅凭当前片段信息往往不足以做出正确选择。 其二，“回归控制”能力不足。工具新增功能时通常能较快给出实现，但更难保证不破坏既有行为；随着迭代推进、系统复杂度上升，回归风险不断累积。 其三，“技术债”容易滚动放大。为在单次任务中尽快“跑通”，工具可能倾向于选择权宜实现，短期可用但长期增加耦合与维护成本，后续迭代的改动空间被压缩，整体质量随之下滑。 其四，工程约束远不止代码。版本管理规范、接口契约、异常处理、性能边界、可观测性、安全合规等要求，往往不会在单次任务描述中完整呈现，却决定系统能否长期稳定运行。 三、影响：理性看待“替代叙事”，研发管理需前移风险控制 业内人士认为，这类“长周期、强依赖”测试提醒行业：智能编程工具更适合在边界清晰的环节提升效率，而难以直接承担系统长期演进的全部责任。对企业研发管理来说，如果只用单次交付速度衡量工具价值，可能忽视回归缺陷、架构退化和维护成本上升带来的长期损失。对产业生态而言，评测体系缺少时间维度，容易造成能力认知偏差，进而影响工具选型、人才结构与研发流程设计。 四、对策：从“写得快”转向“管得住”，以工程机制弥补短板 针对暴露的问题，专家建议在应用侧与评测侧同步完善： 在应用侧，应将智能编程工具纳入既有工程治理体系：一是强化自动化测试与回归测试覆盖，以可验证的质量门禁约束产出；二是推行更严格的代码审查与架构评审，由经验工程师把关关键模块；三是完善文档与接口契约管理，减少隐性约束带来的偏差；四是对工具生成代码建立可追溯机制，明确责任边界与维护策略，避免“无人认领代码”累积为风险。 在评测侧，应持续推动更贴近真实场景的基准建设：通过里程碑任务链、真实依赖图、可执行构建与测试流水线，系统检验工具在连续迭代中的稳定性、兼容性与回归控制能力，为产业提供更可比、更可信的参考。 五、前景：智能化将深度嵌入研发，但“系统工程能力”仍是关键门槛 从趋势看，智能编程工具在标准化开发、样板代码生成、接口适配、测试用例补全等上仍有提升空间，并将持续改变研发分工与效率结构。但研究也表明，软件工程的关键并不会因工具进步而消失：架构治理、技术债管理、质量保障与长期维护，仍需要系统化方法、组织流程与工程经验共同支撑。未来竞争焦点或将从“单次生成能力”转向“长期可靠交付能力”——谁能在持续迭代中把风险降下来，谁就更接近真正可用的工程化水平。
这项研究提示我们，在拥抱人工智能带来的效率提升时，也要清楚看到其在长期工程上的局限。软件开发本就是持续迭代的过程，人工智能的成熟同样需要从单点突破走向系统能力。如何跨过这道门槛，是对研究者和产业实践的共同考验，也将影响下一阶段技术演进的方向。