1. Что еще можно сделать для повышения эффективности НИОКР?
Повышение эффективности исследований и разработок всегда было темой, которой мы занимаемся. От первоначального инструментария до проектирования инженеры делают все возможное, чтобы быстрее писать код для удовлетворения растущих потребностей бизнеса, а затем различные платформы, такие как небольшие программы. , инженеры приступили к поиску решений для унифицированной разработки с несколькими терминалами, что позволяет нам писать код, работающий одновременно на нескольких терминалах, что еще больше повышает эффективность. Но бизнес персонализации по-прежнему стремительно растет, поэтому мы не можем не спросить, как мы можем продолжать внедрять инновации для повышения эффективности наших исследований и разработок.
Мы думаем о «поиске изменений». В то время, когда интеллектуальное мышление становится все более и более популярным, традиционные методы НИОКР и повышения эффективности сталкиваются с узкими местами. Можем ли мы решить эту проблему с помощью интеллектуального мышления? Мы задумались, поскольку путь к более быстрому написанию кода, кажется, почти ушел, можем ли мы реализовать генерацию кода на основе средств ИИ, чтобы мы могли писать меньше кода, поэтому направление нашего исследования свернулось в сторону «Front-end» + « интеллект», надеясь расширить круг передовых возможностей за счет возможностей искусственного интеллекта и машинного обучения, открыть рабочий процесс проектирования и исследований и разработок и добиться крупномасштабного производства.
2. Умный код – избранная дорога?
Проект смарт-кода Deco - это исследование нашей команды в направлении «интерфейсного интеллекта». Мы стараемся начать с точки входа Design To Code и дополнить существующий дизайн исследованиями и разработками. Чтобы повысить эффективность производства и исследований.
В ежедневном процессе разработки требований часто необходимо следовать фиксированному набору рабочих процессов: продукт представляет PRD требования, дизайнер взаимодействий выводит интерактивный черновик в соответствии с PRD, затем визуальный дизайнер выводит визуальный черновик продукта и затем входит в рабочий процесс фронтенд-разработки. Для интерфейсных инженеров источником ввода является визуальный проект + PRD, а выходом — код онлайн-страницы.
То, что Deco рассчитывает решить, — это работа, которая имеет относительно низкую ценность для фронтенд-инженеров в описанном выше процессе и может быть решена с помощью идеи повторного использования:
- восстановление мокапа UI, т.е. рефакторинг страницы, написание HTML+CSS;
- Многоразовая привязка бизнес-логики;
- Идентификация и замена существующих компонентов в эскизах проекта
Взяв за отправную точку «код создания черновика дизайна», мы изучаем использование интеллектуальных решений для замены традиционной ручной реконструкции страницы (анализ стилей слоя + вырезание изображений и т. д.), надеясь извлечь структурированную информацию из исходной информации визуального черновика. , Описание данных, а затем в сочетании с различными интеллектуальными алгоритмами для вывода поддерживаемого кода страницы.
После первоначальной проверки крупного продвижения 618 продвижения деко был постоянно обновлен и полированный. Он широко используется в исследовании и развитии персонализированных площадок на двойной 11, охватывающий около 90% модулей пола большого продвижения, принося 48% бизнес-исследований и разработок. Улучшения эффективности.
3, как реализовать программу, предназначенную для генерации выданного кода
3.1 Генерация статического кода
Первым шагом в интеллектуальном создании кода из черновика проекта является создание статического кода, и суть этого шага заключается в том, как создать информацию «описание структурированных данных» на основе черновика проекта Эти данные называются схемой D2C.
Проект дизайна Deco интеллектуально генерирует статический код в основном для двух целей:
- Извлечение «описаний структурированных данных» из визуальных элементов;
- Выразите «структурированное описание данных» в виде кода;
По сути, интеллектуальный код Deco извлекает схему D2C из исходной информации визуального проекта с помощью подключаемого модуля инструмента проектирования, а затем объединяет систему правил, компьютерное зрение, интеллектуальную компоновку, глубокое обучение и другие технологии для обработки схемы D2C. преобразует его в разумный формат и семантику.D2C Schema JSON данные и, наконец, преобразует в многотерминальный код с помощью синтаксического анализатора DSL.
3.1.1. Обработка эскизного проекта
Документ Sketch — это сжатый документ (суффикс файла «.sketch»), состоящий из метаинформации нескольких слоев (разделенных на «Документ» и «Страницы» и т. д.) и файлов ресурсов (в основном изображений). сервис алгоритма компоновки получен.
Разрабатывая подключаемые модули Sketch, используйте API, предоставляемый Sketch, чтобы помочь нам работать с документами Sketch, а после получения информации о слоях обрабатывать и фильтровать эти данные. Обработка информации слоя в основном делится на два уровня:
- Слой обработки черновика дизайна: разделите символ в черновике дизайна на фактический слой, а затем выполните различную обработку слоя, например фильтрацию невидимых слоев, объединение необходимых слоев, обработку слоев маски и т. д.;
- Уровень обработки информации о слоях: извлечение полезной информации из слоев, преобразование информации, удаление бесполезных слоев, сведение информации о слоях и т. д.
На следующем рисунке показан поток обработки информации слоя:
В дополнение к базовой обработке слоев информации мы установили ряд правил для оптимизации экспорта данных для улучшения макета и разумности семантики. Например, в большом количестве предварительных проектов сложный дизайн фона может быть в группе слоев, состоящей из множества векторной графики (ниже), если эти слои будут получены без изменений, это приведет к большой сложности и неопределенности макета.
В процессе объединения картинок, для ситуации, когда все слои под группой слоев являются векторной графикой, мы объединим ее в одну картинку, что значительно уменьшит сложность компоновки. Окончательный комбинированный эффект изображения выглядит следующим образом:
Конечно, упомянутые выше правила оптимизации не могут удовлетворить все ситуации, ведь дизайнеры свободны. Чтобы повысить рациональность компоновки и семантики, мы предоставляем некоторые стандартные протоколы для эскизов дизайна, которые включены в дизайн для использования дизайнерами и разработчиками.
3.1.2. Восстановление эскиза проекта с помощью алгоритма компоновки
Данные, обработанные подключаемым модулем проекта проекта, должны быть обработаны алгоритмом компоновки, чтобы получить данные выражения структуры кода с хорошим визуальным восстановлением и разумной структурой компоновки.
Данные элемента, экспортируемые подключаемым модулем, представляют собой информацию об элементе, основанную на абсолютном позиционировании верхнего левого угла (0, 0) в качестве начала координат, и в целом (без активной группировки, без распознавания AI и т. д.) элементы Уплощенные, то есть между элементами нет принадлежности.
В процессе разработки интерфейса макет с абсолютным позиционированием не может соответствовать требованиям разработки с точки зрения масштабируемости и удобочитаемости, поэтому, если его не решить, он станет одноразовым кодом. Следовательно, необходим алгоритм компоновки для улучшения масштабируемости и читабельности сгенерированного кода для последующей вторичной разработки.
Алгоритм макета слоя эксплуатационного расхода содержит три этапа: преобразование структуры данных, получение компоновки, вычисления стиля.
Преобразование структуры данных заключается в преобразовании данных схемы JSON в структуру, аналогичную дереву DOM, которое может выполнять операции вставки, удаления и поиска узлов.
Вывод макета должен быть выполнен после обработки преобразования данных.На этом этапе выполняется вывод сегментации строк и столбцов, который обычно включает в себя: алгоритм пространственного расположения, алгоритм расположения проекций, алгоритм расположения фонового изображения, алгоритм обнаружения признаков, алгоритм получения координат, фон уровень и избыточность Алгоритмы обнаружения уровня и многое другое. После того, как макет выведен, структура макета имеет четкие иерархические отношения и смежные отношения, и мы можем получить хорошо сегментированную, разумно сгруппированную и структурированную структуру узлов.
Алгоритм пространственной компоновки
Алгоритм компоновки проекции
После обработки генерации структуры макета необходимо выполнить расчет стиля, который заключается в выполнении ряда вычислений по результатам, полученным через слой создания макета.Например, на основе иерархических отношений главная ось Flexbox и боковая ось могут быть рассчитаны путем вычисления координат; на основе смежных отношений вы можете рассчитать поля и другие стили между соседними. Большинство макетов в стиле Deco используют Flexbox, а в некоторых особых случаях необходимо использовать абсолютное позиционирование.
После обработки алгоритмом компоновки мы можем получить данные Schema JSON с хорошей сводимостью и разумной структурой.
3.1.3 Генерация семантического кода
Когда данные эскиза проекта обрабатываются алгоритмом компоновки, мы можем получить код с лучшей структурой, но в это время мы обнаружим, что код все еще не очень читабелен из-за отсутствия соответствующих имён семантических классов для узловых элементов. Чтобы в итоге получить код, который можно разрабатывать дважды, нам нужно добавить семантическую обработку после алгоритма компоновки, чтобы код имел хорошую семантику.
Первая проблема, которую должна решить семантика, — как добавить имена семантических классов к узлам элементов.
Чтобы достичь этой цели, мы можем сначала просмотреть, как мы добавляли имена классов к узлам элементов во время разработки, взяв в качестве примера следующий график одного продукта.
Изображение выше является примером карты продукта.Мы будем судить, что это продукт, по таким факторам, как изображение, цена и копия под изображением, а затем мы можем присвоить этой области имя класса.goods, а узлам в этой области, например изображениям, можно присвоить имена классовgoods_picИзображение ниже может дать имя классаgoods_tit, цена может быть указана в названии классаprice, которая является нашей общей логикой для добавления имен классов на узлы элементов.
Видно, что когда мы обычно определяем семантику области и компонента, нам необходимо выносить суждение, основанное на семантической комбинации узлов в области.Например, вышеуказанные товарные компоненты должны опираться на внутренние изображения, цены , копирайтинг и другие элементы для определения семантики. , для определения имени класса. Поэтому метод семантической обработки заключается в том, чтобы начать с дочерних узлов элемента-контейнера, сначала определить семантику дочерних узлов, затем вывести семантику элемента-контейнера, вывести слой за слоем и, наконец, вывести полное дерево узлов. .
При семантической обработке нашим основным объектом обработки являются данные схемы JSON, обрабатываемые алгоритмом компоновки, который мы называемдерево компоновки, дерево макета уже имеет хорошую структуру, и мы можем выполнять над ним операции семантического вывода. Процесс вывода начинается с листовых узлов дерева, поднимается слой за слоем к узлам ветвей и, наконец, поднимается к корневому узлу.
В настоящее время наш вывод в основном основан на расположении, стиле, размере, родственных узлах и других факторах узла.В то же время мы будем комбинировать типы разных узлов и комбинировать некоторые интеллектуальные средства для вспомогательного вывода. Например, минимальный листовой узел обычно может быть двух типов: изображение и текст.Для текста мы можем анализировать часть речи и семантику текста с помощью НЛП, для некоторых изображений мы можем использовать классификацию изображений или распознавание для определить классификацию изображения или извлечь изображения.Ключевая информация об изображении используется для определения семантики изображения.
Чтобы определить семантику каждого узла, нам нужно объединить ряд правил разума о существующих фактах (стиль, местонахождение и т. Д.), И в то же время после некоторого ваучинства мы получим новые факты, И нам нужно пройти через другие правила. Только после рассуждения можно получить окончательный результат. Итак, это система рассуждения на основе правил, мы можем реализоватьПередняя цепьМеханизм рассуждений, помогающий нам принимать решения.
Например, в процессе вывода вышеупомянутой товарной компоненты сначала мы сначала находим текстовый узел с ценовым фактором, названным какprice, то находимpriceРядом, в котором закрывается иерархический узел дерева изображения, и продукт соответствует требованиям размера изображения FIG-узла, так что мы можем определить существующие в соответствии с контейнером фиг, характеризующиеся скоростью и контейнерами товаров, затем элемент контейнера в соответствии с Один номер, есть ли текст, и текст анализа NER, мы можем определить, является ли этот текст торговым названием, чтобы определить его имя семантического класса вблизи изображения.
Во всей семантической обработке приведенные выше правила суждения являются лишь верхушкой айсберга.Мы объединили всю сцену электронной коммерции, проанализировали большое количество эскизов дизайна и онлайн-кейсов и суммировали большое количество правил суждения, которые помогут нам. рационализировать семантические имена.В процессе используются методы искусственного интеллекта, такие как анализ НЛП, классификация изображений и распознавание, чтобы помочь в получении более точных семантических псевдонимов.
3.1.4. Создание DSL
После предыдущих шагов мы можем сгенерировать код.Чтобы поддерживать генерацию кодов для разных DSL, мы абстрагируем семантически обработанные данные в данные описания узла, подобные виртуальному DOM, а затем обрабатываем данные описания узла в различные DSL. как код, и в то же время зарезервировать интерфейс для поддержки расширения новых DSL.
генерация кода
3.2 Пусть у кода будет душа
После реализации сгенерированного статического кода мы обнаружим, что некоторые компоненты появятся в рукописете дизайна. Лучший способ состоит в том, что мы можем идентифицировать компоненты в рукописи дизайна, а затем мультиплексировать при генерировании кода.
Чтобы решить эту проблему, мы обратили внимание на глубокое обучение.Используя алгоритмы обнаружения и классификации целей в глубоком обучении, мы можем идентифицировать и находить существующие компоненты в проекте проекта и, наконец, сопоставлять их с компонентами в библиотеке компонентов. , для достижения цели повторного использования компонентов.
Общий поток обработки идентификации и сопоставления компонентов заключается в том, чтобы сначала разумно вырезать исходное черновое изображение проекта на основе визуального алгоритма, идентифицировать блок пользовательского интерфейса, содержащийся в изображении, после вырезанного изображения, а затем сопоставить блок пользовательского интерфейса со схемой JSON. , наиболее вероятный тип компонента идентифицируется алгоритмом классификации для блока, а затем идентификационная информация записывается в узел схемы JSON, чтобы окончательно реализовать идентификацию и сопоставление компонента.
Эффект сопоставления идентификации компонентов
В настоящее время мы завершили подготовку библиотеки большого продвижения бизнес-компонентов, что может точно определить большие составные компоненты в проекте дизайна позиционирования. Тем не менее, мы обнаружили, что если бы мы хотели, чтобы другие предприятия могли получить доступ к идентификации компонентов и сопоставления, было много трудностей, и другие бизнес-команды не имели возможности обработки AI. Если бы мы делаем подготовку компонентов, это значительно увеличит рабочую нагрузку Наша команда. Для того, чтобы решить эти проблемы, мы подумали о том, как поделиться возможностями AI, накапливалась Deco, поэтому мы разработали открытую платформу AI.
Открытая платформа ИИ предоставляет разработчикам беспороговый доступ к возможностям ИИ, таким как классификация изображений и распознавание целей. Разработчики могут создавать настраиваемые наборы данных и управлять ими на открытой платформе ИИ. После выбора предустановленной модели алгоритма они могут напрямую обучить модель.При предварительной оценке, если есть новая библиотека компонентов, которую необходимо обучить, ее можно передать бизнес-группе для работы с ней через открытую платформу ИИ.
3.3. Приземление в бизнесе
На данный момент у нас уже есть общая схема генерации кода из проекта проекта, но до реализации схемы еще далеко.Нам нужна платформа для реализации нашей схемы.Когда есть ошибка в статический код, сгенерированный черновиком дизайна, мы можем передать. Визуальный редактор выполняет вторичные корректировки, и при получении статического кода мы также можем добавить логическую обработку, такую как компонентизация, связывание полей и жизненный цикл.
3.3.1 Компонентизация
Мы можем пометить узел как компонент через функцию "маркировка компонента".После пометки его как компонента мы можем установить состояние и данные в компоненте, задать входные параметры компонента, задать жизненный цикл компонента, и т. д., и, наконец, сгенерировать код, сгенерированный в компонентной форме.
3.3.2 Определение данных
Мы можем определить глобальные данные страницы или внутренние данные компонента в соответствии с нашими потребностями, а также мы можем определить общие данные, установив контекст React.
3.3.3 Асинхронный запрос данных
Для наиболее распространенных сценариев асинхронных запросов данных Deco предоставляет визуальную форму, которая может быстро генерировать код для асинхронных запросов данных с помощью простой настройки.
3.3.4, привязка событий
Deco предоставляет множество событий узлов, включая события щелчков, а также определение событий, таких как жизненный цикл компонентов, и пользователи могут редактировать логический код в событиях.
3.3.5, редактирование свойств и привязка данных
Кроме того, в Deco предусмотрена возможность сопоставления компонентов, на основе которой открываются возможности редактирования свойств и привязки данных компонентов для реализации связи между страницами и динамическими данными.
4. Перспективы будущего
Теперь кажется, что интеллектуальный код — это дорога, которую стоит исследовать. Это семя. Может быть, оно только что проросло в настоящее время, но мы возлагаем на него большие надежды. Мы надеемся использовать Deco, чтобы исследовать дорогу интерфейсного интеллекта. , изучить искусственный интеллект и различные возможности интеграции с интерфейсом, и, что более важно, мы надеемся начать революцию эффективности в производстве и исследованиях с помощью Deco. В то время, когда различные интерфейсные разработки, платформы и методологии становятся все более и более совершенными , мы изучим другие способы снижения бизнес-затрат и повышения эффективности.
В то же время мы усердно работали над интеллектом.Возможно, в будущем мы сможем напрямую реализовать дизайн и доставку, что, несомненно, станет еще одной инновацией для отрасли.
Внешняя среда бета-тестирования была открыта, пожалуйста, нажмитеDecoСсылка на опыт~
Предстоит пройти долгий путь, и для его поиска требуются технические специалисты.