Сразу дам некоторые вводные: я использовал TRAE, это IDE на базе VS Code, в которой уже встроен набор разных моделей, и всё это счастье можно использовать бесплатно. Чтобы вы не тратили время на проверку на момент написания там есть из коробки: GPT 5.4 и 5.2, Dola-seed 2.0 code, MiniMax M2.7 и M3, Kimi k2.5, Deepseek v3.2 и Gemini 2.5flash, 3Flash preview и 3.1 Pro preview. Есть ограничения в виде ожиданий между запросами, но если заплатить 30 долларов в месяц, то на сегодняшний день это безлимит по запросам с авто выбором моделей. И конечно же можно добавить любую свою модель, на которую у вас есть подписка, тот же Claude, например. Тут уже без безлимита, всё будет зависеть от вашего тарифа.
Так вот, попробовав делать разные мобильные приложения, протестировав их на телефоне и так далее, я так и не смог добиться того, что хочу, а в некоторых местах даже сам путался в функционале и пользовательских сценариях. И я понял, что чтобы получить что-то более-менее качественное, с чем потом можно уже работать точечно и возможно ручками нужно очень точно задавать инструкции и ограничивать фантазию агента. А как задать точную инструкцию если я в мобильной разработке полный ноль? Ну да, спросить ии… а что спросить то? В общем, вопросов больше чем ответов. Сначала я пытал ии на предмет написания мне точной инструкции с указанием всего функционала и пр. что я хотел видеть в приложении. Он справлялся, как я думал, писал красиво, много, умно, я половину даже не понимал. Потом всё это скармливал TRAE в виде промтов и инструкций и получал очередную вариацию на тему моего приложения.
После нескольких попыток я решил хорошенько поискать инструмент, который позволил бы хотя бы как-то визуально спроектировать приложение, чтобы на основе этой визуализации объяснить ИИ что я от него хочу в принципе, не обращая внимания не технические моменты реализации. Да и мне гораздо удобнее смотреть глазами на юзерфлоу, а не читать описания и держать всё в голове. Долго и мучительно искал, но всё время натыкался либо на комбайн «всё в одном» (за немалые деньги), либо на текстовые заметки типа Obsidian, тоже весьма универсальный, но не то. Да, есть Figma, и там можно что-то делать: интерактив, красивая презентация заказчику… а что потом? В реальном мире сначала ТЗ, потом Miro или аналог, чтобы раскидать экраны и посмотреть на пользовательский флоу, потом дизайн, и уже затем код, тесты и прочее. Я даже протестировал в Figma их AI и попытался сделать веб-приложение (на бесплатном тарифе можно разок побаловаться). На моём тесте он сделал рабочий фронт и даже что-то писалось в базу, но с косяками, а потом сам себе чинил бэкенд и за полчаса слил все токены, так ничего и не починив. Пусть Figma остаётся инструментом для дизайна и прототипирования, а не комбайном, каким её пытаются сделать сейчас, простите, наболело.
Накушавшись всего этого, я созрел до идеи. Если чего-то нет, надо сделать. Естественно, я начал с самого начала: просто описал, что хочу, как это вижу и как оно должно работать. Речь шла о веб-сервисе по генерации правил, на основании которых любая модель должна программировать максимально в рамках, а что и как программировать я буду изображать визуально и схематично. В общем, идея простая: на холсте рисуем элементы экранов, соединяем стрелочками (пользовательский флоу) и нажимаем кнопку «Экспорт». На выходе получаем набор правил под конкретное приложение: описание экранов, элементов и переходов между ними. Не буду описывать, как именно я этого добивался, но кое-что получилось, и всё работает без использования сторонних сервисов в процессе генерации правил. Выглядит это вот так:
И в процессе создания я наступил на те же грабли. Все, кто кодит с помощью ИИ, неважно где: в Trae, Cursor, Windsurf или через Claude Code, знают главный «секрет» нейросетей: они невероятно тупеют на длинной дистанции. По одному-два запроса на старте они прекрасно справляются (говорю про мобильные приложения, не про веб), но как только начинаешь накручивать функционал, всё. На десятый день, когда проект разрастается, у ИИ начинается «амнезия». Открываешь новый чат, у старого уже кончился контекст, и ИИ начинает изобретать велосипед заново. Она не знает, о чём вы договорились вчера! Находит первый попавшийся похожий участок кода, вставляет туда, прогоняет тесты. С виду всё ок. На деле три библиотеки иконок, один огромный основной файл, где весь код свален в кучу, и масса маленьких файлов, решающих локальные проблемы, но слабо связанных с глобальными. Обычные промпты в духе «пиши чистый код» больше не работают. Универсальные наборы правил из интернета тоже не спасают. И это касается любой модели, когда делается что-то большее, чем сайт из пяти страниц или мобильное приложение.
И вот что я сделал, когда через пару недель ИИ начал так сильно уходить в сторону, а код так разросся, что от первоначальных договорённостей не осталось и следа и приходилось тыкать носом при каждой новой сессию чтобы он впитал проект и мог продолжать.
«Гениальное решение». Я в правилах IDE жёстко прописал, что как только модель что-то меняет в коде или логике, она тут же записывает или обновляет это в спецификации MVP. Это реально спасало: мне больше не нужно было каждый раз объяснять логику при новых задачах. Да, это съедает токены, но как показала практика, на уточнениях и чтении всего кода с ростом проекта, токенов съедается больше, чем на изучение кратких инструкций о коде и механиках. Модель сама бежала в правила, затем в спецификацию, и через 10 секунд знала весь проект на зубок! Тот же приём я реализовал и в правилах, которые генерируются для мобильных приложений, причём с учётом выбора конкретной модели. Так что очень рекомендую завести такой файл и прописать этот навык. У меня был файл правил для IDE, почти стандартный, с просторов интернета, а сейчас это почти 300 строк уникальных инструкций и самые главные эти:
## Specification Maintenance RuleWhen product behavior changes, update the specification in the same work cycle.After every code change that affects runtime behavior, model shape, validator behavior, export output, UI semantics, or catalog choices:1. immediately check which specification files are affected2. update those specification files in the same task before considering the work finished3. do not leave spec follow-up as an optional later cleanup stepUpdate these three reference files first:1. `Specification/12_element_reference.md` for element behavior, props, actions and panel nuances2. `Specification/13_screen_and_modal_reference.md` for screens, modals, connections and flow rules3. `Specification/14_project_settings_reference.md` for settings, services, permissions and export-sensitive configurationIf the change also affects core runtime contracts, update the matching base files too:- `Specification/2_model_data.md`- `Specification/CURRENT_SCOPE.md`- `Specification/6_ui_and_canvas.md`- `Specification/catalog/mvp_function_catalog.md`Do not leave new runtime behavior documented only in code or only in chat history.Before changing action logic, validation, export-sensitive behavior or panel semantics, re-read the matching reference files first instead of reconstructing rules from memory.
В планах сделать то же самое для веб приложений. Мне кажется, это сильно упростит проектирование сайтов: можно будет, не отвлекаясь на дизайн, увидеть всю логику, перелинковку и найти слабые места, вместо того чтобы держать всё в голове. Спасибо за потраченное время, всем удачи.
P.S. Если кому интересно посмотреть на генератор правил для мобильных приложений, добро пожаловать по ссылке: mrkdwn.dev
ссылка на оригинал статьи https://habr.com/ru/articles/1053284/