Роза Роуль – Работать с ИИ, а не верить ему (страница 2)
Задание 2. Возьмите старый ответ ИИ и отметьте цветом факты, мнения, предположения и рекомендации. Запишите исходное состояние, выбранное действие и признак, по которому через неделю можно оценить результат.
Задание 3. Сформулируйте личное правило: какие данные вы никогда не передаете внешнему сервису. Запишите исходное состояние, выбранное действие и признак, по которому через неделю можно оценить результат.
Практическая ценность появляется в цикле: наблюдение, ясная постановка, черновик, проверка и улучшение. Чем лучше описан этот цикл, тем меньше зависимость от случайного ответа и тем легче передавать работу коллегам.
Глава 2. Запрос как техническое задание
Хороший запрос похож не на волшебную фразу, а на короткое техническое задание. Он сообщает, что происходит, для кого создается результат, в каком виде его нужно вернуть и по каким признакам будет оцениваться качество. Не существует универсальной формулы, которая всегда дает идеальный ответ: задачи различаются, входные данные бывают неполными, а ожидания меняются по мере работы. Зато существует надежный способ итерации. Сначала создается минимально ясная постановка, затем изучается ответ, обнаруживаются пробелы, уточняются критерии и только после этого готовится финальная версия.
Основные опоры
Роль задает перспективу. Указание роли полезно, когда оно определяет угол анализа: редактор замечает структуру, методист думает о навыках, финансовый аналитик проверяет допущения. Декоративные титулы вроде «гениальный эксперт» редко добавляют качества. В реальном проекте это правило экономит время только при регулярном применении. Его не нужно превращать в сложный регламент: достаточно короткой проверки, примера допустимого результата и понятного владельца решения.
Цель должна быть наблюдаемой. Фраза «сделай хорошо» не объясняет, что считать успехом. Наблюдаемая цель описывает действие читателя, нужное решение, допустимый объем и признаки готовности. Такой подход сохраняет управляемость. ИИ предлагает варианты быстро, но человек определяет границы и принимает последствия. Хорошая привычка — после каждого крупного этапа формулировать, какое решение уже принято, а что пока остается гипотезой.
Материал важнее красноречия. Даже идеальная инструкция не заменяет исходные данные. Пример письма, таблица характеристик, цитаты клиентов и перечень ограничений уменьшают количество фантазии в ответе. Особенно важно применять правило к материалам, которые будут повторно использоваться. Ошибка в единичном черновике заметна быстро, а ошибка в шаблоне размножается. Поэтому удачные решения фиксируют вместе с условиями, при которых они работают.
Формат экономит редактуру. Просьба вернуть таблицу, план из шести пунктов, JSON, письмо или список вопросов помогает сразу получить удобную заготовку. Формат особенно важен, если результат дальше идет в другой процесс. Практический смысл принципа проявляется в момент выбора: он помогает решить, что поручить системе, что оставить человеку и какой промежуточный результат запросить. Перед началом работы полезно записать один наблюдаемый признак, по которому будет понятно, что принцип соблюден.
Критика должна быть направленной. Вместо «переделай» полезнее написать, что именно не устраивает: слишком общий тон, нет доказательств, нарушена последовательность, отсутствует призыв к действию или текст труден для новичка. Это не теоретическая оговорка, а способ сократить переделки. Если правило игнорировать, черновик может выглядеть завершенным, хотя в нем отсутствует важная опора. Поэтому принцип стоит превратить в вопрос контрольного списка и задавать его перед публикацией.
Рабочий маршрут
Шаг 1. Собрать контекст. В двух-трех предложениях опишите ситуацию, текущий этап и ограничения. Контекст отвечает на вопрос, почему эта работа нужна сейчас. Проверяйте результат на одном реальном и одном неудобном примере. Обычный случай показывает, что основная логика работает, а неудобный выявляет скрытые предположения. Не добавляйте следующий уровень сложности, пока оба примера не проходят проверку.
Шаг 2. Назвать аудиторию. Укажите знания, интересы и возможные возражения читателя. Один текст нельзя одинаково писать для владельца компании, школьника и разработчика. Здесь полезна короткая пауза между генерацией и оценкой. Сразу после получения ответа легко принять гладкую формулировку. Вернувшись к задаче через несколько минут, проще заметить пропуски, лишние обещания и расхождение с исходной целью.
Шаг 3. Приложить опорный материал. Передайте данные, на которых должен строиться ответ. Если материал длинный, сначала попросите его классифицировать и кратко пересказать. Не измеряйте успех количеством созданного текста. Шаг завершен, когда результат можно использовать дальше: согласовать, протестировать, передать, посчитать или опубликовать после предусмотренной проверки.
Шаг 4. Задать структуру выдачи. Определите заголовки, число вариантов, форму таблицы, порядок блоков и желательный объем. Так результат легче сравнивать с ожиданиями. На этом этапе не стремитесь к идеальной формулировке. Нужен небольшой артефакт — заметка, таблица, план или тестовый файл, который можно показать другому человеку и проверить. Завершайте шаг короткой записью: что получено, что неизвестно и кто принимает следующее решение.
Шаг 5. Ввести критерии проверки. Попросите проверить соответствие цели, отсутствие неподтвержденных утверждений, ясность и соблюдение ограничений. Самопроверка не заменяет человека, но находит часть простых дефектов. Если исходных данных мало, не разрешайте модели тихо заполнять пробелы. Попросите перечислить недостающие сведения и обозначить допущения. Такой режим может казаться медленнее, но он уменьшает риск красивой работы не по той задаче.
Шаг 6. Провести второй проход. Во втором запросе не начинайте все заново. Сошлитесь на конкретный вариант, перечислите изменения и попросите сохранить удачные элементы. Сохраните промежуточную версию и дату. Это дает возможность сравнить изменения, вернуться к устойчивому варианту и понять, какая правка действительно улучшила результат. Для повторяемой услуги шаг постепенно превращается в шаблон.
Разбор ситуации
Рассмотрим пример: Денис и проект — студия деловых презентаций «Кадр и смысл». Исходная ситуация выглядела так: готовил предложение для сети языковых школ и получал шаблонный текст без учета закупочной процедуры. Вместо попытки получить один идеальный ответ он добавил роли участников решения, бюджетный диапазон, обязательные разделы и образец прошлогоднего документа; попросил сначала построить карту требований, а потом написать разделы по одному. В итоге предложение стало конкретнее, в нем появились измеримые результаты, а команда использовала структуру как шаблон для следующих тендеров. Отдельно была сохранена ручная точка контроля. Это не замедлило процесс, а позволило использовать шаблон повторно без накопления незаметных ошибок.
Запросы для практики
Вариант 1. «Ты работаешь как редактор технического задания. Задай мне не более семи вопросов, без которых нельзя подготовить [результат]. После ответов собери краткое ТЗ.» Сохраните удачную формулировку в личной библиотеке вместе с пояснением, для каких задач она работает и когда ее нельзя применять.
Вариант 2. «Верни результат в таблице с колонками: элемент, назначение, исходные данные, критерий качества, риск ошибки.» Такой запрос полезно дополнять собственными данными и примером желательного результата. Ответ рассматривается как заготовка, а не как готовая экспертиза.
Вариант 3. «Подготовь три концепции для [задача]. Они должны различаться по аудитории и механике, а не только по словам. Объясни различия.» После первой выдачи выберите один вариант и перечислите точечные изменения. Не просите случайно переписать все заново, если часть решения уже подходит.
Вариант 4. «Проверь текст ниже против критериев: конкретность, доказательность, понятность, соблюдение тона и отсутствие лишних обещаний. Дай только список точечных правок.» Перед использованием удалите конфиденциальные сведения и замените их условными обозначениями. Числа, имена и внешние факты проверяются отдельно.
Типичные ошибки
Перегружать запрос десятками несовместимых ролей. Ошибка особенно опасна в повторяемом шаблоне: ее могут не заметить несколько клиентов подряд. Проверяйте не только удачный пример, но и ситуацию, в которой правило не должно применяться.
Скрывать важные ограничения до финального этапа. Чаще всего это следствие слишком широкой цели. Вернитесь к одному результату, одному владельцу решения и одному критерию готовности.
Требовать пошаговые внутренние рассуждения вместо проверяемого результата. Проблема возникает потому, что удобство подменяет доказательство. Заранее определите простой защитный прием: независимую проверку, ограничение данных, тестовую копию или обязательное согласование.
Менять цель в середине диалога и не сообщать об этом. Такой ход обычно экономит минуты в начале и создает часы исправлений позже. Добавьте в процесс явный вопрос, который останавливает работу до появления нужных сведений.
Рабочая тетрадь
Задание 1. Перепишите расплывчатую просьбу «сделай продающий текст» в техническое задание из шести полей. Запишите исходное состояние, выбранное действие и признак, по которому через неделю можно оценить результат.