На предыдущем уровне вы увидели, как модель думает в токенах, как на неё влияют температура и контекстное окно. Теперь нам нужно перейти от “понимать модель” к “управлять моделью”. И здесь всё начинается со структуры промта.
Почти все слабые промты выглядят одинаково: короткая, размытая просьба без роли, без цели, без ограничений и без примеров. Пример: «Напиши текст для сайта о юридических услугах». Такие запросы живут в иллюзии: “модель же умная, она должна сама догадаться, что мне нужно”. На практике вы получаете в ответ шаблонный, безликий текст, похожий на тысячу других.
Сильный промт – это маленький технический документ. В нём есть роль, чёткая инструкция, контекст, ограничения и примеры. Как только вы начинаете писать промты в этом формате, качество ответов прыгает на другую высоту, и это не магия, а просто грамотное описание задачи.
Прежде всего вам нужно научиться задавать роли и персону модели. У модели нет “истинного” характера: то, как она с вами общается, определяется тем, какую роль вы ей задали, и насколько последовательно вы её удерживаете. Вы можете обращаться к модели как к юристу, как к маркетологу, как к редактору, как к преподавателю. Вы можете задавать стиль – строгий, ироничный, разговорный, академический.
Роль – это не украшение текста промта, а управляющий параметр. Если вы пишете: “вы – опытный маркетолог, который специализируется на 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, вы сделаете ещё один шаг к тому, чтобы ваши промты перестали быть “пожеланиями” и стали настоящими техническими заданиями для модели. В следующих главах мы начнём строить цепочки промтов и учиться заставлять модель рассуждать по шагам, но всё это опирается на фундамент: чётко заданная роль, ясная инструкция, понятный контекст, жёсткие ограничения и хорошие примеры.