Сообщение Codex «готово» полезно только вместе с доказательствами. Измененный файл, успешно выполненная сборка и работающий пользовательский сценарий означают разные уровни проверки. Чтобы не принимать код на доверии, заранее определите, какие действия обязательны до завершения задачи.
Никакой промпт не гарантирует отсутствие ошибок. Но можно сделать процесс прозрачным: агент показывает выполненные команды, их результаты и ограничения. Тогда видно, что действительно проверено, а что остается предположением.
Различайте уровни проверки
- Статический анализ: форматирование, линтер, типы. Помогает найти часть ошибок без запуска сценария.
- Unit-тесты: проверяют отдельное правило или функцию.
- Интеграционные тесты: проверяют взаимодействие модулей, базы и внешних границ.
- Проверка интерфейса: подтверждает, что действие доступно пользователю и дает ожидаемый результат.
Сборка не доказывает, что форма сохраняет данные. Скриншот не доказывает, что уведомление отправлено. Успешный запрос к тестовой заглушке не подтверждает работу реальной CRM. Подбирайте проверки под измененное поведение, а не по принципу «что проще запустить».
Сначала зафиксируйте исходное состояние
До правок нужно понять, какие проверки уже проходят. Если в проекте есть старые падения, сохраните их отдельно. Иначе после изменения трудно отличить новый дефект от существующего. Не просите агента исправить все найденные ошибки автоматически: это незаметно расширит задачу.
Для исправления бага особенно полезен воспроизводимый пример. Допустим, кнопка показывает «Сохранено», но после обновления страницы значение пропадает. Проверка должна включать повторное чтение данных, а не только появление уведомления. Именно наблюдаемый результат определяет, закрыт ли дефект.
Запрос с условиями готовности
Исправь сохранение настройки уведомлений.
Перед правками воспроизведи ошибку на тестовых данных.
Найди существующие команды проверок в проекте.
Добавь регрессионный тест на обнаруженную причину.
После исправления запусти релевантные тесты и сборку.
Проверь сохранение после перезагрузки страницы.
Не меняй соседние настройки и формат API.
В отчете укажи команды, результаты и непроверенные места.
Если проверка недоступна, не называй ее пройденной.Это рабочий шаблон, а не специальная команда Codex. Конкретные команды агент должен брать из проекта. В официальной документации также предлагается задавать шаги воспроизведения, ограничения и запрашивать результаты проверок. Объем тестирования при этом определяется риском изменения.
Каким должен быть итоговый отчет
Указывайте также окружение проверки: тестовая база, версия приложения и используемая ветка. Результат из другой рабочей копии не подтверждает корректность файлов, которые сейчас готовятся к выпуску.
Вместо длинного перечня измененных строк попросите четыре коротких пункта: причина проблемы, исправление, проверки, ограничения. Для команд нужны фактические результаты. Фраза «тесты должны пройти» означает, что проверки еще нет. «Запущено 12 тестов, 12 прошли» можно подтвердить журналом запуска.
Если процесс еще работает, задача не считается проверенной. Важно дождаться завершения, увидеть код выхода и убедиться, что команда не запустила режим наблюдения вместо однократного теста. Также проверьте, что тестовый набор действительно обнаружил тесты: успешное завершение с нулем тестов иногда создает ложное чувство надежности.
Когда окружение не дает выполнить проверку
Нет доступа к сети, не установлена база или отсутствуют тестовые ключи: это ограничения окружения, а не доказательство работоспособности. Агент должен назвать конкретную причину и отделить проверенное локально от непроверенного. Не стоит отключать защиту или передавать рабочие секреты только ради зеленого отчета.
Разумная замена зависит от ситуации. Можно проверить контракт на заглушке, но отдельно отметить, что реальный сервис не вызывался. Можно собрать приложение, но не утверждать, что мобильная верстка корректна без визуальной проверки. Когда критическая часть недоступна, результат следует оставить на приемке, а не публиковать автоматически.
Не позволяйте тесту скрывать проблему
Если после изменения тест упал, сначала выясняют причину. Удаление проверки, ослабление ожидаемого результата или добавление необоснованного пропуска не являются исправлением. Бывают случаи, когда требования действительно изменились, но тогда обновление теста должно сопровождаться объяснением нового поведения.
Полезно попросить показать, почему регрессионный тест обнаруживает старую ошибку. В отдельной тестовой копии можно проверить его на версии до исправления. Не нужно откатывать рабочие изменения в общем каталоге ради такого эксперимента. Изоляция особенно важна, если над репозиторием работают несколько человек.
Закрепите правила без бесконечного списка команд
В AGENTS.md достаточно описать базовые команды и принцип выбора проверок. Для изменения текста обычно не нужен полный нагрузочный прогон. Для авторизации, платежей и миграций недостаточно только линтера. Правила должны помогать оценивать риск, а не заставлять повторять весь набор при каждой запятой.
Самые важные проверки стоит включить в CI: это дает независимый барьер перед слиянием изменений. При этом зеленый CI не заменяет проверку требований, если тесты покрывают только часть сценария. Для интерфейса дополнительно проверяют доступность действий, состояния ошибок и небольшие экраны.
Продолжение: как поручать unit-тесты и как разбирать ошибки. Если приложение уже работает, но качество доработок сложно контролировать, начнем с разбора процесса проверки, не с полной переписки системы.
