Один и тот же Claude Opus 5.5: почему одни делают приложение, а другие считают его глупым
Приложение на React Native + Expo с нуля в Claude Code и Opus 5.5: три отвергнутых интерфейса, отказ от uni-app x и Lynx, тесты через adb, OTA-обновления и версия для HarmonyOS.
Вот один и тот же Claude Opus 5.5. Одни говорят, что он за полдня делает недельный объём работы, другие — что из трёх ответов два мимо.
Недавно я сделал с его помощью мобильное приложение Ruzai (如在): когда ты не за компьютером, с телефона можно смотреть диалоги ИИ-ассистента на компьютере, писать ему сообщения и подтверждать ключевые операции, которые он собирается выполнить.
От продуктового дизайна, интерфейса и кода до автоматической сборки Android APK и iOS TestFlight в GitHub Actions, собственных OTA-обновлений и материалов для публикации в App Store — почти всё сделал Opus 5.5 в Claude Code. По ходу мы один раз сменили стек, оценили два кроссплатформенных варианта, а интерфейс я заворачивал три раза подряд.
Оглядываясь назад: возможности модели почти ни разу не стали узким местом. Модель одна и та же, а качество результата упирается в того, кто ей пользуется. В этом посте разберу по реальным эпизодам из проекта, в чём конкретно эта разница.
Сначала о стеке
| Часть | Что в итоге | Что пробовали / от чего отказались |
|---|---|---|
| Мобильный фреймворк | 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: Android APK, загрузка iOS в TestFlight | |
| OTA-обновления | Протокол expo-updates, хостинг на своём сервере | |
| HarmonyOS | Нативная версия на ArkTS, собирается в CI | |
| Разработка и отладка | Expo Go плюс реальное устройство, ИИ управляет телефоном напрямую через adb |
Каждое «отказались» и «перешли на» в этой таблице — это расхождение между человеком и ИИ. Разберу по порядку.
Разница первая: скажешь только «уродливо» — ИИ будет гадать три раунда
Вышла первая версия интерфейса, я говорю: уродливо.
Раунд первый: Opus 5.5 сменил палитру. Нашёл в сети три проверенные схемы и собрал их в прототипе, чтобы я выбрал:
| Вариант | Источник | Основной цвет |
|---|---|---|
| A Тёплый беж | Официальная палитра Claude | терракотовый #c96442, молочный фон #faf9f5 |
| B Зелёно-бирюзовый | Radix: серый Sage + зелёный Jade | #29a383 |
| C Индиго | Radix: серый Slate + синий Indigo | #3e63dd |
Сами палитры вполне аккуратные, но мне всё равно не нравилось.
Раунд второй: тут он уже не ограничился цветами, а переделал всё целиком в духе редизайна приложения Gemini 2026 года: чисто белый или чисто чёрный фон, никаких рамок, крупное приветствие, плавающее поле ввода в форме капсулы.
В этом раунде он ещё и нашёл причину, о которой я не подумал: дешёво выглядели сами скриншоты. Макеты снимались headless Chrome под Windows, и китайский текст по умолчанию рендерился шрифтом Microsoft YaHei. Стоило переключиться на Source Han Sans (Noto Sans SC), и картинка сразу стала ближе к тому, как выглядят MiSans и PingFang на телефоне. Получается, в первых двух раундах я отчасти ругал шрифт на скриншотах.
Раунд третий: я решил, что проблема, возможно, в цвете иконки, и вообще убрал все градиенты. Он сделал 6 вариантов однотонной иконки (чёрный фон с гротеском, чёрный фон с антиквой, киноварная печать…), и в итоге остановились на белой «Z» на чисто чёрном фоне.
Только после трёх раундов до меня дошло, что я всё это время давал оценку, но не давал направления. Скажи я с первой фразы: «Как в ChatGPT, всё вокруг диалога, чёрно-белое, без градиентов», — и первая версия была бы почти финальной.
У ИИ нет эстетических предпочтений, он выдаёт среднее по огромному количеству дизайнов. Не можешь сформулировать, чего хочешь, — кинь скриншот приложения, которое тебе нравится. Это полезнее десятка просьб «сделай посолиднее».
Разница вторая: что написано в техзадании, то он и сделает — буква в букву
В проекте работали два компьютера: на одном серверная часть и мобильное приложение, на другом Windows-клиент. ИИ на двух машинах не делят память и стыкуются через документы с требованиями в репозитории: протокол, API, что нужно поменять в этот раз. Одна сторона пишет и коммитит, другая подтягивает, делает по документу и проставляет статус.
Схема отлично работает. Новую иконку для десктоп-клиента и подключение мобильного релея мы сделали именно так: здесь пишется передаточный документ, там по нему всё доделывают.
Но есть и побочный эффект: решения, записанные в документ, ИИ выполняет без скидок.
Однажды в техзадании мобильный стек сменили на uni-app x, и Opus 5.5 честно написал под него целую кодовую базу на uni-app: закоммитил, починил баги, всё очень чисто. Уже потом я понял, что этим мы привязываем продукт к одной платформе DCloud — пуши, сборка, OTA-обновления, всё зависит от неё. Пришлось всё снести и начать заново на React Native + Expo.
ИИ сам не спросит: «А не пожалеем ли мы об этом выборе через три года?» Необратимые решения вроде выбора технологий должен принимать человек.
Разница третья: сначала код или сначала причины
Потом мне захотелось попробовать Lynx от ByteDance: одна кодовая база для Android и iOS, а в перспективе, может, и для HarmonyOS. Opus 5.5 быстро собрал прототип: компилируется, подключается к серверу, рендерит диалоги.
Но интерфейс снова стал уродливым и ничем не напоминал утверждённый вариант.
На этот раз я не стал просить сразу исправить, а сказал: пока никакого кода. Сначала разберёмся, почему так, потом предложи решение, и только потом пиши.
Причины он назвал очень конкретные:
| Где | Версия на React Native | Прототип на Lynx | Причина |
|---|---|---|---|
| Иконки | Линейные SVG-иконки | Текстовые символы ☰ ＋ ↑ | Lynx по умолчанию не отображает SVG |
| Боковая панель | Выезжает слева, 84% ширины, с затемнением | Целая страница со списком вместо панели | Нет готовых компонентов drawer и модальных окон |
| Нижняя панель | Выбор компьютера, детали подтверждения со скриншотом | Отсутствует | То же самое |
| В целом | Вылизано шаг за шагом по прототипу | Собрано за час, чтобы проверить осуществимость | Компоненты React Native в Lynx не работают, переиспользовать можно только чистую логику |
Плюс регрессии, найденные при тестировании: в Lynx 4.1.0 не срабатывают нажатия внутри scroll-view, а в ReactLynx 0.128 вообще отваливаются все нажатия, так что пришлось откатиться на 4.0.3 и 0.126.
Когда причины на столе, решение очевидно: остаёмся на React Native.
Скажи я тогда «сделай интерфейс красивым», он, скорее всего, потратил бы несколько часов на повторную вёрстку под Lynx, а в итоге мы бы всё равно вернулись обратно. Чем быстрее пишет ИИ, тем дальше он уходит в неверном направлении.
Разница четвёртая: сколько даёшь прав, настолько чётко очерчивай границы
Для тестов на реальном устройстве я дал ИИ управлять Android-телефоном напрямую через adb: нажимать кнопки, вводить текст, делать скриншоты и смотреть результат. Так нашлась куча проблем, которые на прототипе на компьютере просто не видны:
| Симптом | Причина | Решение |
|---|---|---|
| Клавиатура перекрывает поле ввода | После включения edge-to-edge раскладка не уступает место клавиатуре | KeyboardAvoidingView переключили на padding |
| После затемнения экрана нажатия не срабатывают | Первое нажатие уходит на пробуждение экрана | Перед тестом отправлять KEYCODE_WAKEUP |
| Свайп боковой панели заканчивается, едва начавшись | Нативный ScrollView перехватывает касание | Заменили на ScrollView из Gesture Handler и добавили слева прозрачную зону захвата шириной 36dp |
| Длинный диалог открывается на середине | При порционной вёрстке код сам прокручивает вниз, это тоже порождает событие прокрутки и ошибочно считается как «пользователь пролистал вверх» | Флаг «находимся внизу» меняется только при перетаскивании пальцем |
| Текст, введённый через adb, не попадает на экран | Ввод перехватывает клавиатура WeChat | Тапнуть по варианту подсказки, чтобы подтвердить |
Но и казусы случались: однажды он нажал «Назад», вышел на рабочий стол телефона, и следующие несколько нажатий пришлись прямо по WeChat и Alipay.
Обошлось без потерь, но звоночек был хороший: ИИ, который умеет только болтать, может только говорить; ИИ, подключённый к инструментам, может сам себя проверять — и сам же натворить дел. Одна и та же модель с инструментами и без них — это два совершенно разных уровня. Насколько открывать инструменты, на каком устройстве тестировать и каких приложений не трогать, нужно проговорить заранее.
Разница пятая: в какой среде принимаешь работу, то и увидишь
История со шрифтом на скриншотах — на самом деле вопрос приёмки: если смотреть результат в неправильной среде, забракуешь даже хорошее.
Со сборкой то же самое. APK, собранные в GitHub Actions, каждый раз подписывались разным отладочным сертификатом, поэтому перед установкой новой версии приходилось удалять старую. Решилось только тем, что закоммитили в репозиторий фиксированный debug.keystore. Пока дважды не поставишь сборку на реальный телефон, этого просто не заметишь.
А материалы для App Store — это вообще сплошные мелочи:
| Материал | Требуемый размер |
|---|---|
| Материал для заголовка | 5244 × 2950 или 3840 × 1646 |
| Материал для результатов поиска | 5244 × 2950, 3840 × 2560 или 1920 × 1280 |
| Скриншоты iPhone 6,3 дюйма | 1206 × 2622 или 2622 × 1206 |
С размерами ИИ справился с первого раза, но демо-данные на скриншотах я попросил заменить на нейтральные уже после того, как сам их посмотрел.
Ещё описание для стора. Он написал его по нашим реальным внутренним сценариям использования, функции расписал во всей полноте — но если писать как есть, велик шанс застрять на ревью. Этого ИИ не знает, а я знаю. В итоге переписали под угол «удалённое управление с телефона и просмотр ИИ-диалогов на компьютере», а подзаголовок — «Пульт и просмотр ИИ на компьютере».
ИИ может сделать всё правильно, но какие именно «правильно сделанные» вещи несут риск, знает только тот, кто через это проходил.
Разница шестая: знаешь ли ты, о чём спросить
Ближе к концу я спросил: «А можно мелкие правки интерфейса просто накатывать обновлением, без пересборки каждый раз?»
Этот вопрос обернулся полноценной системой OTA-обновлений: протокол expo-updates, пакеты обновлений хостятся на моём сервере; runtimeVersion по стратегии fingerprint — если менялся только JS, приложение обновляется само при открытии, а пересобирать нужно, только когда затронут нативный код.
Не спроси я — он бы сам этого не сделал. Не потому, что не умеет, а потому, что не знает, что для меня это важно.
Точно так же версия для HarmonyOS появилась только после моего вопроса «а можно собрать нативно под HarmonyOS?». Он написал версию на ArkTS, она собирается в GitHub Actions, а по пути пришлось обойти несколько граблей, о которых узнаёшь, только когда берёшься за дело: репозиторий ohpm от Huawei часто отвечает машинам GitHub ошибкой 503, так что нужны ретраи; imageknife выше 3.2.8 требует API 18, поэтому пришлось остаться на 3.2.7.
Докуда дошёл вопрос, дотуда дойдёт и ИИ. Кто умеет задавать вопросы, тот, естественно, и получает больше.
Разница седьмая: а вы точно пользуетесь «одной и той же моделью»?
Напоследок о факте, который часто упускают: когда двое говорят «я пользуюсь Opus 5.5», они вполне могут пользоваться совершенно разными вещами.
| Отличие | Что конкретно |
|---|---|
| Клиент | Веб-чат, Claude Code, всевозможные приложения-обёртки — системные промпты совершенно разные |
| Инструменты | Может ли он читать файлы, запускать терминал, управлять браузером и телефоном |
| Глубина рассуждений | Уровень thinking, быстрый режим — одна и та же модель на высоких и низких настройках сильно отличается |
| Контекст | 1M контекста или обычная длина; сжимаются ли старые диалоги и что теряется при сжатии |
| Канал | Официальный API, облачный провайдер или всевозможные прокси — версии и ограничения за ними не обязательно совпадают |
Ruzai я делал в Claude Code: он читает и пишет весь репозиторий, запускает команды, дёргает adb и GitHub. Сравнивать это с вопросами-ответами в веб-чате изначально нечестно.
Напоследок
Сведу все семь различий вместе:
| Работает «тупо» | Работает «умно» | |
|---|---|---|
| Эстетика | Только «уродливо» | Дать референсный скриншот, чётко сказать, чего не надо |
| Техзадание | Написано — значит, решено | Необратимые решения принимаешь сам |
| Порядок | Сразу писать код | Сначала причины и план |
| Права на инструменты | Не давать вовсе или открыть всё | Дать инструменты и сразу очертить границы |
| Приёмка | Смотреть скриншоты на компьютере | Смотреть на реальном устройстве, с реальными шрифтами и данными |
| Вопросы | Ждать, пока он сам додумается | Самому знать, о чём спросить |
| Рабочее место | Смотреть только на название модели | Смотреть на клиент, инструменты, уровень, канал |
Почти весь код в проекте написал Opus 5.5, но каждый поворотный момент — это решение человека: отказ от uni-app x, отказ от Lynx, удаление градиентов, правка текста для стора, добавление OTA-обновлений.
Так что в следующий раз, когда покажется, что ИИ «поглупел», не спешите менять модель. Сначала перечитайте то задание, которое вы ему дали, — может, оно само не слишком умное.
Про более технические приёмы — поиск, организацию контекста, бюджет на рассуждения и верификацию — я писал в статье «Прежде чем менять модель, сделайте ИИ умнее», её стоит прочитать вместе с этой.
Если вы тоже делаете свой продукт с Claude Code или другим ИИ, заходите пообщаться: linktr.ee/weiyii