Сразу сделаю важную оговорку: совсем ни одной строчки кода я всё-таки не написал — пару строк пришлось добавить самостоятельно. Например, при открытии карточки ценной бумаги я скрывал или показывал реквизиты, которые относятся к акциям или облигациям. Но весь код, связанный с взаимодействием с API, загрузкой данных, обработкой JSON, постраничной загрузкой, обновлением текущих и базовых значений, был написан ИИ — ChatGPT 5.5.
И самое интересное: этот код оказался рабочим.
Причём я хочу отдельно отметить важный для 1С-разработчика момент: в сгенерированном коде не было ни одной критичной «галлюцинации» в стиле несуществующих методов платформы. Все используемые методы были рабочими. Да, код не был идеальным. Где-то встречались конструкции Попытка…Исключение, которых можно было избежать. Где-то после отладки приходилось менять подход. Но общий результат был неожиданно практичным: код можно было вставлять в конфигурацию, запускать, отлаживать и постепенно доводить до рабочего MVP.
Коротко обо мне
Я разработчик 1С с некоторым опытом разработки. Я не специалист по фондовому рынку и на старте проекта мои знания в этой области были минимальными. При этом у меня было желание не просто «поиграться с ИИ», а попробовать поставить его на службу реальной прикладной задаче.
Мне хотелось проверить, может ли ИИ помочь пройти путь от идеи до работающего прототипа, если у разработчика есть опыт 1С, но почти нет знаний в предметной области.
Идея проекта
Задача была простой по формулировке, но не такой простой в реализации:
- Получить список акций и облигаций с Московской биржи.
- Загрузить текущую цену инструмента.
- Загрузить цену закрытия предыдущей торговой сессии.
- Посчитать разницу.
- Получить список лидеров падения или роста.
Позже я узнал, что текущая цена — это показатель LAST, а цена закрытия предыдущей торговой сессии — CLOSE. Эти термины и смысл их использования мне объяснил ИИ в процессе работы.
То есть изначально я пришёл не с готовой моделью данных, а с достаточно бытовой идеей: «Хочу видеть, какие бумаги сегодня сильно упали или выросли относительно предыдущей торговой сессии».
Первый этап: погружение в предметную область через ИИ
Первым делом я дал ChatGPT ссылки на документацию API Мосбиржи и начал задавать вопросы. Саму документацию я открывал в основном для проверки и уточнения, а основное объяснение получал в диалоге.
На этом этапе стало понятно, что у Мосбиржи есть разные типы данных.
Есть условно постоянная информация по ценным бумагам:
- код бумаги SECID;
- ISIN;
- режим торгов;
- рынок биржи;
- параметры облигаций;
- другие реквизиты инструмента.
Есть текущая рыночная информация, которая меняется во время торговой сессии:
- последняя цена LAST;
- лучшая цена покупки BID;
- объём;
- другие показатели.
Есть историческая информация:
- цена закрытия CLOSE;
- данные по предыдущим торговым дням;
- история торгов по инструменту.
Важным открытием стало то, что эти данные отдаются разными запросами API. Нельзя просто одним запросом получить «всё, что нужно». Нужно понимать, какие данные являются справочными, какие текущими, какие историческими, и загружать их разными механизмами.
Фрагмент переписки с ChatGPT
Я: Как получить текущую цену облигации?
ChatGPT: Для текущих рыночных данных нужно использовать блок marketdata. В нём можно получить, например, LAST, BID, OFFER.
Я: А где взять цену предыдущей торговой сессии?
ChatGPT: Для этого используется исторический endpoint /iss/history/..., а цена закрытия торговой сессии — это показатель CLOSE.
Такой фрагмент хорошо показывает, что ИИ выступал не просто генератором кода, а помощником по погружению в предметную область.
Второй этап: проектирование структуры базы
После первичного понимания API нужно было спроектировать структуру базы в 1С.
ИИ предложил не хранить всё подряд, а разделить данные по смыслу:
- справочники для постоянных сущностей;
- регистр текущих данных для оперативных значений;
- отдельный регистр базовых данных для сравнения с предыдущей торговой сессией.
В итоге появились основные объекты конфигурации:
- справочник «Ценные бумаги»;
- справочник «Эмитенты»;
- справочник «Режимы торгов»;
- справочник «Рынки биржи»;
- справочник «Инструменты биржи»;
- справочник «Показатели биржи»;
- регистр сведений «Текущие данные биржи»;
- регистр сведений «Базовые данные биржи».
Отдельно важным было решение по коду ценной бумаги. ChatGPT предложил использовать связку:
SECID + BOARDID
Это оказалось логичным, потому что один и тот же инструмент может встречаться в разных режимах торгов. В результате код ценной бумаги в базе формировался не просто по тикеру, а с учётом режима торгов.
Например: SBER_TQBR
Для акций и облигаций были заведены разные режимы торгов. На старте использовались:
TQBR — акции
TQCB — облигации
Позже стало понятно, что для облигаций может быть не только один режим, поэтому код пришлось доработать так, чтобы он проходил по всем режимам торгов, относящимся к рынку облигаций.
Фрагмент переписки с ChatGPT
Я: А как лучше формировать код ценной бумаги?
ChatGPT: Лучше использовать связку SECID + BOARDID, потому что один и тот же инструмент может торговаться в разных режимах торгов.
Эта подсказка повлияла на структуру справочника «Ценные бумаги» и помогла избежать неоднозначности при загрузке инструментов.
Третий этап: выгрузка конфигурации в файлы
Разработка нового функционала велась в новом расширении, для выгрузки я использовал стандартный пункт конфигуратора «Выгрузить конфигурацию в файлы»
После этого я загрузил ZIP-архив в чат. Это оказалось очень удобным: ИИ смог анализировать структуру конфигурации не по моим пересказам, а по реальным XML-файлам выгрузки.
Он увидел состав справочников, регистров, реквизитов, измерений и ресурсов. На основе этих файлов мы смогли обсуждать не абстрактную структуру, а конкретные объекты метаданных.
Позже на основе этой выгрузки была построена ER-диаграмма конфигурации. С первого раза она получилась неидеальной: связи были проведены между сущностями, а не между конкретными полями, диаграмма была слишком широкой, заголовки показывали технические имена объектов. После замечаний диаграмму пришлось дорабатывать:
- Связи должны идти от конкретного реквизита или измерения.
- В скобках нужно указывать тип реквизита.
- В заголовке лучше показывать синоним, а техническое имя можно оставить вторым планом.
Это хороший пример того, что ИИ может быстро сделать черновик, но качество результата сильно зависит от обратной связи разработчика.
Четвёртый этап: генерация кода загрузки
После того как структура была определена, я дал команду сгенерировать код загрузки данных.
Код писался в общий модуль мбСервер. Основные задачи модуля:
- обращаться к API Мосбиржи;
- получать JSON;
- разбирать блоки ответа;
- создавать или обновлять элементы справочника «Ценные бумаги»;
- загружать текущие значения LAST, BID, OFFER;
- загружать НКД для облигаций;
- загружать базовые значения CLOSE;
- записывать данные в регистры сведений.
ИИ сгенерировал процедуры и функции, которые постепенно превратились в рабочий серверный модуль.
Среди них были:
- СинхронизироватьЦенныеБумагиПоРежимуТоргов()
- ОбновитьТекущиеДанныеБиржи()
- ОбновитьТекущиеДанныеПоРежимуТоргов()
- ПолучитьТаблицуИсторииПоРежимуТоргов()
- ЗаписатьТекущееЗначение()
- ЗаписатьБазовоеЗначение()
Конечно, не всё получилось идеально с первого раза. Например, при работе с историческими данными Мосбиржи возникли сложности с пагинацией.
Пагинация и cursor: пример реальной отладки
Один из важных технических моментов — загрузка больших наборов данных из API Мосбиржи.
Сначала была логика: делать запросы порциями и увеличивать параметр start. Но на практике выяснилось, что простой признак «если строк меньше размера страницы — значит конец» не всегда удобен и надёжен.
Тогда мы перешли на использование блока history.cursor.
В нём API отдаёт: INDEX, TOTAL, PAGESIZE
И можно понимать, где мы находимся относительно общего количества строк.
Логика стала такой:
СледующееНачало = INDEX + PAGESIZE
Если СледующееНачало >= TOTAL — загрузка завершена
Но и здесь появилась 1С-специфичная проблема: блок в JSON называется history.cursor, а точка в имени свойства не подходит для чтения JSON в структуру 1С. Пришлось заменить имя блока перед чтением: history.cursor → history_cursor
Фрагмент переписки с ChatGPT
Я: Ошибка: недопустимое имя свойства history.cursor для чтения JSON в объект Структура.
ChatGPT: MOEX возвращает блок с точкой в имени. Для структуры 1С такое имя свойства недопустимо. Перед чтением JSON нужно заменить history.cursor на history_cursor.
Это отличный пример совместной работы:
- ИИ предложил подход через cursor;
- я запустил код и получил ошибку;
- отправил текст ошибки в чат;
- ИИ объяснил причину;
- после этого был сгенерирован исправленный вариант.
Это был один из тех моментов, где ИИ не просто написал код, а помог быстро понять причину ошибки и адаптировать внешний JSON под ограничения платформы 1С.
Текущие данные и базовые значения
В процессе обсуждения мы разделили текущие и базовые данные.
Текущие данные — это то, что обновляется часто во время торговой сессии. Например: LAST, BID, OFFER
Для них был создан регистр сведений «Текущие данные биржи».
Базовые данные — это значения, с которыми мы сравниваем текущие. В нашем случае это цена закрытия предыдущей торговой сессии: CLOSE
Для них был создан отдельный регистр «Базовые данные биржи».
Такое разделение оказалось удобным, потому что текущие значения могут обновляться часто, а базовые — только один раз в день или по отдельному регламенту.
Ещё важная договорённость: если из API приходит пустое значение текущего показателя, мы не затираем уже сохранённое значение в регистре. Это защищает данные от ситуации, когда временно в ответе нет цены, но предыдущее корректное значение у нас уже есть.
НКД по облигациям
Отдельной задачей стала загрузка НКД для облигаций.
Сначала логика была встроена не очень удачно: обновление НКД могло вызываться внутри цикла по режимам торгов не там, где нужно. После обсуждения мы пришли к более аккуратному варианту: обновлять НКД только для режимов торгов, относящихся к рынку облигаций.
Пример логики:
Если режим торгов относится к рынку облигаций, тогда обновляем НКД по этому режиму торгов.
Это тоже хороший пример: ИИ сгенерировал рабочий вариант, но после анализа логики стало понятно, что его нужно улучшить, чтобы код был не только рабочим, но и архитектурно правильным.
Что получилось в итоге
В результате получился MVP конфигурации, который умеет:
- загружать справочник ценных бумаг;
- различать акции и облигации;
- учитывать режимы торгов;
- получать текущие рыночные показатели;
- получать базовые значения для сравнения;
- загружать НКД по облигациям;
- сохранять данные в регистры сведений;
- строить основу для списка лидеров роста и падения.
Самое важное — проект двигался итерационно. Я не пытался сразу написать идеальную архитектуру. Вместо этого мы шли маленькими шагами:
- Получили данные из API.
- Создали структуру хранения.
- Написали первую загрузку.
- Поймали ошибку.
- Исправили.
- Добавили следующий показатель.
- Снова проверили.
Именно такой формат работы с ИИ оказался наиболее продуктивным.
Что понравилось в работе с ИИ
Первое — скорость погружения в предметную область.
Я не знал API Мосбиржи, не знал, какие показатели нужны, не знал разницу между LAST и CLOSE. Через диалог удалось быстро сформировать рабочее понимание.
Второе — генерация кода на реальном синтаксисе 1С.
Для меня было критично, чтобы ИИ не придумывал несуществующие методы платформы. В этом проекте код оказался очень близок к рабочему. Иногда его приходилось корректировать, но это была обычная отладка, а не борьба с фантазиями модели.
Третье — возможность работать с файлами.
Я выгружал конфигурацию в файлы, загружал ZIP в чат, и ИИ мог анализировать реальные метаданные. Это сильно удобнее, чем каждый раз вручную описывать структуру базы.
Четвёртое — ИИ хорошо работает как напарник по отладке.
Когда я присылал ошибку 1С или текст URL, он объяснял вероятную причину и предлагал конкретное исправление.
Что не понравилось и где нужно быть осторожным
ИИ не заменяет разработчика полностью.
Он может написать рабочий код, но разработчик всё равно должен понимать:
- куда этот код вставлять;
- как его запускать;
- как проверять результат;
- где логика может быть опасной;
- какие данные реально записались;
- где нужна оптимизация.
Иногда ИИ предлагает лишние конструкции. Например, Попытка…Исключение там, где лучше заранее проверить условие. Иногда он может сделать логически рабочий, но неидеальный архитектурно вариант.
Поэтому роль разработчика меняется: он меньше печатает руками, но больше формулирует задачу, проверяет результат, задаёт ограничения и принимает архитектурные решения.
Важный вывод
Самый ценный навык при работе с ИИ — это не умение «попросить написать код». Самый ценный навык — уметь вести разработку итерационно:
- дать контекст;
- показать структуру базы;
- сформулировать ограничение;
- проверить результат;
- вернуть ошибку;
- уточнить требование;
- не принимать код вслепую.
В моём случае ИИ стал не заменой разработчика, а очень сильным помощником. Он взял на себя большую часть рутинного кодирования и объяснения незнакомой предметной области. А за мной остались постановка задачи, проверка, отладка, здравый смысл и принятие решений.
Итог
Этот эксперимент показал мне, что ИИ уже можно использовать не только для написания отдельных функций, но и для разработки полноценного MVP.
Особенно если у разработчика есть базовый опыт платформы 1С, но не хватает знаний в новой предметной области. В такой ситуации ИИ помогает быстро пройти путь от «я примерно понимаю, что хочу» до «у меня есть рабочий прототип».
Да, это не магия. Да, код нужно проверять. Да, архитектуру нужно обсуждать. Но если относиться к ИИ как к напарнику, а не как к волшебной кнопке, результат может быть очень практичным.
В моём случае итогом стала MVP-конфигурация для работы с API Мосбиржи, загрузкой акций, облигаций, текущих цен и базовых значений. И большая часть кода действительно была написана ChatGPT.
А я, похоже, впервые почувствовал, что ИИ можно не просто изучать, а реально ставить на службу в разработке 1С.
Вступайте в нашу телеграмм-группу Инфостарт