В марте 2026 года мы обновили платформу moonshot.ai целиком. Само обновление выглядело простым: новая цветовая палитра, более выверенная типографика и обновлённая анимация. На практике же оно затронуло общие компоненты, дизайн-токены, маршруты и интерактивные слои по всему сайту.
Для проведения перестройки мы использовали Kimi Code CLI на базе Kimi K2.5 в роли ИИ-агента для кодинга. Этот проект стал практической проверкой того, как терминальный агент вписывается в реальный рабочий процесс продакшна, а не в демо-окружение. В этой статье мы рассказываем, как мы его использовали и чему научились в процессе.
В чём заключалось это обновление
Обновление moonshot.ai не было редизайном бренда с нуля. Большая часть дизайн-работы уже была готова в Figma. Настоящая сложность заключалась в том, чтобы последовательно применить эти изменения к существующей кодовой базе.
Это означало отслеживание общих токенов, обновление компонентов, проверку интерактивного поведения и контроль того, чтобы аналитика и доступность не были нарушены. Многие изменения по отдельности были небольшими, но затрагивали сразу несколько уровней сайта.
Эта работа сложна не из-за алгоритмической сложности. Она сложна из-за широты охвата и необходимости соблюдать единообразие. Основная задача — понимать, что затрагивает каждое изменение, и убедиться, что ничего не упущено. Для этого мы использовали подключение по протоколу Model Context Protocol (MCP) к Figma, чтобы точнее сопоставлять дизайн-спецификации с реализацией, помогая агенту понимать структуру и уменьшая необходимость в ручной интерпретации.
Базовые правила: как сделать агента полезным
Первым шагом было не написание промптов, а настройка контекста. Мы использовали команду /init, чтобы сгенерировать файл AGENTS.md, а затем потратили около часа на его уточнение. В нём мы описали, что входит в объём обновления, что нельзя менять, как устроен проект и как работает процесс сборки. Мы также добавили файл с правилами, охватывающий соглашения по именованию, отступы и требования к контрастности.
Такая настройка снизила необходимость повторных объяснений в дальнейшем и сделала работу с Kimi Code CLI более последовательной. Без контекста, специфичного для проекта, ИИ-агент для кодинга склонен выдавать разумные, но обобщённые результаты. С контекстом его поведение становится ближе к поведению коллеги, который уже знает кодовую базу.
Как мы на самом деле его использовали
В этом разделе подробно рассказывается, как Kimi Code CLI применялся во время обновления на практике — при отслеживании зависимостей, сверке с дизайном, изучении поведения, проверке производительности и анализе рисков интеграции. Речь шла не об автоматизации, а о снижении неопределённости в крупномасштабном рефакторинге.
Понять, что затрагивает изменение
Перед тем как что-либо редактировать, мы просили агента в Kimi Code CLI изучить целевую область и перечислить, что от неё зависит. Одно изменение — например, цвета кнопки — может затронуть героические секции, секции загрузки, состояния при наведении и общие токены, а общие компоненты, тайминг анимации и хуки аналитики могут расширить эффект ещё дальше. Получение списка зависимостей заранее уменьшало число неожиданностей позже и делало правки более предсказуемыми.
Сопоставление кода с дизайн-спецификацией
Затем мы сравнивали компоненты с дизайн-спецификацией по разделам: героическая секция, навигация, секции продукта, призыв к загрузке и подвал. Агент формировал списки изменений на уровне свойств, сравнивая стили с дизайн-токенами и значениями layout. Этот процесс был больше похож на структурированную автоматизацию дизайн-системы, чем на ручную визуальную проверку. Большинство различий были небольшими — отступы, радиус скругления или насыщенность шрифта, — но иногда обнаруживались более крупные несоответствия, где компоненты, которые должны были использовать общие варианты, со временем расходились друг с другом. В результате получился конкретный список правок, а не процесс визуального угадывания.
Изучение нового поведения
Обновление вводило новое поведение интерфейса, которого ранее не было в кодовой базе: кастомный курсор, героическую секцию, управляемую в реальном времени, карточки с иллюстрациями, воспроизводящимися при наведении, и появление элементов при скролле.
Для каждой функции мы использовали Kimi Code CLI как контекстную среду, загружая документацию и состояние репозитория вместе. Именно здесь важен был Kimi K2.5: более длинный контекст позволял рассуждать одновременно о реализации и справочных материалах в рамках одной сессии.
Вопросы были практическими:
Должна ли анимация при наведении завершаться или прерываться при выходе курсора?
Должен ли курсор взаимодействовать с холстом героической секции?
Что ломается, когда пересекается несколько слоёв?
Большое окно контекста позволило сделать работу с kimi code более непрерывной: замысел дизайна и код находятся в рамках одной и той же сессии.
Проверка веса и производительности
Обновление добавило новый шрифт, больше анимации и дополнительные ресурсы, из-за чего вес страницы увеличился. Мы использовали агента, чтобы адаптировать существующий скрипт субсеттинга шрифтов и проверить результат, а позже он помогал интерпретировать отчёты Lighthouse, чтобы мы могли выявлять регрессии на раннем этапе. Цель заключалась не в оптимизации всего в самом конце, а в принятии решений «оставить или убрать», пока изменения ещё были небольшими.
Отслеживание рисков интеграции перед слиянием
Несколько интерактивных слоёв — анимация появления, курсор, холст героической секции — делят общий порядок и поведение указателя, хотя находятся в разных компонентах, поэтому изменение в одном слое всё же может повлиять на другие. Также нужно было учитывать различия между браузерами и операционными системами, где поведение CSS и рендеринга может отличаться. Перед слиянием пакетов изменений мы передавали диффы в Kimi Code CLI и просили его отследить, какие взаимодействия могут быть затронуты, затем проверяли эти сценарии в браузере и проводили лёгкую проверку в разных окружениях.
Интеграции MCP и Skills
Model Context Protocol (MCP) позволил Kimi Code CLI напрямую подключаться к внешним системам с данными проекта. Мы использовали mcp Figma, чтобы получать дизайн-токены, данные о макете и типографике прямо из Figma, что сократило объём ручного переноса информации между дизайном и кодом, а также подключили внутренние инструменты, открыв доступ к задачам, спецификациям и пограничным случаям без переключения контекста.
Подключение сервера — это одна команда:
Этот паттерн применим и к остальной экосистеме MCP. Для примера можно подключить агентов к:
Figma — официальный MCP для получения дизайн-контекста, переменных и данных о макете прямо с холста
Atlassian Cloud — страницы Confluence и рабочие элементы Jira через удалённую точку входа MCP от Atlassian (описана вместе с Rovo)
Базы данных, API CMS — MCP-серверы от вендоров или сообщества; реестры содержат сотни вариантов по категориям
Ваш стек может выглядеть иначе — приватный API документации, внутренний сервис дизайн-токенов или хранилище данных. Идея та же: подключить агента к системам, где уже хранятся нужные данные. Подробнее о конфигурационных файлах, определениях серверов и других способах настройки MCP в Kimi Code CLI см. в руководстве по платформе.
Skill для ревью
Мы также написали Skill для code review. Это файл правил, который объясняет Kimi Code CLI, как оценивать merge request от начала до конца: читать диф, отслеживать затронутые файлы и компоненты, проверять нарушения дизайн-системы (необработанные цветовые литералы, отступы вне сетки, отсутствующие резервные варианты для доступности), оценивать риски по областям и формировать структурированный отчёт.
Отчёт имеет фиксированный формат:
Сводка по замыслу и объёму изменений
Находки, сгруппированные по степени критичности (критические проблемы, блокирующие merge, рекомендуемые улучшения, незначительные предложения по единообразию)
Для каждой находки: подтверждение из дифа, оценка влияния и конкретное действие
Skill также отмечает потенциальные риски, требующие быстрой проверки в браузере или на устройстве — случаи, когда агент не уверен, но стоимость проверки низкая.
На практике каждый PR во время визуального обновления moonshot.ai проходил этот структурированный этап перед завершением ревью. Итоговый результат всегда включал краткое изложение замысла, находки по степени критичности, подтверждения и исправления.
Это помогло снизить количество доработок на позднем этапе и повысить единообразие в рабочем процессе Kimi Code, выявляя такие проблемы, как хардкодированные URL рядом с общими константами, поля аналитики, требующие выравнивания, и пограничные случаи мобильного взаимодействия.
Что оказалось неожиданным
В ходе рефакторинга проявилось несколько паттернов, которые не были очевидны с самого начала.
Переход от спецификации к коду шёл быстрее, чем мы ожидали
Когда Figma MCP и Kimi Code CLI работали в одном треде, размеры и дизайн-токены поступали как структурированные данные, а не переносились вручную. В результате циклы итераций по каждому разделу стали короче — изменения и исправления на уровне свойств часто получалось внести за один проход, без переключения между инструментами.
Промпты для исследования принесли больше пользы, чем мы ожидали
Обновление во многом опиралось на длинные проходы по документации среды выполнения и референсным реализациям, основанные на документах, наряду с репозиторием. Хранение этих материалов в одной сессии с кодом часто оказывалось не менее ценным, чем сами правки.
Skill для ревью превратил мелкие несоответствия в список
Структурированный отчёт выявлял те же типы проблем, что описаны выше — хардкодированные URL рядом с общими константами, поля аналитики, требующие выравнивания, и пограничные случаи мобильного взаимодействия. По отдельности большинство из них были незначительными, но их проще было устранять, объединив в один проход.
Длинные треды оставались дёшевы для возобновления
Команды вроде kimi --continue и /compact означали, что многодневная работа не требовала восстановления контекста каждое утро. Это снизило количество повторных запросов и позволило рабочему процессу Kimi Code двигаться стабильно.
Подробнее о возобновлении сессий, переключении между ними и управлении контекстом с помощью /compact и связанных команд см. в руководстве по сессиям Kimi Code CLI.
Уроки, извлечённые при пересборке moonshot.ai
Если бы мы проводили похожее визуальное обновление moonshot.ai снова, некоторые вещи мы сделали бы иначе.
Начинать с контекста, а не с кода
Первый час, потраченный на документирование объёма работ, ограничений и договорённостей, сэкономил больше времени, чем любые последующие промпты. Заложенная заранее основа сделала работу инструментов вроде Kimi Code CLI более стабильной на протяжении всего процесса.
Подключать источник достоверных данных как можно раньше
В нашем случае это была Figma. В других проектах это может быть CMS, внутренний API или дизайн-система. Главное — обеспечить, чтобы система работала с реальными данными, а не с предполагаемыми допущениями, особенно при использовании ИИ-агента для написания кода в контексте фронтенд-рефакторинга.
Держать контекст дизайна и задач в одном цикле
Объединение токенов, спецификаций и реализации в общем контексте сократило количество согласований и сделало циклы итераций более стабильными. Именно здесь рабочие процессы с Figma MCP и Kimi Code CLI показали себя особенно эффективно, помогая удерживать замысел дизайна и изменения кода в согласованном непрерывном цикле.
Если вы не хотите писать код: Kimi Websites
Всё описанное выше — это рабочий процесс, ориентированный на разработчиков: терминалы, дифы и файлы контекста. Однако тот же результат — аккуратный, адаптивный сайт — можно получить и без этого стека, когда скорость важнее контроля на уровне фреймворка.
Kimi Websites работает на той же модели Kimi K2.5, но через визуальный интерфейс без написания кода. Вы описываете желаемый результат на естественном языке, уточняете разделы в диалоге и публикуете сайт одним нажатием. Также можно подать на вход скриншот существующего сайта, и система восстановит структуру макета.
Для основателей, прототипирующих лендинги, или маркетологов, запускающих сайты кампаний в жёсткие сроки, это более быстрый путь, чем работа напрямую с традиционным фронтенд-стеком.
Заключение
Kimi Code CLI и Kimi K2.5 оказались наиболее полезны в тех частях проекта, где охват был важнее сложности. Визуальное обновление редко связано со сложными задачами — это множество небольших изменений, которые должны оставаться согласованными по всей системе. Для человека это трудоемко, но относительно хорошо подходит для агента, способного отслеживать и сравнивать данные в разных файлах.
Решения по-прежнему принимали мы, каждое изменение проверялось нами же, и итоговый результат тоже проходил нашу проверку. Агент занимался повторяющимся отслеживанием, сравнением и первичной проверкой. На практике такое разделение труда оказалось практичным способом внедрить ИИ-агента для написания кода в производственный процесс. Такой подход показал себя полезным для рефакторинга между файлами, проверки соответствия дизайна коду и масштабной работы по обеспечению согласованности.