Какая локальная модель лучше пишет код 1С: практические замеры в OpenCode

Десять моделей, восемь одинаково устроенных испытаний для каждой, четыре уровня доступных знаний и два способа проверить черновик. Победила Gemma 4 31B, но самый поучительный результат оказался не в первой строке рейтинга.

Мы начали с простого вопроса: что сделает локальная модель, если попросить её написать на 1С не учебный фрагмент, а функцию с настоящими ограничениями? У модели нет исходников конкретной конфигурации. Зато по мере испытания ей можно дать справку платформы, библиотеку стандартных подсистем (БСП) и стандарты разработки. Хотелось отделить собственное знание модели от пользы библиотечного поиска, а затем проверить распространённую идею: «пусть быстрая модель набросает код, а сильная его исправит».

Все основные прогоны шли в OpenCode. Единственным внешним источником знаний был LEM через MCP — протокол, по которому агент вызывает библиотечные инструменты. Другие оболочки и отдельные испытания harness здесь не сравниваются: им нужна своя статья.

Короткий ответ. Gemma 4 31B получила лучший средний балл первого прохода — 53,50/100. Связка «Qwen 35B-A3B пишет → Gemma 31B проверяет» подняла результат до 54,88/100, но заняла примерно 706 секунд на задание вместе с черновиком против 381 секунды у одной Gemma. Для этого набора задач одиночная Gemma оказалась выгоднее по сочетанию качества и времени. Ни один балл в статье не означает, что код проверен компилятором 1С или готов к установке.

Задача: один документ и десять тысяч ссылок

Основной набор содержал две версии одной абстрактной задачи. В простой версии экспортная серверная функция получает ссылку на документ и возвращает его номер, дату, организацию и контрагента. В сложной версии на вход приходит массив до 10 000 ссылок разных видов; ответом должна стать ТаблицаЗначений, которая сохраняет порядок и повторы. Загружать каждый объект целиком и выполнять запрос по одной ссылке в цикле запрещено. Нужно учитывать пустые и удалённые ссылки, отсутствующие реквизиты, права доступа и размер пакета.

Здесь намеренно нет контекста конфигурации. Мы не просили работать с конкретным документом БГУ или чужим модулем. Задача проверяет язык BSL, общие механизмы платформы, БСП и стандарты. Привязка ответа к вымышленному виду документа в таком тесте — ошибка, а не проявление полезной конкретики.

Для каждой версии было четыре режима. Они обозначены A–D; это ступени доступа к знаниям и одновременно разные, заранее сохранённые формулировки задания.

Режим	Что было доступно агенту	Что проверяли
A — без знаний	Только условие, без инструментов и поиска	Что модель знает и домысливает сама
B — платформа	Поиск в библиотечном корпусе по справке 1С	Может ли подтвердить платформенный API
C — платформа + БСП	Поиск и подбор подходящей функции БСП	Выберет ли пакетное решение вместо запроса в цикле
D — полный маршрут	Платформа, БСП, стандарты и требование доказать внешние вызовы	Удержит ли модель ограничения и обоснует решение

Каждый режим запускался в новой сессии OpenCode с --pure --agent build; переносить ответ между режимами и давать подсказки вручную было нельзя. Остальные MCP и встроенные инструменты отключались. На один запуск отводилось не более 45 минут. Таким образом, у модели было восемь официальных попыток: простая A–D и сложная A–D. Это не восемь повторов одного промпта: режимы различались доступом к знаниям, а простая и сложная версии — условиями.

Мы оценивали итоговый ответ по 100-балльной шкале: функциональность — 40, производительность — 25, клиент-серверная граница — 10, крайние случаи и соблюдение контракта — 15, читаемость — 10. Балл отражает экспертную статическую оценку кода и объяснения. Компиляция в конфигураторе и автоматические тесты на платформе 1С в этой серии не выполнялись.

Первый круг: модели без знаний и с библиотекой

Ниже весь сохранённый рейтинг первого прохода. Столбцы «простая» и «сложная» показывают переход A → D внутри одной модели; средний балл рассчитан по всем восьми режимам, включая B и C. Отсутствующее время означает, что в сводном протоколе нет подтверждённой сопоставимой величины; нули и таймауты не скрыты.

Модель и вариант	Простая A → D	Сложная A → D	Средний балл /100	Среднее время*
Gemma 4 31B IT, Q8 + MTP	68 → 52	32 → 61	53,50	381 с
Devstral Small 2 24B, Q8	55 → 40	15 → 35	36,88	162 с
Qwen 35B-A3B, исходный стенд	10 → 56	11 → 61	36,50	189 с
Qwen3.8 Flash-Next, AD-Q4	18 → 33	12 → 68	34,38	—
Qwen Coder Next, исходный стенд	19 → 43	23 → 43	32,75	93 с
Qwen3.8 Flash-Next, IQ3	18 → 62	20 → 27	29,25	936 с
Gemma 4 26B QAT, Q4 + MTP	46 → 45	32 → 0	28,00	112 с
Qwen 122B, исходный стенд	9 → 34	16 → 46	27,00	215 с
GLM-5.3-Flash, IQ2	0 → 0	0 → 0	19,63	—
Qwen3.8 27B, Q8 + MTP	35 → 25	0 → 0	18,50	≥1 950 с

* Время — длительность полного ответа OpenCode, а не скорость генерации токенов. Модели работали на разных вычислительных платформах, движках и вариантах сжатия весов. Поэтому столбец помогает оценить конкретные прогоны, но не доказывает, что одна архитектура всегда быстрее другой на одинаковом оборудовании. Q8/Q4/IQ3 — варианты хранения весов с разной точностью; MTP — ускорение за счёт предсказания нескольких токенов. В ряде строк время включает таймауты или отличается составом платформенного стенда.

Самый наглядный переход дала Qwen 35B-A3B на сложной задаче: 11 → 29 → 55 → 61 балл от A к D. Без библиотеки модель начинала с неверного кода; с БСП ей стала доступна разумная пакетная архитектура. Но даже ответ на 61 балл сохранил ошибки BSL, поэтому рост оценки нельзя читать как «готовая функция».

Gemma 31B выиграла не потому, что каждый дополнительный слой всегда улучшал её ответ. В простой задаче A уже дала 68 баллов, а D — 52: дополнительные поиски и объяснения могут отвлечь модель или добавить неподтверждённые детали. Зато в сложной задаче Gemma прошла путь от 32 до 61 и в режиме C показала лучший свой сложный ответ — 62 балла. Она использовала идею пакетного чтения значений реквизитов через БСП и сохранила порядок и дубли. В листинге остались опечатка и риск неверной сигнатуры функции: это кандидат на проверку, а не фрагмент, который можно бездумно вставить в конфигурацию.

Devstral был быстрым в своём стенде и занял второе место по среднему баллу, но регулярно придумывал имена API и допускал синтаксические ошибки. Qwen Coder Next тоже хорошо держал структуру и дал ответ за 93 секунды в среднем, однако использовал методы и типы, которых нет в BSL. Qwen 122B показал, почему размер модели сам по себе не решает задачу 1С: объяснение нередко выглядело убедительно, а исполняемый код оставался неверным.

У Flash-Next AD-Q4 высокий результат в сложном D — 68 баллов — не отменяет слабых простых ответов. Вариант IQ3 проходил инструментальный диалог стабильно, но качество сложного кода и длительность оказались хуже. Qwen3.8 27B дважды дошёл до лимита 45 минут и иногда не выдал финальный код. GLM-5.3-Flash резко выстрелил в двух промежуточных простых режимах, но нулевые ответы в остальных не позволили считать это устойчивым результатом.

Есть важная граница всей таблицы: в первоначальных 24 ответах трёх исходных моделей — Qwen 35B, Qwen 122B и Qwen Coder Next — не было ни одного готового к выполнению листинга BSL. Баллы дают степень приближения к контракту, а не процент прошедших тестов. Даже у победителя осталась потребность в синтаксической и платформенной проверке.

Почему библиотека помогла, но не «написала код»

Польза LEM была конкретной. Вместо догадки «наверное, есть универсальный метод получения реквизитов» агент мог найти кандидата БСП и документацию платформы. Стандарты добавили проверку на запросы в цикле, границы серверного выполнения и обращение с отсутствующими реквизитами. Это особенно заметно на сложной версии: нужно сохранить соответствие каждой исходной позиции строке результата, даже если одна ссылка встречается дважды.

Но найденная страница и корректный вызов — разные вещи. Модель могла назвать верную функцию БСП, а затем ошибиться в параметрах, типе возврата или BSL-синтаксисе. Иногда она ссылалась на стандарт, но нарушала его в собственном коде. Поэтому режим D оценивал не количество найденных страниц, а подтверждённость внешних вызовов и соблюдение всего контракта. В этом тесте полезные знания улучшали направление поиска; последним звеном всё равно оставалась проверка на платформе.

Второй круг: «проверь себя ещё раз»

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

Модель проверяет свой черновик	Первый проход	Второй проход	Изменение
Gemma 4 31B	53,50	39,75	−13,75
Qwen 35B-A3B	36,50	25,50	−11,00
Qwen Coder Next	32,75	18,50	−14,25
Devstral Small 2	36,88	7,00 на 2 задачах	Полная серия не завершена

Все три полные серии ухудшились. Gemma точнее других соблюдала лимиты инструментов, но при переписывании всё равно добавляла ошибки. Qwen 35B порой верно называла дефект, а заменяла его смесью BSL и конструкций других языков. Coder Next создавал новые несуществующие типы и методы. Серия Devstral оборвалась после двух задач из-за несовместимости шаблона диалога с инструментальными вызовами; её число нельзя сравнивать как среднее по восьми.

Это не доказательство, что самопроверка бесполезна всегда. Здесь модели получали текст и библиотечный поиск, но не получали реальный список ошибок компилятора 1С. Без независимой обратной связи второй проход легко превращается в уверенное переписывание одного спорного решения другим.

Третий круг: пусть черновик проверит другая модель

Мы взяли черновики Qwen 35B и Gemma 31B и передали их другим моделям в той же оболочке OpenCode. Это уже не самопроверка: проверяющий видит задачу и чужой результат. В каждой строке ниже средний балл второго прохода по восьми заданиям; неуданные финальные ответы получили ноль.

Кто написал → кто проверил	Балл /100	Среднее время проверки
Qwen 35B → Gemma 31B	54,88	517 с
Gemma 31B → Qwen 35B	47,75	150 с
Qwen 35B → Qwen Coder Next	21,88	483 с
Gemma 31B → Qwen 122B	16,38	242 с
Qwen 35B → Qwen 122B	12,25	277 с

Комбинация Qwen → Gemma действительно дала лучший средний балл всей двухпроходной серии. Gemma подняла черновики Qwen с 36,50 до 54,88 и ни разу не превысила лимит обращений к инструментам. Особенно сильными стали простые задания: 69,5 балла в среднем. На сложных осталось 40,25 — слабое место не исчезло.

Но «быстрый черновик + умный редактор» не стал самым быстрым способом получить ответ. Средний первый проход Qwen занимал 189 секунд, проверка Gemma — ещё 517. Итого около 706 секунд против 381 у Gemma за один проход, при разнице качества всего 1,38 балла. Это сравнение полных измеренных циклов, а не скорости моделей на одинаковом железе. В остальных сочетаниях перекрёстный проход часто ухудшал результат. Из 40 завершённых запусков 12 не дали пригодного финального текста; лимит вызовов был нарушен в 22.

Практический выбор для этого набора: если нужен один ответ, разумнее сразу начать с Gemma 31B и затем проверить код инструментами 1С. Связка Qwen → Gemma имеет смысл, когда быстрые черновики можно готовить параллельно для нескольких задач или проверяющей модели отдаётся только узкий проблемный участок. Такой выигрыш мы здесь не измеряли и не включаем в вывод.

Позднее испытание Bonsai2: полезная идея, неверный язык

После основной матрицы появился отдельный ответ Bonsai2 — по описанию автора, переработанного варианта Qwen3.8. Ему дали другое задание: объединить две ТаблицаЗначений по общему ключу, собрать все уникальные колонки и явно выбрать таблицу с приоритетом для совпадающих значений. В запросе требовалось использовать Синтакс-помощник, БСП и стандарты из LEM.

Экспертная оценка этого ответа — около 20/100. Модель поняла схему внешнего объединения, приоритет колонок и уместно вспомнила ЗаполнитьЗначенияСвойств: эту процедуру рекомендует стандарт 1С № 448 для копирования строк между таблицами сходной структуры. Затем модель записала в 1С-код неподтверждённые Новый Словарь, Поставить, Найти, Ошибка(...) и Не Неопределено(...); преобразование ключа в строку могло склеить разные типы. Заявление ответа о «нуле диагностических ошибок» не подкреплено трассой проверки.

Bonsai2 не получает место в таблице A–D: задача другая, а точная ревизия, сжатие весов, параметры запуска и протокол OpenCode/LEM для этого ответа не сохранены. Это показательный дополнительный пример той же проблемы — верная общая идея не гарантирует знание точного языка 1С. Новый приоритетный сценарий объединения таблиц также нельзя смешивать со старой задачей чтения реквизитов документов.

Что мы выбрали бы для реальной разработки

Для локального помощника по 1С в этом наборе Gemma 4 31B Q8 — лучший отправной вариант. Она дала самое высокое среднее качество в первом проходе и лучше других держала дисциплину при проверке чужого черновика. Это выбор среди испытанных вариантов, а не универсальный титул для всех версий Gemma и всего оборудования.

Рабочий процесс из измерений получается такой:

1. Дать модели точное задание с ограничениями и версией платформы.
2. Подключить нужные библиотеки LEM: Синтакс-помощник для API, точную версию БСП для функций, стандарты для правил реализации. Контекст конкретной конфигурации добавлять лишь тогда, когда задача зависит от неё.
3. Попросить отделить подтверждённые вызовы от предположений и показать, как сохранены порядок, дубли, права и производительность.
4. Проверить полученный BSL синтаксическим анализатором и, где возможно, в 1С; передать модели конкретные ошибки, если нужен повторный проход.
5. Проверить поведение на граничных данных. Красивое объяснение и высокий экспертный балл сами по себе этого шага не заменяют.

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

Как читать эти цифры

Это авторский прикладной опыт, а не лабораторное сравнение архитектур. Промпты и режимы A–D были зафиксированы до повторных прогонов; исходные ответы, времена и число вызовов сохранены. Оценка статическая и частично экспертная; реальные компиляция и тесты 1С не были обязательным финальным барьером. Между стендами различались оборудование, движок и квантование, поэтому секунды нельзя превращать в общий рейтинг аппаратной скорости. Результаты относятся к конкретной задаче, версиям моделей и конфигурациям запуска на момент испытания.

Основа статьи: внутренний архив 2026-08-28-onec-abcd с точными промптами, results-summary.csv, ALL_MODELS_1C_SCOREBOARD_RU.md, SECOND_PASS_QUALITY_SCORES_20260829_RU.md, полными трассами OpenCode и отчётом CROSS_MODEL_TWO_PASS_QUALITY_REPORT_RU.md. Ответ и исходное задание Bonsai2 сохранены отдельно в bonsai2-2026-10-07. Публичная копия сырого архива сейчас не опубликована.