用Claude Code交付移动应用的实战复盘

同样标着 Claude Opus 5.5，有人说半天干完一周的活，也有人抱怨每三题错两题。原文作者借移动应用 Ruzai（如在）的开发过程提出一个判断：差距经常来自任务怎么交代、工具怎么配置，以及人在哪些地方介入决策。

这篇值得读的地方，是把几次返工摊开了：UI 改了三轮，技术栈推倒重来，真机测试还误入了其他应用。不过，它提供的是一次项目复盘，足以借鉴工作方法，尚不足以证明模型能力几乎从来不是瓶颈。

为什么一句「不好看」能让 AI 连改三轮

Ruzai 让用户离开电脑后，仍能通过手机查看电脑上 AI 助手的对话、发送消息，并批准关键操作。按作者描述，从产品设计、UI、代码，到 GitHub Actions 构建 Android APK、推送 iOS 构建至 TestFlight，再到自托管 OTA 更新服务和 App Store 素材，几乎都由 Claude Code 中的 Opus 5.5 完成。

但第一版 UI 出来，作者只给了三个字：「不好看。」

模型先找来三套成熟配色，仍未过关；第二轮参考作者所称的 2026 年 Gemini App 改版，换成纯白或纯黑背景、无边框、大号问候语和悬浮胶囊输入框；第三轮去掉渐变，给出六种纯色图标，最终选定黑底白色「Z」。

中间还找到了一个容易误判的因素：截图来自 Windows 上的 headless Chrome，中文默认显示为 Microsoft YaHei。改用 Source Han Sans（Noto Sans SC）后，观感更接近手机上的 MiSans 和 PingFang。作者此前嫌弃的，有一部分其实是截图字体。

这里能拿走的经验很具体：评价需要变成约束。「以对话为中心，参考 ChatGPT，黑白配色，不用渐变」比「再高级一点」更容易执行。说不清风格时，提供参考截图也比反复打分有效。

作者把原因归结为「AI 没有审美偏好，只会给出大量设计的平均值」，这个解释偏概括。案例真正证明的是：模糊反馈留下了太大的猜测空间，而且验收环境会影响判断。

写得越快，越需要先确认方向

项目由两台电脑协作，一台负责服务端和移动端，另一台负责 Windows 客户端。两边的 AI 不共享记忆，靠仓库里的协议、API 和交接文档同步：一边编写并提交，另一边拉取、执行，再标记完成状态。

这套做法帮助他们完成了桌面端图标更新和移动中继接入。问题也出在文档：一次规格变更将移动端切到 uni-app x，模型照着写完整套代码、提交并修复问题，作者才意识到自己不接受对 DCloud 的依赖。按作者对项目方案的判断，推送、构建和 OTA 都会受其约束，于是又推倒重来，改用 React Native + Expo。

原文没有展开这些依赖的具体条件，因此不能直接推导出所有 uni-app x 项目都必须如此。但「执行前没有检查退出成本」这个教训成立。

后来作者试用 ByteDance 的 Lynx，希望一套代码覆盖 Android、iOS，并考虑未来的 HarmonyOS。原型能编译、连接服务端、展示对话，UI 却偏离了定稿。这次作者要求：先别写代码，先解释原因、提出方案，再实施。

测试还暴露了版本问题：Lynx 4.1.0 中，scroll-view 内点击不触发；ReactLynx 0.128 中，所有点击失效。他们回退到 Lynx 4.0.3 和 ReactLynx 0.126，最终继续使用 React Native。这些是作者报告的项目实测，不能据此认定对应框架在所有环境都不可用。输入文本也缺少作者提到的具体原因列表，无法进一步核对 UI 偏差的归因。

方向尚未确定时，生成更多代码只会放大返工成本。

工具让 AI 能验证，也让验收必须更具体

作者通过 adb 让 AI 操作 Android 真机，点击、输入、截图，发现桌面原型没有暴露的问题。但一次返回操作让应用退到桌面，接下来的点击落进了 WeChat 和 Alipay。作者称没有造成损失，却由此意识到，设备权限和允许操作的范围应提前明确。

这也是「同一个模型」比较中容易遗漏的变量。Claude Code 能读写仓库、运行命令、调用 adb、使用 GitHub；网页里的一问一答，通常不具备同样的工作条件。两种环境下交付能力不同，不能全部归因于模型名称。

验收同样需要覆盖真实路径。作者发现，GitHub Actions 每次生成的 Android 包使用不同的 debug 签名证书，新版必须先卸载旧版才能装。项目最后把固定的 debug.keystore 提交到仓库，解决了覆盖安装问题。只检查「构建成功」，发现不了这类故障，至少要在真机连续安装两次。

不过，debug.keystore 的处理只是该项目的调试构建方案，不能顺势当作生产签名密钥的管理建议。

App Store 素材也有类似区别：模型第一次就做对了尺寸，截图示例数据却要作者审核后才替换成中性内容。原文没有提供具体尺寸，无法整理成可复用的规格清单。商店描述则从内部使用场景，调整为「通过手机远程控制和查看电脑上的 AI 对话」。

作者认为原文案可能卡审核，但没有给出实际被拒记录。因此，这部分属于作者的审核风险判断，而非已验证的结果。

多问一个交付问题，才多出一套更新系统

项目后期，作者问：「以后小改 UI，能不能直接推更新，不用每次重新打包？」

随后才有了基于 expo-updates 协议的自托管 OTA 系统。OTA 就是不重新安装整包，把兼容的更新交付到设备。更新 bundle 放在作者自己的服务器上，runtimeVersion 使用 fingerprint policy。按项目中的配置和描述，只有 JS 的发布可在打开应用时自动更新，涉及原生代码变化则需要重新构建。

关键收益在于作者提出了维护阶段的目标，而不只是继续追加功能。原文没有展开失败回滚、更新签名等细节，也不能把这段描述理解为任意 JS 改动都能直接下发。

HarmonyOS 版本同样始于一个问题：「能不能做原生 HarmonyOS 版本？」模型随后用 ArkTS 实现，并让它在 GitHub Actions 上构建通过。作者报告了两个具体问题：Huawei 的 ohpm registry 对 GitHub runners 经常返回 503，需要重试；imageknife 3.2.8 及以上要求 API 18，因此项目停留在 3.2.7。

这些细节比「AI 能做完整产品」更有参考价值：交付不仅包括代码，还包括依赖兼容、构建网络和后续更新。需求没有覆盖这些部分，模型就未必主动补齐。

我的判断

我认同作者把人的注意力放到目标、约束和验收上。参考图、交接文档、先分析后实施、连续安装两次，都是能直接改善协作的信息和流程。

但「模型能力几乎从来不是瓶颈」超出了案例能证明的范围。原文没有对照实验，也没有完整记录耗时、成本、失败率和人工修改量。开头的「半天完成一周工作」与「每三题错两题」只是两类评价，不是可比较的统计结果。

同样，「AI 不会主动问你三年后是否后悔」更适合作为提醒，不能当作固定能力边界。可以在选型前要求模型比较供应商依赖、迁移成本和替代方案，只是最终仍需负责人核实并取舍。

与反复换模型相比，先检查任务描述和工具条件是成本较低的排查办法；但如果任务涉及模型反复解决不了的推理或实现问题，更换模型仍然合理。作者的经验能帮助定位问题，不能替代对模型能力的评估。

能拿来做什么

• 做前端页面或 App 原型时，先给参考图、布局优先级、字体环境和明确限制，再让 AI 实现。评审时描述具体偏差，例如信息层级或输入框位置，减少只给「不好看」的反馈。
• 让 AI 更换框架或跨端方案前，先要求它列出当前功能差异、版本兼容问题、平台依赖和退出成本，再决定是否迁移。
• 给 AI 使用 adb 的权限前，明确测试设备、允许进入的应用和退出目标应用后的停止条件；安装验证要覆盖从旧版升级到新版。
• 让 AI 编程任务覆盖交付之后的流程，明确提出 JS 更新、原生重构建、依赖下载失败等问题，并要求它说明已验证的行为和仍缺少验证的部分。