Misha Ford
Мастерство промт-инжиниринга. Продвинутый уровень

ЧАСТЬ I. ФУНДАМЕНТ ПРОДВИНУТОГО ПРОМТ‑ИНЖИНИРИНГА

ГЛАВА 1. КАК РЕАЛЬНО РАБОТАЕТ LLM И ПОЧЕМУ ЭТО ВАЖНО ПРОМТ‑ИНЖЕНЕРУ

Если вы хотите стать профессиональным промт‑инженером, вам недостаточно уметь “хитро” формулировать запросы. Это работает только до определённого уровня. Дальше вы упираетесь в поведение модели, которое на первый взгляд кажется магией: то отвечает идеально, то несёт уверенную чушь, то вдруг перестаёт слушаться инструкций.

Проблема не в вас. Проблема в том, что большинству пользователей вообще не объясняют, как устроена LLM. Не на уровне формул и научных статей, а на уровне того, что действительно влияет на ежедневную работу с промтами.

В этой главе мы спокойно разберёмся с фундаментальными вещами: что такое LLM, что такое токены, контекстное окно, температура, top‑p, откуда появляются так называемые “галлюцинации” и чем одна модель отличается от другой. Всё это нужно не для теории ради теории, а для практики: чтобы вы могли проектировать промты, исходя из реального устройства модели, а не из надежды “может, повезёт в этот раз”.

Начнём с самого главного вопроса: что же такое LLM в человеческом понимании.

LLM – это не разум, не личность и не всемогущий эксперт. Это статистическая модель языка, обученная на огромном количестве текстов. Её задача на техническом уровне проста: по предыдущему кусочку текста с максимальной вероятностью предсказать следующий фрагмент. Не больше и не меньше. Всё, что вы видите – рассуждения, аргументы, структура текста, советы – это результат очень сложного, но всё равно статистического продолжения текста.

Представьте игру: вы начали писать предложение и остановились на середине. Ваш собеседник должен догадаться, как его продолжить так, чтобы оно звучало правдоподобно. Если он видел миллиарды текстов, он начнёт угадывать очень точно. Но всё равно это угадывание, а не “понимание мира”.

Отсюда вытекают важные последствия для промт‑инженера. Модель не “знает” факты в человеческом смысле. Она просто видела много примеров того, как люди пишут о фактах. Она не “знает” алгоритмы – она видела много описаний алгоритмов и их примеров. Она не “понимает”, что такое правда и ложь. Она просто продолжает текст в духе того, что чаще встречалось рядом. Поэтому иногда модель будет уверенно выдумывать то, чего никогда не было, – как если бы человек, который любит болтать, начал фантазировать, чтобы не выглядеть незнающим.

Чтобы управлять этим поведением, нужно понимать ещё одну ключевую вещь: LLM работает на уровне токенов. Токен – это не обязательно слово, а кусочек текста. Иногда это целое слово, иногда часть слова, иногда пробел или знак препинания. Модель на вход получает последовательность токенов, а на выходе генерирует новый токен за токеном.

Почему это важно вам, а не только разработчикам? Потому что у каждой модели есть ограничение: так называемое контекстное окно. Это максимальное количество токенов, которое модель может одновременно “держать в голове”. Если вы передаёте слишком длинный диалог, большую статью, несколько документов – в какой‑то момент старые части контекста просто перестают учитываться. Модель больше не видит их, как будто вы их никогда не писали.

Отсюда возникают типичные жалобы пользователей: “я дал модели всю историю, а она пишет, как будто забыла про начало”, “я прикрепил большой текст, а она ссылается только на конец”. Всё логично: вы перегрузили контекстное окно. Для промт‑инженера это не баг, а рабочее ограничение, с которым надо уметь жить. Вы должны заранее понимать: если задача требует работы с большим объёмом текста, её нужно разбить на части, а не пытаться затолкать всё сразу.

Ещё два параметра, которые вы обязаны ощущать на практике, – это температура и top‑p. Они отвечают за степень “хаотичности” и креативности генерации.

Температура – это коэффициент, который влияет на то, насколько модель будет склонна выбирать менее вероятные продолжения текста. При низкой температуре (например, 0–0,2) модель будет очень “консервативной”: она выбирает наиболее предсказуемые варианты. Это хорошо для задач, где нужна стабильность, однообразие и максимальная точность. При высокой температуре (0,7–1,0) модель становится более творческой и непредсказуемой. Она больше готова “рисковать” с выбором слов, структуры, идей. Это полезно для генерации креативных концепций, сторителлинга, необычных формулировок.

Top‑p – это другой способ управлять разнообразием ответов. Вместо того чтобы просто “разогревать” всю вероятность, модель берёт только верхнюю часть распределения: например, выбирает токены, которые в сумме дают 90% вероятности, и игнорирует всё остальное. Комбинация температуры и top‑p даёт вам тонкую настройку того, как именно будет писать модель: строгим, скучным, но точным языком или живым, интересным, но иногда чрезмерно свободным.

Важно: промт‑инженер не просто знает слова “температура” и “top‑p”, а понимает, когда и зачем их менять. Например, если вы пишете промт для генерации юридического текста, лучше держать температуру около нуля – вам нужна предсказуемость и структурная стабильность. Если вы создаёте десятки вариантов креативных рекламных слоганов, наоборот, увеличиваете температуру, иначе модель будет повторять одно и то же.

Теперь вернёмся к “галлюцинациям”. В контексте LLM под этим подразумевают ситуации, когда модель выдаёт неправду, но делает это уверенно, логично и красиво. Причины у этого явления вполне понятные.

Во‑первых, модель не имеет прямого доступа к реальному времени, базам данных или фактической проверке, если её специально не подключили к таким источникам через инструменты. Она опирается только на то, что видела в процессе обучения, и на ваш текущий промт. Если информация в обучающих данных устарела или неполна, модель будет “достраивать” недостающее.

Во‑вторых, модель оптимизирована на правдоподобие текста, а не на истину. Если вы задаёте вопрос, на который она не знает точного ответа, но видела подобные формулировки, она всё равно попытается продолжить текст так, чтобы он выглядел по‑человечески убедительным.

В‑третьих, промт может неявно провоцировать выдумки. Когда вы просите: “придумай исследования, которые подтверждают…”, “назови конкретные источники…”, “дай ссылки на статьи…”, вы буквально заставляете модель играть в игру “как будто”. Она не умеет сказать: “я не нашла таких данных в базе”, если вы этого явно не требуете.

Как промт‑инженер вы должны относиться к галлюцинациям не как к случайным “глюкам”, а как к предсказуемой части поведения модели. Управлять этим можно несколькими способами.

Первое: чётко задавать режим. Например, прямо указать: если вы не уверены в фактах, пишите, что не уверены, и не придумывайте источники. Добавлять явные инструкции: “если точных данных нет, предложите гипотезы и пометьте их как гипотезы”.

Второе: ограничивать задачи модели. Не просить её там, где нужен доступ к актуальным данным, без дополнительного инструмента. Или хотя бы просить не ссылки, а направления поиска, ключевые слова, типы источников.

Третье: использовать дополнительные шаги проверки. Например, сначала попросить модель выделить, какие части ответа основаны на общих знаниях, а какие – на предположениях. Или попросить её “покритиковать” собственный ответ, как если бы она искала в нём возможные ошибки.

Наконец, вам нужно понимать, что разные LLM ведут себя по‑разному. GPT‑4/4o, Claude, Llama, Gemini – это не просто разные бренды, а разные архитектуры, обученные на разных данных, с разными приоритетами.

GPT‑4/4o, как правило, сильны в универсальности: хорошо держат структуру, умеют рассуждать, комбинировать разные навыки. Claude часто показывает себя очень сильным в длинных текстах, литературном стиле, анализе больших контекстов. Модели семейства Llama – открытые и гибко настраиваемые, но их качество сильно зависит от конкретной версии и дообучения. Gemini делает акцент на интеграции с экосистемой Google и мультимодальности.

Для вас это означает простую вещь: один и тот же промт может вести себя по‑разному на разных моделях. Где‑то он будет работать идеально, где‑то давать слишком обобщённые или наоборот слишком “болтливые” ответы. Профессионал не обвиняет модель, а адаптирует промты под её поведение.

Теперь перейдём к практике. Теория без практики в промт‑инжиниринге превращается в бесполезное знание.

Ваше первое практическое задание – почувствовать, как на самом деле влияет температура. Возьмите один и тот же промт. Наилучший тип – задача, где есть место как структуре, так и креативу. Например, можно использовать такой запрос:

“Вы – копирайтер, который пишет тексты для лендингов финтех‑продукта для молодёжи. Составьте текст главного экрана: заголовок, подзаголовок и короткое описание преимущества сервиса.”

С этим же текстом выполните четыре прогона: с температурой 0, 0.3, 0.7 и 1.0. Все остальные параметры оставьте неизменными. Ваша задача – не просто посмотреть на ответы, а проанализировать, как меняется их характер.

При температуре 0 вы, скорее всего, увидите очень предсказуемые, иногда даже скучные формулировки. Заголовки будут типовыми, без рискованных идей. При 0.3 текст останется структурным, но появится чуть больше разнообразия. При 0.7 появятся более смелые формулировки, неожиданные обороты. При 1.0 модель может начать выдавать что‑то чрезмерно креативное, иногда граничащее с бессмыслицей или слишком “маркетинговой водой”.

Запишите себе наблюдения: как меняется креативность, чёткость структуры, повторяемость одних и тех же фраз. Это упражнение, сделанное один раз сознательно, намного полезнее десятка абстрактных объяснений про температуру. После него вы уже не будете бездумно оставлять параметр “как есть”, а начнёте подбирать его под задачу.

Второе практическое задание касается контекстного окна. Вам нужно на собственном опыте увидеть, как ограничение контекста ломает задачу, и попробовать обойти это ограничение.

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

“Проанализируйте этот текст и сделайте подробное структурированное резюме, выделив главные разделы, тезисы и выводы. Отвечайте на русском языке, в формате иерархического списка.”

Сначала попробуйте просто целиком вставить текст (если длина позволяет). Затем добавляйте ещё материалы – ещё одну статью, ещё одну главу. В какой‑то момент вы столкнётесь с тем, что модель либо начнёт игнорировать начало, либо ответы станут поверхностнее: она будет “слипать” содержимое, вместо реального анализа.

После этого сделайте то, что делает промт‑инженер: разбейте текст на части. Сформулируйте стратегию “chunking” – деления на блоки. Например, вы можете:

Сначала разделить текст на логические куски и для каждого куска попросить модель сделать локальное резюме. Потом попросить модель взять все эти резюме и, на их основе, сделать итоговое обобщение всего материала.

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

Здесь важно, чтобы вы не ограничивались мыслью “ну да, можно дробить”. Вам нужно реально проделать это руками и увидеть разницу: что даёт прямое скармливание большого текста, а что – подход с разбиением и последующей агрегацией. Тогда контекстное окно перестаёт быть абстрактным ограничением и становится конкретным фактором, который вы учитываете при проектировании любых сложных задач.

Освоив эти два упражнения, вы сделаете первый шаг от “пользователя, который пишет запросы” к специалисту, который строит взаимодействие с моделью осознанно. В следующих главах мы будем накладывать более сложные техники на этот фундамент, но без понимания того, как модель генерирует текст, какие у неё пределы памяти и как управлять её креативностью, двигаться дальше бессмысленно.

ГЛАВА 2. СТРУКТУРА СИЛЬНОГО ПРОМТА

На предыдущем уровне вы увидели, как модель думает в токенах, как на неё влияют температура и контекстное окно. Теперь нам нужно перейти от “понимать модель” к “управлять моделью”. И здесь всё начинается со структуры промта.

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

Сильный промт – это маленький технический документ. В нём есть роль, чёткая инструкция, контекст, ограничения и примеры. Как только вы начинаете писать промты в этом формате, качество ответов прыгает на другую высоту, и это не магия, а просто грамотное описание задачи.

Прежде всего вам нужно научиться задавать роли и персону модели. У модели нет “истинного” характера: то, как она с вами общается, определяется тем, какую роль вы ей задали, и насколько последовательно вы её удерживаете. Вы можете обращаться к модели как к юристу, как к маркетологу, как к редактору, как к преподавателю. Вы можете задавать стиль – строгий, ироничный, разговорный, академический.

Роль – это не украшение текста промта, а управляющий параметр. Если вы пишете: “вы – опытный маркетолог, который специализируется на B2B‑юридических услугах и хорошо понимает, как принимают решения директора по правовым вопросам”, вы сразу резко сужаете пространство возможных ответов. Модель перестаёт писать “для всех” и начинает писать для узкой, понятной аудитории.

Персона – это расширение роли. Это уже не просто “маркетолог”, а конкретный тип эксперта: его тон, отношение к риску, стиль речи, даже возраст и культурный контекст. Она задаётся описанием: “вы – практикующий юрист с 15‑летним опытом работы с корпоративными клиентами, который пишет простым, понятным языком для занятых предпринимателей и не терпит канцелярита”. Такая персона позволяет модели ориентироваться в том, какой язык выбирать и какие примеры приводить.

Следующий слой – различие между инструкцией, контекстом и примерами. Большинство промтов всё это смешивают в кашу. Ваша задача как промт‑инженера – разделять эти компоненты в голове, а иногда и явно в тексте.

Инструкция – это то, что вы хотите получить: действие и формат. “Составьте текст”, “проанализируйте”, “сравните”, “создайте структуру”. Это команда.

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

Примеры – это демонстрация того, что вы считаете удачным. Модель невероятно чувствительна к примерам. Один‑два фрагмента правильного стиля, правильного уровня глубины и нужного формата зачастую влияют на качество ответа больше, чем абстрактное “сделайте профессионально и интересно”.

Наконец, в сильном промте всегда присутствуют явные ограничения и критерии качества. Это то, что отделяет “примерно то, что я хотел” от “ровно то, что нужно”.

Ограничения – это рамки: объём текста, запрещённые и желательные слова, стиль, структура, формат вывода, степень детализации. Например: “не используйте штампы вроде ‘команда профессионалов’, ‘индивидуальный подход’”, “длина текста – до 1200 знаков”, “пишите без канцелярита, короткими предложениями”, “не упоминайте физлиц, только бизнес‑клиентов”.

Критерии качества – это то, по чему можно проверить, удался ли результат. “Текст должен чётко говорить, для кого эта услуга, какую главную проблему она решает, и чем наша компания отличается от конкурентов”, “после прочтения клиент должен понять, что мы специализируемся именно на спорах с госорганами, а не на бытовых вопросах”. Если эти критерии вы формулируете в промте, модель может попытаться на них опираться. Более того, вы можете просить её в конце ответа самооценить, насколько результат соответствует заданным критериям.

Всё это можно собрать в простой, но мощный фреймворк RICCE: Role, Instruction, Context, Constraints, Examples – Роль, Инструкция, Контекст, Ограничения, Примеры.

Роль задаёт, “кто сейчас говорит”.

Инструкция определяет, “что нужно сделать”.

Контекст объясняет, “в какой ситуации это делается”.

Ограничения устанавливают, “что нельзя и что обязательно”.

Примеры показывают, “как выглядит хороший результат”.

Сначала вы будете держать RICCE в голове, постепенно вы начнёте автоматически писать промты так, чтобы все эти элементы присутствовали – иногда в явном виде, иногда встроенными в текст.

Отдельного разговора заслуживает формат ответа.

Для промт‑инженера формат – это не косметика, а инструмент интеграции. Чем более сложные и автоматизируемые задачи вы решаете, тем важнее становиться управлять формой вывода.

Иногда вам нужен простой текст, разбитый на разделы. Иногда – маркированные или нумерованные списки, чтобы вы могли легко ориентироваться и править. Иногда – таблицы в Markdown, чтобы из ответа было удобно собирать отчёты или переносить данные. В более технических задачах вам нужен строго структурированный формат: JSON, YAML или другой формат, который будет дальше автоматически обрабатываться скриптом, сервисом, таблицей.

Когда вы просите: “просто опишите…”, модель делает, что хочет. Когда вы говорите: “ответьте в формате: список из пунктов, каждый пункт содержит заголовок, краткое описание и конкретный пример”, вы существенно ограничиваете спектр возможного хаоса. Когда вы требуете: “верните только JSON по следующей схеме, без пояснений и дополнительного текста”, вы превращаете модель в генератор структурированных данных.

Теперь давайте посмотрим, как слабый промт превращается в сильный с помощью RICCE. Представьте исходный запрос: “Напиши текст для сайта о юридических услугах”.

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

Возьмём этот промт и перепишем по RICCE.

Роль: вы задаёте модели роль маркетолога, специализирующегося на B2B‑юридических услугах. Не “просто копирайтер”, а человек, который понимает, как думают директора, предприниматели, руководители юротделов.

Инструкция: нужно не просто “написать текст”, а, например, “написать текст главного блока для сайта юридической компании, который должен мотивировать B2B‑клиента оставить заявку на консультацию”.

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

Ограничения: вы прямо прописываете, что нельзя использовать штампы “команда профессионалов”, “индивидуальный подход”, “широкий спектр услуг”. Указываете желаемый объём: заголовок до 10–12 слов, подзаголовок до 20–25 слов, основной текст до 400–600 знаков. Обозначаете стиль: без канцелярита, конкретно, с фокусом на рисках и их снижении, без перегруженных юридических терминов.

Примеры: вы приводите один‑два примера фраз, которые вам нравятся. Не обязательно юридических – можно из любых удачных лендингов. Например: “Защитим ваш бизнес от штрафов и блокировок, пока вы занимаетесь ростом компании”, “Юристы, которые говорят языком денег, а не статей закона”. Эти примеры задают модель не только стилю, но и направлению мысли.

В результате вместо слабого “Напиши текст для сайта о юридических услугах” у вас получится промт, который по сути напоминает постановку задачи копирайтеру‑профессионалу. От такой постановки профессионал выдал бы намного более сильный текст. Модель сделает то же самое.

Теперь перейдём к практике.

Первое практическое упражнение: возьмите исходный простой промт – “Напиши текст для сайта о юридических услугах” – и вручную разложите его по RICCE.

Сначала самостоятельно сформулируйте:

какую роль вы задаёте модели (например, “маркетолог, который пишет B2B‑тексты для юридических компаний”);

какую конкретную инструкцию вы даёте (какой именно блок сайта, какая цель – например, увеличение заявок);

какой контекст нужно добавить (тип юридических услуг, целевая аудитория, особенности рынка или компании);

какие ограничения по стилю, длине, словам стоит ввести;

какие 1–2 примера фраз вам нравятся и могут служить ориентирами.

Только после того, как вы продумали это на бумаге или в заметках, соберите всё в один цельный промт. Вы должны почувствовать, как вы из размытого запроса делаете чёткую инженерную постановку. Это и есть мышление промт‑инженера.

Второе задание – на точность и управление форматом. Ваша цель – сформулировать промт так, чтобы модель вернула только JSON строго заданной структуры, без пояснений, без вступлений и без дополнительных комментариев.

Например, вы хотите получить описание целевой аудитории для юридической компании в виде JSON. Схема может быть такой:

{

"segment_name": "…",

"pain_points": ["…", "…"],

"desired_outcomes": ["…", "…"],

"decision_maker": "…",

"typical_objections": ["…", "…"]

}

Ваша задача – написать промт, который:

задаёт нужную роль (например, “вы – маркетолог, который помогает структурировать целевую аудиторию юридической компании в формате JSON”);

даёт чёткую инструкцию: “на основе описания компании ниже создайте ОДИН JSON‑объект по следующей схеме”;

приводит контекст (краткое описание юридической компании и её специализации);

задаёт ограничения: “никакого текста вокруг JSON, никаких комментариев, только один валидный JSON‑объект, поле pain_points – массив строк, поле desired_outcomes – массив строк и т.д.”

Когда вы получите ответ, внимательно проверьте:

добавила ли модель что‑то вроде “вот JSON‑структура”

соблюдена ли схема: нет ли лишних полей, все ли поля заполнены, нет ли пустых объектов

корректен ли JSON – парсится ли он без ошибок.

Если модель всё равно добавляет текст вокруг JSON, попробуйте усилить ограничения. Например, вы можете добавить формулировку: “если вы добавите хоть один символ вне JSON‑объекта, ответ считается неверным”, “начните ответ сразу с символа { и завершите только закрывающей фигурной скобкой }”. Иногда полезно добавить фразу: “не используйте тройные кавычки, не используйте Markdown, не добавляйте пояснений”.

Повторите попытку, пока не добьётесь того, что модель стабильно возвращает только один JSON‑объект нужной структуры. Это упражнение может показаться мелочью, но именно такие мелочи отличают любителя от профессионала. В реальных проектах вам очень часто нужно будет получать от модели структурированный вывод, который затем автоматически обрабатывается. Любая лишняя фраза или нарушенная схема ломают автоматизацию.

Отработав RICCE на примере юридического текста и освоив управление структурой ответа через JSON, вы сделаете ещё один шаг к тому, чтобы ваши промты перестали быть “пожеланиями” и стали настоящими техническими заданиями для модели. В следующих главах мы начнём строить цепочки промтов и учиться заставлять модель рассуждать по шагам, но всё это опирается на фундамент: чётко заданная роль, ясная инструкция, понятный контекст, жёсткие ограничения и хорошие примеры.

ЧАСТЬ II. КЛЮЧЕВЫЕ ТЕХНИКИ ПРОМТ‑ИНЖИНИРИНГА

ГЛАВА 3. CHAIN‑OF‑THOUGHT И ПОЭТАПНОЕ МЫШЛЕНИЕ

На каком‑то этапе вы начинаете замечать странную вещь: модель решает сложные задачи почти правильно, но всё время где‑то “спотыкается”. Чуть неправильно расставляет приоритеты, теряет одно из условий, игнорирует важное ограничение, делает вывод, который вроде звучит логично, но при ближайшем рассмотрении разваливается. Это признак того, что вы всё ещё общаетесь с моделью на уровне “дай ответ”, а не на уровне “давай думать по шагам”.

Модели семейства LLM сами по себе уже умеют рассуждать. Но по умолчанию они стараются выдать вам готовый результат как можно быстрее и компактнее. Это значит, что большая часть “внутреннего” рассуждения остаётся скрытой. Вы видите только финальное предложение, не наблюдая, какие предпосылки модель приняла, какие отбросила и где именно допустила ошибку. Как промт‑инженер, вы должны научиться вытаскивать этот процесс наружу и, по сути, управлять логикой модели через промты. Это и есть Chain‑of‑Thought – поэтапное, цепочечное мышление.

Если вы просите: “предложите маркетинговую стратегию для нашего продукта”, модель просто сгенерирует некий текст, опираясь на обобщённый опыт похожих запросов. Она попробует что‑то сказать про целевую аудиторию, каналы продвижения, контент, возможно, про бюджеты. Но она не обязана явно показывать, как она к этому пришла, какие гипотезы рассматривала, от чего отказалась. В результате вы получаете гладкий, но непрозрачный ответ: он может быть частично верным, частично ошибочным, а где и почему – непонятно.

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

Разница между “дай ответ” и “объясни ход рассуждений” критична.

В первом случае модель стремится к краткости и эффектности: дать то, что звучит как уверенный, законченный вариант. Во втором случае вы просите её разжевать мыслительный процесс, и она уже не может просто выдать красиво оформленную догадку – ей приходится “играть” в аналитика, который показывает расчёт. Не случайно многие сложные задачи (логические, математические, стратегические) решаются моделью значительно лучше, если вы просите её объяснить, как она думает.

Однако важно понимать, что Chain‑of‑Thought – не серебряная пуля. Бывают случаи, когда он действительно повышает качество, а бывают – когда только тормозит работу и засоряет ответ лишними словами.

Где CoT особенно полезен? В задачах, где есть несколько ограничений, пересекающиеся условия, trade‑off’ы и необходимость выбрать лучший вариант среди разных альтернатив. Например, когда вы подбираете маркетинговую стратегию с ограниченным бюджетом и несколькими целями; когда нужно приоритизировать фичи продукта; когда вы решаете логическую головоломку; когда разбираете сложные сценарии поведения пользователя. В таких случаях поэтапное мышление помогает модели не потерять условия, а вам – увидеть, где она исказила или забыла важную деталь.

Где CoT может только мешать? В простых, рутинных задачах, где вам нужен быстрый, короткий ответ: переписать абзац, сделать краткое резюме, предложить пару вариантов заголовков. Если каждый раз заставлять модель “думать по шагам” там, где достаточно одного шага, вы будете тратить контекст, время и своё внимание на лишние объяснения. Более того, иногда излишнее “рассуждение” провоцирует модель усложнять то, что можно решить просто.

Как промт‑инженер, вы должны научиться чувствовать этот баланс: где вам нужен только результат, а где обязательно нужен путь. И ещё важнее – уметь задавать структуру этого пути. “Подумай по шагам” – это зачаточная форма Chain‑of‑Thought. Настоящая сила появляется, когда вы явно описываете шаги: “сначала сформулируй критерии, затем собери варианты, затем сравни по критериям, только потом сделай вывод”.

Давайте разберём практический пример. Представим задачу: вам нужно выбрать маркетинговую стратегию для финтех‑продукта с ограниченным бюджетом. Есть несколько каналов: таргетированная реклама, контент‑маркетинг, партнёрства, офлайн‑активности. Бюджет ограничен, целевая аудитория – молодые специалисты и студенты, продукт – приложение для управления личными финансами. Вам нужно, чтобы модель не просто выдала список из “универсальных советов”, а предложила реалистичную, приоритизированную стратегию с учётом ограничений.

Сначала сформулируйте “простой” промт без Chain‑of‑Thought. Например: “Предложите маркетинговую стратегию для нашего финтех‑приложения для молодёжи с ограниченным бюджетом. Укажите основные каналы, примерное распределение бюджета и ожидаемый эффект”. Модель, скорее всего, выдаст вам приличный, но поверхностный ответ: перечислит соцсети, блог, таргет, блогеров, возможно, упомянет партнёрства с вузами. Что обычно происходит в таком сценарии?

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

Теперь перепишите задачу с использованием поэтапного мышления. Вы даёте модели не только цель, но и алгоритм: “подумай шаг за шагом”. Например, вы можете сформулировать промт так, чтобы он явно требовал разложить рассуждения на этапы: сначала анализ, затем критерии, потом варианты и только потом выбор.

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

Когда вы сравните два ответа – простой и поэтапный, – обратите внимание на конкретные вещи. В первом варианте модель может легко потерять часть ограничений (например, говорить о дорогих офлайн‑активностях при микробюджете) или не учитывать особенности аудитории (предлагать каналы, которые слабо бьют по вашей целевой группе). Во втором варианте она, как минимум, будет вынуждена проговорить эти моменты словами, и вы увидите, где логика не стыкуется с реальностью. Очень часто уже один этот факт – явное проговаривание критериев – делает решение в разы качественнее.

Теперь важно научиться формулировать Chain‑of‑Thought не в одном‑двух шаблонных вариантах, а гибко. Вам не нужно всегда писать одно и то же “подумай шаг за шагом”. Иногда эффективнее задавать более содержательные подсказки: “подумай как…”, “пошагово проанализируй…”, “сначала сформулируй критерии, затем выбери…”. Каждая из этих конструкций задаёт немного разный стиль мышления модели.

Первая формулировка – условно “подумай как…”. Здесь вы совмещаете роль и CoT. Например: “Подумайте как маркетолог, который отвечает за рост продукта с ограниченным бюджетом. Сначала разберитесь в продукте и целевой аудитории, затем предложите стратегию продвижения”. Вы тем самым просите модель примерить на себя определённый тип мышления, характерный для эксперта. Полезно детализировать: “Подумайте как перфоманс‑маркетолог, привыкший работать с жёсткими ограничениями бюджета и требованием окупаемости. По шагам разберите…”. Такая формулировка подталкивает модель к более “прагматичному” рассуждению.

Вторая формулировка – “пошагово проанализируй…”. Здесь вы прямо указываете, что хотите видеть анализ в виде последовательных шагов. Например: “Пошагово проанализируйте возможные маркетинговые каналы для нашего продукта: сначала перечислите все релевантные каналы, затем оцените каждый по критериям ‘стоимость’, ‘скорость результата’, ‘точность попадания в целевую аудиторию’, затем сделайте вывод о том, какие 2–3 канала стоит выбрать в первую очередь и почему”. Вы не только просите пошаговый анализ, но и даёте структуру этого анализа. Это уже более строгий CoT.

Третья формулировка – “сначала сформулируй критерии, затем выбери…”. Это особенно мощный приём. Он заставляет модель сначала зафиксировать “правила игры”, а уже потом совершать выбор по этим правилам. Например: “Сначала сформулируйте критерии, по которым следует выбирать маркетинговые каналы для нашего финтех‑приложения с ограниченным бюджетом. Затем, используя только эти критерии, выберите 3 приоритетных канала и объясните, как каждый из них удовлетворяет сформулированным критериям”. Здесь вы вводите важный принцип: модель не просто выбирает что‑то “из головы”, а якобы опирается на явные критерии, отражённые в тексте.

Ваше практическое задание в этой главе состоит из двух частей.

Сначала возьмите задачу с несколькими ограничениями. Хороший пример – тот же выбор маркетинговой стратегии с бюджетными лимитами. Сформулируйте простой промт без Chain‑of‑Thought: дайте модели описание продукта, аудитории, бюджета и попросите “предложить маркетинговую стратегию”. Получите ответ и сохраните его. Затем перепишите промт, добавив явное требование мыслить поэтапно: опишите, какие шаги вы хотите видеть – анализ, критерии, набор вариантов, оценка, итоговое решение. Получите второй ответ. Сравните их не глазами “понравилось – не понравилось”, а с точки зрения логики: где модель лучше учитывает ограничения, где яснее приоритизирует, где меньше внутренних противоречий.

Во второй части задания придумайте три собственные формулировки CoT, которые вы будете использовать в работе. Например, одна – в стиле “подумайте как [роль] и по шагам разберите…”, вторая – “пошагово проанализируйте…”, третья – “сначала сформулируйте критерии, затем выберите…”. Протестируйте их на разных задачах: не только в маркетинге, но и, скажем, в продуктовой аналитике, планировании обучения, выборе архитектуры решения. Сравните, как разные фразы влияют на структуру ответа.

Когда вы сделаете эти упражнения сознательно несколько раз, у вас появится важный навык: вы перестанете ждать от модели “чуда”, и начнёте задавать ей не только вопрос, но и траекторию мышления. Это то, что отличает пользователя от промт‑инженера, который умеет управлять глубиной и качеством ответа за счёт правильной организации цепочки рассуждений. В следующих главах мы будем развивать этот навык до полноценного проектирования цепочек промтов, где каждый шаг – отдельный запрос, но без внутреннего Chain‑of‑Thought двигаться туда бессмысленно.

ГЛАВА 4. FEW‑SHOT, МНОГОПРИМЕРНОЕ ОБУЧЕНИЕ В ПРОМТАХ

К этому моменту вы уже умеете задавать роли, строить структуру промта и заставлять модель думать по шагам. Следующий уровень – научиться “дообучать” модель прямо внутри промта с помощью примеров. Без кода, без датасетов, без сложных пайплайнов. Только вы, модель и грамотно подобранные образцы.

В машинном обучении обычно говорят о трёх режимах: zero‑shot, one‑shot и few‑shot. Эти термины важны и для промт‑инженера, потому что напрямую описывают, как вы будете объяснять задачу модели.

Zero‑shot – это когда вы формулируете задачу только словами, без единого примера. Вы описываете, что нужно сделать, даёте контекст, ограничения, критерии качества, но не показываете ни одного образца “правильного” входа и выхода. Модель опирается исключительно на свой предыдущий опыт обучения и общие знания о похожих задачах. В этом режиме она часто выдаёт что‑то разумное, но не всегда соответствует вашим внутренним стандартам.

One‑shot – когда вы даёте один пример выполнения задачи. Вы показываете модели пару “вход → желаемый выход” и просите по аналогии обрабатывать новые данные. Этот один пример уже сильно сужает пространство интерпретаций. Вы как будто говорите: “делай так, только для других случаев”.

Few‑shot – это когда вы даёте несколько (обычно от 2–3 до 5–10) примеров. Модель смотрит на них как на мини‑обучающую выборку внутри промта. Она пытается уловить закономерность: что общего у входов, что общего у выходов, как именно вы формулируете ответы, какая структура, какой уровень детализации. И уже на этой основе генерирует ответ для нового входа.

Ваше отличие как промт‑инженера в том, что вы перестаёте надеяться на zero‑shot там, где важна точность и единообразие. Вместо этого вы начинаете осознанно подбирать примеры: не просто “накидать что‑то”, а сформировать маленький, но показательный набор, который задаёт нужную логику.

Ключевой вопрос – как выбирать минимальное количество примеров, но самых сильных. Тут работает ровно та же логика, что и в обучении людей: лучше несколько тщательно отобранных кейсов, чем десятки случайных.

Во‑первых, примеры должны покрывать типичные, базовые случаи. Если вы обучаете модель классифицировать отзывы по тону, логично дать по одному‑двум понятным, “чистым” примерам для негативного, нейтрального и позитивного тонов. Без иронии, без двусмысленности, без сложных подтекстов. Пусть модель сначала поймёт ядро категорий.

Во‑вторых, примеры должны быть максимально близки по форме к реальным данным, с которыми вы будете работать. Если настоящие отзывы короткие, разговорные и с опечатками, нет смысла давать в примерах идеально вычитанные, литературные фразы. Модель будет ориентироваться на образец, а потом “удивляться” живому языку.

В‑третьих, вы должны следить за тем, чтобы примеры не противоречили друг другу по стилю и структуре вывода. Если вы в одном примере отвечаете “позитивный”, в другом – “тон: позитивный”, в третьем – “класс: POSITIVE”, вы даёте модели запутанный сигнал. Она попытается как‑то усреднить формат или начнёт хаотично прыгать между ними. Структура выхода во всех примерах должна быть одинаковой.

Отдельная задача – как строить примеры так, чтобы модель верно обобщала, а не привязывалась к случайным деталям. Вы всегда должны помнить: модель не “понимает” смысл как человек, она ловит статистические паттерны. Если во всех негативных примерах у вас встречается слово “ужасно”, модель может начать ассоциировать негатив только с этим словом и хуже справляться с другими формами негатива. Если во всех позитивных примерах вы пишете, что‑то про “рекомендую друзьям”, модель может переоценить важность именно этой фразы.

Поэтому ваши примеры должны быть разнообразными внутри каждой категории, но при этом придерживаться общей логики. Для тональности: одни негативные отзывы могут быть грубыми, другие – холодно‑формальными, третьи – разочарованно‑спокойными, но все они должны очевидно туда относиться. Позитив может быть восторженным, сдержанным, благодарственным. Нейтральные – информационными, сухими, без эмоциональной окраски. Вы как куратор данных решаете, что считать “очевидным” представителем класса.

Теперь перейдём к конкретной задаче и практике.

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

Сначала вы делаете zero‑shot промт. Опишите задачу словами, без примеров. Допустим, вы просите: “Определите тон пользовательского отзыва: негативный, нейтральный или позитивный. В ответе укажите только одно слово: ‘негативный’, ‘нейтральный’ или ‘позитивный’.” Затем подаёте модели реальные отзывы и смотрите на её поведение.

На этом этапе вы быстро увидите типичную картину. В простых случаях модель попадает в нужный тон: откровенный негатив она называет негативом, однозначный позитив – позитивом. Но возникают ошибки на границе: в отзывах с лёгкой иронией, смешанными эмоциями, конструктивной критикой с благодарностью. Например, фраза “Приложение удобное, но баги уже достали” может быть классифицирована как нейтральная или даже позитивная, тогда как для ваших целей это, возможно, негатив: человек жалуется на баги. Или наоборот: “Поддержка ответила с задержкой, но в итоге всё решилось, спасибо” – модель может увести в негатив из‑за слова “задержкой”, хотя общий тон вы считаете скорее позитивным или смешанным.

Теперь вы переходите к few‑shot. В тот же промт вы добавляете несколько carefully picked примеров. Скажем, 3–5 пар “отзыв → правильная метка”. Вы не случайно берёте первые попавшиеся, а отбираете такие, которые:

очень чётко иллюстрируют каждую категорию;

покрывают типичные пограничные случаи;

явно демонстрируют, как вы хотите интерпретировать смешанные формулировки.

Например, вы можете взять один откровенно негативный отзыв (“Поддержка не отвечает, деньги зависли, очень недоволен”), один однозначно позитивный (“Отличное приложение, пользуюсь каждый день, всё удобно”), один нейтральный (“Установил вчера, пока разбираюсь, ничего особенного сказать не могу”), плюс два сложных: мягкая критика и смешанный тон, и явно указать, к каким классам вы их относите. Этими примерами вы как бы устанавливаете правила игры: “Вот это считается негативом, даже если есть благодарность”, “Вот это – позитив, даже если были мелкие неудобства”.

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

Дальше вы сравниваете точность zero‑shot и few‑shot. Вполне вероятно, что в простых случаях разницы почти не будет. Но именно на пограничных, сложных отзывах few‑shot начнёт выигрывать. Модель увидит, что вы относите “удобное приложение, но куча багов” к негативу, и начнёт чаще воспроизводить этот паттерн. Вы фактически “учите” её вашей внутренней политике интерпретации.

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

Контрпример – это специально выбранный сложный случай, который проверяет устойчивость вашей схемы. В нашей задаче это может быть отзыв с сарказмом или смешанным тоном. Например: “О, ещё одно ‘суперудобное’ обновление, после которого приложение вообще не открывается. Браво.” С точки зрения лексики здесь есть слова, которые могли бы намекать на позитив (“суперудобное”, “браво”), но общий смысл – откровенный негатив.

Ваша задача – включить один такой контрпример в набор примеров few‑shot и посмотреть, что произойдёт с остальными ответами. Если вы просто добавите его как “негативный”, модель может начать резче реагировать на сарказм – это хорошо. Но иногда один плохо сформулированный контрпример способен “сломать” баланс: модель начнёт видеть негатив там, где его нет, или, наоборот, станет слишком осторожной.

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

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

Смысл этого упражнения в том, чтобы вы на практике почувствовали хрупкость и силу few‑shot. Небольшой набор примеров может радикально улучшить поведение модели, но также легко может ввести систематическую ошибку, если примеры подобраны невнимательно.

Few‑shot‑промты – это по сути микро‑обучающие выборки, которые вы строите вручную. Вы выступаете в роли и заказчика, и дата‑сайентиста, и учителя. Вы решаете, какие паттерны нужно закрепить, а какие – нет. И чем осознаннее вы это делаете, тем ближе ваш промт становится к настоящей модели “под задачу”, только построенной не кодом, а текстом.

Когда вы несколько раз пройдёте полный цикл – zero‑shot → few‑shot с примерами → оценка точности → добавление контрпримера → корректировка формулировок – у вас появится новый тип мышления. Вы перестанете воспринимать промт как разовую команду и начнёте видеть в нём маленький обучающий набор. А это уже серьёзный шаг до “продвинутого пользователя”, а то и настоящему промт‑инженеру, который может подстраивать поведение модели под конкретные бизнес‑задачи и критерии.

ГЛАВА 5. PROMPT CHAINING: СЛОЖНЫЕ ЗАДАЧИ ЧЕРЕЗ ЦЕПОЧКИ ПРОМТОВ

В какой‑то момент вы упираетесь в естественный предел: даже самый сильный, тщательно прописанный промт перестаёт вытягивать сложные задачи “за один присест”. Вы просите модель: “Разработай полноценный курс, продумай структуру, напиши материалы, придумай задания, сделай чек‑листы” – и получаете или поверхностную солянку, или перегруженный, плохо организованный текст. Проблема здесь не в модели и не в вас, а в самой постановке: вы пытаетесь решить многошаговую задачу одним запросом.

Сложные задачи в промт‑инжиниринге нужно разбивать на цепочки. Вы переходите от парадигмы “один запрос – один результат” к парадигме “пайплайн из шагов”. Каждый шаг решает узкую, чётко ограниченную подзадачу, а его результат становится входом для следующего шага. Это и есть prompt chaining – работа с цепочками промтов.

Разбивка задачи на этапы начинается с того, что вы сами, как человек, проговариваете: каким естественным образом вы бы решали эту задачу без модели. Если вам нужно, например, создать мини‑курс, вы не садитесь и сразу пишете конспекты. Сначала вы думаете, для кого курс, какие цели и исходный уровень. Потом составляете структуру: какие уроки, в каком порядке, с какой логикой прогрессии. Потом уже превращаете структуру в детальные конспекты, позже – в задания, затем – в вспомогательные материалы, чек‑листы, критерии успеха. То же самое вы перекладываете в мир промтов.

В цепочном подходе каждый промт должен быть максимально “узким” и целевым. Ошибка многих пользователей в том, что они делают промежуточные шаги слишком общими и расплывчатыми. В результате каждый шаг превращается в мини‑хаос, и качество итогового решения страдает. Ваша задача – превращать каждый шаг в точную микрозадачу: “только проанализируй аудиторию”, “только предложи структуру”, “только детализируй этот урок”.

Удобная метафора – три типа промтов в цепочке: фильтры, сумматоры и проверяющие.

Промты‑фильтры отбрасывают лишнее и выбирают главное. Они берут необработанный материал – идеи, сырые данные, разрозненные мысли – и превращают их в очищенный, отфильтрованный набор. Например, вы генерируете много идей уроков, а затем отдельным промтом просите: “выбери только те, которые подходят для начинающих”, или “оставь только 5 самых важных тем, убрав дубли и слишком узкие”.

Промты‑сумматоры собирают воедино результаты нескольких шагов. Они берут, например, резюме по целевой аудитории, список проблем, список тем и превращают это в целостную структуру курса. Или берут конспекты всех уроков и делают из них общий план программы, аннотацию, рекламное описание. Сумматор объединяет и упорядочивает.

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

Из этих элементов вы можете собирать пайплайны разной сложности. Один из базовых шаблонов для контентных задач – это последовательность: Анализ → Идеи → Структура → Черновик → Редактура → Проверка фактов.

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

На этапе Идей вы просите модель накидать варианты: возможные темы, подходы, форматы, углы подачи. Здесь полезно давать широкий разброс и не пытаться сразу отфильтровать всё. Это пространство вариантов.

На этапе Структуры вы превращаете хаотичный набор идей в организованную последовательность. Вы просите модель: “исходя из целей и характеристик целевой аудитории, собери линейную структуру из 5–7 блоков”, или “сгруппируй идеи по смысловым модулям и выстрой из них логичный маршрут от простого к сложному”.

Черновик – это уже плотная генерация текста: конспекты уроков, сценарии, описания. Здесь вы опираетесь на утверждённую структуру и параметры аудитории, подавая их в качестве контекста.

Редактура – отдельный шаг, где вы просите модель улучшить уже написанный текст: упростить, сделать более живым, убрать повторы, подстроить под выбранный тон и формат. Этот шаг часто недооценивают, но именно он даёт текстам “человеческий” вид.

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

Теперь переведём это в практику на конкретном кейсе: “Создать мини‑курс из 5 уроков по теме X”. Ваша задача – не решить всё в одном запросе, а выстроить цепочку из пяти промтов.

Первый промт: анализ целевой аудитории и целей. Здесь вы задаёте модели роль и просите её глубоко разобраться, для кого вы делаете курс и зачем. Вы даёте краткое описание предполагаемой аудитории (например, “начинающие маркетологи”, “предприниматели без технического образования”, “разработчики, которые впервые сталкиваются с ML”) и задаёте вопросы: какой у них стартовый уровень, какие у них боли, чего они хотят достичь после курса, сколько времени готовы вкладывать, какие форматы им комфортны. В ответ вы хотите получить портрет ЦА, список целей, список ограничений и предпочтений. Этот ответ вы потом будете использовать как контекст для следующих шагов.

Второй промт: структура курса. Теперь вы подаёте в промт результаты анализа аудитории и целей (либо целиком, либо в виде краткого резюме) и просите модель предложить структуру мини‑курса из 5 уроков. Задача – выстроить путь от стартового уровня к целям, которые вы зафиксировали на первом шаге. Вы уточняете формат: каждому уроку нужен заголовок, краткое описание, ключевые результаты, которые ученик должен получить. На этом этапе вы не просите расписывать детали уроков, только каркас.

Третий промт: детальные конспекты. Вы берёте утверждённую структуру (можете при необходимости вручную её подправить, а затем “заморозить”) и подаёте её в новый промт. Задача этого шага – для каждого урока создать подробный конспект: основные тезисы, объяснения, примеры, возможно, мини‑кейсы или демонстрации. Вы явно указываете уровень глубины: сколько времени ученик должен потратить на урок, какого типа объяснения вы считаете подходящими для этой аудитории, сколько примеров нужно. Важно, что вы жёстко ограничиваете модель рамками уже определённой структуры, чтобы она не начинала на ходу менять количество уроков или темы.

Четвёртый промт: задания к урокам. Теперь, опираясь на готовые конспекты, вы просите модель разработать практику: упражнения, вопросы для самопроверки, небольшие задания. Для каждого урока нужны задания разного уровня – от проверки понимания базовых понятий до простых мини‑проектов или задач на применение. Важно сразу определить формат: тесты, открытые вопросы, практические задачи. Вы можете дополнительно указать критерии оценки: какие ответы считаются удачными, где типичные ошибки, что именно ученик должен уметь после выполнения.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.