同样是 Claude Opus 5.5，为什么有人用来做出 App，有人觉得它笨？

同样是 Claude Opus 5.5，有人说它半天能干完一周的活，有人说它问三句错两句。

我最近用它做了一个手机 App，叫「如在」：人不在电脑前的时候，用手机查看电脑上 AI 助手的对话、给它发消息、批准它要执行的关键操作。

从产品设计、界面、代码，到 GitHub Actions 自动打包安卓 APK 和 iOS TestFlight、自建热更新、App Store 上架素材，基本都是 Claude Code 里的 Opus 5.5 做的。中间换过一次技术栈，评估过两个跨平台方案，界面被我否了三轮。

做完回头看，模型能力几乎没成为瓶颈。 同一个模型，结果好不好，差在用的人身上。这篇按项目里真实发生的事，拆成几个具体的差距。

先交代一下技术栈

部分	最后用的	中途试过 / 放弃的
手机端框架	React Native 0.88 + Expo SDK 58	uni-app x（放弃）、Lynx 4.0（小样后放弃）
路由和编译	Expo Router、React Compiler、TypeScript 6	TypeScript 7（和 typescript-eslint 不兼容）
手势和动画	Reanimated 4.7、Gesture Handler 3.3
打包	GitHub Actions：安卓 APK、iOS 上传 TestFlight
热更新	expo-updates 协议，自己的服务器托管
鸿蒙	ArkTS 原生版，CI 编译通过
开发调试	Expo Go 加真机，AI 通过 adb 直接操作手机

这张表里每一个“放弃”和“改用”，都是一次人和 AI 的分歧。下面一个个说。

差距一：只说“丑”，AI 只能猜三轮

第一版界面出来，我说：太丑。

第一轮，Opus 5.5 换了配色。它从网上找了三套成熟方案做进原型让我选：

方案	来源	主色
A 暖米	Claude 官方配色	陶土橙 #c96442，米白底 #faf9f5
B 青绿	Radix 的 Sage 灰 + Jade 绿	#29a383
C 靛蓝	Radix 的 Slate 灰 + Indigo 蓝	#3e63dd

配色本身都很规矩，我还是觉得丑。

第二轮，它不再只换颜色，而是按 2026 年 Gemini App 的改版风格整套重做：纯白或纯黑底、去掉所有边框、大号问候语、悬浮的胶囊输入框。

这一轮它还查出一个我没想到的原因：截图本身就廉价。 效果图是在 Windows 上用无头 Chrome 截的，中文默认渲染成微软雅黑。换成思源黑体（Noto Sans SC）以后，观感一下接近手机上的 MiSans 和苹方。前两轮我嫌丑，有一部分是在嫌截图的字体。

第三轮，我觉得问题可能出在图标颜色上，干脆去掉所有渐变。它出了 6 个纯色图标方案（黑底黑体、黑底宋体、朱红印章……），最后定成纯黑底白字的“Z”。

三轮下来我才发现，自己一直只给了评价，没给方向。如果第一句就说“像 ChatGPT 那样以对话为主，黑白，不要渐变”，第一版就能接近定稿。

AI 没有审美偏好，它给你的是大量设计的平均值。 说不清要什么，就甩一张你喜欢的 App 截图，比十句“高级一点”管用。

差距二：需求文档写了什么，它就严格做什么

这个项目有两台电脑在干活：一台做服务端和手机 App，另一台做 Windows 客户端。两边的 AI 不共享记忆，靠代码仓库里的需求文档对接：协议、接口、这次要改什么，一边写完提交，另一边拉下来照着做，做完标上状态。

这套办法很好用。电脑客户端换新图标、接入手机中转，都是这边先写交接文档，那边照着就做完了。

但它也有副作用：写进文档的决定，AI 会不打折扣地执行。

有一次需求文档里把手机端技术改成了 uni-app x，Opus 5.5 就照着写了一整套 uni-app 代码，提交、修完问题，干得很漂亮。写完我才意识到，这等于把产品绑在 DCloud 一家平台上，推送、打包、热更新都离不开它，于是推倒重来，改成 React Native + Expo。

AI 不会主动问“这个选择三年后会不会后悔”。技术选型这种不可逆的决定，得人来拍板。

差距三：先让它写代码，还是先让它讲原因

后来我想试字节的 Lynx：一套代码出安卓、iOS，以后可能还有鸿蒙。Opus 5.5 很快搭出一个小样，能编译、能连服务器、能渲染对话。

但界面又丑回去了，和定稿完全不一样。

这次我没让它直接改，而是说：先不写代码，先讨论清楚为什么，再出方案，最后再写。

它给的原因很具体：

地方	React Native 版	Lynx 小样	原因
图标	SVG 线条图标	☰ ＋ ↑ 文字符号	Lynx 默认不能显示 SVG
侧边栏	从左滑出，占 84% 宽，带遮罩	整页换成列表	没有现成的抽屉和弹窗组件
底部面板	选电脑、确认详情带截图	没有	同上
整体	按原型一点点调出来的	一个小时拼出来验证可行性	React Native 组件 Lynx 用不了，只能复用纯逻辑

再加上测试中发现的回归问题：Lynx 4.1.0 里 scroll-view 内的点击不触发，ReactLynx 0.128 干脆所有点击都失灵，只能退回 4.0.3 和 0.126。

原因摆出来，决定就很简单：继续用 React Native。

如果我当时说“把界面改好看”，它大概会在 Lynx 上花几个小时重调一遍，最后还是换回去。AI 写得越快，错的方向走得越远。

差距四：给它多大的权限，就要划多清楚的边界

为了真机测试，我让 AI 通过 adb 直接操作安卓手机：点按钮、输入文字、截图看结果。很多问题都是这样找出来的，电脑上的原型根本看不出：

现象	原因	怎么解决
键盘弹起挡住输入框	开了 edge-to-edge 后布局没让开键盘	KeyboardAvoidingView 改成 padding
屏幕变暗后点击没反应	第一下点击被用来唤醒屏幕	测试前先发 KEYCODE_WAKEUP
侧边栏左滑手势开始就结束	原生 ScrollView 抢走了触摸	换成 Gesture Handler 的 ScrollView，再在左侧加一条 36dp 宽的透明感应区
打开长对话停在半截	分批排版时，代码自己滚到底也触发滚动事件，被误判成“用户往上翻了”	只有手指拖动才改变“是否在底部”的判断
adb 输入的文字没上屏	微信输入法拦截了输入	点一下候选词提交

但也出过状况：有一次它按了返回键，退回了手机桌面，后面几下点击直接落在微信和支付宝上。

没造成损失，但足够提醒我：只能聊天的 AI 只会说，接上工具的 AI 能自己验证，也能自己闯祸。 同一个模型，接不接工具，表现完全是两个级别；工具放开多少、在哪台设备上测、哪些应用不能碰，得提前讲清楚。

差距五：在什么环境里验收，决定你看到什么

前面截图字体的事，其实是一个验收问题：你在错误的环境里看结果，好的东西也会被嫌弃。

打包也一样。GitHub Actions 打出来的安卓包，每次签名的调试证书都不一样，装新版本就得先卸载旧版。最后把固定的 debug.keystore 提交进仓库才解决。不在真手机上装两次，根本发现不了。

App Store 上架素材更是细节堆出来的：

素材	要求的尺寸
标题素材	5244 × 2950 或 3840 × 1646
搜索结果素材	5244 × 2950、3840 × 2560 或 1920 × 1280
iPhone 6.3 英寸截屏	1206 × 2622 或 2622 × 1206

这些尺寸 AI 一次就做对了，但截图里的示例数据，是我看了以后才让它换成中性内容的。

还有商店描述。它按我们内部真实的使用场景写，功能写得很全，但照实写很可能卡审核。这一点 AI 不知道，我知道。最后改成“手机遥控、查看电脑上的 AI 对话”这个角度，副标题是“遥控和查看电脑上的 AI”。

AI 能把事做对，但哪些事做对了反而有风险，只有做过的人知道。

差距六：你知不知道该问什么

做到后面，我问了一句：“以后界面小改动，是不是直接升级就行，不用每次都编译？”

这一句换来了整套热更新：用 expo-updates 协议，在自己的服务器上托管更新包；runtimeVersion 用 fingerprint 策略，只改 JS 的版本手机打开 App 就自动更新，动了原生代码才需要重新打包。

如果我不问，它不会主动做。不是它不会，而是它不知道这对我重要。

同样的，鸿蒙版是我问“能不能编译鸿蒙原生”才开始的。它用 ArkTS 写了一版，在 GitHub Actions 上编译通过，中间还解决了几个只有动手才知道的坑：华为的 ohpm 仓库对 GitHub 的机器经常返回 503，要加重试；imageknife 3.2.8 以上要求 API 18，只能用 3.2.7。

问题问到哪，AI 就做到哪。 会问问题的人，拿到的东西自然多。

差距七：你用的真是“同一个模型”吗

最后说一个经常被忽略的事实：两个人说“我用的是 Opus 5.5”，用到的可能根本不是同一个东西。

差别	具体是什么
客户端	网页聊天、Claude Code、各种套壳 App，系统提示词完全不同
工具	能不能读文件、跑终端、操作浏览器和手机
推理强度	思考档位、快速模式，同一个模型开高开低差很多
上下文	1M 上下文还是普通长度；旧对话会不会被压缩，压缩时丢了什么
线路	官方 API、云厂商还是各种中转，背后的版本和限制不一定一致

我做「如在」用的是 Claude Code：能读写整个代码仓库、跑命令、调 adb、调 GitHub。拿它和网页上一问一答的体验比，本来就不公平。

写在最后

把这七个差距放在一起：

	用着“笨”	用着“聪明”
审美	只说“丑”	给参考截图，说清不要什么
需求文档	写了就当定了	不可逆的决定自己拍板
顺序	一上来就写代码	先讲原因和方案
工具权限	不给，或者全放开	给工具，同时划边界
验收	在电脑上看截图	在真机、真实字体、真实数据下看
提问	等它主动想到	自己知道该问什么
工位	只看模型名字	看客户端、工具、档位、线路

整个项目里，代码基本都是 Opus 5.5 写的，但每一个转折点都是人做的决定：放弃 uni-app x、不用 Lynx、去掉渐变、改商店文案、加热更新。

所以下次觉得 AI “降智”了，先别急着换模型。回头看看自己给它的那份工作说明，是不是本身就不太聪明。

更偏技术的做法，比如检索、上下文整理、推理预算和验证，我在《想让 AI 更聪明，先别急着换模型》里写过，可以一起看。

如果你也在用 Claude Code 或别的 AI 做自己的产品，欢迎来聊：linktr.ee/weiyii