我用AI设计了新项目的架构，从此告别加班重构

StarkCoder
2 阅读7分钟

一个iOS老兵的AI协同开发实战记录

一、背景：老项目重构，我为什么要请AI当“架构师”

去年接手一个AIGC展示类的iOS项目，目标平台iOS 15+，核心能力是WebP动图展示和视频播放。老项目是用UIKit写的，代码耦合严重，一个VC动辄上千行，每次改需求都像拆炸弹。领导说：“重构吧，用SwiftUI，要可维护、要稳定。”

我头大了：SwiftUI我还在学习阶段，架构怎么搭？技术选型怎么定？WebP动图在SwiftUI里会不会卡？视频播放怎么封装？……这些问题足够让我加两个月班。

这时候，我想到了AI。既然它能写代码、能解释概念，那能不能当我的“架构师”？我决定试试：让AI先出一版架构方案，我来审阅、提问、调整，然后按这个方案分步实施。结果出乎意料地顺利——项目重构提前完成，代码质量远超预期，我还顺便把SwiftUI和现代iOS架构学了个透。

今天就把这段“人机协同”的经历分享出来，希望能给同样在重构或新技术转型中的你一点启发。

二、第一步：说清需求，让AI出方案

我向AI描述了项目基本情况：

  • 目标平台：iOS 15+
  • 项目类型：AIGC内容展示（图片、视频为主）
  • 核心能力：WebP动图展示、视频播放
  • 设计原则：可维护性、稳定性优先
  • 技术栈倾向：SwiftUI，希望用最新Swift并发特性

AI很快给出了一份完整的技术架构方案。它推荐了MVVM + Clean Architecture简化版的分层模式，数据流清晰，依赖方向明确。具体分层是这样的：

  • 表现层：SwiftUI Views + ViewModel（MVVM）
  • 业务层：UseCase / Interactor（用例封装，不直接依赖UI）
  • 领域层：Domain Models、Repository 协议（与具体实现解耦）
  • 数据层：Repository 实现、Network、Cache、Local DB

AI解释说，这样分层的好处是：UI只依赖ViewModel，ViewModel依赖UseCase/Repository协议，具体实现（网络、缓存、数据库）在基础设施层注入，便于单测和替换。数据流也清晰：用户操作 → View触发 → ViewModel调用UseCase/Repository → Repository决策（缓存/网络/持久化） → 结果回写ViewModel → View自动刷新。

我仔细看了它的选型理由，发现AI考虑得很周全：

类别AI推荐理由
UI框架SwiftUI官方主推，声明式，iOS 15+ API稳定
网络层Alamofire 或 URLSession+async/await成熟/轻量二选一
图片/WebPSDWebImage + SDWebImageWebPCoderWebP动图支持成熟，缓存完善
视频播放AVPlayer封装 + SwiftUI UIViewRepresentable系统级，可控，避免第三方臃肿
依赖注入Protocol + Environment简单够用，不引入额外库
包管理SPM官方，Xcode原生支持

AI还贴心地给出了“不推荐”的选项：RxSwift、过重的Clean Architecture、未经验证的WebP库——这些坑我以前都踩过，AI居然提前避开了，有点东西。

三、细节追问：AI帮我补全“经验盲区”

方案有了，但具体到SwiftUI实现，我还有一些细节不确定。比如：

  • “在SwiftUI里如何实现类似UIKit的预加载？”
  • “WebP动图如果一屏同时出现十几个，怎么避免卡顿？”
  • “列表中的视频小窗，怎么做到离屏释放？”

这些问题AI都给出了具体建议：

  • 预加载可以用PreferenceKey或结合onAppear + 阈值判断，或者直接混用UIKit的UICollectionView在UIViewRepresentable里做精细控制。
  • 动图过多时，控制同时解码数量（只解码可见区域的图），并建议在极端场景下回退到UIKit构建高性能列表，SwiftUI负责外层框架。
  • 视频播放器用单例管理或统一封装，在onDisappear时暂停并释放资源。

这些建议既有理论，又接地气，有的甚至给出了代码片段。我边读边思考，还反向问它：“如果用UIKit构建那个高性能列表，SwiftUI和UIKit怎么优雅通信？”AI又给出了UIHostingController嵌入SwiftUI、通过协调器双向通信的方案。

这种“你问我答”的过程，让我对SwiftUI的边界能力和混编技巧快速上手，比自己翻文档高效得多。

四、动手实施：AI写代码，我来当“质检员”

架构定好，开始写代码。我采用“子任务拆解 + AI生成 + 人工检阅”的模式：

  1. 先让AI生成一个模块的骨架，比如AIGCRepositoryProtocol、AIGCRepository实现。
  2. 我 review 代码，看是否符合架构原则、命名是否清晰、有没有内存泄漏风险。
  3. 遇到不懂的代码，直接问AI：“为什么要用[weak self]？这里用Task和Task.detached有什么区别？”AI会耐心解释，甚至给出反例对比。
  4. 验证通过后，把代码合入项目，跑通流程。

举个例子，AI生成的LoadAIGCFeedUseCase是这样的：

struct LoadAIGCFeedUseCase {
    private let repository: AIGCRepositoryProtocol
    
    init(repository: AIGCRepositoryProtocol) {
        self.repository = repository
    }
    
    func execute(page: Int) async throws -> [AIGCItem] {
        // 先从缓存读取，缓存没有则请求网络
        return try await repository.fetchFeed(page: page)
    }
}

简洁清晰，依赖倒置，可测试性拉满。我把它和原来的老代码对比：一个300行的VC，里面网络、缓存、UI更新全混在一起——AI生成的代码简直像艺术品。

更妙的是，当我把老项目的一段业务逻辑扔给AI，说“用新架构重构这段代码”，它能把旧代码拆成Repository、UseCase、ViewModel，还自动生成Protocol和单元测试模板。虽然需要微调，但至少省了80%的机械工作。

五、反思：AI让我更轻松，也让我学得更快

有人可能担心：AI生成的代码靠谱吗？会不会引入隐藏bug？

我的经验是：AI是超级副驾驶，不是自动驾驶。它提供的是“初稿”和“思路”，最终决策权还在我手里。但正是这种“AI写我改”的模式，让我能快速尝试多种方案，对比优劣，从而理解为什么某些设计更好。

比如AI一开始推荐用@Published做状态绑定，我问它和@State的区别，它解释了属性包装器的设计意图和使用场景，还提醒我注意ObservableObject的线程问题。这种即时学习比看一周文档都管用。

更重要的是，AI帮我建立了架构思维。以前我也知道分层、依赖注入，但自己搭总怕过度设计。现在AI给出一个基线方案，我在此基础上根据项目规模裁剪，既不缺斤短两，也不过度复杂。

六、成果与展望

项目重构完成后，几个指标明显改善：

  • 编译时间：模块化后，增量编译快了30%
  • 崩溃率：统一错误处理和崩溃收集，线上崩溃降低80%
  • 开发效率：新功能开发，按Feature划分，同事接手不需要看完整项目，只看对应模块即可
  • 可测试性：关键模块单测覆盖率70%以上，以前根本没法测

现在团队内部也推广了这套“人机协同”模式：先用AI生成方案，再集体评审，然后AI辅助实现。大家开玩笑说，AI是我们的“免费架构师”和“代码实习生”。

未来，我还计划让AI参与更多环节，比如根据设计稿生成SwiftUI代码、自动生成文档、甚至做性能瓶颈分析。相信随着AI能力的提升，我们开发者能从繁琐的重复劳动中解放出来，更多专注于创意和架构——这才是技术的乐趣所在。

七、总结：如果你也想试试

如果你正准备重构老项目，或者转向新技术栈（比如SwiftUI），不妨请AI当你的“架构顾问”。三步走：

  1. 说清需求：目标、约束、原则，越详细越好
  2. 审阅方案：AI出的方案未必全对，结合经验提问、调整
  3. 分步实现：让AI生成模块代码，你负责检阅、测试、整合

你会发现，AI不仅能帮你写出更规范的代码，还能在过程中教会你新的设计模式、语言特性，甚至帮你避坑。最终，项目变好了，你也变强了——双赢。

avatar
文章
阅读
粉丝