Оригинальный заголовок: Руководство по /goal
Автор оригинала: @dkundel, член команды поддержки разработчиков OpenAI
Перевод: Peggy

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

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

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

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

Ниже — оригинальный текст:

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

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

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

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

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

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

«Сократить время сборки и развертывания на 30%.»

«Перенести этот функционал с TypeScript на Rust и достичь 100% тестового соответствия.»

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

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

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

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

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

Давайте максимально подробно указывать инструкции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поставить Codex визуальную задачу, например «100% пиксельной точности этого UI», — заманчиво. Но при неправильной постановке это может привести к проблемам.

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

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

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

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

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

Вот несколько способов отслеживать прогресс:

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

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

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

· Можно запустить отдельный чат, чтобы спрашивать о статусе — он будет иметь всю историю, но короткий срок жизни.

· Или открыть новый чат, чтобы Codex прочитал другой поток целей и ответил на ваши вопросы. Можно также настроить автоматические проверки прогресса.

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

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

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

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

Задайте следующую цель

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

Что вы делали с /goal?

[ссылка на оригинал]

Кликните, чтобы узнать о вакансиях в Rhythm BlockBeats

Присоединяйтесь к официальному сообществу Rhythm BlockBeats:

Группа в Telegram: https://t.me/theblockbeats

Общий чат в Telegram: https://t.me/BlockBeats_App

Официальный аккаунт в Twitter: https://twitter.com/BlockBeatsAsia