Goals в Codex Desktop: инструкция для начинающих

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

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

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

Коротко: prompt — это следующее действие. Goal — проверяемый конечный результат.

Когда использовать Goal

Goal подходит, если:

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

Примеры подходящих задач:

• найти и доказать причину нестабильного теста;
• обновить зависимость и исправить связанные несовместимости;
• провести аудит проекта и подготовить отчёт;
• улучшить производительность до измеримого значения;
• подготовить статью, сверить факты и собрать финальную редакцию;
• проверить интерфейс на desktop и mobile;
• довести ветку до состояния, готового к review.

Когда Goal не нужен

Обычного запроса достаточно, если нужно:

• объяснить термин;
• перевести абзац;
• найти один файл;
• переписать заголовок;
• исправить одну очевидную опечатку;
• выполнить короткое действие без последующих итераций.

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

работа → проверка → следующая попытка → повторная проверка → завершение

Как поставить первую цель

Введите /goal, пробел и формулировку результата:

/goal Подготовить проверенное обновление руководства по Goals, сохранив полезные примеры и структуру. Ничего не публиковать без отдельного подтверждения.

После этого Goal становится частью текущей задачи Codex.

Проверить активную цель:

/goal

Поставить работу на паузу:

/goal pause

Продолжить после паузы:

/goal resume

Удалить текущую цель:

/goal clear

/goal clear именно удаляет Goal. Это не доказательство того, что работа выполнена.

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

Чем Goal отличается от большого промпта

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

Goal сохраняет конечный результат внутри задачи. После промежуточной проверки Codex может определить:

• достигнута ли цель;
• что ещё не подтверждено;
• какой следующий шаг даст больше всего информации;
• нужно ли повторить проверку;
• требуется ли решение пользователя;
• возник ли блокер.

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

Формула хорошей цели

Сильная Goal обычно отвечает на шесть вопросов.

1. Какой результат должен быть получен

Опишите конечное состояние, а не только первое действие.

Слабо:

/goal Посмотри проект.

Лучше:

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

2. Чем подтвердить результат

Назовите evidence — то, что можно проверить:

• тесты;
• benchmark;
• команды и их вывод;
• публичная страница;
• итоговый документ;
• скриншоты;
• diff;
• список источников;
• пользовательский сценарий;
• read-back из внешней системы.

Пример:

Готово, когда локальная сборка проходит, тесты зелёные, а изменённый сценарий проверен в интерфейсе.

3. Что нельзя сломать

Добавьте важные ограничения:

Не менять публичный API.
Не удалять пользовательские данные.
Не отключать существующие проверки.
Сохранить текущую структуру и объём материала.

4. Где разрешено работать

Обозначьте границы:

Работать только в текущем репозитории.
Не трогать production.
Не менять базу данных, DNS, secrets и внешние сервисы.

5. Как действовать между попытками

Для исследовательской задачи можно написать:

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

Для разработки:

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

6. Когда остановиться с блокером

Заранее определите честную остановку:

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

Универсальный шаблон

/goal [желаемый конечный результат].

Проверка:
[тест, документ, отчёт, интерфейс, команда или другой источник evidence].

Границы:
[разрешённые файлы, системы, источники и действия].

Сохранить:
[поведение, данные, API, структуру или другие ограничения].

Порядок работы:
[как выбирать следующий шаг между итерациями].

Готово, когда:
[проверяемые критерии завершения].

Если заблокировано:
[что нужно зафиксировать и какое решение или доступ позволит продолжить].

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

Плохая и хорошая формулировка

Плохо:

/goal Улучши сайт.

Непонятно:

• какую страницу менять;
• что означает «улучшить»;
• можно ли менять тексты и backend;
• как проверить результат;
• разрешена ли публикация.

Лучше:

/goal Найти и исправить проблемы первого экрана страницы /services/ на desktop и mobile.

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

Границы:
работать только с frontend этой страницы. Не менять backend, формы, аналитику и содержание оффера.

Порядок работы:
сначала read-only аудит и скриншоты, затем минимальные изменения, после них повторная визуальная проверка.

Готово, когда:
исправления показаны на desktop и mobile, релевантные проверки проходят, diff не содержит посторонних изменений.

Не публиковать и не создавать deploy без отдельного подтверждения.

Готовые шаблоны

Изучение новой темы

/goal Помочь мне разобраться в [тема] до уровня, на котором я смогу самостоятельно объяснить основные понятия и применить их на простом примере.

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

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

Read-only разбор проекта

/goal Подготовить проверяемую карту текущего проекта.

Границы:
только читать файлы и конфигурацию. Ничего не менять, не запускать deploy, не обращаться к production и не выводить secrets.

Порядок работы:
сначала определить правила проекта и источники правды, затем точки входа, компоненты, потоки данных и критические зависимости.

Готово, когда:
есть краткая архитектурная карта, список ключевых файлов, основные риски, неизвестное и следующий безопасный шаг.

Диагностика бага

/goal Найти наиболее вероятную причину бага: [описание].

Границы:
начать с read-only анализа. Не изменять production, данные, auth, routing и внешние сервисы.

Порядок работы:
зафиксировать expected и actual, найти способ воспроизведения, собрать evidence и проверить гипотезы по одной.

Готово, когда:
проблема воспроизводится, причина подтверждена либо оставлены 1–2 конкретные проверяемые гипотезы с указанием недостающих данных.

Исправление не выполнять без отдельного подтверждения.

Подготовка статьи

/goal Подготовить полную статью о [тема] для [аудитория].

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

Границы:
не выдумывать факты и личный опыт, не сокращать полезные разделы без необходимости, ничего не публиковать.

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

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

Проверка интерфейса

/goal Проверить экран [страница или сценарий] глазами нового пользователя.

Границы:
не менять backend, данные, аналитику и содержание оффера без отдельного согласования.

Порядок работы:
проверить desktop и mobile, загрузку, пустые состояния, ошибки, понятность действий и визуальную иерархию.

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

Подготовка к релизу

/goal Определить, готова ли текущая ветка к review и последующему релизу.

Границы:
не пушить, не создавать PR, не мерджить и не деплоить.

Порядок работы:
проверить правила проекта, dirty state, diff, тесты, миграции, документацию, совместимость и возможные изменения поведения.

Готово, когда:
есть решение «готово» или «не готово», список прошедших проверок, блокеров, рисков и следующий безопасный шаг.

Исследование по источникам

/goal Подготовить доказательный разбор вопроса: [вопрос].

Источники:
использовать актуальные первичные и официальные источники. Вторичные материалы применять только для поиска первоисточников или дополнительного контекста.

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

Готово, когда:
есть отчёт с подтверждёнными фактами, ссылками, ограничениями исследования и честно обозначенной неопределённостью.

Библиотека собственных Goal-шаблонов

/goal Подготовить библиотеку из 10 Goal-шаблонов для моих повторяющихся рабочих сценариев.

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

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

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

Управление активной целью

Посмотреть текущую цель

/goal

Используйте эту команду, если нужно проверить:

• какая цель активна;
• не устарела ли её формулировка;
• не изменился ли исходный результат;
• не конфликтует ли новый запрос с текущей работой.

Поставить на паузу

/goal pause

Пауза нужна, если:

• требуется ваше решение;
• нужно проверить промежуточный результат;
• изменилась ситуация;
• продолжение пока нежелательно;
• перед следующим действием требуется отдельное разрешение.

Продолжить

/goal resume

Перед продолжением полезно сообщить Codex новые данные или принятое решение.

Удалить Goal

/goal clear

Удаляйте цель, если она больше не нужна или вы решили начать другой рабочий контур.

Если результат уже достигнут, сначала попросите Codex сверить его с критериями готовности. Очистка Goal не заменяет такую проверку.

Что происходит, пока Goal активен

Активная цель помогает Codex:

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

Продолжение не безусловно. Работа может остановиться, если:

• цель достигнута;
• пользователь поставил её на паузу или удалил;
• требуется решение или подтверждение;
• появился блокер;
• достигнут установленный бюджет;
• задача была прервана;
• дальнейшее действие выходит за разрешённые границы.

Достижение лимита или появление блокера не означает, что цель выполнена.

Goal не отменяет безопасность и подтверждения

Goal задаёт рабочий результат, но не расширяет полномочия Codex.

Если в цели написано «подготовить проект к публикации», это не обязательно означает разрешение:

• публиковать материал;
• выполнять deploy;
• отправлять сообщения;
• менять production;
• записывать данные во внешние системы;
• менять DNS, auth, billing или secrets;
• создавать PR или выполнять merge;
• удалять файлы и данные.

Для потенциально опасной работы добавляйте явную границу:

Сначала выполнить только read-only анализ.

Не изменять файлы, данные, настройки, production, secrets, routing и внешние сервисы без отдельного подтверждения.

Любую публикацию, отправку, deploy, merge или внешнюю запись считать отдельным шагом согласования.

Сильная Goal должна не только направлять работу, но и защищать то, что нельзя менять.

Goal, план, память и трекер задач

Эти инструменты решают разные задачи.

Goal хранит проверяемый конечный результат внутри текущей задачи Codex.

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

AGENTS.md и проектные инструкции задают постоянные правила работы с конкретным проектом.

Память и рабочие заметки сохраняют решения и контекст между задачами и сессиями.

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

Goal не заменяет эти слои. Он связывает их внутри конкретного рабочего контура.

Мини-практика

Шаг 1. Создайте учебную Goal

/goal Научиться формулировать проверяемые Goals для Codex.

Границы:
не менять файлы, настройки и внешние системы.

Порядок работы:
объяснять материал небольшими блоками и давать по одному упражнению.

Готово, когда:
я самостоятельно составлю три качественные цели — для обучения, проекта и подготовки текста.

Шаг 2. Попросите плохой пример

Покажи плохую Goal и помоги превратить её в проверяемую.

Шаг 3. Составьте свои варианты

Напишите три цели и попросите проверить:

Проверь эти Goals. Для каждой отдельно оцени результат, evidence, границы, критерии готовности и условие остановки при блокере.

Шаг 4. Проверьте завершение

Когда упражнения выполнены, попросите:

Сверь результат с критериями готовности активной Goal. Если все критерии подтверждены — подведи итог. Если нет — перечисли, чего не хватает.

Проверить текущее состояние:

/goal

Частые вопросы

Goal сам всё делает без участия человека?

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

Можно поставить несколько целей одновременно?

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

Можно ли создать Goal обычной фразой?

Обычным сообщением можно попросить Codex помочь сформулировать цель:

Преврати это описание в сильную /goal. Пока не активируй её.

После проверки формулировки активируйте Goal через /goal.

Не стоит полагаться на фразу «Поставь цель» как на замену команды: она может остаться обычным запросом и не создать постоянное состояние Goal.

Goal заменяет план?

Нет. Goal определяет результат. План определяет последовательность действий. При сложной работе полезны оба.

Что делать, если задача изменилась?

Если изменился только способ достижения результата, можно уточнить контекст и продолжить.

Если изменился сам конечный результат, лучше поставить текущую Goal на паузу или удалить её, а затем сформулировать новую. Иначе критерии готовности начнут конфликтовать.

Что делать при блокере?

Codex должен сообщить:

• что подтверждено;
• какие варианты уже проверены;
• почему продолжение невозможно;
• какое решение, evidence или разрешение требуется;
• какой следующий шаг станет возможен после разблокировки.

Блокер нельзя выдавать за завершение цели.

Goal может работать бесконечно?

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

Чеклист хорошей Goal

Перед активацией проверьте:

Следующий шаг

Codex App — единый справочник по среде от OpenAI

Связанные материалы

• Статья: Мой первый публичный репозиторий на GitHub — и это Codex-скилл для GPT Pro review
• Блог: Codex обновился — /goal mode вышел из эксперимента и стал полноценной функцией
• База знаний: AGENTS.md / SESSION_NOTES — проектная память для coding-агентов

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov