Команды разработчиков десятилетиями встраивали детерминизм в свои инструментальные цепочки. Lockfile для менеджеров пакетов. Pinned базовые образы для контейнеров. Воспроизводимые сборки для компилируемых артефактов. Принцип хорошо понятен: одинаковые входные данные должны производить одинаковые результаты — всегда, на любой машине, в любое время.

Дизайн-хэндофф никогда не применял этот принцип. По умолчанию это фундаментально человеческий, а значит, недетерминированный процесс. Дизайнер объясняет дизайн разработчику. Разработчик интерпретирует его. Интерпретация варьируется в зависимости от человека, дня, ясности комментария в Zeplin. Это нельзя воспроизвести. Нельзя протестировать. Нельзя сравнить с помощью диффа.

В мире AI-кодирующих агентов недетерминированный хэндофф теперь является первоклассной инженерной проблемой. figmascope решает её с помощью замороженного, портативного контекстного бандла.

Почему текущий инструментарий недетерминирован для агентов

Zeplin и Avocode дают числа, извлечённые из Figma — размеры слоёв, значения цветов, размеры шрифтов. Но они подают их через пользовательский интерфейс, а не как машиночитаемый артефакт. Агент, направленный на Zeplin, должен навигировать по UI для поиска значений, что хрупко, ограничено по скорости запросов и зависит от того, как написаны аннотации.

Figma Dev Mode идёт дальше: он даёт фрагменты кода, сгенерированные встроенно из дизайна. Но фрагменты не имеют состояния — перегенерируются по запросу, не версионируются. Нет бандла, который можно закоммитить. Нет файла, который можно сравнить с помощью диффа. Если дизайнер обновляет дизайн, вид Dev Mode тихо обновляется. Вы не знаете, когда изменился базовый дизайн относительно последнего вашего экспорта.

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

Живые MCP-соединения — инструменты, дающие агентам реальный API-доступ к Figma-файлу в режиме реального времени — недетерминированны по определению. Файл изменяется, пока агент его читает. Запуск агента в 9:00 и в 14:00 видит разные входные данные. Вы не можете воспроизвести запуск 9:00, потому что источник изменился.

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

Бандл как единица компиляции

Правильная ментальная модель для экспорта figmascope — это артефакт компиляции. Так же, как компилятор берёт исходный код и производит детерминированный бинарник — один исходник, одни флаги, один бинарник — figmascope берёт состояние Figma-файла и производит детерминированный бандл: одно состояние файла, один бандл, каждый раз.

Бандл — замороженный снимок. Он захватывает конкретную версию дизайна и сериализует каждое релевантное свойство: пространственный макет, идентичность компонентов, привязки токенов, содержимое строк, иерархию. После экспорта бандл неизменен. Figma-файл может измениться; бандл — нет. Если вы хотите включить эти изменения, повторно экспортируйте и получите новый бандл.

Это модель единицы компиляции. Файл дизайна — исходник. Бандл — артефакт. Агенты потребляют артефакты, не источники.

Четыре свойства детерминированного хэндоффа

Снимаемый. Артефакт хэндоффа должен представлять конкретный момент времени. Не «текущее состояние Figma-файла» — именованный, версионированный экспорт. Бандлы figmascope несут _meta.json с временной меткой экспорта и отпечатком того, что было включено. Бандл — снимок, не живой вид.

Портативный. Артефакт должен быть самодостаточным. Без зависимостей от внешних сервисов, живых API или залогиненных сессий. Бандл figmascope — это ZIP из простых файлов: JSON, Markdown, PNG. Вы можете его скопировать, отправить по email, закоммитить в git, прикрепить к PR, передать младшему разработчику или кодирующему агенту без настройки.

Инспектируемый. Детерминированный артефакт бесполезен, если нельзя проверить, что в нём. Каждый файл в бандле человекочитаем. CONTEXT.md — Markdown. tokens.json — W3C-ish структура. Постраничный IR — JSON с понятными именами полей. Инженер может открыть бандл и аудировать точно то, что было сказано агенту. Это качественно отличается от «я вставил скриншот и получил какой-то код».

Воспроизводимый. Два отдельных экспорта из одного и того же состояния Figma-файла должны производить функционально эквивалентные бандлы. Не побайтово идентичные (временные метки разные), но семантически идентичные: одинаковые структуры узлов, одинаковые значения токенов, одинаковый инвентарь компонентов. Если экспортировать дважды из неизменённого файла и бандлы семантически различаются, что-то не так. Это свойство позволяет вам валидировать пайплайн экспорта и ловить регрессии в самом экстракторе.

Как это работает на практике

Дизайнер заканчивает серию экранов спринта. Они экспортируют бандл. Бандл коммитится в репозиторий рядом с тикетом — или прикладывается к задаче в Jira, или кладётся на общий диск, в зависимости от рабочего процесса. В этот момент артефакт хэндоффа зафиксирован. Агент (или разработчик) работает с бандлом, а не с живым Figma-файлом.

В середине реализации дизайнер обновляет три экрана. Не проблема: рабочий бандл разработчика не изменился. Новые экраны получают новый экспорт. Теперь у вас два бандла, и вы можете их сравнить: что изменилось между дизайном, с которого начал разработчик, и текущим дизайном. Именно такая видимость изменений невозможна при рабочих процессах на основе скриншотов или живых соединений.

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

Сравнение бандлов с помощью диффов

Поскольку бандл — простые файлы, он сравнивается как код. Два экспорта одного файла через две версии Figma дают JSON-дифф, который точно показывает, что изменилось:

Это видимость изменений дизайна, которой нет ни в одном текущем инструменте хэндоффа. У Figma есть собственная история версий, но она визуальная и ориентирована на дизайнеров. Дифф бандла структурирован и ориентирован на разработчиков: машиночитаемые данные об изменениях, которые могут управлять автоматическими тестами, обновлять журналы изменений или запускать CI-воркфлоу.

CI/CD для дизайн-хэндоффа

Как только хэндофф становится детерминированным, CI/CD следует естественным образом. Вы можете писать тесты, которые запускаются против бандла: «этот экран должен включать компонент Button/Primary», «этот токен должен быть привязан, а не хардкодным значением», «эта строка должна иметь ключ stringRef». Это статические проверки анализа структурированных данных. Они выполняются за миллисекунды. Они запускаются в пайплайне.

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

Сравнение с MCP

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

Живые соединения означают: контекст агента зависит от того, когда он запускается. Запуск в 9:00 и запуск в 14:00 видят разные данные, если дизайнер работал в течение дня. Вы не можете воспроизвести более ранний запуск. Вы не можете тестировать против фиксированных входных данных. Вы не можете аудировать, что было сказано агенту. Если сгенерированный код неверен, вы не можете отличить «модель сделала плохой вывод» от «дизайн изменился под агентом».

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

Хэндофф для начинающего разработчика

Те же свойства, которые делают бандлы хорошими для AI-агентов, делают их хорошими для разработчиков-новичков в кодовой базе. Начинающий разработчик, которому передали бандл, имеет: полную спецификацию в CONTEXT.md, все значения токенов в tokens.json, все компоненты перечислены со свойствами, все строки с их идентичностью. Им не нужно заходить в Figma-файл. Не нужен аккаунт Figma. Не нужно знать, какой экран авторитетный.

Бандл — полный, самодостаточный рабочий заказ. Такой же, как получил бы агент. Единственное различие в том, что человек его читает, а агент обрабатывает программно — но артефакт идентичен.

Это объединение — один артефакт, потребитель — человек или агент — это и есть смысл. Бандл — единица хэндоффа. Всё остальное — детали реализации.

Смотрите детерминированный хэндофф на практике с Claude Code, Cursor или Aider. Все начинаются с одного экспорта figmascope.