Каталог скиллов для генеративных моделей
У каждой генеративной модели есть свой характер. Одна лучше понимает длинные описания, другая ждёт короткие теги, третья отлично редактирует изображение по референсу, но плохо переносит лишние отрицания. Даже близкие по назначению модели могут требовать разных настроек, разной структуры промпта и разного подхода к итерациям.
Поэтому я начал собирать отдельный каталог model skills — коротких практических профилей для конкретных моделей и их вариантов.
Идея не в том, чтобы сделать ещё один список моделей. Список сам по себе мало помогает в работе. Важнее быстро понять, как именно обращаться с выбранной моделью, где она сильна, какие ошибки у неё типичны и какую форму промпта она лучше всего воспринимает.
Что такое model skill
Model skill — это сжатая рабочая инструкция для модели.
В ней собраны не общие советы вроде «пишите подробнее», а конкретные правила: какой режим генерации подходит, как строить промпт, где ставить важные детали, нужен ли negative prompt, какие настройки лучше держать рядом с моделью, каких формулировок стоит избегать.
Такой скилл можно использовать как быстрый справочник перед генерацией или как контекст для агента, который помогает писать промпты. Вместо того чтобы каждый раз заново вспоминать особенности модели, я открываю профиль и сразу вижу рабочую форму.
Зачем нужен каталог
Когда моделей немного, всё можно держать в голове. Но в реальном пайплайне быстро появляются разные семейства: image, video, editing, reference-based generation, локальные OSS-модели, hosted API, experimental checkpoints. У каждой свои ограничения и свои сильные стороны.
Каталог помогает не смешивать эти знания в одну большую кучу.
Для каждой модели видно:
- для каких задач она подходит;
- какие режимы поддерживает: T2I, I2I, editing, video и другие;
- насколько профиль готов к практическому использованию;
- какие настройки и ограничения важны;
- какой текст скилла можно быстро скопировать в рабочий контекст.
Главная цель — не красиво описать модель, а сократить путь от выбора инструмента до корректного промпта.
Как формируются скиллы
Скилл не пишется «по ощущению» за один проход. Обычно он собирается из нескольких слоёв.
Сначала я смотрю первичные источники: официальные страницы модели, model cards, документацию, GitHub-репозитории, technical reports. Они помогают отделить реальные свойства модели от слухов и случайных пользовательских находок.
Затем добавляются практические материалы: примеры workflow, заметки по ComfyUI, обсуждения, сравнения, локальные тесты. Эти данные полезны, но их нельзя механически превращать в правила. Часто они завязаны на конкретный wrapper, sampler, LoRA, версию ноды или настройки runtime.
После этого информация сортируется, отбирается то, что подтверждено, часть вопросов проверяется локально. Вся эта информация сжимается в компактный гайд для LLM: что, как и по каким правилам нужно написать для конкретной генеративной модели.
Так получается не исследовательский архив, а практическая инструкция, которую можно использовать в работе.
Зачем эта страница создана?
Первоначально я начал составлять себе скиллы для работы локально на моем компьютере. При усложнении пайплайна и расширении базы захотелось как-то интересно это оформить. Пришла мысль, что подобные ресерчи
- могут быть полезны и новичкам
- хорошо смотрятся как часть портфолио
- полезный способ посмотреть как реализуются автоматизации на GitHub-проектах.
Что дальше
Каталог будет постепенно расширяться по мере того, как я
- добавляю новые модели
- уточняю пайплайн написания скилла
- проверяю накопившиеся ToDo списки проверок гипотез
Часть скиллов уже близка к рабочему состоянию, часть остаётся черновой, потому что требует дополнительных проверок.
Пример использования
Подключаемый скилл не дает модели уйти в какие-то сложные размышления и оставляет необходимое количество слов и нужную структуру для правильной генерации изображений.
Например, это важно при итеративной работе, когда модель пытается подобрать лучший вариант промптинга сама. Разумеется, это не отменяет работу человека как художника или как главного оператора задачи, потому что видение человека заменить нельзя.
Простой пример - попытка "заказать" у модели промпт по тематике "Фотографичное изображение русской деревенской бабушки с пирожками. Советская стилистика. Ностальгия. Как бабушка Тоня."
Схема работы модели получилась следующей:
Легенда схемы: числа в карточках идут в порядке Age / Russianness / Pies / Photorealism / Nostalgia / Naturalness / LivedIn. Это оценки VLM (Vision Language Model) по соответствующим критериям. Зеленая линия — победная цепочка, оранжевый пунктир — ключевые изменения стратегии промпта.
Итеративность подхода.
Первая попытка: простая LLM-обработка.
Я попробовал искать данные по модели, скармливать их LLM с правилами оформления скилла и надеялся получить готовую инструкцию. Ошибка была в том, что я не определил критерии отбора знаний — LLM просто сжимала весь найденный контекст в один текст. Результат: скилл напоминал дамп поисковой выдачи с кучей ссылок, TODO-пунктов и неотфильтрованных обсуждений. На практике такой скилл был бесполезен — в нём не было сфокусированных правил для генерации.Работа над критериями, но узкая выборка.
Я переработал подход: задал чёткие правила — что считать практически значимым знанием, как отделять подтверждённые фичи модели от слухов, как фильтровать привязку к конкретному runtime/софту. Результат стал намного ближе к тому, что я хотел. Но новая проблема: данные собирались вручную и точечно. Охвата по моделям и сценариям не хватало, база росла медленно, многие скиллы оставались в черновиках из-за нехватки источников.Deep research архитектуры.
Чтобы найти правильный способ масштабировать процесс, я провёл глубокий исследовательский опрос девяти разных LLM:claude,Gemini.3.5_flash,kimi,minimax,mistral,perplexity,z.ai,Mercury.5.5,qwen3.7
Каждой дал один и тот же набор вводных — описание текущего пайплайна, проблем и целей — и сравнил их рекомендации по архитектуре автономной фабрики скиллов.
Ключевой вывод: ручной/агентский конвейер (собрал источники → прочитал → написал скилл) не масштабируется. Нужна детерминированная кодовая основа, где каждый шаг формализован и воспроизводим.
Так появилась следующая итерация — Python-пайплайн для автоматической дистилляции скиллов из сырых источников. Перевод процессов
source-curator → distiller → creator → reviewerв код: ingestion источников, экстракция атомарных утверждений, дедупликация и поиск противоречий, оценка доверия (trust scoring), генерация черновика скилла.
Info
Более подробное описание итоговой схемы я сделаю в другом посте чуть позже.