Бесплатный фрагмент - ИИ для управления проектами: планы, риски, сроки, контрольные точки

Глава 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, пробегитесь по пяти вопросам.

Ясно ли, какой результат нужен, а не просто тема? Есть ли минимальный контекст, без которого ответ будет общим? Есть ли запреты, чтобы исключить выдуманные факты и «красивые детали»? Задан ли формат, чтобы ответ был структурой, а не рассказом? Есть ли критерии качества, по которым я смогу принять или отклонить результат?

Если на два и более вопроса ответ «нет», вы почти гарантированно получите воду или фантазии. И это не «плохой ИИ». Это просто недостроенный запрос.

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

Глава 3. Контекст, который реально нужен: как давать минимум данных и получать максимум точности

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

Эта глава про практический минимум. Не про «пишите больше», а про «пишите правильнее». Про то, какие 10–15 строк входных данных дают скачок качества сильнее, чем 10 страниц переписки. И про то, как организовать контекст так, чтобы ИИ перестал «додумывать» и начал вести себя как аналитик, который работает с вашим кейсом, а не со среднестатистической ситуацией.

Почему «контекст» — это не объём, а релевантность

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

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

Практический вывод: контекст должен отвечать на вопрос «что изменится в плане, если этот факт другой?». Если ничего не изменится — факт лишний.

Три уровня контекста: базовый, рабочий, экспертный

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

Базовый контекст — для простых задач: текст, идеи, структура, шаблоны. Обычно достаточно 6–10 строк: кто аудитория, цель, тон, ограничения, формат результата, что нельзя делать.

Рабочий контекст — для задач, где есть риск ошибиться и где важна применимость: стратегия, план действий, анализ причин, позиционирование, коммерческие предложения, регламенты. Здесь нужно 10–20 строк, но они должны быть параметрическими: ресурсы, сроки, ограничения, текущая точка, что уже пробовали, критерии успеха.

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

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

Контекст, который почти всегда нужен: универсальные поля

Есть набор полей, которые полезны в 80% задач. Это ваша «карточка запроса». Если вы научитесь быстро заполнять эти поля, вы перестанете терять время на переписки.

Цель: что должно измениться после результата (метрика, решение, документ, согласование). Объект: что именно делаем (страница, текст, процесс, кампания, интеграция, глава книги). Аудитория: кто будет читать/пользоваться (сегмент, опыт, боли, ожидания). Ограничения: юридические, этические, брендовые, платформенные (что нельзя). Ресурсы: кто делает и сколько времени (1 человек 2 часа или команда 2 недели — это разные решения). Сроки: дедлайн и этапность (нужно «сегодня» или «в течение месяца»). Текущая точка: что уже есть сейчас (черновик, метрики, текущая версия, результаты тестов). Желаемый формат: как должен выглядеть результат (структура, объём, выходной артефакт). Критерии качества: по чему вы примете результат.

Это не бюрократия. Это минимальная рамка, которая делает ответ предсказуемым.

Два типа вводных: факты и интерпретации, их нужно разделять

Очень частая причина ошибок — когда пользователь смешивает факты и свою интерпретацию. Модель воспринимает всё как истину и строит ответ на неверном основании.

Факт: «конверсия снизилась с 2,4% до 1,7%». Интерпретация: «конверсия упала из-за плохого дизайна». Факт: «в карточке товара добавили новый блок». Интерпретация: «этот блок отвлекает и мешает покупать».

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

Практический вывод: пишите вводные в двух разделах. «Факты» — то, что наблюдаемо. «Гипотезы/мои предположения» — то, что вы думаете. И отдельно попросите: «проверь гипотезы, предложи альтернативы, составь план проверки».

Как давать цифры и метрики так, чтобы не получить мусор

Цифры сильно помогают, но только если они сопоставимы и связаны с периодом. Одна цифра без контекста почти бесполезна.

Плохие вводные: «трафик упал», «CTR низкий», «продаж мало», «бюджет большой». Хорошие вводные: «трафик -12% неделя к неделе, органика -18%, платный +3%», «CTR в поиске 5,2% был, стал 3,9% после изменения заголовков», «конверсия в заявку 1,1% при 30 000 посетителей/мес», «бюджет 200 000 {₽} /мес, цель — 120 лидов, текущая цена лида 2 900 {₽}».

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

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

Чего не надо давать: контекст-шум

Есть типы информации, которые часто не помогают и даже мешают.

Длинные эмоциональные описания: «нас достали», «всё плохо», «клиент не понимает». Это понятно по-человечески, но для модели это шум, если вы не превращаете это в ограничения и критерии.

История компании «с основания»: если это не влияет на задачу, лучше убрать.

Переписка целиком: обычно полезнее вытащить 5–10 ключевых тезисов и требований, чем залить весь чат.

Смешивание нескольких задач в одном контексте: модель начинает перескакивать и выдаёт общий текст.

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

Контекст как «карточка проекта»: самый удобный формат

Один из лучших способов — держать «карточку проекта» и вставлять её в запросы. Это экономит время и даёт стабильное качество. Карточка — это не документ на 10 страниц, а 12–20 строк с параметрами.

Пример структуры карточки для маркетинга/контента: Проект: что продаём, где, сегмент. ЦА: 2–3 сегмента и ключевые боли. Цель: метрика и срок. Ограничения: юридические, бренд, что нельзя обещать/упоминать. Каналы: что используем, что запрещено, что пробовали. Ресурсы: команда и доступы. Текущие данные: 5 ключевых метрик. Стиль: тон, словарь, запреты. Формат выдачи: что хотим получить от ИИ обычно.

Пример структуры карточки для продукта/разработки: Система: стек, платформа, окружение. Проблема: симптом, где проявляется, с какого времени. Что меняли: последние изменения. Логи/ошибки: фрагменты, коды. Ограничения: доступы, сроки, запреты. Цель: что должно работать и как проверяем. Формат: нужен патч-код/псевдокод/план диагностики/список гипотез.

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

Как давать контекст частями: метод «слоёв»

Иногда вы не уверены, что важно. Тогда не нужно заливать всё. Работает метод слоёв.

Слой 1: минимальная карточка (10 строк) и задача. Слой 2: если модель задаёт вопросы или если вы видите, что ответ общий, добавляете только то, что влияет на выбор действий. Слой 3: если нужно, прикладываете документы, примеры, данные.

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

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

Как понять, какого контекста не хватает: диагностика по типу плохого ответа

Вы можете по характеру ответа определить, что именно вы не дали.

Если ответ слишком общий и «учебниковый» — не хватает конкретики по цели, аудитории, ограничениям и текущей точке.

Если ответ предлагает то, что вам запрещено или не подходит — вы не обозначили рамки (юридические запреты, география, «это не работает», «это нельзя упоминать»).

Если ответ уходит в теорию — вы не задали формат результата и критерии готовности.

Если ответ содержит выдуманные цифры/факты — вы не запретили добавлять факты и не разрешили модели сказать «данных недостаточно».

Если ответ предлагает слишком много вариантов без выбора — вы не дали критерии выбора и не попросили рекомендацию.

Это простая матрица: по типу ошибки понятно, какой блок контекста отсутствует.

Практический блок: минимальные шаблоны контекста для разных задач

Ниже — набор минимальных «вводных», которые можно копировать и заполнять. Они короткие, но дают резкий прирост качества.

Шаблон для текста: Цель текста: Аудитория: Контекст (где будет использоваться): Основные тезисы/факты (5–7 пунктов): Ограничения (что нельзя): Тон/стиль: Формат (что именно нужно: заголовки, лид, блоки, CTA, объём):

Шаблон для стратегии/плана: Цель (метрика и срок): Проект/ниша/регион: ЦА: Ресурсы (люди/часы/бюджет): Текущая точка (что уже сделано, текущие метрики): Ограничения: Формат результата (план на N недель, действия+метрики+риски): Критерии качества:

Шаблон для анализа проблемы: Симптом: Когда началось: Что изменилось перед этим: Данные (было/стало): Гипотезы (мои): Ограничения (что нельзя делать): Формат: гипотезы → данные для проверки → порядок проверки → быстрые безопасные действия:

Шаблон для регламента/процесса: Цель процесса: Кто участвует: Триггер (когда начинается): Входы (что нужно на входе): Выход (что считаем готовым): Ограничения/риски: Формат: шаги → ответственный → SLA/срок → контроль качества → типовые ошибки:

Эти шаблоны — не «правильная форма ради формы». Это минимальный набор, который делает ответ практичным.

Ключевая идея главы: не пытайтесь победить фантазии «умолянием писать аккуратно». Побеждайте их структурой входных данных. Давайте не больше текста, а больше управляющих параметров. Разделяйте факты и гипотезы. Задавайте рамки. Определяйте формат результата. Тогда ИИ перестанет быть генератором общих слов и начнёт работать как инструмент, который вы настраиваете под конкретную задачу.

Глава 4. Формат как рычаг: чеклисты, алгоритмы, матрицы и почему они сильнее «хорошего текста»

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

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

Почему повествование провоцирует воду

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

Первая — расплывчатость. В абзацах легко скрыть отсутствие конкретных шагов. Слова «важно», «нужно», «стоит», «следует» звучат полезно, но не дают процедуры.

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

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

Главный принцип: формат должен соответствовать типу задачи

Ошибки происходят, когда вы выбираете формат «по привычке». Например, просите «объяснение», когда вам нужен план. Или просите «план», когда вам нужна диагностика причин. У каждого типа задачи есть свой оптимальный формат.

Есть четыре базовых типа задач.

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

Задачи на диагностику (почему так): здесь нужен набор гипотез, признаки подтверждения/опровержения, план проверки.

Задачи на выбор (что лучше): здесь нужна матрица критериев, сравнение вариантов, рекомендация с обоснованием.

Задачи на коммуникацию (как сказать): здесь нужен сценарий, структура сообщения, варианты формулировок, карта возражений.

Как только вы определили тип задачи, вы выбираете формат. И уже внутри формата просите содержание.

Чеклист: когда он лучший и как правильно его просить

Чеклист — идеальный формат, когда вам нужно снизить вероятность пропуска шага. Это формат контроля качества. Его сильная сторона — бинарность: «проверено/не проверено». Он особенно полезен для повторяющихся задач: подготовка отчёта, проверка текста, релиз, запуск рекламы, публикация, оформление договора, сбор требований.

Слабый чеклист — это список общих слов: «проверь качество», «убедись, что всё корректно». Сильный чеклист содержит наблюдаемые проверки.

Например, вместо «проверь структуру» — «в тексте есть: 1) цель, 2) контекст, 3) шаги, 4) критерии готовности, 5) риски». Вместо «проверь факты» — «все цифры и даты либо даны во входных данных, либо помечены как требующие проверки».

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

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

Если вы делаете чеклист один раз и потом используете постоянно, вы превращаете ИИ в инструмент стандартизации, а не в генератор текста.

Алгоритм: когда нужна процедура, а не список советов

Алгоритм нужен, когда важно не просто «что делать», а «в каком порядке» и «что делать, если условия разные». Алгоритм особенно полезен, когда есть развилки: если так — делаем A, если иначе — B. Это формат, который превращает рекомендации в процедуру.

Алгоритм должен отвечать на вопросы: какой вход; какой выход; какие шаги; какие условия перехода; что считать успехом; что делать при неуспехе.

Например, «алгоритм написания ТЗ» или «алгоритм проверки ответа ИИ на факты» будет сильнее, чем текст «как писать ТЗ» или «как проверять факты». Потому что алгоритм заставляет модель дать последовательность.

Как просить алгоритм: просите «если/то» -ветвления; просите обработку ошибок: «если данных нет — задать вопросы»; просите лимиты: «не более 12 шагов»; просите критерии завершения: «когда считать задачу выполненной».

План: чем он отличается от алгоритма и когда нужен

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

Хороший план содержит: этапы и задачи; ответственных; сроки и зависимости; метрики контроля; риски и меры снижения.

Плохой план — «сделайте анализ, потом улучшите, потом оптимизируйте». Это не план, а пересказ здравого смысла. Поэтому в запросе важно требовать конкретные артефакты и метрики.

Например, «план на 4 недели» должен содержать: что делаем на неделе 1/2/3/4; какой результат на выходе каждой недели; как измеряем прогресс; что является стоп-сигналом, чтобы не продолжать в неверном направлении.

Матрица решений: как выбирать варианты без вкусовщины

Когда вы просите ИИ «предложи варианты», вы часто получаете много вариантов без выбора. Это нормально для брейншторма, но плохо для управленческого решения. Чтобы перейти от вариантов к выбору, нужен формат матрицы.

Матрица решений — это критерии × варианты. Критерии могут быть качественными и количественными. Главное — чтобы они отражали ваши ограничения: бюджет, сроки, риск, трудозатраты, юридические ограничения, влияние на метрики.

Даже если вы не используете таблицы, матрицу можно описывать текстом: «критерии такие-то, оцени вариант A/B/C по каждому критерию по шкале 1–5, затем выбери лучший и объясни почему».

Как просить матрицу: задать критерии самому или попросить ИИ предложить и согласовать; задать веса критериев (например, риск важнее скорости); задать требования к итоговой рекомендации (один выбранный вариант + план внедрения).

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

Карта рисков: формат для задач, где цена ошибки высокая

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

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

Если вы просите такой формат, модель начинает думать как менеджер риска, а не как автор текста. И это резко повышает полезность.

Диагностический формат: «гипотеза → признаки → проверка»

Это один из самых сильных форматов для поиска причин. Когда у вас проблема (упали продажи, вырос CPL, просела конверсия, начались ошибки), вам не нужен рассказ о «возможных причинах». Вам нужен диагностический протокол.

Структура: гипотеза; что должно быть видно в данных, если гипотеза верна; что должно быть видно, если неверна; какие данные нужны; как проверить быстро и безопасно; какой следующий шаг.

Такой формат обрезает пустые рассуждения и делает ответ проверяемым.

Сценарий коммуникации: когда важнее слова и структура разговора

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

Сильный сценарий содержит: цель разговора; структуру (вступление → уточнение → предложение → фиксация); вопросы для диагностики; варианты ответов на типовые возражения; фразы для фиксации договорённостей; что записать после разговора.

Если вы просите такой формат, ИИ перестаёт «писать красиво» и начинает давать инструмент.

Комбинированные форматы: когда одной формы недостаточно

В сложных задачах один формат не закрывает всё. Например, вы внедряете процесс. Вам нужен план, чеклист контроля качества и карта рисков. Или вы пишете важный текст. Вам нужен черновик, затем чеклист проверки и список слабых мест.

Хорошая практика — просить выдачу в 2–3 слоя: слой 1: итог (коротко, что предлагаем); слой 2: структура/план (как реализуем); слой 3: контроль (чеклист, риски, критерии).

Так вы получаете не только «что делать», но и как не ошибиться.

Как выбирать формат: практическая таблица в голове

Без таблиц можно держать простое соответствие:

Нужно действие → план/алгоритм. Нужно избежать ошибок → чеклист. Нужно понять причину → гипотезы+проверка. Нужно выбрать из вариантов → матрица критериев. Нужно согласовать с людьми → сценарий коммуникации. Нужно снизить риск → карта рисков. Нужно стандартизировать повторяющуюся работу → регламент + чеклист.

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

Как форматом бороться с выдумками

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

Первый: требовать явное разделение фактов и допущений внутри формата. Например, «в каждом шаге: факт из вводных / допущение / что нужно проверить».

Второй: требовать «точку неопределённости». Это строка: «чего не хватает для точного решения». Когда это встроено в формат, модель перестаёт маскировать пробелы.

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

Практический блок: универсальные формулировки запросов под каждый формат

Ниже — готовые формулировки, которые вы можете использовать как шаблоны.

Запрос на чеклист: «Сделай чеклист проверки [объект], цель — исключить [тип ошибок]. Каждый пункт должен быть проверяемым. Добавь блок „красные флаги“ — 7 признаков, что работа сделана плохо. Запрет: не добавлять фактов, которых нет во входных данных; если нужно — сформулируй вопросы.»

Запрос на алгоритм: «Составь алгоритм выполнения [задача] в виде шагов с развилками „если/то“. Укажи входные данные, выход, критерии завершения, обработку случая, когда данных недостаточно. Не более 12 шагов, без общих фраз.»

Запрос на план: «Сделай план на [срок] для [цель]. Для каждой недели/этапа: задачи, ответственный (роль), ожидаемый результат, метрика контроля, риск и мера снижения. Учти ограничения: [список].»

Запрос на диагностику: «Составь диагностическую карту проблемы [симптом]. Формат: гипотеза → что подтвердит → что опровергнет → какие данные нужны → как проверить быстро и безопасно → следующий шаг. Не придумывай цифры и причины без привязки к вводным.»

Запрос на матрицу выбора: «Есть варианты A/B/C для [задача]. Сформулируй критерии выбора (5–7), задай веса, оцени каждый вариант по шкале 1–5, затем выбери лучший и объясни. Учитывай ограничения: [список].»

Запрос на сценарий коммуникации: «Составь сценарий разговора/сообщения для [цель], аудитория [кто], контекст [2–3 факта]. Структура: вступление → 5 вопросов диагностики → предложение → отработка 5 возражений → фиксация договорённостей. Тон: [какой]. Запреты: [какие].»

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

Глава 5. Антигаллюцинации на практике: как проверять ответы ИИ быстро и без паранойи

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

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

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

Что именно мы называем «галлюцинацией» в рабочем смысле

В бытовом смысле галлюцинация — это «выдумка». В рабочем смысле понятие шире. Ошибка ИИ может быть не только в факте.

Тип 1. Выдуманный факт: цифра, дата, цитата, название документа, термин, которого нет, либо он употреблён неверно.

Тип 2. Подмена причинности: факты могут быть верными, но вывод «почему» неверный или слишком смелый.

Тип 3. Скрытое допущение: модель строит решение на предпосылке, которую вы не давали, и не помечает её как допущение.

Тип 4. Неприменимость: ответ логичный, но не подходит к вашим ограничениям (регион, закон, платформа, ресурс, этап проекта).

Тип 5. Псевдоточность: всё звучит конкретно, но проверки и критерии отсутствуют, поэтому вы не можете подтвердить правильность.

Антигаллюцинации — это не только «проверить факты». Это ещё и выявить подмену причинности, допущения и непригодность.

Золотое правило: проверять не весь ответ, а точки риска

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

Обычно «точки риска» в ответе — это: цифры и статистика; юридические утверждения и нормы; обещания результата; диагнозы причин («потому что…»); рекомендации «делайте X» без условий; термины и названия (особенно редкие); инструкции, где порядок шагов критичен.

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

Протокол антигаллюцинаций: 7 шагов от дешёвого к дорогому

Шаг 1. Отделить факты от интерпретаций

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

Практический приём: попросите модель переписать ответ в формате: «Факты из вводных» (только то, что вы дали), «Выводы, которые следуют из фактов», «Гипотезы/допущения», «Что нужно проверить/уточнить».

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

Шаг 2. Найти и выписать «утверждения высокой ставки»

Утверждение высокой ставки — это фраза, которая при ошибке приведёт к серьёзным последствиям. Вы выписываете такие утверждения отдельным списком. Обычно их 5–15, а не 150.

Пример: «в РФ запрещено X», «конверсия должна вырасти на Y», «в вашей нише средняя цена лида такая-то», «по закону нужно сделать так-то», «этот метод всегда даёт результат».

Когда эти утверждения вынесены в список, их становится проще проверять и проще спорить с ними. В тексте они были «размазаны», в списке — становятся проверяемыми объектами.

Шаг 3. Проверка на «чужие факты» (самая частая галлюцинация)

Задайте себе вопрос: «Мог ли ИИ знать это из моего контекста?» Если вы не давали цифры, даты, конкретные названия, а они появились — это автоматически подозрительно. Не потому что обязательно неверно, а потому что это не основано на вашем вводе.

Практический приём: попросите модель поставить метки возле каждого фактического утверждения: [Дано пользователем] / [Вывод] / [Допущение] / [Требует проверки]. И затем удалить всё, что «требует проверки», если вы хотите безопасную версию.

Это создаёт две версии ответа: «безопасная» (основана на вашем вводе) и «расширенная» (с гипотезами).

Шаг 4. Проверка причинности через альтернативы

Очень опасная форма ошибки — когда факты верны, но причина выдумана. В маркетинге, продукте, управлении это происходит постоянно. Модель любит объяснять. Но «объяснение» не равно «диагноз».

Практический приём: требуйте 3–5 альтернативных причин и признаки, по которым их различить. Не «может быть так», а «если причина A — увидим это; если причина B — увидим то».

Формат: гипотеза причины; какой сигнал должен быть в данных; какой сигнал опровергнет; какой самый дешёвый тест.

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

Шаг 5. Проверка применимости к ограничениям

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

Практический приём: попросите модель сделать «проверку на ограничения»: перечисли мои ограничения; для каждого пункта ответа отметь, не нарушает ли он ограничения; если нарушает — предложи замену.

Это особенно полезно, когда у вас строгие запреты (например, нельзя упоминать определённые вещи, нельзя использовать каналы, нельзя приводить выдуманные кейсы). Такая проверка превращает модель в саморедактора и снижает риск «вставленных» неподходящих идей.

Шаг 6. Проверка на полноту: не пропущены ли обязательные блоки

Иногда ответ не «ложный», а «неполный», что в практике равно ошибке. Например, план действий без метрик, регламент без критериев готовности, текст без CTA, стратегия без рисков.

Практический приём: используйте стандартный контрольный набор блоков для вашей задачи. Примеры: для плана: цель → шаги → ответственные → сроки → метрики → риски → критерии завершения; для анализа: симптомы → гипотезы → данные → тесты → порядок проверки → вывод; для текста: цель → аудитория → тезисы → структура → CTA → ограничения.