（来源：科技行者）
这项由中山大学和阿里巴巴集团联合开展的研究发表于2026年3月4日，已提交至顶级会议评审中，研究论文编号为arXiv:2603.03823v1。有兴趣深入了解的读者可以通过该编号在学术数据库中查询完整论文，也可以在Hugging Face平台搜索"skylenage/SWE-CI"或在GitHub上访问"SKYLENAGE-AI/SWE-CI"项目获取相关资源。
想象一下这样的场景：你精心照料一个花园，不仅要让花朵绽放，更要确保花园在四季更迭中依然茁壮生长。传统的园艺评判只看某一时刻的花朵是否美丽，但真正的园艺大师需要让花园在长年累月的变化中保持生机盎然。同样的道理，在软件开发的世界里，一个优秀的AI编程助手不仅要写出能运行的代码，更要写出能够经得起时间考验、在不断修改和扩展中依然保持优雅的代码。
然而，目前几乎所有评测AI编程能力的标准都像是在评判"一瞬间的花朵美"——它们只关注代码在某个特定时刻是否能正确运行，完全忽略了代码在长期维护过程中的表现。这就好比只看照片中的花园是否漂亮，却从不考虑这个花园在一年四季的风雨中是否依然能保持美丽。
正是为了填补这一重要空白，研究团队开发了SWE-CI（软件工程持续集成）评测基准。这是全球首个专门评估AI代理在长期代码维护中表现的评测系统，它不再满足于"一次性正确"，而是要求AI像真正的软件工程师一样，在数月甚至数年的开发过程中持续保持代码质量。
研究团队精心构建了100个评测任务，每个任务都对应着真实世界中一个软件项目的完整进化历程。这些项目平均跨越233天的开发时间，包含71个连续的代码提交记录。更令人印象深刻的是，研究团队还创造性地设计了一套"建筑师-程序员"双重角色的评测协议，模拟真实软件团队中的协作模式，让AI在一个更接近现实的环境中接受考验。
通过对18个来自8家顶级AI公司的模型进行全面测试，研究团队消耗了超过100亿个AI计算单元，获得了令人深思的发现：尽管这些AI模型在短期编程任务上表现出色，但在长期代码维护方面却普遍存在明显不足。这一发现不仅揭示了当前AI编程助手的重要局限性，更为未来的技术发展指明了关键方向。
一、从"一次性编程"到"终身维护"：软件开发的真实挑战
要理解为什么需要SWE-CI这样的评测体系，我们首先需要认识到现实软件开发与传统评测之间的巨大差距。
传统的AI编程评测就像考试中的单选题——给定一个明确的问题，要求AI给出一个正确的答案。比如经典的HumanEval测试会给AI一个函数的描述，要求它完成这个函数的编写。这种测试虽然有用，但就像在平静的游泳池中测试游泳技能一样，无法反映在波涛汹涌的大海中游泳的真实挑战。
真实的软件开发更像是在动态变化的环境中持续建造一座复杂的建筑。你不能简单地搭建一个结构然后就此完成，而是需要在建筑的使用过程中不断进行维护、扩展和改进。新的需求不断涌现，旧的功能需要调整，而且每一次修改都可能影响到整个建筑的稳定性。
研究团队发现了现有评测方法的根本问题：它们都采用"快照式"评估。就像用一张照片来评判一个人的整个人生一样，这种方法只能看到某个特定时刻的表现，完全忽略了时间维度上的变化和挑战。在这种评估方式下，一个匆忙拼凑的解决方案和一个经过深思熟虑的优雅设计可能会得到同样的评分，因为它们在当下都能通过测试。
但是，当需求开始发生变化时，两者之间的差别就会显现出来。那个匆忙拼凑的解决方案会变得越来越难以维护，每次修改都需要更多的时间和精力，而且容易引入新的错误。相比之下，经过深思熟虑的设计会表现出良好的适应性，能够优雅地应对新的需求和变化。
这种差异在软件工程领域被称为"技术债务"。就像财务债务一样，技术债务在初期可能看起来无关紧要，甚至能够带来短期的便利。但是随着时间的推移，利息会不断累积，最终可能拖垮整个项目。据业界统计，软件维护活动占据了整个软件生命周期成本的60%到80%，这个惊人的数字充分说明了长期维护能力的重要性。
莱曼定律（Lehman's Laws）这一软件工程的经典理论进一步揭示了这个问题的本质：随着维护过程的进行，软件质量会不可避免地下降。这意味着，真正优秀的软件开发能力不仅仅是写出能运行的代码，更重要的是写出能够抵御质量衰减、在长期演化中保持健康的代码。
二、SWE-CI的创新突破：从静态测试到动态进化
面对传统评测方法的局限性，研究团队提出了一个根本性的范式转变：从静态的"快照式"评估转向动态的"进化式"评估。
在传统的评测方法中，整个过程就像是在特定时刻拍摄一张照片。AI接收到一个完整的需求描述，然后提供一个一次性的解决方案。无论这个解决方案是经过精心设计的还是匆忙拼凑的，只要它能通过当前的测试用例，就被认为是成功的。
SWE-CI的创新在于引入了时间维度和持续性要求。在这个新的评测框架中，AI不再面对一个静态的问题，而是需要在一个不断演化的环境中持续工作。就像园丁需要根据季节变化调整照料策略一样，AI需要根据不断出现的新需求来调整代码。
研究团队巧妙地将这个过程形式化为数学模型。他们定义了两个关键函数：需求识别函数和代码实现函数。需求识别函数负责分析当前代码状态与目标状态之间的差距，并生成相应的需求文档。代码实现函数则根据这些需求对代码进行修改。
这种设计的巧妙之处在于，它创造了一个反馈循环。每一次代码修改都会影响下一轮的需求识别，而之前修改的质量会在后续的迭代中得到体现。如果AI在早期阶段做出了草率的设计决策，这些决策的负面影响会在后续的开发过程中逐渐放大，使得后续的修改变得越来越困难。
为了更准确地衡量代码在这种动态环境中的表现，研究团队还开发了一套新的评分机制。传统的评测通常只关注"通过"或"未通过"这样的二元结果，但SWE-CI引入了"归一化变化"这一更细致的度量标准。
这个度量标准的设计非常贴心。当AI改进了代码功能时，改进程度会按照从基线到目标的总体差距进行归一化，确保无论任务大小如何，满分都是1分。但当AI破坏了原有功能时，退步程度会按照原有基线进行归一化，这样无论任务规模如何，最坏情况下的得分都是-1分。这种非对称的设计确保了改进和退步都能在统一的尺度上得到公平的评估。
更进一步，研究团队还提出了EvoScore（进化评分）这一核心指标。这个指标不是简单地计算所有迭代的平均得分，而是对后期迭代给予更高的权重。其背后的逻辑简单而深刻：真正可维护的代码应该在长期演化中表现得越来越好，而不是越来越差。
通过调节权重参数，EvoScore能够灵敏地区分不同类型的开发策略。那些为了短期效果而牺牲长期可维护性的方法会得到较低的评分，而那些在初期可能进展较慢但能够为后续开发奠定坚实基础的方法会得到更高的认可。
三、精心构建真实世界的代码进化历程
SWE-CI最令人印象深刻的特点之一就是它完全基于真实世界的软件开发历程。研究团队并没有人为构造简化的测试场景，而是花费大量精力从实际的开源项目中提取完整的进化轨迹。
整个数据构建过程就像是考古学家在寻找和保存珍贵的历史文物。研究团队首先在GitHub这个全球最大的代码托管平台上进行了广泛的搜索。他们设定了严格的筛选标准：项目必须至少维护了三年，获得了超过500个星标，包含完整的配置和测试文件，并且采用宽松的开源许可证。经过这轮筛选，从海量的项目中保留下了4923个高质量的候选项目。
接下来的步骤更加精细。研究团队分析了每个项目的完整提交历史，寻找那些依赖关系保持稳定的连续开发阶段。这样做的原因很实用：如果一个项目在开发过程中频繁更换核心依赖库，那么代码的变化可能主要是为了适应外部变化，而不是反映内在的功能演进。只有在依赖关系稳定的情况下，代码的变化才能真正体现开发者的设计决策和维护能力。
为了确保任务的充实性，研究团队还设定了代码变化的最低阈值：每个候选任务必须涉及至少1000行代码的修改。这个标准确保了每个任务都代表着足够复杂的演化过程，而不是简单的小修小补。
最具挑战性的部分是环境重建。为了让现代的AI能够在历史代码环境中正常工作，研究团队需要为每个任务重新构建当时的运行环境。这个过程就像是文物修复师在重建古代工艺品的制作环境。他们根据每个项目在特定时期的配置文件自动生成Docker容器，并实现了一套智能修复机制：当某个环境因为依赖缺失而无法启动时，系统会自动检测问题并尝试补充缺失的组件。
为了进一步保证质量，研究团队还进行了多轮精细筛选。他们在重建的环境中运行项目的测试套件，确保基础代码和目标代码都能正常工作。同时，他们还验证了基础版本和目标版本之间确实存在足够的测试差异——至少5个测试用例的差别，以确保任务具有实质性的挑战。
最终，100个精心挑选的任务组成了SWE-CI基准测试集。这些任务来自68个不同的开源项目，平均跨越233天的真实开发时间，包含71个连续的提交记录。每个任务都配备了完整的源代码和预构建的运行环境，确保了实验的可重复性。
这样的数据构建过程确保了SWE-CI不是在测试AI处理人造问题的能力，而是在评估它们应对真实世界复杂性的能力。这些任务中包含的每一个代码变化、每一个设计决策都曾经是真实开发者在面对实际需求时做出的选择，因此具有无可替代的真实性和代表性。
四、双重角色协作：模拟真实团队的智慧分工
为了更真实地模拟专业软件开发团队的工作模式，研究团队设计了一个精巧的"建筑师-程序员"双角色协作机制。这种设计的灵感来自真实软件团队中常见的分工模式：架构师负责分析需求和制定技术方案，程序员负责具体的代码实现。
建筑师角色承担着战略层面的责任。当面对测试失败时，建筑师需要像侦探一样进行层层分析。首先，它要仔细研究所有失败的测试用例，从中找出共同的模式和根本原因。这个过程就像医生诊断病情一样，需要从表面症状深入到根本病因。
接着，建筑师需要深入检查相关的源代码，将抽象的测试失败与具体的代码缺陷关联起来。这一步骤特别重要，因为同样的测试失败可能源于完全不同的代码问题，而有效的解决方案必须针对真正的根源。
在完成分析后，建筑师的任务是设计改进方案。但这里有一个重要的约束：建筑师必须采用增量式的思维，每次只提出最多5个最紧迫的改进需求，避免一次性提出过于宏大的重构计划。这种约束模拟了真实敏捷开发中的"小步快跑"理念，确保每次迭代都是可管理的。
建筑师生成的需求文档必须遵循两个重要原则。首先是"增量性"：文档应该专注于当前最迫切的需求，避免过度设计的陷阱。其次是"高层次性"：需求应该用自然语言描述期望的行为，而不是给出具体的实现细节，为程序员留出创造性发挥的空间。
程序员角色则专注于将高层次的需求转化为具体的代码实现。程序员的工作流程同样被标准化为三个步骤：首先是理解需求，将自然语言描述的期望转化为明确的技术规格；然后是制定实现计划，考虑如何在现有代码基础上进行修改；最后是具体的代码编写和修改。
这种双角色设计的巧妙之处在于它真实地反映了软件开发中的认知负荷分配。在真实的团队中，架构师和程序员往往具有不同的思维模式和关注重点。架构师更多地从系统整体角度思考问题，而程序员更多地关注具体实现的技术细节。通过让AI分别扮演这两个角色，SWE-CI能够更准确地评估AI在不同层面上的能力。
更重要的是，这种设计避免了"上帝视角"的问题。在传统的评测中，AI往往能够同时看到问题的全貌和最终的解决方案，这与真实开发中的渐进式认知过程截然不同。在SWE-CI中，程序员只能根据建筑师提供的需求文档进行工作，而建筑师只能基于当前的测试结果进行分析，这种信息限制使得评测更加贴近现实。
双角色协作还引入了一个重要的反馈机制。建筑师的需求质量会直接影响程序员的实现效果，而程序员的实现质量又会影响下一轮的测试结果，进而影响建筑师的后续分析。这种相互依赖的关系准确地模拟了真实团队合作中的复杂动态。
五、革命性的评估指标：捕捉长期维护的真实挑战
SWE-CI的评估体系最具创新性的地方在于它不再简单地关注"对错"，而是深入分析代码在时间维度上的表现变化。这种评估理念的转变就像是从关注单次考试成绩转向关注学习能力的长期发展。
传统评测的局限性在于它假设每个问题都有一个明确的"正确答案"。但在真实的软件维护中，很多时候并不存在唯一的标准答案，而是存在多种可能的解决路径，这些路径在短期内可能表现相似，但长期效果却大相径庭。
SWE-CI引入的"归一化变化"指标巧妙地解决了这个问题。这个指标的设计哲学是：不仅要看AI能否解决问题，更要看它解决问题的方式是否可持续。当AI改善了代码功能时，改善的程度会按照总体目标进行归一化，这样无论任务规模大小，完全达成目标都对应1分的满分。但当AI破坏了原有功能时，破坏程度会按照原有基线进行归一化，确保最糟糕的情况（完全破坏所有原有功能）对应-1分。
这种非对称的评分设计反映了软件维护的一个重要现实：破坏现有功能的代价往往比增加新功能的收益更大。在真实的开发环境中，引入回归错误（即破坏原本正常工作的功能）是极其严重的问题，因为它会直接影响用户体验，并可能引发连锁反应。
EvoScore（进化评分）的设计更是独具匠心。这个指标通过给后期迭代分配更高的权重，有效地区分了两种截然不同的开发策略。一种是"短期收益"策略，通过快速但可能不够稳固的修改来尽快通过测试；另一种是"长期投资"策略，可能在初期进展较慢，但会为后续开发建立坚实的基础。
权重参数γ的作用非常关键。当γ等于1时，EvoScore就是简单的平均分，对所有迭代一视同仁。但随着γ的增加，后期迭代的重要性急剧上升。这种设计模拟了真实软件项目中的一个重要现象：技术债务的复合效应。早期的草率决策在初期可能影响不大，但随着项目的发展，其负面影响会越来越明显。
研究团队通过大量实验发现了一个有趣的现象：不同AI模型在面对不同γ值时表现出了明显的偏好差异。一些模型在低γ值时表现较好，说明它们擅长快速解决当前问题，但可能缺乏长期规划能力。而另一些模型在高γ值时表现更佳，表明它们能够做出更有利于长期发展的设计决策。
这种差异性揭示了AI模型训练策略的深层影响。那些主要基于短期编程任务训练的模型往往倾向于快速解决问题，而那些更多接触到长期项目维护案例的模型则表现出更好的前瞻性思考能力。
六、令人深思的实验发现：AI的维护能力现状
研究团队对18个来自8家主要AI公司的先进模型进行了全面评测，总计消耗了超过100亿个计算token，获得了一系列令人深思的发现。
最引人注目的发现是AI模型的发展轨迹呈现出明显的加速趋势。在同一家公司的产品线中，较新的模型几乎总是比较早的版本表现更好，而且2026年后发布的模型相比其前代产品显示出了更大幅度的改进。这种趋势表明，AI公司正在越来越重视代码维护能力的提升，而不仅仅是单次编程任务的准确性。
在所有测试的模型中，Claude Opus系列表现最为突出，在整个观察期间都保持着领先地位。GLM-5也表现出了令人印象深刻的性能。这些领先模型的成功可能源于它们在训练过程中更多地接触了长期项目维护的案例，或者采用了更有利于培养前瞻性思维的训练策略。
更有意思的是，研究团队发现不同AI公司在开发策略上存在明显差异。通过调节EvoScore中的权重参数γ，研究者能够观察到模型偏好的变化。MiniMax、DeepSeek和GPT系列模型表现出了对长期收益的明显偏好，在γ值较高时表现更好。这表明这些模型在面对编程任务时更倾向于采用有利于长期维护的策略。
相比之下，Kimi和GLM系列模型则倾向于短期收益，在γ值较低时表现更佳。这可能反映了不同的训练哲学：一些公司可能更注重快速解决问题的能力，而另一些公司则更重视代码的长期可维护性。
Qwen、Doubao和Claude系列模型在不同γ值下表现相对稳定，这种稳定性本身就是一种优势，表明这些模型在短期效率和长期可维护性之间找到了较好的平衡。
然而，最令人担忧的发现是所有模型在控制回归错误方面都表现不佳。研究团队测量了"零回归率"——即在整个维护过程中完全没有破坏原有功能的任务比例。结果显示，大多数模型的零回归率都低于25%，只有Claude Opus系列的两个模型超过了50%。
这个发现特别重要，因为在真实的软件开发中，回归错误是极其严重的问题。每当一个原本正常工作的功能因为新的修改而失效时，不仅会直接影响用户体验，还可能引发级联效应，导致其他相关功能的不稳定。在专业的软件开发团队中，严格控制回归错误是质量保证的基本要求。
这些发现揭示了当前AI技术的一个重要局限性：尽管在单次编程任务上已经达到了令人印象深刻的水平，但在需要全局考虑和长期规划的复杂维护场景中，AI仍然面临着重大挑战。这种局限性可能源于训练数据的特点——大多数公开可用的编程数据都是独立的代码片段或简单的问题-答案对，缺乏真实项目中长期演化的完整上下文。
七、技术实现的精巧设计
SWE-CI在技术实现层面展现了研究团队的深厚功底和细致考虑。整个系统的设计既要保证评测的公平性和准确性，又要确保实验的可重复性和扩展性。
评测环境的搭建采用了容器化技术，每个任务都运行在独立的Docker环境中。这种设计的好处是多方面的：首先，它确保了不同任务之间的完全隔离，避免了相互干扰；其次，它能够精确地重现特定时期的软件环境，包括操作系统版本、编程语言版本以及各种依赖库的具体版本；最后，它使得整个评测过程可以在任何支持Docker的机器上重现，大大提高了实验的可重复性。
测试执行采用了pytest框架配合pytest-json-report插件，这种组合能够生成详细的结构化测试报告。每次测试运行都设置了3600秒的超时限制，这个时长足以应对大多数复杂的测试场景，同时避免了因为死循环等问题导致的无限等待。
双角色协作的实现使用了iFlow CLI框架，这是一个专门为复杂AI智能体交互设计的工具。整个协作过程被严格限制在最多20轮迭代内，这个限制既确保了评测的可控性，又避免了无谓的长时间运行。
系统的提示词设计展现了研究团队对软件工程实践的深刻理解。建筑师角色的提示词要求AI严格按照五个步骤进行工作：总结测试失败的原因、追踪相关的测试文件、分析源代码中的根本问题、筛选最关键的修改需求、生成规范的需求文档。每个步骤都有详细的指导原则，确保分析过程的系统性和全面性。
程序员角色的提示词则强调了实现的规范性和约束性。AI被明确禁止主动执行测试命令，只能专注于代码修改工作。这种约束确保了评测过程的标准化，避免了因为不同AI模型采用不同验证策略而产生的不公平比较。
为了确保评测结果的可靠性，研究团队还实现了多层次的质量控制机制。每个任务在正式评测前都要经过环境验证，确保基础环境能够正常运行。测试执行过程中的所有输出都会被详细记录，便于后续的分析和调试。
特别值得一提的是，整个评测过程完全自动化，从任务分配到结果收集都无需人工干预。这种设计不仅提高了评测效率，更重要的是确保了评测过程的客观性和一致性，避免了人为因素对结果的影响。
八、深远影响与未来展望
SWE-CI的提出不仅仅是一个新的评测基准，更代表了对AI编程能力评估理念的根本性变革。这种变革的影响将是深远而多层次的。
从技术发展角度来看，SWE-CI为AI研究者指明了一个重要的发展方向。长期以来，AI编程领域的进展主要通过提高在短期任务上的准确率来衡量，这导致了研究重点的偏向。SWE-CI的出现提醒我们，真正有价值的AI编程助手不仅要能解决当前问题，更要能够写出经得起时间考验的代码。
这种评估理念的转变可能会推动训练方法的创新。传统的训练数据主要由独立的代码片段组成，但要培养长期维护能力，AI模型需要接触到更多完整项目的演化历程。这可能会促使研究者开发新的数据收集和标注方法，以及新的训练策略。
从软件工程实践角度来看，SWE-CI为代码质量评估提供了新的视角。传统的代码审查主要关注当前代码的正确性和可读性，但很难评估代码的长期可维护性。SWE-CI的评估框架可能为开发团队提供一种新的工具，帮助他们更好地评估和改进代码质量。
在教育领域，SWE-CI也可能产生重要影响。计算机科学教育长期以来重视算法正确性和编程技巧，但对软件维护和长期设计的重视不够。SWE-CI的理念可能会推动教育内容和方法的调整，帮助学生从一开始就建立正确的软件工程思维。
从产业应用角度来看，SWE-CI的发现对AI编程工具的发展具有重要指导意义。目前的AI编程助手主要专注于快速生成代码，但SWE-CI的结果表明，未来的工具需要更多地考虑代码的长期影响。这可能会推动新一代编程助手的开发，这些工具不仅能够解决当前问题，还能够预测和优化代码的长期演化路径。
研究团队也明确指出了当前工作的局限性和未来的改进方向。虽然SWE-CI已经包含了100个精心构建的任务，但这个规模相对于软件开发的复杂性来说仍然有限。未来需要扩展任务的数量和多样性，涵盖更多编程语言、更多应用领域以及更多开发模式。
另一个重要的发展方向是评估指标的进一步完善。虽然EvoScore已经能够有效区分不同的维护策略，但软件质量的评估是一个多维度的问题。未来可能需要开发更多维度的指标，如代码可读性的变化、性能的演化、安全性的保持等。
此外，双角色协作机制虽然很好地模拟了真实团队的工作模式，但真实的软件开发往往涉及更多角色和更复杂的协作关系。未来的发展可能需要引入更多角色，如产品经理、测试工程师、系统架构师等，构建更完整的开发生态系统模拟。
九、对AI发展的深层启示
SWE-CI的研究成果为我们理解AI能力的本质提供了新的视角。它揭示了一个重要现象：AI在解决孤立问题和处理复杂系统性挑战之间存在着显著差距。
这种差距的根源可能在于当前AI训练方法的固有局限性。大多数AI模型是通过学习大量独立的输入-输出对来训练的，这种方法虽然在单次任务上能够达到很高的准确率，但在需要全局思考和长期规划的复杂场景中就显得力不从心。
真正的软件维护能力需要多种认知技能的协调配合：理解当前系统的结构和约束、预测修改对系统的潜在影响、在多个可能的解决方案之间进行权衡、保持代码的一致性和可扩展性。这些技能的培养需要大量的实践经验和深层次的理解，而不仅仅是模式识别和模仿。
SWE-CI的发现也揭示了AI评估方法的重要性。评估方法不仅是衡量AI能力的工具，更是引导AI发展方向的指挥棒。当我们只关注短期任务的准确性时，AI模型自然会朝着快速解决问题的方向发展。但当我们开始重视长期可维护性时，AI模型就需要发展出更加复杂和全面的能力。
这种认识对整个AI领域都有着重要意义。在自然语言处理、计算机视觉、机器人控制等各个领域，我们可能都需要重新思考评估标准，从关注单次表现转向关注系统性能力和长期稳定性。
从更宏观的角度来看，SWE-CI的研究还触及了一个深层次的哲学问题：智能的本质是什么？真正的智能不仅体现在解决特定问题的能力上，更体现在适应变化、学习成长和保持稳定的能力上。这种观点可能会影响我们对AI发展目标和路径的整体思考。
说到底，SWE-CI为我们提供了一个重要的提醒：在追求AI技术突破的过程中，我们不应该只关注令人眼花缭乱的短期成果，而应该更多地思考如何构建真正稳健、可靠、可持续发展的智能系统。只有这样，AI才能真正成为人类在复杂世界中的可靠伙伴。
就像一个园丁的价值不在于能否让花朵在某一天绽放得特别美丽，而在于能否让整个花园在四季轮回中始终保持生机勃勃一样，真正优秀的AI系统也应该在长期的任务演化中展现出持续的智慧和适应能力。SWE-CI的贡献在于为我们提供了衡量这种长期智慧的标准和方法，这无疑将推动AI技术向着更加成熟和实用的方向发展。
这项研究的发布标志着AI编程能力评估进入了一个新的时代。未来的AI编程助手将不再满足于简单的"能用就行"，而是要追求"用得久、用得好、用得稳"的更高标准。对于整个软件行业来说，这种变化的意义怎么强调都不为过，因为它最终将让我们拥有更可靠、更可维护、更有价值的软件系统。
Q&A
Q1：SWE-CI评测基准与传统编程评测有什么根本区别？
A：传统评测像考试单选题，只看AI能否一次性写出正确代码。而SWE-CI模拟真实软件开发，要求AI在数月的持续迭代中维护代码质量，就像要求园丁不仅让花朵绽放，还要在四季变化中保持花园生机。它关注的是代码的长期可维护性，而非短期功能正确性。
Q2：EvoScore进化评分如何区分不同的AI维护策略？
A：EvoScore给后期迭代更高权重，能有效区分"短期收益"和"长期投资"两种策略。那些为了快速通过测试而草率修改代码的AI会随着时间推移得分越来越低，而那些前期进展较慢但为后续发展奠定坚实基础的AI会获得更高评分。
Q3：为什么大多数先进AI模型的零回归率都很低？
A：实验显示大多数模型零回归率低于25%，说明AI在修改代码时经常会破坏原有功能。这反映了当前AI训练主要基于独立代码片段，缺乏完整项目演化的上下文经验，难以进行全局思考和预测修改的长期影响，这是AI技术的重要局限性。
