1. 旧 App 项目为什么值得用 TRAE + Doubao-Seed-Evolving 跑一遍
手里有一个 2019 年前后停更的视频剪辑 App 项目，多模块、接了广告 SDK、登录、支付、视频编辑、上传，Gradle 插件版本还停在 4.x。直接./gradlew assembleDebug，日志 140KB，BUILD FAILED后面跟着 22 个 failure。这种项目最麻烦的地方不是单个错误难改，而是错误之间互相咬：Facebook SDK 用latest.release拉到了新版本，把 Kotlin stdlib 顶到 1.8，然后 Manifest 合并、资源链接、native so 重复全跟着炸。
TRAE 是字节出的 AI IDE，支持接入自定义模型；Doubao-Seed-Evolving 是豆包面向 Coding 和 Agent 场景的持续迭代分支，特点是长上下文里能记住前面改过哪些文件、哪些依赖被 force 过。把这两个凑一起，再挂上 TaoToken 的统一 Key，就能在 Android Studio 旁边开一个能读构建日志、能改build.gradle、能顺着模块结构补 Manifest 的工程搭子。这篇就按我实际跑通的顺序，把 settings.json / config.toml 骨架、TaoToken 接入、逐步验证动作和踩过的坑一次写清楚，适合需要迁移或复现历史 Android 项目的开发者跟做。
2. 前置准备：TaoToken 统一 Key 与 TRAE 模型接入
TaoToken 在这里的角色是统一模型入口：一个 Key 同时给 TRAE、Coding Plan、模型对话用，不用在多个平台之间来回切。官网入口 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 基址是 https://taotoken.net/api （这个不加 UTM）。
拿 Key 的路径很短：进 console 建一个 API Key，复制出来。如果你后面要长期跑编码和 Agent 任务，直接看 Coding Plan 更划算；只是临时验证模型能力，用模型对话页面就够。接入文档在 doc 里，ClaudeCodeAnthropic 那条线也有单独说明，按需取。
注意：Key 只存在本地配置文件里，不要提交到 Git。旧项目往往有
.gitignore漏配的历史，先确认settings.json、config.toml所在目录被忽略。
TRAE 侧添加模型时，把 provider 指向 TaoToken 的 API 基址，模型名填Doubao-Seed-Evolving。这一步做完，TRAE 里的对话、代码补全、Agent 任务都会走这个 Key。
3. 可复制配置：settings.json 与 config.toml 骨架
TRAE 的模型配置分两层：一层是 IDE 级的settings.json，管 provider 和默认模型；一层是项目级的config.toml，管这个旧 App 项目专属的上下文和工具行为。两个文件都放在项目根目录下的.trae/里，跟着仓库走，换机器不用重配。
3.1 settings.json 骨架
{ "model.provider": "taotoken", "model.baseUrl": "https://taotoken.net/api", "model.apiKey": "${env:TAOTOKEN_API_KEY}", "model.name": "Doubao-Seed-Evolving", "model.contextWindow": 128000, "model.temperature": 0.2, "agent.maxIterations": 40, "agent.autoReadFiles": true, "agent.autoApplyPatch": false }几个参数值得说清楚。temperature压到 0.2，是因为旧项目排障要的是稳定复现，不是发散创意。agent.autoApplyPatch设成false，让模型先给 diff 我再决定是否落盘，避免它一口气改十几个文件后我找不到回滚点。contextWindow给到 128000，是因为 140KB 的构建日志加上多个build.gradle和 Manifest，上下文小了根本装不下。
Key 用环境变量注入，别写死在文件里：
export TAOTOKEN_API_KEY="sk-你的key"3.2 config.toml 骨架
[project] name = "legacy-video-editor" androidGradlePlugin = "4.2.2" kotlinVersion = "1.7.10" minSdk = 24 targetSdk = 33 [context] include = [ "**/build.gradle", "**/build.gradle.kts", "**/AndroidManifest.xml", "**/gradle.properties", "**/settings.gradle" ] exclude = [ "**/build/**", "**/.gradle/**", "**/node_modules/**" ] [tools] gradleTasks = ["assembleDebug", "lintDebug"] logFile = "build/reports/build-log.txt"include里把 Manifest 和所有build.gradle都圈进来，是因为旧项目的依赖冲突往往藏在某个 library 模块的build.gradle里，模型看不到就定位不到。exclude掉build/和.gradle/，避免上下文被编译产物撑爆。logFile指向构建日志，后面验证环节直接让模型读这个文件。
4. 逐步验证：从 22 个构建错误到真机跑通
配置就位后，验证不是一次 Build 就完事，而是按「归类 → 修核心 → Rebuild → 修连锁 → 装真机 → 抓闪退」这条链路走。下面每一步都给可复制的动作和预期结果。
4.1 第一轮：让模型先归类，别急着改代码
先把构建日志落盘：
./gradlew assembleDebug > build/reports/build-log.txt 2>&1然后在 TRAE 里发第一条指令，明确要求「只归类，不改代码」：
读取 build/reports/build-log.txt，搜索 FAILED、error、exception， 按模块和错误类型归类，输出一张表：错误类型 / 关键信息 / 涉及模块。 不要修改任何文件。预期结果是模型给出三类核心问题：Facebook SDK 重复类、AndroidTest 资源链接失败、APNetReceiver 缺android:exported。这一步的价值在于，它把 22 个 failure 收敛成 3 个根因，后面的修改才有顺序。
4.2 第二轮：修核心问题
Facebook SDK 从动态版本改固定版本，并排除传递进来的 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}" } } }network_security_config不再用resValue动态指定，改成按 build type 放各自的资源文件：
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.xmlManifest 里始终引用@xml/network_security_config，具体用哪份交给 source set 合并机制决定。
APNetReceiver 补exported声明：
<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模块加声明不够，router、upload、base_app、ipay-exposed、webview、downloadImpl这些模块的 Manifest 合并路径不一定经过common，得逐个补。让模型顺着模块结构扫一遍，比手工翻快得多。
4.3 第三轮：Rebuild 后处理连锁问题
继续 Rebuild，日志里会冒出新的What went wrong。native so 重复：
packagingOptions { pickFirst 'lib/*/libc++_shared.so' }allowBackup清单冲突：
<application android:allowBackup="true" tools:replace="android:allowBackup">Guava ListenableFuture 重复，对 AWS 依赖加 exclude：
implementation(rootProject.ext.dependencies.aws_s3) { exclude group: 'com.google.guava', module: 'listenablefuture' }4.4 第四轮：Kotlin 编译错误与 Run 按钮灰色
Gradle 层修完后，upload模块报 Smart Cast 错误：
e: CreateThumbManager.kt: (74, 42): Smart cast to 'FileOutputStream' is impossible, because 'out' is a local variable that is captured by a changing closure改成.use {}写法，既符合 Kotlin 习惯，也避免异常时漏关流：
runCatching { FileOutputStream(saveFile).use { out -> bitmap.compress(format, 100, out) out.flush() } }.onFailure { if (saveFile.exists()) saveFile.delete() }Make Project成功后 Run 按钮灰色，不是代码问题，是改了多个build.gradle后 IDE 需要重新 Gradle Sync。同步完设备识别正常，Run 恢复。
4.5 第五轮：真机闪退与完整 Logcat
装到 Android 10 真机后开屏闪退，Logcat 里全是 MIUI 和系统日志，没有明显 Java 崩溃栈。让模型提醒「导出完整日志再判断」，把完整 Logcat 存成文件再分析，抓到关键堆栈：
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)这是 drawable 资源兼容性问题，线性渐变的android:angle必须是 45 的倍数。项目里有几个资源写得不规范：
| 文件 | 原角度 | 修改后 |
|---|---|---|
| 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 正常进首页。
5. 本篇常见错排查
构建日志太大，模型读不完。先把日志落盘成文件，用include圈进上下文，别直接粘贴到对话框。140KB 的日志粘进去会截断，模型只能看到前半段。
Facebook SDK 版本选高了。第一次改到 16.0.0，Rebuild 时发现它引入 Kotlin 1.8.x stdlib，和项目 1.7.x 冲突。收敛到 15.2.0 并排除传递依赖才稳。动态版本latest.release在老项目里是定时炸弹，远端仓库一变，本来能构建的项目过段时间就炸。
Manifest 覆盖声明漏模块。APNetReceiver的exported只在common加不够，多模块项目的 Manifest 合并路径不唯一，得顺着依赖树逐个补。
Run 按钮灰色。改过build.gradle后必须 Gradle Sync，不是代码问题。设备连接状态也会影响，先确认adb devices能看到设备。
闪退日志不完整。系统日志混在 Logcat 前面，容易误判成系统版本不兼容。导出完整日志再分析，才能抓到GradientDrawable的angle异常。
Key 泄露风险。settings.json里用${env:TAOTOKEN_API_KEY}注入，别写死。旧项目的.gitignore往往漏配.trae/，先补上。
6. 接入与后续：按场景选对入口
排障和接入相关的配置，Key 在 API Keys 页面建，接入细节看接入文档，两条路径覆盖了 TRAE 挂模型和后续换工具的场景。如果你主要是验证 Doubao-Seed-Evolving 在旧项目排障上的表现，用模型对话页面直接试就行，不用先配 IDE。长期跑编码和 Agent 任务、需要多轮上下文不断链的，Coding Plan 更合适，token 消耗和工具调用都在一个池子里管。
这次跑下来，TRAE + Doubao-Seed-Evolving 在旧 App 项目上的价值不在「替你写几段代码」，而在「把长上下文里的错误、文件、修改历史串起来」。22 个构建错误、多模块 Manifest、Gradle 与 Kotlin 交叉问题、真机闪退，这些散在不同知识点里的坑，它能顺着上下文一路推下去。你不需要一开始就把所有问题说清楚，把真实日志、真实代码、真实现象给它，Build 到 Run 这条链路就能逐步跑通。
