Ловушка "ПЕРВЫЕ 100": как нейросеть тихо потеряла 5 товаров на складе 1С

🔍 Паспорт метаданных: почему нейросети нельзя давать свободную постановку

Когда разработчик ставит задачу искусственному интеллекту в свободной форме вроде «Сделай форму остатков номенклатуры для УТ 11», результат почти всегда оказывается непригодным к промышленной эксплуатации. Языковая модель не знает конкретный релиз конфигурации, режим совместимости и точную схему метаданных. В итоге она начинает домысливать окружение: использует имена регистров из УТ 10.3, обращается к несуществующим ресурсам или путает способ поставки (внешняя обработка вместо расширения).

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

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

💻 Архитектура воспроизводимого стенда верификации на платформе 8.3.27.2130

Для объективной проверки запросов был спроектирован полностью автономный тестовый стенд. Исследуемое ограничение вынесено в изолированный запрос к таблице значений (помещаемой во временную таблицу), что позволило протестировать алгоритмическую логику без привязки к тяжеловесной демо-базе УТ 11.

Сценарий сборщика выполняет следующие шаги в автоматическом режиме:

1. Создаёт чистую файловую базу 1С пакетом команд утилиты платформы.
2. Выгружает каркас конфигурации в XML, добавляет программные общие модули ОстаткиПроба и ПроверкаОстатков, загружает их обратно и выполняет обновление конфигурации базы данных.
3. Запускает пакетную синтаксическую проверку: /CheckModules -Server -ExternalConnection.
4. Инициализирует COM-соединение, вызывает функцию верификации ПроверкаОстатков.Запустить() и сериализует детальный отчёт в JSON.

python build_stand.py --output run
Синтаксических ошибок не обнаружено!
{"variant": "stock", "passed": 8, "total": 8}

Выполнение скрипта завершается с нулевым кодом возврата, подтверждая успешное выполнение всех 8 тестов. Детальные метрики и логи платформы фиксируются в run/stock-results.json.

📊 Дефект скрытого усечения: 100 строк вместо 105 на складе A

В исследуемом запросе параметр Данные загружается во временную таблицу. Далее накладываются условия по складу, положительному количеству и номенклатуре. Параметр Лимит динамически подставляет либо пустую строку, либо конструкцию ПЕРВЫЕ 100 .

1
2
3
4

Лимит = "";
Если ОграничитьСто Тогда
    Лимит = "ПЕРВЫЕ 100 ";
КонецЕсли;

Результаты прогона тестовой матрицы на синтетическом наборе выявили расхождение в полноте выборки:

Первый тест наглядно демонстрирует архитектурную проблему: ограниченный запрос молча оставляет за рамками выборки 5 реальных позиций из 105. В структуре отчёта stock-results.json факт подтверждается отдельными элементами массива:

1
2
3

{"id":"first100-truncates","pass":true,"expected":100,"actual":100}
{"id":"all-105","pass":true,"expected":105,"actual":105}
{"id":"item-105","pass":true,"expected":1,"actual":1}

Директива ПЕРВЫЕ 100 допустима исключительно тогда, когда бизнес-требование явно формулирует задачу как получение топ-100 записей с обязательной сортировкой УПОРЯДОЧИТЬ ПО. Если же перед пользователем открывается журнал складских остатков, искусственный лимит искажает результаты учёта. Вопрос оптимизации производительности решается построением правильных индексов и виртуальных таблиц среза, а не усечением выборки.

🚨 Ловушка неограниченных строк: почему синтаксического контроля недостаточно

При первичной генерации кода разработчики нередко полагаются на штатный синтаксический контроль платформы (/CheckModules), полагая, что отсутствие синтаксических ошибок гарантирует корректность выполнения. Опыт стендового тестирования доказывает обратное.

В первоначальной конфигурации таблицы значений колонкам был присвоен базовый тип Строка без явного указания длины. Модули успешно прошли статический контроль платформы 8.3.27.2130. Однако при реальном исполнении запроса через внешнее соединение платформа выдала фатальное исключение времени выполнения:

{ОбщийМодуль.ОстаткиПроба.Модуль(26)}:
Ошибка при вызове метода контекста (Выполнить):
{(10, 19)}: Неверные параметры в операции сравнения.
Нельзя сравнивать поля неограниченной длины и поля несовместимых типов.
ГДЕ Остатки.Склад = &Склад

СУБД и встроенный язык запросов 1С не поддерживают операции сравнения и группировки для строковых полей неограниченной длины. Чтобы устранить сбой, в генератор тестовых данных было внесено явное ограничение квалификатора длины:

1
2
3

СтроковыйТип = Новый ОписаниеТипов("Строка", , Новый КвалификаторыСтроки(100));
Данные.Колонки.Добавить("Склад", СтроковыйТип);
Данные.Колонки.Добавить("Номенклатура", СтроковыйТип);

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

🎯 Спецификация задачи для нейросети: готовый инженерный шаблон

Для гарантированного получения чистого BSL-кода в состав архива-компаньона включён готовый шаблон задания prompt.md. Он структурирован таким образом, чтобы исключить любые двусмысленности при генерации запроса и формы динамического списка.

Ключевые блоки инженерного промпта:

• Контекст метаданных: точное указание регистра (например, РегистрНакопления.ТоварыНаСкладах.Остатки), измерений (Номенклатура, Склад, Характеристика) и ресурсов (ВНаличии).
• Запрет искусственных лимитов: явный запрет на использование несанкционированных конструкций ПЕРВЫЕ N в основном запросе.
• Обработка параметров и отборов: разделение параметров виртуальной таблицы (для фильтрации на уровне СУБД) и пользовательских отборов динамического списка (рекомендуемый шаблон 1C International).
• Поведение при сбросе фильтров: обязательное описание того, что происходит при очистке поля выбора склада (полная очистка списка либо срез по всем складам предприятия).
• Секция ненайденных определений: инструкция агенту не придумывать имена, а формировать блок открытых вопросов при отсутствии точных типов.

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

🔒 Регламент приёмочного тестирования на копии рабочей базы УТ 11

Хотя изолированный стенд с временной таблицей подтверждает алгоритмическую полноту запроса, итоговая форма динамического списка должна быть принята на актуальной тестовой копии целевой конфигурации УТ 11 / ERP. Приёмочный регламент включает четыре обязательных этапа:

1. Сквозной сценарий фильтрации по складам: последовательное переключение Склад A → Склад B → Очистка поля. Проверяется, что при переключении склада строки предыдущего склада мгновенно удаляются из отображения, а при очистке отбора поведение соответствует согласованному ТЗ.
2. Сверка итогов с типовым отчётом: сравнение количества позиций и суммарных остатков с отчётом «Ведомость по товарам на складах» на идентичную дату и время среза.
3. Контроль нулевых и отрицательных значений: проверка отображения товаров с отрицательным остатком при наличии разрешённого списания в минус в настройках склада.
4. Проверка прав доступа и RLS: запуск формы под учётной записью линейного пользователя (роли Кладовщик или МенеджерПоПродажам). Проверяется, что форма не падает с ошибкой нарушения прав доступа и не открывается в привилегированном режиме без отдельного согласования с архитектором.

Приёмка завершается фиксацией плана отката (деактивация или удаление расширения) и проверкой отсутствия изменений в метаданных основной конфигурации.

📂 Содержимое архива-компаньона и инструкция по запуску стенда

Для воспроизведения описанных проверок подготовлен компактный архив-компаньон «Проверка полноты запроса остатков 1С .zip» (1 SM, 8.20 КБ). Для запуска требуются:

• Операционная система Windows.
• Установленная 32-битная платформа 1С:Предприятие (в нашем тесте — 8.3.27.2130 x86).
• Зарегистрированная библиотека comcntr.dll (V83.COMConnector).
• Python версии 3.12 или выше.

Запуск автоматизированного прогона выполняется одной командой из терминала:

# Стандартный запуск с автоопределением установленной платформы
python build_stand.py --output run

# Запуск с явным указанием пути к исполняемому файлу 1С
python build_stand.py --platform "C:\Program Files (x86)\1cv8\8.3.27.2130\bin\1cv8.exe" --output run

Файловый состав архива:

• build_stand.py — главный оркестратор: создание временной базы, компиляция XML-исходников, запуск синтаксической проверки и сбор результатов.
• run_com.ps1 — скрипт вызова COM-объекта в изолированном 32-битном процессе PowerShell с локальной политикой выполнения.
• src/ОстаткиПроба.bsl и src/ПроверкаОстатков.bsl — программные модули логики запроса и тестовых наборов.
• prompt.md — верифицированный шаблон инженерного задания для нейросети.
• acceptance.md — пошаговый протокол приёмки на целевой конфигурации УТ 11.
• run/stock-results.json — эталонный протокол успешного прогона 8 тестов.

🏁 Итоги и правила надёжного применения ИИ в разработке 1С

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

1. Контролируйте полноту выборки: директива ПЕРВЫЕ 100, добавленная без проектной необходимости, приводит к потере данных. Тестируйте запросы на массивах, превышающих лимит.
2. Фиксируйте метаданные до генерации: паспорт задачи защищает от галлюцинаций и подмены типов.
3. Исполняйте, а не только компилируйте: синтаксический анализатор платформы слеп к ошибкам операций сравнения строк неограниченной длины и несовместимости типов в запросах.
4. Принимайте в контексте пользователя: форма динамического списка должна быть проверена на копии целевой конфигурации под реальными ролями и профилями доступа.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S