Часть 2. Промпт-инжиниринг · Глава 4
Что такое промпт
Цели раздела
3 пунктаК концу раздела вы сможете:
- Изучить и научиться применять фундаментальную структуру эффективного запроса.
- Понимать каждый компонент метода RTCCO.
- Создавать предсказуемые и воспроизводимые промпты.
Промпт как техническое задание для модели
Эффективный промпт следует рассматриваться как техническое задание для LLM: чёткое, структурированное, полное и однозначное описание того, что требуется получить.Аббревиатура RTCCO: Role → Task → Context → Constraints → Output
Компоненты RTCCO
Нажмите на компонент — увидите описание и шаблоны
Заполните блоки — итоговый промпт появится ниже. Черновик сохраняется автоматически.
Заполните хотя бы один блок, чтобы увидеть итоговый промпт.
| Компонент | Описание | Назначение | Примеры для QA-задач |
|---|---|---|---|
| R (Role) — Роль | Кто отвечает | Профессия, уровень, специализация | «Ты — Senior QA Engineer с 10-летним опытом в финтехе» |
| T (Task) — Задача | Что делать | Конкретное действие, глагол в повелительном наклонении | «Сгенерируй 8-12 тест-кейсов для валидации полей формы регистрации» |
| C (Context) — Контекст | На основе чего | Требования, данные, предыстория | Требования в тегах <requirements>, код в блоках, логи с метками |
| C (Constraints) — Ограничения | Что запрещено/обязательно | Формат, объём, запреты | «Не генерируй тест-кейсы для функциональности, не описанной в требованиях» |
| O (Output) — Формат вывода | Как оформить результат | Структура, примеры, формат | Markdown-таблица с указанными столбцами, JSON с определённой схемой |
R (Role) — Роль
Компонент Role задаёт профессиональную рамку, в которой модель должна функционировать. Указание роли активирует соответствующий «сегмент» обучающих данных модели.Шаблоны Role:
Ты — Senior QA Engineer со специализацией в автоматизации на Python/Pytest
Ты — QA-аналитик в финтехе, эксперт по платёжным системам
Ты — специалист по исследовательскому тестированию с фокусом на usability
Ты — Staff QA Engineer с экспертизой в REST API тестированииT (Task) — Задача
Компонент Task содержит чёткую, конкретную, разбитую на пункты инструкцию. Шаблоны Task (глаголы для чёткости):- ❌ «Посмотри...» → ✅ «Проанализируй и выяви...»
- ❌ «Сделай тестирование...» → ✅ «Сгенерируй набор тест-кейсов, покрывающих...»
- ❌ «Напиши отчёт...» → ✅ «Сформируй баг-репорт, включающий...»
C (Context) — Контекст
Компонент Context предоставляет структурированные входные данные. Критически важно визуально отделять контекст от инструкций. Шаблоны Context (разделители):--- ТРЕБОВАНИЯ ---
[текст]
--- ИСТОРИЯ ИЗМЕНЕНИЙ ---
[текст]
--- ИЗВЕСТНЫЕ ОГРАНИЧЕНИЯ ---
[текст]Или с XML-тегами:
<requirements>
[текст требований]
</requirements>
<code>
[фрагмент кода]
</code>C (Constraints) — Ограничения
Компонент Constraints устанавливает границы допустимого поведения модели.Критические ограничения:
- НЕ выдумывай API-эндпоинты, которых нет в документации
- НЕ предполагай бизнес-логику, не описанную явно
- НЕ используй плейсхолдеры [ДАННЫЕ] — если данных нет, запроси
- Если информации недостаточно, укажи это явно
- Каждый кейс должен ссылаться на конкретное требованиеO (Output) — Формат вывода
Компонент Output специфицирует желаемую структуру, формат и характеристики генерируемого ответа.Шаблоны Output (форматы):
JSON с полями: id, title, preconditions, steps, expected_result, priority
CSV с заголовками: Test_ID, Description, Input_Data, Expected_Output
Markdown-таблица для Confluence/Notion
Gherkin-сценарии (Given/When/Then) для BDDПошаговое построение промпта "от нуля до результата"
Задача: тест-кейсы для «2FA через SMS» — нажмите шаг, чтобы развернуть промпт
Шаг 1 → Шаг 5 = на 80% конкретнее
Каждый добавленный компонент RTCCO делает ответ предсказуемее и ценнее
🧪 Пример для QA: Ниже — как из размытого запроса («напиши тест-кейсы для 2FA») шаг за шагом получается конкретный, воспроизводимый промпт.
Задача: Сгенерировать тест-кейсы для "двухфакторной аутентификации через SMS"
Шаг 1: Только роль (результат: слишком общий)
Ты — QA-инженер. Напиши тест-кейсы для 2FA.Результат: Общие кейсы, не учитывающие специфику SMS
Шаг 2: Роль + Task
Ты — QA-инженер с опытом в security-тестировании.
Задача: Сгенерируй тест-кейсы для 2FA через SMS, включая:
- Позитивные сценарии (успешная верификация)
- Негативные (неверный код, истёкший код)
- Граничные значения (длина кода, формат)
- Отказоустойчивость (недоступность SMS-шлюза)Результат: Лучше, но всё ещё без привязки к реализации
Шаг 3: + Context
[Предыдущий текст]
Контекст реализации:
- Код: 6 цифр, время жизни — 5 минут
- Максимум 3 попытки, затем блокировка на 30 минут
- SMS-шлюз: сторонний сервис, SLA 99.9%, таймаут 10 сек
- Регионы: РФ, Казахстан, Беларусь
- Резервный канал: голосовой звонок при недоставке за 60 секРезультат: Специфичные кейсы, но непредсказуемый формат
Шаг 4: + Constraints
[Предыдущий текст]
Ограничения:
- Не выдумывай функциональность вне контекста
- Если информации недостаточно, укажи это явно
- Каждый кейс должен ссылаться на конкретное требованиеРезультат: Почти готово
Шаг 5: + Output (финальный промпт)
[Все предыдущие блоки]
Формат: Markdown-таблица с колонками:
| ID | Название | Предусловия | Шаги | Ожидаемый результат | Приоритет | Ссылка на требование |Сравните: Шаг 1 → Шаг 5 = на 80% конкретнее!
- ❌ Плохо: «Напиши тесты»
- ✅ Хорошо: «Ты — QA. Задача: сгенерировать 5 тест-кейсов для поля «Email» формы регистрации. Контекст: поле обязательное, формат email. Ограничения: не придумывать другие поля. Формат: таблица с колонками ID, Шаги, Ожидаемый результат.»
Полный промпт по RTCCO
[R] Ты — Senior QA Engineer с опытом тестирования финансовых систем.
[T] Сгенерируй полный набор тест-кейсов для функции "Перевод средств
между счетами".
[C] Вот требования:
- Пользователь может переводить средства между своими счетами
- Минимальная сумма перевода: 100₽
- Максимальная сумма перевода: 500 000₽
- Комиссия: 0% для внутренних переводов, 1% для внешних
- Перевод подтверждается SMS-кодом
Технологии: Java Spring Boot, PostgreSQL, REST API
[C] Ограничения:
- Не выдумывай эндпоинты API, не указанные в требованиях
- Укажи [НЕДОСТАТОЧНО ДАННЫХ], если чего-то не хватает
- Каждый тест-кейс должен иметь уникальный ID (TF-001, TF-002...)
[O] Выведи результат в виде Markdown-таблицы:
| ID | Сценарий | Предусловия | Шаги | Ожидаемый результат | Приоритет |Библиотека RTCCO-шаблонов
Ты — QA-аналитик с опытом выявления неоднозначностей.
Проанализируй требования и найди проблемы тестируемости.
Требования: [вставить]
Не предлагай решения, только идентифицируй проблемы.
Таблица: Тип проблемы | Место | Описание | Вопрос к аналитику
Чек-лист качества промпта
Отметьте пункты по мере проверки (0/6).