Руководство по использованию режима цели в Codex: как заставить ИИ последовательно продвигаться к конкретной цели

marsbitОпубликовано 2026-06-06Обновлено 2026-06-06

Введение

OpenAI представила режим цели (/goal) для Codex, который позволяет ИИ непрерывно работать над достижением конкретного результата в течение часов или даже дней. Ключ к эффективному использованию — определение чётких, измеримых критериев завершения (например, «сократить время сборки на 30%» или «добиться LCP ниже 2,5 сек»), а не длинные описания. Важно давать Codex направление, инструменты и доступ к реалистичной среде (например, staging, близкому к production), чтобы он мог оценивать прогресс. Для визуальных задач лучше ставить функциональные или системные требования, а не требовать «пиксель в пиксель». При длительной работе полезно отслеживать прогресс через коммиты, черновики PR, обновления в Slack или отдельные чаты (/side). После достижения цели рекомендуется провести ревью и рефакторинг, чтобы убрать пробные или неоптимальные изменения. Таким образом, роль разработчика смещается от написания промптов к управлению автономным инженерным агентом, который самостоятельно работает над чётко определёнными, измеримыми целями.

Примечание редактора: эта статья от Доминика Кунделя, члена команды по работе с разработчиками 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?

Трендовые криптовалюты

CitreaCTR

wrapped stUSDTWSTUSDT

Связанные с этим вопросы

QЧто такое режим 'goal mode' (или /goal) в Codex и какую основную задачу он решает?

AРежим 'goal mode' (или /goal) в Codex — это функция, которая позволяет задать искусственному интеллекту конкретную цель, к достижению которой он будет последовательно стремиться. В отличие от стандартных запросов, этот режим превращает Codex из инструмента, реагирующего на единичные команды, в агента, способного непрерывно работать над достижением определённого результата — будь то оптимизация производительности, миграция кода или визуальная разработка. Ключевая задача — предоставить Codex чёткий, измеримый критерий завершения работы.

QКаковы основные рекомендации по формулированию цели для Codex в режиме /goal?

AОсновная рекомендация — формулировать цель максимально чётко и с измеримыми критериями завершения. Цель должна содержать конкретные, проверяемые показатели, например: «сократить время сборки и деплоя на 30%», «достичь 100% покрытия тестами» или «снизить LCP (Largest Contentful Paint) ниже 2,5 секунд». Это позволяет Codex самостоятельно оценивать прогресс и понимать, когда задача выполнена. Слишком длинные или расплывчатые формулировки могут привести к неэффективной работе.

QПочему в статье рекомендуется с осторожностью ставить Codex визуальные задачи, такие как «пиксель в пиксель воссоздать UI»?

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

QКакие способы отслеживания прогресса Codex при долгосрочных задачах предлагаются в статье?

AДля отслеживания прогресса в долгосрочных задачах предлагается несколько методов: 1) Запрашивать у Codex коммиты кода и создание черновика Pull Request. 2) Поручать ему обновлять специальный документ о ходе работы (HTML, Markdown или через платформу Sites). 3) Настроить автоматические оповещения о важных этапах (например, в Slack). 4) Использовать функцию /side для создания отдельного краткосрочного чата с текущим контекстом, чтобы быстро узнать статус.

QЧто важно сделать после того, как Codex сообщит о достижении поставленной цели?

AПосле достижения цели важно не просто принять результат, а провести финальную проверку и рефлексию. Рекомендуется: 1) Выполнить локальный код-ревью с помощью команды /review. 2) Попросить Codex проанализировать пройденный путь — какие подходы сработали, а какие нет. 3) Очистить код от промежуточных или неэффективных изменений, которые могли остаться в процессе итеративной работы. Это помогает получить чистый, качественный и осмысленный итоговый результат.

Похожее

Tether (USDT) опубликовал ожидаемые финансовые результаты за второй квартал! Вот его текущее состояние и активы

Крупнейший эмитент стейблкоинов Tether опубликовал финансовый отчёт за второй квартал 2026 года, подтверждённый аудитором BDO. Чистая операционная прибыль составила около $1,5 млрд, а превышение активов над обязательствами достигло $4,11 млрд. Объём USDT в обращении на 30 июня составил приблизительно $184,6 млрд, увеличившись за квартал на $446 млн. Доля Tether на мировом рынке стейблкоинов превысила 60%. Основную часть прибыли принесли инвестиции в казначейские облигации США и операции репо. Совокупные активы компании оцениваются в $187,75 млрд, обязательства — в $183,64 млрд, из которых $183,62 млрд связаны с выпущенными токенами. Tether сократил объём обеспеченных кредитов на $2,38 млрд (15%) и увеличил золотой запас на 14 тонн, доведя его до более чем 146 тонн. Компания остаётся одним из крупнейших мировых держателей гособлигаций США, а её пользовательская база выросла более чем на 30 миллионов человек. Генеральный директор Паоло Ардоино подчеркнул, что USDT полностью обеспечен резервами, и сообщил о прохождении всестороннего аудита в одной из "большой четвёрки" аудиторских фирм.

cryptonews.ru11 мин. назад

Tether (USDT) опубликовал ожидаемые финансовые результаты за второй квартал! Вот его текущее состояние и активы

cryptonews.ru11 мин. назад

Circle достигла важной вехи в области регулирования, получив лицензию на ведение трастовой деятельности от Департамента финансовых услуг штата Нью-Йорк (NYDFS)

Компания Circle, предоставляющая финансовые услуги и услуги в сфере стейблкоинов, достигла важного этапа, получив от Департамента финансовых услуг штата Нью-Йорк (NYDFS) устав трастовой компании с ограниченным кругом деятельности. Эта лицензия позволяет Circle расширить свою деятельность в штате Нью-Йорк, предлагая клиентам услуги по хранению активов, выпуск одобренных штатом стейблкоинов и управление резервными фондами для их обеспечения. Соучредитель и генеральный директор Circle Джереми Аллайр отметил, что получение данной лицензии было давней целью компании, подчеркивая ясность регулирования, которую она предоставляет. Он назвал NYDFS международным органом, устанавливающим стандарты в регулировании цифровых активов, а само достижение — результатом более чем десятилетней приверженности соблюдению нормативных требований. Компания рассматривает это как подтверждение своих высочайших стандартов безопасности, прозрачности и соответствия, сравнивая уровень проверки NYDFS с требованиями к полноценным коммерческим банкам. Данное разрешение от NYDFS последовало за недавним одобрением Управления валютного контролера США (OCC) на создание Circle National Trust, что перевело деятельность компании по выпуску стейблкоинов под федеральный надзор. Эти шаги, по словам руководства Circle, направлены на установление нового стандарта прозрачности и управления, укрепляя позиции стейблкоина USDC в глобальной финансовой системе.

cryptonews.ru23 мин. назад

Circle достигла важной вехи в области регулирования, получив лицензию на ведение трастовой деятельности от Департамента финансовых услуг штата Нью-Йорк (NYDFS)

cryptonews.ru23 мин. назад

Криптовалюта со скидкой: биткоин в России может стать дешевле мирового рынка

В России с 1 сентября 2026 года вступит в силу закон о криптовалютах, создающий лицензионную среду для торговли цифровыми активами. Однако эксперты прогнозируют, что это может привести к формированию дисконта на криптовалюты, включая биткоин, внутри страны по сравнению с мировыми ценами. Основными причинами станут санкционные риски, строгий комплаенс (включая проверки происхождения средств AML/KYT) и ограниченные возможности вывода монет за рубеж. Активы, прошедшие через российскую инфраструктуру, могут получить риск-метки, снижающие их ликвидность на международных площадках. Теоретическая возможность арбитража (покупка дешевле в России и продажа дороже за рубежом) на практике будет крайне затруднена из-за тех же ограничений, которые создают дисконт. Снятие риск-меток — сложный и длительный процесс, а попытки скрыть историю транзакций через микшеры лишь усугубят ситуацию. Кроме того, высокие комиссии лицензированных посредников, административные издержки и временные затраты на проверки могут полностью съесть потенциальную прибыль. Таким образом, российский рынок может стать изолированной площадкой с более низкими ценами, но извлечь выгоду из этой разницы для рядовых участников окажется практически невозможно. Новая модель в большей степени ориентирована на ограниченный круг крупных игроков и внешнеэкономическую деятельность.

cryptonews.ru24 мин. назад

Криптовалюта со скидкой: биткоин в России может стать дешевле мирового рынка

cryptonews.ru24 мин. назад

Питер Шифф заявляет, что план STRC компании Strategy наносит ущерб акционерам MSTR

Критик биткойна Питер Шифф заявил, что политика компании Strategy Inc. в отношении своих привилегированных акций STRC наносит ущерб держателям обыкновенных акций MSTR. После публикации квартального отчета Strategy, в котором подтверждена цель удерживать курс STRC вблизи номинала в $100, Шифф утверждает, что это создаёт конфликт интересов и перенаправляет ресурсы от акционеров MSTR в пользу инвесторов в привилегированные бумаги. Strategy выпустила бессрочные привилегированные акции STRC с переменным дивидендом (сейчас 12% годовых), чтобы создать стабильный источник финансирования для покупки биткойнов. Компания увеличила долларовый резерв до $3,75 млрд для покрытия дивидендных обязательств и провела выкуп части STRC, демонстрируя приверженность поддержанию этой структуры капитала. Мнения инвесторов разделились. Шифф видит в этом риск размывания доли и ухудшения финансовых показателей для акционеров MSTR. Другие аналитики, например из Grayscale Research, полагают, что действия Strategy снижают риски финансирования и укрепляют доверие рынка. Ключевым испытанием станет способность компании балансировать между покупками биткойнов, выплатой дивидендов по STRC и поддержкой стоимости обыкновенных акций.

cryptonews.ru25 мин. назад

Питер Шифф заявляет, что план STRC компании Strategy наносит ущерб акционерам MSTR

cryptonews.ru25 мин. назад

Blackrock обеспечила 79 % притока средств в биткоин-ETF на сумму 233 млн долларов

Институциональный спрос на криптовалюты вернулся: спотовые биткоин-ETF в США привлекли более 233 млн долларов за один день, причём ни один фонд не зафиксировал оттока. Лидером стал Blackrock (IBIT), обеспечивший 79% притока (183,38 млн долларов). За ним последовали ETF от Bitwise, Fidelity и Morgan Stanley. Общий объём торгов достиг 1,73 млрд долларов. ETF на эфир также показали чистый приток в 13,29 млн долларов, возглавляемый продуктом Blackrock. Фонды на XRP привлекли 5,98 млн долларов, вернув совокупные активы к отметке в 1 млрд долларов, а ETF на Solana зафиксировали скромный прирост. Данные указывают на возобновление широкого институционального аппетита к риску, который распространился за пределы биткоина на другие сегменты крипторынка.

cryptonews.ru27 мин. назад

Blackrock обеспечила 79 % притока средств в биткоин-ETF на сумму 233 млн долларов

cryptonews.ru27 мин. назад

Торговля

Спот

Обсуждения

Добро пожаловать в Сообщество HTX. Здесь вы сможете быть в курсе последних новостей о развитии платформы и получить доступ к профессиональной аналитической информации о рынке. Мнения пользователей о цене на AI (AI) представлены ниже.