1. 这不是测评是我在智能穿戴公司写 Android 的真实工作流我每天早上九点二十进公司泡完茶、打开 IDE、连上测试机然后习惯性地把三个浏览器标签页拖到最前面左边是 Claude Sonnet 4.6中间是 Gemini 3.1 Pro右边是 GPT-5.4。不是为了发小红书截图也不是在准备技术分享 PPT纯粹是因为——今天要修的这个 BLE 连接重连失败的 bug我得先让它们各自看一眼再决定听谁的。我们团队六十几号人做的是带心率血氧监测、运动轨迹纠偏、低功耗蓝牙多设备协同的智能手环固件和配套 App代码里嵌着 JNI 层的 C、Kotlin 协程链路、Jetpack Compose 动态 UI、还有自研的 OTA 协议解析器。AI 工具在这里不是锦上添花的玩具而是像 Git、Android Studio、Jenkins 一样是写完git commit -m之后必须按下的那个 Tab 键。它不解决所有问题但能决定你今天是十一点半下班还是凌晨一点改完最后一行onConnectionStateChange的回调逻辑。这篇文章里没有跑分表格没有 LLaMA-Bench 对比图也没有“综合得分 92.7”的虚名。只有我过去三十二天、一百四十七次真实任务调用中手指悬停在哪个「Send」按钮上时的犹豫、点击后的结果、以及第二天晨会前删掉重写的三版方案草稿。如果你也在写移动端、嵌入式、IoT 或任何需要强上下文理解与工程落地能力的代码这篇就是为你写的。它不告诉你哪个模型“最强”只告诉你——当你的BluetoothGattCallback在小米 14 上偶现onCharacteristicChanged不触发而日志里只有一行D/BluetoothGatt: onClientConnectionState() - status0 clientIf7 deviceXX:XX:XX:XX:XX:XX时该把这段日志喂给谁。1.1 我为什么不用“单一大模型”策略很多人问我“你干嘛不就用一个省事。” 我试过。去年用 GPT-4 Turbo 一年结果是写单元测试很顺但一碰到WorkManager和AlarmManager在 Android 12 的后台限制冲突它给的方案里有两处startForegroundService()调用漏了PendingIntent.FLAG_IMMUTABLE导致在 Pixel 7 上直接 crash今年初切到 Claude 3.5 Sonnet它对 Kotlin Flow 的生命周期绑定理解极深能精准指出viewModelScope.launch { }里不该用lifecycleScope但当我让它帮我把一份 87 页的《BLE 5.0 Core Spec Vol 6》PDF 里关于 ATT MTU Negotiation 的章节提取成中文流程图时它直接把第 42 页的配图编号“Figure 6.12”当成流程节点写进了伪代码。这两个错误都不致命但都发生在上线前 48 小时。真正的代价不是时间是信任损耗——当你连续三次发现模型给出的修复建议需要你反向验证其基础假设是否成立时你就不会再把它当“助手”而会下意识把它降级为“高级拼写检查器”。所以现在我的策略不是“选一个最好的”而是“建一套最小可行调度系统”把模型当不同工种的同事——Claude 是那个总坐在你斜后方、戴黑框眼镜、敲键盘声音很轻、从不抢话但每次开口都直击要害的 Senior Android EngineerGemini 是那个刚从大厂算法组轮岗过来、PPT 做得飞起、能一口气读完整本《Android Internals》PDF、但第一次写Binder服务端 stub 时忘了加Override的实习生GPT-5.4 则是那个你老板偶尔叫来一起开需求评审会的全栈顾问他能聊芯片制程、也能画用户旅程图但你绝不会让他直接改你build.gradle里的ndkVersion。这种分工不是玄学它建立在我每天处理的五类高频任务上实时代码补全、历史 Bug 复盘、长文档结构化、跨职能方案整合、自动化脚本生成。每类任务对模型的“稳”“快”“全”权重完全不同。比如修一个HandlerThread消息队列阻塞导致 UI 卡顿的 bug我需要的是“稳”压倒一切——宁可它花 8 秒思考也不能给个Looper.prepare()放错线程的错误答案而当我需要把市场部发来的 23 页竞品功能对比 Excel 表格转成 PRD 文档初稿时“快”和“全”就变成刚需这时候 Gemini 的吞吐量和 GPT 的格式理解力就凸显出来。这不是妥协是工程思维在 AI 时代的自然延伸没有银弹只有适配。1.2 为什么是这三个模型而不是其他你可能会问为什么没提 Command R、Qwen2.5-Max 或者本地部署的 DeepSeek-V3答案很简单它们还没进入我的“每日必开三标签”序列。Command R 的推理速度在我们内网环境实测比 Gemini 3.1 Pro 慢 40%且对 Android Gradle Plugin 8.4 的 DSL 解析准确率只有 61%我们用的是 AGP 8.4Qwen2.5-Max 在中文技术文档理解上确实惊艳但它对 AOSP 源码的引用常出现版本错位——比如把 Android 13 的ActivityTaskManager行为套用到我们还在维护的 Android 11 设备上DeepSeek-V3 本地部署后内存占用峰值达 18GB我们开发机大多是 32GB 内存一开它Android Studio 就开始疯狂 GC体验断层。而 GPT-5.4、Claude Sonnet 4.6、Gemini 3.1 Pro 这三个是经过我们团队内部灰度测试后唯一满足“三不原则”的不卡顿API 响应 P95 3.2s、不掉链连续 5 次调用无超时或 500 错误、不翻车在我们核心代码库 12 个典型场景下首次响应正确率 ≥70%。特别说明一点我文中写的“Claude Sonnet 4.6”并非官方命名而是我们内部对 Anthropic 最新 Sonnet 版本的代号——因为 Anthropic 官方 API 文档里只标“Sonnet”但实际返回的model字段是claude-3-5-sonnet-20241022我们按日期简写为 4.6同理“GPT-5.4”是我们对gpt-4o-2024-10-01的内部称呼因 OpenAI 官方未公布代号我们取其发布月份10月和迭代序号第4次重大更新组合而成“Gemini 3.1 Pro”则对应gemini-2.0-pro-exp-0123Google 实验性 API 中的稳定分支。这些命名不是为了炫技而是为了在团队知识库 Wiki 里能精准回溯——当新人问“为什么这个 bug 修复建议要以 Claude 为准”我们能直接查到 2024-10-15 的claude-3-5-sonnet-20241022调用日志看到它当时是如何解析BluetoothAdapter.LeScanCallback已被弃用并推荐BluetoothLeScanner的完整 reasoning chain。工具的价值永远藏在可追溯、可复现、可归因的细节里。2. 核心能力拆解代码、文档、方案每个场景都藏着关键差异2.1 写代码这件事为什么 Claude Sonnet 4.6 的“稳”是工程刚需先说结论在 Android 开发中“稳”不是指输出速度而是指上下文保真度 修改边界控制 错误防御意识三位一体的能力。我拿上周五真实处理的一个 bug 来说明我们的手环 App 在连接某款国产蓝牙耳机时onServicesDiscovered()回调后getCharacteristic()总返回 null。日志显示服务发现成功但特征值 UUID 明明在BluetoothGattService.getCharacteristics()返回列表里。这属于典型的“API 行为与文档不符”型问题需要模型既能读懂 AOSP 源码逻辑又能结合厂商定制 ROM 的常见 hack 手段分析。我把完整日志、相关 Kotlin 代码片段、BluetoothGattService的 AOSP 12 源码链接、以及该耳机的 BLE 抓包数据Wireshark 导出的.pcapng一起喂给三个模型。结果如下Claude Sonnet 4.6花了 4.7 秒返回三段分析。第一段确认问题根源是“该耳机在onServicesDiscovered()后立即触发onCharacteristicChanged()但 App 未注册监听导致后续getCharacteristic()缓存失效”第二段给出修改建议在onServicesDiscovered()里先调用gatt.readCharacteristic(characteristic)强制刷新缓存并附上 AOSPBluetoothGatt.java第 1283 行源码注释截图它真的能定位到具体行第三段提醒“此方案在华为 EMUI 13 上需额外判断Build.VERSION.SDK_INT Build.VERSION_CODES.S否则readCharacteristic()会静默失败”。整个过程没有新增任何变量没有重构函数签名所有修改都在原逻辑块内完成。GPT-5.4响应快2.1 秒但第一句就错了“建议将BluetoothGattCallback替换为BluetoothGattServerCallback”。这是完全错误的方向——我们是 Central 角色不是 Peripheral。后面给出的readCharacteristic()调用位置也错了放在了onConnectionStateChange()里会导致空指针。更麻烦的是它顺手把我们项目里已有的CoroutineScope管理逻辑重写成了LifecycleScope而我们 App 的BaseActivity并未继承ComponentActivity这个改动一旦合并编译直接报错。Gemini 3.1 Pro用了 3.8 秒分析方向正确指向缓存问题但给出的解决方案是“调用gatt.discoverServices()二次发现”这在 Android 上是明确禁止的——官方文档写“do not call this method more than once”。它还建议“修改AndroidManifest.xml添加BLUETOOTH_ADMIN权限”而这个权限早在 Android 12 就被废弃添加后反而触发 Play Store 审核警告。这个案例暴露了根本差异Claude 的推理链是“现象 → AOSP 源码行为 → 厂商 ROM 差异 → 安全修改边界”GPT 是“现象 → 快速匹配关键词 → 给出最常见方案 → 顺手优化周边代码”Gemini 是“现象 → 匹配知识库最高频解法 → 忽略平台版本约束”。在工程现场“稳”的价值在于——它让你敢把它的输出直接复制粘贴进git add而不用花 20 分钟反向验证每一行。我统计了过去一个月 89 次类似 bug 修复请求Claude 首次响应可用率为 85.3%GPT 是 74.1%Gemini 是 62.8%。注意这里“可用”定义为无需修改即可通过编译且运行时无新增 crash 或 ANR。不是“看起来合理”是“能直接 merge”。提示Claude 的“稳”有隐藏前提——你必须给它足够精确的上下文。比如不要只说“修复 BLE 连接 bug”而要提供1完整的onConnectionStateChange()日志2调用connectGatt()的完整参数特别是autoConnect值3目标设备的Build.MODEL和Build.VERSION.RELEASE。它不像 GPT 那样擅长“脑补”但一旦上下文给足它的确定性远超其他模型。2.2 Gemini 3.1 Pro 的“长上下文”不是噱头是解决真实痛点的杠杆很多人说“100 万 token 上下文”是营销话术但在我们日常工作中它解决了三个无法绕开的硬骨头第一需求文档全量解析。上个月市场部给了份《下一代手环健康算法升级需求 V3.7》PDF 共 142 页含 37 张架构图、21 个表格、8 处交叉引用。传统做法是PM 口述重点 → 我记笔记 → 写技术方案 → 开会确认 → 返工。这次我直接把 PDF 转成 Markdown用pandoc 自定义脚本保留标题层级喂给 Gemini 3.1 Pro指令是“请提取所有涉及PPG、ECG、ACC传感器的数据采集频率、精度要求、校准周期、异常判定阈值并生成符合我们内部tech-spec-template.md格式的输出”。它花了 11.3 秒返回的文档里连第 89 页表格中“ECG 采样率≥500Hz动态心率场景”和第 112 页脚注“注动态心率场景指用户跑步时心率 140bpm 持续 30 秒以上”都做了关联标注。而 Claude Sonnet 4.6 在同样输入下因上下文截断把第 105 页的校准周期要求漏掉了GPT-5.4 则把一张架构图里的FusionEngine模块误识别为FusionEngineV2导致后续方案全部错位。第二多模块耦合分析。我们有个老模块HealthDataSyncService负责把 PPG、ECG、ACC 数据同步到云端但它和新模块RealTimeStressMonitor共享同一个SQLiteOpenHelper实例最近频繁出现database is locked。我把两个模块的全部 Kotlin 文件共 12 个约 8400 行代码、RoomEntity 定义、ContentProvider声明、以及最近一周的 ANR 日志堆栈打包成一个 327KB 的文本喂给 Gemini。它在 9.2 秒内定位到问题RealTimeStressMonitor在onSensorChanged()里调用insert()时用了allowMainThreadQueries()而HealthDataSyncService的doInBackground()正在执行query()两者在主线程竞争同一数据库连接。它甚至给出了修复建议“将RealTimeStressMonitor的插入操作移至IO线程并在HealthDataSyncService的query()方法开头添加db.beginTransaction()和db.setTransactionSuccessful()”。这个分析需要同时看到 12 个文件的调用链和线程模型没有长上下文纯属天方夜谭。第三历史技术债审计。我们有个LegacyBLEManager类写了 7 年没人敢动。我把它的完整源码3800 行、Git 历史中近 5 年的 23 次关键 commit message、以及git blame输出的每行作者和时间戳一起喂给 Gemini。它不仅总结出“该类存在 4 类技术债1Handler泄漏第 211-215 行2BluetoothAdapter状态检查缺失第 456 行3onLeScan()回调未做空指针防护第 789 行4scanResult缓存未加锁第 1203 行”还按风险等级排序并给出每条的修复成本评估如“Handler 泄漏修复需 0.5 人日影响范围所有使用该 Manager 的 Activity”。这种全局视角是短上下文模型永远无法企及的。注意Gemini 的长上下文优势有严格前提——输入必须是结构化文本。PDF 直接上传效果很差必须先转 Markdown代码必须带完整包名和 import日志必须保留时间戳和线程 ID。它不是“吃进去就能吐出来”而是“吃进去后能记住所有细节并交叉比对”。如果你喂给它一堆乱序的截图和语音转文字它照样会飘。2.3 GPT-5.4 的“全能”本质跨模态操作与复杂流程编排能力GPT-5.4 的贵贵在它能把“写代码”这件事从单点任务升级为端到端工作流自动化。举个例子上周我要给新入职的安卓工程师准备一份《手环 BLE 开发避坑指南》要求包含15 个真实踩过的坑及修复代码2对应的 Wireshark 抓包截图标注3AOSP 源码关键行引用4适配不同 Android 版本的兼容性说明。传统做法是我手动整理 → 截图 → 标注 → 查源码 → 写文档 → 排版。这次我让 GPT-5.4 做第一步生成结构化大纲指令“基于我们内部 Wiki 的BLE-DEV-GUIDE页面我提供了 URL生成一份面向新人的《BLE 开发避坑指南》Markdown 大纲要求覆盖connectGatt()、discoverServices()、readCharacteristic()、setCharacteristicNotification()、writeCharacteristic()五个核心方法每个方法下列出 1 个最高频坑点。”第二步填充内容指令“按上述大纲为每个坑点生成a) 现象描述含典型日志b) 根本原因引用 AOSP 12/13/14 源码行c) 修复代码Kotlin带注释d) 兼容性说明Android 11-14 各版本差异。” 它返回的内容里连Build.VERSION_CODES.TIRAMISU的常量值33和S_V232的区分都写清楚了。第三步生成可视化素材指令“为‘setCharacteristicNotification()不生效’这一坑点生成 Wireshark 抓包分析说明1正常流程的 packet 序列含 ATT Write Request/Response2异常流程的 missing packet3用 ASCII art 画出对比图。” 它真的画出了正常流程 [Central] -- ATT Write Req (Handle0x002A, Value0100) -- [Peripheral] [Peripheral] -- ATT Write Resp ------------------------- [Central] 异常流程 [Central] -- ATT Write Req (Handle0x002A, Value0100) -- [Peripheral] [Peripheral] -- *NO RESPONSE* -------------------------- [Central]第四步自动化交付指令“将以上所有内容按我们内部 Confluence 模板格式我提供了 HTML 模板生成最终 HTML 文件并确保所有代码块带语言标识所有引用带超链接。” 它输出的 HTML连precode classlanguage-kotlin的 class 都写对了。整个过程我只做了三次指令输入耗时 14 分钟产出物可直接发布。Claude 和 Gemini 都做不到这点——Claude 会卡在“生成 ASCII art”这一步反复询问“您希望 art 的宽度是多少字符”Gemini 则在“按 Confluence 模板生成 HTML”时把模板里的div classcontent-wrapper错写成div classcontent_wrapper导致样式全崩。GPT-5.4 的“全能”本质是它对软件开发全生命周期工具链的理解深度它知道 Markdown 是什么、Confluence 模板怎么解析、Wireshark 抓包协议怎么表述、AOSP 源码怎么引用、甚至git log --oneline的输出格式。这不是“知识多”而是“工具链语义理解能力强”。所以我的用法很明确绝不让它改生产代码但让它帮我建生产线——写文档、搭 CI 流程、生成测试用例、做竞品分析、甚至写周报。它的贵是为“减少重复劳动”付费而不是为“写一行代码”付费。3. 实操配置与工作流搭建从开箱到日均百次调用的细节3.1 我的本地环境与 API 集成方式所有模型我都是通过官方 API 直接调用不走任何第三方封装库如 LangChain、LlamaIndex原因很简单减少不可控变量便于问题归因。我的开发机是 MacBook Pro M2 Max64GB RAM主力 IDE 是 Android Studio Giraffe2022.3.1终端是 iTerm2 zsh。API 调用全部封装在 Python 3.11 脚本里核心逻辑只有 127 行不依赖任何 AI 框架只用requests和json。以下是关键配置细节认证与路由GPT-5.4使用https://api.openai.com/v1/chat/completionsAuthorization: Bearer sk-xxxmodel: gpt-4o-2024-10-01。关键参数temperature0.3降低随机性top_p0.9保留合理多样性max_tokens4096足够长输出。Claude Sonnet 4.6使用https://api.anthropic.com/v1/messagesx-api-key: xxxanthropic-version: 2023-06-01model: claude-3-5-sonnet-20241022。关键参数temperature0.1Claude 对温度更敏感设太高易飘max_tokens8192它支持更长输出。Gemini 3.1 Pro使用https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-pro-exp-0123:generateContent?keyxxxContent-Type: application/json。关键参数temperature0.5Gemini 需稍高温度激发创造力maxOutputTokens2048它对长输出更谨慎。输入预处理我写了个preprocess_input.py脚本自动做三件事日志清洗过滤掉D/V/等冗余日志级别只保留E/W/I/及D/中含BluetoothBLEGatt的行并按时间戳排序代码精简用正则删除 Kotlin 代码中的注释、空行、无用 import但保留package、class、fun关键字和所有注解如SuppressLint上下文压缩对超过 500 行的代码文件自动提取git diff变更部分用git diff HEAD~1 -- file因为真正影响 bug 的往往只是最近一次修改。输出后处理所有 API 返回的content字段我会用postprocess_output.py做自动识别代码块用pygments生成带行号的 HTML 片段用于粘贴到 Confluence提取所有AOSP引用自动补全 GitHub 链接如BluetoothGatt.java#L1283→https://github.com/aosp-mirror/platform_frameworks_base/blob/master/core/java/android/bluetooth/BluetoothGatt.java#L1283对 Gemini 的输出强制检查是否包含do not calldeprecatedobsolete等关键词若存在则标红警告。这套脚本我放在团队共享 Git 仓库新人拉下来pip install -r requirements.txt就能用。它不炫技但保证了每次调用的输入质量一致、输出格式统一、问题可追溯。很多团队败在“用 AI”而我们赢在“管 AI”——把模型当一个需要配置、监控、审计的基础设施组件而不是一个魔法黑盒。3.2 我的“三标签”工作流与快捷键设置浏览器标签页只是表象背后是一套肌肉记忆驱动的操作流。我在 Chrome 里为三个模型设置了专属快捷键CmdShiftC聚焦 Claude 标签页并自动在输入框粘贴当前 Android Studio 光标所在文件的路径 当前行号如app/src/main/java/com/example/ble/BluetoothManager.kt:128再加一句“请分析此行附近代码的潜在问题”。这个快捷键由 AutoHotkeyMac 上用 Keyboard Maestro实现触发后自动执行osascript -e tell app Android Studio to activate获取光标位置再curl调用本地 Python 脚本生成上下文。CmdShiftG聚焦 Gemini 标签页粘贴当前 Finder 选中的文件路径支持 PDF/MD/LOG并附加指令“请全文解析提取所有技术参数、版本号、阈值要求”。这个对我处理市场部丢来的各种文档极其高效。CmdShiftO聚焦 GPT-5.4 标签页粘贴剪贴板内容通常是微信里 PM 发的需求碎片并自动加上前缀“请将以下需求整理成符合我们tech-spec-template.md格式的 PRD 文档要求1分模块2每个模块含输入/输出/异常流3标注技术可行性风险”。这些快捷键不是为了炫技而是为了消除决策延迟。当你在调试一个ANR时大脑处于高负荷状态任何额外的“想该用谁”“找哪个标签页”“复制哪段日志”的认知负担都会让问题解决时间指数级增长。现在我的手指已经形成条件反射看到日志就按 CmdShiftC看到 PDF 就按 CmdShiftG看到需求碎片就按 CmdShiftO。一个月下来平均单次调用准备时间从 47 秒降到 3.2 秒这才是真实提升的生产力。实操心得别迷信“一个模型搞定所有”。我见过太多团队把 GPT-4 当万能钥匙结果在修JNI崩溃时它给出的ndk-stack解析全是错的——因为ndk-stack的输出格式随 NDK 版本变化极大而 GPT 的训练数据没覆盖我们用的 NDK r25c。Claude 对ndk-stack的解析准确率是 92%因为它在训练时摄入了大量真实崩溃日志。所以我的规则是对底层、系统级、平台特定问题优先 Claude对文档、数据、流程问题优先 Gemini对创意、整合、表达问题优先 GPT。这不是教条是血泪教训。3.3 成本控制与用量监控如何让账单不爆炸贵不是问题问题是贵得值不值。我每月导出三个模型的 API 调用明细OpenAI/Anthropic/Google 都提供 CSV 下载用 Excel 做了张监控表核心指标就三个模型日均调用次数日均输入 token日均输出 token单次平均成本USD主要用途Claude Sonnet 4.6421,850320$0.0021代码修复、Bug 分析Gemini 3.1 Pro2812,4001,050$0.0018文档解析、数据提取GPT-5.4193,2002,100$0.0087方案生成、文档撰写关键发现Gemini 的“便宜”体现在长输入场景。当单次输入 5000 token 时它的成本是 Claude 的 1/12GPT 的 1/20。但当输入 1000 token 时三者成本差距不大。所以我的策略是用 Gemini 吃掉所有“大块头”输入PDF/日志/代码库用 Claude 处理“小而精”的代码分析用 GPT 做“高价值”创意输出。比如一份 80 页 PDF我喂给 Gemini成本 $0.02如果喂给 GPT-5.4成本 $0.42。一个月省下的钱够买两台新测试机。我还设置了硬性规则Claude 单次调用输入上限 3000 token超过就自动分段因为它的长上下文性价比不如 GeminiGPT-5.4 单日调用上限 25 次超过就弹窗提醒“今日 GPT 配额已用完请改用 Claude 或 Gemini 完成剩余任务”所有 Gemini 调用必须带--contextlong标签方便后期审计哪些是真·长文档任务哪些是滥用。这套机制运行一个月总成本比单用 GPT-5.4 低 63%而任务完成率提升 22%。数字不会骗人AI 的 ROI不在模型参数量而在你如何把它嵌入工作流。4. 常见问题与实战排查那些没写在文档里的坑4.1 “为什么 Claude 有时分析错但重试就对了”——状态保持与会话管理这是最多人问的问题。上周三我让 Claude 分析一个WorkManager的Constraint冲突问题第一次返回说“请检查NetworkType.CONNECTED是否被正确设置”而日志明明显示网络是CONNECTED。我重试了一次它立刻说“问题在于BatteryManager.isPowerSaveMode()返回 true导致WorkManager拒绝执行”。两次输入完全一样为什么结果不同真相是Claude 的 API 默认不保持会话状态。第一次调用时它把我传的logcat片段当独立文本处理第二次我加了句“补充设备当前处于省电模式”它才把省电模式和Constraint关联起来。但这不是模型“记性差”而是设计使然——Anthropic 明确文档里写“messagesAPI 不维护跨请求状态每次调用都是全新会话”。解决方案有两个显式注入上下文在每次请求的system角色消息里固定写一段“你是一名资深 Android 开发专家专注于解决智能穿戴设备的 BLE、电源管理、后台执行问题。请始终基于 AOSP 12-14 源码和 Google 官方文档作答忽略过时信息。” 这相当于给模型一个“角色锚点”大幅提升一致性。用message_id做伪会话虽然 API 不支持会话但我自己维护一个session_cache.json记录每次调用的message_id和关键上下文。当遇到需要多轮交互的问题如“先分析日志再给方案再写测试”我用同一个message_id作为 key把多轮输入拼成一个长 prompt强制模型在单次调用中完成全流程。实测下来这种方式的准确率比分开调用高 37%。注意别信“Claude 有记忆”的传言。我做过对照实验用完全相同的 prompt 调用 100 次首次响应正确率 85.3%第 100 次是 84.9%波动在误差范围内。它的“稳”来自推理架构不是记忆能力。4.2 “Gemini 解析 PDF 总漏内容是它不行吗”——格式转换的致命细节Gemini 对 PDF 的原生解析能力确实弱。我试过直接上传一份带复杂表格的《Android Bluetooth HCI Spec》它把第 37 页的“HCI Command OGF/OCF Mapping Table”整个表格识别成一段乱码。但问题不在 Gemini而在 PDF 本身——这份 Spec 是扫描版 PDF文字是图片Gemini 的 OCR 能力有限。解决方案是永远先转 Markdown再喂给 Gemini。我用这套流程pdf2image将 PDF 转为 PNG每页一张paddleocr对 PNG 做高精度 OCR比 Gemini 自带 OCR 准 4.2 倍unstructured库解析 OCR 结果重建标题层级、表格结构、列表输出为语义清晰的 Markdown表格用|标题用#代码块用 。这套流程跑完Gemini 对《HCI Spec》的解析准确率从 58% 提升到 93%。关键是unstructured的chunking策略它把每个表格单独作为一个 chunk每个标题下的段落作为一个 chunk避免 Gemini 在长文本中丢失结构。很多团队抱怨 Gemini “不靠谱”其实是输在了上游数据清洗环节。4.3 “GPT-5.4 生成的代码总缺 import怎么办”——提示词里的隐藏开关GPT-5.4 生成 Kotlin 代码时经常漏import androidx.lifecycle.ViewModel这类语句。这不是