Как дать Codex проверять свою работу до публикации

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

Плохой вариант звучит так: «Сделай статью, проверь ее и опубликуй». В такой формулировке Codex оказывается одновременно автором, редактором, проверяющим и человеком, который принимает риск. Для бизнеса это слабая схема. Агент может быть полезным проверяющим, но проверка должна быть отдельным этапом, с понятными правилами, примерами и стоп-точками.

В официальной документации Codex есть отдельный блок про agent approvals and security. Для нетехнического владельца смысл простой: не все действия одинаковы. Одно дело попросить агента составить план или найти слабые места. Другое - дать ему менять файлы, отправлять сообщения, публиковать или запускать команды. Чем ближе действие к внешнему миру, тем жестче должна быть проверка.

Самопроверка не равна самодоверию

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

Для владельца проекта это особенно важно. Он может не понимать код, но он может проверить смысл, адресата, риск, публичность, тон, деньги, обязательства и соответствие задаче. Значит, самопроверка должна быть написана так, чтобы человек мог ее прочитать и принять решение.

Главное:

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

Рабочий запрос

Работай в три этапа.

Этап 1. План.
Сначала покажи, как ты понял задачу, какие источники используешь,
какие ограничения видишь и какой результат считаешь готовым.
Не выполняй работу, пока я не подтвержу план.

Этап 2. Результат.
После подтверждения сделай черновик результата.
Не публикуй, не отправляй и не меняй внешние системы.

Этап 3. Самопроверка.
Проверь результат по чеклисту:
- соответствует ли исходной задаче;
- не добавлены ли неподтвержденные факты;
- не нарушены ли ограничения;
- понятен ли результат человеку без технической экспертизы;
- какие 3 риска остаются;
- какие действия требуют моего явного решения.

В конце дай статус: можно использовать / нужна правка / нельзя выпускать.

Этот запрос выглядит длиннее обычного, зато он меняет роль Codex. Агент перестает быть быстрым исполнителем, который стремится закончить. Он становится участником процесса: сначала показывает понимание, потом делает, потом проверяет.

Какие стоп-точки нужны владельцу проекта

Стоп-точки зависят от проекта, но базовый набор почти всегда одинаковый.

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

Вторая стоп-точка - деньги и обязательства. Агент не должен сам обещать сроки, скидки, юридические условия, оплату, гарантию или результат. Он может предложить формулировку, но человек должен подтвердить.

Третья стоп-точка - источники. Если Codex пишет на основе материалов, он должен показать, какие источники использовал. Если источника нет, лучше честно написать «нужно проверить», чем выпускать гладкую фразу без основания.

Четвертая стоп-точка - доступы и команды. Если Codex работает в среде, где он может что-то менять, удалять, отправлять или запускать, человеку нужен понятный режим разрешений. В документации Codex app про computer use этот слой важен именно потому, что агент может взаимодействовать с интерфейсом, а значит границы должны быть явными.

Как понять, что проверка полезная

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

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

Codex становится must have не потому, что делает все за человека. Он становится must have тогда, когда помогает человеку держать процесс: видеть вход, видеть результат, видеть риск и вовремя нажимать стоп.

Простая форма журнала проверки

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

Для владельца проекта это особенно ценно в повторяемых задачах. Если Codex каждый раз ошибается в одном и том же месте, это не повод злиться на агента. Это повод превратить ошибку в правило проекта: «не использовать неподтвержденные цифры», «не менять тон письма без причины», «перед публикацией показать список источников». Так самопроверка постепенно становится памятью работы.