Ассистент руководителя получил задание «написать письмо клиенту с просьбой продлить договор». Открыл ChatGPT, набрал три строчки и отправил письмо клиенту. Через час клиент перезвонил: «Что значит „мы рады предложить вам продолжение сотрудничества на условиях, отличных от ранее обсуждённых”? Какие условия?» Ассистент перечитал письмо и обнаружил, что модель сама придумала три пункта, которых в исходных договорённостях не было.
Такие провалы — обычное дело: пользователь пишет промпт один раз и считает задачу выполненной. OpenAI в официальном Help Center прямо называет это базовой нормой: промпт-инжиниринг требует итеративного подхода, первая версия — гипотеза, а не ответ. Тот, кто пишет промпт один раз и считает, что задача сделана, в девяти случаях из десяти получает мусор — и потом удивляется, почему коллега «на том же ChatGPT» выдаёт результат на порядок лучше.
Промпт — рабочая петля: написал → отправил → посмотрел, где плывёт → поправил → повторил. Версия промпта, прошедшая пять итераций, всегда лучше версии, написанной «по вдохновению» в воскресенье вечером. И порядок шагов в инструкции — рычаг итерации, а не длина промпта и не количество правил. Этому правилу мы ещё вернёмся, и оно красной нитью пройдёт через всю главу.
ПРОМПТ-ИНЖИНИРИНГ КАК НЕПРЕРЫВНЫЙ ИТЕРАТИВНЫЙ ПРОЦЕСС
Хороший промпт — это версия, прошедшая через итерации, а не текст, который с первого раза получился правильным сам по себе. Обе ведущие конторы в индустрии прямо об этом говорят: первая версия — гипотеза, а не ответ. OpenAI в Help Center рекомендует начать с первоначального промпта, посмотреть на ответ и уточнять формулировку, добавлять контекст или упрощать запрос по мере необходимости. Anthropic в официальном гайде идёт дальше: начинайте с минимального промпта на самой сильной модели, прогоните его на репрезентативном наборе задач, посмотрите, где сломалось, и только после этого добавляйте инструкции — опираясь на конкретные failure modes, то есть на реальные наблюдаемые случаи провала, а не на теоретические риски.
Разница между тем, кто это понимает, и тем, кто ждёт готового результата с первой попытки, измеряется часами вычитки.
Когда я собираю шаблон для типовой офисной задачи (резюме протокола, проверка рисков в договоре, подготовка письма клиенту), я закладываю пять-семь итераций как рабочую норму. Первая итерация — убедиться, что модель вообще поняла задачу. Вторая — задать формат ответа. Третья — добавить ограничения: что нельзя выдумывать, какие данные обязательны, какие границы. Четвёртая — закрыть самый частый провальный случай на вашей выборке. Пятая — проверить стабильность на новых вводах, которых не было в первых итерациях.
Иначе не выйти на результат, который можно отправить клиенту без второго круга правок.
НОРМА ИТЕРАЦИЙ: ЦИФРЫ ИЗ ПРАКТИКИ
Цифры по количеству итераций разные, и почти все авторы сходятся в диапазоне от 5 до 15 для не-инженерных задач. Исследовательская работа «From Tool to Teammate: LLM Coding Agents as Collaborative Systems» (arXiv, март 2026) зафиксировала, что для выхода на стабильное качество разметки требуется от 8 до 12 итераций на одну настройку шаблона. Методология PIV (Plan-Implement-Validate) от MindStudio формулирует жёстче: для чётко поставленной, ограниченной задачи типично одна-две итерации, три и больше обычно означают, что шаг планирования был неверным. В среднем нормальная рабочая настройка требует серии итераций, а одна-две — случай тривиальной задачи с готовым шаблоном. Практический отчёт Alibaba Cloud «From ReAct to Ralph Loop» (январь 2026) разбивает итерации по размеру задачи: маленькие задачи — 5–10 итераций, средние — 20–30, большие — больше. Для офисного работника это даёт конкретную разметку: на письмо клиенту 3–5 итераций, на проверку рисков в договоре 5–8, на построение нового шаблона для отдела 10–15. Эти цифры — не проклятие LLM (большой языковой модели). Это нормальный объём работы по отладке любой новой процедуры. Разница в том, что у LLM итерация занимает секунды, а у живого подрядчика — дни.
РАБОЧИЙ ЦИКЛ «НАПИСАЛ — ПРОВЕРИЛ — ПОПРАВИЛ»
Зная ожидаемый объём итераций, полезно понимать, как они устроены изнутри.
Anthropic в инженерном блоге «Effective context engineering for AI agents» (сентябрь 2025) разбирает цикл оптимизации промпта до уровня конкретных шагов. Шаг первый — сформулировать критерии успеха в измеримом виде: не «ответ должен быть хорошим», а «в 95 из 100 тестовых запросов модель возвращает JSON с заполненными полями a, b, c». Шаг второй — собрать минимальный репрезентативный набор тестов, лучше всего из реальных примеров, на которых раньше обжигались. Шаг третий — взять минимальный промпт и самую сильную модель, прогнать тестовый набор, зафиксировать, на каких именно примерах результат не сошёлся с критерием. Шаг четвёртый — менять по одной переменной за раз: либо формулировку роли, либо порядок шагов, либо формат вывода, — снова прогонять, фиксировать.
Шаг пятый — после стабилизации базового результата добавлять ограничители: правила на случай нехватки данных, примеры из обучающей выборки на corner-cases (редкие пограничные случаи, на которых модель обычно спотыкается), ограничение формата. Это инженерная дисциплина, и она применима к офисной задаче напрямую. Вместо «тестового набора» — папка из десяти прошлых писем клиентам, на которых вы обожглись. Вместо «JSON-валидации» — галочка в чек-листе рисков договора.
Цикл нужен не для того, чтобы «подбирать слова». Цикл нужен, чтобы превратить свой опыт в инструкцию, которая стабильно даёт нужный результат.
ЧАСТЫЙ ПРОВАЛ: ДОПИСЫВАТЬ ПРАВИЛА ВМЕСТО СМЕНЫ ПОРЯДКА
Стратегия «напишу подлиннее и добавлю побольше правил» — распространённый провал, особенно когда проблема на самом деле в порядке шагов. Здесь важно зафиксировать эмпирическое подтверждение из сторонних гайдов: добавление новой инструкции в середину системного промпта сдвигает акценты модели, и старые правила теряют силу.
Один мой клиент, юрист по корпоративным спорам, в какой-то момент собрал 14 правил в системный промпт своего AI-ассистента. Стало хуже, не лучше. Когда я попросил его убрать всё, кроме трёх ключевых правил, и переставить их в нужном порядке — «сначала определи тип документа, потом вытащи обязательные реквизиты, потом сформируй вывод» — точность по тестовой выборке из 20 договоров поднялась с 38% до 71%.
Итерация не про длину. Итерация про то, чтобы видеть, какая именно часть промпта не работает, и менять её, а не добавлять рядом новый блок. Это разница между плотником, который видит, что дверь скрипит из-за петли, и плотником, который начинает подкладывать под дверь тряпки.
ЭВОЛЮЦИЯ РЕКОМЕНДАЦИЙ ANTHROPIC И OPENAI ЗА ДВА ГОДА
Правила игры в промпт-инжиниринге заметно сдвинулись с 2024 по 2026 год: часть «классических» советов теперь работает хуже, часть новых стала обязательной. Я держу в голове пять ключевых сдвигов, и они видны в официальных гайдах обеих компаний.
– Цепочка рассуждений по запросу больше не нужна для reasoning-моделей. В 2022 году Wei и соавторы показали, что просьба «давайте думать по шагам» поднимает качество на арифметических задачах — в оригинале по Wei et al. 2022: «let’s think step by step». В 2026 году Anthropic Opus 4.7+, OpenAI o3 и GPT-5, Google Gemini 3 умеют «рассуждать» сами. Параметр reasoning_effort (у OpenAI) или effort (у Anthropic: low, medium, high, xhigh, max) или thinking_level (у Google) заменяет ручную просьбу. Просить модель «давай по шагам» — избыточный шум. Подробнее об этом мы поговорим в блоке «Рассуждение».
– Структурные теги вместо голого текста. Anthropic в Claude Prompting Best Practices рекомендует оборачивать примеры и инструкции в XML-подобные теги — формат разметки, похожий на HTML: открывающий тег, содержимое, закрывающий тег, — выделяя блоки «пример» и «инструкция». Google Gemini идёт тем же путём. Это не косметика: теги помогают модели отделять блоки и не «размывать» их друг в друга, особенно в длинных системных промптах.
– Длина промпта перестала быть проблемой. Старая школа говорила: «чем короче — тем лучше». В 2026 году это не так. Модели с контекстом 200K (Claude 4.x, GPT-5) и до 1M (Claude 4.8) спокойно держат большие системные промпты. Вопрос теперь не «укладывается ли в 4K токенов», а «не конкурируют ли инструкции в системном промпте друг с другом за внимание». Shopify, про которую я ещё скажу в этой главе, на масштабе 50+ инструментов упёрлась не в длину, а в то, что каждая новая правка ломает поведение в неожиданном месте.
– Примеры по-прежнему помогают, но меньше, чем раньше. Исследование Min и соавторов (EMNLP 2022) показало, что для reasoning-моделей few-shot (подача нескольких примеров «вход — вывод» прямо в промпте) даёт меньший прирост, чем для старых LLM. Но для стабилизации формата вывода few-shot остаётся лучшим приёмом. Об этом подробнее в разделе 4.
– Явные инструкции работают лучше подразумеваемых. В материалах OpenAI Academy рекомендация звучит прямо: пишите ясно и конкретно. Anthropic в Best Practices добавляет: вместо того чтобы говорить модели, чего не делать, скажите, что делать. Конкретное «напиши три абзаца по 3–5 строк, без вводных фраз вроде “в этой статье мы рассмотрим”» работает стабильнее, чем абстрактное «напиши кратко и по делу».
Эти сдвиги означают, что советы из гайдов 2023 года устарели. Если у вас в закладках лежит пост «30 лучших приёмов промпт-инжиниринга» с формулировками вроде «будь вежлив с моделью, распиши по шагам, приведи 5 примеров», откройте его заново — половина советов теперь работает в минус, а не в плюс. Этот провал с «30 лучшими приёмами» — частный случай того сдвига в рекомендациях 2024–2026 годов, который мы только что разобрали.
Хороший промпт — всегда версия, пережившая итерации, а не «рецепт из методички», написанный по вдохновению в воскресенье вечером. Первый рецепт борща всегда корявый: капусты много, свеклы мало, уксуса перебор, время варки неверное — и только версия, пережившая пять вкусов, два ингредиента и одну смену плиты, становится рабочей. С промптом та же история: сделал первый выстрел, посмотрел, куда упало, скорректировал, повторил. Правило — записывать, что именно не сошлось в прошлый раз, и менять одну вещь за раз.
У Anthropic Console есть кнопка «improve prompt», и она работает не как волшебная палочка: после нажатия вы получаете новую версию, которую всё равно надо проверить на своих примерах. Каждое нажатие — новая гипотеза, а не финальный ответ.
И ключевое: если за 10–12 итераций без улучшения вы продолжаете крутить формулировки, остановитесь и пересмотрите саму задачу. Скорее всего, она не для одного промпта.
СИСТЕМНЫЙ ПРОМПТ: БЛОКИ КОНСТРУКЦИИ И ПРИНЦИПЫ СБОРКИ
Системный промпт — это инструкция, которая загружается в модель один раз и применяется ко всем запросам в ходе сессии или продукта. Anthropic, OpenAI и Google рекомендуют в 2026 году структурировать системный промпт по блокам: роль, тон, фон, инструкции, примеры, история, задача, рассуждение, формат, предзаполнение. Каждый блок решает конкретный класс проблем. Пропуск нужного блока ломает стабильность результата. Но заполнять все десять подряд без разбора тоже не нужно: для большинства офисных задач хватает первых пяти.
БЛОК «КОНТЕКСТ»: РОЛЬ МОДЕЛИ
Роль задаёт модели «кто она» в этой сессии. Формулировка «Ты опытный юрист по корпоративным спорам с 10-летним стажем, консультируешь сотрудников малого бизнеса» работает лучше, чем «Ты помощник по юридическим вопросам». Разница в детализации: первая версия даёт модели конкретный профиль экспертизы и конкретную аудиторию, вторая оставляет размытое поле. Anthropic относит роль к «правильной высоте» — зоне между двумя крайностями: слишком жёстким «if-else» описанием поведения, которое ломается на нестандартном входе, и слишком общим «будь полезным ассистентом», которое не даёт модели конкретных сигналов.
Один и тот же запрос «перепиши этот пункт договора» с ролью «старший юрист по корпоративным спорам, аудитория — судья арбитражного суда» даёт на порядок другой ответ, чем с ролью «опытный копирайтер». В нашей практике с офисными задачами смена роли с «юрист» на «юрист-практик с 10-летним стажем, аудитория — генеральный директор» изменяла результат сильнее, чем удвоение длины инструкций. Роль — самый дешёвый рычаг в системном промпте.
БЛОК «ТОН»: ГОЛОС ОТВЕТА
Тон — это «как звучать». Без явного указания модель выдаёт нейтрально-канцелярский тон по умолчанию, который подходит для одной компании и абсолютно чужд другой. Я на консультациях даю клиентам три-пять прилагательных для описания голоса: «уверенный, без пафоса, конкретный, без хеджирования». Это работает лучше, чем абстрактное «дружелюбный и профессиональный». Отдельно фиксируется правило на случай нехватки данных: «Если данных не хватает — скажи, не придумывай». Маленькое добавление закрывает большой класс выдумок.
БЛОК «ФОН»: ОБСТОЯТЕЛЬСТВА ЗАДАЧИ
Фон — это стабильная информация о данных, которая кешируется и не меняется от запроса к запросу. Для одиночного запроса фон минимален. Для серии запросов в ходе проекта он разрастается: структура входящих документов, реквизиты контрагента, согласованный ранее стиль. Типовая ошибка — класть сюда переменные данные, которые меняются от запроса к запросу. Anthropic в Effective context engineering рекомендует давать только релевантный контекст, а не всю доступную информацию: «меньше — значит лучше» работает в 2026 году так же, как в 2024.
Фон — это то, что не меняется. Всё, что меняется, — в задачу.
БЛОК «ИНСТРУКЦИИ»: ПОРЯДОК ШАГОВ
Блок инструкций описывает порядок действий, который модель должна выполнить. Его сила — в последовательности, а не в количестве. Кажется контринтуитивным: чем больше правил, тем стабильнее результат. На практике 12 правил в случайном порядке дают худший результат, чем 4 правила, выстроенные в логическую цепочку «проверь → действуй → подтверди». Мы уже зафиксировали это правило во вступлении и в подразделе про «дописать правил». Порядок шагов в инструкции — самый сильный рычаг. Перестановка шагов меняет результат на порядок сильнее любого другого приёма.
Хорошая инструкция — это пронумерованный список шагов, где каждый следующий шаг опирается на результат предыдущего. Плохая инструкция — это свалка «учти X, помни про Y, не забудь Z», где Y, X и Z конкурируют за внимание модели. Один из моих клиентов, аудитор, переписал 15 правил в 4 шага, и время обработки одного акта сократилось с 40 минут до 15. Правил стало не меньше — они стали последовательностью, а не параллельным шумом.
БЛОК «ПРИМЕРЫ»: ОБУЧЕНИЕ НА FEW-SHOT
Блок примеров — это пара «вход — правильный выход», показанная модели в системном промпте, чтобы она поняла формат, метки и стиль. Anthropic в Best Practices рекомендует от 1 до 5 примеров для задач, где формат нестандартный или есть редкие пограничные случаи — corner-cases, на которых модель обычно спотыкается. Google Gemini идёт дальше и рекомендует всегда включать few-shot — несколько примеров «вход — вывод» прямо в промпте. Промпты без примеров, по мнению Google, обычно менее эффективны.
Идея: примеры могут заменить инструкции, если они достаточно показательны. Но в 2022 году Sewon Min с коллегами опубликовал работу «Rethinking the Role of Demonstrations: What Makes In-Context Learning Work?» (EMNLP 2022, arXiv:2210.15059), которая перевернула популярное убеждение: few-shot учит не правильному ответу, а формату, пространству меток и распределению входов. Из этого два следствия, которые мы ещё усилим в разделе few-shot.
Первое: не тратьте час на «идеальный» пример. Важно, чтобы он показывал формат и метки, а содержание может быть приближённым. Второе: если corner-case действительно сложный и метки в нём нестандартные, few-shot на нём поднимет качество. Но если corner-case стандартный — лучше потратить время на хорошие инструкции, а не на «идеальный» пример.
Примеры — это формат, не истина.
БЛОК «ИСТОРИЯ»: ПАМЯТЬ ДИАЛОГА
История — это предыдущие сообщения в диалоге, если они есть. Частая ошибка — накапливать в одном диалоге сообщения, которые уже не относятся к текущей задаче: модель тратит контекст на их обработку, и в результате «теряет» релевантное. Если вы переключаетесь в том же диалоге на новую задачу — откройте новый чат. Не экономьте на чистоте контекста.
БЛОК «ЗАДАЧА»: СУТЬ ЗАПРОСА
Задача — это «что конкретно нужно сделать прямо сейчас». Формулировка должна быть одна, ясная, измеримая. Плохо: «сделай с этим что-нибудь полезное». Хорошо: «Извлеки из письма клиента имя, компанию, ИНН, сумму задолженности и срок оплаты. Верни в формате JSON с полями name, company, inn, amount, due_date». Разница — в проверяемости. Первую формулировку нельзя проверить: что значит «полезное»? Вторую — можно, прогнав на 10 письмах и сверив с эталоном.
Задача без измеримости — это пожелание, а не инструкция.
БЛОК «РАССУЖДЕНИЕ»: ПОШАГОВЫЙ CHAIN-OF-THOUGHT
Для сложных задач блок рассуждения заставляет модель сначала пройти по логической цепочке, а потом выдать ответ. Просьба «давайте думать по шагам» (в оригинале Wei et al. 2022: «let’s think step by step») поднимала качество на арифметических и логических задачах в 2022 году.
В 2026 году это уже шум для reasoning-моделей — мы разобрали это в подразделе про сдвиги в рекомендациях и ещё вернёмся к этому в разделе про CoT. Но если вы работаете со старой моделью или с задачей, где рассуждение нужно «показать» для аудита, явная инструкция вроде «перед ответом перечисли 3 ключевых риска, потом дай рекомендацию» остаётся полезной.
БЛОК «ФОРМАТ»: ФОРМА ОТВЕТА
Формат — это «в каком виде вернуть результат». Markdown с заголовками, JSON, таблица, проза, список — каждая задача требует своего. Если формат не зафиксирован, модель выбирает сама, и от запроса к запросу формат «плавает». Это причина, почему автоматический парсинг ответов ломается: разработчик рассчитывал на JSON, а модель выдала прозу с JSON-блоком внутри.
OpenAI предлагает для борьбы с этим два уровня. JSON-режим (JSON mode): модель обязана вернуть валидный JSON, но структура не фиксирована. Структурированный вывод (Structured Outputs): модель обязана вернуть JSON, точно соответствующий предоставленной JSON-схеме. Разница в надёжности: JSON-режим даёт валидный JSON в большинстве случаев, но структура может плавать. Структурированный вывод почти всегда совпадает со схемой — модель физически не может вернуть JSON с другими полями.
Anthropic идёт другим путём: рекомендует XML-теги и предзаполнение — задать начало ответа и позволить модели дописать остальное. Google Gemini предлагает responseSchema — аналог Structured Outputs от OpenAI.
БЛОК «ПРЕДЗАПОЛНЕНИЕ»: PREFILL В ПЕРВОМ ТОКЕНЕ
Предзаполнение — это техника, при которой вы заранее пишете первые несколько слов или символов ответа модели, и она вынуждена продолжить именно с этой точки. Если в API-запросе (программном вызове к модели) вы поставите в сообщении ассистента <final_verdict>, модель не сможет начать с приветствия или объяснения — она продолжит после тега и выдаст чистый вердикт.
В Opus 4.6 в феврале 2026 эту возможность убрали, и одно это показывает, насколько серьёзно индустрия относится к управлению форматом вывода. Anthropic в руководстве по миграции рекомендует переходить на Structured Outputs, системные промпты или параметр output_config.format — настройку формата ответа на уровне API. Практический вывод: если вы строите пайплайн «чат → парсер JSON → CRM», можно либо пользоваться Structured Outputs (если у вас enterprise-доступ и схема описана заранее), либо комбинировать prefill + JSON mode + пост-валидацию.
На июнь 2026 года prefill — устаревающий приём. В новых кодовых базах его лучше не закладывать.
ПРОПУЩЕННЫЙ БЛОК: ПРЕДСКАЗУЕМЫЙ СИМПТОМ В ОТВЕТЕ
Каждый блок в системном промпте закрывает конкретный класс сбоев. Отсутствие блока даёт предсказуемый симптом.
Нет блока «Контекст» — модель отвечает «общим голосом», без доменной специфики. В юридическом вопросе она звучит как учебник для первокурсника, а не как практикующий юрист. Нет блока «Тон» — модель отвечает развёрнуто, когда нужна одна строка, или наоборот. Нет блока «Фон» — модель путает формат полей, называет «дату заключения» там, где в исходнике «дата вступления в силу». Нет блока «Инструкции» — модель сваливает всё в один ответ, и непонятно, что было сделано, а что пропущено. Нет блока «Примеры» — на corner-case модель ошибается в каждом третьем случае, даже если базовые случаи отрабатывает идеально. Нет блока «Формат» — модель отвечает прозой, а вам нужен JSON для дашборда. Нет блока «Предзаполнение» — модель пишет вступление «Конечно, вот ваш ответ…», которое ломает парсер и добавляет секунды к обработке.
Когда результат «плывёт» в конкретном месте, ищите, какой блок пустует. Диагноз ставится по симптому.
ОБЯЗАТЕЛЬНЫЕ БЛОКИ И ТЕ, БЕЗ КОТОРЫХ МОЖНО ОБОЙТИСЬ
Эти симптомы объясняют, почему для офисной задачи обязательны пять блоков: контекст (роль), тон, инструкции, задача, формат. Эти пять закрывают около 80% сценариев. Блок «фон» нужен часто: если у вас стабильная структура данных, описание один раз кешируется и сокращает расходы. Блок «примеры» нужен для пограничных случаев — это мы ещё отдельно разберём в разделе про few-shot. Блоки «история», «рассуждение» и «предзаполнение» подключаются по ситуации: история нужна в длинном диалоге, рассуждение для сложной задачи, prefill если работаете со старой моделью или не хотите заводить полноценный pipeline валидации по схеме.
Anthropic, OpenAI и Google сходятся в одном: если вы не указали формат явно, модель выберет сама, и в 30–60% случаев выберет не то, что нужно. Это правило работает и в обратную сторону: если вы указали формат и не указали задачу, модель выдаст правильно отформатированную пустоту.
Системный промпт — это фундамент дома. Вы не видите его после постройки, но если он кривой, дом перекашивается. Можно поставить хорошие стены, окна, двери — но если фундамент поехал, всё напрасно.
Хороший системный промпт не бросается в глаза. Он просто делает каждый последующий ответ стабильным. Плохой заметен сразу: то модель «плывёт» по тону, то забывает формат, то выдаёт «Конечно!» перед сутью. Если вам приходится в каждом запросе заново объяснять «не пиши вступление, отвечай в JSON, не выдумывай», — проблема не в запросе, а в системном промпте. Эти правила должны жить там, а не в каждом пользовательском сообщении.
ИЕРАРХИЯ АБСТРАКЦИЙ: ОТ ПРОМПТА К НАВЫКУ И ВОРКФЛОУ
Один промпт покрывает одну задачу. Навык (skill) покрывает класс задач, которые вызываются из разных контекстов. Воркфлоу (workflow) покрывает многошаговый процесс, где результат одного шага — вход для следующего. Это иерархия. И она определяет, на каком уровне писать инструкцию.
ПРОМПТ КАК РАЗОВЫЙ ЗАПРОС ДЛЯ ЕДИНИЧНОГО СЛУЧАЯ
Промпт — это минимальная единица работы с моделью: один запрос, один ответ, ноль состояния между запросами. Anthropic в документации по Agent Skills (октябрь 2025) явно разделяет промпты и навыки: в отличие от промптов, которые представляют собой инструкции уровня диалога для разовых задач, навыки (Skills) загружаются по требованию и устраняют необходимость повторно передавать одни и те же указания в нескольких диалогах.
Промпт — это для ситуации, когда задача случилась один раз или редко, и нет смысла оформлять её как переиспользуемый артефакт. Написать письмо клиенту с извинениями — это промпт. Сделать шаблон для таких писем — это навык. Сделать конвейер, который по событию в CRM сам генерирует письмо, отправляет на согласование, логирует — это воркфлоу.
Один мой клиент, руководитель отдела продаж, в какой-то момент решил «автоматизировать» ответы на входящие запросы и потратил две недели на воркфлоу для задачи, которая случалась три раза в месяц. Через месяц воркфлоу сломался, чинить было некому, и клиент вернулся к промпту, который работал. Иерархия — это про зрелость задачи, а не про «сначала автоматизируем, потом подумаем». Преждевременная автоматизация — это техдолг в чистом виде, плюс проклятие «теперь это надо поддерживать».
НАВЫК КАК ПЕРЕИСПОЛЬЗУЕМАЯ ПРОЦЕДУРА, А НЕ ДЛИННЫЙ ПРОМПТ
Skill в терминологии Anthropic (октябрь 2025) — это папка инструкций, скриптов и ресурсов, которые Claude загружает динамически для повышения качества работы на специализированных задачах. Анатомия навыка: директория с SKILL.md (обязательный файл), YAML frontmatter с полями name и description (обязательные метаданные), и опциональные бандл-файлы — другие markdown-документы, Python-скрипты, шаблоны.
Ключевой принцип — progressive disclosure (постепенное раскрытие). На старте в системный промпт загружаются только метаданные (около 100 токенов на навык). Когда модель понимает, что навык релевантен, она подгружает тело SKILL.md (до 5K токенов), а дальше — отдельные файлы, которые могут быть «эффективно неограничены» по размеру, потому что скрипты выполняются, а не читаются. Сначала модель видит лишь краткое описание навыка, и только когда навык ей реально нужен по контексту запроса, она подгружает полное тело инструкции и сопутствующие файлы.
В офисной практике это значит вот что. Навык — это директория с инструкцией, примерами, скриптами и шаблонами, которая «включается» в работу, когда модель видит соответствующий триггер. Например, навык «чек корпоративного договора» — это директория с инструкцией, чек-листом рисков, примерами типовых пунктов, скриптом, который вытаскивает реквизиты из PDF. При запросе «проверь этот договор» модель «включает» навык, читает только нужные файлы и возвращает структурированный результат. Это радикально отличается от промпта, в котором всё в одном большом тексте.
ВОРКФЛОУ КАК ЦЕПОЧКА ШАГОВ С МОДЕЛЬЮ В РОЛИ ЭЛЕМЕНТА
Воркфлоу — это автоматизированная последовательность шагов, в которой модель может быть одним из шагов, но не единственным. LangChain (популярный открытый фреймворк для построения приложений на основе LLM) в блоге «How to think about agent frameworks» (апрель 2025) разделяет workflows и agents: в workflow LLM-компонент контролирует процесс меньше, поток более детерминированный. И OpenAI, и Anthropic прямо говорят, что агенты нужны не всегда — воркфлоу часто проще, надёжнее, дешевле, быстрее и производительнее.
Воркфлоу — это когда вы заранее знаете последовательность шагов и можете предсказать, что произойдёт. Агент — это когда модель сама решает, какие шаги предпринять, и предсказать результат заранее нельзя. Большинство «агентных систем» в продакшене — это комбинация: воркфлоу с вкраплениями агента на тех шагах, где нужна модель, и с детерминированным кодом на тех шагах, где он достаточен.
Типичный офисный воркфлоу: «пришло письмо в CRM → классификатор (LLM) определил тип → если тип „счёт”, вызвать скрипт для проверки реквизитов → если реквизиты ок, отправить на согласование бухгалтеру → если согласовано, сформировать платёжное поручение → залогировать». Модель здесь — один шаг, а не центр вселенной. И когда клиент спрашивает «а что если модель ошибётся в классификаторе», правильный ответ — «у нас на этом шаге есть fallback: если уверенность ниже 80%, передаём оператору». Воркфлоу живёт за счёт того, что у каждого шага есть предсказуемый результат и понятный путь отказа.
KLARNA: МЕТРИКА БЕЗ ЧЕЛОВЕКА МАСКИРУЕТ ДЕГРАДАЦИЮ СЕРВИСА
В феврале 2024 года Klarna запустила AI-ассистента на базе OpenAI для поддержки клиентов. Этот кейс подробно разбирался в одной из предыдущих глав — как пример того, что AI замещает задачу, но не функцию, и как пример корпоративной автоматизации с сильным инфраструктурным риском. Здесь мы возвращаемся к нему под другим углом.
Заявленная цель — заменить 700 операторов. Первые месяцы: ассистент обработал 2,3 миллиона разговоров, время разрешения упало с 11 до 2 минут, Klarna отчиталась о $40 миллионах дополнительной прибыли в 2024 году. К маю 2025 года компания признала, что качество упало, и начала возвращать людей. Сейчас Klarna снова нанимает операторов и снижает долю AI-обработки.
Здесь важен один урок про иерархию абстракций. Klarna попыталась перевести задачу «ответить клиенту на вопрос по счёту» с уровня «промпт» сразу на уровень «полная автоматизация» (воркфлоу без человека в контуре), минуя промежуточный уровень «навык с человеком-в-контуре как fallback». По публичной хронологии и интервью CEO это читается как разумная интерпретация случившегося: компания встала на самую радикальную точку шкалы автоматизации, не проверив систему на угловых случаях, и угловые случаи её догнали.
Правильная архитектура была бы: «AI-агент берёт 70% типовых вопросов, оператор-человек берёт 30%, в том числе все случаи, где модель не уверена». Вот она, иерархия: промпт для разовых, навык для повторяемых с человеком в контуре, воркфлоу для повторяемых без человека в контуре. Переход между уровнями должен быть явным, а не «автоматизируем всё и посмотрим, что получится».
СИГНАЛ ДЛЯ ПЕРЕХОДА НА СЛЕДУЮЩИЙ УРОВЕНЬ ИЕРАРХИИ
Anthropic в гайде по Agent Skills формулирует прямо: начните с оценки. Выявите конкретные пробелы в возможностях ваших агентов, запуская их на репрезентативных задачах и наблюдая, где они испытывают трудности. Создавайте навыки поэтапно, чтобы закрыть эти пробелы. Навык появляется тогда, когда в работе агента (или человека, использующего модель) появляется повторяющийся провальный случай, который можно закрыть переиспользуемой инструкцией. Не раньше.
Shopify прошли эту траекторию: 0–20 инструментов — простой системный промпт, 20–50 — начали выделять блоки, 50+ — перешли на инструкции по запросу (JIT-инструкции, just-in-time — подгружаются в момент запроса, а не хранятся в системном промпте постоянно), потому что иначе системный промпт превращался в нечитаемую свалку частных случаев. McKinsey с Lilli пошли по похожему пути: внутри компании Lilli — это навык, который грузится по триггеру «помоги с клиентским исследованием», и она умеет обращаться к 100 тысячам внутренних документов, накопленных фирмой за 60 лет. Это не «написали большой системный промпт с перечислением всех документов». Это skill + RAG (Retrieval-Augmented Generation — модель сначала ищет релевантные фрагменты во внешней базе знаний, потом формирует ответ) + рабочий процесс.
Правило для офисного работника: промпт стабильно работает на 8+ примерах из 10 — задача не переросла промпт. Запускаете вручную больше 5 раз в неделю — пора оформлять навык. Навык используют 3+ человека или 30+ раз в неделю — пора думать о воркфлоу. Каждый переход — отдельное решение, не «давайте сразу воркфлоу, потому что так солиднее».
Каждый уровень оправдан, когда переход к нему отражает реальную частоту задачи, а не амбиции. Ручной шуруповёрт нужен, чтобы закрутить один шуруп. Станок — чтобы закручивать один и тот же шуруп в одном и том же месте каждый день. Конвейер — когда станок не успевает за спросом и шурупы надо закручивать тысячами в час. Проблема в том, что новички часто покупают конвейер, чтобы закрутить один шуруп. Обслуживать конвейер, чинить, перенастраивать, оплачивать электричество обходится дороже, чем сто раз взять шуруповёрт в руки.
FEW-SHOT: ОБУЧЕНИЕ МОДЕЛИ НА НЕСКОЛЬКИХ ПРИМЕРАХ
Few-shot — это приём, при котором в системный промпт добавляются несколько пар «вход — выход», чтобы модель увидела желаемый формат, метки и стиль. Модель не учится на этих примерах в привычном смысле. Она подстраивает своё поведение под форму, которую видит прямо сейчас в диалоге. Это как если бы новый сотрудник в первый день посмотрел три ваших письма клиенту и на четвёртом написал в той же интонации, с теми же формулами, с тем же уровнем формальности. Никакого переобучения, никакой магии — просто очень сильная имитация паттерна.
Anthropic прямо пишет: для LLM примеры — это «картинки, стоящие тысячи слов». Одно изображение объясняет больше, чем абзац определений.
ПРОИСХОЖДЕНИЕ ТЕРМИНА: GPT-3 КАК ТОЧКА ОТСЧЁТА
Термин few-shot в том смысле, в котором мы его сейчас используем, ввели Brown и соавторы в июле 2020 года в статье «Language Models are Few-Shot Learners» (arXiv:2005.14165) про GPT-3. До этого инженеры использовали словосочетание «in-context learning» — обучение в контексте, без обновления весов модели. Brown формализовали разницу между zero-shot (модель видит только инструкцию), one-shot (один пример) и few-shot (несколько примеров в контексте).
В их собственных экспериментах few-shot стабильно бил zero-shot на десятках бенчмарков: перевод, ответы на вопросы, заполнение пропусков, рассуждения. Парадокс, который они же подсветили: чем больше модель, тем сильнее эффект от few-shot, но и тем меньше нужно примеров. GPT-3 на 175 миллиардов параметров с десятью примерами обходил fine-tuned (дообученные на узкой задаче) модели меньшего размера, обученные на тысячах.
С тех пор каждый серьёзный гайд по промпт-инжинирингу начинается с few-shot как базовой техники.
КОНТРИНТУИТИВНЫЙ ВЫВОД 2022 ГОДА О НАЗНАЧЕНИИ ПРИМЕРОВ
Севон Мин (Sewon Min) и команда из Вашингтонского университета в EMNLP 2022 выпустили работу «Rethinking the Role of Demonstrations: What Makes In-Context Learning Work?», которая перевернула интуицию. Как мы уже обсуждали в разделе про блок «Примеры», в задачах классификации с ограниченным набором классов главное в примере не «правильный ответ», а карта пространства «вход → метка».
Когда метки в примерах заменяли на случайные, точность падала, но не катастрофически. А вот когда перемешивали метки между классами или убирали входной текст и оставляли только метки, точность падала заметно. Из этого простой вывод: в ваших few-shot примерах разнообразие входов важнее, чем вылизанность выходов. Лучше пять разных кейсов из реальной почты, чем пять идеально отредактированных образцов из методички.
ОПТИМАЛЬНОЕ ЧИСЛО ПРИМЕРОВ: ЭМПИРИКА ПО СЕМИ МОДЕЛЯМ
По данным работы «The Few-shot Dilemma: Over-prompting Large Language Models» команды из Siemens AG и Мюнхенского технического университета (сентябрь 2025), для каждой модели существует свой оптимум, и превышение его деградирует точность. GPT-4o даёт максимум на 5–10 примерах, а на 20 уже проседает. LLaMA-3.1-8B-instruct — оптимум 10–20 примеров, потом спад.
Самое практичное: TF-IDF-отбор примеров (по текстовому сходству с целевой задачей — это простой статистический метод, который оценивает важность слова в документе через частоту в нём и редкость во всей коллекции) бьёт случайную выборку и эмбеддинг-отбор (выбор примеров по близости векторных представлений текстов) в большинстве сценариев. Их итоговая модель с 10–20 примерами, отобранными через TF-IDF, превзошла state-of-the-art fine-tuned BERT на 1% по F1 (гармоническому среднему точности и полноты — метрике, которая штрафит модели, если они хороши только в чём-то одном). Цифра скромная, но вывод жёсткий: «больше примеров» — это не то же самое, что «лучший результат». Миф «чем длиннее промпт, тем лучше» получил формальное опровержение на семи моделях.
СОРТИРОВКА ВХОДЯЩИХ ПИСЕМ: PREFILL ЗАДАЁТ ФОРМАТ JSON
Задача из реальной практики: модель должна была классифицировать входящие письма по 11 категориям — претензия, запрос акта, запрос справки, оферта и так далее. Без few-shot лучший результат был 76% точности. С тремя примерами на категорию (33 примера) стало 89%. С пятнадцатью примерами на категорию (165 примеров) стало 84% — хуже, чем с тремя. Результат перепроверяли трижды, ошибки в подсчёте не было.
Модель начала «переобучаться на примерах»: ловила не категорию, а конкретные слова-маркеры из примеров и пропускала синонимы. После отсева лишних примеров и оставления 3–5 разнообразных на категорию точность зафиксировалась на 91%.
Этот кейс — маленькая иллюстрация того, что Min и команда показали теоретически, а Tang с коллегами доказали на семи моделях: примеров должно быть столько, чтобы покрыть пространство входов, а не столько, чтобы влезло в токен-бюджет (количество токенов, которое клиент готов потратить на один запрос, у каждого провайдера и тарифа он свой).
РЕКОМЕНДАЦИИ ANTHROPIC ИЗ ОФИЦИАЛЬНОГО ГАЙДА ПО FEW-SHOT
Anthropic в Effective Context Engineering для AI-агентов и в Claude Prompting Best Practices формулирует четыре практических правила.
Количество: 1–5 примеров могут резко улучшить результат, больше пяти — только по необходимости, не по привычке. Разнообразие: разнообразные, канонические примеры, эффективно отражающие ожидаемое поведение. Качество против количества: «не набивайте список граничных случаев» — угловые случаи не пихать в промпт пачкой. Формат: XML-теги или markdown-заголовки, чтобы отделить примеры от основной инструкции визуально. Эти правила валидны для Claude Sonnet/Opus 4.x, и общая логика применима к другим современным моделям: 3–5 хороших примеров лучше 20 случайных.
Few-shot — это карта, а не маршрут. Карта показывает устройство местности: дороги, ориентиры, ограничения. Маршрут от А к Б вы строите сами: модель смотрит на few-shot-карту и прокладывает свой путь под каждый новый вход.
PREFILL: НАПРАВЛЕНИЕ МОДЕЛИ С ПЕРВОГО ТОКЕНА
Приём, при котором в API-запросе в сообщении ассистента стоит первая часть ответа. Если поставите { — модель продолжит в формате JSON, а не уйдёт в прозу. Если Уважаемый Иван Петрович, — в формальном тоне. Если Заключение: — пропустит шаблонную преамбулу и сразу перейдёт к сути. Тот же приём, что мы уже разобрали в блоке системного промпта, но с практической стороны.
ЗАДАЧИ, КОТОРЫЕ РЕШАЕТ PREFILL
Первая — зафиксировать формат. Хотите, чтобы модель начала с JSON-объекта? Пишите в prefill { — модель продолжает в JSON, а не уходит в прозу. Вторая — направить тональность. Привет, — разговорный, Уважаемый, — формальный. Третья — пропустить шаблонную преамбулу: большинство моделей начинают с «Конечно, я помогу с этим» или «Вот ваш ответ:», prefill позволяет перейти к сути сразу.
ГРАНИЦЫ ПРИМЕНИМОСТИ PREFILL
Prefill работает только в API, не в веб-интерфейсе: в чате нельзя заполнить «начало» ответа модели. На июнь 2026 года prefill — устаревающий приём, и в новых кодовых базах его лучше не закладывать: для фиксации формата используйте Structured Outputs и output_config.format в новых API (детали в блоке «Предзаполнение» системного промпта).
PREFILL УСКОРЯЕТ ФОРМАТИРОВАНИЕ, НО НЕ ОТМЕНЯЕТ ПРОВЕРКУ
Типичный пример: нужно вернуть сумму и валюту из платёжного документа в JSON. Если просто попросить «извлеки и верни в JSON», модель часто добавляет пояснение перед блоком, и парсер ломается. Решение — prefill {"amount": 0, "currency": ""}: модель понимает, что нужно заполнить оба поля и закрыть объект, и стартует с валидного JSON. Это как первая буква в кроссворде: вы видите { и понимаете, что дальше будут пары ключ-значение и закрывающая }. Без prefill модель гадает, с чего начать.
СЛОЖНЫЕ ЗАДАЧИ ЧЕРЕЗ ИТЕРАЦИИ: РАБОЧИЙ ПОДХОД
Сложная задача — это задача, в которой один промпт не справляется. Либо задача объективно многошаговая (составить договор из шаблона, проверить юридические риски, передать на подпись), либо задача требует разных режимов работы модели — рассуждение, генерация, проверка. В обоих случаях итеративный подход превращает одну сложную задачу в серию простых, каждая из которых решается одним промптом.
БАЗОВЫЙ ЦИКЛ ИЗ ЧЕТЫРЁХ ШАГОВ
Я держу в голове простую памятку в четыре строки: базовый промпт, запрос в AI, анализ ответа, корректировка промпта. Цикл повторяется, пока результат не станет стабильно приемлемым на 10–20 разных входов.
Шаг 1 — отправная точка: не «идеальный промпт», а первая рабочая версия. Шаг 2 — вы получаете ответ и не соглашаетесь с ним, а разбираете, что в нём хорошо и что плохо. Шаг 3 — фиксируете конкретное изменение, а не «переписать всё с нуля». Шаг 4 — проверяете изменение на новом наборе входов, а не на тех же двух, на которых «заметили улучшение».
Исследования подтверждают, что даже опытные NLP-инженеры тратят значительное время на эксперименты и оценку эффектов разных стратегий. Это не «лень новичков». Это встроенное свойство работы с вероятностной системой.
МЕТОД ПЯТИ ПРИМЕРОВ ДЛЯ СТАРТА В НЕОПРЕДЕЛЁННОСТИ
Эндрю Нг (Andrew Ng, сооснователь Coursera, бывший глава AI-подразделения Baidu, один из самых цитируемых AI-практиков в мире) в одном из постов 2025 года сформулировал практичный совет: «допустимо начать с быстрой и грубой реализации, скажем, 5 примеров с простым LLM-судьёй» (LLM-as-a-judge — подход, при котором оценку качества ответов поручают другой LLM, а не человеку). Эта фраза снимает перфекционизм.
Пять примеров — стартовая точка для цикла итераций, не полноценный тест. LLM-judge на пяти примерах — грубый фильтр: он ловит явные провалы, но не тонкие расхождения.
Когда я работаю с командой и она говорит «мы не знаем, с чего начать», я говорю: возьмите пять реальных кейсов, дайте чату задачу, посмотрите на результат, и зафиксируйте — в трёх из пяти он провалился. Это и есть база. Дальше — по одному изменению за итерацию.
УРОВНИ ЗРЕЛОСТИ В РАБОТЕ С ПРОМПТАМИ
По моему опыту, есть четыре уровня взаимодействия с AI.
1: «Потребление». Эпизодические запросы, бытовые справки, черновики. Хватает для справки, перевода, простой генерации. Мало, когда нужна повторяющаяся задача с гарантированным качеством.
2: «Итеративный диалог». Человек уточняет, переспрашивает, корректирует, выходит на нужный результат за 3–5 итераций. Хватает для разового отчёта, персонального текста. Мало, когда нужен типовой процесс в отделе.
3: «Оптимизация». Человек копит шаблоны, фиксирует удачные промпты, выходит на библиотеку проверенных промптов. Хватает для работы внутри одной команды. Мало, когда нужно масштабирование на компанию.
4: «Автоматизация». Человек создаёт воркфлоу, Custom GPT (настраиваемые версии ChatGPT с заданной ролью и набором знаний) или Skills, выходит на самоулучшающуюся систему. Хватает для рабочих систем. Мало, когда система должна работать без присмотра — тогда нужны агенты с явными границами, и это уже следующая глава.
Большинство пользователей сидит на уровне 1 и разочаровывается, когда уровень 1 не справляется с задачей уровня 3. Переход на следующий уровень начинается с простого осознания: проблема не в том, что «модель плохая». Проблема в том, что вы используете не тот метод.
ТИПИЧНАЯ ОШИБКА: ИЗМЕНЕНИЕ СРАЗУ НЕСКОЛЬКИХ ПЕРЕМЕННЫХ
Самая частая ошибка новичков, которую я вижу в своей работе: человек получает плохой ответ, переписывает промпт наполовину, отправляет снова, получает «улучшение» и не понимает, что именно сработало. Или наоборот: переписывает, получает «ухудшение», и не понимает, какая из дюжины правок всё сломала.
Правило: одно изменение за итерацию. Записали: «версия 1.2 — добавил пример с граничным кейсом». Сравнили с версией 1.1 на тех же 20 кейсах. Измерили. Решили: оставить или откатить.
Итерация — это записанное измерение: «было 76%, стало 89% на этих 20 кейсах», а не субъективное «ну вроде лучше». Допустим, я думаю, что модель путает категории X и Y, потому что в примерах я использовал похожие формулировки. Дальше я меняю примеры, чтобы формулировки расходились, прогоняю на 20 тестовых кейсах и записываю, сколько ошибок ушло. Метод начинается там, где появляется связка «гипотеза → изменение → тест → измерение». Anthropic в Skills-гайде формулирует мягче, но суть та же: следите за неожиданными траекториями или чрезмерной опорой на определённые контексты; итерируйте с Claude — просите Claude фиксировать успешные подходы и распространённые ошибки в переиспользуемом контексте внутри навыка; если Claude отклоняется от курса, попросите его самостоятельно поразмышлять, что пошло не так.
ОБУЧАЮЩИЕ ДАННЫЕ МОДЕЛИ И РАЗБРОС ПОВЕДЕНИЯ НА ОДНОМ ПРОМПТЕ
Один и тот же промпт может работать в ChatGPT и спотыкаться в GigaChat, и наоборот. Это не повод «выбирать правильную модель», а повод знать особенности.
ChatGPT (GPT-4o, GPT-5) хорошо работает с 3–5 few-shot примерами на русском, и с английским у него плотная база. GigaChat 2 требует больше примеров (5–7) для стабильности на русском, но сильнее на российской отраслевой лексике — юриспруденция, бухгалтерия РФ. Для русской специфики GigaChat может выигрывать. На уровне structured output у GPT-4o с Structured Outputs 100% по бенчмарку OpenAI, у GigaChat поддержка есть, но процент ниже, и для продакшна нужно закладывать валидацию и retry. На длинных промптах ChatGPT лучше «добирает» детали из конца, GigaChat сильнее зависит от порядка: важное ставить в начало. По скорости итерации ChatGPT быстрая, но платная, у GigaChat бесплатный тариф удобен для прототипирования.
Практический вывод: прототипировать можно в GigaChat, финализировать в ChatGPT. А если задача целиком в российской специфике — тестировать обе модели на своих 20 кейсах и выбирать по результату, а не по обещаниям поставщика.
РЕЗЮМЕ
Хороший промпт — это результат нескольких итераций, а не текст, который с первого раза получился правильным. Самый сильный приём — порядок шагов в инструкции, а не длина промпта и не количество правил.
Системный промпт для офисной задачи собирается из пяти обязательных блоков: роль, тон, инструкции, задача, формат. Эти пять закрывают около 80% сценариев. Пропуск любого из блоков даёт предсказуемый симптом в ответе.
Иерархия «промпт → навык → воркфлоу» отражает зрелость задачи: разовый запрос, повторяемая процедура, автоматизированный процесс. Каждый переход — осознанное решение. Преждевременная автоматизация хуже её отсутствия.
Few-shot учит формату и распределению входов, а не «правильному ответу». Три-пять разнообразных примеров стабильно бьют пятнадцать-двадцать однотипных.
Цепочка рассуждений через «let’s think step by step» для reasoning-моделей 2026 года — лишний шум. Модель умеет рассуждать сама, и параметр reasoning_effort или thinking_level заменяет ручную просьбу.
Prefill постепенно уходит из практики. Anthropic убрал его в Opus 4.6 и рекомендует мигрировать на Structured Outputs.
Правило итерации одно: одна переменная за раз. Иначе вы не поймёте, что именно сработало.
Хороший промпт покрывает одну задачу в одном разговоре. Иерархия «промпт → навык → воркфлоу» показывает, как от разового запроса перейти к переиспользуемой процедуре. Следующая ступень — агент, который сам решает, какие шаги предпринять, какие инструменты вызвать и где остановиться.