Примечание редактора: эта статья от Доминика Кунделя, члена команды по работе с разработчиками OpenAI, обобщает опыт использования функции Codex «режим цели» (/goal). Речь идет не об обычном приеме промптов, а об изменении роли инструментов ИИ-программирования: Codex перестает быть просто помощником по коду, реагирующим на одноразовые инструкции, и начинает превращаться в агента-исполнителя, который может последовательно работать над достижением четкой цели.
В режиме /goal действительно важно не писать требования как можно длиннее и детальнее, а задавать для Codex четкие, проверяемые критерии завершения. Например: «сократить время развертывания на 30%», «достичь 100%-ной паритетности тестового покрытия», «снизить LCP ниже 2,5 секунды». Эти показатели позволяют Codex определить, выполнена ли задача, и избежать бесконечных попыток и ошибок при нечеткой цели. В то же время пользователю необходимо предоставить достаточно указаний, инструментов и реальной среды, чтобы Codex мог оценивать прогресс и проверять результаты, а не просто создавать кажущееся работоспособным решение локально или в гипотетических условиях.
В статье особенно подчеркивается, что визуальные задачи чаще всего затягивают Codex в болото деталей. Вместо требования «100%-ного пиксельного соответствия» лучше разбивать визуальную цель на функциональный список, спецификации дизайн-системы и поддающиеся оценке метрики. Для долгосрочных задач, продолжающихся несколько часов или даже дней, также необходим постоянный мониторинг через коммиты, черновые PR, документы о ходе работ, обновления в Slack или побочные чаты, чтобы в итоге не получить лишь кучу неотслеживаемых изменений.
Информационная ценность этой статьи заключается в том, что она переопределяет /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 может, ради «пиксельного соответствия» какому-либо UI, просто обрезать референсный макет и встроить его в страницу; или, чтобы добиться 100%-ной проходимости тестов, сократить покрытие тестами. Это не те способы завершения, которых вы на самом деле хотите.
Создайте реалистичную среду
Если вы хотите, чтобы Codex действительно добивался эффективного прогресса в достижении цели, ему необходимо работать в достаточно реалистичной среде.
На практике это означает: если вы хотите оптимизировать время развертывания или задержки, Codex должен иметь доступ к средам развертывания и тестирования, максимально приближенным к production. То есть использовать тот же технологический стек, те же конфигурационные переключатели и аналогичную базу данных.
Например, мы как-то отлаживали оптимизацию времени сборки и развертывания для developers.openai.com. В то время мы уже использовали preview-развертывания, поэтому Codex мог использовать эти среды для деплоя и просмотра соответствующих логов. Но проблема была в том, что в наших preview-деплоях, по сравнению с полноценной production-средой, были отключены некоторые пути сборки.
В итоге Codex пришлось выполнять ручное развертывание, помещая код в среду, более близкую к production-конфигурации, чтобы действительно проверить проблему.
Аналогичным образом вы можете позволить Codex использовать computer use (возможность модели взаимодействовать с реальным интерфейсом приложения) для тестирования реального приложения. Чтобы оптимизировать некоторые проблемы производительности на iOS, @dimillian даже использовал физическое устройство для получения наиболее точной тестовой среды.
Осторожно ставьте визуальные цели
Дать Codex визуальную цель, например, «воссоздать этот UI с 100%-ным пиксельным соответствием по этой картинке», действительно заманчиво. Но в зависимости от конкретных условий это может создать проблемы.
Если вы не дадите подходящих указаний и ограничений, Codex может увязнуть в деталях и упустить общую цель. Например, если референсное изображение содержит графические элементы, и вы ожидаете, что Codex сгенерирует их — будь то иконки SVG или картинки — он может потратить много усилий на «точное воссоздание этих ресурсов», вместо того чтобы правильно декомпозировать всю проблему.
Кроме того, Codex нужны инструменты для корректного визуального сравнения. Это означает больше ввода изображений, большее общее потребление токенов, но не обязательно дает Codex простой способ выявления действительно ценных возможностей для улучшения.
Поэтому изображения обычно лучше подходят в качестве контекста цели, а не единственного критерия завершения. Следует искать другие способы, позволяющие Codex определить, достигнута ли цель, например, функциональный чек-лист, спецификации реализации, соответствие дизайн-системе.
Отслеживайте прогресс
Если Codex в итоге работает в фоне несколько часов или даже дней, или даже на другой машине, легко забыть, на каком этапе он находится и какую работу уже проделал.
В зависимости от цели я нашел полезными следующие методы:
· Заставлять Codex фиксировать код в ключевых точках и отправлять его в черновой PR. Особенно это полезно, когда вы работаете над сайтом и у вас есть preview-деплой.
· Заставлять Codex обновлять документ для менеджмента. Это может быть HTML-файл, который вы держите открытым во встроенном браузере; может быть · страница, развернутая через Sites для просмотра командой; может быть визуализированная диаграмма прогресса или просто обычный Markdown-файл.
Указывать Codex активно публиковать обновления о прогрессе. Вы также можете включить это в цель: чтобы Codex отправлял обновления в канал Slack или в другие места, где вы хотите фиксировать прогресс, при достижении важных вех.
Использовать другие окна чата для запроса статуса. Если вы просто хотите быстро узнать текущее состояние, можно запустить /side для начала нового побочного чата и задать вопрос там. Поскольку он форкается из текущего треда, он имеет весь контекст до этого момента, но его жизненный цикл короткий.
Другой вариант в приложении Codex: начать обычный новый чат и попросить Codex прочитать другой тред с целью и ответить на ваши вопросы. Этот подход особенно мощный, если вы поручите Codex настроить автоматизированную задачу для периодической проверки прогресса.
Приведите в порядок и окончательно подтвердите результат
Отлично, цель наконец достигнута! Теперь можно просто скинуть результат команде и закончить?
Как правило, особенно в задачах оптимизации, я считаю полезным позволить Codex пересмотреть и проанализировать свою работу. Вы можете сначала запустить локальный код-ревью с помощью /review, но также стоит дать Codex глубже поразмышлять: какие пути он пробовал для достижения цели? Что сработало? Что не сработало? И затем привести код в порядок на основе этого.
Поскольку Codex будет работать до тех пор, пока цель не будет достигнута, он мог попробовать методы, которые оказались недостаточно хорошими или вовсе неэффективными, и эти остаточные изменения могут остаться в финальном коде.
Поставьте цель и для своей следующей задачи
Функция цели в Codex — чрезвычайно мощный инструмент, который может помочь вам решить самые значимые инженерные задачи. Но только при наличии правильной среды и инструкций он сможет эффективнее достигать цели.
Что вы делали с помощью /goal?
