1С:EDT: зачем он нужен для ИИ-разработки в 1С

Коротко:

• без EDT ИИ получает только обрывки текста, которые ему вручную скопировали;
• с EDT ИИ видит проект целиком: модули, объекты, расширения и связи;
• с Git появляется история изменений;
• с MCP-серверами появляется быстрый поиск по конфигурации, документации, шаблонам и тестовым рецептам;
• с диагностикой и YAxUnit/Smoke появляется управляемая проверка результата.

Конфигуратор и EDT: главное отличие

Конфигуратор — привычный инструмент 1С-разработчика. В нём можно открыть объект, форму, модуль, внести изменение и обновить базу. Для человека это понятно.

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

1С:EDT работает иначе. После импорта информационной базы он создаёт проект конфигурации. Модули становятся текстовыми файлами, объекты и метаданные раскладываются по структуре проекта, расширения открываются отдельными проектами. Это подтверждается и официальной документацией EDT: при импорте информационной базы EDT анализирует базу, загружает конфигурацию и расширения, а в панели «Навигатор» появляется новый проект конфигурации и проекты расширений.

Для разработчика это означает более современный рабочий процесс. Для ИИ — принципиальную разницу: теперь агент может читать не пересказ, а реальный проект.

Что такое 1С:EDT

1С:EDT — это 1C:Enterprise Development Tools, официальный инструмент разработки от фирмы «1С». Он построен на технологиях Eclipse, поддерживает разработку на Windows, Linux и macOS и содержит инструменты для работы с конфигурациями, расширениями, запуском, отладкой, Git и проектами.

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

В повседневной работе EDT даёт разработчику:

• дерево проекта и объектов;
• редактор модулей;
• запуск и отладку;
• работу с Git;
• сравнение изменений;
• импорт информационных баз;
• отдельные проекты расширений;
• возможность подключать инструменты автоматизации вокруг файлов проекта.

Для ИИ-разработки последний пункт особенно важен. Как только конфигурация стала проектом на диске, к ней можно подключать Codex, Claude Code, MCP-серверы, диагностики, тесты и регламенты проверки.

Почему без EDT ИИ в 1С работает вслепую

ИИ хорошо работает там, где у него есть контекст. В 1С контекст — это не только текст задачи от пользователя. Это ещё:

• какие объекты есть в конфигурации;
• где лежит нужная форма;
• какие процедуры вызываются;
• какие реквизиты есть у документа или справочника;
• какие расширения подключены;
• как сейчас реализована похожая логика;
• что изменилось в Git;
• какие проверки уже есть.

Если этого контекста нет, ИИ начинает угадывать. Он может написать красивый пример на языке 1С, но этот пример не будет привязан к вашей конфигурации. Для реальной разработки это опасно: код может ссылаться на несуществующие реквизиты, повторять уже готовую логику или ломать типовой механизм.

EDT даёт ИИ доступ к проекту. MCP-серверы дают ему инструменты для поиска по этому проекту. В нашей текущей базе 1c-metadata уже проиндексированы крупные конфигурации: например, по УТ видно более 9 000 объектов и более 214 000 процедур, по УНФ — более 11 000 объектов и более 279 000 процедур. Это масштаб, который невозможно нормально передать ИИ копированием фрагментов в чат.

Поэтому правильная формула такая:

не «ИИ вместо разработчика», а «ИИ + EDT + Git + MCP + проверки».

Только в этой связке агент перестаёт гадать и начинает работать с реальными данными вашей 1С.

Что дают MCP-серверы после перехода на EDT

EDT сам по себе делает конфигурацию доступной как проект. Но для ИИ этого мало: ему нужны удобные инструменты поиска и проверки. Здесь появляются MCP-серверы. В нашем стеке используются несколько источников:

• 1c-edt-docs — документация EDT, платформы, БСП, типовых конфигураций и методических материалов;
• 1c-metadata — индекс объектов, модулей, процедур, вызовов и атрибутов конкретных конфигураций;
• 1c-testing — рецепты YAxUnit/Smoke, JUnit, тестовые расширения и паттерны проверки;
• frontol — документация Frontol для задач касс, обмена и торгового оборудования.

Что это даёт на практике:

• можно спросить: «где используется эта процедура?»;
• можно найти похожую реализацию в типовой конфигурации;
• можно проверить, есть ли нужный объект, реквизит или модуль;
• можно найти шаблон для запроса, формы, интеграции или расширения;
• можно свериться с документацией EDT или БСП;
• можно после доработки пройти диагностики и тестовый регламент.

Важно: MCP — это не магия и не замена EDT. MCP работает хорошо тогда, когда есть что индексировать. Для 1С этим источником становится EDT-проект.

Что меняется в работе команды

После перехода на EDT меняется не только редактор. Меняется вся цепочка разработки.

Было

• задача приходит в свободной форме;
• разработчик ищет место в Конфигураторе;
• код правится локально;
• изменения сложно сравнивать по строкам;
• ИИ получает только то, что ему вручную скопировали.

Становится

• задача формулируется как ТЗ с контекстом и критериями приёмки;
• проект лежит в EDT и Git;
• ИИ через MCP ищет объекты, процедуры, шаблоны и документацию;
• разработчик подтверждает план до написания кода;
• изменения видны в Git;
• код проверяется диагностикой и тестами;
• результат фиксируется в журнале работ.

Это особенно важно для командной разработки. Когда есть Git, видно, что именно поменялось. Когда есть MCP, ИИ может объяснить, почему он предлагает именно такой план. Когда есть YAxUnit/Smoke, результат можно проверять не только словами, но и сценариями.

Что нужно для перехода с Конфигуратора

Переход на EDT не обязан быть «большим взрывом». Его можно сделать поэтапно.

1. Установить EDT

Берётся актуальный релиз EDT с официальных ресурсов 1С. Конкретную версию платформы нужно сверять с требованиями выбранного релиза EDT. Например, в локальной документации EDT 2026.1.0 отдельно отмечены требования к версиям платформы 8.3.27 и 8.5.1. По железу никаких экзотических требований нет: нужна обычная рабочая машина разработчика, SSD и достаточный объём памяти. Для небольших проектов можно начинать с 8 ГБ, для крупных конфигураций уровня УТ/ERP комфортнее 16 ГБ и выше.

2. Импортировать информационную базу

Официальный сценарий EDT — импортировать конфигурацию из информационной базы в новый проект. EDT анализирует базу, показывает расширения, предлагает версию платформы и создаёт проект конфигурации. Если есть расширения, они открываются отдельными проектами. Это важный момент для ИИ: расширения нужно индексировать отдельно, чтобы агент понимал, где типовая конфигурация, а где ваша доработка.

3. Подключить Git

Git нужен не «для красоты». Он даёт историю изменений и возможность смотреть разницу по строкам. Для человека это контроль. Для ИИ — дополнительный контекст: что было, что стало, какие файлы затронуты. Подробно про Git — в отдельной статье серии: Git для 1С-разработчика. Здесь важно зафиксировать: EDT без Git даёт файлы, EDT с Git даёт управляемый процесс разработки.

4. Проиндексировать конфигурацию

После импорта проекта ИИ ещё не обязан автоматически понимать вашу 1С. Нужно проиндексировать проект через MCP 1c-metadata. На маленьком расширении это может занять секунды. На крупной конфигурации — минуты. Это нормально: индексатор разбирает тысячи объектов, десятки тысяч модулей, сотни тысяч процедур и миллионы вызовов. Зато после индексации можно задавать ИИ вопросы не в пустоту, а по реальной конфигурации.

5. Подключить тесты и регламент проверки

Для серьёзной работы одного «ИИ написал код» недостаточно. Нужен регламент: сначала план; потом код; затем диагностика; затем загрузка в тестовую базу; затем YAxUnit/Smoke или ручная проверка сценария; затем запись результата в журнал работ. В нашем 1c-testing уже есть паттерны вроде проверки расширения перед переносом, простого теста, теста подписки и сценария query-to-xlsx. Это хорошая основа, чтобы ИИ-разработка не превращалась в набор непроверенных фрагментов.

Типичные опасения про EDT

«EDT медленнее Конфигуратора»

На старте и на больших конфигурациях EDT действительно может требовать больше ресурсов. Это решается нормальным SSD, памятью и корректной настройкой рабочей области. Зато взамен команда получает Git, проектную структуру, навигацию и возможность подключить ИИ к реальному коду.

«В EDT есть не всё, что в Конфигураторе»

Отдельные редкие операции могут оставаться в Конфигураторе. Это не отменяет EDT как основной среды разработки. Практический подход простой: основная ежедневная работа идёт в EDT, а Конфигуратор используется как вспомогательный инструмент для специфичных случаев.

«Команда не освоит»

Если пытаться перейти без регламента, будет тяжело. Если идти по шагам — импорт, Git, базовые операции, MCP, первые задачи — команда начинает работать в новом процессе быстро. Самая большая сложность обычно не в интерфейсе EDT, а в дисциплине: писать задачи как ТЗ, фиксировать изменения, проверять результат.

«Можно же просто копировать код в ИИ»

Можно. Но это работает только для маленьких вопросов. Как только задача касается нескольких объектов, форм, регистров, расширений и типовой логики, копирование фрагментов перестаёт работать. Агенту нужен проект и индекс.

Что остаётся в Конфигураторе

Конфигуратор не исчезает полностью. Он может понадобиться для отдельных административных, миграционных или специфичных сценариев. Но это не должно быть основным рабочим процессом, если вы хотите использовать ИИ всерьёз.

Практический принцип такой: Конфигуратор можно оставить как инструмент для редких операций. Основная разработка, история изменений, анализ ИИ и проверки должны жить вокруг EDT-проекта. Иначе команда каждый раз возвращается к старой проблеме: ИИ не видит систему целиком. Как мы прошли этот путь целиком — в статье «Как мы за 5 месяцев внедрили ИИ в 1С-разработку».

Вывод

EDT нужен не потому, что он «моднее Конфигуратора». Он нужен потому, что ИИ работает с текстом, файлами, историей изменений и индексами. Если конфигурация остаётся только внутри старого процесса, ИИ-агент работает вслепую: он может отвечать общими словами, но не знает вашу систему.

Если конфигурация импортирована в EDT, лежит в Git, проиндексирована MCP-серверами и проверяется тестами, появляется нормальный инженерный процесс: задача → контекст → план → код → проверка → документация. Именно с этого начинается внедрение ИИ в 1С-разработку.