Kitabı oxu: «ИИ для управления проектами: планы, риски, сроки, контрольные точки»
Глава 1. Почему ИИ «льёт воду» и выдумывает: механика ошибок на человеческом языке
Есть ощущение, что ИИ ошибается странно. Он может звучать уверенно, писать гладко, строить логичные абзацы, даже добавлять «детали», которые выглядят убедительно, и при этом промахиваться по фактам, путать причинность, подменять смысл и «дорисовывать» то, чего в исходных данных не было. Важно понимать простую вещь: когда вы общаетесь с ИИ, вы общаетесь не с источником истины, а с системой, которая умеет продолжать текст так, чтобы он выглядел правдоподобно и соответствовал вашему запросу по форме. Именно поэтому ошибки ИИ чаще похожи на «хорошо написанную неправду», чем на бессвязный бред.
Эта глава нужна не для того, чтобы научить вас бояться ИИ. Она нужна для другой цели: дать вам ясную, практичную модель, почему возникают «вода» и фантазии, и что в вашем запросе почти гарантированно провоцирует эти эффекты. Пока вы не видите механики ошибок, вы пытаетесь «уговорить» ИИ писать лучше. Как только механика становится понятной, вы начинаете управлять результатом через контекст, рамки, формат и проверку.
Убедительность не равна истинности: почему звучит уверенно даже когда неверно
Уверенный тон возникает не потому, что система «знает», а потому, что так устроены нормы письма: связность, ясная структура, отсутствие колебаний, уверенные формулировки воспринимаются как компетентность. ИИ обучался на огромном массиве текстов, где уверенный стиль часто соседствует с реальными знаниями. В результате система усваивает форму «как пишут, когда знают», и воспроизводит её даже тогда, когда фактов не хватает.
Отсюда типовая ловушка: человек оценивает ответ глазами читателя, а не глазами проверяющего. Читатель верит стилю, проверяющий верит только проверяемости. Пока вы не переключились в режим проверяющего, вы будете попадать в ситуацию, когда «вроде всё звучит правильно», а затем в реальной работе всплывает ошибка: неверная цифра, выдуманная причина, несуществующий термин, неверная трактовка нормы, неправильный порядок действий.
Практический вывод: уверенность в тексте нужно заменить на управляемую неопределённость. Вам полезно прямо в запросе требовать маркировки: где факт, где допущение, где рекомендация. Ещё полезнее требовать «границы уверенности» и список того, что нужно уточнить, чтобы превратить догадки в надёжный ответ. Это не «слабость» текста. Это повышение качества, потому что вы перестаёте платить за красивую уверенность ценой ошибок.
Главная причина фантазий: недостаток контекста и отсутствие рамок
Фантазии почти всегда растут из пустоты. Когда в запросе мало данных, система всё равно пытается дать законченный ответ, потому что так «ожидается» от помощника. Если вы не задали рамки, система заполняет пробелы наиболее вероятными догадками, опираясь на типичные паттерны из похожих текстов. Она не «врет» намеренно, она достраивает.
В работе это выглядит так: вы просите «дай стратегию», но не говорите, что у вас за продукт, регион, ограничения по бюджету, каналы, этап воронки, сроки, ресурсы. В ответ вы получаете «универсальные советы» и много воды. Или вы просите «объясни причину», но не даёте исходных данных. В ответ получаете правдоподобное объяснение, которое может быть неверным именно потому, что исходных фактов не было.
Практический вывод: чем меньше контекста, тем больше риск выдумок. Чем меньше рамок, тем больше воды. Контекст – это не «простыня», а минимальный набор параметров, который делает ответ конкретным. Рамки – это запреты и правила игры: что нельзя придумывать, что делать, если данных нет, как оформлять выводы. Как только контекст и рамки заданы, качество растёт резче, чем от любых «пожалуйста, подробнее».
Слишком общий запрос → слишком общий ответ
Общий запрос заставляет систему действовать широко: покрыть всё понемногу, не попасть в явный конфликт с ожиданиями, дать «безопасный» набор мыслей. Так рождается вода. Она выглядит как полезная «вступительная часть», но на деле съедает место и внимание, а решения не приближает.
Плохая формулировка в работе обычно звучит так: «расскажи про», «дай советы», «как улучшить», «какие тренды», «что делать». Хорошая формулировка обычно содержит объект, границы и измеримость результата: «составь план», «сделай шаблон», «дай критерии», «предложи 3 варианта и выбери лучший по условиям», «подготовь список проверок», «сформулируй текст для клиента».
Практический вывод: если вы хотите практику, в запросе должен быть результат. Не тема, а результат. Не «маркетинг», а «план рекламной кампании на 14 дней с бюджетом X и KPI Y». Не «промпты для команды», а «универсальный промпт-шаблон и правила, как его адаптировать, плюс чеклист проверки ответа». Чем чётче продукт на выходе, тем меньше воды.
«Сделай красиво» → «сделай правдоподобно» и как это меняет результат
Слова «красиво», «интересно», «вкусно», «сильно», «убедительно» задают эстетическую цель. Эстетическая цель запускает в системе режим литературного украшательства: метафоры, уверенный тон, обобщения, «умные» формулировки. Иногда это полезно, когда вы действительно хотите текст как текст. Но когда вам нужен точный смысл и корректные факты, эстетическая цель становится токсичной: она поощряет правдоподобие, а не проверяемость.
Формулировка «сделай правдоподобно» тоже опасна, если под ней подразумевается «придумай детали, чтобы выглядело реалистично». Для точной работы правильнее просить «сделай проверяемо» и «не добавляй деталей без оснований». Вместо «красиво» лучше использовать: «ясно», «однозначно», «без воды», «с критериями и шагами», «без новых фактов», «с пометками уверенности».
Практический вывод: заменяйте эстетические прилагательные на критерии качества. Критерий – это то, что можно проверить. «Без повторов», «каждый пункт применим», «каждый вывод опирается на данное», «если данных нет – перечисли, что нужно», «не использовать предположения без маркировки». Такой запрос делает ответ холоднее по стилю, зато теплее по пользе.
Проблема источников: когда нужны ссылки, а когда достаточно логики
В реальной работе есть два типа задач. Первый – задачи на логику и опыт: структурирование, планирование, формулировки, сценарии, дизайн процесса, чеклисты, декомпозиция, варианты решений. Здесь ссылочная база не всегда критична, потому что вы оцениваете качество по применимости и здравому смыслу, а затем проверяете результат на практике.
Второй тип – задачи на факты: цифры, нормативные требования, конкретные определения, свежие изменения, исторические события, медицинские и финансовые утверждения, юридические трактовки, «кто сейчас», «какая ставка», «какой срок». Здесь источники критичны, потому что цена ошибки высока, а правдоподобие ничего не гарантирует.
Но есть нюанс: даже в задачах «без ссылок» вы должны уметь отличать фактические утверждения от логических выводов. Логика может быть сильной, даже если факты не приводятся. Факт без опоры может быть красивой выдумкой. Поэтому полезно требовать от ИИ разделения: «вот выводы, которые следуют из условий», и отдельно «вот места, где нужны проверяемые сведения».
Практический вывод: как только вы видите в ответе числа, точные названия документов, даты, проценты, «исследования показали», «по данным», включайте внутренний сигнал тревоги. Если вы не давали эти данные в исходном вводе, вероятность выдумки повышается. В таких местах ваша задача – либо предоставить данные, либо заставить ИИ перейти в режим вопросов, либо самостоятельно проверить и заменить на реальные сведения.
Непроверяемые утверждения: как их распознавать
Непроверяемое утверждение – это фраза, которая выглядит умно, но не содержит ни способа проверки, ни критериев, ни условий применимости. Примеры узнаваемых маркеров: «как правило», «обычно», «часто», «многие эксперты считают», «доказано», «эффективно», «повышает», «улучшает». Такие слова могут быть нормальными в публицистике, но в рабочем тексте они опасны, потому что не ведут к действию.
Ещё одна форма непроверяемости – «замкнутые объяснения»: когда утверждение объясняется словами-синонимами. Например, «это работает, потому что повышает эффективность». Это не объяснение, это повтор. Вам нужно объяснение через механизм: что именно меняется, за счёт чего, при каких условиях, каким образом это проявится в метриках или наблюдаемом результате.
Практический вывод: любая «общая» фраза должна быть превращена в конкретику через вопросы: «что именно сделать», «каким образом измерить», «какой риск», «какая альтернатива», «какие условия». Если ИИ не может ответить, значит, перед вами декоративная фраза, её нужно либо удалить, либо заменить на шаги и критерии.
Как ИИ реагирует на противоречия в запросе
Противоречия в запросе бывают явные и скрытые. Явные – когда вы просите одновременно «максимально коротко» и «максимально подробно», «без фантазий» и «приведи примеры, чтобы было живо», «без ссылок» и «со ссылками». Скрытые – когда вы просите «универсально» и одновременно «под нашу ситуацию», но не даёте данных о ситуации.
В ответ на противоречие система часто выбирает компромисс: даёт среднее, пытается удовлетворить оба требования понемногу, поэтому получается ни то ни другое. Иногда она выбирает то, что сильнее звучит или чаще встречается в данных обучения: например, «подробно» побеждает «кратко», а «примеры» побеждают «не выдумывай». В итоге вы получаете либо воду, либо выдуманные детали, либо смесь.
Практический вывод: ваша задача – убрать противоречия из промпта. Если требования конфликтуют, нужно явно расставить приоритеты: «главное – точность и проверяемость, краткость вторична», или «главное – итоговый артефакт, стиль вторичен». Ещё полезнее – задавать порядок работы: сначала вопросы, затем план, затем финальный текст. Порядок снимает конфликт, потому что система перестаёт пытаться сделать всё сразу.
Роль формата: почему «таблица/чеклист/план» режет воду
Формат – это дисциплина. Когда вы просите «рассказать», система выбирает повествование: оно может быть красивым и длинным. Когда вы просите «план», «чеклист», «матрицу решений», «алгоритм», вы встраиваете рамки, которые обрезают лишнее, потому что внутри формата нет места для бесконечных вступлений.
При этом важно понимать: формат сам по себе не гарантирует истины. Он гарантирует структуру. Структура облегчает проверку, потому что вы видите, где у ответа «пустые места», где логические дыры, где пропущены входные данные. Структура позволяет быстро заметить подмену смыслов: когда вместо действий дают советы, вместо критериев дают лозунги, вместо рисков дают успокаивающие фразы.
Практический вывод: если задача практическая, просите результат в структуре «итог → шаги → критерии готовности → риски → что уточнить». Если задача аналитическая, просите «гипотезы → что подтверждает → что опровергает → какие данные нужны → план проверки». Формат превращает болтовню в инструмент.
Роль ограничений: что запрещать прямо в запросе
Ограничения – это те самые «перила», которые не дают ответу улететь в фантазии. Запреты должны быть прямыми и конкретными. «Не выдумывай» хорошо, но лучше – «не добавляй цифры, даты, названия документов, статистику и ссылки, если они не даны во входных данных». Ещё лучше – «если данных нет, напиши: “недостаточно данных”, и перечисли, что нужно уточнить».
Ограничения полезны не только против фантазий. Они режут воду. Например: «без вводных абзацев», «не повторять одно и то же другими словами», «не использовать общие слова без конкретных шагов», «не давать советов уровня “улучшайте качество” без механики и метрик». Чем точнее запрет, тем меньше «пустых» абзацев.
Практический вывод: запреты нужно формулировать так, чтобы их можно было проверить глазами. Если запрет звучит расплывчато, система найдёт способ его обойти, не нарушая буквально. Когда запрет измерим, ответ становится управляемым.
Артефакт: чеклист «почему ответ получился плохим»
Этот чеклист нужен для быстрого разбора любого неудачного ответа. Он экономит время, потому что вы перестаёте переписывать промпт «на эмоциях» и начинаете точечно исправлять причину.
Проверьте, что именно пошло не так.
В ответе много уверенных формулировок, но мало проверяемых оснований. Это признак имитации знания. Решение: требовать маркировку «факт/допущение/рекомендация» и список того, что нужно уточнить.
В ответе много общих слов и мало действий. Это признак слишком общего запроса. Решение: заменить тему на результат и требовать конкретный формат «шаги + критерии готовности».
В ответе появились цифры, статистика, «исследования», которых вы не давали. Это признак заполнения пустоты. Решение: запретить любые факты, которых нет во входных данных, и требовать вопросы при нехватке информации.
В ответе много вступлений, «объяснений ради объяснений», повторов. Это признак отсутствия формата и ограничений. Решение: задать формат выдачи и лимиты: «итог в X пунктах, затем обоснование, без повторов».
Ответ «средний», потому что в запросе конфликт требований. Решение: убрать противоречия, расставить приоритеты, задать порядок: вопросы → план → финал.
Ответ «как из учебника» и не подходит к ситуации. Это признак недостатка контекста. Решение: дать минимальный бриф: цель, аудитория, ограничения, ресурсы, сроки, регион, текущая точка.
Ответ слишком «красивый» и мало полезный. Это признак эстетических требований. Решение: заменить «красиво» на критерии: ясность, однозначность, применимость, проверяемость.
В ответе много вариантов без рекомендации. Это признак отсутствия критериев выбора. Решение: дать критерии и попросить выбрать лучший вариант с объяснением.
В ответе нет рисков и ограничений. Это признак «презентационного» режима. Решение: требовать блок «риски и как снизить» и «что может быть неверно».
В ответе всё выглядит логично, но вы не понимаете, как применить. Это признак отсутствия «следующего шага». Решение: просить конкретный план внедрения: что сделать сегодня, завтра, на неделе, и как проверить результат.
63
Глава 2. Как задавать вопросы, чтобы ИИ перестал «додумывать»: конструкция запроса как инженерная работа
Большинство проблем с качеством ответа решаются не «другой моделью» и не магическими промптами, а тем, как вы формулируете задачу. Запрос для ИИ – это не разговор с человеком, который способен уточнить и прикинуть реальность по интонации. Запрос для ИИ – это техническое задание в миниатюре. Чем ближе ваш запрос к нормальному ТЗ, тем меньше воды, тем меньше фантазий, тем выше плотность полезного результата.
Если в первой главе мы разобрали, почему система вообще начинает заполнять пустоты и говорить уверенно о том, чего не знает, то теперь переходим к практике: как строить запрос так, чтобы пустоты не возникали, а если они неизбежны – чтобы модель честно показала, где именно она не уверена, и предложила вопросы вместо выдумки.
Эта глава не про «красивые формулировки». Она про то, как превратить запрос в управляемую конструкцию: входные данные, рамки, формат выхода, критерии качества и порядок действий. Именно эти элементы делают ответ предсказуемым и проверяемым.
Почему «одна фраза» почти всегда проигрывает
Люди любят короткие запросы: «сделай стратегию», «напиши текст», «подскажи, что делать». Кажется, что так быстрее. На практике это почти всегда дольше, потому что вы получаете расплывчатый ответ, затем начинаете уточнять, переписывать, ругаться на воду, и всё равно в конце даёте то, что могли дать сразу: контекст и ограничения.
Однофразный запрос плох не потому, что он короткий. Он плох потому, что в нём нет инструмента контроля. В нём нет того, что удерживает ответ в нужном коридоре. Модель начинает выбирать «среднестатистический» вариант решения, который подходит всем и никому. Это не саботаж, это закономерность.
Поэтому правило простое: если задача важная, запрос должен быть многослойным. Не длинным ради длины, а состоящим из нужных блоков. У вас может быть 10 строк, но они должны быть правильными.
Четыре слоя хорошего запроса
Почти любой сильный запрос можно собрать из четырёх слоёв. Это не теория. Это практичная схема, которую можно запомнить и применять к любым задачам: от текста и стратегии до анализа данных и подготовки документов.
Первый слой – цель. Не тема, а то, что вы хотите получить на выходе и зачем. «Нужно письмо клиенту, чтобы согласовать сроки и снять возражение по цене». «Нужен план внедрения процесса, чтобы команда перестала забывать этапы». «Нужны варианты структуры главы, чтобы выбрать лучшую для книги».
Второй слой – контекст. Минимальный бриф: кто вы, что за проект, какие ограничения и вводные. Здесь важна не полнота, а релевантность. Если вы пишете оффер для клиники, важны аудитория, регион, тип услуг, конкурентная среда, ценовой сегмент, ограничения по рекламе, юридические риски. Если вы просите техническое решение, важны платформа, интеграции, уже сделанные шаги, что не работает, какие есть ограничения по доступам.
Третий слой – рамки и запреты. Это то, что вы запрещаете модели делать: «не добавлять цифры и факты без источников», «не выдумывать примеры людей», «не использовать ссылки», «не предлагать то, что не работает в РФ», «не давать абстрактные советы без шагов». Рамки – ваш основной инструмент против воды и фантазий.
Четвёртый слой – формат результата. Модель подстраивается под формат очень сильно. Если вы не задали формат, она выбирает повествование. Если вы задали формат, она строит выдачу в нужной структуре. Это может быть: план внедрения по дням, чеклист проверки, сценарий звонка, структура статьи, таблица рисков (если таблицы допустимы), список гипотез с планом проверки, список альтернатив с критериями выбора.
Эти четыре слоя не обязаны быть длинными. Они обязаны быть ясными.
Пятый слой, который отделяет профессионала: критерии готовности
Критерии готовности – это то, что делает результат применимым. Когда вы даёте критерии, вы превращаете «текст» в рабочий продукт. Критерии отвечают на вопрос: как понять, что ответ годится, и что нужно исправить.
Примеры критериев готовности для разных задач.
Для текста: «тон нейтрально-деловой», «без обещаний, которые нельзя выполнить», «без канцелярита», «первый абзац сразу по сути», «не упоминать источники и ссылки», «объём 2500–3500 знаков», «3 аргумента, 1 призыв к действию», «без воды и общих фраз».
Для стратегии: «3 сценария бюджета», «каждый пункт – действие, измеримое метрикой», «у каждого действия: цель, инструмент, срок, риск, критерий успеха», «план на 4 недели», «учесть ограничение по ресурсу: 1 специалист 20 часов в неделю».
Для анализа: «отделить факты от гипотез», «для каждой гипотезы – какие данные нужны», «предложить последовательность проверки от дешёвого к дорогому», «указать возможные альтернативные объяснения».
Критерии готовности дисциплинируют ответ сильнее, чем просьба «пиши профессионально».
Два режима работы с ИИ: генерация и верификация
Одна из главных ошибок пользователя – смешивать режимы. Вы хотите сразу «идеально и точно», но при этом просите «придумай варианты». Или наоборот: вы хотите чистовую инструкцию, но даёте запрос как на мозговой штурм. Модель пытается быть полезной и начинает «подмешивать» то, что не просили.
Есть два режима, и их лучше разделять.
Режим генерации. Здесь вы допускаете гипотезы, варианты, сценарии, но требуете маркировку: что является предположением, что требует проверки, что основано на ваших данных. В этом режиме нормально просить «дай 10 идей», «предложи 5 вариантов», «накинь сценарии». Но вы должны удержать модель от выдуманных фактов и ложной уверенности.
Режим верификации. Здесь вы не просите «придумывать». Вы просите проверять, критиковать, искать дыры, выявлять риски, улучшать структуру, приводить критерии. В этом режиме модель должна быть максимально строгой: «где слабые места», «какие вопросы остались без ответа», «что может быть неверно», «какие допущения скрыты».
Самая сильная схема работы: сначала генерация, потом верификация. Сначала вы получаете материал, потом вы превращаете его в продукт через критику и улучшение.
Порядок действий в запросе: почему это важно
Когда вы задаёте порядок действий, вы убираете хаос. Модель перестаёт пытаться сделать всё одновременно. Особенно это важно в задачах, где есть риск выдумок.
Рабочий порядок часто выглядит так.
Шаг 1. Задай уточняющие вопросы, если данных недостаточно. Если вопросов нет – явно напиши «данных достаточно».
Шаг 2. Сформулируй краткий план решения на 5–7 пунктов.
Шаг 3. Выполни задачу по плану.
Шаг 4. Проверь результат по критериям готовности и перечисли, что улучшить.
Это не бюрократия. Это способ заставить модель быть честной с пробелами и не заполнять их выдумкой.
Уточняющие вопросы: как сделать так, чтобы их было не 30, а 5
Модель может утонуть в вопросах, если вы просто скажете «задай вопросы». Она начнёт перестраховываться. Чтобы вопросы были полезными, задайте рамку: «задай 5 вопросов, без которых результат будет неточным», или «задай вопросы только по тому, что влияет на выбор решения».
Ещё лучше: попросите модель назвать не просто вопросы, а тип влияния: «какой ответ на этот вопрос изменит план». Тогда вопросы становятся не формальными, а осмысленными.
Если вы не хотите вопросов, а хотите результат сразу, используйте другой приём: дайте модели право сделать допущения, но заставьте её их выписать. Например: «если чего-то не хватает, сделай разумные допущения, но вынеси их отдельным списком и пометь, что это допущения». Тогда вы видите, где потенциальная ложь, и можете быстро исправить вводные.
Стоп-слова и опасные формулировки, которые провоцируют воду
Есть слова, которые почти гарантированно увеличивают воду. Они не «плохие», они просто включают режим повествования и общих рассуждений.
Слова-триггеры воды: «расскажи», «объясни», «поделись мыслями», «дай советы», «как улучшить», «что важно», «какие тренды», «почему это работает». Эти формулировки можно использовать, но только если вы дополнительно задаёте формат и критерии.
Слова-триггеры фантазий: «приведи статистику», «сошлись на исследования», «приведи примеры кейсов», «как в реальных компаниях», если вы не даёте источники и не разрешаете поиск. В этом месте модель начинает «достраивать» и очень легко придумывает правдоподобные детали.
Слова, которые часто дают «гладкий мусор»: «уникально», «сильно», «цепляюще», «вирусно», «продающе», «вдохновляюще». Если вам нужен бизнес-результат, заменяйте их на измеримые критерии: «конкретные выгоды», «ясный оффер», «снятие возражений», «структура AIDA», «варианты заголовков под SEO».
Решение простое: вы можете использовать любые слова, но рядом должны быть рамки, формат и критерии. Иначе вы получите литературу вместо инструмента.
Как требовать «без выдумки» правильно
Фраза «не выдумывай» полезна, но она слишком общая. Модель может подумать, что вы имеете в виду «не фантазируй безумно», и всё равно добавит «правдоподобные детали». Поэтому нужно конкретизировать запрет.
Правильный запрет формулируется так: «не добавляй новые факты, цифры, даты, названия компаний, нормативов, исследований и статистику, если они не даны во входных данных». Ещё лучше: «если таких данных нет, напиши, что данных недостаточно, и предложи, какие данные нужны».
Плюс важное уточнение: вы должны разрешить модели не отвечать полностью. Многие пользователи боятся фразы «данных недостаточно» и считают её провалом. На самом деле это признак качества: система перестаёт имитировать знание и начинает вести себя как аналитик. Если вы запретили выдумки и при этом требуете «всё равно дай готовый ответ», вы сами закладываете противоречие.
Как резать воду: ограничение объёма и плотность
Вода появляется не только из-за общего запроса, но и из-за отсутствия ограничений по плотности. Модель часто стремится «объяснить», «обосновать», «быть дружелюбной». Если вам нужна плотность, задайте правила.
Рабочие правила против воды: «без вступления», «сразу к делу», «каждый пункт должен содержать действие», «не использовать общие фразы без механики», «не повторять мысль другими словами», «минимум прилагательных, максимум сущностей и шагов».
Ограничение объёма тоже помогает, но оно должно быть умным. Не «коротко», а «в 12 пунктов», «в 7 шагов», «в 3 сценария», «в 5 критериев». Тогда модель вынуждена выбирать главное.
Ещё один приём – «проверка на применимость». Попросите: «после ответа добавь блок “как применить завтра”: 3 действия на завтра и 1 метрика контроля». Это заставляет модель выйти из теории.
Шаблон запроса, который можно использовать почти всегда
Дальше я дам универсальный шаблон. Его не нужно вставлять целиком каждый раз. Он нужен как конструкция в голове. Вы берёте те блоки, которые нужны задаче.
Цель: что я хочу получить и зачем.
Контекст: что за проект, аудитория, ограничения, исходная точка.
Входные данные: перечисление фактов, которые уже известны.
Ограничения: что запрещено, что обязательно.
Формат ответа: структура результата.
Критерии качества: как понять, что ответ годный.
Порядок действий: вопросы → план → выполнение → самопроверка.
Если вы начнёте думать такими блоками, качество общения с ИИ вырастет на порядок без смены модели.
Три рабочих примера, чтобы было видно разницу
Пример 1. Вместо «Напиши стратегию продвижения».
Слабый запрос: «Напиши стратегию продвижения стоматологии в Москве».
Почему слабый: нет целей, бюджета, услуги, аудитории, ограничений, каналов, сроков, ресурсов. Ответ будет универсальным и водянистым.
Сильная конструкция: «Нужен план продвижения стоматологии в Москве на 4 недели, цель – увеличить число первичных записей на консультацию. Бюджет на рекламу 300 000 ₽/мес, команда: 1 маркетолог 20 часов/неделя, 1 администратор. Услуги: имплантация и ортодонтия, средний чек высокий. Ограничения: никаких обещаний результата в тексте, без ссылок и статистики, не предлагать каналы, которые не работают в РФ. Формат: 1) краткая стратегия в 7 пунктов, 2) план по неделям: действия, ответственный, метрика, риск, 3) список из 10 гипотез для теста, 4) 5 уточняющих вопросов, без которых точность упадёт».
Разница: появляется управляемость.
Пример 2. Вместо «Объясни, почему упали продажи».
Слабый запрос: «Почему упали продажи?».
Сильная конструкция: «Нужно разобрать причины падения продаж в интернет-магазине за последние 14 дней. Данные: трафик -10%, конверсия -25%, средний чек без изменений, рекламные расходы те же, ассортимент и цены не меняли. Ограничения: не придумывать причины без привязки к данным, если данных не хватает – перечислить, какие нужны. Формат: 1) список гипотез, 2) что подтверждает/опровергает, 3) какие данные запросить, 4) порядок проверки от дешёвого к дорогому, 5) быстрые действия на завтра, которые не навредят».
Так вы получаете не «умные рассуждения», а план расследования.
Пример 3. Вместо «Напиши текст для лендинга».
Слабый запрос: «Напиши продающий текст для лендинга».
Сильная конструкция: «Нужен текст для первого экрана лендинга услуги X. Цель: повысить конверсию в заявку. Аудитория: Y. Основные боли: Z. Уникальные преимущества: A, B, C. Ограничения: без клише, без обещаний, без сравнений с конкурентами, без выдуманных цифр. Формат: 5 вариантов заголовка, 5 подзаголовков, 3 варианта списка выгод, 2 варианта CTA. Критерий: в каждом варианте должен быть конкретный результат для клиента и понятный следующий шаг».
В итоге вы получаете набор, из которого реально можно собирать страницу и тестировать.
Как переписывать запрос, если ответ уже плохой
Часто вы уже получили плохой ответ, и теперь нужно быстро исправить ситуацию, не переписывая всё с нуля. Есть три быстрых приёма.
Первый: потребовать «версию без воды». «Перепиши ответ, убрав любые вводные и общие слова. Оставь только действия, критерии и риски. Никаких повторов».
Второй: включить режим «аудита». «Найди в своём ответе места, где есть непроверяемые утверждения или возможные выдумки. Перепиши эти места так, чтобы либо опереться на данные, либо пометить как гипотезы и задать вопросы».
Третий: сузить задачу до одного результата. Плохие ответы часто возникают, когда вы просите «всё сразу». Разбейте: «Сейчас сделай только первый экран», или «Сейчас дай только план проверки гипотез», или «Сейчас выпиши только риски и как их закрыть».
Обычно после этого качество резко повышается, потому что модель перестаёт распыляться.
Мини-чеклист перед отправкой любого важного запроса
Перед тем как нажать Enter, пробегитесь по пяти вопросам.
Ясно ли, какой результат нужен, а не просто тема?
Есть ли минимальный контекст, без которого ответ будет общим?
Есть ли запреты, чтобы исключить выдуманные факты и «красивые детали»?
Задан ли формат, чтобы ответ был структурой, а не рассказом?
Есть ли критерии качества, по которым я смогу принять или отклонить результат?
Если на два и более вопроса ответ «нет», вы почти гарантированно получите воду или фантазии. И это не «плохой ИИ». Это просто недостроенный запрос.
Главная мысль этой главы простая: качество ответа – это производная от качества постановки задачи. Когда вы начинаете писать запрос как инженер, модель становится управляемым инструментом. Когда вы пишете запрос как в разговоре, модель становится рассказчиком. В бизнесе, в документах, в процессах и в принятии решений вам чаще нужен инструмент, а не рассказчик.
