MIUI 遗留代码迁移：把 Codex 接到 TaoToken 对照 Flutter/Rust 重写的完整配置
小米分阶段清除 MIUI 时代积累的遗留代码这件事，对做 Android 系统层和跨端迁移的开发者来说，是一个很典型的"存量代码治理"样本。HyperOS 3.1 部分模块已经移除 MIUI SDK，核心系统应用开始用 Flutter 工具链和 Rust 重写，HyperOS 4 目标是"零遗留"。但真到自己动手梳理旧 SDK 调用点、判断哪些模块可以先迁、哪些必须保留兼容层时，靠人肉 grep 效率很低。这篇就把执行工具 Codex 接到 TaoToken（官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end ）上，让它来辅助做调用点梳理和迁移对照，配置和验证一次讲清。
一、原问题与场景：MIUI 遗留代码迁移到底卡在哪
小米这次迁移的痛点其实有三个层次，理解清楚才能知道 Codex 该干什么。
第一层是旧 SDK 依赖的隐蔽性。MIUI 时代积累的代码不是集中在一个仓库里，而是散落在系统应用、框架层、甚至第三方适配代码中。很多 MIUI SDK 的调用是隐式的，比如通过反射、通过资源 ID 引用、通过私有 API 间接调用。你 grep 一个类名可能只找到一半，另一半藏在编译产物或者动态加载的 dex 里。
第二层是模块化迁移的边界判断。HyperOS 3.1 的做法是引入原生 HyperOS SDK 的同时保留 MIUI SDK 作为过渡，这意味着同一个功能可能有两套实现并存。哪些模块可以整体切到 Flutter + Rust，哪些需要先做适配层，哪些因为旧设备兼容必须保留——这个判断需要对照代码结构和调用关系来做，不是拍脑袋能定的。
第三层是旧设备兼容的约束。原文提到老设备无法单独安装新应用获取新特性，这意味着迁移后的代码路径必须考虑降级方案。Flutter 渲染层和 Rust 逻辑层在旧设备上的表现，和 MIUI SDK 老路径的行为差异，需要在迁移前就标出来。
Codex 在这条链路里的定位是：帮你快速梳理调用点、生成迁移对照表、标注风险模块，而不是替你做重写决策。重写本身还是人来定，但前期调研的体力活可以交出去。
二、TaoToken 前置：注册、拿 Key、明确边界
在把 Codex 接进来之前，先把 TaoToken 这边的准备工作做完。
打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 注册账号，然后在控制台创建 API Key。这个 Key 就是后面 Codex 配置里要填的凭证。TaoToken 在这里提供的只有两样东西：API Key和Base URL。它不替 Codex 做 Flutter/Rust 重写，也不参与你的代码逻辑，只是一个让 Codex 能正常发请求的通道。
Base URL 是https://taotoken.net/api，注意两点：不要加/v1，不要带 UTM 参数。这两个是配置时最容易出错的地方，后面排查章节会展开。
Key 的管理入口在 API Keys 页面，如果后面要换 Key 或者查用量，从这里进。接入相关的文档在接入文档页，配置格式有疑问时对照一下。
三、可复制配置：Codex 的 config.toml 怎么写
Codex 的配置走config.toml，不是 Claude Code 那套settings.json/ANTHROPIC_*环境变量，别搞混。下面是可以直接复制的配置片段：
# ~/.codex/config.toml [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY" [profiles.miui-migration] model_provider = "taotoken" model = "YOUR_MODEL_ID"然后在 shell 里导出 Key：
export TAOTOKEN_API_KEY="YOUR_API_KEY"几个关键点：
base_url严格写https://taotoken.net/api，结尾不要加斜杠，不要加/v1。env_key指向的环境变量名自己定，但要和 export 的一致。model填你在 TaoToken 侧确认可用的模型 ID，不要凭记忆写。- profile 名字
miui-migration只是示例，你可以按项目分多个 profile。
如果你用的是 CLI 方式而不是直接改配置文件，对应的命令是：
npm i -g @taotoken/taotoken taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m YOUR_MODEL_ID注意-u后面跟的就是 Base URL，同样不要加/v1。
四、验证请求：先跑通通道再谈迁移
配置写完不要直接上大任务，先跑一次最小请求验证通道。
最简单的验证方式是在 Codex 里发一个短 prompt，比如让它读一个文件并总结：
读取 app/src/main/java/com/example/legacy/LegacySdkBridge.java， 列出其中所有对 MIUI SDK 的 import 和直接调用点。如果通道正常，你会看到 Codex 返回结构化的调用点列表。如果报错，先看错误类型：
- 401 / 403：Key 没填对，或者环境变量没生效。检查
echo $TAOTOKEN_API_KEY是否有值。 - 404：Base URL 写错了，大概率是加了
/v1或者多了斜杠。 - 超时 / 连接失败：网络层问题，确认 Base URL 是
https://taotoken.net/api而不是别的域名。
通道跑通之后，再让它做真正的迁移对照任务。比如：
对照 HyperOS 3.1 的迁移思路，分析当前模块中： 1. 哪些 MIUI SDK 调用点可以替换为 HyperOS SDK； 2. 哪些需要保留兼容层； 3. 哪些模块适合用 Flutter 重写 UI、Rust 重写逻辑。 输出一张对照表，标注每个调用点的迁移风险和依赖关系。这一步的输出就是你要的迁移调研底稿。Codex 不会替你做决定，但它能把散落的调用点聚合成一张可读的表，这比人肉翻代码快得多。
五、本篇常见错排查
错误一：Base URL 加了/v1
这是最高频的错。Codex 的配置里base_url写https://taotoken.net/api就够了，加/v1会导致路径拼接错误，表现为 404 或者返回空。检查你的config.toml，确认没有多余的路径段。
错误二：Key 没导出到当前 shell
config.toml里写了env_key = "TAOTOKEN_API_KEY"，但 shell 里没 export，Codex 启动时会拿不到 Key。验证方法：在同一个终端里echo $TAOTOKEN_API_KEY，有输出才算生效。如果你在 IDE 里用 Codex，注意 IDE 的环境变量可能和终端不一致，需要在 IDE 的启动配置里单独设置。
错误三：profile 没激活
config.toml里定义了[profiles.miui-migration]，但启动 Codex 时没指定 profile，它会走默认配置。确认你的启动命令带了--profile miui-migration或者对应的参数。
错误四：模型 ID 写错
model字段填的 ID 必须是 TaoToken 侧确认可用的。如果你不确定，先去模型对话页面确认一下当前可用的模型列表，再填到配置里。填错的表现是请求返回模型不存在的错误。
错误五：把 Codex 当成重写工具
Codex 在这条链路里的角色是辅助梳理和对照，不是自动重写。如果你期望它直接输出可编译的 Flutter/Rust 代码，那预期就错了。它的价值在于把 MIUI SDK 调用点、模块依赖、迁移风险整理清楚，重写决策和代码质量还是人来把控。
六、语义一致 CTA
如果你在配置 Codex 接 TaoToken 的过程中遇到 Key 或 Base URL 的问题，先去 API Keys 页面确认 Key 状态，再对照接入文档检查配置格式。通道跑通之后，想验证模型是否正常工作，可以在模型对话页面发一条测试请求。如果你打算把这条链路长期用在 MIUI 迁移或者类似的存量代码治理项目上，Coding Plan 更适合持续性的编码任务，不用每次单独配 Key。
配置这件事本身不复杂，难的是把 Codex 的输出和实际的迁移决策对上。先把通道跑通，再让它帮你梳理调用点，最后人来定迁移边界——这个顺序不要反。
