Как формулировать запросы и превращать идеи в понятные тексты

Курс помогает научиться ясно выражать мысль, формулировать запросы (в том числе к ИИ) и структурировать информацию. Подходит тем, кто часто «не знает, как правильно написать» и хочет получать точные результаты.

1. Определяем цель: что именно вы хотите получить

Определяем цель: что именно вы хотите получить

Когда вы пишете запрос (к человеку, команде или ИИ), вы фактически даёте техническое задание на текст. Если цель не определена, текст почти всегда получается «не тот»: длинный вместо короткого, умный вместо понятного, красивый вместо полезного.

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

!Воронка превращения идеи в точный запрос и предсказуемый результат

Почему сначала цель, а не формулировки

Обычно люди начинают с формулировок: «напиши красиво», «сделай продающе», «перепиши поумнее». Но это описывает манеру, а не результат.

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

Что такое цель в контексте текста

Цель полезно фиксировать на трёх уровнях:

  • Результат (артефакт): что именно вы хотите получить как объект.
  • Эффект: что должно произойти после чтения.
  • Условия: ограничения и требования, без которых результат не подходит.
  • Пример различия:

  • Результат: «инструкция на 1 страницу»
  • Эффект: «чтобы новичок смог выполнить настройку без вопросов»
  • Условия: «без профессионального жаргона, с нумерованными шагами, с разделом “Если не получилось”»
  • Пять вопросов, которые проясняют цель

    Если вы теряетесь, ответьте на эти вопросы (коротко, в черновике):

  • Что нужно получить на выходе? (статья, письмо, план, конспект, скрипт, пост, FAQ)
  • Для кого текст? (кто читатель и какой у него уровень знаний)
  • Зачем этот текст нужен? (какое действие/решение должен совершить читатель)
  • В каком контексте это будет читаться? (почта, сайт, чат, презентация, внутренний документ)
  • По каким признакам вы поймёте, что получилось хорошо? (критерии приемки)
  • Если после ответов всё ещё «размыто», почти всегда не хватает пункта 2 или 3: аудитории или эффекта.

    Уточняем результат: какой именно артефакт вам нужен

    Один и тот же смысл можно оформить десятками способов. Поэтому полезно явно назвать тип результата и его параметры.

    Параметры результата

    | Параметр | Варианты | Пример формулировки | |---|---|---| | Тип | письмо, пост, инструкция, лендинг, план, тезисы | «Сделай письмо клиенту» | | Объём | в знаках, в словах, в минутах чтения, «до N пунктов» | «До 1200 знаков» | | Структура | списки, шаги, блоки, Q&A, таблица | «Нумерованные шаги + блок “Ошибки”» | | Тон | нейтральный, дружелюбный, официальный, уверенный | «Официально, без канцелярита» | | Уровень сложности | для новичка, для специалиста | «Как для человека без опыта» | | Язык и термины | можно/нельзя использовать термины | «Без англицизмов, термины объяснять» |

    Важно: параметры не заменяют цель, а фиксируют форму результата.

    Критерии успешности: как понять, что цель достигнута

    Чтобы текст можно было «принять», нужны критерии. Это не про придирки, а про ясность.

    Хорошие критерии:

  • Проверяемые (их можно сравнить с текстом)
  • Связанные с задачей (они помогают получить эффект)
  • Короткие (5–7 пунктов обычно достаточно)
  • Примеры критериев:

  • «В начале — 2–3 предложения: что это и кому подходит»
  • «Каждый раздел заканчивается выводом в 1 строку»
  • «Не более 3 терминов без объяснения»
  • «Есть конкретный призыв к действию и один следующий шаг»
  • Если хотите опереться на известную рамку постановки целей, используйте SMART как подсказку, но не как бюрократию: SMART criteria.

    Формула цели в одном предложении

    Если вам нужно быстро привести мысли в порядок, соберите цель в одно предложение:

    Сделать [какой результат] для [какой аудитории] чтобы [какой эффект/действие]. Условия: [ограничения и критерии].

    Пример:

    > Сделать короткую инструкцию для новых сотрудников, чтобы они смогли настроить рабочую почту самостоятельно. Условия: до 1 страницы, нумерованные шаги, без терминов, добавить раздел «Если возникла ошибка».

    Такое предложение уже почти готово к превращению в полноценный запрос.

    Превращаем «идею» в цель: примеры

    | Было (идея/пожелание) | Стало (цель) | |---|---| | «Напиши пост про наш продукт» | «Сделать пост для подписчиков, которые нас не знают, чтобы они поняли пользу и перешли на сайт. Условия: 1200–1500 знаков, 3 преимущества, 1 кейс, CTA в конце.» | | «Сделай текст на лендинг, чтобы продавал» | «Сделать первый экран и блок “Как это работает” для лендинга, чтобы посетитель оставил заявку. Условия: без громких обещаний, ясные выгоды, 1 форма, 5–7 буллетов.» | | «Объясни это нормально» | «Переписать объяснение для новичка, чтобы он мог повторить действие по шагам. Условия: короткие предложения, примеры, чек-лист в конце.» |

    Обратите внимание: в хорошей цели всегда есть кто, что и зачем, а требования к стилю идут как условия.

    Частые ошибки при постановке цели

  • Подмена цели стилем: «сделай красиво» вместо «чтобы читатель сделал X».
  • Слишком общий результат: «текст про компанию» без формата и аудитории.
  • Несовместимые условия: «очень коротко» и «с максимальной детализацией» одновременно.
  • Отсутствие критерия приемки: потом сложно объяснить, что именно «не так».
  • Не указан контекст: текст для письма и для лендинга устроен по-разному.
  • Итог

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

    2. Структура запроса: контекст, требования, ограничения, формат

    Структура запроса: контекст, требования, ограничения, формат

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

    Эта статья даёт рабочую структуру запроса из четырёх блоков:

  • Контекст (что происходит и почему это важно)
  • Требования (что обязательно должно быть в результате)
  • Ограничения (что нельзя и какие рамки нельзя нарушать)
  • Формат (как именно вернуть результат)
  • !Схема показывает, как цель превращается в понятный запрос через 4 обязательных блока.

    Зачем вообще нужна структура

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

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

    Блок «Контекст»

    Контекст отвечает на вопрос: в каком мире живёт этот текст.

    Хороший контекст обычно включает:

  • кто вы и что за продукт/ситуация;
  • кто читатель и что он уже знает;
  • где будет опубликовано/использовано;
  • какие обстоятельства важны (сроки, чувствительность темы, конфликт, история переписки).
  • Как писать контекст

  • Дайте 2–5 фактов, без которых текст будет неправильным.
  • Укажите аудиторию не в общем виде, а через состояние читателя.
  • Добавьте примеры исходных данных, если они есть (тезисы, сырой текст, ссылки, цифры).
  • Пример контекста:

    > Мы запускаем онлайн-курс для новичков в дизайне. Текст нужен на страницу оплаты. Читатель — человек без опыта, сомневается, стоит ли начинать. Страница читается с телефона, времени на чтение мало.

    Блок «Требования»

    Требования — это то, без чего результат нельзя принять. Здесь вы описываете содержательные обязательства.

    Чтобы требования были однозначными, полезно формулировать их как проверяемые пункты. В инженерной среде для этого используют строгие модальные слова (например, MUST, SHOULD) — см. RFC 2119. В текстах можно делать то же самое, но простым русским языком: «обязательно», «должно быть», «нужно добавить».

    Типовые категории требований

  • Смысл: какие мысли обязаны быть отражены.
  • Структура: какие блоки обязательно должны присутствовать.
  • Доказательность: какие факты, примеры, цифры нужно использовать.
  • Действие: какой призыв к действию должен быть в конце.
  • Как писать требования

  • Начинайте с обязательных блоков (что точно должно быть включено).
  • Затем уточняйте, что именно должно быть внутри каждого блока.
  • Если важны факты/цифры — дайте их сразу, чтобы их не «придумывали».
  • Пример требований:

  • В начале: 2–3 предложения, что это за курс и кому он подойдёт.
  • Дальше: 3 выгоды в формате буллетов.
  • Добавить 1 мини-кейс (до 4 предложений): «было → стало».
  • В конце: один чёткий CTA — «Оплатить участие».
  • Блок «Ограничения»

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

    Ограничения бывают двух типов:

  • Жёсткие (нельзя нарушать): «не упоминать цены конкурентов», «не обещать гарантированный результат».
  • Рамочные (держать в пределах): объём, сложность языка, количество терминов.
  • Что часто стоит ограничивать заранее

  • Объём: знаки/слова/абзацы.
  • Тон: «дружелюбно, но без панибратства».
  • Язык: без жаргона, объяснять термины.
  • Риски: не давать медицинских/юридических советов, не использовать дисклеймеры “мелким шрифтом”, не делать неподтверждённых обещаний.
  • Запреты: что точно не писать (темы, формулировки, сравнения).
  • Полезный ориентир по ясности языка: принципы plain languagePlainLanguage.gov.

    Как писать ограничения

  • Выпишите 3–7 самых опасных «провалов», которые случались раньше.
  • Переформулируйте их в запреты или лимиты.
  • Если есть чувствительные слова/темы — дайте чёрный список.
  • Пример ограничений:

  • До 1200 знаков без пробелов.
  • Без слов: «лучший», «гарантируем», «уникальный».
  • Не использовать англицизмы. Если термин нужен — объяснить в скобках.
  • Не давить на страх, без манипуляций.
  • Блок «Формат»

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

    Сюда относятся:

  • структура ответа (заголовки, списки, таблица, Q&A);
  • оформление (markdown/без markdown, эмодзи/без, обращение на «вы»);
  • варианты (1 версия или 3 версии на выбор);
  • дополнительные артефакты (план, краткий конспект, идеи заголовков).
  • Как писать формат

  • Укажите носитель: пост/письмо/лендинг/скрипт/FAQ.
  • Задайте структуру (блоки в нужном порядке).
  • Укажите, что должно быть в конце (CTA, чек-лист, резюме).
  • Пример формата:

  • Верни результат в виде:
  • 1. Вариант A — нейтральный тон. 2. Вариант B — более энергичный тон.
  • Каждый вариант:
  • 1. Заголовок (до 60 знаков). 2. Лид (2 предложения). 3. Буллеты (3 пункта). 4. CTA (1 строка).

    Собираем запрос целиком: шаблон

    Ниже шаблон, который можно копировать и заполнять.

    Важно: если у вас уже хорошо сформулирована цель (из прошлой статьи), этот шаблон превращает её в понятное ТЗ на текст.

    Примеры: одна и та же цель — разные форматы

    Пример запроса для письма клиенту

    Цель: написать письмо клиенту, чтобы согласовать перенос сроков без конфликта.

    Контекст: задержка из‑за поставщика; клиент уже раздражён; переписка официальная.

    Требования:

  • Признать задержку и взять ответственность за коммуникацию.
  • Предложить 2 альтернативных срока.
  • Дать компенсацию (скидка 5% или бесплатная доставка).
  • Завершить вопросом, какой вариант выбирают.
  • Ограничения:

  • Без оправданий и обвинений поставщика.
  • Без эмоциональных формулировок.
  • До 1200 знаков.
  • Формат:

  • Тема письма.
  • Текст письма.
  • PS с коротким резюме в 1 строку.
  • Пример запроса для инструкции

    Цель: сделать инструкцию для новичка, чтобы он настроил двухфакторную аутентификацию.

    Контекст: внутренний документ; читатель не технический; инструкция будет в базе знаний.

    Требования:

  • Пошаговая последовательность.
  • На каждом шаге: что нажать и что должно получиться.
  • Раздел «Если не получилось» с 3 типовыми проблемами.
  • Ограничения:

  • Без терминов без объяснения.
  • Не ссылаться на «как на скриншоте» (скриншотов нет).
  • Формат:

  • Заголовок.
  • Время выполнения (оценка).
  • Нумерованные шаги.
  • Блок «Если не получилось».
  • Частые ошибки

  • Контекст подменяют оценками: «сделай хорошо» вместо фактов о ситуации.
  • Требования смешивают с ограничениями: «добавь три пункта» и «не больше трёх пунктов» в одном месте, без приоритета.
  • Ограничения формулируют слишком абстрактно: «без воды» вместо измеримых рамок.
  • Формат не указывают — и получают правильный смысл в неудобной упаковке.
  • Мини-чеклист перед отправкой запроса

  • Контекст даёт исполнителю достаточно фактов, чтобы не угадывать?
  • Требования можно проверить по готовому тексту?
  • Ограничения защищают от главных рисков (объём, тон, запреты)?
  • Формат позволяет сразу вставить результат туда, где он будет жить?
  • Итог

    Цель задаёт направление, а структура запроса делает результат воспроизводимым. Используйте четыре блока — контекст, требования, ограничения, формат — и ваши идеи будут превращаться в понятные тексты без бесконечных уточнений и переделок.

    3. Ясность языка: точные слова вместо общих формулировок

    Ясность языка: точные слова вместо общих формулировок

    В первых двух статьях курса мы разобрали:

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

    Эта статья — про ясность языка: как заменять общие формулировки на точные, чтобы результат можно было проверить и принять.

    !Схема показывает переход от размытых пожеланий к проверяемым требованиям

    Что такое «общие формулировки» и почему они ломают запрос

    Общая формулировка — это слово или фраза, которые:

  • не описывают наблюдаемый результат
  • не задают критерий проверки
  • допускают много интерпретаций
  • Типичные примеры: «сделай нормально», «повысь качество», «напиши цепляюще», «убери воду», «сделай короче, но чтобы всё было».

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

    Признаки точной формулировки

    Точная формулировка отвечает хотя бы на один из вопросов:

  • что именно должно появиться в тексте (какие блоки, какие тезисы)
  • что должен понять или сделать читатель (эффект)
  • как это выглядит на поверхности (объём, структура, тон, примеры)
  • как проверить, что сделано правильно (критерии приемки)
  • Чем больше таких ответов, тем меньше «магии» и переделок.

    Заменяем оценку на наблюдение: таблица переводов

    | Общее слово | Что в нём неопределённо | Как переформулировать, чтобы стало проверяемо | |---|---|---| | «Понятно» | для кого понятно и по каким признакам | «Для новичка: без терминов без объяснения, каждое действие описано шагом, в конце чек-лист» | | «Коротко» | насколько коротко и что можно убрать | «До 900 знаков, 1 абзац + 3 буллета, без предыстории» | | «Без воды» | что считать “водой” | «Убрать общие фразы, оставить только: проблема, решение, 3 факта, 1 следующий шаг» | | «Продающе» | какая модель убеждения и какое действие нужно | «Сфокусироваться на выгодах, добавить 1 кейс, в конце CTA “Оставить заявку”» | | «Дружелюбно» | где граница между дружелюбием и фамильярностью | «На “вы”, простые слова, без шуток и уменьшительно-ласкательных форм» | | «Экспертно» | какой уровень читателя и какая глубина нужна | «Для специалиста: добавить 3 термина с определениями и 2 ссылки на источники, без упрощений» |

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

    Три техники, которые быстро повышают ясность

    Уточняйте «кто читатель» через состояние, а не ярлык

    Фразы вроде «для клиентов» или «для пользователей» слишком широкие. Полезнее описывать состояние читателя.

    Сравните:

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

    Используйте критерии вместо прилагательных

    Прилагательные часто маскируют отсутствие критерия.

  • «Сделай текст сильнее»
  • «Сделай так, чтобы в первом абзаце была главная выгода, далее 3 буллета с фактами, в конце один CTA»
  • Критерий — это то, что можно сверить с готовым текстом.

    Добавляйте примеры и антипримеры

    Если вы боитесь, что вас поймут не так, самый короткий путь — показать.

  • Пример: «как должно звучать» (1–2 предложения)
  • Антипример: «как точно не надо» (1–2 предложения)
  • Важно: примеры лучше давать как ориентир, а не как единственно допустимый текст.

    Как встроить ясность языка в структуру запроса

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

    Контекст: только факты, которые меняют текст

    Плохой контекст:

  • «Ситуация сложная, клиент токсичный»
  • Хороший контекст:

  • «Клиент писал 3 раза за неделю, требует ответ в течение суток, не принимает общие объяснения, просит конкретные даты»
  • Факты помогают не угадывать.

    Требования: формулируйте как «должно быть в тексте»

    Хорошие требования можно проверить глазами.

  • «Обязательно: 3 причины задержки в нейтральных формулировках»
  • «Обязательно: 2 варианта нового срока»
  • «Обязательно: вопрос в конце, какой вариант выбирают»
  • Если хотите сделать требования максимально однозначными, используйте модальные слова из инженерной практики: RFC 2119.

    Ограничения: убирайте рискованные слова заранее

    Ограничения — место, где особенно важно точное перечисление.

    Вместо:

  • «не манипулировать»
  • Лучше:

  • «не давить на страх (“иначе вы потеряете…”), не стыдить, не использовать капслок и множественные восклицательные знаки»
  • Формат: зафиксируйте упаковку результата

    Вместо:

  • «Сделай пост»
  • Лучше:

  • «Заголовок до 60 знаков, лид 2 предложения, 3 буллета, один CTA, без хэштегов»
  • Формат — это способ сразу сделать результат пригодным к использованию.

    Мини-алгоритм: как редактировать свой запрос на ясность

  • Выпишите свой запрос в одном абзаце.
  • Подчеркните все слова-оценки.
  • Для каждого слова-оценки ответьте на вопрос: «Как я пойму, что это выполнено?».
  • Замените оценку на критерий или наблюдаемое свойство.
  • Добавьте один пример или антипример там, где риск непонимания самый высокий.
  • Обычно уже после шага 4 запрос становится заметно сильнее.

    Частые ловушки

    «Слишком общо» маскируется под профессиональные слова

    Слова вроде «оптимизировать», «усилить», «повысить вовлечённость» звучат делово, но часто не дают понятных инструкций.

    Полезная замена:

  • что именно изменить в тексте
  • по какому принципу
  • какой ожидаемый эффект
  • Точность не равна перегрузке

    Ясность — не про длинные ТЗ. Часто достаточно 5–7 чётких пунктов.

    Если хочется добавить ещё 20 требований, проверьте: это точно обязательное, или просто «было бы неплохо».

    Нельзя требовать несовместимое

    Типовой конфликт:

  • «до 700 знаков»
  • «с подробными объяснениями и примерами»
  • Если требования конфликтуют, явно расставьте приоритеты.

    Чек-лист перед отправкой запроса

  • Есть ли в запросе слова «красиво», «нормально», «качественно», «понятно», «цепляюще» без расшифровки?
  • Указано ли, для кого текст и в каком состоянии читатель?
  • Требования можно проверить по готовому тексту?
  • Ограничения перечислены конкретно (слова, темы, обещания, объём)?
  • Формат выдачи задан так, чтобы результат можно было сразу использовать?
  • Итог

    Цель задаёт направление, структура запроса задаёт каркас, а ясность языка убирает неоднозначность. Заменяйте общие слова на критерии, наблюдаемые свойства и примеры — и ваши запросы начнут давать предсказуемые, «принимаемые» тексты с меньшим числом итераций.

    Если нужен ориентир по простому и ясному языку в целом, полезно посмотреть принципы: PlainLanguage.gov.

    4. Примеры и критерии качества: как задавать ожидания

    Примеры и критерии качества: как задавать ожидания

    В предыдущих статьях курса вы разобрали:

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

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

    Зачем нужны критерии качества

    Даже хорошо структурированный запрос может давать разные результаты, если у вас и у исполнителя разные представления о том, что такое:

  • понятно
  • достаточно подробно
  • убедительно
  • аккуратно
  • Критерии качества решают три задачи:

  • убирают угадывание
  • ускоряют согласование
  • уменьшают число итераций
  • Если цель отвечает на вопрос зачем, то критерии отвечают на вопрос как вы поймёте, что получилось правильно.

    Что такое критерии качества в тексте

    Критерий качества — это проверяемое требование к результату.

  • Плохой критерий: сделай сильнее
  • Хороший критерий: в первом абзаце — главная выгода в 1–2 предложениях; далее 3 буллета с фактами; в конце один CTA
  • Хороший критерий почти всегда привязан к одному из трёх уровней:

  • поверхность текста (структура, объём, формат, тон)
  • смысл (какие мысли должны быть в тексте)
  • эффект (что читатель должен понять или сделать)
  • Признаки хороших критериев

    Критерий работает, если он:

  • проверяемый (можно сверить глазами)
  • однозначный (не требует интерпретации)
  • связанный с целью (помогает получить нужный эффект)
  • короткий (обычно хватает 5–9 критериев)
  • Удобная проверка: если критерий нельзя превратить в вопрос да/нет или в понятную проверку, он обычно слишком общий.

    Где в запросе живут критерии

    Критерии качества обычно распределяются по двум блокам из структуры запроса:

  • Требования: что должно быть, иначе результат не принимается
  • Ограничения: что нельзя, какие рамки нельзя нарушать
  • Формат тоже помогает, но он про упаковку: как вернуть результат, чтобы его можно было сразу использовать.

    Типы критериев качества

    Критерии по структуре

    Подходят, когда важна упаковка смысла.

  • есть заголовок и лид
  • есть список выгод
  • есть блок возражение → ответ
  • есть финальный следующий шаг
  • Критерии по содержанию

    Подходят, когда важно не потерять мысль.

  • в тексте явно названы 3 причины
  • использованы конкретные цифры и факты из вводных
  • есть пример применения в ситуации читателя
  • Критерии по ясности

    Подходят, когда нужно снизить риск непонимания.

  • термины объяснены в скобках
  • предложения до 20–25 слов
  • нет общих слов без уточнения (быстро, удобно, эффективно)
  • Критерии по тону и рискам

    Подходят для коммуникации с клиентами и публичных текстов.

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

    Критерии говорят что проверить, но не всегда показывают как это звучит. Поэтому примеры ускоряют понимание в разы.

    Есть два типа:

  • пример: 1–3 предложения, которые задают желаемую манеру
  • антипример: 1–3 предложения, которые показывают, как нельзя
  • Важно: пример — это не трафарет, который нужно копировать. Это ориентир, чтобы совпали ожидания.

    Как писать примеры безопасно

    Чтобы примеры не превратились в ловушку «перепиши вот это слово в слово», задавайте их так:

  • пример стиля, не текста целиком
  • 2–3 предложения максимум
  • пояснение, что именно в примере важно
  • Мини-рубрика: уровни качества вместо бесконечных правок

    Иногда вы хотите не просто принять/не принять, а выбрать лучший вариант. Тогда удобно задавать уровни:

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

    Пример рубрики для короткого поста:

  • минимум: понятный лид, 3 буллета, CTA
  • хорошо: один мини-кейс было → стало
  • отлично: один контраргумент и ответ на него
  • Алгоритм: как быстро сформулировать критерии и примеры

    Шаг

  • Выпишите цель одним предложением по формуле из первой статьи: сделать что для кого чтобы что произошло.
  • Назовите 3–5 рисков, которые чаще всего портят результат.
  • Переведите каждый риск в критерий или ограничение.
  • Добавьте 1 пример и 1 антипример для самого рискованного места.
  • Сверьте критерии с ограничениями: нет ли конфликтов по объёму, тону и детализации.
  • Таблица: из размытых ожиданий в проверяемые критерии

    | Размытое ожидание | Во что превращаем | Пример критерия | |---|---|---| | Сделай убедительно | эффект + структура | В начале — выгода, затем 3 аргумента с фактами, в конце — один следующий шаг | | Понятно | аудитория + ясность | Для новичка: без терминов без объяснения, шаги пронумерованы, в конце чек-лист | | Без воды | состав + запреты | Оставить только: проблема, решение, 3 факта, один CTA; убрать предысторию и общие фразы | | Аккуратно | тон + риск | Без категоричных оценок, без обвинений, без капслока и множественных восклицательных знаков |

    Примеры: как выглядят критерии в реальных задачах

    Письмо клиенту о переносе сроков

    Цель: согласовать перенос сроков без конфликта.

    Критерии (требования):

  • в первом абзаце признать перенос и назвать новую рамку по срокам
  • предложить 2 альтернативные даты
  • описать компенсацию в 1 строку
  • завершить вопросом, какой вариант выбирают
  • Ограничения:

  • без обвинений третьих лиц
  • без оправданий в стиле «обстоятельства сильнее нас»
  • без эмоциональных оценок
  • Пример (как звучит):

    > Переносим срок сдачи на 2 рабочих дня: новая дата — 14 февраля. Можем сделать передачу результата 14 февраля или 17 февраля, как вам удобнее.

    Антипример (как нельзя):

    > Мы не виноваты, поставщик опять подвёл, поэтому сроки сдвигаются. Надеемся на понимание.

    Инструкция для новичка

    Цель: чтобы новичок выполнил настройку без вопросов.

    Критерии (требования):

  • шаги пронумерованы
  • на каждом шаге есть действие и ожидаемый результат
  • есть блок Если не получилось с 3 типовыми ошибками
  • Ограничения:

  • без ссылок на скриншоты
  • термины объяснять в скобках
  • Пост для соцсетей про продукт

    Цель: чтобы человек, который нас не знает, понял пользу и перешёл по ссылке.

    Критерии (требования):

  • лид: что за продукт и для кого (2 предложения)
  • 3 буллета выгод, каждая в формате выгода + факт/пример
  • один CTA в конце
  • Ограничения:

  • без слов лучший, уникальный, гарантируем
  • без давления на страх
  • Шаблон: критерии и примеры внутри запроса

    Частые ошибки при задании критериев

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

    Критерии качества превращают запрос в проверяемое ТЗ: вы заранее фиксируете, по каким признакам принимаете результат. Примеры и антипримеры устраняют неоднозначность на уровне звучания.

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

    5. Итерации: как уточнять запрос и исправлять результат

    Итерации: как уточнять запрос и исправлять результат

    В предыдущих статьях курса вы собрали основу предсказуемого результата:

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

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

    !Диаграмма показывает, как улучшать результат через короткие контролируемые циклы

    Зачем итерации, если запрос уже “хороший”

    Причины обычно простые и нормальные:

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

    Минимальный цикл итерации

    Чтобы итерации не превращались в бесконечные правки, держите цикл коротким и одинаковым:

  • Сверка с целью
  • Сверка с критериями качества
  • Диагноз: что именно не так
  • Точечная правка запроса (в одном из 4 блоков: контекст, требования, ограничения, формат)
  • Новая версия с сохранением того, что уже получилось
  • Практическое правило: в каждой итерации меняйте 1–3 пункта, а не “всё сразу”. Так вы понимаете, что именно дало улучшение.

    Как проверять черновик: не “нравится/не нравится”, а “сходится/не сходится”

    Самая быстрая проверка — пройтись по чек-листу:

  • Цель: текст делает то, что нужно? (объясняет, убеждает, даёт шаги, снимает возражения)
  • Аудитория: звучит на языке читателя и учитывает его состояние?
  • Требования: всё обязательное на месте?
  • Ограничения: ничего запрещённого не появилось?
  • Формат: можно вставить “как есть” туда, где текст будет жить?
  • Если где-то “не сходится”, не спешите переписывать весь запрос. Сначала определите тип проблемы.

    Типовые “поломки” результата и как их чинить

    Ниже — карта диагностики: что вы видите в тексте и что, скорее всего, надо уточнить в запросе.

    | Что не так с результатом | Вероятная причина | Где чинить в запросе | Как сформулировать правку (пример) | |---|---|---|---| | Текст не про то / неправильный угол | не зафиксирован эффект, неверный контекст | контекст + цель | «Цель: не “рассказать”, а “чтобы читатель сделал X”. Контекст: читатель уже пробовал и разочаровался» | | Слишком общий, “вода” | нет требований к содержанию и доказательности | требования | «Обязательно: 3 тезиса, каждый с фактом/примером. Убрать общие фразы без данных» | | Нет важных блоков (CTA, шагов, возражений) | требования перечислены слишком расплывчато | требования + формат | «Структура: лид → 3 буллета выгод → блок “возражение→ответ” → CTA одной строкой» | | Не тот тон (слишком фамильярно/жёстко/продавливо) | ограничения по тону не заданы или заданы оценочно | ограничения + пример | «На “вы”, нейтрально. Без давления, без восклицаний. Пример тона: … Антипример: …» | | Слишком длинно/коротко | не задан объём или не расставлены приоритеты | ограничения + рубрика | «Лимит: до 1200 знаков. Приоритет: сохранить шаги и CTA, убрать предысторию» | | Появились выдуманные факты/цифры | не дан источник фактов и не запретили додумывать | контекст + ограничения | «Используй только факты из блока “Дано”. Если данных нет — пометь вопросом, не придумывай» | | Структура неудобна для вставки | не задан формат выдачи | формат | «Верни в markdown: заголовок, лид 2 предложения, далее список, затем CTA» |

    Как давать обратную связь так, чтобы следующая версия стала лучше

    Хорошая обратная связь:

  • опирается на цель и критерии, а не на вкусовые оценки
  • говорит что сохранить и что изменить
  • даёт конкретные правки уровня “добавь/убери/переставь/переформулируй”
  • Формула обратной связи

    Используйте шаблон (можно копировать):

    Пример обратной связи по делу

    > Что получилось (сохранить): хороший лид и ясные выгоды. > > Что не сходится с целью: текст должен привести к заявке, а сейчас заканчивается без следующего шага. > > Что не проходит критерии: > - нет CTA > - во втором буллете общая формулировка без факта > > Правки: > 1) Добавь CTA одной строкой в конце: “Оставить заявку на демо”. > 2) Во втором буллете — выгода + конкретика: срок, пример или цифра из вводных. > > Вопрос: какой минимальный срок внедрения мы обещаем (в днях)?

    Обратите внимание: здесь нет “сделай посильнее”. Есть проверяемые изменения.

    Итерация через вопросы: когда лучше не править, а уточнять

    Если вы видите, что результат “не попадает”, иногда причина — нехватка данных. Тогда эффективнее задать 3–7 уточняющих вопросов, чем просить переписать “как-нибудь иначе”.

    Какие вопросы задавать

  • про аудиторию: кто читатель и в каком он состоянии
  • про цель: какое действие нужно
  • про приоритеты: что важнее — краткость или полнота
  • про факты: какие данные можно использовать
  • про запреты: каких формулировок избегать
  • Шаблон запроса на уточнение

    Как не “сломать” удачные части при правках

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

    Рабочие приёмы:

  • Якоря: «Сохрани структуру и первый абзац, перепиши только буллеты 2–3»
  • Диапазон правок: «Меняем только тон и объём, смысловые тезисы оставляем»
  • Запрет на перегенерацию: «Не переписывай весь текст заново, внеси правки точечно»
  • Версионирование: «Версия 2: покажи изменения списком, затем полный текст»
  • Инструмент “рубрика”: как расставлять приоритеты и ускорять итерации

    Когда требований много, полезно ввести уровни качества (из статьи про критерии):

  • минимум: без этого нельзя принять
  • хорошо: заметно улучшает
  • отлично: добавлять только если влезает в объём
  • Пример рубрики для короткого письма:

  • минимум: признать ситуацию, предложить 2 варианта решения, задать вопрос в конце
  • хорошо: 1 строка компенсации
  • отлично: короткий блок “что сделаем, чтобы не повторилось” (если помещается)
  • С рубрикой итерации становятся проще: вы сначала добиваете минимум, а затем улучшаете.

    Шаблоны итераций под типовые задачи

    Когда текст слишком длинный

    Когда не хватает конкретики

    Когда тон “не тот”

    Когда результат “не в формате”

    Частые ошибки в итерациях

  • Правка оценками: «сделай лучше/сильнее» вместо конкретных критериев
  • Смена цели по ходу: в первой версии хотели объяснить, во второй — продать, в третьей — “и то и другое”
  • Много изменений сразу: невозможно понять, что помогло
  • Нет фиксации “что сохранить”: хорошие фрагменты исчезают
  • Новые факты появляются в тексте без источника: не запрещали додумывать и не дали “дано”
  • Мини-чеклист перед запуском версии 2

  • Сформулировано ли 1–3 точечных изменения?
  • Указано ли, что нужно сохранить?
  • Есть ли приоритеты (что важнее, если конфликтует)?
  • Есть ли вопросы по недостающим данным?
  • Понятен ли формат выдачи следующей версии?
  • Итог

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

    Так идеи превращаются в понятные тексты не “с первого раза”, а стабильно — за 1–2 коротких цикла без хаоса и бесконечных переделок.