Goal — это контракт между вами и Codex. Не «сделай шаг», а «доведи до понятного результата по таким-то правилам». Разбираем, как им пользоваться с версии 0.128.0, что писать в самой формулировке и где Goal лишний.
Что это
Goal — режим Codex (slash-команда /goal), который превращает обычный диалог в работу по контракту с критерием готовности. Вместо разового ответа Codex держит в голове одну цель, проверяет прогресс по фактам и продолжает сам, пока не дойдёт до финишной черты.
Идея простая. Обычный промпт — это вопрос: «объясни модуль», «поправь баг», «добавь тест». Codex отвечает и ждёт следующего. Goal — это про другое. Вы задаёте результат, проверочный сигнал и границы, а Codex сам решает, какой следующий шаг самый полезный, и идёт по нему до тех пор, пока есть куда идти.
В терминах документации OpenAI Goal — это persistent objective, привязанный к треду (не глобальный, не проектный). У него есть состояние жизненного цикла (active, paused, complete, budget-limited), бюджет и явный stop-condition. Codex не «делает что попало подряд» — он продолжает только в безопасных точках: после завершённого хода, при свободном треде и при отсутствии пользовательского ввода.
Ключевое правило: Goal — это не «включи автономность и молись». Это компактный контракт: «сделай X, проверь Y, не трогай Z, остановись, когда W».
Зачем нужно
Goal нужен там, где задача не помещается в один ответ, а правильный следующий шаг зависит от того, что Codex только что узнал.
- Разбор нового инструмента или проекта в режиме read-only. Пока Codex сам читает файлы и строит карту, вы не дёргаете его после каждого поворота.
- Расследование сложного бага. Цель — найти причину и доказать её воспроизведением, а не закрыть тикет «оно как-то работает».
- Долгие рефакторинги и миграции. Перенос стека, замена зависимостей, многошаговые переезды — всё, где нужно держать в голове совместимость и критерии пройденных чекпоинтов.
- Эксперименты и прототипы. Игры, оптимизации промптов, тюнинг моделей по eval-сюитам — Codex крутит цикл «попробовал → измерил → выбрал лучшее», пока не достигнет нужной метрики.
- Подготовка материалов. Статья, пост, чеклист — Goal держит структуру и границы (не выдумывать факты, не уходить в рекламу), пока вы проверяете промежуточные версии.
- Аудит перед релизом. Проверить diff, тесты, миграции, риски поведения — и выдать ответ «готово / не готово» со списком блокеров.
Goal не нужен там, где задача закрывается одним ходом: перевести фразу, дать 5 вариантов заголовка, поправить одну строку, объяснить термин. Для этого есть обычный промпт.
Как устроено
Goal реализован как thread-scoped persistent state. Это значит три важных вещи.
1. Цель живёт в треде, а не «в голове» у Codex. Если вы откроете Goal в одном треде, в другом он не подхватится. Контекст — файлы, которые Codex уже прочитал, команды, которые запустил, диффы, логи, рассуждения — остаётся именно там, где Goal активен.
2. Codex продолжает только в безопасных точках. Не в середине хода, не когда вы печатаете сообщение, не когда тред ждёт другой работы. Это защищает от «вращающегося цикла», когда модель тратит ресурсы впустую.
3. Завершение — только по фактам, а не по ощущению. Codex не имеет права сказать «цель достигнута» просто потому, что ему кажется. Должны сойтись проверяемые сигналы: тесты прошли, бенчмарк выдал нужное число, артефакт собран, документ открывается.
В Codex версии 0.128.0 и выше Goal доступен как набор команд:
| Команда | Что делает |
|---|---|
| /goal <цель> | Поставить цель на текущий тред |
| /goal (без аргументов) | Показать текущую цель |
| /goal pause | Поставить на паузу |
| /goal resume | Возобновить работу |
| /goal clear | Удалить цель из треда |
Если slash-команда /goal не появляется в интерфейсе, включите её в config.toml или через CLI:
# ~/.codex/config.toml
[features]
goals = true# или одной командой
codex features enable goalsCodex умеет сам помочь составить Goal: опишите задачу простым языком, попросите превратить её в Goal, отредактируйте критерии готовности и границы — и только потом активируйте.
Когда использовать
| Ситуация | Подходит Goal? | Почему |
|---|---|---|
| Переписать модуль на новый фреймворк с сохранением публичного API | Да | Есть финишная черта, есть тесты как проверочный сигнал |
| Расследовать flaky-тест | Да | Цель — стабильный прогон, есть команда воспроизведения |
| Оптимизировать p95 ответа до 120 мс | Да | Метрика измерима, есть бенчмарк |
| Подготовить черновик поста по вашим заметкам | Да | Структура фиксируется, границы (тон, объём) задаются |
| Объяснить одну функцию | Нет | Один ответ закрывает задачу |
| Сгенерировать 5 заголовков | Нет | Конечного состояния нет, итерации не нужны |
| «Сделай код красивее» | Нет | Нет ни проверочного сигнала, ни границ |
| Свободный бэклог «почини всё подряд» | Нет | Нет ни одной цели с критерием готовности |
Практическое правило: если задача больше одного ответа, но меньше открытого бэклога — это кандидат на Goal. Если больше открытого бэклога — разбейте на несколько Goal’ов.
Формула хорошей цели
В open-source-гайде OpenAI формулировка сильного Goal строится на шести элементах. Не обязательно перечислять их явно — Codex поймёт и без этого — но проверьте, что все шесть закрыты.
| Элемент | Что значит | Пример |
|---|---|---|
| Outcome | Желаемое конечное состояние | «p95 ниже 120 мс» |
| Verification surface | Чем доказываем, что достигли | «прогон бенчмарка checkout» |
| Constraints | Что нельзя сломать по дороге | «корректностные тесты остаются зелёными» |
| Boundaries | Какие файлы, инструменты, ресурсы разрешены | «только сервис checkout и связанные тесты» |
| Iteration policy | Как выбирать следующую попытку | «логировать изменение, бенчмарк, следующий эксперимент» |
| Blocked stop condition | Когда остановиться и доложить | «если бенчмарк не запускается — стоп с описанием блокера» |
Шаблон-формула, которую удобно копировать:
/goal <конечное состояние>,
verified by <проверочный сигнал>,
while preserving <ограничения>.
Use only <разрешённые ресурсы>.
Between iterations <как выбирать следующий шаг>.
If blocked, stop and report <что нужно от человека>.Две версии одной и той же цели — слабая и сильная:
# слабая
/goal Improve performance
# сильная
/goal Reduce p95 latency below 120 ms on the checkout benchmark,
verified by the checkout benchmark run, while keeping the correctness
test suite green. Use only the checkout service, benchmark fixtures,
and related tests. Between iterations, log what changed, what the
benchmark showed, and the next best experiment to try.
If the benchmark cannot run, stop and report the blocker.Вторая версия даёт Codex не только направление, но и контракт: как проверить, что готово, что нельзя сломать, как идти дальше, когда сказать «стоп».
Готовые шаблоны целей
Восемь шаблонов под типовые рабочие сценарии. Копируйте и подставляйте свои значения.
Обучение без риска
Поставь цель: помочь мне освоить <тема> на простых примерах.
Границы: не менять файлы, настройки, базы данных и внешние сервисы.
Формат работы: короткие объяснения, мини-практика после каждого блока, без жаргона.
Готово, когда: я могу сам объяснить тему и привести 3 рабочих примера.Read-only разбор проекта
Поставь цель: понять, как устроен этот проект.
Границы: только читать файлы, ничего не менять, не запускать deploy и не трогать secrets.
Формат работы: сначала карта проекта, потом ключевые потоки, потом риски.
Готово, когда: есть краткая схема архитектуры, список главных файлов и следующий безопасный шаг.Разбор бага
Поставь цель: найти вероятную причину бага <описание>.
Границы: сначала read-only анализ, без изменений в production, базе, routing, auth и webhook.
Формат работы: отделять факты от гипотез, показывать evidence.
Готово, когда: есть воспроизведение, expected vs actual, причина или 1–2 проверяемые гипотезы, и план минимального фикса.Подготовка статьи или поста
Поставь цель: превратить эту идею в понятный пост для <аудитория>.
Границы: не выдумывать факты, не делать рекламный тон, не усложнять.
Формат работы: сначала структура, потом черновик, потом редактура.
Готово, когда: есть версия, которую можно отправить в чат или опубликовать как черновик.Проверка интерфейса
Поставь цель: проверить этот экран глазами нового пользователя.
Границы: не менять backend и тексты оффера без отдельного согласования.
Формат работы: проверить desktop/mobile, пустые состояния, ошибки, загрузку и понятность действий.
Готово, когда: очевидные UI-баги исправлены или перечислены, а спорные продуктовые вопросы вынесены отдельно.Подготовка к релизу
Поставь цель: понять, готова ли эта ветка к релизу.
Границы: не пушить, не мерджить, не деплоить.
Формат работы: посмотреть diff, тесты, миграции, docs и риски поведения.
Готово, когда: есть решение «готово / не готово», список блокеров и проверки, которые прошли или не прошли.Оптимизация промптов по eval-сюите
/goal Improve prompt score on <eval-suite> to >= <target>.
verified by the eval command output, while preserving outputs of the held-out set.
Use only the prompt file and the eval fixtures.
Between iterations, log what changed in the prompt, what the eval showed, and the next best experiment.
If a regression appears, stop and report the diff.Исследование по статье или отчёту
/goal Produce the strongest evidence-backed reproduction of <работа> using
the available materials and local resources. Attempt the headline results
where feasible, verify outputs where possible, and end with a report that
separates confirmed findings, approximate reconstructions, blocked claims,
and remaining uncertainty.Управление активной целью
Команды для работы с уже поставленной целью:
| Действие | Команда |
|---|---|
| Проверить текущую цель | /goal |
| Продолжить работу | «Продолжай по цели.» |
| Уточнить цель | «Уточни цель: теперь важно не только объяснить, но и дать 5 готовых примеров.» |
| Сузить границы | «Добавь ограничение: ничего не менять в файлах и настройках.» |
| Поставить на паузу | /goal pause |
| Возобновить | /goal resume |
| Закрыть цель | /goal clear или «Цель выполнена, закрой её.» |
| Отметить блокер | «Похоже, цель заблокирована: нужно моё решение по доступу или направлению.» |
Codex можно попросить давать компактные status-апдейты: какой сейчас чекпоинт, что проверено, что осталось, есть ли блокер. Если статус расплывается — не добавляйте ещё инструкций, а переформулируйте Goal. Скажите прямо: какой чекпоинт важнее всего сейчас, какой командой он проверяется и когда Codex должен остановиться.
Пример
Минимальный сценарий: вы хотите, чтобы Codex разобрался с новой фичей в вашем проекте, но боитесь, что он начнёт править код «по ходу дела».
/goal Помоги мне понять, как устроена фича <имя фичи> в проекте.
Boundaries: только читать файлы, ничего не менять, не запускать deploy, не трогать secrets.
Verification: список ключевых файлов, схема потоков данных и список рисков — текстом в ответе.
Between iterations: после каждого шага короткий вывод, что узнал и что смотрит дальше.
If blocked, stop and report which file or log is needed to continue.Что произойдёт после активации:
- Codex прочитает релевантные файлы и составит карту: какие модули задействованы, какие функции вызываются.
- Пойдёт по потокам данных сверху вниз: вход → трансформации → выход → побочные эффекты.
- На каждом шаге коротко отчитается, что увидел, и сразу двинется к следующему слою.
- Когда картина соберётся — выдаст сводку: основные файлы, поток, риски, что безопасно делать дальше.
- Если упрётся в непонятный кусок — остановится и попросит у вас либо файл, либо решение по направлению.
Если в какой-то момент вам нужно уточнить или ограничить — пишете обычной фразой, Codex обновит Goal и продолжит с учётом новых границ.
Безопасность и границы
Чем дольше работает Codex по Goal, тем важнее явные границы. Особенно если рядом есть production, база данных, платежи, auth, секреты, deploy, чужие файлы.
Хорошая привычка для опасных контекстов — начинать Goal со строки:
Boundaries: сначала только read-only анализ.
Не менять файлы, настройки, данные, secrets, deploy, routing и внешние сервисы
без отдельного подтверждения.Дополнительные правила:
- Одна активная цель на один поток работы. Несколько параллельных целей начинают конфликтовать и теряют фокус.
- Опасные действия — только по явному подтверждению. Удаление, деплой, миграции БД, изменения в auth — всё это Codex делает, только если вы отдельно разрешили.
- Бюджет — ваш союзник. Если Goal упёрся в лимит, Codex остановится, подведёт итоги и попросит следующий шаг. Это не «провал», а сигнал, что пора вмешаться.
- Проверочный сигнал — единственный источник правды. «Похоже, работает» не считается. Должны сойтись тесты, метрики, артефакты.
Goal и соседние инструменты
| Инструмент | Что держит | Пример |
|---|---|---|
| Goal в Codex | Курс внутри текущего диалога | «Помоги мне разобраться, что именно надо сделать» |
| Notion | Человеческую память: инструкции, решения, выводы | «Вот документ, где зафиксировали план» |
| Linear / GitHub Issues | Исполняемые задачи со статусом, блокерами, критериями готовности | «Вот конкретная задача, которую можно выполнять» |
| AGENTS.md / SESSION_NOTES | Проектные инструкции и состояние сессии | «Вот файл, где описано, как работать с этим репозиторием» |
Goal не заменяет план — он задаёт направление. План говорит, какими шагами идти. Notion и Linear нужны, когда результат надо сохранить и передать другим людям. AGENTS.md помогает Codex понимать контекст проекта между сессиями.
Мини-практика для первого знакомства
Четыре шага, чтобы освоить Goal за один заход.
- 1. Поставьте первую цель.
/goal Помоги мне освоить Goals в Codex Desktop на простых примерах.
Boundaries: не менять файлы и настройки.
Формат работы: объясняй как новичку, задавай маленькие упражнения.
Готово, когда: я сам сформулирую 3 цели — одну для обучения, одну для проекта, одну для текста.- 2. Попросите разобрать ошибку.
Дай мне плохой пример цели и помоги переписать его в хороший.- 3. Попросите проверку.
Проверь мои 3 цели и скажи, где не хватает границ или критериев готовности.- 4. Закройте цель и подведите итог.
Цель выполнена, закрой её и коротко подведи итог.После этого вы уже сможете ставить рабочие Goal’ы для своих задач.
Частые вопросы
Goal сам всё делает без меня?
Нет. Goal задаёт направление и помогает Codex не терять задачу между ходами. Опасные действия всё равно требуют границ и подтверждений. Бюджет и стоп-условия — ваш тормоз.
Можно ли ставить несколько целей сразу?
Лучше держать одну активную цель на один поток работы. Несколько целей начинают конфликтовать и теряют фокус. Для параллельных задач — несколько тредов.
Что делать, если /goal не появляется в интерфейсе?
Обновите Codex до версии 0.128.0 или выше. Затем включите Goal в config.toml ([features]\ngoals = true) или через codex features enable goals. Если всё равно не видно — проверьте, что версия Codex поддерживает Goals (codex —version).
Goal заменяет план?
Нет. Goal говорит, куда идти. План говорит, какими шагами. Для сложных задач описывайте план в отдельном документе и используйте Goal, чтобы Codex по нему двигался.
Goal заменяет Notion или Linear?
Нет. Goal живёт в рабочем диалоге. Notion и Linear нужны, когда результат надо сохранить, передать другим людям или продолжить в другом контексте.
Что значит «Goal завершён»?
Что Codex проверил финишную черту по фактическому сигналу: тесты прошли, метрика достигнута, артефакт собран. Это не «мне кажется, готово», а «я проверил — сошлось».
Ограничения
Ограничения
Прежде чем включать Goal в продакшен-процесс, держите в голове эти грабли — не каждая задача становится лучше от Goal, и не каждая формулировка работает как контракт.
Зависимость от версии Codex — Goal доступен с версии 0.128.0.
В более ранних сборках slash-команда может не появиться даже после включения фичи в config.toml. Сначала обновите Codex.
Goal не глобальный — он привязан к треду. Открыли новый тред — Goal надо ставить заново. Это защищает от утечки контекста, но требует дисциплины:
не теряйте важные цели при переключении между тредами.
Проверочный сигнал должен быть проверяемым — если в формулировке Goal нет ни теста, ни команды, ни артефакта, Codex не сможет честно сказать «готово».
Слабая формулировка делает Goal бесполезным.
Бюджет не бесконечен — Goal упрётся в лимит, и это нормальный сценарий.
Codex остановится и попросит следующий шаг. Не путайте «бюджет исчерпан» с «задача провалена».
Один активный Goal на тред — параллельные цели начинают конфликтовать и теряют фокус.
Если задач несколько — несколько тредов.
Не все задачи подходят — для одноразовых правок, объяснений и коротких ответов обычный промпт лучше.
Goal ради Goal — антипаттерн.
Антипаттерны
Антипаттерны
Цель, которая звучит как лозунг, приносит больше вреда, чем её отсутствие. Вот типовые провалы — держитесь подальше.
«Сделай лучше» без критерия — Goal без измеримого результата не имеет стоп-сигнала.
Codex будет крутиться бесконечно или закрывать цель по ощущению.
«Почини всё в этом репозитории» — это бэклог, а не Goal.
Разбейте на конкретные задачи со своими критериями готовности.
Goal без границ в опасном контексте — рядом с production, БД, платежами, auth и секретами Goal без явных Boundaries:
read-only — это бомба замедленного действия.
Goal, в котором не сказано, что нельзя трогать — Codex может «улучшить» смежный модуль, обновить зависимость или переписать форматирование.
Если это не входит в задачу — назовите это явно.
Добавлять инструкции вместо переформулирования Goal — если статус расплылся, не пишите «ещё раз проверь X». Переформулируйте Goal:
какой чекпоинт важнее всего сейчас, какой командой он проверяется.
Goal ради Goal — для одноразовой правки или короткого объяснения обычный промпт быстрее и проще.
Не превращайте Goal в серебряную пулю.
Чеклист
Чеклист
Прежде чем нажать /goal, пройдитесь по этим семи пунктам. Если хотя бы два из них «нет» — переформулируйте Goal до запуска.
Результат сформулирован как проверяемое состояние
не «улучшить», а «p95 ниже 120 мс», не «разобраться», а «есть карта файлов и потоков».
Назван проверочный сигнал — тест, бенчмарк, команда, артефакт.
Без этого Goal не имеет стоп-условия.
Перечислены ограничения
что нельзя ломать, какие модули нельзя трогать, какие действия требуют подтверждения.
Указаны границы ресурсов — какие файлы, инструменты, сервисы разрешены.
Особенно важно в больших репозиториях.
Понятен формат работы
как Codex отчитывается, какие статусы показывает, в каком виде выдаёт промежуточные результаты.
Задача достаточно длинная или важная для Goal
если её можно закрыть одним ответом, Goal лишний.
Вы знаете, как закрыть Goal
/goal clear, /goal pause, «Цель выполнена, закрой её.» Без этого Goal повиснет в треде.
Ссылки
Ссылки
- Документация: Follow a goal
- Cookbook: Using Goals in Codex
- Codex: Commands