Редакторская заметка: Эта статья от участника команды по работе с разработчиками OpenAI Доминика Кунделя, подводящая итоги опыта использования функции Codex «goal mode / /goal». В ней рассматривается не просто прием работы с промптом, а изменение роли инструмента ИИ для программирования: Codex больше не просто помощник по коду, реагирующий на однократные команды, а начинает выступать в роли исполнительного агента, способного последовательно продвигаться к четко определенной цели.

В режиме /goal важно не то, насколько длинным и детальным будет описание требований, а то, чтобы для Codex были заданы четкие и проверяемые критерии завершения. Например: «снижение времени развертывания на 30%», «покрытие тестами на уровне 100% parity», «LCP ниже 2,5 секунды». Эти показатели позволяют Codex определить, завершена ли задача, и избегают бесконечных попыток на основе нечетких целей. В то же время пользователь должен предоставить достаточные ориентиры, инструменты и реальную среду, чтобы Codex мог оценивать прогресс и проверять результаты, а не просто реализовывать кажущееся жизнеспособным решение в локальной или гипотетической среде.

Статья особенно подчеркивает, что визуальные задачи最容易让 Codex陷入细节泥潭。与其要求「100% 像素级还原」，不如将视觉目标拆解为功能清单、设计系统规范和可评估指标。对于持续数小时甚至数天的长期任务，也需要通过 commit、draft PR、进度文档、Slack 更新或 side chat 等方式持续跟踪，避免最终只得到一堆不可追溯的改动。

Информационная ценность этой статьи заключается в том, что она переопределяет /goal как «механизм управления долгосрочными задачами». Когда ИИ может непрерывно выполнять задачи в течение десятков甚至 сотен часов, ключевые навыки разработчиков также меняются: теперь речь идет не только о том, чтобы заставить ИИ генерировать код, а о том, чтобы определять для него цели, создавать системы измерения, настраивать среду выполнения и в конце проводить проверку и анализ. Другими словами, программирование с помощью ИИ переходит от «написания подсказок» к «управлению непрерывно работающим инженерным исполнителем».

Следует отметить, что:

Мы запустили режим цели (goal mode, или /goal), чтобы помочь вам направить Codex на достижение конкретного результата. После установки цели Codex будет работать непрерывно до её выполнения — независимо от того, сколько времени это займет: несколько часов или несколько дней. Уже есть пользователи, которые заставляли Codex работать над одной и той же целью более 120 часов подряд.

Целевой режим очень мощный. Чтобы максимально эффективно его использовать, при использовании /goal обратите внимание на 7 вещей.

Установите четкие, проверяемые критерии

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

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

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

Сократите время построения и развертывания на 30%.

Перенесите эту функцию из TypeScript в Rust и достигните 100% согласованности тестов.

Оптимизировать каркас приложения, чтобы показатель Largest Contentful Paint (LCP), измеряющий скорость загрузки основного содержимого страницы, в производственной среде был ниже 2,5 секунды.

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

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

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

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

Предоставьте как можно больше инструкций

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

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

Например, мой коллега @reach_vb сделал это в одном из экспериментов: он сообщил Codex, что можно использовать браузер Chrome для доступа к Google Colab, и указал некоторые допустимые ограничения, например, позволить Codex самостоятельно генерировать набор данных при обучении модели.

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

Альтернативный подход заключается в том, чтобы сначала позволить Codex провести предварительное исследование в режиме планирования (plan mode) и создать файл плана, в котором будут зафиксированы потенциальные варианты. Затем вы можете направить свою цель на этот план.

Сделайте прогресс измеримым

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

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

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

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

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

Например, Codex может для «пиксельной точности» воспроизведения интерфейса напрямую обрезать дизайн-референс и встраивать его на страницу; или чтобы достичь 100% проходимости тестов, наоборот сокращать покрытие тестами. Это не те способы завершения, которых вы действительно хотите.

Создайте реальную среду

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

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

Например, мы ранее оптимизировали время сборки и развертывания developers.openai.com. В то время мы уже использовали предварительные версии развертывания, поэтому Codex мог использовать эти предварительные среды для развертывания и просмотра соответствующих журналов. Однако проблема заключалась в том, что наши предварительные развертывания отключали некоторые пути сборки по сравнению с полной производственной средой.

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

Аналогично, вы также можете заставить Codex использовать computer use (способность модели взаимодействовать с реальными интерфейсами приложений) для тестирования реальных приложений. Для оптимизации некоторых проблем с производительностью на iOS @dimillian даже использовал физические устройства, чтобы получить наиболее точную тестовую среду.

Осторожно устанавливайте визуальные цели

Задать Codex визуальную цель, например, «точно воспроизвести этот интерфейс на 100% по пикселям на основе этого изображения», действительно привлекательно. Однако в зависимости от конкретных условий это может вызвать проблемы.

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

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

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

Отслеживание прогресса

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

В зависимости от цели я обнаружил, что следующие методы очень полезны:

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

· Пусть Codex обновит отчет для руководства. Это может быть HTML-файл, который вы можете постоянно открывать во встроенном браузере приложения; или страница, развернутая через Sites для просмотра командой; может быть визуализированная диаграмма прогресса или просто обычный Markdown-файл.

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

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

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

Очистить и окончательно подтвердить результат

Отлично, цель наконец достигнута! Теперь можно просто передать результат команде и закончить работу?

Как правило, особенно в задачах, связанных с оптимизацией, я обнаружил, что полезно заставить Codex пересмотреть и проверить свою выполненную работу. Вы можете сначала запустить локальный код-ревью с помощью /review, но также стоит предложить Codex более глубоко проанализировать: какие пути он пробовал для достижения цели? Какие из них оказались эффективными, а какие — нет? И затем на основе этого очистить код.

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

Установите цель и для вашего следующего задания

Цель Codex — это чрезвычайно мощный инструмент, который поможет вам решить некоторые из самых значимых инженерных задач. Однако он сможет достичь этой цели более эффективно только при предоставлении правильной среды и инструкций.

Что ты делал с помощью /goal?