Александр Костин – ИИ для управления проектами: планы, риски, сроки, контрольные точки (страница 2)

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

Роль формата: почему «таблица/чеклист/план» режет воду

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

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

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

Роль ограничений: что запрещать прямо в запросе

Ограничения – это те самые «перила», которые не дают ответу улететь в фантазии. Запреты должны быть прямыми и конкретными. «Не выдумывай» хорошо, но лучше – «не добавляй цифры, даты, названия документов, статистику и ссылки, если они не даны во входных данных». Ещё лучше – «если данных нет, напиши: “недостаточно данных”, и перечисли, что нужно уточнить».

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

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

Артефакт: чеклист «почему ответ получился плохим»

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

Проверьте, что именно пошло не так.

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

В ответе много общих слов и мало действий. Это признак слишком общего запроса. Решение: заменить тему на результат и требовать конкретный формат «шаги + критерии готовности».

В ответе появились цифры, статистика, «исследования», которых вы не давали. Это признак заполнения пустоты. Решение: запретить любые факты, которых нет во входных данных, и требовать вопросы при нехватке информации.

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

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

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

Ответ слишком «красивый» и мало полезный. Это признак эстетических требований. Решение: заменить «красиво» на критерии: ясность, однозначность, применимость, проверяемость.

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

В ответе нет рисков и ограничений. Это признак «презентационного» режима. Решение: требовать блок «риски и как снизить» и «что может быть неверно».

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

63

Глава 2. Как задавать вопросы, чтобы ИИ перестал «додумывать»: конструкция запроса как инженерная работа

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

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

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

Почему «одна фраза» почти всегда проигрывает

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

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

Поэтому правило простое: если задача важная, запрос должен быть многослойным. Не длинным ради длины, а состоящим из нужных блоков. У вас может быть 10 строк, но они должны быть правильными.

Четыре слоя хорошего запроса

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

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

Второй слой – контекст. Минимальный бриф: кто вы, что за проект, какие ограничения и вводные. Здесь важна не полнота, а релевантность. Если вы пишете оффер для клиники, важны аудитория, регион, тип услуг, конкурентная среда, ценовой сегмент, ограничения по рекламе, юридические риски. Если вы просите техническое решение, важны платформа, интеграции, уже сделанные шаги, что не работает, какие есть ограничения по доступам.

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

Четвёртый слой – формат результата. Модель подстраивается под формат очень сильно. Если вы не задали формат, она выбирает повествование. Если вы задали формат, она строит выдачу в нужной структуре. Это может быть: план внедрения по дням, чеклист проверки, сценарий звонка, структура статьи, таблица рисков (если таблицы допустимы), список гипотез с планом проверки, список альтернатив с критериями выбора.

Эти четыре слоя не обязаны быть длинными. Они обязаны быть ясными.

Пятый слой, который отделяет профессионала: критерии готовности

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

Примеры критериев готовности для разных задач.

Для текста: «тон нейтрально-деловой», «без обещаний, которые нельзя выполнить», «без канцелярита», «первый абзац сразу по сути», «не упоминать источники и ссылки», «объём 2500–3500 знаков», «3 аргумента, 1 призыв к действию», «без воды и общих фраз».

Для стратегии: «3 сценария бюджета», «каждый пункт – действие, измеримое метрикой», «у каждого действия: цель, инструмент, срок, риск, критерий успеха», «план на 4 недели», «учесть ограничение по ресурсу: 1 специалист 20 часов в неделю».

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