目录前言一、拿什么项目来试 Seed Evolving二、第1轮先把 22 个构建错误理清楚三、第二轮先修核心问题再处理连锁问题3.1 Facebook SDK从 latest.release 改成固定版本3.2 network_security_config不用 resValue 绕了改成 source set3.3 APNetReceiverAndroid 12 的 exported 要求四、继续 Rebuild后面几类问题才露出来4.1 native so 重复4.2 allowBackup 清单冲突4.3 Guava ListenableFuture 重复五、Gradle 问题修完又遇到 Kotlin 编译错误六、编译通过后Run 按钮又灰了七、终于装到手机但开屏后闪退八、整个流程回顾九、个人感受十、总结前言最近看到豆包 Seed Evolving 上线我对它的理解是它不是一个固定版本的模型而是一个会持续迭代的 latest 分支尤其偏向 Coding 和 Agent 这类需要多轮上下文、工具调用和长期任务推进的场景。这下子又有新玩意可以倒腾了我在官网开通了Agent Plan 个人版当然只使用它的语言模型 Doubao-Seed-Evolving 来试试水看看能力如何。我选择在TRAE 软件上添加模型进行使用 Doubao-Seed-Evolving毕竟都是一家的产品适配度更高。一、拿什么项目来试 Seed Evolving刚好手里有一个很适合测试的真实问题一个很久没维护的视频剪辑 App 项目。这个项目不是 Demo也不是新建工程而是一个多模块、依赖复杂、接了广告、登录、支付、视频编辑 SDK、上传模块的老项目。我在 Android Studio 里拉完代码后直接 Build结果迎面就是BUILD FAILED with 22 failures。错误日志文件有 140KB里面混着依赖冲突、Manifest 合并失败、AndroidTest 资源失败、native so 重复、Kotlin 编译错误等问题。平时遇到这种项目我一般会先深呼吸一下因为它不是改一行代码能解决的而是要一点点剥洋葱。这次我就把它作为 Seed Evolving 的测试任务让它陪我从 Build、安装、运行到真机闪退排查完整走一遍。二、第1轮先把 22 个构建错误理清楚一开始比较棘手的问题不是“怎么改”而是“到底先看哪个错误”。Android Studio 一次性抛出 22 个 failure很多错误还会互相影响前面的依赖冲突不解决后面可能继续连锁报错。我把构建日志文件交给 AI让它先不要急着改代码而是帮我做错误归类。它先从日志中搜索FAILED、error、exception这些关键字再按模块和错误类型梳理。第一轮它先抓出了三类核心问题#错误类型关键信息1Facebook SDK 重复类Type com.facebook.internal.AppCall$Companion is defined multiple times2AndroidTest 资源链接失败resource xml/network_security_config_debug not found3APNetReceiver缺少android:exported多个 library 模块在 AndroidTest Manifest 合并时失败这里我觉得比较有价值的是它没有只盯着某一条报错而是把错误背后的关系串起来了。比如 Facebook SDK 的重复类不是简单“删一个包”就能解决它追到了login_base/build.gradle里用了api com.facebook.android:facebook-login:latest.releaselatest.release在老项目里很危险因为它会随着远端仓库变化导致本来能构建的项目过一段时间突然不稳定。三、第二轮先修核心问题再处理连锁问题3.1 Facebook SDK从 latest.release 改成固定版本AI 先建议把 Facebook SDK 固定到明确版本避免动态拉取。这里中间还有一个小插曲第一次它先改到了16.0.0但后面 Rebuild 时发现 Facebook SDK 16.x 又引入了 Kotlin 1.8.x 的 stdlib和项目当前 Kotlin 1.7.x 体系冲突。于是又调整成更贴合当前工程的15.2.0并排除它传递进来的 kotlin-stdlibapi(com.facebook.android:facebook-login:15.2.0) { exclude group: org.jetbrains.kotlin, module: kotlin-stdlib }同时在根build.gradle里补了一层版本约束统一 Kotlin stdliballprojects { configurations.all { resolutionStrategy { force org.jetbrains.kotlin:kotlin-stdlib:${kotlin_version} force org.jetbrains.kotlin:kotlin-stdlib-jdk7:${kotlin_version} force org.jetbrains.kotlin:kotlin-stdlib-jdk8:${kotlin_version} } } }这个过程很像真实开发不是一次就选到完美版本而是根据后续报错再收敛方案。3.2 network_security_config不用 resValue 绕了改成 source set原项目在app和app_*模块里通过resValue动态指定网络安全配置resValue xml, network_security_config, xml/network_security_config_debug普通 Debug 包可能没问题但 AndroidTest 构建时测试 APK 找不到被引用的network_security_config_debug于是资源链接失败。AI 的处理方式不是简单复制一个同名文件到 androidTest而是把方案改得更清晰不同 build type 直接放各自的network_security_config.xml。app/src/debug/res/xml/network_security_config.xml app/src/release/res/xml/network_security_config.xml app/src/betaTest/res/xml/network_security_config.xml app/src/huaweiBetaTest/res/xml/network_security_config.xml app/src/huawei/res/xml/network_security_config.xml app/src/google/res/xml/network_security_config.xmlapp_*也做同样处理。这样 Manifest 里始终引用xml/network_security_config具体用哪份资源交给 Android 的 source set 合并机制来决定逻辑更直观。3.3 APNetReceiverAndroid 12 的 exported 要求另一个批量报错来自com.aipai.netmonitorsdk.receiver.APNetReceiver。它在第三方 SDK 的 Manifest 中声明了intent-filter但没有写android:exported。Android 12 之后这类组件必须显式指定 exported否则 Manifest merger 会失败。AI 先在common模块里加了覆盖声明receiver android:namecom.aipai.netmonitorsdk.receiver.APNetReceiver android:exportedtrue tools:replaceandroid:exported intent-filter action android:nameandroid.net.conn.CONNECTIVITY_CHANGE / /intent-filter /receiver但它也继续检查了依赖关系发现有些模块不一定通过 common 传递到这个 Manifest所以又在router、upload、base_app、ipay-exposed、webview、downloadImpl等模块补了对应声明。这一步如果手工做比较容易漏模块AI 的优势在于它能顺着错误日志和模块结构继续扫。四、继续 Rebuild后面几类问题才露出来前面三类问题处理完后我本来以为差不多了。但继续读日志后面的What went wrong又发现了几类隐藏问题。4.1 native so 重复main模块报了2 files found with path lib/arm64-v8a/libc_shared.so - jetified-mmkv-1.2.7 - jetified-video-editor-ai-common-1.9.0.300这是多个 AAR 都带了libc_shared.so。处理方式是在main/build.gradle里添加packagingOptions { pickFirst lib/*/libc_shared.so }4.2 allowBackup 清单冲突pay-huaweipay模块里aiPai http 库和华为 IAP SDK 对android:allowBackup的声明不一致一个是 true一个是 false。Manifest merger 需要明确取哪个值。于是 Manifest 里加了application android:allowBackuptrue tools:replaceandroid:allowBackup4.3 Guava ListenableFuture 重复upload模块中 AWS SDK 传递依赖带来了guava:18.0同时又有listenablefuture:1.0产生重复类。AI 对 AWS 依赖加了 excludeimplementation(rootProject.ext.dependencies.aws_s3) { exclude group: com.google.guava, module: listenablefuture } implementation(rootProject.ext.dependencies.aws_auth) { exclude group: com.google.guava, module: listenablefuture }这几类问题都不大但散落在不同模块里。对人来说比较消耗注意力对 Agent 来说只要上下文不断它可以一直往下推进。五、Gradle 问题修完又遇到 Kotlin 编译错误Gradle 配置、Manifest、资源问题修完后再 Rebuildupload 模块又冒出一个 Kotlin 编译错误e: CreateThumbManager.kt: (74, 42): Smart cast to FileOutputStream is impossible, because out is a local variable that is captured by a changing closure出问题的代码大概是这样var out: FileOutputStream? null runCatching { out FileOutputStream(saveFile) bitmap.compress(format, 100, out) out?.flush() out?.close() }.onFailure { out?.close() if (saveFile.exists()) saveFile.delete() }Kotlin 不允许对被闭包捕获、且会变化的局部变量做 Smart Cast。AI 把它改成.use {}runCatching { FileOutputStream(saveFile).use { out - bitmap.compress(format, 100, out) out.flush() } }.onFailure { if (saveFile.exists()) saveFile.delete() }这个改法比原代码更符合 Kotlin 写法也避免了异常情况下漏关流的问题。六、编译通过后Run 按钮又灰了Make Project 成功后我准备直接装手机结果 Android Studio 顶部的 Run 按钮是灰色的。这个问题其实和代码无关是因为前面改了多个build.gradle文件Android Studio 需要重新 Gradle Sync。同步完成后设备能正常识别Run 按钮也恢复了。这个小插曲也挺真实工程跑起来不是只有“代码正确”就够了IDE 状态、Gradle Sync、设备连接都会影响最后一步。七、终于装到手机但开屏后闪退Run 成功安装到小米手机Android 10 / MIUI 12后App 能进入开屏页但很快闪退。再次打开会弹各种权限授权后还是闪退。一开始我怀疑是不是 Android 10 系统版本不兼容。但看项目的 minSdk 是 24Android 10 理论上没问题。我先尝试用 adb 抓日志但终端里 adb daemon 没连上。后来用 Android Studio Logcat 看了一段只看到进程启动后几秒结束前面全是 MIUI、Google Play services、PowerKeeper 这类系统日志没有明显的 Java 崩溃栈。AI 建议我导出更完整的日志文件。我把完整 Logcat 保存成日志报错.md再给它分析这次终于抓到了关键堆栈FATAL EXCEPTION: main java.lang.IllegalArgumentException: Linear gradient requires angle attribute to be a multiple of 45 at android.graphics.drawable.GradientDrawable$GradientState .updateGradientStateOrientation(GradientDrawable.java:2208) ... at androidx.viewpager.widget.ViewPager.onMeasure(ViewPager.java:1622)这不是系统版本不匹配而是 drawable 资源兼容性问题。Android 的GradientDrawable要求线性渐变的android:angle必须是 45 的倍数比如 0、45、90、135、180、225、270、315。项目里有几个资源写得不规范文件原角度修改后bg_home_vip_tip.xml332315audio_extract_normal_bg.xml3600common_color_fb2055_13_bg.xml3600其中332肯定不合法360虽然数学上等于 0但在部分系统实现里也会抛异常。修改后重新 Make Project再 RunApp 终于能正常进入首页。八、整个流程回顾这次不是一次性修完而是一步一步推进Build失败22个错误 → 分析日志先定位3类核心问题 → 修复Facebook / network_security_config / APNetReceiver → Rebuild后发现Facebook版本引入Kotlin冲突 → 调整Facebook版本并统一Kotlin stdlib → 继续读日志处理native so / allowBackup / Guava问题 → Rebuild后出现Kotlin Smart Cast错误 → 重构FileOutputStream写法 → Make Project成功但Run按钮灰色 → Gradle Sync后恢复Run → 安装到手机开屏后闪退 → 日志不完整导出完整Logcat → 定位GradientDrawable angle问题 → 修改drawable资源重新运行成功我没有刻意统计精确耗时但对比自己以前处理类似项目的经验这类问题通常会被拆散在半天甚至更久的碎片时间里。用 Seed Evolving 的感受是它能把长上下文里的错误、文件、修改历史串起来不会只盯着当前这一条报错看。阶段如果手动排查这次AI辅助体验大日志归类需要反复翻日志能按错误类型和模块归类依赖冲突要查 dependency tree能指出动态版本和传递依赖风险多模块 Manifest容易漏模块能顺着模块结构继续补齐Gradle / Kotlin / 资源问题容易在不同知识点间切换能连续处理不同层级问题运行时闪退日志不全时容易误判能提醒补充完整日志再判断比较打动我的是它不是只回答“这一行怎么改”而是能陪着任务往后走。前面修完构建后面又遇到 IDE 状态、真机安装、运行时闪退它都能接着上下文继续分析。九、个人感受如果只是新建一个 Demo让 AI 写几个页面其实不太能看出差距。真实项目麻烦的地方在于问题不是按教材顺序出现的而是混在一起你修完一个另一个才会冒出来。这次 app项目 的修复过程比较能体现 Seed Evolving 适合的场景上下文长要读构建日志、多个 build.gradle、Manifest、drawable、Kotlin 文件任务链长Build → Rebuild → Make → Sync → Run → Logcat → 再修复问题跨度大Gradle、Android资源、Manifest合并、Kotlin语法、Android版本兼容性都碰到了多轮对话不能断每一步都依赖前面的修改结果。解决问题过程中的 token / 工具调用消耗也不低但这个场景里我觉得是合理的。它花的不是“闲聊成本”而是在持续读文件、定位问题、修改代码、根据新错误调整方案。这次体验之后我对这类 Coding Agent 的期待也更明确了不是替我写几段代码而是在我面对复杂老项目时能帮我稳定地把上下文接住一步步把项目跑起来。十、总结这次用 TRAE 豆包 Seed Evolving 修复 app 项目的过程从一开始的 22 个构建错误到后来真机运行成功基本覆盖了一次旧 Android 项目接手时会遇到的典型坑。它让我感觉比较明显的一点是AI 编程助手已经不只是“代码补全工具”更像一个能一起排查问题的工程搭子。它可能中间也会试错比如 Facebook SDK 版本一开始选高了但它能根据后续错误继续调整不会卡在一个点上。对于开发者来说这种能力挺实用你不需要一开始就把所有问题都说清楚只要把真实日志、真实代码、真实现象给它它就能陪你把 Build、安装、运行这条链路逐步跑通。