Как написать хороший промпт для Codex, чтобы он менял код правильно

Короткий ответ: хороший промпт для Codex похож на хорошую задачу разработчику

В промпте для Codex важны не красивые формулировки, а инженерная конкретика: цель, контекст, ограничения, ожидаемое поведение, команды проверки и формат результата.

Плохой промпт звучит как “почини форму”. Хороший: “в форме регистрации email должен валидироваться до отправки, ошибки показывать под полем, API не менять, проверить npm run build”.

Структура промпта для Codex

1. Цель: какое поведение должно измениться.
2. Контекст: ссылки на задачу, файлы, ошибку, документы.
3. Границы: что можно менять, а что нельзя.
4. Критерии готовности: как понять, что задача выполнена.
5. Проверка: какие команды запустить.
6. Отчет: что перечислить в финальном ответе.

Примеры плохого и хорошего промпта

Слабый промпт

Сделай регистрацию нормальной.

Сильный промпт

Исправь регистрацию:
- email должен валидироваться на клиенте до POST /api/v1/auth/register/code;
- текст ошибки показывать под полем email;
- backend API и тексты писем не менять;
- сохранить текущий визуальный стиль;
- проверить npm run build;
- в финале перечислить измененные файлы и результат проверки.

Второй вариант дает агенту контекст и рамки. Он не вынужден угадывать, что значит “нормально”.

Как просить Codex проверять результат

Всегда добавляйте проверку под тип задачи: unit-тесты для логики, браузерный просмотр для UI, сборку для фронтенда, миграции и feature-тесты для backend-изменений.

Проверь:
- npm run build
- php artisan test --filter=Registration
- вручную открой /register и проверь ошибку email

FAQ