Как правильно ставить задачу ИИ-агенту для 1С: анализ, план, код и проверка

Обновлено: июнь 2026

Главный принцип: не просите ИИ сразу писать код

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

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

Сначала не пиши код. Проанализируй задачу и текущий код. Найди, какие объекты конфигурации затронуты. Определи риски. Задай вопросы, если данных не хватает. Предложи план. Код — только после подтверждения.

Одна эта вставка меняет поведение: вместо «генератора кода» ИИ становится младшим помощником — сначала разбирается, потом предлагает, потом делает черновик.

Почему это снимает страх программиста

Главный вопрос разработчика — не «может ли ИИ написать код», а «смогу ли я понять, проверить и принять этот код». Если нет — он не должен попадать в рабочую базу. Отсюда наше правило:

Если разработчик не может объяснить код, который предложил ИИ, — код не принимается.

Так ИИ перестаёт быть автором финального решения: он готовит варианты, ищет ошибки, предлагает план и черновик, а человек проверяет, понимает и отвечает за результат. Разница видна сразу:

• Плохо: ИИ написал → вставили → никто не понял → база сломалась.
• Хорошо: ИИ разобрал и предложил план → программист проверил → ИИ сделал черновик → программист понял код → проверили на тестовой базе → внедрили.

Если в команде есть сопротивление, начните с задач, где ИИ заведомо не «пишет вместо человека»: объяснить чужой модуль, найти риски в коде, составить тест-кейсы, подготовить план, разобрать ошибку. Здесь он только ускоряет — и не угрожает.

Формула задачи: контекст, задача, ограничения, критерий

Вместо «сделай доработку» держите четыре элемента (а перед ними — режим «сначала анализ и план, код без подтверждения не писать»). Каждый закрывает свой типовой провал:

• Контекст — где работаем. «Сделай отчёт по продажам» → «УТ 11.5, отчёт на СКД по регистру ПродажиОбороты; группировки: период, менеджер, номенклатура; показатели: количество, сумма». Без контекста ИИ пишет «по среднему», а в 1С это опасно.
• Задача — одна и проверяемая ответом «да/нет». «Доработай обработку» → «В ЗагрузкаПрайсаПоставщика строки без артикула не загружать, а выводить в таблицу ОшибкиЗагрузки с причиной “Не заполнен артикул”».
• Ограничения — что трогать нельзя. Самое забываемое и самое важное (список ниже).
• Критерий готовности — как проверить. «Чтобы работало нормально» → сценарий: загрузить файл с 3 строками без артикула → они не попадают в товары → появляются в ОшибкиЗагрузки с нужной причиной.

Ограничения для 1С проговаривайте явно — иначе ИИ полезет в типовой модуль, создаст лишний объект или сделает запрос в цикле:

• не менять типовые модули и структуру объектов без согласования;
• не создавать новые объекты конфигурации без подтверждения;
• не использовать запросы в цикле, не менять права и движения документов;
• русские имена процедур и переменных, стандарты БСП и проекта;
• все изменения — только в тестовом контуре, не в рабочей базе.

Ограничения помогают и бизнесу, и программисту: видно, что ИИ работает в рамках, а не «делает что хочет».

5 ошибок, из-за которых ИИ делает не то

1. «Сделай красиво/удобно». Нет результата и критерия. Лучше: «добавь на форму кнопку “Отправить” справа от “Печать”; по нажатию открывается форма отправки письма».
2. «Доработай эту обработку». Непонятно что и что нельзя менять. Лучше: «добавь проверку пустого артикула; сначала проанализируй код загрузки и предложи план».
3. «Перепиши на новый стиль». «Стиль» не определён, можно сломать логику. Лучше: «найди места не по стандартам проекта — длинные процедуры, запросы в цикле, дубли; сначала список, код не меняй».
4. «И ещё вот это заодно». Несколько задач разом трудно проверить. Разбейте на короткие законченные циклы.
5. «Только ничего не сломай». Это не ограничение. Дайте список критичных мест: модуль проведения, движения по регистру, существующие реквизиты, права, обмен — «нужно тронуть из списка — остановись и объясни».

Почему наш ИИ сильнее обычного промпта

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

Покажи структуру документа ЗаказПокупателя. Какие реквизиты у справочника Контрагенты? Где используется процедура ОбработатьЗаказ? Какие регистры движет документ?

В нашем процессе перед ответом ИИ-агент проверяет несколько слоёв контекста, а не отвечает «из памяти модели»:

1. Правила проекта: AGENTS.md, стандарты разработки, ограничения по базе и расширениям.
2. Документацию: 1С, БСП, EDT, платформу, СКД, язык запросов, типовые конфигурации.
3. Метаданные: документы, справочники, регистры, реквизиты, формы, общие модули.
4. Код: процедуры, функции, вызовы, места использования, зависимости.
5. Готовые примеры: обработки, шаблоны, типовые паттерны.
6. Проверки: диагностики BSL Language Server, /CheckConfig, YAxUnit/Smoke, журнал работ.

Поэтому хороший вопрос звучит не «придумай решение», а «проверь по документации, метаданным и коду, как это устроено в нашей конфигурации, и только потом предложи вариант». Подробнее про серверы — в статье «Что такое MCP-сервер и зачем он 1С».

ИИ для аналитиков и поддержки 1С

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

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

Агент сначала смотрит документацию и правила проекта, затем метаданные и код, а при безопасном доступе к копии базы или read-only — сверяет ответ с фактическими данными. В итоге поддержка получает не общую подсказку, а ответ с привязкой к вашей конфигурации: какой объект смотреть, какой модуль участвует, где причина ошибки.

Готовый шаблон постановки задачи

Скопируйте и используйте в Claude Code, Codex, Cursor или другом ИИ-агенте — он собирает всё, о чём выше:

Режим работы:
  Сначала не пиши код.
  Сначала проанализируй задачу, текущий код и метаданные.
  Если данных недостаточно — задай вопросы.
  После анализа предложи план изменений.
  Код писать только после подтверждения плана.

Перед ответом:
  - проверь документацию и MCP;
  - проверь метаданные и реальный код;
  - не используй объекты, реквизиты и методы, которых не нашёл;
  - если нужен доступ к данным, сначала запроси безопасный режим: копия базы, тестовая база или read-only.

Конфигурация:
  <УТ 11.5 / ERP 2.5 / БП 3.0 / ЗУП 3.1 / УНФ / ДАЛИОН / другая>

Задача:
  <Одна конкретная фраза: что должно получиться>

Контекст:
  - Объект: <Документ / Справочник / Регистр / Обработка / Отчёт>
  - Форма: <если есть>
  - Модуль: <Модуль объекта / Модуль формы / Общий модуль>
  - Связанные объекты: <если есть>
  - Текущая проблема: <что сейчас не работает или чего не хватает>

Что нужно сделать сначала:
  1. Проанализировать текущую реализацию.
  2. Объяснить, как сейчас работает код.
  3. Найти места, которые нужно изменить.
  4. Найти риски.
  5. Предложить план.
  6. Не менять файлы без подтверждения.

Ограничения:
  - Не трогать типовые модули без отдельного согласования.
  - Не менять структуру объектов без подтверждения.
  - Не создавать новые объекты конфигурации без подтверждения.
  - Не менять права пользователей.
  - Не менять движения документов без отдельного плана.
  - Не использовать запросы в цикле.
  - Использовать русские имена процедур, функций и переменных.
  - Соблюдать стандарты проекта и БСП.
  - Все изменения только в тестовом контуре.

Критерий готовности:
  - Запустить сценарий: <описание сценария>
  - Получить результат: <ожидаемый результат>
  - Проверить ошибки: <что не должно происходить>
  - Составить список тестов.
  - После изменений объяснить, что было изменено и почему.

Формат ответа:
  1. Краткое понимание задачи.
  2. Уточняющие вопросы, если нужны.
  3. Анализ текущего состояния.
  4. План изменений.
  5. Риски.
  6. После подтверждения — черновик реализации.
  7. После реализации — список проверок и описание изменений.

На первых задачах шаблон кажется длинным, но это дешевле, чем разбирать неправильный код. Постоянные правила со временем переезжают в CLAUDE.md или AGENTS.md, и в задаче остаётся только контекст и цель.

Два примера: до и после

Разбор ошибки проведения

Плохо: «Почини проведение документа». Хорошо — сначала анализ, без правок:

Режим работы:
  Код не менять. Сначала анализ.

Конфигурация: УТ 11.5.

Проблема:
  Документ ЗаказКлиента не проводится, если в табличной части есть услуга без склада.
  Для товаров склад обязателен, для услуг склад не должен требоваться.

Задача:
  Проанализировать код проведения и найти, почему для услуг проверяется склад.

Контекст:
  - Документ: ЗаказКлиента.
  - Ошибка: «Не заполнен склад».
  - Сценарий: в табличной части есть строка с типом номенклатуры «Услуга».

Ограничения:
  - Пока не менять код.
  - Не менять движения документа.
  - Не менять структуру документа.
  - Не менять справочник Номенклатура.

Критерий готовности анализа:
  - Объяснить, где выполняется проверка склада.
  - Показать, почему она срабатывает для услуг.
  - Предложить 1–2 варианта исправления.
  - Указать риски каждого варианта.
  - Составить список тестов.

Код писать только после подтверждения варианта.

Задача от аналитика

Аналитику не нужен код — нужно хорошее ТЗ для разработчика:

Я аналитик, не программист.
Помоги подготовить техническое задание для разработчика 1С.

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

Конфигурация: УТ 11.5.

Нужно:
  1. Сформулировать задачу для программиста.
  2. Определить, какие вопросы задать клиенту.
  3. Определить возможные риски.
  4. Составить критерии приёмки.
  5. Составить тест-кейсы.

Код писать не нужно.

Результат — не пересказ слов клиента, а понятная задача с вопросами, рисками и критериями приёмки.

Вынесите правила в CLAUDE.md или AGENTS.md

Чтобы не повторять одно и то же в каждой задаче, положите постоянные правила в файл проекта:

Правила проекта:
  1. Не изменять типовые модули без явного разрешения.
  2. Не создавать новые объекты конфигурации без согласования.
  3. Не использовать запросы в цикле.
  4. Использовать русские имена процедур, функций и переменных.
  5. Перед изменением кода сначала давать план.
  6. После изменения кода объяснять, что было изменено.
  7. Если данных недостаточно — задавать вопросы, а не придумывать.
  8. Не работать с боевой базой.
  9. Все изменения должны проходить через Git и ревью.
  10. Код, который разработчик не может объяснить, не принимается.

ИИ каждый раз видит рамки проекта — и ошибок в постановке становится меньше.