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

Запрос, который становится рабочим заданием

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

Возьмём одно и то же письмо клиенту.

«Добрый день! По счёту №417 от 10 июня в нашей системе пока не отображается оплата. Отгрузка заказа запланирована на 18 июня. Если платёж уже отправлен, направьте копию платёжного поручения, чтобы мы проверили его у банка. Если оплаты ещё не было, сообщите, когда её ожидать. После подтверждения оплаты мы уточним статус отгрузки».

К этому письму можно добавить короткую команду: «Сделай покороче».

Результат может выглядеть так:

«Добрый день! Оплата по счёту №417 не поступила. Пришлите платёжное поручение или сообщите срок оплаты».

Или так:

«Коллеги, отгрузка 18 июня под угрозой из-за неоплаченного счёта. Срочно подтвердите оплату».

Или ещё жёстче:

«Счёт №417 не оплачен. Отгрузка не состоится до подтверждения оплаты».

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

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

Мифы, из-за которых запросы не работают

Миф первый: чем короче запрос, тем лучше.

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

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

Миф второй: модель сама поймёт контекст из приложенного текста.

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

Миф третий: достаточно назначить роль.

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

Миф четвёртый: неудачный результат нужно просто попросить переделать.

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

Миф пятый: удачный пример не нужен, достаточно описать тон словами.

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

Конструкция рабочего запроса

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

Роль

Роль — это рабочая позиция модели в конкретной задаче. Она не должна звучать как украшение. Сравните:

«Ты — профессионал высокого уровня».

«Ты — редактор деловой переписки. Сохраняй подтверждённые факты и не усиливай утверждения».

Во втором варианте есть функция и граница ответственности. Для сводки встречи подойдёт роль аналитика протоколов, для обработки обращений клиентов — классификатора входящих сообщений, для повестки — координатора рабочих совещаний.

Роль не наделяет модель правом принимать решения за пользователя. Фраза «Ты — руководитель проекта» не означает, что модель может назначить ответственных или утвердить дату. Если такого права нет в исходных данных, она должна обозначить пробел.

Цель

Цель отвечает на вопрос: зачем нужен результат? Фраза «Сделай покороче» описывает действие над текстом, но не объясняет, какого эффекта нужно добиться.

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

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

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

Исходные данные

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

Полезно обозначать границы источника прямо:

«Используй только текст обращения ниже».

«Даты бери из блока “Подтверждено”».

«Не используй сведения из старой версии инструкции».

«Если в материалах есть противоречие, остановись и укажи на него».

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

Адресат

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

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

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

Ограничения

Ограничения определяют, что нельзя потерять и что нельзя добавлять. Здесь задаются длина, тон, допустимые утверждения, обязательные элементы и запрещённые действия.

Например:

«Не называй оплату просроченной: в системе пока отсутствует только подтверждение».

«Не меняй даты и номера документов».

«Не обещай клиенту новую дату отгрузки».

«Не используй обвинительные формулировки».

«В каждой строке классификации указывай только одну основную категорию».

Ограничение должно быть проверяемым. Фраза «сделай красиво» не проверяется. А условие «не более 600 знаков, одна просьба о действии, без восклицательных знаков и без новых фактов» вполне можно проверить.

Форма выдачи

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

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

К этой конструкции добавляются ещё два элемента.

Проверка предположений

Перед выполнением задачи модель должна отделить подтверждённые факты от предположений и неизвестных данных.

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

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

Неизвестное — обстоятельство, для которого в материалах недостаточно данных. Например, неизвестно, отправил ли клиент платёж, кто должен согласовать итог встречи или можно ли перенести совещание.

В рабочий запрос полезно вставлять такой блок:

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

Такой фильтр не заставляет модель задавать вопросы по каждой мелочи. Неизвестная форма приветствия обычно не блокирует письмо: можно выбрать нейтральное обращение. А неизвестность в вопросе о том, был ли отправлен платёж, не позволяет утверждать, что счёт не оплачен.

Критерий готовности

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

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

Лабораторное упражнение

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

Затем разберите задачу по семи шагам.

Сначала назовите действие, которое адресат должен выполнить после получения результата.

Затем выпишите только те материалы, на которые модель имеет право опираться.

После этого разделите сведения на факты, предположения и неизвестные.

Далее опишите адресата не одним словом, а через его задачу: что он знает, чего не знает и что должен сделать.

Следом укажите ограничения, которые нельзя нарушить.

Потом задайте форму выдачи.

И наконец, сформулируйте условие «готово, если».

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

Четыре задачи через один шаблон

Письмо клиенту

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

Исходные данные: по счёту №417 от 10 июня в системе пока не отображается оплата; отгрузка запланирована на 18 июня; если платёж уже отправлен, клиент может прислать копию платёжного поручения; если оплаты ещё не было, клиент может сообщить ожидаемую дату.

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

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

Остаётся неизвестным, отправил ли клиент платёж, актуальна ли дата отгрузки, нужно ли копировать в письмо менеджера по продажам и насколько формальным должно быть обращение.

Рабочий запрос:

Роль: ты — редактор деловой переписки.

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

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

Адресат: представитель компании-клиента, знакомый с заказом, но, возможно, не видевший предыдущую переписку.

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

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

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

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

Такой запрос не заставляет модель угадывать, что означает «короче». Короткость здесь измеряется количеством предложений, а качество — сохранением фактов и понятным действием.

Сводка встречи

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

Исходные данные: встреча длилась 45 минут; обсуждалось обновление внутренней инструкции; в заметках есть предложение завершить работу к 20 июня; обсуждалась необходимость согласования с ответственным подразделением; ответственный и окончательный срок не указаны.

Факты: дата и продолжительность встречи, её тема, наличие предложения о сроке и наличие вопроса о согласовании.

Предположения: дата 20 июня утверждена; обновление инструкции поручено конкретному сотруднику; все участники согласились с предложением.

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

Рабочий запрос:

Роль: ты — аналитик рабочих протоколов.

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

Материалы: используй только заметки встречи. Не добавляй сведения из общих знаний или старых протоколов.

Адресат: участники встречи и руководитель проекта.

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

Форма: разделы «Решения», «Поручения», «Открытые вопросы». Для каждого поручения укажи действие, ответственного и срок; при отсутствии данных поставь отметку «не указано».

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

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

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

Классификация обращений

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

Представим, что на вход поступают сообщения:

«В личном кабинете сумма заказа списалась дважды».

«Заказ доставлен, но одного товара внутри нет».

«После смены номера телефона не получается войти в личный кабинет».

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

Факты: тексты обращений, утверждённый список категорий и необходимость выбрать рабочую очередь.

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

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

Рабочий запрос:

Роль: ты — классификатор входящих обращений.

Цель: присвоить каждому сообщению одну основную категорию для передачи в рабочую очередь.

Материалы: используй только текст обращения и список категорий ниже.

Адресат: оператор первой линии, который будет направлять сообщения дальше.

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

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

Проверка предположений: не выдавай предположение за факт. В формулировке «сумма списалась дважды» сохрани именно утверждение клиента, а не вывод о подтверждённом двойном списании.

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

В этом примере полезно требовать короткое основание. Если модель просто выдаст категорию, сотрудник не увидит, почему она так решила, и не сможет быстро исправить спорную строку.

Подготовка повестки

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

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

Факты: продолжительность встречи, цель выбора, два варианта, роли участников и наличие материалов.

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

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

Рабочий запрос:

Роль: ты — координатор рабочей встречи.

Цель: составить повестку на 45 минут, которая приведёт участников к выбору даты запуска или зафиксирует, почему решение перенесено.

Материалы: используй описание двух вариантов и список рисков. Не добавляй новые критерии и не назначай ответственных без указания в исходных данных.

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

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

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

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

Критерий готовности: сумма времени равна 45 минутам, в повестке есть блок принятия решения и блок фиксации итогов, а подготовка участников понятна заранее.

Здесь результат можно проверить арифметически: время должно сходиться. Это хороший пример критерия, который не зависит от впечатления редактора.

Как использовать образец

Образец — не украшение и не повод копировать старый текст. Это сжатая демонстрация структуры. Один удачный пример письма может заменить несколько абзацев о желаемом тоне.

Например, в библиотеку можно положить такой обезличенный образец:

Тема: Статус оплаты по счёту №[номер]

Добрый день!

По счёту №[номер] оплата пока не отображается в нашей системе. Если платёж уже отправлен, пришлите, пожалуйста, платёжное поручение для проверки. Если оплата ещё не проведена, сообщите ориентировочную дату. После проверки мы вернёмся со статусом заказа.

С уважением,

[подпись]

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

В новый запрос стоит вставить не только сам образец, но и правило его использования:

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

Обычно одного чистого образца достаточно. Три образца могут быть полезны, если они показывают разные допустимые случаи: первое обращение, напоминание и ответ на претензию. Но противоречивые примеры без объяснения только увеличат неопределённость.

Как превращать удачный запрос в рабочий актив

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

Для этого подойдёт карточка запроса.

Название задачи: «Клиентское письмо — запрос статуса оплаты».

Назначение: получить от клиента подтверждение платежа или ожидаемую дату оплаты без обвинительных формулировок.

Роль: редактор деловой переписки.

Версия: 0.1.

Дата создания: [дата].

Последняя дата улучшения: [дата].

Исходный пример: обезличенный текст письма и описание ситуации.

Текст запроса: полная рабочая формулировка со всеми слоями.

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