Как заставить Codex работать правильно. Постановка задач, контроль и проверка результата

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

Вход в админ-панель означает, что можно приступать к работе?

В одном из реальных примеров управления интернет-магазином Codex должен был помогать в проведении исследований, выборе товаров, ценообразовании и подготовке черновых версий товаров. В браузере уже был выполнен вход в админ-панель Jingmai, и все кнопки на странице были активны.

С точки зрения функциональных возможностей, он «может выполнять операции».

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

В других случаях на странице появляется всплывающее окно «Товар успешно добавлен», но состояние в последующем списке и в деталях не совпадает. Уведомление об успешном добавлении подтверждает, что браузер получил обратную связь, но не подтверждает, что нужный товар с правильными полями перешел в правильное бизнес-состояние.

Эти две проблемы указывают на одну и ту же границу:

доступ не означает наличие полномочий; возможность нажать не означает, что нужно нажимать; успешное нажатие не означает завершение бизнес-операции.

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

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

Управляющий — не самый занятой человек

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

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

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

Определение результата: зачем это делается, для кого предназначено, при каких условиях результат будет иметь ценность;

Установка границ: какие принципы, бюджет, полномочия и риски нельзя превышать;

Выбор доказательств: что может подтвердить завершение, а что — лишь частичный успех;

Установка контрольных точек: какие компромиссы должны быть подтверждены человеком, прежде чем можно будет продолжить;

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

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

Разделение полномочий на три категории

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

Право на внесение предложений

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

Например, он может предложить три модели ценообразования, указав валовую прибыль, риск возврата товаров и пробелы в доказательствах для каждой из них.

Право на исполнение

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

Например, он может создавать до N черновиков товаров, не выставленных на продажу, но при этом должен привязываться к точным SKU и после завершения каждого черновика возвращаться к списку и деталям.

Право принятия решений

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

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

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

Карта полномочий, более полезная, чем «полная автоматизация»

Перед началом проекта разделите действия на три зоны:

Зона

Поведение по умолчанию

Типичные действия

Зона самостоятельности

Codex — можно выполнять напрямую и сохранять доказательства

Чтение файлов, анализ данных, изменение исходного кода, выполнение тестов, подготовка черновиков

Зона подтверждения

Предложение решения или карточки утверждения, ожидание подтверждения

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

Запрещённая зона

Данное задание не подлежит выполнению

Официальный релиз, оплата, возврат средств, размещение рекламы, отправка сообщений клиентам, удаление производственных данных

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

Разрешение должно быть привязано к четырём элементам:

Действие + Объект + Область применения + Срок действия.

Формулировка «можно изменять цену» недостаточно чётка; «в рамках данного задания можно рассчитать рекомендуемую цену для 5 черновиков из списка, которые ещё не выставлены на продажу, но нельзя подавать официальную цену» — вот и есть допустимые границы.

Не следует дистанционно контролировать шаги, а нужно управлять соглашением

Не нужно указывать Codex, как действовать на каждом этапе, но следует требовать, чтобы он предоставлял однозначные результаты на ключевых этапах.

Возьмём в качестве примера подготовку черновика интернет-магазина. Неэффективный способ:

открыть админ-панель, щелкнуть второе меню слева, найти третью вкладку, затем нажать кнопку в правом нижнем углу…

Как только страница меняется, эта система координатных инструкций теряет силу, и человек берет на себя всю ответственность за планирование действий.

Лучшее задание:

подготовить не более 5 черновиков товаров из подтвержденного списка, которые еще не выставлены на продажу. Перед каждой операцией проверять SKU, название и источник поставки; запрещается публиковать, изменять рекламу или связываться с клиентами. По завершении одновременно перепроверять количество черновиков, элементы списка и поля с подробностями; при несоответствии этих трех показателей пометить задачу как «UNKNOWN» и остановить процесс. В конце сформировать пакет документов для утверждения владельцем магазина.

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

Четыре категории решений, которые нельзя передать на аутсорсинг

Оценка ценности

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

Принятие рисков

Разрешать ли использование реальных учетных записей, можно ли изменять производственные данные, следует ли принимать тот или иной правовой или bezpečnostный риск — все это должны решать лица, уполномоченные нести ответственность за последствия.

Достаточность доказательств

Являются ли «зеленые» результаты тестирования, нормальные скриншоты и появление всплывающего окна об успешном завершении достаточными доказательствами для признания задачи «выполненной» — это зависит от уровня реальной реализации задачи. Необходимо отклонять заявления о завершении, если уровень доказательств не соответствует уровню реализации.

Компромиссы

Скорость, стоимость, качество, совместимость и удобство обслуживания часто вступают в противоречие. Codex может перечислить возможные издержки, но без соответствующих полномочий не должен выбирать от имени проекта, чем пожертвовать.

Какие обязанности Codex должен брать на себя по собственной инициативе

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

•

перед выполнением повторять цели и полномочия;

•

изучать авторитетные источники и указывать на противоречия;

•

разделять факты, предположения и неизвестные моменты;

•

предлагать минимальные вертикальные изменения;

•

самостоятельно вносить изменения и проводить проверку в рамках установленных границ;

•

останавливаться при обнаружении действий с высоким риском или необратимых действий;

•

сообщать о фактических доказательствах, а не только о выполненных шагах;

•

проводить анализ повторяющихся ошибок и предлагать закрепление долгосрочных правил.

Люди управляют направлением и ответственностью, а Codex — сложностью выполнения. Ни те, ни другие не должны сводиться к построчному дистанционному управлению.

Можно использовать напрямую: карта полномочий ответственного лица

Цель задачи: [Кто, в каких условиях и какой результат должен быть достигнут]

Codex может самостоятельно: - [Просмотр в режиме «только для чтения»] - [Локальные, восстанавливаемые изменения] - [Проверка разрешений на выполнение]

Сначала необходимо убедиться: - [Решения, которые изменят направление развития продукта] - [широкомасштабные или трудновосстановимые изменения] - [Действия, которые повлияют на работу реальных пользователей или внешних систем]

В данном случае запрещено: - [релизы, платежи, удаления, отправки, производственные операции и т. д.]

Объекты: [конкретные хранилища, файлы, SKU, среды, учетные записи или версии]

Точки ручной проверки: [по каким доказательствам и кто принимает решение о продолжении]

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

Самопроверка ответственного лица

•

[ ] Определил ли я результат, а не просто распределил задачи;

•

[ ] Разграничил ли я права на внесение предложений, исполнение и принятие решений;

•

[ ] Связаны ли полномочия с четко определенными действиями, объектами, сферой действия и сроками;

•

[ ] Предусмотрены ли ручные контрольные точки для действий с высоким риском;

•

[ ] Может ли Codex самостоятельно выбирать путь реализации в пределах безопасных границ;

•

[ ] Существуют ли правила остановки и «UNKNOWN» в случае аномалий;

•

[ ] Видел ли человек, принимающий окончательное решение, доказательства соответствующего уровня.

«Руководитель» — это не ролевой термин, позволяющий ИИ действовать по своему усмотрению. Это система ответственности.

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

Основания и границы данной главы

•

Пример интернет-магазина взят из реального проекта интернет-магазина «Jingmai», которым лично управляет автор, а также из соответствующих доказательственных материалов (C06) и матрицы взаимодействия с примером; отзывы на конкретных страницах обобщены в соответствии с состоянием бизнеса, информация об учетных записях, товарах и заказах не разглашается.

•

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

•

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

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

Почему даже очень длинное задание всё равно может сойти с курса

Одна из платформ рыночной аналитики реализовывала проект, следуя этапам от G0 до G7. Задачи охватывали архитектуру, безопасность, данные, инструменты MCP, интерфейсы, плагины, подачу материалов и тестирование. На каждом этапе были получены результаты, и в итоге все показатели стали «зелеными».

Судя по итоговому отчёту, это типичный пример того, как «хорошие указания приводят к хорошим результатам»: требования были подробными, этапы чётко определены, проверки — исчерпывающими.

Однако независимая проверка всё же выявила несколько ключевых проблем: планировщик не был должным образом подключён к Cadence, виджет отображал успешные запросы на извлечение данных как пустые результаты, в Discovery имелись конфликты между идеаленными ключами, а в Preflight обнаружились уязвимости, связанные с типами данных.

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

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

Поэтому проблема не в том, что «подсказка недостаточно длинная». Проблема в том, что постоянно меняющийся проект рассматривается как система вопросов и ответов, требующая всего одного ввода и одного вывода.

На что способен промпт

Подсказка лучше всего подходит для выполнения четырёх задач:

описать результат, который необходимо получить в данный момент;

указать актуальный контекст;

указать ключевые границы и формат вывода;

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

В руководстве по лучшим практикам Codex от OpenAI «Goal», «Context», «Constraints» и «Done when» рассматриваются как хорошая отправная точка для важных задач; в случае сложных или неоднозначных задач рекомендуется сначала составить план или позволить Codex сначала конкретизировать идеи с помощью вопросов. [1]

Это означает, что подсказка является точкой входа в совместную работу, а не всей системой совместной работы.

Даже самый чёткий вход не решает три категории долгосрочных проблем:

•

будет ли следующая задача помнить те же правила;

•

кто имеет приоритет при конфликте нескольких файлов в репозитории;

•

пропустил ли сам разработчик в своих тестах непредвиденные пути.

Почему одноразовый чат не работает

Правила существуют только в памяти человека

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

План не обновляется с учётом фактических данных

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

В объявлении о завершении отсутствует возможность опровержения

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

Отсутствие накопления опыта

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

Переход от подсказок к пятиуровневой системе задач

Первый уровень: подсказки для текущего раунда

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

Второй уровень: договор о задаче и план выполнения

Для сложных задач сначала составьте соглашение, подлежащее проверке: факты и неизвестные, объем и нецели, полномочия, сегменты, доказательства и условия прекращения. План — это не фиксированный маршрут, а оптимальный маршрут с учетом текущих доказательств; при изменении фактов его следует явно обновлять.

Третий уровень: постоянные правила проекта

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