Представьте, что вы просите ИИ-ассистента написать код для 1С

Представьте, что вы просите ИИ-ассистента написать код для 1С. Вы даёте ему, казалось бы, простую задачу: «выбери контрагентов с задолженностью больше 30 дней». Универсальный инструмент, обученный на миллионах примеров, с высокой уверенностью выдаст синтаксически безупречный запрос, который обращается к реквизиту «Задолженность» у справочника контрагентов. Выглядит правдоподобно, код компилируется, но результат — абсолютно бесполезен, потому что в реальной конфигурации такого реквизита нет. Задолженность в 1С почти никогда не хранится плоским полем, она вычисляется через регистры накопления. Модель не злонамеренно вводит вас в заблуждение, она просто не имеет доступа к вашей метаданной и подставляет статистически наиболее вероятное, но ложное имя.

Это фундаментальная проблема: 1С — это не язык с фиксированной стандартной библиотекой, как Python. Это платформа, где 90% сущностей, с которыми вы работаете — справочники, регистры, документы, их реквизиты — генерируются индивидуально под каждую конфигурацию. Универсальной «правильной» структуры данных не существует. Есть только то, что реально реализовано в вашей конкретной базе. И пока ассистент не имеет доступа к этой конкретике, он обречён галлюцинировать, предлагая поля-фантомы, которые звучат как валидные имена, но не привязаны ни к одной реальной базе.

Решение лежит не в улучшении модели, а в изменении архитектуры взаимодействия. Агент должен сначала прочитать вашу конфигурацию, а уже потом писать код. Не документацию по платформе, не общие представления о стиле BSL, а конкретную выгрузку конкретной базы: объекты метаданных, реквизиты, табличные части, типы, существующий код. Технически это реализовано через цикл tool-calling: агент вызывает инструмент, получает результат, анализирует его и решает, нужен ли следующий вызов или уже можно давать ответ. На нетривиальный запрос уходит от трёх до десяти и более вызовов инструментов за один ответ. Это не классический RAG, где вы достали релевантный чанк и вставили его в промпт. Агент сам решает, какой инструмент использовать на каждом шаге, и может вернуться назад, если результат его не устроил.

Рассмотрим более сложный пример. В типовой конфигурации у документа «ЗаказПокупателя» в табличной части «Товары» стандартный набор полей: Номенклатура, Количество, Цена, Сумма. Но у вас накатано расширение, которое добавляет в эту табличную часть новый реквизит и правит расчёт суммы с его учётом. Спросите generic-ассистента «напиши запрос, который выберет товары в заказе с итоговой суммой» — и получите синтаксически рабочий, но полностью бесполезный код, который игнорирует ровно ту скидку, ради которой вы писали расширение. Ассистент не мог поступить иначе: он видел только «стандартную 1С», а не то, что реально накатано у вас поверх. Агент с доступом к конфигурации сначала накладывает расширения на основную конфигурацию в порядке приоритета, с учётом аннотаций &Вместо и &После, и видит итоговую картину. Он знает, что это поле физически существует в объекте, которым вы пользуетесь каждый день, даже если в «чистой» типовой конфигурации его никогда не было.

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

Обычная рабочая цепочка в 1С — это не одна функция, а несколько, раскиданных по разным модулям и типам объектов. Обработчик проведения документа в модуле объекта вызывает функцию из общего модуля, та обращается к менеджеру записи регистра накопления, а он ещё дальше — к процедуре в модуле формы. Четыре разных модуля, три разных типа сущности, и всё это одна логическая цепочка, которую человеку приходится собирать вручную, кликая по каждому вызову и держа в голове, где он сейчас находится. У агента эта связка уже собрана на этапе загрузки и разбора конфигурации, вместе со всей остальной аналитической моделью. Когда он вызывает построение графа вызовов, он не парсит заново текст четырёх модулей — он читает уже готовые рёбра графа, вычисленные один раз при загрузке и пересчитанные инкрементально после правок.

Типизация — ещё один критический момент. Движок анализа уже определяет типы переменных и параметров функций там, где это можно установить по коду, ещё на этапе разбора, до всякого участия агента. Когда агент пишет код, использующий существующую переменную или параметр, он оперирует не догадкой «это, наверное, СправочникСсылка», а уже вычисленным типом. Из той же готовой базы агент получает доступ к результатам девяти сканеров статического анализа: безопасность, производительность, транзакции, блокировки, фоновые задания, плохие имена переменных, рекурсия. Плюс роли и права доступа к объектам, реквизиты форм и макетов. Всё это — не то, что агент «ищет» по вашему запросу, а то, к чему он уже имеет прямой доступ через SQL-запрос к готовым таблицам.

Отдельного внимания заслуживает поиск. Обычный полнотекстовый поиск по коду работает по точному или частичному совпадению текста. Спросить «где мы проверяем, не просрочен ли контрагент», не помня точного имени функции — он бессилен в принципе. Векторный поиск решает это иначе: каждая функция и объект конфигурации проходят через модель эмбеддингов и превращаются в вектор фиксированной размерности — математическое представление смысла, а не текста. Дальше поиск — это косинусное расстояние между вектором вопроса и векторами проиндексированных сущностей. Ключевое архитектурное решение — эмбеддинг-модель считается локально, отдельным Python-процессом, который держится в памяти постоянно, а не поднимается заново на каждый вызов. Индексация не отправляет код в облако вообще: весь массовый прогон по конфигурации, потенциально десятки тысяч функций, происходит на диске пользователя. В облако уходит только точечный контекст под конкретный вопрос: код той функции, которую агент решил прочитать, результат конкретного поискового запроса. Семантический и полнотекстовый поиск работают в связке — гибридный поиск, где агент сам решает, какой из двух методов использовать. Точное совпадение по редкому идентификатору забирает FTS5, вопрос, сформулированный своими словами без единого точного термина из кода — векторный поиск.

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

Граф вызовов строится не только по прямым текстовым вызовам. В 1С хватает мест, где реальная связь между кодом спрятана иначе: динамически собранная строка, где имя вызываемого метода формируется в рантайме; оповещения, где связь между тем, что оповестило, и тем, что среагировало, не выражена прямым вызовом; подписки на события, где связь прописана не в коде функции, а отдельно в метаданных подписки; фоновые задания, где запуск и содержимое задания — две разные вещи. Все эти случаи разбираются отдельно: часть эвристиками по паттернам в коде, часть — прямым разбором метаданных подписок на события. Смысл в том, что и граф вызовов, и ответы агента опираются не только на то, что видно в тексте функции, а на все способы, которыми одна часть системы в 1С реально может дотянуться до другой.

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

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

Вопрос не в том, какая модель лучше — GPT-5 или Claude. Вопрос в том, что задача в принципе нерешаема без доступа к конкретной конфигурации. Агент с tool-calling, который сначала читает вашу базу, а потом пишет код, — это не просто очередная AI-надстройка. Это попытка решить проблему галлюцинаций архитектурно, а не через бесконечное увеличение размера обучающей выборки. И, наверное, главный вопрос здесь: готовы ли вы доверить написание кода инструменту, который знает вашу конфигурацию лучше, чем вы её помните?

Телеграм: t.me/ainewsline

Источник: vk.com

Комментарии: