达尔文小姐每年Android Studio大版本的命名都挺有意思，从Koala、Ladybug到Meerkat，一路动物世界走过来，今年这个Otter 3（水獭）算是把版本号终于推到了2024.2.2系。说实话，我最初看到这个版本号的时候还愣了一下，Otter不是早就发过了吗？后来翻了更新日志才发现，这次相当于一个把新UI、设备镜像、Compose预览增强全部打磨到位的"完全体"版本。
但真正让我有兴趣聊这个话题的，是这两天不断有朋友问我同一个问题：既然Cursor这么强，日常写Android代码到底该用Android Studio还是Cursor？这个问题放在三年前根本不用讨论，AS是安卓开发唯一答案。可现在AI编程工具火了以后，团队里越来越多人在用Cursor写完代码再贴回Android Studio编译，两套工具来回倒腾，谁主谁辅已经成了实际痛点。
这篇文章我不打算给你一个非黑即白的答案，那没意义。我准备从Otter 3真正更新的东西讲起，再把AS和Cursor在安卓开发场景下的各自定位拆开揉碎，最后给一套我实际用了两个月的工作流。你看完自己去判断，哪种组合更适合自己手头的项目。
1. 内容整体设计与思路拆解
1.1 Otter 3到底更新了什么，值得你从旧版本迁移
先说一个很多人忽略的事实：Android Studio的版本号规则在两年前改成了按年份和功能命名，Otter 3对应的其实是IntelliJ 2024.2.2平台。大部分开发者从Meerkat或者Ladybug升上来，最直观的感受就是启动界面变了、图标变了、整个UI变得更加扁平紧凑，但真正内核层面的变化远不止这些。
第一个大变化是全新UI界面已经成为默认主题。这个新UI其实在Koala时代就开始灰度测试了，到Otter 3这里彻底转正。布局上最大的不同是左侧工具窗口默认折叠成细长图标条，主编辑区更宽，多行标签页改成可横向滚动的单行标签。很多人一开始觉得不习惯，尤其是用惯旧版侧边栏投射布局的老手，但我实际用了一周后，发现这个设计对16:10及以下比例的笔记本屏非常友好，代码区多出的每一列都是实打实的视野面积。
第二个核心升级是设备镜像和设备控制功能。你连着USB调试或者无线调试的时候，Otter 3可以在编辑器里直接开一个小窗实时投射手机屏幕，同时模拟点击、滑动、手势解锁。以前要装Vysor或者Scrcpy这类第三方工具才能做类似的事，现在官方把它内置了。这个功能对做TV端、车机端这类没法直接抱着真机到处跑的开发者来说，价值极高。
第三个值得关注的地方是Compose预览增强。这次Compose Preview不再只是一个静态渲染窗口，新增了交互式预览模式，你可以在预览面板里直接点击按钮、滚动列表、输入文字，模拟一次完整的用户操作流程，而不用先把App跑起来。这对纯Compose项目的开发效率提升是肉眼可见的。我自己的实操体验是，以前写一个带LazyColumn列表和点击事件的页面，至少要起一次模拟器，现在预览面板里点几下就能验证核心交互，整个调试循环的时间压缩了至少三分之一。
还有一个不容易被注意到的底层变化是内置了对Gradle 8.9和Kotlin 2.0.20的更完整支持，AGP版本插件也同步升级到8.7以上。这意味着新项目模板生成的构建脚本清爽了很多，用Kotlin DSL写构建逻辑的时候，类型安全的提示和补全比旧版本精准了一个量级。对用uni-app x这类跨端框架做原生打包的人来说，这个版本的SDK和构建工具链匹配度更高，踩兼容坑的概率明显下降。
1.2 Cursor在移动开发里的定位，其实和AS不是同一层
聊Cursor之前，我得先把一个误区纠正过来：很多人把Cursor理解成"Android Studio的竞品"，这个出发点就错了。Cursor本质是一个基于VSCode架构的AI原生编辑器，它的核心卖点不在编译、调试、性能剖析这些IDE能力上，而在"AI理解你的整个代码库、跨文件生成和修改代码"这件事上。
说白了，Android Studio在传统IDE维度上的积累——比如布局预览、APK分析器、Profiler、模拟器管理、SDK管理器——Cursor短期内根本不打算碰，也碰不了。你不可能指望Cursor替你做资源混淆、看内存泄漏、抓JNI崩溃日志，那本来就该是IDE的活。但Cursor的强项AI补全、Agent模式、跨文件重构，又是Android Studio目前的短板。
我常用Cursor的一个典型场景是：接到一个需求，要把项目里十几个数据模型类从Java转成Kotlin，同时顺手把Gson注解换成Kotlinx Serialization。这种活如果纯手写，一上午就没了。但用Cursor的Agent模式，你只需给一句指令"把所有使用Gson的Model类迁移到Kotlin Serialization，保留字段名兼容旧缓存"，它会自动遍历相关文件、生成修改方案、逐文件执行替换，而且会主动识别你项目里自定义的TypeAdapter，不会乱改序列化逻辑。
这才是Cursor在安卓日常开发中真正有价值的地方——它不是一个完整的Android IDE，而是一个高智商、高配合度的代码协作者。所以你想在"AS还是Cursor"里二选一，本质上是把两个不同维度的工具放在同一个维度上比，怎么选都是错的。
1.3 选择方案背后的思考：主IDE + AI协作者的组合逻辑
从我目前的实践来看，最合理的组合不是"二选一"，而是"双工具并行，各取所长"。Android Studio Otter 3作为主IDE，负责项目的构建、编译、真机调试、性能分析和版本管理；Cursor作为代码协作者，负责跨文件重构、样板代码生成、疑难问题的AI问答和批量代码修改。
听起来好像更麻烦了？其实配合得当反而比单一工具更高效。我现在的操作模式是：AS里写完一个模块的主体逻辑，切到Cursor里让它基于现有代码风格生成配套的Repository、ViewModel、UI State，再切回AS编译验证。如果编译报错，直接把报错信息扔给Cursor分析，它通常能结合整个项目的上下文给出准确的修复建议。
这套协作逻辑的核心在于，AS的输出（编译日志、崩溃堆栈、lint警告）恰好是Cursor最需要的输入。Cursor很擅长读代码、改代码，但它不擅长发现"编译期才知道"的问题；AS恰恰相反，它是发现问题最准的工具，但它在"怎么改"这件事上给不了AI级别的建议。两者互补关系非常清晰。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心细节解析与实操要点
2.1 Otter 3安装配置时的几个关键选项
不管你是从旧版本升级还是全新安装，Otter 3首次启动后有几个配置项值得你停下来认真选一下，而不是一路点下一步。
第一个是SDK组件选择。首次启动创建项目时，AS会提示你安装Android SDK Platform、Build-Tools和Platform-Tools。这里不要急着全选，我建议只安装你目标设备实际运行的API Level对应的Platform。比如你的测试机是Android 14，那就只装API 34，最多再加一个API 35以防万一。装一堆用不到的旧Platform不仅白占磁盘空间，还会拖慢每次Gradle构建时的SDK组件探测速度。
第二个是Gradle JDK版本。Otter 3默认会捆绑一个JBR（JetBrains Runtime），但实际跑Gradle构建时用的JDK和IDE运行用的JBR可以分离。如果你项目用了Java 17特性，请在Settings → Build Tools → Gradle里把Gradle JDK明确指向17或21版本。我碰到过不少朋友卡在"明明代码没问题但Gradle一直报错"，十有八九就是Gradle JDK版本和项目配置不匹配。
第三个是要不要启用新的UI。虽然Otter 3把新UI设为默认，但你完全可以在Settings → Appearance → New UI里切换回旧版布局。如果你有多个项目在维护，新旧窗口混着开也没问题。不过说句实在话，新UI用习惯之后很难回去，尤其是标签页管理和工具窗口折叠逻辑，切换成本在一两天内就能消化掉。
还有一个非常实用的小技巧：首次启动时在SDK Manager里勾选"Show Package Details"，然后把"Android SDK Command-line Tools"装好。后面你想用命令行去管理AVD、抓取日志、安装APK都会方便得多。很多只装IDE默认组件的人，后面用到adb、sdkmanager命令时才发现缺这个，再回头补装反而多花时间。
2.2 Cursor接入安卓项目的正确姿势
Cursor不是一个安卓IDE，但它完全可以当AI外挂来用。我建议的做法是：Cursor不要直接负责"跑项目"，而是作为AS项目的第二编辑器打开同一个目录。
实际操作很简单。Android Studio项目的根目录通常就是一个Gradle工程文件夹，你直接用Cursor的File → Open Folder打开这个目录就行。Cursor会自动识别Gradle构建文件和Java/Kotlin源码，代码跳转和语法高亮基本可用。但它不会自动配置Android SDK路径，所以你在Cursor里按F5想直接编译运行项目是行不通的，需要配置tasks.json之类的VS Code任务，麻烦而且性能也一般。所以我的原则是：Cursor只负责看代码、写代码、改代码，至于"运行"这件事，永远交给Android Studio。
接入之后，最有价值的玩法是给Cursor一个"项目级指令"，也就是写一份AGENTS.md或者CLAUDE.md放在项目根目录。这里面可以描述项目结构、代码风格、技术栈规范，比如"网络层用Retrofit + OkHttp，数据层用Room，UI全部用Jetpack Compose，不要新增XML布局"。这样Cursor在生成代码时就会优先遵循你的约束，而不是盲目按它自己的模板写。我实测下来，写了这份文件之后，AI生成代码的返工率直接低了一半。
还有一点要注意：Cursor的上下文窗口虽然大，但它不可能一次读完整个项目。所以给它指令时尽量把需求描述得足够具体，最好附上相关的文件路径或者类名。比如"参照model/User.kt的写法，新建一个model/Order.kt，字段包含id、amount、status，使用@Serializable注解"，这比一句"帮我写个Order模型"靠谱得多。
2.3 中文设置和界面汉化的实操要点
热词里有不少人在搜"android studio怎么设置中文""cursor汉化"，这里我统一说一下实际操作，免得每次都单独解释。
Android Studio本身是国际版IDE，官方没有内置中文语言包，但可以通过插件市场安装Chinese Language Pack。打开Settings → Plugins，搜索"中文"或者"Chinese"，找到JetBrains官方出品的中文语言包插件，安装后重启就是中文界面了。这里有个坑要提醒：如果你同时装了代码翻译类插件，两个插件可能起冲突，界面出现部分英文部分中文的"混合双打"状态，解决方法是只保留语言包插件，把翻译类插件禁用。
Cursor这边的情况稍微特殊一点。Cursor的基础UI是VSCode的壳，所以它支持中文的方法跟VSCode一样：打开扩展面板搜索"Chinese (Simplified) Language Pack for Visual Studio Code"，安装后右下角弹窗切换语言，重启即可。装完之后，菜单、设置界面、右键菜单都会变中文，但对话面板里的AI回复语言取决于你在设置里选择的模型行为，不影响。
我也见过有些朋友非要追求"打开就是中文"，用各种非官方汉化包去改配置文件。说实话没必要，官方中文语言包已经覆盖了95%以上的界面文案，剩下5%的技术术语本来就是英文更准确。汉化本身的意义是降低上手门槛，不是让你在技术文档里都看不到英文。长期做这行，英文界面其实更有利于你搜问题、看官方文档。
2.4 首次构建卡在Gradle下载的根治方法
Gradle首次构建慢几乎是每个新手绕不过去的坎。项目明明刚建好，点一下运行就要等半天，进度条一直卡在Gradle Sync或者Download Gradle distribution。这背后有两个原因：一是Gradle Wrapper要下载对应版本的Gradle包，二是构建过程要去中央仓库拉依赖库。国内网络环境下这两个步骤都可能慢得让人怀疑人生。
根治方法其实不复杂，核心思路是"本地分发 + 镜像仓库"双管齐下。首先，你可以直接从Gradle官网或者可靠的软件源下载对应版本的Gradle完整包，解压到本地任意目录，然后在AS的Gradle设置里指定"Use Gradle from: specified location"，这样就不需要每次Wrapper去下载。其次是仓库镜像，在项目根目录的settings.gradle或者build.gradle里，把仓库地址加上阿里云或腾讯云的Maven镜像，依赖下载速度能快好几倍。这个操作对国内开发者来说是刚需，我每次新建项目第一件事就是改仓库地址，否则点击构建之后那十几分钟的等待真的很消磨耐心。
另外一个小技巧是：如果你手上同时维护多个项目，可以把Gradle用户目录下的缓存文件夹转移到大分区。默认的Gradle缓存都在C盘用户目录，时间长了几个G都是正常的，C盘吃紧的时候整体迁移排队再软链接回去，比反复清理要有用得多。
3. 实操过程与核心环节实现
3.1 我用Otter 3跑通一个完整Compose页面的实测流程
我拿最近写的一个订单列表页拆解一下Otter 3的完整工作流，方便你直观感受新版本在真实项目里到底能省多少事。
项目用的是Clean Architecture加Jetpack Compose，一个典型的功能模块从0到1大概涉及数据层、领域层和UI层。以前写这套东西，Moshi的JsonAdapter、Retrofit的Service接口、Repository实现类、ViewModel的状态和事件、Compose的页面布局，每一层都要手写，接口字段多的时候光敲样板代码就能占一大半时间。
这次我刻意试了一下"AS + Cursor"的组合流程。第一步在AS里手动建好模块骨架，把Gradle依赖配好；第二步把后端给的接口文档直接丢给Cursor，让它生成Retrofit Service接口和对应的数据模型；第三步再把Cursor生成的数据模型和接口贴回AS里的对应包路径；第四步回AS编译，处理报错；第五步跑真机调试。
实际操作里，最花时间的不是写代码，而是"编译—报错—修"这个循环。Cursor生成的代码质量已经不错，但偶尔还是会出现类型不匹配、缺少依赖、Compose作用域写错这类问题。好在AS的报错定位非常精准，Lint提示也很完整，配合IDE的Quick Fix快速导入类名或补充缺失依赖，整个循环从发现问题到解决基本控制在一两分钟内。我记录了一下，整个订单列表模块从新建目录到真机跑通，一共花了不到一个半小时，对比以前纯手写动辄三四个小时，效率提升是实打实的。
3.2 利用设备镜像功能做TV端远程调试的现场记录
Otter 3的设备镜像功能我专门在TV端项目上做了验证。做TV应用开发最痛苦的地方就是调试，电视屏幕大、遥控器操作繁琐、想截图看UI还得先截图再传到电脑。旧版AS里虽然可以通过Layout Inspector看视图层级，但想看页面渲染的实际效果，还是得来回切屏幕。
这次我在Otter 3里连了一台Android TV模拟器，直接在Device Mirroring窗口里观察画面。按钮焦点切换、RecyclerView滚动效果、退出对话框的展示逻辑，全都可以在一个小窗里完成操作和观察，不用在大电视屏幕和电脑之间反复转头。更实用的一点是，你可以直接在镜像窗口里发起手势操作，比如模拟遥控器上的D-Pad按键、Back键、Home键，对TV端开发来说简直是一键解决痛点。
不过也要说实话，设备镜像功能目前还有两个小问题：一是画面延迟比较明显，尤其在做动画流畅度验证时不准确；二是镜像窗口里的截图功能导出的是当前屏幕缩略图，分辨率不高。我的建议是拿它做静态UI和逻辑交互验证，真要评估动画帧率或者画面细节，还是得靠传统的截屏加ADB导出，或者用模拟器自带的Screen Record功能。
3.3 用Cursor辅助重构遗留Java代码的一个具体案例
项目里有一段五年前写的老代码，一个订单状态判断的工具类，全是if-else嵌套近两百行，每次加新状态都要在方法里再塞几层判断，改一处崩三处。这个类的重构需求一直排不上队，因为逻辑分支太散，靠人肉读代码梳理状态流转很容易漏。
这次我直接用Cursor把这个类丢给它，指令是"重构这个类，用枚举加状态机的模式重写，保证对外方法签名不变，注释清楚每个状态的入口和出口"。Cursor大约花了十几秒给出了重写版本，我粗看一遍没有明显问题，就贴回AS里编译跑单测。结果测试挂了四个用例，我把失败的断言信息原样丢给Cursor，它很快就定位到我原来的状态流转里有两个分支在当前模式下没有显式定义，属于原代码里的隐式逻辑。
这个案例给我最大的启发是，AI重构工具最大的价值不是一次性成功，而是它愿意并且能够基于测试反馈快速迭代。传统程序员面对这种两百行烂代码至少要鼓动半天勇气才敢动手，现在让AI先出一个候选方案，我再针对边界情况补充修改，整体心理负担小了很多。
3.4 新手最常问的SDK问题和环境变量配置
如果你是完全新手，我建议先把Android SDK和环境变量的关系搞明白，否则以后很容易被各种教程绕晕。
Android SDK是安卓开发的基础工具集，里面包含platform（各版本的系统库）、build-tools（编译打包工具）、platform-tools（包含adb、fastboot这些基础命令）。Android Studio安装时会在你指定的目录下创建一套SDK，比如macOS上通常在~/Library/Android/sdk，Windows上通常在%LOCALAPPDATA%\Android\Sdk。
SDK本身通过IDE内置的SDK Manager管理，不需要你去手动配置环境变量，IDE能自动找到它。你需要额外配置环境变量的场景，主要是你想在终端里直接用adb、sqlite3、sdkmanager这些命令。配置方法很老套：把$SDK_ROOT/platform-tools和$SDK_ROOT/tools加入PATH。macOS和Linux改shell配置文件，Windows改系统环境变量Path。设置完之后开一个新的终端窗口，敲adb version能出输出就说明配置成功。
另外我强烈建议新手在SDK Manager里把"Android SDK Command-line Tools（latest）"勾上，很多脚本和自动化工具依赖它。还有模拟器系统镜像，你如果用x86电脑就装x86_64镜像，用苹果Apple Silicon芯片就装arm64-v8a镜像，装反了模拟器启动会慢到让你怀疑人生。
3.5 Otter 3里的新项目模板和Gradle配置变化
Otter 3上的新项目模板相比旧版有一处明显的进化：默认生成的MainActivity已经不再是一堆模板注释的堆积，而是直接用Compose搭了一个可运行的最小页面。对于用Compose作为主力UI框架的项目来说，省去了手动添加Compose依赖、再删除XML布局的步骤。
另一个变化是Gradle配置的默认值更合理。新建项目的build.gradle.kts里，namespace和applicationId已经自动同步，compileSdk默认指向当前最新稳定版，Kotlin插件的版本号和Kotlin标准库版本号保持一致，不需要再像老版本那样手动对齐。AGP和Kotlin插件之间的兼容矩阵，在模板中也已经预先搭配好，新手直接运行基本不会遇到版本冲突。
当然，Gradle版本升级也带来了迁移成本。老项目如果用的是AGP 7.x甚至更老的版本，直接打开Otter 3会提示AGP版本过旧无法兼容。这时候不要慌，按提示升级AGP版本，再把Gradle Wrapper的distributionUrl改成匹配的版本即可。常见的坑是Kotlin插件和Kotlin标准库的版本不一致，或者用了废弃的API，这些编译日志都会明确提示，逐个处理就行。
4. 常见问题与排查技巧实录
4.1 热词里那些高频问题的集中回复
我把评论区还有各社区里经常被问到的几个典型问题，集中在这里回复一下，后续再有人问可以直接甩链接。
"Android Studio每次新建项目都要下载Gradle，真受不了。" 这个我在前面讲过了，就是把Gradle改为指定本地路径，同时配置镜像仓库。还有一个小技巧是：新建项目时选择Gradle DSL为Kotlin，构建脚本里把repositories优先指向你的内网镜像。如果你是在公司开发，团队内搭一个Nexus仓库，几十号人共享缓存，体验完全不一样。
"为什么我的Cursor没有聊天面板？""Cursor免费次数用完怎么办？" Cursor分为Free和Pro模式。免费版每天的AI请求次数有限，如果你当天额度用完，系统会提示你等待或者升级。升级Pro之后能解锁更多高级模型和带宽。实际操作中，如果每天重度使用，基本不可能靠免费额度撑到底；但轻度写写补全、偶尔聊天问问问题，免费版也还能用。别去搜那些所谓的无限额度破解方案，Curosr的账号是云校验的，破解不靠谱，还容易封号。
"MVVM架构里ViewModel需要把Repository传进去吗？" 这个问题的核心不在工具，在架构设计。传统写法确实是ViewModel构造参数里持有Repository的实例，但更好的做法是用依赖注入框架或者简单的手写ServiceLocator来解耦。AI工具能帮你生成代码，但架构决策始终是你来定的。
4.2 AS与Cursor并排使用时常见的协作混乱问题
双工具并行最大的问题不是技术，而是"改动了同一份代码但两个窗口没有即时同步"。AS和Cursor同时打开一个项目，在AS里改了一个文件，切到Cursor时可能还停留在旧版本，反过来也一样。如果你不小心在某个窗口手动编辑了已经被另一个窗口修改过的文件，还会产生磁盘冲突弹窗。
解决办法有两个方向。第一，尽量坚持"一个窗口负责改，一个窗口负责读"的原则。我的习惯是Cursor主要用于生成和修改代码，AS用于编译、调试、查看错误信息，不在AS里手动编辑Cursor正在处理的文件，避免双方互相踩。第二，如果确实需要在两边切换编辑，可以在Cursor里顺手保存一下文件（Cmd+S），AS会自动感知到外部文件变化并重新加载，反过来也一样。关键就是别把"未保存的状态"留在某个窗口里。
另外提醒一个容易踩的坑：Cursor在根目录创建的那些配置文件（比如.cursorrules、AGENTS.md）会出现在AS的文件树里。你不用删它，在AS的Settings → File Types里把它们标记为忽略文件即可，避免它们污染搜索和代码审查范围。
4.3 一些反直觉但很实用的Debug经验
Otter 3和Cursor配合调试时，有几个经验是反直觉的，但确实有效。
第一，你在AS里顺手记下的错误日志往往是喂给AI的最好"食粮"，而不是你自己去逐行读源码。很多报错信息含有堆栈、行号、异常类型，这些信息越完整，AI给出的定位越精准。所以别再说"我贴了个报错截图给Cursor但它回答得很敷衍"，要让AI去理解报错上下文，前提是你给它足够多可解析的文本。
第二，用Compose预览时，如果预览面板一直白屏，先检查你的Compose函数是不是用了非纯状态依赖，比如直接访问了ViewModel或者读取了全局单例。预览环境本身没有完整的Application生命周期，一旦依赖真实运行环境就会崩溃。解决办法是把可预览的UI状态通过函数参数传进去，让预览用一个假数据对象渲染。
第三，ADB的无线调试功能比很多人想象中好用。Otter 3的Device Mirroring支持无线连接，前提是你的手机和电脑在同一局域网内，且已开启开发者选项中的"无线调试"。首次连接用配对码，之后在AS的设备下拉列表里就可以直接重连。真机调试的时候，无线连接省去了找数据线的麻烦，但大安装包或高频率日志输出时稳定性不如USB，建议两种方式按场景切换。
4.4 用反编译工具辅助学习项目实现
热词里有"使用android studio反编译apk"，这块我简单提一下。AS本身没有内置APK反编译功能，但你可以把APK文件直接拖到AS的编辑器窗口里，它会自动打开一个APK分析界面，让你查看APK里的资源、DEX文件数量、Manifest信息等。这个功能主要用于自查打包产物和检查资源混入情况。
如果真想看别人APK的Java代码，需要配合工具链：先用APKTool把APK的资源和smali中间码解包出来，再用Jadx把DEX转成可读性更好的Java代码。这类操作建议只用于学习、逆向分析和安全研究。实际项目里遇到"这个效果怎么做出来的"问题，与其反编译别人代码，不如直接去GitHub搜类似实现，更省事也更规范。
5. 再聊几句工具选择的底层判断逻辑
5.1 为什么我觉得谈"AS还是Cursor"这个问题本身有点伪
不管怎么选，Android开发绕不开AS的原因很简单：官方SDK、模拟器、Android Gradle Plugin、布局检查器、Profiler，这些核心能力只在AS里有完整集成，第三方编辑器永远只能做"外部工具"级别的集成。所以只要你做的是正经Android项目，AS基本上是必装的。
但这不妨碍Cursor作为第二工具入场。它的AI能力在代码生成、重构、跨文件理解上已经超出了"补全插件"的范畴，更像一个实时的结对编程伙伴。当你把那些"体力活"（生成DTO、写样板Repository、整理if-else分支）交给它之后，你会发现自己的精力能更集中在架构设计和业务梳理上。这才是这类工具真正的价值。
所以，与其问"AS还是Cursor"，不如换个问法：你希望自己的时间是花在"写代码"还是"设计系统"上？如果答案是设计系统，那Cursor算是一个很有力的杠杆。如果现阶段你自己连基础的Gradle配置、SDK管理、构建流程都还没完全吃透，先把AS用熟更重要——因为AS帮你建立的是安卓工程的底层逻辑，Cursor则是放大这个底层逻辑的效率工具。
5.2 后续还可以怎么扩展这套双工具工作流
这套"AS主IDE + Cursor协作者"的工作流，再往后扩展其实还有很多玩法。比如可以把Cursor生成的代码直接通过Git分支管理起来，改动由AI在一个独立分支完成，然后在AS里做Code Review合并，这就形成了"AI先干活，人来review"的协作闭环。更进一步，可以在CI里加一个AI Code Review环节，让机器先扫一遍代码风格和潜在问题，再交给人工复审，能减少不少低级问题。
另外，Compose Multiplatform现在越来越成熟，如果你打算让一套Compose代码同时跑Android和iOS，那这套工作流的优势会更明显。Cursor擅长生成跨平台共用代码，AS负责Android侧的调试和打包，整个工程的复杂度被分摊到两个最适合各自角色的工具里，每个工具都只做自己最擅长的事。这个方向我最近在尝试，等跑通一个完整项目之后再专门写一篇分享具体的坑和心得。
最后再啰嗦一句：工具这东西，没有标准答案。你自己测试下来顺手，团队协作不出问题，那就是最合适的方案。别人的工作流可以参考，但别照搬，效率最终是长在你自己习惯里的。