Перейти к содержанию
Разработка

Как научить AI разрабатывать на Битриксе: AGENTS.md, MCP и Skills

Как научить AI разрабатывать на Битриксе: AGENTS.md, MCP и Skills

AI уже способен писать значительные объёмы production-кода. Но качество результата зависит не только от выбранной модели.

Особенно хорошо это заметно в разработке на 1С-Битрикс и Битрикс24.

Можно взять современную coding-модель, попросить её разработать модуль и получить вполне работающий результат. Но без знания архитектуры конкретного проекта, актуального API, внутренних стандартов команды и особенностей Bitrix Framework модель неизбежно будет где-то угадывать.

Поэтому сегодня более интересный вопрос звучит не так:

Какая AI-модель лучше пишет код?

А так:

Какой контекст и какие инструменты нужно дать AI, чтобы он писал код по правилам конкретного проекта?

Для этого постепенно формируется полноценный набор инструментов: AGENTS.md, MCP, специализированные Skills, существующий код проекта и автоматические проверки.

Разберём, как всё это можно использовать при разработке на Битриксе.

Почему Битрикс — сложная среда для AI

1С-Битрикс существует много лет и сочетает несколько поколений архитектурных подходов.

В одном проекте одновременно могут встречаться:

  • современный D7;

  • legacy API;

  • собственные модули;

  • компоненты;

  • инфоблоки;

  • Highload-блоки;

  • ORM;

  • события;

  • агенты и фоновые задачи;

  • Sale;

  • REST;

  • большое количество исторического проектного кода.

Причём технически рабочее решение далеко не всегда является правильным решением для конкретного проекта.

Например, AI может использовать существующий API корректно, но выбрать устаревший подход, нарушить принятую структуру модуля или решить задачу способом, который не соответствует архитектуре системы.

Поэтому одного хорошего промпта недостаточно.

AI-разработчику нужен примерно тот же набор контекста, который мы дали бы новому человеку в команде.

AGENTS.md: правила разработки для AI

Первый уровень такого контекста — AGENTS.md.

Это файл с инструкциями для coding agent, в котором можно описать правила конкретного проекта.

Например:

  • где должен располагаться собственный код;

  • какую структуру модулей использовать;

  • когда применять D7;

  • допустимо ли использование legacy API;

  • как разделяются Controller, Service и Repository;

  • как работать с ORM;

  • правила обработки ошибок;

  • требования к кешированию;

  • логирование;

  • безопасность;

  • naming;

  • PHPDoc;

  • форматирование;

  • правила работы с существующим legacy;

  • какие части системы нельзя изменять.

По сути, AGENTS.md становится onboarding-документом для AI-разработчика.

И здесь возникает довольно важный побочный эффект.

AI заставляет формализовать инженерные правила

Во многих командах значительная часть стандартов разработки существует только в голове ведущих разработчиков.

О них узнают во время code review:

Здесь мы так не делаем.

Для таких задач у нас используется другой сервис.

Legacy API здесь применять нельзя.

Этот код должен находиться в другом слое.

Человек постепенно запоминает эти правила.

AI не сможет их знать, пока они не будут формализованы.

Поэтому внедрение coding agents одновременно заставляет команду привести собственные engineering practices в более системный вид.

И это полезно независимо от AI.

Существующий код проекта как reference implementation

Не все правила обязательно описывать текстом.

Если в проекте уже существует качественно реализованный похожий модуль, его можно использовать как reference implementation.

Например, задача для AI может выглядеть так:

Изучи существующий модуль X. Новый модуль должен использовать аналогичную архитектуру и структуру, но работать с другой сущностью и реализовывать следующую бизнес-логику...

Модель получает сразу большое количество информации:

  • структуру директорий;

  • namespace;

  • naming;

  • используемые API;

  • работу с ORM;

  • установку и удаление модуля;

  • события;

  • контроллеры;

  • сервисы;

  • локализацию;

  • взаимодействие с остальными частями проекта.

Для больших legacy-систем это особенно полезно.

Абстрактный best practice далеко не всегда совпадает с архитектурными решениями, которые необходимо поддерживать в конкретной системе.

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

MCP: AI больше не обязан помнить документацию

Следующая проблема coding-моделей — актуальность знаний.

LLM может хорошо понимать архитектуру решения, но:

  • перепутать название REST-метода;

  • использовать неправильный параметр;

  • придумать несуществующее поле;

  • применить устаревший API.

Один из способов решения этой проблемы — MCP, Model Context Protocol.

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

Официальный MCP Битрикс24

У Битрикс24 уже существует официальный MCP-сервер:

https://apidocs.bitrix24.ru/ai-tools/mcp.html

Он позволяет AI-инструментам обращаться к актуальной REST-документации Битрикс24.

Таким образом, схема работы меняется.

Раньше:

LLM → знания из обучающей выборки → предполагаемый REST API

Теперь:

LLM → MCP → актуальная документация → реальный REST API

Это значительно более устойчивый подход.

Модель больше не обязана помнить весь API Битрикс24. Она должна уметь найти нужный метод и правильно его использовать.

Именно к такой модели работы, вероятно, постепенно будет двигаться большая часть AI-разработки.

MCP для Bitrix Framework

REST API Битрикс24 — только часть экосистемы.

При разработке на «1С-Битрикс: Управление сайтом» регулярно возникает необходимость работать непосредственно с Bitrix Framework.

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

Для AI можно использовать похожий подход.

Один из проектов в этом направлении — BxMCP:

https://camouf.ru/

Его задача — дать AI-агенту возможность получать информацию об актуальном Bitrix Framework:

  • искать классы;

  • проверять методы и их сигнатуры;

  • находить события;

  • исследовать ORM-сущности;

  • обращаться к документации;

  • изучать исходный код.

Для AI это принципиально полезная возможность.

Вместо:

Я предполагаю, что у этого класса есть такой метод.

получаем:

Я посмотрю реальный API и проверю сигнатуру.

То есть задача заключается не в том, чтобы научить LLM всему Bitrix Framework.

Гораздо эффективнее дать модели инструменты для самостоятельного исследования framework.

Skills: от документации к инженерным практикам

Но наличие API ещё не означает умение правильно им пользоваться.

Документация отвечает прежде всего на вопрос:

Что есть в платформе?

При разработке обычно нужен ответ ещё и на другой вопрос:

Как лучше решить конкретную задачу?

Для этого появляются специализированные AI Skills.

1c-bitrix-cms-skill

Один из примеров:

https://github.com/vrtalex/1c-bitrix-cms-skill

Это специализированный набор знаний для разработки на «1С-Битрикс: Управление сайтом».

В нём собраны рекомендации и рецепты по нескольким направлениям:

  • настройка проекта;

  • структура;

  • компоненты;

  • контент;

  • SEO;

  • commerce;

  • безопасность;

  • REST;

  • качество кода;

  • обновления.

Отдельное внимание уделяется работе в /local, выбору между современными и legacy-подходами и безопасности.

Bitrix Framework Skills

Другой проект:

https://github.com/bxmaximum/bitrix-framework-skills

Здесь знания разбиты на специализированные skills по отдельным областям Bitrix Framework:

  • ORM;

  • Controllers;

  • Routing;

  • Events;

  • Validation;

  • Caching;

  • Security;

  • Background Jobs;

  • Components;

  • Highload-блоки;

  • Catalog;

  • Sale;

  • REST;

  • Bizproc;

  • миграции;

  • и другим подсистемам.

Такое разделение хорошо соответствует принципу progressive disclosure: агенту необязательно каждый раз загружать всю документацию по Битриксу. Он может использовать знания именно по той части платформы, которая нужна для текущей задачи.

AGENTS.md, Skills и MCP — это разные уровни контекста

Важно не смешивать эти инструменты.

У каждого из них своя задача.

AGENTS.md отвечает:

Как принято разрабатывать именно в нашем проекте?

Skills отвечают:

Какие инженерные практики следует применять для решения этой задачи?

MCP отвечает:

Что реально существует в API и framework прямо сейчас?

А существующий код проекта показывает:

Как аналогичные задачи уже реализованы в нашей системе?

Именно комбинация этих уровней позволяет значительно повысить предсказуемость AI-разработки.

Как выглядит полный AI development pipeline

Упрощённо современный процесс можно представить так:

Coding model

AGENTS.md

Стандарты и архитектурные правила конкретного проекта.

Skills

Специализированные знания и практики работы с Bitrix Framework.

MCP

Актуальная документация, API и сведения о framework.

Existing project code

Реальные примеры архитектуры и существующих решений.

Tests / Linters / Static Analysis

Автоматическая проверка результата.

Human Code Review

Инженерная оценка архитектуры, бизнес-логики и качества реализации.

Production

При таком подходе AI становится не заменой engineering practices, а их исполнителем.

Что меняется в работе разработчика

AI не отменяет необходимость понимать код.

Скорее наоборот.

Человек всё меньше занимается механическим набором PHP и всё больше работает на другом уровне:

  • формулирует задачу;

  • проектирует архитектуру;

  • выбирает ограничения;

  • определяет правила;

  • предоставляет модели необходимый контекст;

  • анализирует diff;

  • проверяет edge cases;

  • оценивает бизнес-логику;

  • контролирует результат.

Вместо задачи:

Написать 500 строк PHP.

появляется другой процесс:

Спроектировать решение → дать AI контекст → получить реализацию → проверить → скорректировать → протестировать → принять.

При этом ответственность за production-код никуда не исчезает.

AI не отменяет:

  • тестирование;

  • статический анализ;

  • code review;

  • мониторинг;

  • ответственность инженера за принятое решение.

Но он способен значительно сократить объём ручной работы между постановкой задачи и готовой реализацией.

Как начать использовать AI в существующем Bitrix-проекте

Для внедрения такого подхода необязательно сразу перестраивать весь development process.

Можно начать постепенно.

1. Создать AGENTS.md

Зафиксировать основные правила проекта:

  • архитектуру;

  • структуру;

  • naming;

  • требования к безопасности;

  • допустимые API;

  • правила работы с legacy.

2. Выбрать хорошие reference implementations

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

3. Дать агенту доступ к репозиторию

Изолированные фрагменты кода в чате дают значительно меньше контекста, чем возможность исследовать реальный проект.

4. Подключить актуальную документацию через MCP

Особенно для REST Битрикс24 и API, которые активно меняются.

5. Добавить специализированные Skills

Они позволяют модели использовать не только API, но и рекомендуемые практики работы с Bitrix Framework.

6. Требовать самостоятельного code review

Перед завершением задачи агенту можно отдельно поручить:

  • проверить собственный diff;

  • найти нарушения архитектурных правил;

  • проверить безопасность;

  • найти лишнюю сложность;

  • удалить ненужный код.

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

7. Сохранить обычные quality gates

Перед production должны остаться привычные инженерные проверки:

  • тесты;

  • линтеры;

  • статический анализ;

  • code review.

Модель важна. Но контекст становится важнее

Выбор coding-модели, безусловно, влияет на результат.

Но разница между:

Хорошая модель без контекста

и

Хорошая модель + AGENTS.md + Skills + MCP + репозиторий + автоматические проверки

может оказаться гораздо существеннее, чем разница между двумя соседними моделями в рейтинге.

Особенно при разработке на такой большой и исторически сложной платформе, как Битрикс.

Поэтому развитие AI-разработки постепенно смещается от поиска «самой умной модели» к построению правильного инженерного окружения вокруг модели.

И именно здесь, вероятно, находится основной резерв дальнейшего роста качества и скорости разработки.

А какую AI-модель использовать для Битрикса?

Это уже отдельный вопрос.

Для сравнения моделей на одинаковых задачах существует, например, проект Bitrix AI Challenge:

https://github.com/bxmaximum/bitrix_ai_challenge

В нём разные AI-модели выполняют одно техническое задание по разработке на Bitrix Framework с общей базой знаний, Skills, AGENTS.md и едиными критериями оценки.

Нужен сайт или приложение?

Обсудим ваш проект бесплатно

Оставить заявку

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