Сверхпродуктивность с искусственым интеллектом: От первого промпта до собственной системы агентов

4.4.3 Библиотека промптов: как собирать и систематизировать

Библиотека промптов — это не архив на полке, это живой рабочий инструмент. Ключевой принцип: промпт в библиотеке должен содержать не только текст, но и метаданные — когда создан, для какой задачи, какие результаты дал, какие итерации улучшения прошёл.

Минимальная структура записи в библиотеке: название задачи, рекомендованная модель (GigaChat Professional, YandexGPT, другая — задача по умолчанию для того, с чем конкретная модель справляется лучше), текст промпта с явными плейсхолдерами для переменных частей (например, [ВАШ ОТДЕЛ], [ДЕДЛАЙН]), ожидаемый формат вывода, известные ограничения («не работает для договоров с иностранными сторонами»), дата последнего обновления.

Для команды: библиотека промптов эффективнее работает в общем пространстве (Notion, Confluence, папка в корпоративном облаке), где каждый может добавить новый шаблон и отметить, что старый устарел. Промпты, которые никто не использует три месяца подряд, — кандидаты на удаление или пересмотр.

Практикум 4.А: Сборка личного промпт-плейбука — 20+ шаблонов под свою профессию

Задача: создать структурированную личную библиотеку промптов для регулярных задач своей профессии.

Шаг 1 — Перечислите 10–15 задач из вашей работы, которые: повторяются не реже раза в месяц, содержат значительную текстовую или аналитическую составляющую, имеют более-менее предсказуемый формат вывода.

Шаг 2 — Для каждой задачи создайте запись в формате:

Название: [краткое описание задачи]

Промпт: [полный текст промпта с плейсхолдерами для переменных частей]

Модель: [рекомендованная модель]

Ожидаемый вывод: [описание формата]

Ограничения: [что промпт не покрывает]

Шаг 3 — Воспользуйтесь мета-промптингом для задач, которые сложно сформулировать: опишите задачу модели, получите уточняющие вопросы, ответьте на них, получите черновой промпт.

Шаг 4 — Протестируйте каждый шаблон минимум на двух реальных задачах. Зафиксируйте, что работает и что требует доработки.

Шаг 5 — Попросите модель проверить и улучшить три промпта, результатами которых вы менее всего довольны: «Вот мой промпт: [ПРОМПТ]. Его слабое место: [КРИТИКА]. Предложи улучшение».

Ожидаемый результат: библиотека из 20+ промптов в удобном для вас формате (Notion, Google Docs, Word) с заполненными метаданными.

На что обратить внимание: наиболее ценные промпты — не универсальные («напиши деловое письмо»), а специализированные под ваш контекст («напиши письмо поставщику с запросом скидки в B2B-контексте промышленного производства»). Чем конкретнее плейсхолдеры, тем стабильнее результат.

4.5 Структурированный вывод и форматирование

Пока предыдущие параграфы касались преимущественно текстовых задач, этот параграф — о ситуациях, когда вывод модели нужно встроить в другой инструмент или обработать программно. Структурированный вывод (JSON, XML, CSV) превращает языковую модель из «инструмента для текста» в «компонент рабочего процесса».

4.5.1 Markdown внутри промпта: заголовки, таблицы, списки как инструкция

Использование Markdown в промпте — не только стилистическое решение. Заголовки помогают структурировать длинный промпт так, чтобы модель чётко разграничивала его части: «# Контекст», «## Задача», «## Формат вывода». Таблицы в промпте задают модели пример формата, который нужно воспроизвести. Списки в промпте сигнализируют модели о том, что ответ тоже должен иметь параллельную структуру.

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

4.5.2 Получение ответа в JSON и XML: зачем и как

JSON-вывод нужен тогда, когда результат модели будет обрабатываться другим инструментом: импортироваться в таблицу, передаваться в API, встраиваться в приложение. Без явной инструкции модель добавляет пояснения вокруг данных — «Вот JSON, который вы просили:» — что ломает парсинг. Инструкция должна быть явной: «Верни ответ только в формате JSON, без пояснений, без Markdown-обёртки. Структура: ...».

Проанализируй следующий отзыв клиента и верни результат ТОЛЬКО в формате JSON.

Без пояснений, без кода в тройных кавычках, только чистый JSON объект.

Структура:

{

"sentiment": "positive" | "negative" | "neutral",

"score": число от 1 до 10,

"main_topic": "строка — главная тема отзыва",

"actionable": true | false,

"suggested_action": "строка или null если actionable=false"

}

Отзыв: «Доставка была быстрой, но упаковка повреждена — товар помялся»

Такой промпт возвращает машиночитаемый JSON, который можно напрямую вставить в таблицу или передать в другую программу. Это превращает разовый анализ в масштабируемый процесс: тот же промпт обработает 200 отзывов с тем же качеством.

4.5.3 Шаблонный вывод для последующей обработки

Помимо JSON и XML, существуют промежуточные форматы — структурированный текст с разделителями, который не требует программирования для обработки, но при этом легко импортируется в Excel или Google Sheets. Например: вывод в формате «поле: значение», или CSV с чётко заданными заголовками, или таблица Markdown с предсказуемыми столбцами.

Практическое правило: если вы планируете обрабатывать вывод вручную — Markdown-таблица удобнее JSON. Если планируете передавать в другой инструмент — JSON или CSV. Если неизвестно — просите Markdown-таблицу с возможностью «позже попрошу то же самое в JSON».

4.5.4 Сравнение: когда структура помогает, когда мешает

Структурированный вывод — не улучшение по умолчанию. Для творческих задач (написание текста, генерация идей, редактура) принудительная структура JSON может ухудшить качество: модель начнёт подгонять нарратив под поля схемы вместо того, чтобы строить органичный текст. Структура помогает там, где задача имеет чёткие поля и критерии — анализ, классификация, извлечение данных. Она мешает там, где качество определяется плавностью и органичностью — написание, перефразирование, творческие задачи.

Практикум 4.В: Получить структурированный JSON-ответ и использовать его в таблице

Задача: создать промпт, возвращающий JSON, и встроить результат в рабочий процесс.

Шаг 1 — Выберите задачу с чёткими полями. Подходящие варианты: анализ отзывов / обращений клиентов, извлечение ключевых данных из описаний вакансий или резюме, классификация входящих заявок, извлечение структурированной информации из неструктурированного текста (например, из новостных заметок — организация, дата, тип события).

Шаг 2 — Спроектируйте JSON-схему: какие поля нужны, какие типы данных (строка, число, булево, перечисление). Нарисуйте схему на бумаге или в текстовом редакторе.

Шаг 3 — Напишите промпт с инструкцией на JSON-вывод. Обязательные элементы:

• «Верни ответ ТОЛЬКО в формате JSON»

• «Без пояснений, без кода в тройных кавычках»

• Явная схема с примером структуры

• Описание допустимых значений для полей-перечислений

Шаг 4 — Протестируйте на 3–5 объектах одного типа. Проверьте: корректно ли парсится JSON? Все ли поля заполняются предсказуемо?

Шаг 5 — Скопируйте полученный JSON в онлайн-инструмент конвертации JSON→CSV (их несколько бесплатных) и откройте в Excel или Google Sheets.

Ожидаемый результат: работающий JSON-промпт + 3–5 успешно обработанных объектов + таблица с результатами.

На что обратить внимание: если модель возвращает JSON с пояснениями вокруг — добавьте в промпт: «Если ты хочешь добавить пояснение — помести его в поле 'note' внутри JSON-объекта, не вне него». Это изящнее, чем запрет на пояснения, который модель иногда игнорирует.

4.6 Длинный контекст (1M+ токенов)

Одно из самых значимых изменений 2024–2025 годов — распространение моделей с контекстом от 128 000 до 1 000 000+ токенов. Это принципиально новый класс задач, который стал доступен без специального технического обеспечения. Понимание возможностей и ограничений длинного контекста — необходимая часть инструментального арсенала в 2026 году.

4.6.1 Что изменилось с приходом длинного контекста

До 2024 года работа с документом больше 50–80 страниц требовала либо специальных технических решений (RAG, разбивка на чанки, программирование), либо ручного выбора релевантных фрагментов. Теперь для многих задач достаточно просто загрузить документ целиком. 1 млн токенов — это примерно 750 000 слов, или книга объёмом 1 500 страниц, или несколько сотен типовых деловых документов одновременно.

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

4.6.2 Работа с целыми книгами, архивами, кодовыми базами как с одним промптом

Три наиболее ценных применения длинного контекста для нетехнического специалиста: поиск конкретной информации в большом массиве документов, кросс-документный анализ (поиск противоречий, трендов, паттернов), синтез материала из множества источников в один связный вывод.

Конкретный пример корпоративного применения: аналитик загружает 30 отчётов от региональных офисов за год и задаёт вопрос: «Какие проблемы встречаются в более чем трёх регионах? Оформи как таблицу: проблема — сколько регионов — первое упоминание по дате». Раньше это был многочасовой ручной анализ. Теперь — несколько минут на загрузку и обработку.

4.6.3 Стратегии навигации в длинном контексте

Длинный контекст требует более точной навигации, чем обычный диалог. Три рабочих приёма. Первый — «якорные вопросы»: прежде чем делать развёрнутый запрос, попросите модель сначала составить структуру или оглавление загруженного материала. Это помогает обоим — и вам ориентироваться в ответах, и модели — «настроиться» на структуру документа. Второй — прогрессивное уточнение: сначала задайте общий вопрос («Какие главные темы в этих документах?»), затем уточняйте по конкретным темам. Третий — явные ссылки: в запросе указывайте на конкретные части материала («В третьем разделе договора... в строке 47 таблицы...»), чтобы снизить вероятность того, что модель будет работать с другим фрагментом.

Для задач с несколькими документами полезен промпт «сначала читай, потом отвечай»: «Внимательно прочитай все загруженные документы целиком. Не отвечай на вопросы, пока я не скажу 'готов'. После того как закончишь — напиши 'Готов к вопросам'». Такой порядок снижает вероятность того, что модель ответит на первый вопрос, не полностью обработав весь материал.

4.6.4 Ограничения: где длинный контекст не помогает

Длинный контекст не устраняет ограничения точности. Эффект «потери в середине», описанный в Главе 1, сохраняется: информация из середины очень длинного документа удерживается хуже, чем из начала и конца. Для критически важного поиска конкретного факта в 500-страничном документе — верифицируйте результат прямым поиском по тексту.

Длинный контекст не заменяет RAG для задач с постоянно обновляющейся базой знаний. Если ваша база документов растёт каждую неделю, загружать её целиком каждый раз неэффективно — RAG (Глава 6) здесь предпочтительнее. Длинный контекст оптимален для разовых аналитических задач с конечным набором документов.

Важно: большой контекст — большие токены = большая цена

При работе через API каждый токен в контексте стоит денег. 1 млн токенов контекста может стоить существенно дороже, чем несколько сотен токенов. Для частых задач с большими документами — оцените, не выгоднее ли RAG-подход с меньшим контекстом. Для разовых аналитических задач — длинный контекст оправдан.

4.7 Специфика разных моделей

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

4.7.1 Различия в поведении GigaChat, YandexGPT, зарубежных моделей

GigaChat оптимизирован для русскоязычного корпоративного контекста и задач, типичных для российского делового оборота: деловая переписка, юридические формулировки, нормативная документация. Его сильные стороны — знание российского делового и правового контекста, хорошая работа с русскоязычными текстами, соответствие требованиям российского законодательства о персональных данных. В задачах с международным контекстом или на английском языке качество уступает специализированным зарубежным моделям.

YandexGPT интегрирован в экосистему Яндекса и хорошо работает с задачами, близкими к его обучающему контексту: поиск информации, структурирование текста, анализ. Алиса как интерфейс к нему оптимизирована под диалоговые сценарии и голосовое взаимодействие. В задачах глубокого профессионального анализа или сложного многошагового рассуждения флагманские зарубежные модели пока сохраняют преимущество, хотя разрыв сокращается.

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

4.7.2 Как адаптировать промпт под конкретную модель

Три аспекта, по которым промпты чаще всего требуют адаптации. Первый — длина и структура инструкции: GigaChat и YandexGPT хорошо справляются с чёткими структурированными инструкциями; флагманские зарубежные модели лучше следуют длинным сложным промптам с многоуровневыми инструкциями. Если переносите промпт из одной модели в другую — проверяйте, не стала ли инструкция избыточно сложной или, наоборот, слишком краткой.

Второй аспект — контент-политика: у каждой модели своя политика ограничений. Некоторые задачи (критический анализ, ролевое разыгрывание сценариев переговоров, анализ рисков) одна модель выполнит без вопросов, другая потребует переформулировки. Если модель отказывается от задачи, которая кажется вам рабочей, — попробуйте переформулировать контекст: уточнить профессиональную цель, добавить явную роль.

Третий аспект — особенности форматирования: некоторые модели возвращают ответы с большим количеством Markdown-форматирования по умолчанию, другие — в виде сплошного текста. Явная инструкция по формату из параграфа 3.2.2 решает это, но нужно помнить, что «умолчания» у разных моделей разные.

Типичные ошибки продвинутого промпт-инжиниринга

Ошибка 1: CoT там, где он не нужен

В чём: пользователь добавляет CoT-инструкцию к каждому промпту как «магический улучшитель». Для простых задач (написать объявление, перевести абзац, ответить на фактический вопрос) CoT добавляет объём без качества и замедляет ответ.

Как правильно: CoT — инструмент для задач с многофакторным рассуждением. Для простых задач с однозначным ответом — стандартный чёткий промпт по КЗФО лучше.

Ошибка 2: Few-shot примеры из «чужой» области

В чём: пользователь берёт few-shot примеры из интернета или учебника, не адаптируя их под свой контекст. Модель обучается на чужом стиле, терминологии, форматах — и воспроизводит их вместо нужных.

Как правильно: few-shot примеры должны быть из вашей реальной практики — образцы ваших реальных текстов, классификаций, анализов. Это единственный способ передать специфику вашего контекста через примеры.

Ошибка 3: JSON-промпт без теста на парсинг

В чём: пользователь пишет JSON-промпт, получает ответ, который выглядит как JSON, — и использует его без проверки корректности. Модели иногда возвращают «почти JSON» с ошибками (лишними запятыми, некорректными кавычками, добавленными комментариями), который ломается при парсинге.

Как правильно: проверяйте JSON-вывод через онлайн-валидатор (jsonlint.com или аналог) перед тем как встраивать в рабочий процесс. Для регулярного использования добавьте в промпт: «Убедись, что JSON валиден. Если нет — исправь перед ответом».

Ошибка 4: Длинный контекст как замена критического мышления

В чём: «Я загрузил все документы — теперь ИИ сам во всём разберётся». Даже с 1 миллионом токенов контекста модель не заменяет профессиональное суждение о том, что в этих документах важно, что противоречиво и что требует внимания.

Как правильно: используйте длинный контекст как инструмент навигации и первичного анализа. Ключевые выводы — проверяйте по первоисточнику, профессиональное суждение — остаётся за вами.

Ошибка 5: Один системный промпт на все задачи

В чём: пользователь создаёт один системный промпт «на всё» — описывает свою роль, компанию, стиль — и ожидает, что он улучшит любой запрос. Универсальный системный промпт часто мешает задачам, для которых нужен другой контекст или другой тон.

Как правильно: системные промпты создаются под конкретные типы задач. У хорошей библиотеки — несколько системных промптов: один для редактуры текстов, другой для аналитики, третий для коммуникации с клиентами. Переключаетесь между контекстами — переключаете системный промпт.

Кейс 2026: Аналитик инвестиционного фонда — от ручного скрининга к системе промптов

Игорь — старший аналитик в российском венчурном фонде ранних стадий. Ключевая задача: первичный скрининг стартапов — оценка питч-деков и кратких описаний для решения о встрече с основателями. До систематизации промптов: около 40–50 стартапов в месяц, первичный анализ каждого — 45–60 минут.

Игорь начал с простого: попросил языковую модель помочь ему сформулировать критерии оценки. Результатом стал список из 12 критериев с описанием того, что означает «сильно» и «слабо» по каждому. Затем создал системный промпт, превращавший модель в «скрининговый комитет»: не дающий финального вердикта, но структурированно оценивающий по каждому критерию.

Ты — аналитик венчурного фонда с фокусом на B2B SaaS и deep tech.

Твоя задача — первичный скрининг стартапа по питч-деку или описанию.

Для каждого стартапа:

1. Оцени по 12 критериям (ниже). Оценка: 1–5 + обоснование (2 предложения).

2. Выдели 2–3 главных сильных стороны.

3. Выдели 2–3 главных red flags.

4. Сформулируй 3 вопроса, которые аналитик должен задать на встрече.

5. Итог: recommend / pass / need_more_info.

Критерии: [список из 12 критериев с описанием]

Формат: структурированный текст с явными заголовками.

Тон: нейтральный аналитический, без энтузиазма.

Результаты через три месяца: время на первичный анализ одного стартапа сократилось с 45–60 минут до 15–20 минут (10 минут на загрузку и запрос, 5–10 минут на проверку и уточнение). Пропускная способность выросла: Игорь стал обрабатывать 80–100 стартапов в месяц, не увеличивая рабочее время. Качество не снизилось — по оценке партнёров фонда, структурированные аналитические записки стали более последовательными и полными.

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

Второй урок: промпт для анализа software-стартапа не работал для hardware и deeptech. Пришлось создать три отдельных варианта системного промпта — по типу стартапа. Универсальный шаблон оказался неэффективным там, где специфика отрасли критически важна для оценки.

Честное ограничение: ИИ-анализ — первый фильтр, не замена суждению. Два стартапа, которые модель оценила низко, но которые Игорь всё равно встретил «по интуиции» — показали более интересные результаты, чем предсказывал алгоритм. Суждение аналитика, накопленное за 7 лет работы с основателями, — не заменяется текстовым анализом питч-дека. Системный промпт заменил рутинный скрининг, но не инвестиционное суждение.

Ключевой вывод кейса

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

Контрольные вопросы к Главе 4

1. (Применение) Вам нужно выбрать, в каком городе открыть второй офис компании. Есть три кандидата: Москва, Санкт-Петербург, Екатеринбург. Напишите CoT-промпт для этого решения: определите, по каким шагам должна идти модель, прежде чем дать рекомендацию. Укажите, какой контекст о компании нужно добавить.

2. (Анализ) Few-shot промпт с тремя примерами даёт хорошие результаты для анализа положительных отзывов, но систематически ошибается при анализе негативных. Предложите две возможные причины этой проблемы и опишите, как скорректировать промпт для каждой причины.

3. (Применение) Напишите системный промпт для ассистента, который будет помогать вам с одним конкретным типом задач из вашей профессии. Системный промпт должен содержать все четыре блока (роль, контекст, стиль, ограничения). После написания: какой блок оказался наиболее сложным для формулировки и почему?

4. (Оценка) Игорь из кейса обнаружил, что модель систематически завышает оценки стартапам с хорошим нарративом. Почему это происходит с точки зрения механики работы языковой модели (вспомните Главу 1)? Какие ещё систематические смещения можно ожидать в подобной задаче скрининга?

5. (Синтез) У вас есть 200-страничный внутренний регламент компании. Предложите два принципиально разных подхода к работе с ним с помощью ИИ: один — через длинный контекст (параграф 4.6), другой — через систему промптов с частичной загрузкой. Для каждого подхода: назовите задачи, для которых он предпочтителен, и задачи, для которых он не подходит.

→ К Главе 5: Мультимодальный промптинг

Главы 3 и 4 охватывают работу с текстом. Глава 5 разбирает то, что стало нормой в 2025–2026 годах: работу с изображениями, аудио, документами и видео в едином промпте. Граница между «текстовым ИИ» и «остальными» практически стёрта.

Глава 5. Мультимодальный промтинг

Часть II. Язык взаимодействия: промпт-инжиниринг

Учебные результаты: построить мультимодальный промпт для документа, изображения и аудио; создать полный контент-кит из одного исходного материала.

5.1 Мультимодальность: что это значит для пользователя

5.1.1 Omni-модели: текст + изображение + аудио + видео в одном запросе

В 2022 году граница между «языковой моделью» и «моделью для изображений» была чёткой и непреодолимой. Одни системы понимали текст, другие — картинки, третьи — звук. Соединить их вместе требовало отдельной инженерии, нескольких API и специалиста, который умеет их связывать. К 2026 году эта граница практически стёрта — и это меняет не только инструменты, но и сам способ постановки задачи.

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

На практике это означает принципиально иной дизайн промпта. В одном запросе вы можете приложить скриншот интерфейса и попросить выявить UX-проблемы; загрузить аудиозапись переговоров и получить структурированный протокол с задачами и ответственными; вставить PDF-договор и задать конкретный вопрос по одному разделу; подать фотографию доски с задачами и получить таблицу для Jira или Notion. Это не последовательность отдельных шагов через разные сервисы — это один запрос, один ответ.

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