Android Bench 正式发布 | 专为 Android 开发打造的 LLM 评测基准与 TaoToken 配置骨架-开发者社区

1. Android Bench 发布后，Android 开发者真正要解决的问题

Android Bench 是 Google 官方针对 Android 开发场景推出的 LLM 评测基准，它用真实 GitHub Android 库里的任务来考察模型能力，覆盖版本升级破坏性变更、可穿戴设备网络连接、Jetpack Compose 迁移等场景，通过单元测试或插桩测试验证结果。首批结果显示各模型任务完成率在 16% 到 72% 之间，差距相当大。这意味着一个现实问题：你在 Android Studio 里随手选的模型，可能根本搞不定你项目里的 Compose 迁移或 AGP 升级。

对 Android 开发者来说，Android Bench 的价值不是看排行榜热闹，而是把它变成自己团队的选型依据。你需要一套可复制的流程：在 Android Studio 和 Jetpack Compose 项目里接入 LLM 评测，用统一的 Key/API 通道跑通一次基准调用，再根据结果决定长期用哪个模型。这篇就交付这套骨架，包括 settings.json、config.toml 配置和一次可验证的评测请求。

适合谁：正在用或准备用 AI 辅助写 Compose 的 Android 工程师、需要给团队选 LLM 的技术负责人、想把 Android Bench 任务接进 CI 的 DevOps。下面从接入通道开始，一步步跑通。

2. TaoToken 前置：统一 Key 与 API 通道

Android Bench 本身是评测方法和数据集，真正跑评测时你还是要调用某个 LLM。如果每个模型都单独申请 Key、单独改 base URL，Android Studio 里的配置会变得很难维护。TaoToken 在这里的角色是统一通道：一个 Key 走多个模型，base URL 固定，Android Studio、命令行、CI 脚本共用同一套配置。

你需要先拿到 API Key。打开 https://taotoken.net/api-keys 创建，复制出来保存好。注意这个 Key 只在创建时完整显示一次，丢了就重新生成。控制台在 https://taotoken.net/console ，可以看调用量和余额。

接入地址分两个：官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 基址是 https://taotoken.net/api ，注意 API 地址后面不加 UTM 参数，否则部分客户端会把查询串拼进请求路径导致 404。

注意：Android Studio 的 AI 配置里填 base URL 时，通常要求以/v1结尾或由客户端自动补全。TaoToken 的 API 基址填https://taotoken.net/api，如果客户端报 404，先检查是不是多拼了斜杠或少了版本段。

模型选择上，Android Bench 首批里 Gemini 3.1 Pro 平均分最高，Claude Opus 4.6 紧随其后。你可以先在 https://taotoken.net/models 用对话方式快速对比这两个模型对 Compose 代码的理解，再决定哪个进你的评测流水线。模型对话入口：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 。

3. 可复制配置：settings.json 与 config.toml 骨架

Android Studio 的 AI 助手配置和命令行评测工具的配置格式不同，这里给两份骨架。先说明：Android Studio 不同版本对 AI 配置的字段名有差异，下面以通用结构为准，你按自己版本微调字段名，值不变。

3.1 Android Studio 侧 settings.json 骨架

Android Studio 的配置一般放在用户目录下的配置文件夹里，Windows 是%APPDATA%\Google\AndroidStudio<版本>\options，macOS 是~/Library/Application Support/Google/AndroidStudio<版本>/options。新建或修改settings.json：

{ "aiAssistant": { "provider": "openai-compatible", "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的TaoTokenKey", "model": "gemini-3.1-pro", "timeoutSeconds": 120, "maxTokens": 8192, "temperature": 0.2 }, "androidBench": { "enabled": true, "taskSource": "https://github.com/android-bench/android-bench", "verifyWith": ["unitTest", "instrumentedTest"], "reportPath": "./build/android-bench-report.json" } }

几个参数说明：temperature设 0.2 是因为评测任务要的是稳定复现，不是创意；maxTokens给 8192 是因为 Compose 迁移任务经常要输出整段文件；timeoutSeconds给 120 是因为复杂任务推理时间长，默认 30 秒容易断。

3.2 命令行评测工具 config.toml 骨架

如果你要把 Android Bench 任务接进 CI，用命令行工具更合适。下面这份config.toml放在项目根目录：

[provider] name = "taotoken" base_url = "https://taotoken.net/api" api_key = "sk-你的TaoTokenKey" model = "claude-opus-4.6" [bench] dataset = "android-bench" tasks = ["compose-migration", "agp-upgrade", "wear-network"] verify = ["unit", "instrumented"] concurrency = 2 retry = 2 [report] format = "json" output = "./build/android-bench-report.json" include_traces = true

concurrency设 2 是保守值，因为插桩测试要起模拟器，并发太高会互相抢资源。retry设 2 是因为网络抖动或模型偶发超时，重试能提高评测稳定性。include_traces打开后报告里会带模型推理轨迹，方便你人工审查它是不是真的在推理而不是猜。

提示：两份配置里的 Key 都不要提交到 Git。用环境变量TAOTOKEN_API_KEY注入，配置文件里写api_key = "${TAOTOKEN_API_KEY}"，大多数工具支持这种占位符。

4. 验证请求：跑通一次 Android Bench 评测调用

配置写完，先别急着跑全量。用一条最小请求验证通道是否通。下面用 curl 模拟一次评测调用，任务是一个 Compose 迁移片段：

curl -X POST https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gemini-3.1-pro", "messages": [ { "role": "system", "content": "你是 Android 开发助手，只输出可编译的 Kotlin 代码，不要解释。" }, { "role": "user", "content": "把下面这段基于 View 的布局迁移到 Jetpack Compose，保持原有交互逻辑：\n\n<LinearLayout ...>...</LinearLayout>" } ], "temperature": 0.2, "max_tokens": 4096 }'

成功的话你会拿到一个 JSON，choices[0].message.content里是 Compose 代码。把这段代码贴进你的 Compose 项目，跑一次./gradlew :app:testDebugUnitTest，看单元测试是否通过。这就是 Android Bench 的核心验证逻辑：模型输出代码，测试验证结果。

如果你更想先看模型对 Android 问题的理解，不写代码，用模型对话入口快速试：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 。输入一个 AGP 升级报错，看它能不能定位到namespace缺失这类常见问题。

跑通单条后，用命令行工具跑全量：

android-bench run --config ./config.toml --task compose-migration

结果会写到./build/android-bench-report.json。打开看passRate字段，这就是你这个模型在你选定任务上的完成率。拿 Gemini 3.1 Pro 和 Claude Opus 4.6 各跑一遍，对比 passRate 和 trace 里的推理质量，再决定长期用哪个。

5. 本篇常见错排查

5.1 404 或 base URL 拼接错误

最常见的是 base URL 多拼或少拼。TaoToken 的 API 基址是https://taotoken.net/api，客户端通常会自动补/v1/chat/completions。如果你在配置里写成https://taotoken.net/api/v1，有些客户端会拼成/api/v1/v1/...导致 404。检查方法：把 base URL 单独用 curl 测一下https://taotoken.net/api/v1/models，能返回模型列表就说明基址对。

5.2 401 或 Key 无效

先确认 Key 有没有复制完整，前后有没有空格。然后确认请求头格式是Authorization: Bearer sk-xxx，不是Bearer: sk-xxx。如果 Key 是在环境变量里，用echo $TAOTOKEN_API_KEY确认变量真的注入了，尤其在 CI 里容易漏。

5.3 评测任务超时

Compose 迁移这类任务输出长，默认超时容易断。把timeoutSeconds提到 120 以上，maxTokens提到 8192。如果还是断，检查是不是concurrency太高导致模拟器排队。插桩测试建议concurrency = 1。

5.4 模型输出不是纯代码

评测要求模型只输出可编译代码，但有些模型会加解释。在 system prompt 里明确写「只输出 Kotlin 代码，不要 markdown 代码块标记，不要解释」。如果还不行，在评测脚本里加一层后处理，剥掉 ```kotlin 标记再送进编译器。

5.5 报告里 passRate 为 0

先看 trace，确认模型是不是真的在改代码，还是只输出了「我建议你……」这类话。如果是后者，说明 system prompt 没约束住。另外确认测试命令真的跑了，有些项目testDebugUnitTest需要先assembleDebug，漏了这步测试根本没执行。

6. 长期编码与 Agent 场景的接入选择

如果你只是偶尔对比模型，用模型对话入口就够了。但如果你要把 Android Bench 评测接进日常开发，比如每次 AGP 升级前先让模型跑一遍迁移任务，或者把 Compose 迁移做成 Agent 自动提交 PR，那就需要更稳定的通道和更高的调用额度。

长期编码和 Agent 场景建议用 Coding Plan，入口：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 。它适合高频调用、多模型切换、CI 集成的场景。接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面有各客户端的完整配置示例，包括 Android Studio、VS Code、命令行工具的字段对照。

如果你用 Claude Code 做 Android 项目的 Agent 开发，Anthropic 兼容通道的配置参考：https://taotoken.net/claude-code-anthropic?utm_source=taotoken_aicg_blog_end&utm_content=claude_code&utm_campaign=rewrite 。把 base URL 指向 TaoToken，Key 用同一个，就能在 Claude Code 里调用 Android Bench 评测过的模型。

最后给一个实操建议：Android Bench 的任务集是公开的，你可以把它 clone 下来，挑和你项目最像的 3 到 5 个任务，做成自己的回归测试集。每次换模型或升级模型版本，先跑这套小集，passRate 掉了就说明新模型在你的场景上退化了。这比看排行榜有用得多。