Промпт как проверяемая постановка задачи
Соберите запрос, в котором понятны данные, ограничения и критерий полезного ответа.
- Разделить задачу, контекст, входные данные, ограничения и формат.
- Задать прослеживаемость ожиданий к требованиям.
- Проверить структуру результата без угадывания намерений модели.
Пять частей закрывают разные неопределённости
Промпт удобно читать как короткую постановку задачи. Задача описывает преобразование: например, предложить проверки ограничений полей. Контекст указывает стадию работы и аудиторию: это черновик для обсуждения, а не отчёт о выполненном регрессе. Входные данные содержат правила с идентификаторами и допустимые примеры. Ограничения фиксируют, что нельзя додумывать или делать. Формат задаёт артефакт, который другой человек сможет проверить. Эти части нужны для ясности; наличие пяти заголовков само по себе не гарантирует правильность.
«Ты лучший QA, протестируй форму» звучит определённо, но не содержит источника ожиданий. Неясно, какую форму исследуют, кто имеет доступ, что считается результатом и был ли вообще предоставлен стенд. Улучшение начинается с этих пробелов, а не с усиления роли словами «эксперт мирового уровня». Просьба объяснить основания и перечислить допущения полезнее требования раскрыть скрытые внутренние рассуждения.
Разобранный пример: длина title
В OrbitDesk F1 задаёт диапазон 1–80 включительно. Для этой части упражнения ограничим значения ASCII-буквами: на них легко вручную проверить размер по указанным кодовым точкам. Unicode-контракт уже задан, но отдельные составные примеры потребуют самостоятельного подсчёта. Просим таблицу с исходным значением, длиной, ожиданием и F1. Получаем строки 0 — отклонить, 1 — принять по длине, 80 — принять по длине, 81 — отклонить. Слова «по длине» важны: валидный размер не доказывает наличие права создания или успешное сохранение на сервере.
Если модель добавила «все остальные проверки пройдены», это выход за рамки задачи. Если она вместо конкретных значений написала только «проверить границы», формат недостаточен для повторения. Если выдала вопрос о нормализации Unicode, он полезен, но должен находиться в разделе вопросов. Такая дисциплина превращает абстрактную просьбу в небольшой контракт результата: можно указать, что именно принято и почему работа ещё не готова.
Критерии приёмки ответа
| Критерий | Как проверить |
|---|---|
| Каждое ожидание имеет основание | В строке есть F1 или F2 и оно действительно применимо |
| Недостающее явно отделено | Нет выдуманной нормализации, отсутствующих прав публикации и кодов API |
| Данные повторяемы | Длина и способ построения строки указаны явно |
| Статус честный | Сценарии названы предложенными, а не выполненными |
Формат помогает найти ошибки, но не исправляет их автоматически
Таблица и JSON делают результат удобнее для просмотра или обработки. Они не доказывают смысловую корректность. JSON может быть синтаксически верным и содержать вымышленное правило; строка таблицы может ссылаться на F2, хотя проверяет права пользователя. Проверяйте отдельно форму, связь с источником и ожидаемый результат. Не просите модель заполнить каждую колонку любым текстом: для неизвестного поля допустим явный вопрос.
Перед использованием промпта сделайте короткую ручную проверку на одном входе. Сможете ли вы по нему отличить хороший ответ от плохого, не спрашивая ту же модель? Если нет, уточните критерии. После ответа исправляйте постановку по конкретному обнаруженному дефекту. Сохраняйте версию запроса вместе с входом, иначе при сравнении результатов окажется невозможно понять, изменилась модель, требования или сама задача.
ЗАДАЧА Предложи минимальный набор проверок длины title и description. КОНТЕКСТ Это проектирование тестов для OrbitDesk, выполнение не проводилось. В этом запросе используй только ASCII-букву A для непустых значений. ВХОДНЫЕ ДАННЫЕ Синтетический учебный продукт OrbitDesk. Реальных клиентов и рабочих данных нет. Это сокращённый фрагмент полного учебного контракта: работайте только с переданными правилами. Публикацию уточним в итоговом задании. F1. Заголовок задачи — строка от 1 до 80 кодовых точек Unicode включительно. Сохранение не удаляет пробелы по краям автоматически. F2. Описание — строка от 0 до 2000 кодовых точек Unicode включительно. F3. Состояния: draft и published. Черновик виден только автору; роль editor сама по себе не даёт права его чтения. F4. Заголовок опубликованной задачи виден участникам её команды. Существуют роли user и editor. Права публикации не включены в этот фрагмент. Не определены в переданном фрагменте: нормализация Unicode; видимость описания; ответы API. Недостающие правила нельзя восстанавливать догадкой. ОГРАНИЧЕНИЯ Сохрани заданные кодовые точки и отсутствие автоматического trim. Не придумывай отсутствующие права публикации, коды API или фактические результаты. Ожидание сформулируй только по длине. Неопределённые вопросы вынеси отдельно. Для повторов используй обозначение A×N. ОЖИДАЕМЫЙ ФОРМАТ Таблица: ID | поле | значение | длина | ожидание по длине | основание. Затем открытые вопросы. Устрани дубли, но не объединяй разные поля.
Используйте разрешённый ИИ-сервис. Не отправляйте рабочие секреты и персональные данные.
Источники и проверка фактов
NIST AI 600-1: Generative AI ProfileПервичный источник: риск убедительных ошибочных ответов, оценка результатов и ограничения применения ИИ. Учебные проверки OrbitDesk разработаны редакцией.Microsoft HAX: Guidelines for Human-AI InteractionПервичный источник: понятные ограничения ИИ, возможность исправить результат и контроль пользователя. Применение к QA — редакционная адаптация.Авторский учебный материал · Редакция QA Orbit · версия 2026-10-28.1