Отчёт Codex: как принимать работу по фактам, а не по словам

Андрей Отинов -

Самая опасная фраза в работе с Codex - не ошибка и не предупреждение. Самая опасная фраза: "готово".

Она звучит удобно. Агент что-то сделал, написал короткий отчёт, возможно даже сообщил, что проверки прошли. Но для владельца проекта этого недостаточно. "Готово" не показывает, что именно изменилось, что было проверено, какие риски остались и какое решение теперь должен принять человек.

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

Почему «готово» ничего не доказывает

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

Это слабая точка. Если принять работу только по формулировке "готово", вы не знаете:

  • какие файлы или части системы изменились;
  • совпадает ли результат с исходной целью;
  • какие проверки действительно запускались;
  • были ли предупреждения;
  • что Codex не проверял;
  • не появились ли лишние изменения рядом с задачей.

В рабочем процессе важно разделять выполнение и приёмку. Codex может выполнить задачу, но решение "принимаем" остаётся человеческим.

Что документация Codex говорит о проверке и review

В документации OpenAI по Codex есть прямая логика: не стоит останавливаться на просьбе "сделай изменение". Нужно просить Codex создавать тесты, запускать релевантные проверки, подтверждать результат и review-ить работу до принятия.

Там же описан review pane в приложении Codex. Он показывает состояние Git-репозитория: изменения Codex, изменения пользователя и другие незакоммиченные изменения. Можно смотреть разные области diff: последние изменения, все изменения ветки или незакоммиченные изменения. Можно оставлять inline-комментарии по конкретным строкам, stage-ить нужное и откатывать ненужное.

Для программиста это звучит как review diff. Для владельца проекта это можно перевести проще: Codex должен показать не только результат, но и доказательства результата.

Что попросить у Codex после выполнения

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

Минимальный запрос:

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

Такой запрос полезен даже без программирования. Он заставляет Codex перейти из режима "я сделал" в режим "вот доказательства".

Как должен выглядеть отчёт приёмки

Хороший отчёт приёмки короткий и проверяемый.

Блок отчёта Что в нём должно быть
Изменено Конкретные файлы, страницы, тексты, настройки или публикации
Проверено Команды, live-аудит, визуальный осмотр, тест, ссылка, скриншот
Совпадение с целью Почему результат решает исходную задачу
Риски Что не проверено, где возможен побочный эффект
Решение человека Что принять, что вернуть, что отложить

Плохой отчёт выглядит так: "Всё сделано, проверил, проблем нет".

Хороший отчёт выглядит так: "Изменён черновик статьи, создан V4-визуал, Silver passed, Ghost published, live audit passed, Telegram/VK поставлены в ArticleFactory. Риск: Gold-проверка ещё не выполнена, но она постпубликационная и не блокирует выход".

Второй вариант можно проверить. Первый вариант можно только принять на веру.

Как проверить результат без программирования

Непрограммисту не нужно читать весь diff как инженер. Но ему нужно проверить три слоя.

Первый слой - видимый результат. Откройте страницу, документ, публикацию, интерфейс или отчёт. Сравните с исходной целью. Если просили "сделать практическую статью", она должна учить действию, а не пересказывать документацию.

Второй слой - доказательства. Если Codex пишет "проверил", должно быть понятно чем: команда, URL, статус passed, список файлов, live-аудит, скриншот, diff, staged/unstaged view. Слово "проверил" без объекта проверки ничего не стоит.

Третий слой - границы. Хороший Codex должен назвать, что он не проверял. Например: "не проверял мобильную версию", "не запускал полный e2e", "VK sync временно не ответил", "Gold-проверка ещё не проведена".

Это не слабость отчёта. Это его ценность. Видимый риск лучше скрытого риска.

Какие решения остаются за человеком

Codex может предложить рекомендацию, но не должен сам закрывать все решения.

После отчёта у человека есть четыре нормальных варианта:

  1. Принять работу полностью.
  2. Вернуть на точечную доработку.
  3. Принять часть и отложить спорное.
  4. Откатить изменение, если оно вышло за границы задачи.

В review pane это может быть stage, unstage или revert. В статье это может быть "публикуем", "оставляем в черновике" или "переписываем заголовок". В бизнес-процессе это может быть "внедряем", "тестируем на одном клиенте" или "останавливаем".

Главное: решение не должно растворяться внутри ответа Codex. Агент помогает увидеть факты. Человек принимает ответственность.

Шаблон запроса на отчёт

Используйте такой шаблон после выполнения задачи:

Сформируй отчёт приёмки по завершённой задаче.

Не пиши просто "готово".

Дай:
1. цель задачи в одном предложении;
2. что изменено;
3. какие артефакты получились;
4. какие проверки выполнены и какой результат;
5. что не проверено;
6. какие риски остались;
7. что ты рекомендуешь мне сделать: принять, вернуть на доработку, принять частично или откатить.

Если есть diff, live URL, тесты, audit-файлы или queue/job статусы, перечисли их конкретно.

Такой отчёт не делает работу медленнее. Он убирает слепую приёмку. Codex остаётся исполнителем, но человек видит основания для решения.

Это и есть нормальная рабочая модель: задача, выполнение, доказательства, человеческое решение.