北京
移动开发团队曾经花大量时间争论架构模式。Android阵营讨论MVC、MVP、MVVM、MVI、Clean Architecture、模块化、依赖注入、仓库模式、用例和特性模块。iOS这边也不闲着，MVC、MVVM、VIPER、The Composable Architecture、协调器、服务层、依赖容器、状态管理——每个名词背后都是一场技术选型战争。
这些争论有其合理性。架构让应用更易理解、测试、扩展和维护。它给开发者提供共同语言，帮助新人快速定位代码位置，降低每个功能都用不同风格实现的风险。
但AI编程代理正在改变这一切。
当AI能生成大部分实现代码、重构、写测试、连接功能的多个部分时，一个严肃的问题浮现：我们是否还需要同样强调架构？还是说，我们需要一种完全不同的架构？
一种观点认为架构变得更重要了。
AI代理虽强，但需要清晰边界。没有结构约束，代理可能写出本地运行正常、却长期削弱系统的代码。它可能重复逻辑、绕过现有模式、创建不必要的抽象，或引入与项目其余部分不匹配的新风格。
从这个角度看，架构成为代理的指南。它告诉系统决策如何做出、逻辑归属何处、数据如何流动、错误如何处理、哪些变更是可接受的。清晰的架构不再只服务于人类，它成为AI工作环境的一部分。
但反方论点同样有力。
移动团队有时过度使用架构。我们都见过简单功能因每件小事都要穿过太多层级而变得臃肿。有时架构保护产品，有时它只保护技术纯洁性的执念。
AI可能让情况更糟。由于代理能快速生成样板代码，团队可能接受更多层级，因为"写它们的成本感觉很低"。但理解、审查、调试和演进这些代码的成本依然真实。生成的复杂性仍是复杂性。
在代理成为主要编码者的时代，我们需要相应调整架构思维。
代码生成速度呈指数级增长，系统改进或衰败的速度也是如此。
我们需要新的架构方法，核心软件工程原则仍需尊重：DRY（不要重复自己）、KISS（保持简单）、SOLID、清晰边界、可测试性、可维护性。但实现方式也需要易于理解、易于审查，并让人类和代理都能安全扩展。
也许移动架构的下一步进化不是增加更多层级，而是创建足够简单的系统，让代理能够有效工作。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
