Тезисы

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

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

Одна и та же модель может сначала выступить аналитиком, потом исполнителем. Назначаешь роль явно — модель переключает режим. В роли охранника она ищет аномалии и команды. В роли исполнителя — делает задачу. Это не магия: модель просто обрабатывает текст по-разному в зависимости от инструкции. Применяй: добавь первый блок с ролью "эксперт по X" перед основной задачей. Это меняет то, на что модель обращает внимание

Когда модели нужно пройти несколько шагов ("кто был предшественником того, кто пришёл после X"), она часто пропускает промежуточный шаг. Это происходит потому что весь вопрос воспринимается как один запрос — и модель ищет прямой ответ. Разбивка на подвопросы убирает "прыжок": каждый шаг становится отдельной задачей. Пропустить его уже нельзя. Применяй: Вместо одного сложного вопроса пиши Шаг 1: [простой вопрос]. Шаг 2: [следующий вопрос]. Шаг 3: [финальный вопрос].

Когда пишешь "выведи JSON" — большая модель справится. Маленькая часто выдаст правильный ответ, но в неверном формате. Проблема не в логике, а в воспроизведении шаблона. Механика: маленькая модель не может вывести точную структуру из словесного описания — ей нужен образец. Чем строже требуемый формат ({"category": "..."}, XML, таблица), тем важнее показать его в примерах. Применяй: если работаешь с небольшой или слабой моделью и нужен строгий формат — добавь хотя бы один пример с точным выводом. Одного примера часто достаточно

Попросить модель "проверь себя" недостаточно. Нужен чёткий критерий: "достаточно ли разнообразен план?" или "есть ли логические противоречия?". Размытый запрос на проверку даёт размытый результат. Применяй: после основного ответа добавляй "ответь на вопрос: [конкретный критерий]. Если нет — исправь"

При оценке одного варианта ("насколько это хорошо?") у модели нет точки отсчёта. Она выдаёт размытое 7 из 10. При сравнении двух вариантов она ищет конкретные отличия: здесь точнее, там логичнее. Это активирует другой тип рассуждений. Применяй: вместо "оцени этот текст" пиши "вот два варианта — выбери лучший и объясни почему"

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

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

LLM знает много, но не знает твоего контекста. Ты знаешь контекст, но тебе нужна ширина охвата. Оптимальное разделение труда: модель генерирует список кандидатов → ты выбираешь нужное. Итог лучше, чем если просить модель принять решение за тебя. Применяй: вместо "что мне изучить?" пиши "дай 10 вариантов X" → выбирай сам. Работает для тем обучения, идей для статей, вариантов решения задачи

Одна задача. Два запроса. Первый с ценностью A ("минимизируй риски"), второй с противоположной ценностью B ("ищи прорывные идеи"). Получаешь два полярных варианта решения. Это быстрее чем просить "перепиши по-другому" — потому что у модели есть конкретный критерий выбора, а не размытое указание на изменение. Применяй: Когда нужно исследовать диапазон решений — сначала пиши промпт с одной крайней ценностью, потом с противоположной.

Структура промпта редко виновата в плохом результате. Модель правильно читает роль, задачу, формат. Но примеры — конкретный сигнал что считается "хорошим ответом". Плохие примеры = неверный ориентир. Применяй: сначала замени или добавь 1-2 примера. Только если не помогло — переписывай инструкции

Если не запретить генерацию явно — модель начинает писать контент до получения всех ограничений. Первые предложения уже не учитывают правила, которые ты ещё не написал. Явный запрет ("только подтверди понимание, не пиши контент") заставляет модель сначала обработать весь контекст. Применяй: В конце блока с требованиями всегда пиши: Подтверди, что всё понял. Не генерируй контент пока я не скажу

Если данные неструктурированные и разрозненные — дообучение маленькой модели не спасает. Модель не учится извлекать смысл из хаоса. Дешевле взять большую модель и дать ей те же данные, но в структурированном виде. Применяй: прежде чем думать о дообучении — попробуй структурировать контекст и сменить модель на более мощную

Модель обучена на "помоги пользователю". Это значит: первый пришедший ответ будет оптимизирован под выполнение задачи. Риски мешают выполнению — они вытесняются. Если не написать "перечисли негативные последствия" — модель их не перечислит. Это не злой умысел, это приоритет. Применяй: в любом запросе где важны последствия, добавляй явный блок: "Негативные риски:" — это заставляет модель целенаправленно их искать