Текст / Бурбон
История и тенденции
С развитием искусственного интеллекта в последние годы ИИ появился во всех сферах жизни. В разработке и оформлении интернета в последние годы также можно увидеть подобные изображенияRico(набор данных аннотаций мобильных приложений) такие общедоступные наборы данных появились для отраслевых исследователей, чтобы лучше проводить академические исследования в сценарии мобильных приложений (приложений), и интеллектуальная генерация внешнего кода является одним из хороших направлений.
В дополнение к некоторым наборам данных, используемым для академических исследований, есть также некоторые интернет-продукты, которые напрямую пытаются предоставлять услуги интеллектуальной генерации кода, стремясь предоставлять услуги генерации кода и в то же время собирать оценку качества кода, созданного службами. которые могут дополнительно оптимизировать себя Обслуживая возможность генерировать код.
- imgcook: Хорошо разбирается в сервисе генерации черновиков кода.
- fronty: Хорошая домашняя страница веб-сайта для создания изображений.
- Yotako: хорошо разбирается в сервисе генерации кода PSD.
Для трех вышеперечисленных продуктов, которые генерируют код, большинство каналов для ввода информации исходят из структурированных дизайнерских эскизов или изображений.В то же время анализ этого ввода также определяет качество конечного вывода, автоматически сгенерированного кода, так как мерить код внутри Что с качеством сборки? Давайте сначала посмотрим, как обычно выглядит наш интерфейсный код.
Структура кода
Обычно структуру кода внешнего интерфейса можно условно разделить на две части: статический код графического интерфейса и код динамической логики.
Статический код графического интерфейса
Статический код GUI обычно состоит из языка гипертекстовой разметки (HTML) и каскадных таблиц стилей (CSS). Описание визуального стиля кода можно сравнить со стилем заполнения каждого узла слоя на этапе проектирования, но описание иерархической структуры обычно уникально для внешнего кода и не может быть отражено на этапе проектирования.
код динамической логики
Внешний логический код (Javascript) обычно представляет собой интерактивный логический код, который часто придает статическому коду графического интерфейса некоторое динамическое интерактивное логическое поведение, что также является наиболее громоздкой частью требований к программной реализации, но такое интерактивное логическое поведение обычно не находится непосредственно в Этап проектирования Воплотите (в инструменте статического проектирования) замысел здесь.
В соответствии с текущей горячей тенденцией бессерверных технологий, еще одна часть кода программирования, с которой столкнется внешний интерфейс, — это разработка серверной части FaaS (функция как сервер), которая включает в себя внешний сбор и обработку данных на стороне сервера в спрос, который находится ближе к задней части программы Процесс кодирования потока данных.
Вышеупомянутые три части кода занимают сегодня большую часть нашего программного контента для внешнего интерфейса.Чтобы реализовать интеллектуальное создание этих кодов, нам нужно две подготовки:
- Структурируйте описания этих кодов и преобразуйте их с помощью описаний данных.
- Извлечение ключевой информации из соответствующих материалов для описания структурированных данных
В этой статье основное внимание уделяется второй части размышлений о сборе информационных данных.Давайте рассмотрим части источников информационных каналов для получения сгенерированного кода.
входной источник информации
В реальном сценарии бизнес-требований информация, к которой мы можем получить доступ до НИОКР, включает следующие части: черновик спроса менеджера по продукту, черновик взаимодействия дизайнера взаимодействия, визуальный черновик визуального дизайнера и окончательное изображение страницы.
Если сравнить процесс информационного потока нашей веб-страницы (программы) с теорией информации, предложенной известным математиком Клодом Шенноном (источник информации-кодировщик-канал-декодер):
- Источник информации соответствует черновику потребности, то есть плановой потребности веб-страницы (программы).
- Кодер соответствует интерактивному черновику, то есть дизайнер взаимодействует с полученными требованиями и оформляет общий дизайнерский вид страницы
- Канал соответствует дизайн-проекту, то есть в качестве канала передачи информации в дизайне дизайнер использует изображение, цвет, текст, звук и т.д.
- Декодер соответствует информационному процессу, который эти каналы, наконец, отображают перед пользователем, чтобы перевести в его собственное понимание, например, понимание определенного функционального компонента в изображении.
Из вышеизложенного видно, что полное получение пользователем информации и понимание приложения происходит из потока информации на различных этапах.Если мы посмотрим только на один канал, мы неизбежно потеряем другой важный информационный контент, что также важно. для получения информации о НИОКР. Точно так же вы смотрите только на визуальный проект, а не на проект требований для исследований и разработок. Очевидно, что требования, реализованные в доставленном коде, часто являются безоговорочными.
Проект требований (PRD)
Проект запроса часто включает в себя функциональные точки запроса внешних и серверных данных, а также является самой примитивной отправной точкой для получения информации о пользователе. Но в основном содержание проекта спроса не может быть описано структурированным образом, а это означает, что мы можем только субъективно переварить и понять содержащуюся в нем информацию Что, если мы ограничим доставку проекта спроса, испытываемого продуктом, чтобы выразить его в структурированный способ?
| отображение данных переднего плана | Логика взаимодействия с интерфейсом | Логика внутренних данных | |
|---|---|---|---|
| Модуль А | Показать поле A, поле B и т. д. | Скрыть, когда поле A отсутствует; при нажатии на модуль отправить скрытую точку | Поле A получается из канала xx и обрабатывается xxx |
Можно видеть, что для запроса структурированного выражения мы можем более легко извлечь информацию, соответствующую конкретным модулям в вышеупомянутых трех частях внешнего кода, с помощью обработки естественного языка (NLP) и других возможностей. в сочетании с конкретной моделью данных полевых запасов.Проанализируйте и структурно опишите важный логический код, который нам нужен.
дизайн макета
Описание содержания черновика проекта относительно простое. В настоящее время некоторые инструменты дизайна, используемые дизайнерами, такие как Sketch, Photoshop, XD и другие программы, сами имеют определенные структурированные описания. Нам нужно только использовать возможности разработчика, которые поставляются с Извлеките эту часть структурированной информации из визуального проекта, преобразуйте ее в нужное нам структурированное описание, а затем заполните ее в нашем визуальном коде статического графического интерфейса.
Интерактивный черновой (моушн) дизайн
В этой статье в основном описывается интерактивный черновик, который может повлиять на динамический эффект и отклик.В отличие от описания статической информации узла слоя в визуальном черновике, интерактивный черновик обычно выражает отклик между состояниями узлов.В некоторых общих случаях инструменты дизайна, которые могут давать интерактивные ответы (такие как AE, Principle), если мы можем извлечь интерактивное структурное описание, сделанное дизайнером в инструменте дизайна, то мы также можем преобразовать его в соответствующее интерактивное поведение в нашем программировании и использовать это часть как часть реализации кода логики интерфейса взаимодействия с интерфейсом.
модель обучения информации
В дополнение к упомянутому выше прямому получению данных с носителя информации, мы также можем обогатить извлеченные нами данные путем обучения модели и обучения на основе нашего опыта.Например, общие веб-компоненты не могут быть описаны в проекте дизайна.Модель извлекает эту часть информации; например, для полей, соответствующих текстовому содержимому в бизнес-домене, мы также можем автоматически сопоставлять статическое текстовое содержимое в проекте проекта с динамическими полями посредством обучения классификации.
изображение
В отличие от вышеупомянутого носителя информации, изображение не содержит структурированных информационных данных, и мы можем только интуитивно получить информацию о решетке пикселей в изображении. Однако с текущими возможностями глубокого обучения мы можем извлечь содержимое (текст, изображение, форму) и атрибуты стиля основных элементов дизайна в изображении.
Кроме того, мы также можем распознать описание информационного содержания цели (компонента), существующего в изображении, путем обучения модели.
текст
Для некоторого статического текстового содержимого в проекте дизайна, если есть связь с динамическим отображением полей, предоставляемым интерфейсом, мы также можем проанализировать текстовое содержимое, которое часто описывает дизайнер, и объединить его с полями данных, которые могут соответствовать содержание конкретного бизнеса, напримерxxx 旗舰店, которые, как мы можем предположить, являются бизнес-данными店铺в источнике данных店铺标题поле, чтобы его можно было автоматически сопоставить с полями в интерфейсе при создании кода.
Структурное описание
Структурное описание относится к продукту (описание данных JSON), извлеченному из приведенного выше проекта дизайна. Когда мы используем статический код GUI для описания страницы или приложения, в дополнение к базовой информации о стиле часто присутствует часть семантической структуры, то есть , структура Layout grouping. На самом деле визуальный набросок не содержит информации о семантике структуры, поэтому нам часто приходится использовать наш прошлый опыт семантики структуры макета для обучения модели получению результатов этой части, чтобы сделать описание структуры макета GUI более семантический.
глубокая связь информации
Существует много источников информации для разумно сгенерированного кода, и каждый канал более или менее тесно связан с окончательным сгенерированным кодом.Если вся информация не может быть переработана и использована, сгенерированный код должен быть неполным. линия также критична.
Ниже приведена попытка сопоставить информацию разных каналов.Видно, что ввод каждого канала можно сопоставить, используя размерность модуля, то есть модуль соответствует статическому коду GUI, внешнему логическому коду. и данные на стороне сервера Логический код и результат определения потенциальных компонентов модели в модуле. Благодаря соединению этой информации, в дополнение к статическому коду пользовательского интерфейса, восстановленному из визуального проекта на самом раннем этапе, код модуля, который мы генерируем, может также комбинировать другую логическую и семантическую информацию для автоматического преобразования статической части в динамическую, чтобы достичь полное назначение кода (привязка полей, идентификация материала модуля, логика рендеринга и т. д.).
Суммировать
После двух лет напряженной работы imgcook продемонстрировал, что можно извлекать информацию из черновика дизайна для автоматического создания части кода графического интерфейса. Тогда как мы можем получить больше информации из других информационных каналов на следующем этапе? Это будет направление которые мы продолжим исследовать, выполняя корреляционный анализ этих информационных точек и создавая полную карту для достижения покрытия и создания более точных кодов.