«Не просите модель построить все ваше приложение. Разбейте запрос на более мелкие части и создавайте по одной функции, хуку или компоненту за раз».
Вы, наверное, слышали этот совет, если использовали для написания кода инструменты искусственного интеллекта, такие как Copilot или ChatGPT. Это хороший совет, потому что меньшие подсказки, как правило, дают более чистый результат и меньше галлюцинаций. Они также дают вам больше контроля над тем, что попадает в вашу кодовую базу.
Однако даже если ваши подсказки очень информативны, а фрагменты выглядят хорошо, этот рабочий процесс в конечном итоге сталкивается с тем же ограничением. Без всеобъемлющей архитектуры, которая связывает все воедино, ничто не будет связано в масштабе.
Каждый раз, когда вы начинаете новый чат, вы создаете изолированные фрагменты кода без общей памяти, истории версий или согласованности. Как только чат заканчивается, модель забывает, что построила. Когда вы позже вернетесь, чтобы расширить или повторно использовать этот код, зачастую проще создать что-то новое, чем улучшить то, что уже существует.
А что, если бы ваш рабочий процесс ИИ не приходилось каждый раз начинать с нуля? Что, если бы у каждой сгенерированной функции, ловушки или компонента был домашний адрес, версия и запись о том, как она использовалась?
Вот что делает возможным компонуемая архитектура. Это дает вашему рабочему процессу ИИ структуру, которая соединяет каждую созданную часть в живую систему. Компоненты становятся многоразовыми, имеют версии и документируются, а ваша работа усложняется, а не исчезает с каждым новым чатом.
В этой статье вы увидите, что происходит, если вы следуете современным подсказкам лучших практик, и почему это по-прежнему создает трудности при масштабировании. Вы узнаете, как компонуемая архитектура закрывает этот пробел, вводя структуру для повторного использования, управления версиями и совместной работы. Вы также узнаете, как BitCloud и Hope AI делают эту систему практичной, создавая модульные компоненты, которые сохраняются за пределами одного проекта.
Почему плоские рабочие процессы ИИ не масштабируются
Рассмотрим компонент React UserAvatar, который генерирует Copilot. Фрагмент системно действителен и функционально завершен:
функция экспорта UserAvatar({ name, img, onClick }) { return (
} ); 1234567 функция экспорта UserAvatar({ name, img, onClick }) { return (
} );
Проблема не в сгенерированном коде; это отсутствие системы для ее организации. Без четкого рабочего процесса для его продвижения вы в конечном итоге получите:
Эти проблемы создают ограничивающий фактор в развитии кода ИИ. Без схемы, сохраняющей контекст, историю версий и зависимости, код, созданный ИИ, не сможет превратиться в повторно используемые или поддерживаемые модули.
Как составная архитектура решает проблемы плоского рабочего процесса ИИ
Компонуемая архитектура обеспечивает структуру, которой не хватает коду, созданному искусственным интеллектом. Вместо фрагментов, удаляющихся после каждого сеанса, каждая часть функциональности становится версионным модулем со своей собственной документацией, тестами и историей. Настойчивость гарантирует, что между сеансами ничего не потеряется. При управлении версиями фиксируется каждая итерация, что позволяет отслеживать изменения. Кроме того, у вас есть понятные интерфейсы и графы зависимостей, которые обеспечивают общий контекст модулей и архитектурную непрерывность, гарантируя, что система растет как одна организованная библиотека, а не как куча несвязанных фрагментов.
Плоский рабочий процесс искусственного интеллекта и составной рабочий процесс.
Давайте возьмем, к примеру, пользовательский интерфейс электронной коммерции. В составном рабочем процессе Button, Card и ProductTile определяются и публикуются как независимые модули. Разработчик обновляет кнопку, чтобы улучшить доступность клавиатуры. Прежде чем изменение будет опубликовано, система покажет, какие компоненты зависят от Button и какие приложения будут затронуты. Разработчик открывает запрос на изменение, тестирует кнопку отдельно и в независимых компонентах, отмечает новую второстепенную версию и публикует ее. Потребители этой кнопки могут затем выбрать новую версию или остаться на предыдущей.
В то же время дизайнер, просматривающий библиотеку компонентов, видит существующие варианты карт, примеры использования и тестовое покрытие. Они расширяют существующий вариант карты, а не перестраивают его, и отправляют на рассмотрение. Библиотека записывает историю изменений, график зависимостей и опубликованные версии, поэтому каждое изменение видно и отслеживается.
При такой структуре изменения проходят через четкие контракты и общие версии, превращая разрозненные фрагменты в единую систему, которая развивается с каждым обновлением.
Как создавать многоразовые компоненты с помощью бита
Создание скаффолдинга в Bit основано на оперативном и ориентированном на архитектуру рабочем процессе. Приведенные ниже шаги показывают, как использовать Hope AI в Bit Cloud для формирования, структурирования и управления повторно используемыми компонентами таким образом, чтобы ваша кодовая база оставалась модульной и удобной для сопровождения.
1. Начните с подсказки
Каждый компонент начинается с четкого запроса. Надеюсь, ИИ воспользуется вашей подсказкой в качестве первого задания, чтобы понять, что нужно построить. Он должен как можно проще описывать основную функциональность и назначение компонента.
Например, вы можете предложить:
Создайте компонент карточки товара с изображением, названием, ценой и кнопкой «Добавить в корзину» для сайта электронной коммерции. 1. Создайте компонент карточки товара с изображением, заголовком, ценой и кнопкой «Добавить в корзину» для сайта электронной коммерции.
Когда вы отправляете запрос, Hope AI не генерирует код сразу. Вместо этого он интерпретирует ваш запрос и начинает формировать архитектурный план компонента.
2. Обзор предлагаемой архитектуры
В Bit Cloud Hope AI предоставляет архитектуру, которая определяет структуру перед любой реализацией. Сюда входят задействованные модули, интерфейсы между ними и зависимости, на которые они полагаются.
Изображение, показывающее архитектуру, созданную Hope.
На этом этапе вы проверяете предлагаемую архитектуру, чтобы убедиться, что она соответствует назначению компонента, соответствует логической структуре и при необходимости соединяется с существующими модулями. Это дает вам четкое представление о том, как будет создаваться компонент и как он вписывается в систему.
3. Создайте компонент
Как только вы одобрите архитектуру, Hope AI создаст фактическую реализацию, которая представляет собой полностью структурированный модуль.
Интерфейс Bit Cloud отображает документацию созданного компонента, карту зависимостей, ссылки на API и покрытие тестов. Каждый компонент существует как отдельная единица с четким жизненным циклом, что упрощает обновление, тестирование и повторное использование без необходимости копаться в коде приложения.
4. Повторное использование существующих компонентов
Чтобы расширить систему дизайна, вы можете попросить Hope AI опираться на существующую работу:
Создайте сетку продуктов, используя @hackmamba-creators/design.content.card.
Надеюсь, ИИ обнаружит ссылку, поймет зависимость и соединит новый компонент с существующим. Это означает, что новая сетка продуктов наследует правила оформления и шаблоны дизайна исходного компонента карты, сохраняя при этом установленный интерфейс.
5. Версия и совместная работа
Когда компонент готов, вы открываете Запрос на изменение для проверки реализации. Именно здесь Ripple CI от Bit автоматизирует управление в масштабе. Он не просто запускает тесты; он автоматически определяет истинный «радиус взрыва», сопоставляя каждый компонент и приложение, на которые повлияют ваши изменения, и проверяя их. Это дает вам 100% уверенность в выпуске.
Повторное использование компонента извне.
После публикации в Bit Cloud ваш компонент становится первоклассным «цифровым активом» в «Фабрике цифровых активов» вашей организации. Каждый ресурс хранится в виде пакета с поддержкой версий, сохраняя свою структуру и контракты независимо от того, где он используется. Он остается доступным для обнаружения, документирования и управления версиями, что позволяет командам уверенно повторно использовать компоненты в различных проектах и средах.
Сравнение ключевых характеристик составных ИИ и плоских рабочих процессов ИИ
Основное различие между плоскими и составными рабочими процессами ИИ заключается в оперативности и настойчивости. В плоских рабочих процессах приоритет отдается быстрой генерации кода, а в составных рабочих процессах основное внимание уделяется структуре, повторному использованию и долгосрочной поддержке.
Вот наглядное сравнение:
- Скорость: Плоские рабочие процессы искусственного интеллекта ориентированы на мгновенное получение результатов, быстрое создание кода с минимальным предварительным планированием. Напротив, составные рабочие процессы тратят немного больше времени на определение структуры, что экономит время на протяжении всего проекта.
- Упорство: Плоские рабочие процессы искусственного интеллекта не сохраняют созданное. Фрагменты живут только в текущем контексте и впоследствии исчезают. Между тем, компонуемые рабочие процессы создают документированные компоненты с поддержкой версий, которые сохраняются в разных сеансах и проектах.
- Портативность: Код, созданный с помощью плоских рабочих процессов ИИ, привязан к одному проекту или контексту, в то время как компонуемые рабочие процессы создают компоненты, которые плавно перемещаются между проектами, не нарушая зависимостей.
- Сотрудничество: В плоских рабочих процессах искусственного интеллекта отсутствует общий источник истины, что приводит к дублированию вариантов и ручным исправлениям. В то время как компонуемые рабочие процессы публикуют компоненты в виде общих модулей, что упрощает совместную работу между командами и проектами.
- Масштабируемость: Плоские рабочие процессы ИИ фрагментируются по мере роста кодовой базы, что усложняет обслуживание. Компонуемые рабочие процессы легко масштабируются за счет многократно используемых, совместимых строительных блоков.
Лучшие практики
Хорошей практикой является разбиение подсказок на более мелкие части. Это помогает уменьшить количество ошибок и держать код под контролем, но не решает более глубокую проблему. Без архитектурного уровня выходные данные ИИ остаются одноразовыми. Код, который работает сегодня, завтра часто фрагментируется.
Компонуемая архитектура заполняет этот пробел. Рассматривая каждую созданную искусственным интеллектом деталь как компонент с жизненным циклом, вы переходите от изолированных фрагментов к системе, ценность которой растет. Bit and Hope AI делают этот подход практичным, создавая компоненты, которые документируются, имеют версии и доступны для совместного использования с самого начала.
Преимущество этого подхода — структурная целостность. Вместо того, чтобы разбрасывать недолговечные фрагменты по проектам, ваш рабочий процесс ИИ создает библиотеку повторно используемых модулей и взаимосвязанных строительных блоков. Этот сдвиг превращает код, сгенерированный ИИ, из временного решения в модульную архитектуру, которая со временем усложняется, предлагая более устойчивый способ управления кодом в эпоху разработки с помощью ИИ.
Если вы уже экспериментируете с инструментами ИИ в своей повседневной работе, это следующий шаг. Попробуйте компоненты каркаса и посмотрите, как компонуемый рабочий процесс меняет путь развития вашего кода.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Имея двадцатилетний опыт работы в отрасли в качестве специалиста по данным, разработчика программного обеспечения и менеджера по исследованиям и разработкам, а также почти десятилетний опыт руководства в Bit, Лали специализируется на использовании генеративного искусственного интеллекта и архитектуры данных для создания и масштабирования технологических продуктов. Ее работа… Читать далее от Лали Бар-Илан
