ИИ может уверенно писать код на встроенном языке 1С, объяснять запросы, предлагать обработчики и разбирать ошибки. Но в реальной базе он часто спотыкается о простые вещи: использует реквизит, которого нет, путает документ, пишет проверку в неподходящем модуле, забывает про расширение или не учитывает права.
Снаружи это выглядит как слабость модели. На практике причина чаще в контексте. Модель пишет по тому набору фактов, который получила перед ответом.
Если в контексте нет структуры документа, модель будет достраивать ее по похожим решениям. Если нет информации о расширениях, она может предложить правку типового объекта. Если не передали стандарты команды, ответ будет технически похож на рабочий, но выбиваться из проекта.
Контекст — рабочий стол модели
Контекст LLM — все, что модель видит прямо сейчас. В него попадают системные инструкции, сообщение пользователя, история диалога, результаты MCP-вызовов, фрагменты кода, документы из RAG, ошибки тестов, логи, метаданные и ограничения проекта.
У модели есть общие знания о 1С. Она знает, что такое справочники, документы, регистры, управляемые формы, клиентский и серверный контекст. Конкретную информационную базу ей нужно показать через контекст.
В одной конфигурации заказ называется `ЗаказКлиента`, в другой — `ЗаказПокупателя`. Клиент может быть реквизитом `Контрагент`, `Партнер`, `Клиент` или находиться в связанной сущности. Логика может жить в модуле объекта, общем модуле, подписке, расширении или внешней обработке.
Для 1С это критично. Общие знания дают правдоподобный код, а рабочее решение появляется только после проверки фактов базы.
Хороший запрос к ИИ должен содержать задачу и границы: какую конфигурацию трогаем, какой объект целевой, можно ли менять типовую конфигурацию, где должна быть правка, какие данные нельзя изменять, что нужно проверить перед ответом.
Иначе модель ведет себя как разработчик, который пришел на проект в первый день и сразу пишет проведение документа, не открыв структуру объекта.
Большой контекст не всегда помогает
Кажется, что проблему можно решить грубо: выгрузить всю конфигурацию и отправить модели. В 1С этот путь быстро становится дорогим и шумным.
Контекстное окно ограничено токенами. На него расходуются системный промпт, история, задача, метаданные, код, документы, результаты инструментов и сам будущий ответ. Большая конфигурация легко занимает больше, чем модель способна нормально обработать. Даже при формальном попадании в окно получается огромная масса текста, где важные детали начинают теряться.
В длинном контексте появляются типичные проблемы:
- старое ТЗ спорит с новым;
- ограничения теряются среди кода и логов;
- похожие объекты конкурируют друг с другом;
- результаты инструментов вытесняют важную часть истории;
- модель возвращается к ранним гипотезам, которые уже опровергли.
Хороший контекст должен быть маленьким, точным и проверенным. Не вся конфигурация целиком, а целевой объект, нужные реквизиты, связанные регистры, правила проекта и фрагмент кода вокруг места изменения.
Четыре слоя контекста
Для 1С-задач удобно разделять контекст на четыре слоя: системный промпт, RAG, MCP и история диалога. У каждого своя работа.
|
Слой |
Что дает |
Где помогает |
|
Системный промпт |
Правила поведения модели |
Не выдумывать метаданные, проверять структуру, учитывать клиент-серверный контекст |
|
RAG |
Документацию и стандарты |
Как принято в команде, какие есть регламенты, примеры похожих доработок |
|
MCP |
Факты из живой базы |
Какие объекты есть, какие реквизиты и табличные части, какие движения и права |
|
История |
Текущую линию работы |
Что уже проверили, какие решения приняли, какие варианты отбросили |
Системный промпт не должен быть фразой "ты опытный 1С-разработчик". Такая инструкция почти не снижает риски. Лучше задавать конкретные правила: не использовать непроверенные реквизиты, сначала получать структуру объекта через MCP, разделять клиентский и серверный код, не предлагать запись данных без подтверждения.
RAG отвечает на вопрос "как у нас принято?". Он подгружает стандарты разработки, документацию платформы, правила интеграций, примеры корректных доработок, базу типовых ошибок. Но RAG может принести устаревший документ, поэтому его нельзя считать истиной по текущей базе.
MCP отвечает на вопрос "что реально есть здесь и сейчас?". Он может вернуть структуру документа, табличные части, движения, формы, фрагменты модулей, права ролей, журнал регистрации или данные по безопасному запросу на чтение.
История полезна до момента, когда в ней накапливаются старые гипотезы. В длинной работе стоит явно фиксировать актуальные выводы: целевой объект, проверенные реквизиты, действующие ограничения, что уже сделано и какие варианты больше не рассматриваем.
MCP дает доступ, но не заменяет понимание
Подключение MCP к 1С не означает, что модель мгновенно знает конфигурацию. MCP дает канал доступа к фактам и инструментам. Дальше агент должен правильно выбрать, что запросить, в какой последовательности и в каком объеме.
Плохой сценарий выглядит так: агент получает огромный список объектов и сразу пишет решение. Формально контекст есть, но он слишком общий.
Хороший сценарий идет шагами:
- Понять цель и ограничения.
- Найти целевой объект через MCP.
- Получить структуру объекта.
- Проверить табличные части, реквизиты и типы.
- Посмотреть движения или связанный код, если они важны.
- Подгрузить стандарты команды через RAG.
- Сформировать список проверенных фактов.
- Только после этого писать план и код.
Например, задача звучит так: запретить проведение заказа, если в строках не заполнена аналитика продаж. Модель может сразу написать цикл по `Объект.Товары` и реквизиту `АналитикаПродаж`. Но сначала нужно проверить, какой именно документ используется, есть ли табличная часть `Товары`, как называется колонка, где принято делать такие проверки и можно ли менять типовой модуль.
Сила MCP не в выгрузке всего подряд. Сила в точечном доступе: получить нужный факт в нужный момент и не засорить окно лишними данными.
Как выглядят ошибки плохого контекста
Галлюцинации в 1С часто выглядят почти как рабочий код. Именно поэтому они опасны. Ответ уверенный, синтаксис похож на правильный, структура знакомая. Ошибка обнаруживается уже при проверке в базе.
Типовые причины:
- не получили метаданные и использовали несуществующий реквизит;
- не проверили табличную часть;
- не посмотрели движения документа;
- не учли клиентский и серверный контекст;
- забыли про расширение;
- не подгрузили стандарты проекта;
- не проверили права и РЛС.
Классический пример: модель пишет `Объект.ДоговорКонтрагента`, потому что в похожих конфигурациях такой реквизит встречается. В текущей базе используется `Соглашение`. Код выглядит правдоподобно, но работать не будет.
Такую ошибку нельзя лечить просьбой "будь внимательнее". Нужен другой порядок работы: сначала факты, потом решение.
Паспорт контекста
Полезный прием для 1С-задач — оформлять контекст как короткий паспорт. Лучше в структурном виде, например YAML. Он убирает лишний текст и явно отделяет проверенные факты от предположений.
task: "Проверка перед проведением"
target: "Документ.ЗаказКлиента"
change_mode: "Только расширение"
tabular_section: "Товары"
fields:
- "Номенклатура"
- "Количество"
- "АналитикаПродаж"
constraints:
- "Не использовать непроверенные реквизиты"
- "Сначала предложить план"
- "Код писать после проверки структуры"
Такой формат помогает модели держать рамки. Видно, какой объект целевой, какие поля уже проверены, где можно менять код и какие ограничения действуют. Его проще обновлять по мере работы: нашли другую табличную часть, добавили факт; выяснили, что правка только через расширение, зафиксировали; нашли стандарт команды, добавили ссылку.
Практический порядок работы
Рабочий алгоритм с ИИ в 1С можно собрать в короткую последовательность.
Сначала формулируем цель и ограничения. Затем через MCP находим целевой объект и получаем его структуру. После этого проверяем связанные объекты, движения, модули и права, если они влияют на задачу. Через RAG подгружаем стандарты команды и похожие решения. Просим агента отдельно перечислить проверенные факты и предположения. Только после этого переходим к плану и коду.
Перед принятием ответа стоит проверить четыре вещи:
- использованы реальные имена объектов и реквизитов;
- правка попала в допустимое место;
- учтены права, расширения и клиент-серверный контекст;
- есть понятный способ проверить результат.
Если агент сразу пишет код без проверки структуры, это сигнал риска. Особенно в задачах с проведением документов, движениями регистров, правами и изменением данных.
Выводы
Качество ответа ИИ в 1С складывается из качества задачи, качества контекста, качества инструментов и качества проверки. Сильная модель без фактов по вашей базе все равно будет угадывать.
RAG и MCP лучше работают вместе. RAG дает правила и методологию, MCP дает факты из текущей базы, системный промпт задает дисциплину, а история удерживает ход работы. Главное — не превращать контекст в свалку всего проекта.
Хороший контекст должен быть точным, маленьким и проверенным. Для 1С это особенно важно: один неверный реквизит или неправильное место правки превращают красивый ответ в нерабочий код.
А как вы думаете, чего чаще не хватает ИИ в ваших 1С-задачах: фактов из базы, стандартов команды или проверки результата? Напишите в комментариях.
Вступайте в нашу телеграмм-группу Инфостарт