Описание: как объяснить ИИ задачу

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

Представьте нового коллегу

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

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

Модель 4D раскладывает описание на три слоя: результат, процесс, поведение. Разберём каждый.

Описание результата

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

Формат. Письмо, таблица, список, документ с заголовками, код на конкретном языке, JSON. Если формат важен, покажите образец — модель повторит структуру точнее, чем поймёт описание.

Объём. «Три абзаца», «не больше 20 пунктов», «одна страница». Без ограничения модель обычно пишет длиннее, чем нужно.

Аудитория. Для кого текст: для клиента без технического бэкграунда, для разработчика, для руководителя, у которого две минуты. От этого зависят и лексика, и уровень детализации.

Тон и стиль. Деловой, нейтральный, дружелюбный; на «вы»; без восклицаний; без маркетинговых оборотов. Если у команды есть гайд по стилю, вставьте его.

Обязательное и запрещённое. Что точно должно быть (два вопроса клиенту в конце письма; ссылка на документ) и чего быть не должно (никаких сроков, которых нет в исходнике; никаких предположений о бюджете).

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

Описание процесса

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

Типичные инструкции процесса:

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

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

Описание процесса — главное средство против заполнения пробелов. Инструкция «разделяй сказанное и предполагаемое» превращает опасную привычку модели в полезный список вопросов.

Описание поведения

Третий слой — как модели вести себя в диалоге. Его чаще всего забывают, а он определяет, насколько удобно работать.

• Краткость или подробность. «Отвечай коротко, без вступлений и итогов» или «объясняй подробно, я разбираюсь в теме впервые».
• Спорить или соглашаться. «Если считаешь, что я неправ, скажи об этом прямо и объясни почему». Без этой инструкции модель склонна соглашаться.
• Спрашивать или действовать. «Если задача неоднозначна — спроси» или, наоборот, «не задавай вопросов, сделай лучшее предположение и отметь его».
• Роль. «Ты — опытный тестировщик, который придирается к формулировкам» или «ты — клиент, которому дорого и страшно». Роль задаёт точку зрения, с которой модель смотрит на задачу.
• Границы. «Не предлагай менять архитектуру, только исправляй логику внутри функции».

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

Собираем шаблон

Три слоя укладываются в короткую структуру, которую можно держать под рукой:

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

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

Пример для менеджера целиком: «Контекст: я менеджер проекта по мобильному приложению, ниже — заметки со стендапов за неделю и список задач из трекера. Результат: письмо клиенту, 150–200 слов, три блока — сделано, в работе, нужно от вас; в конце два вопроса, требующие его решения. Тон деловой, спокойный, без восклицаний. Не добавлять ничего, чего нет в заметках. Процесс: сначала выпиши факты из заметок, потом пиши письмо. Поведение: если по какому-то факту неясно, готов он или нет, — спроси меня, а не сглаживай».

Типичные ошибки описания

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

Противоречивые требования. «Кратко, но подробно», «формально, но по-дружески». Модель выберет одно, и не факт, что то, которое вы имели в виду.

Перегрузка. Страница инструкций на задачу в три строки. Модель может потерять главное среди второстепенного. Инструкция должна быть пропорциональна задаче.

Без примера там, где он всё решает. Если у команды есть три готовых чек-листа, приложите один — это лучше любого описания формата.