← Назад в журнал

Слой макета, который холст прежде скрывал

Ответ участника сообщества на preview 0.8.0 назвал настоящий вопрос, стоящий за agent-native дизайном: если холст перестаёт быть единицей работы, как пользователи по-прежнему понимают макет?

Слой макета, который холст прежде скрывал

Полезный ответ сообщества не просит кнопку побольше. Он называет недостающий слой.

Именно это и произошло в обсуждении Open Design 0.8.0-preview. Стартовая ветка отстаивала два сдвига: перестать относиться к холсту как к основной единице работы и сделать агента первоклассным дизайн-работником. Один из ответов согласился с направлением, а затем указал на сложную часть: когда холст исчезает, пользователям всё равно нужен способ понять, что именно сделал агент, прежде чем они смогут уверенно это редактировать.

Фраза в ответе была «Layout Understanding Layer» (слой понимания макета). Это хорошее название, потому что оно отвергает ленивый ответ. Agent-native дизайн не может означать «доверяй скриншоту». Ему нужна читаемая модель артефакта: секции, замысел, редактируемые части, стабильные ссылки и предлагаемые правки. Этот пост — попытка отнестись к тому ответу всерьёз: набросать, что мог бы нести такой слой, где ему место в Open Design и почему это путь для вклада, а не обещание в дорожной карте.

Холст давал дизайнерам пространственную уверенность

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

Что вы на самом деле теряете, когда холст исчезает

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

«Сделай hero увереннее» полезно только в том случае, если агент и человек сходятся в том, что такое hero. «Подтяни секцию цен» работает только тогда, когда артефакт несёт стабильную идентичность секции между ревизиями. Без этого каждая инструкция вырождается в указывание пальцем: дизайнер описывает область по её положению («второй блок сверху»), агент догадывается по отрендеренному результату, а следующая регенерация тихо перенумеровывает всё заново. Холст раньше молча поглощал эту цену. Он называл части за вас, удерживал эти имена стабильными, пока вы работали, и позволял выбрать одну из них без описания.

Ясность стоит сохранить, даже если единица выбрана неверно

Это та часть аргумента #DeFigma, которая требует осторожности. Холст, возможно, неверная единица работы для agent-native системы — он предполагает человека, перетаскивающего прямоугольники, а не агента, пишущего файлы — но ясность, которую люди получали от холста, по-прежнему ценна. Ошибкой было бы относиться к «отказаться от холста» и «отказаться от понимания, которое холст давал» как к одному и тому же решению. Это не так. Open Design должен перенести эту ясность в модель артефакта, а не выбросить её. Слой макета — это название для такого переноса.

У Open Design уже есть нужные примитивы

Причина, по которой это предложение вписывается в Open Design, в том, что проект уже построен вокруг явных контрактов. Навык — это файл SKILL.md. Дизайн-система — это файл DESIGN.md. Плагин добавляет сопроводительный файл open-design.json. Ничто в системе не является бинарным блобом, который приходится реверс-инжинирить; контракты — это текст, а текст может прочитать и агент, и человек. Механика описана в 31 навык, 72 системы: как работает библиотека Open Design, а продуктовый аргумент — в Почему мы построили Open Design как слой навыков, а не как продукт.

Слой макета должен следовать тому же паттерну. Это должен быть текст, который может прочитать агент, состояние, которое может отрендерить интерфейс, и метаданные, которые может переиспользовать другой агент. Если он не может удовлетворить все три условия одновременно, у него неправильная форма.

В терминах репозитория это указывает на три поверхности:

ПоверхностьЧто она должна нести
Манифест артефактаСтабильные ID для секций, компонентов, ассетов и сгенерированных файлов
Снимок плагинаКакой навык, дизайн-система, входные данные и стадии конвейера произвели артефакт
Интерфейс проверки / headless-выводКарта макета, редактируемые аспекты и предлагаемые правки

Важное ограничение: слой не должен превратиться во второй проприетарный холст. Режим отказа, которого нужно избегать, — это перестроить граф сцены Figma под новым именем: богатую, специфичную для приложения структуру, которую может отрендерить только интерфейс Open Design и которая умирает в тот момент, когда вы покидаете приложение. Вместо этого слой макета должен быть простой картой артефакта, которая путешествует вместе с файлами, чтобы участник мог прочитать её в текстовом редакторе, а другой агент мог потребить её без SDK.

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

Практическая форма слоя макета

Вот наименьшая версия, которая сделала бы agent-native дизайн менее непрозрачным:

  1. Каждый сгенерированный артефакт получает стабильные семантические ID: hero, proof-strip, pricing, faq, final-cta.
  2. Каждый ID несёт предложение о замысле: «Объяснить обещание продукта на одном экране», а не «верхняя секция».
  3. Каждая секция перечисляет редактируемые аспекты: текст, плотность, макет, цвет, медиа, движение, источник данных.
  4. Каждый сгенерированный файл ссылается обратно на ID секции, которая его произвела.
  5. Каждый проход проверки выдаёт предлагаемые правки: «сократить заголовок hero», «увеличить контраст в карточках цен», «разделить блок отзывов».
  6. Интерфейс рендерит это как навигатор, а headless-пользователи получают ту же структуру в виде JSON или Markdown.

Как мог бы выглядеть манифест

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

{
  "artifact": "landing/index.html",
  "producedBy": { "skill": "magazine-poster", "system": "linear", "stage": "compose" },
  "sections": [
    {
      "id": "hero",
      "intent": "Explain the product promise in one screen",
      "editable": ["copy", "density", "media"],
      "files": ["landing/index.html#hero", "landing/hero.css"]
    },
    {
      "id": "pricing",
      "intent": "Let a visitor self-select a plan without scrolling back",
      "editable": ["copy", "layout", "data-source"],
      "files": ["landing/index.html#pricing", "landing/pricing.json"]
    }
  ],
  "suggestedEdits": [
    { "target": "hero", "intent": "shorten headline to one line" },
    { "target": "pricing", "intent": "drop from three plans to two" }
  ]
}

Ни один из этих ключей не является экзотическим. sections — это список, editable — это enum, files — обратная ссылка. Ценность не в изобретательности схемы — она в том факте, что ID переживают регенерацию, поэтому тот же блок pricing остаётся pricing после того, как агент перепишет его дважды.

Этого достаточно, чтобы дизайнер мог сказать: «Измени pricing с трёх планов на два», и достаточно, чтобы код-агент пропатчил нужный файл, не догадываясь по пикселям. Инструкция разрешается в ID секции, ID секции разрешается в набор файлов, и правка приземляется там, где и было задумано.

Почему это путь для вклада, а не запрос функции

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

Что делать дальше

Если это та проблема, над которой вы хотите работать, внесите небольшой навык или плагин, который облегчает осмотр одного артефакта. Начните с конкретного результата: лендинга, презентации или мобильного экрана. Добавьте стабильные ID секций, опишите редактируемые аспекты, выдайте их в виде JSON или Markdown рядом с артефактом и откройте PR с артефактом «до/после», чтобы проверяющий увидел разницу, которую вносит осматриваемый слой.

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

Внесите навык.

Связанное чтение


← Назад в журнал GitHub · Источник ↗