Расширение УТ 11 за 19 минут: бесплатные скиллы и память проекта (Часть 2)
В конце прошлой статьи я предложил записать продолжение: сколько та же задача займёт, если дать агенту навыки и память. Записал.
Напомню исходную точку. В прошлом эксперименте Codex по одному заданию делал расширение УТ 11 с панелью остатков в форме списка номенклатуры. Условия были намеренно стерильными: никакого специализированного MCP, никаких навыков для 1С, никакой памяти проекта - только выгрузка конфигурации, штатная платформа и мои универсальные скрипты. Работа до перехода к проверке заняла 37 минут, весь сеанс - около 57.
Тогда я написал, что 37 минут - это не предел скорости подхода, а результат запуска с намеренно ограниченной подготовкой агента. В комментариях мне на это ответили ровно то, что и следовало ответить:
Можно же не в вакууме. Используйте скиллы. Интересно посмотреть, насколько быстро справится модель, если просто взять бесплатные скиллы из интернета, которые может скачать каждый.
Возражение справедливое. Я и сам в прошлой статье показывал пальцем на готовый бесплатный набор и говорил, что он закрыл бы именно ту рутину, на которой у меня уходило время. Поэтому в новом видео три прогона одной и той же задачи.
Дальше - что именно менялось, что осталось прежним и какие у этих цифр оговорки. Оговорок будет много: чистым сравнением одной настройки это не является, и я объясню почему.
Задача не изменилась
Задача та же самая, из спора в комментариях, и формулировал её не я:
Расширение создаётся само, в него заимствуется форма списка номенклатуры, на форме размещается динамический список с произвольным запросом по остаткам, реквизиты формы и колонки создаются автоматически, всё открывается у пользователя и работает.
Демобаза «Управления торговлей» 11.5.24.57, расширение ОстаткиНоменклатуры, панель остатков по текущей позиции, флажок «Показывать остатки», источник данных - именно реквизит формы типа ДинамическийСписок с произвольным запросом. Результат я, как и в прошлый раз, проверял руками: и в конфигураторе, и в пользовательском режиме.
Для нового видео я поднял отдельную демобазу без расширений (в записи она называется SkillRun) и пустую папку проекта под каждый прогон.
Что такое эти бесплатные скиллы
Скилл - это папка с инструкцией и вспомогательными скриптами, которую агент подхватывает сам, когда задача попадает под описание. Никакого закрытого сервера, никакой подписки: текстовые файлы, которые можно прочитать и поправить.
Я взял известный открытый набор cc-1c-skills Николая Широкова - тот самый, на который ссылался в конце прошлой статьи. Лично автора я не знаю, но набор давно на слуху и сделан хорошо. Использовал я свой форк, где дописан один инструмент, на суть эксперимента это не влияет.
Внутри набора есть ровно то, на чём в прошлом прогоне терялось время: cfe-init создаёт XML-каркас расширения, cfe-borrow заимствует объекты и формы и регистрирует их в расширении. В прошлый раз агент делал это сам: создавал расширение и первое заимствование через графический конфигуратор, потому что штатного пакетного способа для этих операций нет.
Кроме скиллов в папке лежал файл .v8-project.json на пару строк: путь к базе и путь к выгрузке конфигурации в XML. Больше там ничего нет, я показываю его в кадре целиком.
Промпт стал не длиннее, а короче
Это важный момент, потому что напрашивается обратное подозрение: мол, со скиллами задание стало толще. Наоборот. В папке проекта лежал один файл задания, и по сути в нём было написано вот что:
- создать с нуля расширение ОстаткиНоменклатуры для указанной базы и платформы
- сделать панель остатков на динамическом списке с произвольным запросом
- база чистая, пользователь - администратор без пароля
- всё оставить в этой папке
- не копировать готовые CFE или исходники решений этой задачи откуда бы то ни было.
Всё. Ни регистра, ни имён обработчиков, ни порядка работы, ни критериев приёмки, ни описания окружения - в прошлый раз всё это в задании было. Теперь эти знания лежат в скиллах, а во втором прогоне - ещё и в памяти проекта.
Запрет на копирование готовых решений я после прошлого видео пишу уже рефлекторно. Напомню, чем он вызван: в первом дубле прошлого эксперимента агент нашёл на диске расширение, оставшееся от репетиции, и воспользовался им. Тогда мне пришлось переносить старые материалы на съёмный диск и переснимать прогон. Сейчас чистка была мягче: запрет в промпте плюс таймлапс, по которому видно, чем агент занимался. Если найдёте в записи момент, где он что-то откуда-то скопировал, пишите, это будет честная находка.
Прогон 1: только скиллы, низкий уровень рассуждений
Первый прогон я сознательно сделал в самых экономных условиях: Codex, модель GPT5.6 Sol (не топовая, топовая сейчас GPT6 Astra) и уровень рассуждений low - минимальный. В прошлом эксперименте был medium.
Первый запуск в 20:12 я потерял на бытовой мелочи: не включил полный доступ. Агент упёрся в вопрос про права на запись в папку, остановился и стал ждать, а я в это время спокойно занимался своими делами. Классическая ошибка автономного прогона: уходишь на час, возвращаешься к диалогу, который замер на первом же подтверждении.
Перезапустил в 22:46. Минут через семь агент уже пошёл проверять сделанное, но с первого раза не получилось: вылезла ошибка, и он занялся её исправлением. Ещё около минуты потерял я сам - забыл закрыть базу, агент закрыл её за меня.
Итог: 25 минут до «готово» на экране и 28 минут вместе с проверкой результата.
Отдельное наблюдение, которое к ИИ отношения не имеет. Самой долгой операцией в этом прогоне были не размышления модели, а запуск 1С и открытие демобазы: без пользователей, без нагрузки, только с демоданными. Агент даже отметил в своих сообщениях, что забеспокоился, почему база открывается так долго. Я с ним согласен: в наш век это неприемлемо долго. (к примеру в onebase всё моментально)
Прогон 2: скиллы плюс память проекта
Дальше мне стало интересно другое. Первый прогон - это человек, который скачал чужие скиллы и сразу запустил задачу. А как выглядит та же работа у практикующего разработчика, который этими скиллами пользуется постоянно и понемногу их правит?
Поэтому после первого прогона я спросил у Codex, что можно улучшить, чтобы ускорить и упростить процесс. Он доработал скиллы и правила. Это и есть обычный режим работы с агентом: ты не пишешь инструкции заранее на все случаи жизни, а накапливаешь их по ходу дела - сам или руками того же агента.
Что именно агент допилил себе
Здесь важно правильно понимать слово «доработал». Модель не переобучалась и не меняла свои веса. Агент отредактировал лежащие на диске инструкции и скрипты - то есть улучшил собственный рабочий инструмент так же, как разработчик улучшает библиотеку, тестовый стенд или набор команд. Получилось семь обычных Git-коммитов, которые можно прочитать, проверить и при необходимости откатить.
Что изменилось в форке после первого прогона
Работа с формой. form-edit научился полностью описывать реквизит формы типа ДинамическийСписок: запрос, поля, ключевые поля и режим чтения. До этого агенту приходилось часть XML дописывать вручную.
Проверка динамического списка. В form-validate и cfe-validate появились проверки ошибок, найденных именно во время эксперимента: задан ли устойчивый ключ строки, установлены ли параметры запроса до показа таблицы, нет ли серверного вызова при выключенном флажке, не используется ли у динамического списка API обычной формы. Это не «готовое решение задачи», а автоматизированная проверка типичных дефектов.
Безопасная загрузка в базу. db-load-xml теперь перед загрузкой находит процессы именно целевой файловой базы по точному пути. Он может попросить обычный клиент закрыться штатно, но не завершает похожую базу, конфигуратор или неизвестный процесс. Это появилось после ситуации, когда база была занята клиентом.
Версия платформы и служебные утилиты. db-cfe-admin стал искать ibcmd той же версии, что и платформа, проверять совпадение версий и ограниченно повторять операцию при кратковременной блокировке базы. db-run получил явный выбор толстого или тонкого клиента, ожидание готового окна и защиту от запуска второго экземпляра.
Проверка данных. В правила db-query добавили простой, но важный принцип: пустая таблица на форме ещё не означает, что данных в базе нет. Сначала нужно независимым read-only запросом найти номенклатуру с остатком, а уже потом проверять её в интерфейсе.
Новый runtime-инструмент. Появился скилл 1c-client-test для воспроизводимых сценариев в обычном толстом и тонком клиенте. Он запускает клиент или подключается к уже открытому процессу, находит элементы через Windows UI Automation, проверяет текст и состояние переключателей, делает снимки и сохраняет диагностику. После неудачи клиент можно не запускать заново: сценарий подключается к тому же PID и продолжает с нужного шага.
Надёжность самого тестера. Последующие коммиты ограничили поиск элементов окнами нужного процесса, добавили предварительную проверку JSON-сценария и регулярных выражений, запрет выхода путей артефактов за рабочий каталог, ожидание исчезновения диалогов и сохранение клиента после сбоя для повторной попытки. Отдельно поправили совместимость Python- и PowerShell-реализаций на Windows.
То есть агент не «запомнил ответ». Он превратил причины потерь времени первого прогона в повторно используемые команды и проверки. В следующей задаче эти улучшения работают уже как часть среды, независимо от названия расширения, регистра и конкретной формы.
Второй элемент это память проекта. В Codex это файл AGENTS.md, в Claude Code -CLAUDE.md. Ничего мистического: текстовый файл рядом с проектом, который агент читает перед работой.
Сразу закрою вопрос, который обязательно возникнет: в AGENTS.md не написано, как решать эту конкретную задачу. Там записано, как вообще работать с теми или иными объектами системы: общие платформенные знания, проверенные приёмы, ограничения. Ни слова про регистр остатков, запрос или обработчик формы номенклатуры.
В промпте изменилась ровно одна строка: следуй AGENTS.md, используй скиллы, зафиксируй в результате время. Просьба про время оказалась полезной: агент сам разделил время разработки и общее время сеанса, и мне не пришлось потом пересматривать таймлапс с секундомером, как в прошлый раз.
Запуск в 21:36, модель и уровень рассуждений те же: GPT5.6 Sol, low. Права на этот раз проверил заранее.
Результат: 19 минут по моим часам, 18 минут по отчёту агента, из них разработка - 4 минуты 35 секунд. «Разработка» здесь означает момент, после которого код расширения больше не менялся, всё остальное время ушло на сборку, загрузку и проверки. Это же видно и по файлам: расширение в каталоге датировано 21:54, а на часах в кадре 22:02.
Почему агент не стал делать скриншоты
Во втором прогоне визуальной приёмки не было: 1С в пользовательском режиме агент не открыл и скриншотов не сделал. Это не сбой, это сработало правило из памяти проекта: если что-то не получается сразу, не надо биться до талого - зафиксируй и остановись.
Мне такое поведение нравится больше, чем упорство. Агент почти наверняка дожал бы графический интерфейс - вопрос только в том, за полчаса или за час. В реальной работе я это время лучше потрачу на проверку сам. Тем более что в условии задачи никаких скриншотов не было: там была работающая панель, а не альбом доказательств. В прошлом эксперименте я, наоборот, перестарался с требованием доказательств - агент наснимал около двадцати скриншотов.
Это, кстати, ответ на частый вопрос «а что, агент всё умеет?». Умеет, но не всё стоит своих минут. Рамки задаёте вы.
Что получилось и как я это проверял
Сначала конфигуратор. В расширении - заимствованная форма списка справочника «Номенклатура», на ней реквизит с типом ДинамическийСписок, у него включён произвольный запрос, а в настройке списка - запрос к регистру накопления «Товары на складах». То есть выполнено именно то условие, вокруг которого был спор, а не похожая по виду таблица значений.
Мелочь, которая мне нравится: реквизит в этом прогоне называется по-своему - ОстНом_Остатки. В каждом прогоне имена получаются разными. Это косвенный, но приятный признак того, что решение пишется заново, а не достаётся из кармана.
Потом пользовательский режим.
Цифры по йогурту я уже помню наизусть: 10 и 20 по двум сериям, те же самые, что сверял со стандартной ведомостью в прошлом видео. Кстати, в кадре видно, как несколько строк выглядят дублями - это не дубли, а разные серии одной номенклатуры.
Почему это не чистый замер одной настройки
Соблазн большой: 37 минут разработки против 4 минут 35 секунд - и вот вам эффект скиллов и памяти в цифрах. Так говорить нельзя, и вот честный список отличий между прошлым экспериментом и вторым прогоном:
- промпт стал заметно короче: ушли окружение, порядок работы и критерии приёмки
- уровень рассуждений снизился с medium до low, то есть модель работала в более экономном режиме
- скиллы закрывают создание каркаса расширения и заимствование формы - именно те операции, где в прошлый раз тратились попытки
- в прошлом прогоне были обязательными проверка нескольких позиций, независимая сверка остатков и перезапуск сеанса, а также акт приёмки и техническое задание, во втором прогоне визуальной приёмки не было вовсе
- другая база, другая папка, другое время суток и, соответственно, другая скорость открытия демобазы
- а она тут отъедает минуты сама по себе.
Поэтому правильная формулировка такая: это сравнение не двух настроек, а двух практик. «Модель в вакууме, всё описываю в задании» против «модель с бесплатными скиллами и накопленной памятью проекта». Во второй практике та же задача закрывается за 19 минут вместо часа, а собственно написание кода - за пять минут вместо сорока.
И ещё одно: оба раза это не рекорд. Я не выжимал секунды, не подбирал модель под задачу и вообще не большой специалист по написанию расширений.
А сколько это заняло у платного инструмента
Раз уж вся история началась со спора, скажу и про исходный ролик оппонента. По нему время восстановить нельзя: запись с монтажными склейками, таймера на экране нет, таймлапса нет. По моей оценке, там не меньше двадцати минут.
Я не утверждаю, что платный инструмент хуже или медленнее -у меня нет данных, чтобы это утверждать. Я утверждаю только то, что обещал показать: та же задача решается бесплатными средствами, и это видно от запуска до результата, с таймлапсом и часами в кадре.
Прогон 3: а если модель бесплатная?
Дальше самое интересное. Если знание «как это делается в 1С» вынесено в скиллы и память проекта, то, может быть, и модель нужна попроще? Проверяем.
Взял GLM 5.3 Flash: сейчас её можно использовать бесплатно по ночам (было указано, что до 20 сентября, но я и сейчас когда пишу эту статью 25.09.26 всё ещё пользуюсь ей бесплатно), плюс к ней раздают триста миллионов токенов - про это у меня есть отдельное видео. Запускал в Z Code, к нему подключены те же самые скиллы. И главное: у этой модели открытые веса, её можно поставить локально, если есть подходящее железо.
Честно скажу сразу: это уже второй заход. Первый я снимал, но не дождался и лёг спать. Утром выяснилось, что расширение сделано - за три часа. Причина была не в модели: скиллы были подключены неправильно, и она очень долго исследовала конфигурацию сама.
Ко второму заходу я поправил подключение скиллов и дополнил AGENTS.md общими платформенными знаниями. И попросил фиксировать время отдельно: сколько ушло на разработку, а сколько на всё остальное.
Запустил в 3:45 ночи, включил таймлапс и пошёл спать. Результат в отчёте: время разработки - 51 минута 08 секунд, общее время - 3 часа 12 минут 14 секунд по монотонным меткам, и там же честная приписка: общее время включает длительную диагностику пустого списка в демобазе.
Расширение при этом работает. Я проверил так же, как и предыдущее: панель остатков в списке номенклатуры, флажок, тот же йогурт с 10 и 20, переход по позициям с обновлением панели. В конфигураторе - снова динамический список с произвольным запросом к регистру накопления «Товары на складах». Всё как заказывали.
Где бесплатная модель слабее
Разница между 51 минутой и тремя часами и есть главный вывод третьего прогона. Код бесплатная модель пишет: медленнее топовой в несколько раз, но 51 минута для такой задачи - вполне приемлемо, особенно если она работает ночью, пока вы спите.
А вот диагностика и приёмка - слабое место. Два с лишним часа ушло на разбирательство с пустым списком, и это не единичный случай: в первом заходе история была той же. Практический вывод простой: с дешёвой моделью проверку лучше не оставлять ей самой. Проверяйте сами, другой моделью или скриптами - то есть не визуальной приёмкой, а чем-то воспроизводимым.
Ради справедливости: я не назову это приговором. Модель бесплатная, её можно поставить локально, и в задаче, где результат проверяется отдельно, такой расклад вполне рабочий.
Что я из этого вынес
Первое. Бесплатные скиллы действительно дают ускорение - то самое, за которое обычно предлагают заплатить. Скачиваются за минуту, читаются глазами, правятся под себя.
Второе. Память проекта не менее важна, чем скиллы. Один файл с правилами превратил 28 минут в 19, а написание кода - в пять минут. И заполняет этот файл в основном сам агент, если его об этом попросить.
Третье. Когда знания вынесены наружу, требования к модели падают. Нетоповая модель на минимальном уровне рассуждений справляется за минуты, а бесплатная - за час, и её ещё можно поставить локально.
Четвёртое. Узкое место смещается. Раньше спорили, сможет ли модель вообще написать расширение. Теперь вопрос в другом: сколько времени и денег стоит проверка результата - и не там ли теперь ваш главный расход.
Ну и мой основной тезис не изменился. Я не считаю покупку специализированного платного инструмента обязательной точкой входа: сначала пробую решить задачу с агентом и доступными средствами, а если удобного инструмента нет - поручаю агенту сделать свой. В прошлый раз я делал это скриптами с нуля, в этот - чужими бесплатными скиллами. Оба пути рабочие.
Если попробуете на своей задаче - напишите в комментариях, что получилось и на какой модели. И если интересно посмотреть, как те же скиллы ведут себя на задаче посложнее панели остатков, скажите: материал для следующего эксперимента у меня есть.
Если видео здесь не открывается, вот ссылка на YouTube.
Спасибо за внимание!
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
