Локальный LLM-помощник для 1С-разработчика: как встроить, что доверять, что проверять руками
Что на самом деле произошло
LLM хорошо умеет три вещи: формулировать черновик кода по описанию, переводить между формами одного и того же (SQL ↔ запросы 1С, JSON ↔ структура, описание ↔ заготовка обработки) и быстро объяснять незнакомый кусок. Это закрывает значительную часть рутины — но именно рутины. Бизнес-смысл, ответственность за корректность учёта, понимание отраслевой специфики конфигурации, тонкости прав и RLS — всё это по-прежнему остаётся на разработчике, и никакая модель не подпишет за вас акт сдачи-приёмки.
Спокойная позиция
Хорошая новость в том, что 1С-разработчик и раньше тратил большую часть времени не на «набивку кода», а на понимание задачи, чтение чужих модулей, отладку и согласование с заказчиком. Эту часть LLM не отбирает. А набивку — да, забирает. Это нормально и даже желательно: освободившееся время уходит на то, ради чего вас, собственно, и нанимали.
Что отдавать LLM, а что — нет
| Тип задачи | Кому поручить | Почему |
|---|---|---|
| Черновик запроса по описанию полей | LLM, потом проверка в консоли запросов | Синтаксис простой, типовые ошибки видны сразу при выполнении |
| Заготовка формы / обработки / отчёта | LLM, потом ручная доводка | Скелет всегда похож; экономит 70% времени на «нажать-кликнуть» |
| Перевод SQL-логики в язык запросов 1С | LLM + сверка по документации | Полезно при миграции с других учётных систем |
| Объяснение чужого модуля | LLM как «второй пары глаз» | Быстрее, чем разбираться с нуля; но решение принимать вам |
| Бизнес-логика учёта (НДС, проводки, закрытие месяца) | Только вы | Ошибка стоит дорого, ответственность по закону на специалисте |
| Настройка RLS и ролей | Только вы | Контекст безопасности модель не видит, риск утечки данных |
| Отраслевая логика нетиповой конфигурации | Только вы | Модель не знает вашу историю изменений, шаблонов имён, договорённостей в команде |
Минимальный рабочий контур
Не нужно строить «AI-платформу» с нуля. Достаточно одного локально запущенного движка LLM, текстового редактора с поддержкой промптов и папки с контекстом. Локальный движок предпочтительнее облачного по двум причинам: код заказчика не уходит наружу, и инструмент работает в контуре без зависимости от внешних сервисов.
- Поставьте локальный inference-движок (на выбор:
ollama,llama.cpp,vllm— любой, который вы умеете администрировать). Минимум 16 ГБ ОЗУ для моделей 7–13B, 32+ ГБ для 32B. - Заведите рабочую папку
~/1c-context/: туда положите выгрузку метаданных вашей основной конфигурации (имена справочников, документов, регистров — без данных), несколько типовых модулей с комментариями, ваш личный «свод хороших практик» в Markdown. - Создайте 5–7 промпт-шаблонов: «запрос по описанию», «обработка-загрузчик из Excel», «разбор ошибки журнала регистрации», «code review этого фрагмента», «объясни этот модуль». Промпты эволюционируют — храните их в git.
- Каждый ответ LLM прогоняйте через две проверки: синтаксическую (выполнить в консоли запросов / в обработке) и смысловую (соответствует ли описанной задаче).
- Никогда не вставляйте сгенерированный код в продуктивную базу без выполнения хотя бы на тестовом контуре. LLM придумывает несуществующие методы платформы достаточно часто, чтобы это правило окупалось.
Главное правило профессионала, работающего с LLM: вы остаётесь автором кода, который коммитите. Если завтра по этому коду сломается учёт, объяснять придётся вам, а не модели. Поэтому каждый сгенерированный фрагмент должен быть для вас понятен от первой до последней строчки — иначе его в репозиторий вкладывать нельзя.
Чек-лист внедрения за неделю
- Установите локальный движок и протестируйте на одной модели 7–8B; убедитесь, что задержка приемлема.
- Соберите выгрузку метаданных одной знакомой конфигурации и сохраните её в Markdown.
- Возьмите три недавние задачи из своей очереди и пройдите их в новом контуре. Замерьте время.
- Соберите личный список случаев, где LLM ошиблась — это ваш будущий «свод хороших практик».
- Поделитесь опытом с коллегами: общий контур и общие промпты в команде окупаются втройне.
Типичные ошибки
- Коммит без понимания. Вставили — заработало — закоммитили. Через месяц никто не вспомнит, что там делает этот цикл. Полный технический долг.
- Выгрузка чужого кода во внешний сервис. Кодовая база заказчика — часто коммерческая тайна; внешние модели могут логировать запросы. Локальный движок снимает риск.
- Доверие к выдуманным именам методов. Модель уверенно выдаёт несуществующие функции платформы. Без проверки в консоли — гарантированная регрессия.
- Один большой промпт на всё. Чем шире задача, тем хуже ответ. Разделяйте: «структура» отдельно, «запрос» отдельно, «UI» отдельно.
- Отказ от инструмента «из принципа». Через год соседи по рынку будут делать те же задачи за 30% времени. Принципиальность стоит дорого.
- Замена квалификации инструментом. Без понимания учёта и платформы LLM выдаёт правдоподобные, но опасные ошибки. Инструмент усиливает квалификацию, а не заменяет её.
Перейти в каталог решений →