Claude Code для 1С: как агент работает с конфигурацией целиком

Claude Code для 1С — это не «ещё один чат, куда копируешь код». Это агент, который запускается в консоли внутри папки проекта и сам ходит по файлам: ищет, читает, правит, запускает тесты. Для 1С это меняет масштаб работы. Стоит выгрузить конфигурацию в файлы, и агент видит не выделенный фрагмент модуля, а всё дерево метаданных сразу. Ниже разберу процесс: что выгружать, как описать правила проекта в CLAUDE.md, почему без плана агент рапортует о победе на пустом месте и что за ним всё равно придётся проверять руками.

Сразу оговорюсь про рамку. Это не про «нейросеть напишет вам конфигурацию». Это про процесс, где агент делает рутину, а архитектуру и проверки держите вы. Вся фактура ниже из живого проекта: сервиса перевода конфигураций 1С на другие языки, который я собрал через Claude Code от первого коммита до веб-интерфейса. Файлы, правила и цифры оттуда.

Что видит Claude Code и где заканчивается Напарник

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

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

Отсюда класс задач, которого до этого просто не было:

• «найди все места, где обращаемся к реквизиту КодТНВЭД, и добавь проверку на пустое значение» — это обход десятков файлов, а не подсказка в одном;
• «объясни, как устроен обмен в этом расширении, и нарисуй порядок вызовов»;
• «собери список объектов, у которых синоним не заполнен на английском» — то есть отчёт по всей выгрузке;
• «перепиши эти четыре модуля под новый API, тесты не ломай».

Есть и третий уровень области видимости: агент, у которого кроме файлов есть инструменты. Справка платформы через MCP закрывает выдуманные методы, а MCP-сервер к самой базе даёт агенту читать данные. Как это собирается, я разбирал в статье про MCP-сервер для 1С. Практическое правило простое: Напарник для точечной работы в EDT, Claude Code для задач по всей конфигурации, MCP там, где агенту не хватает знаний платформы или доступа к данным.

Выгрузка конфигурации под агента

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

Catalogs/
├── Номенклатура.xml
└── Номенклатура/
    └── Forms/
        ├── ФормаСписка.xml
        └── ФормаСписка/Ext/Form.xml
Documents/
├── Реализация.xml
└── Реализация/Forms/...
Languages/Русский.xml
Roles/Админ.xml
Configuration.xml

Внутри XML лежит ровно то, с чем работает агент. Вот блок синонима справочника из демо-выгрузки моего проекта:

<Name>Номенклатура</Name>
<Synonym>
	<v8:item>
		<v8:lang>ru</v8:lang>
		<v8:content>Номенклатура</v8:content>
	</v8:item>
</Synonym>

Структура читаемая, и это хорошая новость: агент понимает такой XML без обучения. Плохая новость в объёме. Выгрузка типовой УТ или ERP это десятки тысяч файлов, и никакое окно контекста их не вмещает. Поэтому работать надо не «дай ему всю конфигурацию», а как с обычным репозиторием: сузить рабочую папку до подсистемы или пары объектов, а поиск оставить агенту. Он сам найдёт нужное грепом, если знает, что искать.

Что имеет смысл отсекать сразу. Макеты (Template.xml) и файлы справки (Help.xml) раздувают выгрузку и почти никогда не относятся к задаче. Каталоги bin/, .git/, картинки и двоичные ресурсы агенту бесполезны. В моём сервисе перевода сканер вообще исключает *.bsl, Help.xml, Template.xml, *.mdo и bin/, потому что локализуемых строк там нет. Для задачи «разберись в коде» набор исключений будет обратным: как раз .bsl станет главным, а XML форм можно не читать.

Отдельный вопрос, который лучше решить до первого запуска, а не после. Конфигурация уходит в облако. Для типовой это обычно не проблема, для заказной с чувствительной логикой уже разговор с безопасниками, а иногда и с юристами. Варианты нормальные: отдавать только ту подсистему, которая нужна; выкинуть из выгрузки всё, что не относится к задаче; поднять агента в изолированном контуре. У себя я держу для этого Docker-обвязку: контейнер с Python и установленным Claude Code, исходники подключены томом с хоста, авторизация подхватывается из ~/.claude. Агент варится внутри контейнера и физически не видит ничего, кроме смонтированной папки.

services:
  dev:
    volumes:
      - ./SOURCE:/app          # только проект, ничего лишнего
      - ${HOME}/.claude:/home/dev/.claude
    working_dir: /app

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

CLAUDE.md проекта — главный рычаг

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

Вот как выглядит рабочий файл из сервиса перевода. Он у меня по-английски, агенту это безразлично, а мне так короче:

## Development

For new backend functionality tasks — write the test first, then the
implementation. After implementation — run the tests.

### Test data

The test upload of the configuration is located in `demo/configuration/`.
All tests are written for it. The original configuration must remain
unchanged — the translation results are saved in `demo/result/`.

## Workflow for each task

1. **Plan.** Create `docs/exec-plans/active/<task-name>.md` with:
   goal, steps, done criteria, risks.
2. **Decomposition.** If the task breaks into ≥2 independent subtasks,
   launch them in parallel. Otherwise work directly.
3. **Execution.** As you work, tick off completed steps in the plan
   (checkboxes) without rewriting history. If the plan changes
   significantly, add a "Deviations from plan" section.
4. **Verification.** Run tests and linter. Confirm the done criteria
   from the plan are met.
5. **Closing.** Move the plan to `docs/exec-plans/completed/`. Any issues
   discovered but deferred go into `docs/exec-plans/tech-debt-tracker.md`
   (date, context, proposed fix).
6. **Report.** Brief summary: what was done, what remains, what
   reviewers should pay attention to.

Always write all comments and descriptions in Russian.

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

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

Эталон неприкосновенен. Правило про demo/configuration выглядит мелочью, а на деле снимает самый частый трюк: когда тест не сходится, агент правит ожидаемый результат. Здесь прямо сказано, что исходная выгрузка не меняется, а результат перевода пишется в отдельную папку. Для 1С это правило важнее, чем для Python: эталонный XML нельзя «слегка причесать», он должен грузиться в конфигуратор побайтово корректным.

План до кода. Первый шаг workflow не «начни делать», а «создай файл плана с целью, шагами, критерием готовности и рисками». Дальше в этом же файле агент отмечает чекбоксы. Про это отдельный раздел ниже, тут важно, что требование живёт в CLAUDE.md, а не в вашей голове.

Историю не перезаписывать. Строчка про «tick off completed steps without rewriting history» и раздел «Deviations from plan» лечит тихую подмену задачи. Если агент отступил от плана, он обязан это написать, а не молча заменить план на описание того, что получилось.

Техдолг фиксировать сразу. Всё, что найдено и отложено, идёт в tech-debt-tracker.md с датой, контекстом и предлагаемым решением. У меня в проекте таких записей набралось четырнадцать, и они настоящие: например, что SHA-256 считается для каждого файла при каждом запуске, хотя можно было бы сначала сравнивать mtime. Агент честно нашёл узкое место, честно не стал его лечить в рамках задачи и честно записал. Без этого правила такие находки просто исчезают.

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

Теперь как это переносится на выгрузку 1С. Правила, которые я бы положил в CLAUDE.md рядом с конфигурацией:

• версия платформы и режим совместимости, чтобы агент не предлагал синтаксис из другой версии;
• «метаданные не менять без явного указания» — правки только в модулях, состав объектов и типы реквизитов трогает человек;
• «структуру XML не переформатировать»: отступы табами как в выгрузке, кодировка UTF-8 с BOM, порядок элементов сохранять. Иначе конфигуратор откажется загружать файл, и вы будете искать причину в диффе на сорок тысяч строк;
• где лежит эталонная выгрузка и что она неизменна;
• запрет на любые действия с боевой базой: агент работает с файлами, конфигуратор и обновление базы делает человек;
• имена и комментарии по-русски, как принято в проекте;
• как проверять результат: чем прогоняется синтаксический контроль, что считается критерием готовности.

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

Работа по плану, а не по промпту

Диалог агент забывает и переинтерпретирует. Файл на диске не забывает. Именно поэтому цикл в проекте начинается с плана, а не с задачи в чате: в docs/exec-plans/completed/ у меня 14 выполненных планов, и по ним видно всю историю разработки.

План это не абзац «сделай парсер». Вот фрагмент того, как выглядит нормальный шаг:

## 1.5 XML-парсер (parser.py) — только Synonym

Файлы: src/translateones/parser.py
Тесты: tests/test_parser.py
Фикстуры: tests/fixtures/sample_catalog.xml

- [ ] Написать тесты:
  - [ ] test_parser_extracts_synonyms — корректное извлечение Synonym
  - [ ] test_parser_skips_already_translated — пропуск переведённых блоков
  - [ ] test_parser_handles_multiline — многострочные тексты
  - [ ] test_parser_handles_xml_entities — &, < декодируются
  - [ ] test_parser_char_offset — правильность вычисления char_offset
- [ ] Реализовать класс XMLParser:
  - [ ] Regex-парсинг (НЕ DOM) — точное сохранение смещений
  - [ ] char_offset = позиция последнего </v8:item> в блоке

Критерий готовности: парсер извлекает все непереведённые Synonym-блоки
из фикстур, правильно считает смещения, строит контекст.

Тесты перечислены по именам до того, как написана первая строка кода. Критерий готовности сформулирован проверяемо. Решение «regex, а не DOM» зафиксировано в плане с причиной: DOM-парсер переформатирует XML при сохранении, а нам нужны точные символьные смещения, чтобы вставить перевод и не тронуть больше ничего. Это то самое архитектурное решение, которое агент сам бы не принял, а принял бы удобное для себя.

Цикл получается такой: план → ваше ревью плана → тест → код → прогон тестов и линтера → закрытие плана и запись техдолга. Ревью плана здесь самый дешёвый гейт из всех. Прочитать двадцать строк плана и сказать «не так, смещения нельзя считать по DOM» занимает две минуты. Отловить то же самое в готовом коде на шестьсот строк займёт вечер. Тот же принцип я описывал в разборе вайбкодинга в 1С: большинство провалов это не «модель тупая», а отсутствие правил и контекста на входе.

Сколько это даёт на практике

Чтобы разговор был не абстрактным, цифры того самого сервиса перевода конфигураций, собранного по описанному процессу:

• 20 модулей и 6 391 строка в src/translateones: сканер, парсер, патчер, роутинг, кэш, rate limiter, детектор изменений, CLI на Typer и Rich, веб-интерфейс на Streamlit;
• 22 тест-файла и 5 983 строки тестов, 9 фикстур;
• 14 выполненных планов в docs/exec-plans/completed, 14 записей техдолга;
• 20 типов объектов метаданных 1С и 13 языков перевода с отдельными промптами под ERP-терминологию;
• маршрутизация строк по приоритету SKIP → GLOSSARY → CACHE → LLM, SQLite-кэш, инкрементальный режим по SHA-256 файлов.

Обратите внимание на соотношение: 6 391 строка кода и 5 983 строки тестов. Почти один к одному, и это не аккуратность ради аккуратности. Тесты здесь единственное, чем проверяется работа агента, поэтому их объём сопоставим с объёмом кода по построению процесса.

Полный разбор кейса, включая пайплайн перевода и выбор модели под задачу, есть в записи вебинара: Claude Code для 1С: разработал сервис перевода конфигураций без единой строчки кода. Здесь я специально не пересказываю сам сервис, а показываю процесс, который к нему привёл.

Что проверять руками всегда

Тесты закрывают регресс, но не закрывают доменные ошибки. В 1С есть три зоны, где агент ошибается тихо и дорого.

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

# Сортируем смещения в обратном порядке,
# чтобы ранние смещения не сдвигались при вставке
all_offsets.sort(key=lambda x: x[0], reverse=True)

Рядом та же история с экранированием: перед вставкой текст обязан пройти замену &, <, >, " на сущности, иначе XML станет невалидным и конфигуратор его не примет. Записывать файл лучше атомарно, через временный файл с переименованием, чтобы прерванная запись не оставила от выгрузки половину.

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

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

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

Когда Claude Code не нужен

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

Точечная правка. Добавить проверку в одну процедуру, поправить условие, дописать три строки в обработчике. Пока задача помещается в один файл, Напарник в EDT или собственные руки быстрее любого агента.

Вопрос по платформе. «Какой метод читает файл в двоичные данные», «какие параметры у конструктора HTTP-соединения». Это вопрос к справке, а не задача обхода файлов. Агент здесь либо ответит правильно, либо выдумает метод, и второй вариант обходится дороже, чем открыть синтакс-помощник. Лечится справочным MCP, но сама задача агентской не становится.

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

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

Задачи над данными, а не над кодом. «Сколько мы продали этому контрагенту», «покажи заказы без оплаты». Здесь нужен не Claude Code над выгрузкой, а агент с инструментами к базе через MCP. Это другой класс решения, не пытайтесь решать его выгрузкой конфигурации.

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

Куда дальше

Claude Code для 1С не заменяет знание платформы. Он его усиливает: тот, кто понимает, почему XML нельзя переформатировать и почему смещения считаются с конца файла, получит от агента рабочий инструмент за несколько вечеров. Тот, кто не понимает, получит выгрузку, которую конфигуратор откажется грузить, и зелёные тесты, которые проверяют переписанный эталон.

Как выстроить ИИ-ассистированную разработку в 1С системой, а не набором промптов, я разбираю на курсе по ИИ для 1С: контекст и правила проекта, справочный MCP по платформе, агент, который ходит в вашу конфигурацию, и проверки на каждом гейте. Там же практика на реальных задачах, а не на демо-примерах.

Если хотите сначала осмотреться, начните с обзора ИИ для 1С в 2026 году: там карта всех сценариев, от Напарника до агентов над данными.