Промпт-инженер: работа строится вокруг задачи, тестов и правок, а не хитрой фразы. Разбираю учебный пилот с письмами и способ показать навык работодателю.
М
Марина
Контент-маркетолог LibraChat
9 мин чтения
Промпт-инженер: работа такого специалиста видна не по эффектному запросу в чате, а по тому, насколько надёжно команда получает нужный результат на разных входных данных. Я разберу один учебный пилот с письмами клиентам: от постановки задачи до проверки ошибок. Если тебя привлекает эта роль, к концу статьи у тебя будет план небольшого проекта для портфолио, а не коллекция «секретных формул».
Пять красивых запросов у меня уже были. Один просил модель говорить как опытный редактор, второй требовал «максимальной точности», третий делил ответ на шаги. На учебном письме каждый выглядел убедительно. А затем в примере без подтверждённого срока черновик обещал клиенту конкретную дату. Я поняла, что улучшала форму запроса, не описав правило, по которому письмо вообще можно отправлять.
Промпт-инженер: работа начинается до первого запроса
Возьмём конкретную задачу: сотрудник поддержки готовит черновик ответа на типовой вопрос клиента. Команда хочет сократить время на набор текста, но не вправе обещать неподтверждённый срок. Промпт-инженер не должен начинать с подбора роли вроде «ты лучший консультант». Сначала он выясняет, откуда берутся факты, что сотрудник может утверждать и кто принимает финальную версию.
Я собрала бы учебный набор из 12 вымышленных обращений. Четыре содержат полную информацию, четыре — недостающую дату или номер заказа, ещё четыре — противоречие между старым и новым условием. Никаких клиентских имён и реальных договоров. Такой набор не доказывает качество сервиса на производстве, зато показывает, какой вид ошибки надо искать. Один удачный пример этого не покажет.
Карточка задачи получается короткой:
Вход: обезличенный вопрос и утверждённая памятка с фактами.
Выход: черновик ответа на один экран и список сведений, которых не хватило.
Запрет на догадки: нельзя добавлять сроки, цены или условия вне памятки.
Проверка: сотрудник сравнивает черновик с исходным вопросом и памяткой.
Остановка: если условия конфликтуют, письмо не готово к отправке.
Я показываю карточку владельцу процесса до работы с моделью. Иногда выясняется, что «утверждённая памятка» существует в двух версиях. Тогда проблема не в промпте: у команды нет одного источника истины. Запрос к ИИ только замаскирует расхождение, потому что оба текста будут звучать одинаково уверенно.
Версия 0: как понять, что стало лучше
Для сравнения нужен исходный способ работы. В учебном проекте я беру три обращения и прошу коллегу без помощи ИИ написать короткие ответы по памятке. Мы не измеряем его как сотрудника; фиксируем, какие факты он проверил и где возник вопрос к руководителю. Это даёт ориентир для качества и показывает, что часть задач даже человеку нельзя закрыть без уточнения.
После этого я формулирую первую версию запроса к LibraChat. Сервис помогает писать и переписывать тексты, а диалог позволяет уточнять задачу. Но предложенный ниже промпт — шаблон для читателя, не запись фактически полученного ответа:
«Ниже учебный вопрос клиента: [обезличенный текст]. Подтверждённые сведения: [пункты актуальной памятки]. Предложи письмо до 120 слов: суть, что уже известно, следующий шаг. Если срока, условия или номера нет среди подтверждённых сведений, перечисли вопросы сотруднику отдельно. Не превращай предположение в обещание клиенту».
У первой версии есть проверяемое слабое место. Она просит отдельные вопросы, но не говорит, что делать, когда два пункта памятки противоречат друг другу. Если учебный пример содержит старую и новую дату, модель может выбрать одну. Я не считаю такой ответ успешным, даже если письмо звучит спокойно. Проверка должна видеть конфликт, а не только хорошую грамматику.
Я записываю критерии до просмотра черновиков. Иначе легко подменить задачу: понравился тон — объявили проект удачным. Моя таблица не оценивает художественность письма; она проверяет условия, из-за которых письмо можно или нельзя отправить.
Критерий · Что смотрю в каждом примере · Что считаю ошибкой
Смысл вопроса — Ответ касается просьбы клиента — Уход в общую консультацию
Факты — Каждое утверждение есть в памятке — Новый срок или неподтверждённое условие
Неизвестное — Пробел вынесен в вопрос сотруднику — Догадка спрятана в текст письма
Конфликт — Две версии сведений помечены отдельно — Молчаливый выбор одной версии
Передача — Человеку ясно, что проверить — Черновик выглядит готовым без оснований
Версия 1: исправить не фразу, а правило
Когда я вижу ошибку с конфликтом, хочется добавить в промпт грозное «никогда не ошибайся». Это бесполезно: критерий всё ещё не описан. Я переписываю конкретный участок: «Если два подтверждённых пункта противоречат друг другу, не составляй финальное письмо. Назови оба пункта и попроси сотрудника выбрать актуальный источник». Теперь у модели есть действие на спорном входе.
После правки я повторяю ту же учебную подборку из 12 обращений. Проверяю не только пример, который прежде провалился: новая инструкция могла ухудшить простой случай и начать задавать лишние вопросы там, где ответ уже известен. В таблице отмечаю для каждого примера тип ошибки, а не только общую оценку. Если сложно понять, почему строка была зачтена, критерий слишком расплывчатый.
Так появляется то, что я действительно назвала бы инженерной частью работы: версия задачи, набор случаев, правило проверки, найденный сбой и следующая версия. Точный набор обязанностей зависит от компании; отдельного универсального стандарта должности я не предполагаю. Но человек, который может объяснить эту цепочку, полезен в команде сильнее, чем обладатель длинного списка готовых промптов.
Небольшое улучшение стоит записывать честно. Не «качество выросло в два раза», если ты просто посмотрел три письма. Напиши: «На учебной подборке я нашла две повторяющиеся ошибки и уточнила инструкцию; результат для реальных обращений ещё не проверен». Такая фраза не продаёт чудо. Она показывает, что ты различаешь пробу и доказанный рабочий результат.
Как разобрать провал, который выглядит успехом
Самая неприятная строка в учебной таблице — та, где письмо приятно читать, но ответ нельзя отправить. Допустим, вопрос клиента касается даты, а в подтверждённых сведениях только «работа идёт». Черновик может вежливо обещать обновление завтра. Внешне это забота. Внутри — новое обязательство. Я отмечаю такую строку как ошибку фактов, даже если тон, длина и структура прекрасны.
Другой вид провала тише. Модель перечислила вопросы сотруднику, но оставила в основном письме фразу, которая предполагает ответ на один из них. Для проверки я разделяю черновик на две части: что можно отправить клиенту сейчас и что остаётся внутренним вопросом. Если граница размыта, запрос нужно уточнить. Нельзя исправлять только послесловие, оставив рискованное обещание в начале письма.
Я веду простой журнал с четырьмя полями: номер учебного случая, наблюдаемая ошибка, правило, которое её допустило, и следующая версия инструкции. Поле «виновата модель» не помогает. Оно не даёт коллеге возможности повторить проверку. А запись «в случае без срока инструкция всё равно разрешала формулировку про завтра» показывает конкретный участок работы.
После каждого исправления я оставляю один случай, который раньше проходил хорошо, как контроль от побочного эффекта. Если новый запрос начал отказывать в каждом простом письме, проблема не решена: команда потеряла полезный сценарий. Так проверка становится двусторонней. Мы ищем не только исчезновение опасного обещания, но и сохранение нужной помощи там, где исходных фактов достаточно.
Что добавить к запросу, кроме роли и тона
Хорошая роль в запросе бывает полезна, но она не заменяет четыре опоры. В официальных материалах Microsoft о работе с Copilot отдельно выделяются цель, контекст, ожидания и источник. Для нашего задания это переводится в простые вопросы: какое письмо нужно, какие факты разрешены, каким должен быть формат и откуда взяты сведения. Я бы поставила их раньше красивых слов о стиле.
Когда задача повторяется, я держу рядом две версии инструкции: короткую для сотрудника и подробную для проверки. В короткой написано, какой материал вставить и где увидеть вопросы модели. В подробной — почему каждое правило существует и какой сбой оно предотвращает. Если всё сложить в один гигантский промпт, коллегам трудно понять, что можно менять, а что требует согласования.
Для работы с клиентскими данными есть отдельная граница. Учебный бриф можно сочинить самой; реальную переписку, персональные сведения и внутренние документы нельзя отправлять в сервис без разрешённого процесса. Я сначала проверяю правила команды и убираю лишние поля. Инструкция «сохраняй конфиденциальность» в тексте промпта не заменяет решение о доступе.
Продуктовые условия тоже стоит сверять перед внедрением. У LibraChat есть работа с текстом и проектами с инструкциями, но доступность режимов зависит от тарифа. Проект может держать общие инструкции для разговоров внутри него; это не значит, что туда стоит загружать всю клиентскую базу. Я бы начала с разрешённого учебного материала и только затем обсуждала с владельцем процесса, какие рабочие сведения нужны.
Промпт-инженер: работа в портфолио без театра
Если ты ищешь такую работу, не показывай работодателю только снимок удачного ответа. Покажи постановку задачи и критерий, который можно опровергнуть. В нашем примере это означает: текст карточки, 12 обезличенных ситуаций, таблица ошибок, две версии запроса и объяснение, почему вторую пришлось изменить. Можно обойтись без коммерческих данных и без утверждения, что ты внедрил инструмент в компании.
Я бы собрала портфолио из трёх страниц:
Постановка: кому нужен результат, какие факты допустимы, что считается ошибкой.
Проверка: примеры разных типов и заполненная таблица критериев, включая неудобные случаи.
Итерация: что изменилось в инструкции после обнаруженного сбоя и что ещё не проверено.
На собеседовании тебя могут спросить, почему ты не приняла красивое письмо. Ответ «потому что оно обещало неутверждённую дату» показывает понимание реальной задачи. Ответ «потому что модель могла галлюцинировать» слишком общий: он не объясняет, какую именно ошибку ты заметила и как исправила процесс. Я тренируюсь на конкретных строках, которые другой человек сможет проверить.
Профессия меняется вместе с инструментами, поэтому я бы не привязывала навык к одной кнопке или модели. Сохраняются умение уточнять задачу, оценивать результат и разговаривать с владельцем данных. В материале «Вакансии с нейросетями без опыта в IT» можно посмотреть смежный карьерный угол. Если хочешь собрать учебный пилот, сравни доступные условия на странице тарифов, затем открой чат LibraChat с вымышленным обращением. Попробуй сегодня составить не идеальный промпт, а первый случай, на котором твой черновик обязан остановиться.
