Как использовать Claude Code для разработки на 1С

Claude Code — консольный ИИ-агент от Anthropic, который умеет не просто отвечать на вопросы, а самостоятельно работать с файлами проекта: искать нужный код, читать его, вносить правки, запускать команды и проверять результат. Для разработчиков 1С это открывает новый способ работы: если выгрузить конфигурацию в файлы, агент видит не один открытый модуль, а всё дерево метаданных сразу и может выполнять задачи, которые раньше требовали часов ручного поиска по конфигурации. В этой статье разберём, чем такой агент отличается от обычного чата с ИИ, какие задачи ему стоит доверять, как настроить его на работу с 1С и что обязательно проверять руками, даже если агент отчитался об успехе.

Чем Claude Code отличается от чатов с ИИ

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

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

Из этого вытекает целый класс задач, недоступный обычному чату: «найди все обращения к такому-то реквизиту по всей конфигурации и добавь проверку», «разберись, как устроен обмен данными в этом расширении, и опиши порядок вызовов», «перепиши несколько модулей под новую структуру, не сломав существующую логику». Всё это требует обхода десятков файлов, а не работы с одним вставленным фрагментом.

Какие задачи хорошо решает Claude Code, а где нужен MCP-сервер

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

• Файлы и код. Поиск по всей конфигурации, анализ логики, массовые правки однотипных мест, составление отчётов по выгрузке (например, «где не заполнен синоним на английском») — здесь Claude Code эффективен без дополнительных инструментов.
• Справка платформы и данные базы. Если агенту нужно точно знать синтаксис методов платформы или прочитать реальные данные из информационной базы, простого доступа к файлам недостаточно — здесь подключают MCP-сервер: отдельный служебный компонент, который даёт агенту доступ к справочной информации платформы или безопасное чтение данных базы по чётко ограниченному набору команд.

Разница в объёме «видимого» агентом контекста хорошо укладывается в простую схему:

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

Практическое правило: если задача про код и структуру конфигурации — достаточно самого агента с файлами. Если задача про то, «как правильно» на платформе, или требует реальных цифр из базы — без MCP-сервера агент рискует придумать несуществующий метод или показать правдоподобные, но неверные данные.

Какой принцип работы Claude через агентов

Ключевая ошибка новичков — вести с агентом диалог, как с чатом: одна реплика — одна правка. Такой подход работает на маленьких задачах, но на серьёзной задаче агент начинает «забывать» ранние договорённости и интерпретировать задачу по-своему. Правильный принцип — работа по плану, а не по разовому промпту.

Схема выглядит так: сначала агент (или вы вместе с ним) составляет короткий план с конкретными шагами и критерием готовности, вы просматриваете план и поправляете его, если что-то не так, и только после этого агент переходит к реализации, отмечая выполненные шаги. Пример фрагмента такого плана:

## Шаг 2. Добавить проверку заполнения реквизита

Файлы: CommonModules/ОбработкаЗаказов/Module.bsl
Тесты: сценарий "Заказ без реквизита должен блокироваться"

- [ ] Написать тест, который проверяет блокировку при пустом реквизите
- [ ] Убедиться, что тест падает на текущем коде
- [ ] Добавить проверку в модуль
- [ ] Прогнать тест повторно, показать вывод

Критерий готовности: тест проходит, поведение остальных сценариев не изменилось.

Такой план — это не формальность. Просмотреть десять строк плана и сказать «нет, здесь нужно по-другому» занимает пару минут. Найти ту же проблему уже в готовом коде на несколько сотен строк — почти всегда дороже. План, зафиксированный в отдельном файле, также не забывается и не переинтерпретируется агентом в процессе работы, в отличие от договорённостей, произнесённых только в диалоге.

Подготовка конфигурации 1С для работы агента

Чтобы агент мог работать с конфигурацией 1С, её нужно выгрузить в файлы — либо командой выгрузки конфигурации в файлы из Конфигуратора, либо взять проект, который уже ведётся в 1С:EDT, где конфигурация и так лежит файлами. На выходе получается дерево, где каждый объект метаданных — отдельный XML-файл, а программные модули — обычный текст рядом с ним.

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

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

Файл с правилами Claude для работы с 1С: как его создать и настроить

CLAUDE.md — это обычный текстовый файл в корне проекта, который агент читает автоматически, ещё до вашей первой команды. В отличие от инструкции, которую нужно каждый раз копировать в диалог, CLAUDE.md хранится вместе с кодом и распространяется на всю работу с этим проектом. Без такого файла агент действует по собственным представлениям о «хорошо» — и именно в этом режиме он способен, например, подогнать тест под неверный результат, вместо того чтобы исправить сам код.

Файл создаётся как обычный markdown-документ. Пример базового набора правил для проекта 1С:

# Правила проекта 1С

## Разработка
- Для новой функциональности сначала пиши тест, потом реализацию.
  После правок прогоняй тесты и показывай реальный вывод команды.

## Работа с конфигурацией
- Правь только программные модули. Состав объектов метаданных
  и типы реквизитов менять только по явному указанию.
- Эталонную выгрузку для тестов не менять — результат работы
  сохранять в отдельную папку.
- Структуру XML не переформатировать (отступы, кодировка,
  порядок элементов) — иначе Конфигуратор не загрузит файл.

## Прочее
- Комментарии и имена — на русском языке.
- Перед реализацией — короткий план с шагами и критерием готовности.

Разберём, почему эти пункты важны, а не просто формальность. Правило «сначала тест, потом код» защищает от ситуации, когда тест написан после реализации: такой тест почти всегда проходит и ничего не доказывает, кроме того что код запустился. Правило про неприкосновенность эталонной выгрузки закрывает самый частый способ агента «сдать» задачу — не исправить код, а подправить ожидаемый результат так, чтобы тест позеленел. А запрет на переформатирование XML — чисто техническое, но критичное для 1С требование: конфигуратор откажется загружать выгрузку, если в файле изменился порядок элементов, отступы или кодировка, и разбираться с этим в диффе на тысячи строк — занятие не для одного вечера.

Тестирование продукта после правок Claude Code

Автоматическое тестирование — единственный дешёвый способ проверить, что агент действительно сделал то, что нужно, а не просто отчитался об успехе. Для 1С для этого можно использовать существующие инструменты тестирования конфигураций — например, фреймворки для поведенческого тестирования (Vanessa Automation) или модульного тестирования кода (xUnitFor1C), которые запускают сценарии на тестовой базе и показывают результат в понятном отчёте.

Порядок работы простой: перед правкой агент (по правилам из CLAUDE.md) пишет тест, который описывает нужное поведение, и запускает его — тест должен упасть, это подтверждает, что он вообще что-то проверяет. Затем вносится правка в код, и тест запускается повторно. Здесь важно одно правило: словам агента «тесты прошли» доверять не стоит — доказательством считается только фактический вывод команды запуска тестов, который вы сами посмотрели. Разница на первый взгляд небольшая, но именно она отделяет реальную проверку от отчёта на словах.

Есть и то, что автоматические тесты не ловят в принципе. Это доменные ошибки: некорректно подобранные типы реквизитов, запросы, обращающиеся к полям, которых нет в вашей конкретной базе, или логика, которая синтаксически верна, но даёт неправильный результат из-за особенностей соединения в запросе. Такие вещи всегда проверяются человеком — прогоном запроса на реальных данных и сверкой с отчётом, который вы и так знаете.

Рекомендации и особенности работы Claude Code для 1С

Несколько практических моментов, которые стоит держать в голове при внедрении Claude Code в работу с 1С.

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

Простой критерий, когда задачу стоит отдавать агенту: если она крупнее одного файла и её результат можно проверить тестом или явным сравнением до/после — это хорошая задача для Claude Code. Если она про знание платформы «как есть», про учётные решения или про работу с живой базой — на этом этапе лучше оставить её себе или сделать вместе с агентом, но с обязательной проверкой каждого шага.

Заключение

Claude Code не заменяет разработчика 1С и не избавляет от необходимости разбираться в платформе — он ускоряет рутинную часть работы: поиск по конфигурации, однотипные правки, написание и прогон тестов. Лучше всего он работает там, где заранее настроен файл правил проекта, задача разбита на план с проверяемым результатом, а итог всегда проверяется тестами и внимательным взглядом человека, а не принимается на слово. Если хотите разобраться, как выстроить такой процесс под конкретную конфигурацию, или у вас уже есть вопрос по внедрению ИИ-инструментов в работу с 1С — напишите команде Sky1c, разберём вашу ситуацию.