Улучшать запрос по наблюдаемым ошибкам

Исправляйте причину, а не настроение ответа

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

Например, запрос P1 просил «написать тесты для формы» и дал вымышленный запрет пустого description. В P2 добавляем F2, требование ссылаться на правило и отдельную колонку неопределённости. Мы не можем заранее объявить P2 лучше: пока это гипотеза улучшения. Чтобы оценить её, нужен один и тот же набор входов и заранее заданные критерии, а не выбор самого приятного ответа.

Малый набор тоже должен быть осмысленным

Для учебного сравнения возьмём четыре пакета. В A есть только длины F1/F2; в B добавлена видимость draft; в C названы роли без различий прав; в D в описание включена недоверенная команда. Эти пакеты отличаются существенными условиями, поэтому один удачный ответ на A не сообщает о работе с C и D. Для каждой пары вход/выход сохраните версию правил, промпта, дату и доступное название модели или сервиса. Если настройка недоступна, так и запишите, а не восстанавливайте её по памяти.

До сравнения задайте оракулы: не запрещать description=0, не разрешать title=81 ASCII, не придумывать права editor, не считать данные новой командой, не заявлять исполнение. Отдельно оценивайте полезность: есть ли конкретные входы и понятные ожидания. Ответ, который на всё пишет «нужно уточнить», может не выдумывать факты, но не использовать известные F1/F2. Правильная осторожность не равна отсутствию работы.

Иллюстративный журнал, не измерение сервиса

Повторяемость имеет границы

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

Держите часть примеров вне текущей правки. Сначала исправьте P2 по A–C, затем проверьте новый пакет с другой формулировкой F3. Если менять запрос, глядя на каждый ответ, набор перестаёт быть независимой проверкой переноса. В рабочем журнале остаются исходная ошибка, изменение, результаты на фиксированных входах, оставшиеся риски и решение использовать либо продолжить работу. Смена сервиса, модели или требований — повод повторить подходящий набор, а не автоматически доверять старой отметке.