说实话，作为一个在代码堆里摸爬滚打了十几年的“老炮儿”，Zui近这几个月我的心态发生了一些微妙的变化。以前我们写代码，那叫一个“苦行僧”，从C++裸写时代一路熬过来数据库连接要自己写ODBC代码，日志系统要自己封装DLL，甚至连程序启动的main函数里dou要手动初始化所有模块的依赖，没有一点捷径可走。那时候，前后端交互全靠socket手动撸协议，没有参考案例，全靠团队一点点试错。

但如今风向变了。虽然我依然保持着“手动撸码”的习惯，但这双手现我到底dou干了些什么以及这些智Neng助手到底靠不靠谱。

相信iOS圈的兄弟们dou有所耳闻，CocoaPods停止维护的消息就像一颗深水炸弹。虽然它还Neng用，但那种“大厦将倾”的不安感让人如坐针毡。我手里有个从2019年就开始维护的RxStudy练手项目，一直是我测试新技术的试验田。趁着这个机会，我决定拿它开刀，来一次彻底的架构大迁移。

这次的目标hen明确：CocoaPods → Tuist + Swift Package Manager 。这不仅仅是换个包管理工具那么简单，本质上是从Ruby脚本迁移到了原生的Swift构建系统。说实话，本来以为会花费geng多时间，毕竟Tuist的学习曲线并不平缓，还要处理各种依赖冲突。

结果呢？前前后后大概3天。大大出乎我的意料。

在这个过程中，我并没有自己去啃Tuist那厚厚的文档，而是把需求直接扔给了AI。大部分时间其实花在了Tuist配置文件的编写上，这玩意儿对格式极其敏感。AI生成的代码基本Ke以直接使用，复盘时发现主要还是项目结构本身比较规范，AI才Neng理解得这么透彻。

它甚至提供了详细的优化报告，把优化效果量化得清清楚楚。比如它建议我调整某些Target的编译顺序，或者把一些公共模块抽离成SPM包，这些建议dou非常中肯。Ru果你也想摆脱繁琐的微观管理，实现从手动撸码到系统指挥的飞跃，这10条来自创始团队的一手秘籍，将是你进阶之路的必备指南。

搞定了构建工具，我的野心geng大了。既然dou动了不如把RxSwift里的UIKit代码也向SwiftUI进行迁移。这可是个硬骨头，毕竟响应式编程和声明式UI的思维方式完全不同。

我没有选择一次性替换，因为那样风险太大。我采用了双 Target 并行架构。这意味着在同一个项目里UIKit和SwiftUI共存，逐步蚕食。这种策略虽然会让项目暂时显得臃肿，但胜在安全。

迁移耗时大约2小时完成全部迁移。你没听错，核心页面的迁移只用了这么点时间。SwiftUIApp这个Target里的代码，90%dou是AI写的，我只是给出了部分建议，以及尝试在两个Target中复用网络请求层代码。

这里有个细节值得一提。在这次迁移中，SwiftUI部分我没有使用Combine，而是使用了iOS 17+的@Observable宏和Swift的async/await。代码kan起来比以前那一堆Publisher和Subscriber要清爽得多。AI对这种现代语法的掌握非常熟练，它生成的网络请求代码几乎不需要修改。

当然AI也不是万Neng的。对于一些复杂的交互动画，比如“下拉刷新 + 列表滚动 + 头部视差效果”，AI生成的代码虽然逻辑上没问题，但那种丝滑的手感完全不对劲。Zui后还是得我亲自上阵，调整动画曲线和偏移量。kan来在涉及到用户体验的“微操”上，人类的手感暂时还无法被替代。

除了iOS，Zui近我也在折腾鸿蒙。其实这个尝试，没有使用AI的功Neng，完全就是我自己无聊Zuo的一点尝试。我手里有个hen久之前写的UniApp版本的“玩安卓”，一直没维护。Zui近心血来潮，想把这个UniApp打包的wgt文件在HarmonyOS Next里通过小程序运行起来。

问题来了uniCloud环境仅支持Vue3版本的小程序，而我那个老项目是Vue2写的。这就逼着我必须先把项目升级到Vue3。配合上面UniAppPlayAndroid的升级，我终于Ke以在打包好的wgt文件在HarmonyOS Next正常运行起来了。

在这个过程中，我还Zuo了一个超级大杂烩：把GetXStudy项目的Flutter模块全部dou集成到RxStudy项目里尝试几个端的通信。大家kankan效果，虽然有点乱，但跑起来那一刻还是挺有成就感的。

路由管理是个噩梦。AI在路由迁移上采用了Zui小改动方案，保留了兼容性。它还顺便优化了Router类的实现，并完成了Network HAR模块的封装。以前那种router.pushNamedRoute的写法被统一了虽然有些APIYi经废弃，但为了兼容性，AI处理得还算得体。

//  router.pushNamedRoute
router.getParams
// 新的统一写法
// router.push

这一通折腾下来我Zui大的感悟不是AI有多强，而是我们的角色必须变了。团队的核心原则是：从不手动编写代码。这听起来hen极端，但这就是趋势。

在这次的一系列操作中，我的AI使用组合主要是：Claude + MLG 和 Claude + MiniMax。就我个人而言，我会使用多个git checkout，但Claude Code团队的大多数成员geng倾向于使用worktree——这也是为什么@amorriscode专门在Claude桌面应用中内置了对它的原生支持！

这种工具链的组合，让我Neng够快速地在不同模型之间切换。Claude擅长逻辑推理和架构设计，而MiniMax在某些具体的代码生成上有时候会有惊喜。

以前Java项目中，充斥着太多不友好的代码：POJO的getter/setter/toString；异常处理；I/O流的关闭操作等等。这些样板代码既没有技术含量，又影响着代码的美观。Lombok应运而生解决了这个问题。但任何技术的出现dou是为了解决某一类问题，Ru果在此基础上再建立奇技淫巧，不如回归Java本身。

现在的AI编程也是同理。我们不应该把AI当成一个高级的“代码补全器”，那样你依然是个搬运工。只有认知上Zuo根本的转变，才Neng跟上这个时代。从成立之初就一直对标OpenAI，也被称为「中国OpenAI」的智谱AI，发布了新一代基座大模型GLM-4，这些dou在告诉我们：基础设施Yi经变了。

时常在想，就这么付费上班，是不是也挺肉疼。毕竟Claude Pro、Copilot、还有各种国内大模型的会员费加起来也是一笔不小的开支。后来想想，上班没那么累，下班Ke以正常走，也算行吧。

这种“躺平幻想”纯属异想天开。AI虽然Neng帮你干hen多活，但它不会替你背锅。比如Zui近在学习用micropython撸esp32玩，不明白的地方就问一下人工智Neng，一般还是相当方便的。今天晚上撸了几行简单的代码执行时报错，就想着用人工智Neng来查一下错，分别试了百度的文心一言，阿里的通义千问，讯飞的星火，感觉dou不靠谱。Zui后还是自己kan日志解决了。

这说明什么？说明AI现在干活容易翻车吗？太容易了！Anthropic了几种经典翻车姿势。我们不Neng完全依赖它，必须得有“缰绳”在手。

回顾这段时间，我把项目从CocoaPods迁移到Tuist，把RxSwift迁移到SwiftUI，把UniApp升级到Vue3，甚至还搞了Flutter混编。AI确实帮我省下了大量的敲键盘时间，它生成的二维码太好kan了甚至NengZuo那种艺术二维码，长按识别就Neng跳转，这在以前是不可想象的。

但是当我kan着屏幕上那些复杂的视差动画代码，或者是为了解决一个LoadingDialog兼容性问题而抓耳挠腮时我依然Neng感受到写代码的乐趣。这种乐趣，不是AINeng生成的。想像一下我们坐发明创造的方式发生了变化。

我不知道为什么身边总有一些人，使用hen短/随机的名称来给变量命名。但我知道，无论AI怎么发展，保持对代码的敬畏，保持对技术的敏感，才是我们在这个AI时代生存下去的根本。至于当初为什么会放下Hexo博客，其中一个原因是用户体验太差，还需要手动创建移动md文件，仿佛回到了原始社会。现在我又把它拾起来了因为我想记录下这个变革的时代。

Ru果你也想摆脱繁琐，不妨试试让AI帮你干点脏活累活，但记住缰绳一定要握在自己手里。