К оглавлению10 мин
Часть 2. Промпт-инжиниринг · Глава 5
Правила хорошего промпта
Цели раздела
3 пунктаК концу раздела вы сможете:
- Освоить конкретные тактики для повышения качества вывода LLM.
- Научиться делать результат проверяемым и трассируемым.
- Избежать распространённых анти-паттернов.
Тактики для качественного вывода
Поскольку LLM может "выдумывать" факты, каждый вывод должен быть привязан к исходным данным.Привязка вывода к исходным данным
❌ Неэффективный запрос
Найди потенциальные риски в этом функционале
✅ Эффективный запрос
Проанализируй требования ниже и для каждого найденного риска укажи, на какой именно пункт (или абзац) в требованиях он опирается. Формат вывода: 'Риск', 'Пункт в тексте', 'Обоснование'
Уровни проверяемости
Базовый
Требование ссылаться на источник
В промпте
«Для каждого риска укажи пункт требований»
Продвинутый
Требование цитировать фрагмент
В промпте
«Приведи дословную цитату из требований»
Экспертный
Многоуровневая трассировка
В промпте
«Укажи: требование → бизнес-правило → поле/экран»
Явно запрещать догадки
LLM по своей природе любит "дополнять" недостающую информацию.Запрет на догадки при нехватке данных
Если в предоставленных логах нет информации о времени ответа сервера, напиши: 'Для анализа не хватает данных. Требуется получить логи с метками времени ответов от внешнего сервиса X'
Запрограммировать формат
Структурированный вывод (таблица, JSON, CSV) гораздо удобнее для дальнейшей работы.Явный формат вывода (CSV)
Сгенерируй набор тестовых данных для поля 'пароль'. Выведи результат в формате CSV с колонками: 'Тип_теста', 'Значение', 'Ожидаемый_результат'
Просить модель выявлять неопределенности и противоречия
LLM обладает уникальной способностью к "редактуре".Выявление неопределённостей и противоречий
Ты — опытный технический писатель. Проверь следующий текст требований на наличие грамматических ошибок, стилистических несоответствий и внутренних противоречий между разными разделами. Выведи список всех найденных проблем со ссылками на соответствующие места в тексте.
Разделять "генерацию" и "оценку"
Сложные задачи лучше всего решать в два этапа.- Этап 1: Просите модель сгенерировать максимальное количество вариантов.
- Этап 2: Берёте черновик и даёте модели другой промпт для критической оценки.
Генерация и оценка — два запроса
- 1
Этап 1
Генерация — максимум вариантов без фильтрации
промптТы — QA-инженер. На основе приложенных требований сгенерируй максимально полный черновик тест-кейсов: позитивные, негативные, граничные. Не отфильтровывай варианты — цель этапа объём для последующей оценки.
- 2
Этап 2
Оценка черновика по чек-листу
промптТы — опытный QA-lead. Вот набор тест-кейсов, сгенерированных ранее. Проверь их по следующему чек-листу: 1. Полное покрытие всех пунктов требований 2. Наличие как минимум трех негативных сценариев для каждой функции 3. Отсутствие дублирующихся тестов Для каждого тест-кейса, не прошедшего проверку, предложи исправление.
Практикум: рефакторинг плохого промпта
❌Исходный промпт (анти-паттерн)
Протестируй форму регистрации. Нужны качественные тест-кейсы, подробно, со всеми проверками. Выведи в удобном формате.
⚠️Что не так
- Нет роли → непонятен уровень экспертизы
- «Протестируй» — не конкретная задача, нет глагола действия
- Нет контекста — какие поля в форме?
- «Качественные», «подробно» — неизмеримые критерии
- «Удобный формат» — не определён
✅Рефакторинг по RTCCO
[R] Ты — QA-инженер с опытом в веб-тестировании. [T] Сгенерируй тест-кейсы для формы регистрации: 1. Проверь валидацию каждого поля (email, пароль, подтверждение) 2. Проверь кросс-полевую валидацию (совпадение паролей) 3. Проверь UX-сценарии (подсказки, сообщения об ошибках) [C] Контекст: — Email: обязательное, валидация формата — Пароль: обязательное, минимум 8 символов, 1 цифра + 1 заглавная — Подтверждение: обязательное, совпадение с паролем [C] Ограничения: — Не выдумывай дополнительные поля — Если данных не хватает: «Требуется уточнение: [что]» — ID формата: TC-REG-[XXX] [O] Формат: Markdown-таблица | ID | Название | Предусловия | Шаги | Ожидаемый результат | Приоритет |
Чек-лист качества промпта
Типичные ошибки новичков
- Слишком общая роль («помощник») → Указывайте специализацию (QA, Security, Automation).
- Нет формата вывода → Всегда задавайте таблицу, JSON или нумерованный список.
- Один гигантский запрос → Дробите задачу на шаги (анализ → генерация → ревью).
Анти-паттерны (чего следует избегать)
| Анти-паттерн | Проблема | Решение |
|---|---|---|
| Смешивание разных задач | Генерация тестов + автотесты + анализ логов в одном запросе | Разделите эти задачи на отдельные промпты |
| Использование нечётких слов | "подробно", "качественно", "хорошо" без метрик | Используйте конкретные критерии: "не менее 10 негативных тест-кейсов" |
| Переизбыток контекста без структуры | Вставка всего текста документа | Предоставьте оглавление и ключевые выдержки |
| Отсутствие ограничений | Модель выдумывает информацию | Явно запретите выдумывать, требуйте указания на недостаток данных |