1. Дайте минимальное воспроизведение
Перечислите начальное состояние, точные действия, ввод и момент ошибки. Если проблема плавающая, укажите частоту и условия, при которых она уже наблюдалась.
Не вставляйте только скриншот результата. Лог, URL, test case или запрос к API помогают повторить путь.
2. Разделите фактическое и ожидаемое поведение
Фактическое: PENDING заказ показывает кнопку выдачи. Ожидаемое: выдача доступна только после подтверждённого статуса оплаты.
Так агент видит нарушенный контракт и не исправляет проблему скрытием кнопки без защиты API.
3. Приложите доказательства без секретов
Дайте stack trace, сокращённый лог, failing test, схему данных или screenshot. Удалите токены, персональные данные и лишние большие бинарные файлы.
Если ошибка появилась после изменения, укажите commit или diff, но не утверждайте причину без проверки.
4. Попросите найти корневую причину
Задайте read-only диагностику до правки: проследить путь данных, найти первое неверное состояние и объяснить, почему текущий тест не ловит его.
При нескольких гипотезах агент должен проверить их наблюдением, а не выбрать самую удобную.
5. Ограничьте исправление
Перечислите соседние системы, которые нельзя менять, и запретите отключать проверку ради зелёного CI. Попросите сохранить обратную совместимость, если она является требованием.
Минимальная правка означает минимальный риск, а не минимальное число строк любой ценой.
6. Потребуйте регрессионный тест
Тест сначала воспроизводит дефект на старой логике, затем проходит после исправления. Добавьте отрицательный сценарий для соседней границы.
Для визуального бага нужен browser smoke на точном viewport; для состояния базы - integration и restart.
Готовый каркас запроса
«В [среде] при [действиях] получаю [факт], ожидаю [результат]. Доказательства: [лог/test/URL]. Сначала воспроизведи и найди первое неверное состояние. Исправь только [scope], не меняй [границы]. Добавь регрессионный тест [сценарии] и покажи команды проверки. При отсутствии воспроизведения остановись с точным blocker».
Effort помогает заполнить этот каркас, но не воспроизводит ошибку и не подтверждает исправление.
Источники
У каждой опоры есть дата проверки. Если источник изменится, материал нужно пересмотреть.
-
01
Codex documentation OpenAI Developers · проверено 6 сентября 2026 г.
Сверены рабочий цикл Codex, роль инструкций проекта, локальных проверок и ограниченной области изменений.
-
02
Claude Code best practices Anthropic · проверено 6 сентября 2026 г.
Сверены рекомендации исследовать контекст, планировать сложную работу, давать модели способы проверки и вести постоянные инструкции проекта.
-
03
Prompt engineering OpenAI Developers · проверено 6 сентября 2026 г.
Сверены рекомендации о ясных инструкциях, релевантном контексте, примерах и проверяемом формате результата.
-
04
Effort Translator: рабочий интерфейс Нейроквалификатор · проверено 6 сентября 2026 г.
Сверена граница продукта: перевод исходной мысли в структурированную постановку без подмены цели и без гарантии результата.