Привет! Меня зовут Игорь Росляков, я технический писатель. По приглашению тимлида DevRel‑команды Владимира Верхотурова готовлю цикл статей на тему ИИ‑ассистированной разработки решений для Битрикс24.

Сегодня сравниваем 2 варианта работы с ИИ в своей CRM:

  • Работа с внешним GPT‑инструментом. Мы описываем нейросети всю нашу ситуацию, передаём скриншоты, настраиваем интеграцию, ставим задачу, корректируем результат.

  • Работа с уже интегрированной платформой для ИИ‑работы, у которой уже есть все необходимые доступы к CRM.

Под «внешним GPT» в статье я буду понимать ИИ‑агента, который работает без интеграционного слоя CRM. Тот же агент можно подключить через Вайбкод — тогда платформа передаст ему инструменты, права и контекст Битрикс24.

Для примера будем работать с бизнес‑порталом системы Битрикс24 и платформой для вайбкодинга Битрикс24 Вайбкод.

Содержание

Варианты работы с CRM через ИИ

«Использование ИИ в CRM» может означать разные процессы — от копирования текста в чат до создания полноценного приложения. Вот несколько примеров того, как это может быть реализовано на разных уровнях.

Работа с внешним чатом. Для этого нужно копировать в чат с нейросетью данные, задавать вопросы, просить написать текст письма или фрагмент кода. Между ИИ и CRM нет связи.

Работа с ИИ‑агентом разработки. В этом варианте агент может создавать приложение или скрипт, который подключается к CRM через API. Для этого нужно настроить авторизацию, разобраться со структурой данных, проверить методы и самостоятельно развернуть приложение.

ИИ внутри CRM‑платформы. Такой ИИ понимает окружение, может использовать подготовленные инструменты платформы и обращаться к данным CRM по заданным разработчиками платформы правилам.

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

Посмотрите, чтобы создать приложение для CRM, ИИ должен понимать много вещей, например:

  • Какие сущности существуют в системе. Это могут быть сделки, лиды, контакты и задачи.

  • Как получить доступ к этим сущностям.

  • Где разместить интерфейс приложения.

  • Как запустить и проверить результат.

Стороннему ИИ весь этот контекст приходится передавать вручную. Если у CRM есть платформа для вайб‑кодинга, она передаёт агенту подготовленные инструменты для работы с Битрикс24 и доступ к выбранным пользователем разделам CRM. Агенту не нужно самостоятельно настраивать соединение с порталом и изучать способ авторизации.

Что сделаем в статье

Мы на практике посмотрим разницу между ИИ‑агентом, который работает без контекста, и нейросетью, которую подключили к CRM через платформу вайб‑кодинга.

У нас уже есть приложение, которое мы делали с помощью специального стартера для AI‑разработки. Это репозиторий с шаблоном готового приложения, который упрощает разработку кастомизаций, но всё же находится снаружи системы. Посмотреть репозиторий можно здесь: github.com/bitrix‑tools/b24-ai‑starter.

Внутри репозитория со стартером подключены библиотека JS SDK и официальный UI Kit для использования графических элементов в стиле платформы. Ещё здесь есть подробные инструкции для ИИ‑агентов о том, как и что создавать и подключать в портал Битрикс24.

Дальше мы кратко рассмотрим, на какие этапы делилось создание проекта со стартером, и повторим такой же проект с платформой Битрикс24 Вайбкод. В конце попробуем сравнить оба подхода.

Как ставится задача:

  • Внешний агент получил подробности про JS SDK, встройки, методы и архитектуру.

  • Агент через Вайбкод получил задачу на языке результата: что показать в карточке и какие данные посчитать.

Разработка через ИИ‑агента снаружи платформы

Стартер избавляет от создания проекта с нуля, но значительную часть интеграции всё равно нужно настраивать и контролировать вручную.

Подготовка локального окружения

Сначала нужно установить Docker, Git и make, скопировать репозиторий стартера и запустить мастер настройки. 

Затем подключается CloudPub: технология, которая работает как туннель между приложением и Битрикс24. CloudPub выдаёт публичный HTTPS‑адрес, через который Битрикс24 может открыть приложение, запущенное на локальном компьютере.

Регистрация приложения в Битрикс24

После настройки проекта нужно вручную создать локальное приложение на портале. Для этого нужно указать адрес основного обработчика и отдельный адрес страницы установки, выдать права на CRM и встраивание приложений, а затем перенести CLIENT_ID и CLIENT_SECRET в настройки проекта.

Выбираем права и указываем адреса приложения, которые получили с помощью CloudPub
Выбираем права и указываем адреса приложения, которые получили с помощью CloudPub
Копируем CLIENT_ID и CLIENT_SECRET
Копируем CLIENT_ID и CLIENT_SECRET

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

Передача внешнему ИИ контекста проекта

Дальше нужно объяснить агенту, что именно мы создаём, какие возможности стартера существуют и какие ограничения нужно соблюдать.

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

Сборка приложения

На этом этапе агент меняет проект‑шаблон: настраивает сценарий установки, регистрирует встройки, добавляет загрузку сделок и создаёт страницы дашбордов для контакта и компании.

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

Исправление ошибок в архитектуре и API

Даже с вшитыми инструкциями для ИИ внутри стартера агент не всегда учитывает особенности платформы. 

Например, сначала он регистрировал встройки на главной странице приложения, из‑за чего они могли переустанавливаться при каждом открытии. Регистрацию пришлось перенести в отдельный сценарий установки. В другом случае агент использовал метод crm.deal.list, который не полностью учитывал сделки, связанные с несколькими контактами. 

В итоге агент всё сделал правильно, но результаты нужно было отслеживать и проверять самостоятельно.

Результат внешнего GPT

Мы получили приложение с вкладками в карточках контакта и компании. Оно загружает связанные сделки и показывает полученную, потерянную и потенциальную выручку.

AI‑стартер заметно сократил объём разработки, и создавать кастомизации уже сильно удобнее, чем делать это с нуля: в проекте есть структура приложения, библиотеки Битрикс24 и инструкции для агента. Но перед началом работы мне пришлось подготовить локальное окружение, подключить публичный HTTPS‑туннель, зарегистрировать приложение на портале, выдать ему права и перенести параметры авторизации в проект.

Во время разработки я контролировал выбор API‑методов, размещение встроек и сценарий установки. Внешний агент может писать код, но не видит всей цепочки между проектом и CRM. Поэтому ошибка в настройках портала выглядела для него как ошибка программы, а отдельные особенности Битрикс24 приходится объяснять вручную.

Приложение работало через локальное окружение и CloudPub. Для постоянного использования его нужно отдельно разворачивать на сервере.

Разработка через платформу вайбкодинга

Для разработки этим способом нам понадобится подписка BitrixGPT + Маркетплейс. 

Создаём ключ

Платформу можно связать с любым ИИ‑инструментом через API‑ключ:

При создании ключа можно ограничить его возможности, выбрав нужные скоупы под свою задачу. Это права доступа, которые получит приложение:

Почитать про скоупы можно самостоятельно — или попросить агента изучить их ограничения в зависимости от нужного приложения и выбрать нужные. Описание скоупов можно посмотреть на странице документации vibecode.bitrix24.tech/docs/scopes

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

API‑ключ служит не только способом авторизации. Через него агент получает набор инструментов платформы Вайбкод и разрешение работать с выбранными разделами портала. Платформа знает, как обращаться к сущностям Битрикс24, где размещать приложение и как готовить к запуску. Поэтому пользователю не нужно вручную передавать вещи вроде CLIENT_ID, CLIENT_SECRET, адрес туннеля и описание всей интеграционной архитектуры.

Пишем запрос агенту

Вместе с ключом можно сразу запросить приложение у агента:

Создай приложение для Битрикс24. Добавь в карточки контакта и 
компании вкладку с тремя показателями: полученная, потерянная и
потенциальная выручка. Данные рассчитай по связанным сделкам.
Добавь загрузку, сообщение об ошибке и кнопку обновления.
Установи приложение в мой портал.

Нам не нужно называть SDK, REST‑методы, placement и сценарий установки. Выбор технической реализации остаётся платформе и агенту.

Агент почти справился, и приложение уже видно в локальном открытии. Это видно даже в окне разработки, где агент описывает ход работы:

Проблема с деплоем

Небольшая проблема осталась в финальном деплое. ИИ просил зарегистрировать приложение в портале самостоятельно:

Трудность, о которую спотыкается агент, звучит примерно так:

Приложению нужен OAuth-токен пользователя, 
а он рождается только из согласия на портале. 

Тут есть 2 варианта.

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

Отдать агенту дополнительное объяснение, что нужно сделать. Эти инструкции я собрал в ходе другой работы и использую их как скил. Вот ссылка, которую нужно прислать агенту

После этого нейросеть закончила деплой, и приложение появилось на портале:

Проверяем, насколько удобно вносить правки

Дополнительная проверка — добавим новые функции. 

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

Что получилось:

Для доработки не пришлось повторно настраивать интеграцию или объяснять, как получить сделки. Агент уже работал с существующим приложением и подключённой CRM. Я описал изменение на уровне интерфейса, а он обновил приложение и сохранил работу с теми же данными и правами.

Результат

В этом варианте я не клонировал стартер, не устанавливал Docker и make, не поднимал CloudPub и не регистрировал локальное приложение вручную. Я создал ключ с нужными правами, передал агенту задачу и проверил готовый интерфейс.

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

Особенно заметной разница стала при доработке. Чтобы вывести список сделок, я описал только нужное изменение интерфейса. Агент уже знал, откуда получать данные, как устроено приложение и где оно работает, поэтому не пришлось повторно собирать интеграцию.

Итоговое заключение

Понимание CRM появляется из контекста, который платформа выдаёт ИИ‑агенту.

Вайбкод уже знает почти всё: доступные сущности Битрикс24, поддерживаемые способы встраивания, правила работы с API и окружение, в котором запускается приложение. При этом доступ агент получает только к выбранным пользователем разделам портала — через ключ.

Внешний ИИ тоже может создать такое приложение. Для этого ему нужно самостоятельно передать тот же контекст. Нужно подготовить:

  • Репозиторий.

  • Документацию.

  • Авторизацию.

  • Публичный адрес.

  • Права доступа.

  • Инструкции по установке. 

В таком процессе пользователь связывает между собой ИИ, код и CRM и проверяет, правильно ли агент понял каждый слой.

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

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

Комментарии (0)