Профессия: Промпт-инженер

Антон Золотавин

Профессия: Промпт-инженер

Профессия: Промпт-инженер

Антон Золотавин

Введение. От первого запроса к рабочему решению

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

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

Книга рассчитана на новичка. Для первых глав достаточно браузера, текстового редактора и таблицы. Позже появятся JSON, API и автоматизация, но сначала мы разберём их смысл на обычных примерах. Вы сможете пройти основной маршрут без программирования. Технические разделы помогут разговаривать с разработчиком и понять, что следует поручить программе, а что можно решить инструкцией.

Название профессии ещё не означает одинаковую работу во всех компаниях. Где-то специалист улучшает ответы внутреннего помощника, где-то готовит материалы с помощью генеративных моделей, а где-то участвует в разработке сложного приложения. Мы будем изучать общую основу: как превращать требования человека в проверяемую задачу для ИИ. Для конкретной должности к ней потребуется добавить знание отрасли и инструментов команды.

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

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

Как работать с практикумом

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

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

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

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

Глава 1. Что делает промпт-инженер

Работа начинается с задачи человека

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

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

Представьте запрос клиента: «Третий день жду посылку. Где заказ?» Модель может написать сочувственный ответ и придумать дату доставки. Для читателя текст будет выглядеть убедительно, а для магазина это опасное обещание. Рабочее решение должно понимать, что срок конкретного заказа нельзя получить из общего регламента. Оно запросит идентификатор в разрешённом канале или подготовит обращение к сотруднику.

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

Четыре направления работы

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

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

Третье направление — участие в разработке ИИ-продукта. Промпты работают внутри приложения, которое получает данные, обращается к инструментам и показывает результат пользователю. Здесь важны API, форматы данных, тесты, ограничения доступа и взаимодействие с разработчиком. Текст запроса становится одним из компонентов системы.

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

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

Что относится к компетенциям

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

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

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

Доход и формат занятости

В открытой выдаче hh.ru, просмотренной при подготовке книги, встречались позиции с разным содержанием: AI-креатор, специалист по развитию сайта и Senior Prompt Engineer для англоязычных СМИ. В отдельных объявлениях были указаны суммы до 100 000 рублей на руки и диапазон 100 000–250 000 рублей на руки. Эти числа описывают конкретные объявления и требования к опыту, а не среднюю зарплату профессии. Ссылки приведены в разделе источников [7].

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

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

Миф о секретной формуле

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

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

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

Практикум. Собственная карта навыков

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

Теперь разделите работу на части. Что может подготовить ИИ? Что требует проверки предметного эксперта? Что следует считать программой? Кто вправе выполнить внешнее действие? В задаче с протоколом модель может извлечь поручения, сотрудник подтвердит владельцев, программа проверит формат дат, а отправку участникам выполнит уполномоченный человек.

Сохраните описание как первую страницу «Задачи». В конце книги вернитесь к ней и сравните с итоговым решением. Это будет первое свидетельство вашего профессионального роста: вы научитесь точнее видеть процесс и границы автоматизации.

Глава 2. Как устроена работа с языковой моделью

Модель, чат и приложение

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

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

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

Контекст и токены

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

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

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

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

Почему ответы меняются

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

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

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

Инструкции разных уровней

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

Написать в обычном сообщении «SYSTEM» — не то же самое, что создать системное сообщение через поддерживаемый механизм. Аналогично, выделение документа тегами помогает обозначить границы, но не гарантирует защиту от вредоносных инструкций внутри него. Структура полезна для ясности; безопасность требует дополнительных мер.

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

Ошибка, пробел и отказ

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

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

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

Инструменты новичка

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

Российские читатели могут изучать инструкции и примеры GigaChat и Yandex AI Studio [4, 5]. Выбор рабочей платформы зависит от функций, условий доступа, политики организации и обработки данных. Перед передачей файлов проверьте официальный регламент, ограничения тарифа и возможности удаления или хранения материалов. Рекламное описание сервиса не заменяет эти документы.

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

Практикум. Проверка контекста

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

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

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

Глава 3. Постановка задачи и критерии качества

Перевод пожелания в результат

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

Начните с вопроса о дальнейшем использовании ответа. Кто его прочитает? Какое действие выполнит? Что произойдёт, если ответ будет неверным? Черновик для редактора допускает больше свободы, чем сообщение, которое автоматически отправляется клиенту. Памятка для новичка требует другого объяснения, чем отчёт для специалиста.

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

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

Паспорт задачи

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

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

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

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

Обязательные условия и предпочтения

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

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

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

Проверяемые критерии

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

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

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

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

Когда задавать уточняющий вопрос

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