近日，一位开发者在Linux.do论坛发帖，分享了在不同类型项目中使用AI编程工具截然相反的体验。该开发者目前同时负责新项目开发与老项目维护。在新项目中，由于是一次性交付、没有历史包袱，AI工具表现出色，开发者大量消耗token调用AI进行开发，过程高效顺畅。然而在老项目维护中情况完全相反：该项目由开发者本人从零手写完成，此前仅在小范围内使用AI工具并保持在自己可控范围内。当开发者尝试让AI模型（帖子中提及gpt-6.1-sol）全盘接管老项目开发时，发现AI的逻辑与原有需求产生大量冲突，AI引入了许多不必要的保护措施和冗余修改。开发者试图强行矫正AI的行为，反而让自己身心疲惫，因此发帖向社区征求应对思路。该话题已获得社区成员参与讨论。这一现象折射出当前AI编程工具的典型局限：在无历史包袱的新项目中，AI优势明显、产出质量高；而在承载既有架构设计与隐性业务逻辑的遗留代码库中，AI难以准确理解原始设计意图，容易生成与预期不符的改动，导致维护成本不降反升。如何在存量项目中有效引入AI，正成为开发者群体面临的普遍课题。
事件分析
这一讨论触及AI编程的核心瓶颈之一：上下文与意图理解的缺失。遗留代码库中蕴含大量隐性设计决策——为何如此分层、为何保留看似冗余的逻辑，这些信息往往只存在于开发者脑中而非代码注释里。大模型仅凭静态代码难以还原完整语境，因而倾向于套用通用最佳实践，生成过度防御性代码和冗余重构。从产业角度看，这解释了为何AI编程工具的市场叙事多聚焦于从零构建场景，而对存量软件维护这一占据行业主要工时的领域渗透缓慢。可能的改进方向包括：将架构决策文档化后注入模型上下文、采用增量式小步重构而非全盘托管、利用代码库语义索引增强检索精度等。短期内，AI负责绿地项目、人类工程师把控存量系统的分工格局仍将持续。
核心观点：AI能读懂代码语法，却读不懂代码背后的历史与意图，遗留系统的维护仍是人类工程师难以替代的护城河。
原文链接：Linux.do
