Вторая серия из полугодового цикла про «Танец с ИИ и его внедрения». В первой статье я рассказывала, почему автоматизация начинается не с нейронки, а с понимания процесса. Сегодня — про ЧБД.

Напомню, с чего всё началось. Прихожу я как-то с совещания, на котором руководитель заявляет: «Какая Figma в 2026 году? Убираем». Иду к команде и говорю: «Всё, работаем исключительно с нейронкой», а вся команда глазёнками луп-луп, прям как я час назад.

Аналитика к тому моменту у нас уже была готова — её собирали аналитики (удивительно, не правда ли), в основном головой, а где-то, возможно, с нейронкой. А вот всё, что было дальше, — уже наша история.

Вводные: один проект и два пути

Мы разработали сервис для работы с фотографами — масштабный и состоящий из нескольких частей. И это оказалось нам на руку: внутри одного проекта мы обкатали сразу два подхода.

  • Чистый сервис — внутренний личный кабинет.

  • Публичная часть — тоже личный кабинет и часть сервиса, но презентабельная и красивая для клиента, а не для внутренних пользователей.

Работали параллельно: публичную часть отрисовывали руками в виде прототипов, а сервисную половину я собирала нейронкой на основе той самой аналитики.

Аналитику тоже прогоняю через нейронку

Отдельная история — сама аналитика. Мы привыкли за ней перепроверять, но я решила подключить к этому процессу нейронку.

Загоняю блок — целую страницу или раздел документа — и пишу: «Проанализируй бизнес-решение в сравнении с конкурентами». Даю ссылки на похожие сервисы, в том числе зарубежные. «Посмотри кликабельность, проверь по UI/UX и поищи критические моменты. Всё ли учтено, что можно улучшить? Предложи».

Именно предложи, а не «меняй». Она возвращает список правок, ранжированный по критичности: критичное, некритичное, совсем мелочь, плюс доработки на моё усмотрение. Я прохожусь и решаю, что берём, а что нет. Прошу поправить документацию под мои комментарии — и уже с этим идём верстать.

И так по каждому блоку. Результат более чем устроил: иногда нейронка подкидывала идеи, которые наш аналитик не учёл. А времени ушло сильно меньше, чем на вычитку томика в пятьдесят страниц. Перепроверять, конечно, всё равно приходилось — особенно первое время, но предлагала она достойные идеи.

Прототипирование в Claude Code

Аналитику мне передали большим пластом. Скормить это нейронке целиком — так себе идея: подавится ещё. Практика уже показала — лучше дробить на мелкие куски, чем вываливать всё и сразу.

Всё это я проворачивала в Claude Code через терминал. Подготовка простая:

  • создала папку на локальном ПК;

  • перетащила актуальную документацию от аналитиков, брендбук и скачанные шрифты;

  • попросила дизайнера отрисовать буквально одну страницу прототипа для десктопа размером в 1920px, чтобы понимать направление — какие формы и шрифты.

Перенос Figma и вёрстка один в один

Дальше я пошла по сайдбару — по пунктам и поступательно. Скормила нейронке ссылку на фрейм через MCP Figma: «Визуально опирайся вот на это. Мне нужен такой же прототип у себя, свёрстанный».

Первые разы получалась полная шляпа.

Чтобы получить желанный вариант, пришлось перебрать кучу вариантов:

  • Токены. Пыталась через скрипты — выгружала скрипт макета и кормила через HTML-плагин. Но бесплатной версии хватает на один макет, а платить за каждый не хотелось. Мимо. Да и один в один всё равно не выходило.

  • Скрины. Тоже коряво.

  • Переговоры. Сказала ей: «Задавай мне вопросы и запрашивай материалы, которые нужны, чтобы получилось один в один». И вот тут, как в диалоге с живым человеком, мы потихоньку договорились: скрины оставляю в отдельном документе, снова подсовываю MCP — она изучает всё ещё подробнее и находит подходящие скиллы для переноса в GitHub.

Когда результат наконец устроил, я попросила её записать весь наш путь в отдельный .md — по сути, внутренние правила, чтобы на следующих страницах она шла тем же маршрутом. А поскольку такое я собиралась переиспользовать и на других проектах — попросила собрать мне отдельный скилл: переносить макеты из Figma в вёрстку один в один на десктопе 1920.

Свёрстали один макет — нейронка поняла визуальную логику и дальше дело пошло.

Адаптив сразу на прототипах

Зачем я на этапе прототипов сразу полезла в адаптив?

Потому что это сервис. Прототипы здесь высоко детализированы — потом останется, грубо говоря, раскрасить и поправить пару моментов на дизайне, и всё готово. А значит, прототипы надо проработать максимально чётко и структурно, включая мобилку.

Других адаптивов у меня не было — времени на них тоже. Плюс мы всё-таки ставим эксперименты. Поэтому я попросила нейронку не рисовать наугад, а построить систему — отступов, шрифтов, паддингов и сеток.

«Изучи макет 1920 и то, что ты свёрстал. Посмотри на заголовки, наборный шрифт, отступы между заголовками и блоками. Запомни. И по нормам UI/UX собери мне систему». Конкретные отступы я не закладывала — оперлась на общепринятые стандарты (при таком отступе всё корректно ужимается до мобильного).

Когда она записала систему шрифтов, отступов, паддингов и сеток, я сказала: «Внеси всё в CHANGELOG.md и при разработке следующих страниц опирайся на эти правила. Не гуляй шрифтом, держи преемственность». Потому что следующих-то прототипов у меня нет — нужно правило, чтобы всё было чётенько, красивенько и одинаково от страницы к странице.

Дальше иду по разделам. Беру следующий кусок аналитики: «Мне нужна таблица с таким-то функционалом. Возьми его из документа аналитика, раздел такой-то. Больше ничего не бери и не придумывай». И затем шагаю по уже заданным правилам.

Важный нюанс: свои макеты нейронка адаптивит лучше, чем «ручные». Когда даёшь ей готовый макет из Figma, который мы делали, она адаптирует его чуть хуже (то есть совсем не очень), чем то, что собрала сама. Логично — как с человеком: свою работу править проще, чем чужую.

Проход по страницам

Каждую страницу я отсматривала на трёх разрешениях: 1920, 1084 и 360. Стандартный набор, чтобы всё влезало и выглядело адекватно.

Если что-то мне не нравилось — делала скрин конкретного блока: «Вот здесь поправь, ты сделал неадекватно». И он правит. В Claude Code ещё можно оставлять комментарии прямо к нужной части — это кому как удобнее.

В итоге получился единый файл — фактически сайт-прототип. Сайдбар-то везде одинаковый, поэтому я прописала, что он сквозной на всех страницах, и попросила настроить реальные ссылки для переключения. Добавила плавную анимацию перехода, чтобы всё было бесшовно и без дёрганья. Вышло очень круто.

Как показать это клиенту: HTML вместо Figma

И тут встал вопрос ребром: раз Figma мы больше не используем — как презентовать всё это клиенту?

Раньше было понятно: рисуем в Figma постранично, по всем состояниям. На одной странице их могло быть от трёх до десяти и больше. Всё прорисовано и наглядно. 

Мои опасения:

  • Клиент поймёт, что это нейронка. А они относятся к этому по-разному. Один скажет: «Класс, давайте использовать». А другой: «Ого, вы это в ИИ за пять минут сделали, я и сам могу, а вы с меня миллионы просите». К такому надо быть готовым.

  • Клиент клиенту рознь. Кто-то доверяет тебе как исполнителю, и ему важно только, чтобы учли комментарии и визуал. А кому-то важнее функционал. Наш относился щепетильно и к тому, и к другому — поэтому даже прототипы мы отсматривали очень-очень внимательно.

Раз способ демонстрации заранее не проговорили, мы решили, что это новое время — новые технологии. Отдаём в HTML. Пусть клиент ходит как по сайту — кликает, смотрит, оценивает функционал и визуал.

И вот что тут кайфово. Когда прототип собран нейронкой и его можно потыкать — это просто экстаз. Берёшь то, что написали аналитика, а нейронка уже прорабатывает сценарий: жмёшь кнопку — что-то добавляется, удаляется или подтягивается автоматически. Бэка нет вообще, но на фронте всё выглядит так, что систему реально можно пощупать. Загрузить туда ничего не загрузишь, но потрогать сырой, но кликабельный сервис — можно. И даже на этапе прототипа так проще заметить свои же ошибки.

Боялась я вот чего. В Figma всё нагляднее: видны все состояния, можно оставить комментарий и пройтись по сценариям. В HTML, как в готовом сайте, что-то легко упустить. Поэтому нужен хотя бы краткий план пользовательского сценария по шагам, чтобы понимать: нажму сюда — «А что будет? Всё отрисовано? Нейронка дошла или отвалилась?».

В общем, для презентации — супер, продукт можно сразу пощупать. По наглядности, пожалуй, хуже Figma: объём работ так не оценишь, и это не всегда очевидно клиенту и исполнителю. Но мы всё-таки отдали HTML — клиент всё отсмотрел и ему понравилось.

Правки всей командой через GitHub

Вот это, кстати, отдельная и очень классная история.

Времени в обрез, гонимся за эффективностью — но терять в качестве нельзя. Поэтому я попросила аналитиков отсмотреть прототипы на соответствие их же документации. Они глубже всех погружены в структуру — им и карты в руки. Отсматриваем вместе — и всё идёт быстрее.

Всё это я загнала в репозиторий на GitHub. Так каждое изменение команда видит одновременно: и разработчик, и аналитик, и я. Когда результат меня устраивал — сразу перетаскивала в GitHub. Заодно это спасло от помойки из нужных и ненужных файлов — переносила только нужное.

Схема правок сложилась следующая. Аналитик формирует документ — со скринами и описанием, что именно поправить. Я скачиваю его целиком и кидаю в папку проекта: «Возьми правки от такого-то числа вот в этом документе и иди править». Нейросеть правит и подсвечивает слабые места: «Вот тут спорный момент, обрати внимание». Я иду смотреть дополнительно — глазами пробегаюсь по правкам, проверяю аналитика и вспоминаю, что говорил клиент.

Иногда всплывал конфликт: «Вчера мы это поправили, а теперь возвращаем назад? Ты в себе вообще?!». Тогда я шла к аналитику: «Тут конфликт по разработке — берём сегодняшние правки или оставляем вчерашние?» Дополнительная проверка для всех нас. А потом нейронка и сама начала задавать такие вопросы — и жить стало сильно проще.

Второй способ: переносим готовые прототипы из Figma

Сценарий выше описывает ситуацию, когда мы идём от описания аналитики. Но есть и второй вариант: перенести прототипы, уже отрисованные в Figma, добавить мобильную версию и подготовить под натяжку дизайна.

Зачем? Потому что практика показала, что нейронке проще перерисовывать, когда у неё уже есть прототипы. Можно, конечно, сразу прыгнуть к макетам — такие эксперименты у нас тоже были, но об этом в следующей статье про дизайн.

Схема работы: даём по MCP с Figma ссылку на фрейм, говорим «верстай один в один» и пользуемся уже готовым скиллом. Потом смотрим на результат: есть UI kit — замечательно, а если нет — не страшно. Берём страницу отрисованного дизайна (обычно это дизайн-концепция, её вы всё равно согласуете с клиентом) и цепляем ссылкой из Figma.

Лайфхак: давайте ссылку не на всю Figma, а на конкретный фрейм. Выделили нужную страницу с её состояниями — даёте ссылку именно на этот фрейм (Select, который объединяет всё) и говорите: «Свёрстай макет на основе этих прототипов. Визуал бери с Figma, а цвета — из дизайн-концепции, которую верстали раньше. Обрати внимание: состояний здесь шесть, ни одно не забудь». И фигачите дальше.

Этот же путь выручает, когда на проекте не было аналитики. Бывают проекты, где клиент от неё отказался, и на руках у вас, дай Бог, есть бриф. Нейронка и с этим помогжет — пропишет и укажет документацию.

А где нейронка буксует: креативный контентный сайт

Ещё один сценарий из моей практики. Был у нас проект, который мы решили попробовать сделать целиком нейронками — ещё до сервисника.

С сервисами нейросеть работает вообще супер. Ачишуенно. Но тут был контентный сайт для дистрибьютора оборудования. И захотели они наглядный, красивый и дизайнерский сайт — с чувством прекрасного, подключением к космосу и прочими творческими штучками.

Решили мы собрать макеты дизайна. Была дизайн-концепция, загрузили её в нейронки — я гоняла ещё тогда через Claude Design и пару других генераторов. И что я увидела: креативный дизайн на тот момент не тянула ни одна. Даже если загрузишь стиль, скрины, референсы и попросишь «обучись и сделай» — не делает.

Claude Design тут работает ничем не лучше, чем если бы вы делали то же в Claude Code. А коннекта между ними тогда не было вообще — HTML всё равно надо вытащить, скормить Claude Code и верстать там. Полная дичь.

Прототипов на этом проекте не было — сразу дизайн-концепция и макеты. Аналитики особо тоже не было. Проект из говна и палок, как говорится, но вышел на самом деле классным. Подробности и что за дизайн у нас в итоге получились (да-да, получились!) — расскажу в следующей статье.

Вместо вывода

Для прототипов и особенно для сервисников нейронка — это то, что и Господь Бог прописал, и доктор, и аптекарь. Для контентных сайтов её тоже можно смело брать хотя бы на прототипы — показать визуальную структуру она вполне способна, особенно если есть аналитика.

Так что использовать нейронку для прототипирования — прямое показание. Делегируйте смело.

В следующей серии — самое вкусное: дизайн. Где нейронка красавица, где буксует и как мы всё-таки выгрузили из неё те самые макеты.