Вы просите исправить кнопку, а в результате меняются стили, структура компонентов и половина зависимостей. Проблема не всегда в сложности задачи. Иногда в запросе просто не обозначено, какой результат нужен и что должно остаться прежним.

Ни один промт не гарантирует, что ИИ никогда не выйдет за рамки. Но понятные границы, небольшие задачи и проверка изменений делают работу управляемее. Разберём, как сформулировать задание Codex на примере формы заявки.

Почему просьба «сделай нормально» приводит к лишним изменениям

Слова «улучши», «оптимизируй» и «приведи в порядок» допускают разные трактовки. Для владельца сайта это может означать исправление отступа. Для исполнителя — переработку компонента, замену библиотеки или изменение поведения формы.

В официальном руководстве OpenAI по постановке задач рекомендуется обозначать цель, полезный контекст, ожидаемый результат и существенные ограничения. Необязательно заполнять огромный шаблон для каждой мелочи. Достаточно информации, которая действительно влияет на решение.

Начинайте с наблюдаемого результата

Сравните две формулировки.

Неопределённо: «Переделай форму, чтобы всё работало хорошо».

Проверяемо: «После успешной отправки формы покажи сообщение “Заявка отправлена”. Повторное нажатие во время отправки не должно создавать вторую заявку. Остальной сценарий сохрани».

Во втором случае понятно, какие состояния проверить: до отправки, ожидание ответа, успех и ошибка. При этом не нужно заранее диктовать каждую строку кода.

Укажите границы задачи

Полезно назвать область, в которой ожидаются изменения, и соседние части, которые нельзя затрагивать без согласования. Если точный файл неизвестен, опишите пользовательский сценарий и попросите найти соответствующий модуль.

Задача: исправить повторную отправку формы заявки.
Проблема: двойной клик создаёт две записи.
Результат: пока запрос выполняется, повторная отправка недоступна.
При ошибке пользователь может повторить попытку.

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

Проверь успех, ошибку и быстрый двойной клик.
В отчёте перечисли изменённые файлы и результаты проверок.

При этом блокировка кнопки не гарантирует отсутствие дублей на сервере. Если операция критична, например создаёт заказ, может понадобиться защита на стороне обработки запроса. Хорошая постановка задачи не запрещает сообщить о такой проблеме, а определяет, когда расширение работ надо согласовать.

Не требуйте фиксированное число файлов любой ценой

Ограничение «измени ровно один файл» кажется безопасным, но иногда заставляет помещать логику не туда, где она должна находиться. Лучше ограничить поведение и область ответственности: «меняй только форму заявки и связанные с ней проверки».

Количество строк также не равно риску. Однострочное изменение общей функции может затронуть весь сайт, а новый тестовый файл — не менять поведение вообще. Просите объяснять влияние правки, а не только её размер.

Разделяйте исправление и рефакторинг

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

Сначала исправь указанную ошибку минимально достаточным способом.
Не совмещай это с общим рефакторингом.
Смежные проблемы перечисли отдельно с объяснением риска.
Не изменяй уже существующие несвязанные правки в проекте.

Исключение — случай, когда локальная правка действительно невозможна без изменения общей логики. Тогда нужен короткий разбор вариантов, а не молчаливое расширение задачи.

Задайте критерии готовности заранее

«Код написан» и «задача проверена» — разные состояния. Для интерфейса важна работа на нужных экранах, для обработки данных — корректность расчётов, для интеграции — поведение при недоступности внешней системы.

  • Опишите основной сценарий, который должен проходить.
  • Добавьте один-два существенных пограничных случая.
  • Укажите, какое прежнее поведение нужно сохранить.
  • Попросите назвать реально выполненные проверки.
  • Если проверка невозможна, потребуйте явно указать причину.

Не просите сообщать об успешных тестах, которых в проекте нет. Сначала выясните, какие проверки предусмотрены. Если автоматических тестов пока нет, отдельно согласуйте их добавление или зафиксируйте ручной сценарий приёмки.

Проверяйте разницу до публикации

Перед переносом в рабочую среду посмотрите список изменённых файлов и сравнение версий. Особенно внимательно проверяйте конфигурацию, зависимости, схему базы данных и общие стили.

Если изменения оказались шире запроса, не начинайте с безусловного отката всего проекта. В рабочей папке могут находиться ваши собственные правки. Сначала отделите изменения текущей задачи от остальных и только затем выберите, что сохранить или отменить.

Что перенести в постоянные правила

Повторяющиеся требования не стоит вставлять в каждое сообщение. Например, запрет менять платёжный модуль без согласования или команды проверки проекта удобно хранить в AGENTS.md. Но конкретная ошибка, экран и критерии готовности должны оставаться в текущей задаче.

Для нового проекта начните с пошаговой инструкции по разработке приложения с Codex. Для существующего используйте короткую формулу: результат, границы, проверки. Она полезнее длинного набора запретов, в котором теряется смысл работы.

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