目录

前言

一、拿什么项目来试 Seed Evolving

二、第1轮：先把 22 个构建错误理清楚

三、第二轮：先修核心问题，再处理连锁问题

3.1 Facebook SDK：从 latest.release 改成固定版本

3.2 network_security_config：不用 resValue 绕了，改成 source set

3.3 APNetReceiver：Android 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 这些关键字，再按模块和错误类型梳理。

        第一轮它先抓出了三类核心问题：

#	错误类型	关键信息
1	Facebook SDK 重复类	Type com.facebook.internal.AppCall$Companion is defined multiple times
2	AndroidTest 资源链接失败	resource xml/network_security_config_debug not found
3	APNetReceiver 缺少 android:exported	多个 library 模块在 AndroidTest Manifest 合并时失败

        这里我觉得比较有价值的是，它没有只盯着某一条报错，而是把错误背后的关系串起来了。比如 Facebook SDK 的重复类，不是简单“删一个包”就能解决，它追到了         login_base/build.gradle 里用了：

        api "com.facebook.android:facebook-login:latest.release"

  latest.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-stdlib：

api("com.facebook.android:facebook-login:15.2.0") {
    exclude group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib'
}

        同时在根 build.gradle 里补了一层版本约束，统一 Kotlin stdlib：

allprojects {
    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.xml

   app_* 也做同样处理。这样 Manifest 里始终引用 @xml/network_security_config，具体用哪份资源交给 Android 的 source set 合并机制来决定，逻辑更直观。

3.3 APNetReceiver：Android 12+ 的 exported 要求

        另一个批量报错来自 com.aipai.netmonitorsdk.receiver.APNetReceiver。它在第三方 SDK 的 Manifest 中声明了 intent-filter，但没有写 android:exported。Android 12 之后这类组件必须显式指定 exported，否则 Manifest merger 会失败。

        AI 先在 common 模块里加了覆盖声明：

<receiver
    android:name="com.aipai.netmonitorsdk.receiver.APNetReceiver"
    android:exported="true"
    tools:replace="android:exported">
    <intent-filter>
        <action android:name="android.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:allowBackup="true"
    tools:replace="android:allowBackup">

4.3 Guava ListenableFuture 重复

  upload 模块中 AWS SDK 传递依赖带来了 guava:18.0，同时又有 listenablefuture:1.0，产生重复类。AI 对 AWS 依赖加了 exclude：

implementation(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、资源问题修完后，再 Rebuild，upload 模块又冒出一个 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 是 24，Android 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.xml	332	315
audio_extract_normal_bg.xml	360	0
common_color_fb2055_13_bg.xml	360	0

        其中 332 肯定不合法；360 虽然数学上等于 0，但在部分系统实现里也会抛异常。修改后重新 Make Project，再 Run，App 终于能正常进入首页。

---

八、整个流程回顾

        这次不是一次性修完，而是一步一步推进：

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、安装、运行这条链路逐步跑通。