Чем отличается структурированный контекст от пиксельного при генерации кода

Кодинг-агенты упираются не в возможности моделей. Модели развиваются так быстро, что уже не они — ограничение. Узкое место — контекст, который получает агент. От того, в каком виде вы передадите макет, зависит, получится ли код, который переживёт стык с реальной дизайн-системой. Пока индустрия в основном работает с пиксельным контекстом. Это ошибка.

Пиксельный контекст: что это такое

Пиксельный контекст — любая растровая картинка дизайна: скриншот Canvas, PNG из экспорта фрейма, рендер из инструмента. Vision-модели читают картинки впечатляюще: распознают UI-паттерны, угадывают лэйаут, генерируют правдоподобный код. Вы видели это, если пробовали screenshot-to-code на Claude или GPT-4V. Выглядит правильно чаще, чем ожидаешь.

Но «выглядит правильно» и «правильно» — не одно и то же. Дизайн-система, токены, компоненты, воспроизводимость — всё живёт в зазоре между этими понятиями.

Структурированный контекст: что это такое

Структурированный контекст — типизированное, машиночитаемое представление дизайна, которое сохраняет семантику: что каждый элемент значит, а не как выглядит. Сюда входят:

• Типизированные узлы: каждый элемент имеет тип (FRAME, TEXT, INSTANCE, VECTOR), который определяет его роль в лэйауте.
• Именованные значения: цвета — это ссылки на токены, а не hex-строки; отступы — ключи токенов, а не пиксели.
• Пространственные отношения: направление лэйаута, gap, padding, выравнивание — как свойства, а не догадки по картинке.
• Идентичность: у экземпляров компонентов есть source component ID, у строк — ключи для i18n.
• Иерархия: полное дерево узлов с родительскими связями.

Если коротко: структурированный IR — это эксплицитное дерево дизайна. У каждого узла — kind, name, absoluteBoundingBox, children, заливка, разрешённая в токены, свойства auto-layout, componentId у инстансов.

Пиксельный контекст говорит агенту, как выглядит дизайн. Структурированный — что он означает. Агенту для написания кода нужно значение, а не внешность. Внешность — удел визуальных тестов.

Что теряется на пути от пикселей к структуре

Главная беда пиксельного контекста — необратимая потеря информации. Когда Figma рендерит фрейм в PNG, она выбрасывает ровно то, что нужно для генерации кода.

Схлопывается дерево слоёв. «Группа из трёх элементов с отступами 8px» превращается в «область пикселей, похожую на группу». Агенту приходится заново собирать структуру по визуальным признакам — и он ошибается. С ростом сложности макета растёт и доля ошибок.

Исчезают токены. Оранжевый фон, который должен быть color/action/primary, становится #FF6B00. Агент хардкодит hex. Сменится цвет, появится тёмная тема, понадобится аудит токенов — и это станет болью.

Теряется идентичность компонентов. Четыре инстанса одной карточки выглядят как четыре похожих прямоугольника. Агент может сгенерировать один переиспользуемый компонент, а может — четыре почти одинаковых блока. Вместо предсказуемого результата вы получаете вероятностный.

Намерение лэйаута двусмысленно. Это flex-row или grid? Расстояние между элементами — gap, margin или padding? Пиксели этого не говорят. Агент выбирает наугад — и выбор может отличаться от запуска к запуску.

Сравнение пиксельного и структурированного контекста

Рабочий процесс: два пути

Вот как выглядит типичный путь из Figma в продакшн на React.

С пиксельным контекстом: экспорт PNG, вставка в чат с ИИ, получение JSX. Дальше — ревью, поиск хардкода, исправление структуры, промпты для корректировок. Итерации. Потом ручные правки под дизайн-систему. Шип. Следующий экран — всё заново, потому что прошлые результаты не компонуются.

Со структурированным контекстом: экспорт бандла в один клик, передача CONTEXT.md + IR агенту, системный промпт с правилами фреймворка. Получаете JSX с вашими токенами, именами компонентов и правильной структурой. Ревью — и на прод. Следующий экран — тот же бандл, тот же агент, и результаты теперь компонуются: входы согласованы.

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

Структура — это типизация, пространство и идентичность

Типизация. У каждого узла в IR есть kind. TEXT — текстовый элемент, FRAME с auto-layout — контейнер, INSTANCE — вызов компонента с правильными пропсами. Агент не угадывает, а применяет правила из CONTEXT.md: «для INSTANCE используйте имя компонента, для FRAME с layoutMode HORIZONTAL — flex-row». Это стиль компилятора, а не инференс.

Пространство. absoluteBoundingBox даёт координаты и размер. Вместе с auto-layout-свойствами — gap, padding, alignment — у агента есть всё для корректной вёрстки без подсчёта пикселей. А ещё бандлы позволяют агенту проверять себя: если сгенерированный компонент имеет другие размеры, чем предписано — что-то сломалось. Это проверяемое свойство, которого у пиксельного контекста нет.

Идентичность. Четыре узла с одинаковым componentId — это четыре инстанса одного компонента. Агент создаёт определение один раз, выводит пропсы из вариантов и рендерит четыре вызова. Ссылки на строки stringRef.key превращаются в один i18n-lookup, а не в три захардкоженные строки. Агент просто читает ID — ничего не угадывая.

Честно: пиксели всё ещё нужны

В структурированный бандл входят PNG каждого экрана, но не для генерации кода, а для визуального контроля. Агент сверяет свой вывод с картинкой, разработчику не нужно открывать Figma, чтобы посмотреть на макет. PNG — артефакт QA, а не спецификация.

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

Один дизайн — несколько платформ

Структурированный контекст открывает то, чего не умеют скриншоты: один макет, много целей. Один и тот же IR можно скормить генераторам для React/Tailwind, Jetpack Compose и SwiftUI. Код, специфичный для платформы — примитивы, соглашения об именах, layout API — лежит в CONTEXT.md, который генерируется под каждую цель.

Это масштабируемый мультитаргет. Вы экспортируете один бандл, запускаете три агента с разными CONTEXT.md и получаете три реализации, структурно эквивалентные — потому что они созданы из одного IR, а не из трёх отдельных прогонов по трём скриншотам. Узкое место здесь не возможности модели. Качество контекста — вот что решает. И структурированный контекст — то, что делает этот сценарий реальным.