План перед Codex: как получить маршрут работы до первой правки

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

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

Это не бюрократия. Это способ остановить хаотичную правку до того, как она началась.

Почему Codex не должен сразу бросаться в файлы

Когда задача звучит как "улучши страницу", "почини публикацию", "доделай модуль", "сделай нормальный текст", Codex может начать действовать слишком рано. Он прочитает часть контекста, сделает разумные предположения и пойдет менять файлы. Иногда это сработает. Но если задача неточная, цена ошибки будет выше: появятся лишние изменения, не те проверки, спорный результат и длинная ручная приемка.

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

План перед выполнением нужен в четырех случаях:

Если вы пропускаете этот этап, вы принимаете не план, а уже последствия.

Что OpenAI называет планированием перед сложной задачей

В документации OpenAI по Codex есть несколько связанных советов. Для хорошей задачи полезно дать цель, контекст, ограничения и критерий готовности. Для сложных или неоднозначных задач рекомендуется просить Codex сначала спланировать работу. А в разделе о промптах отдельно говорится: сложную работу лучше разбивать на небольшие фокусные шаги; если непонятно, как делить задачу, попросите Codex предложить план.

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

Хороший план отвечает на вопросы:

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

Так документационная рекомендация превращается в рабочий навык: сначала маршрут, потом действие.

Что дать Codex на вход

Запрос не должен быть длинным ради длины. Ему нужна структура. Минимальный вход выглядит так:

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

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

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

Критерий готовности. Что должно быть true в конце. Тест прошел, страница открывается, live-аудит passed, текст не содержит внутренних меток, пользователь может выполнить действие.

Просьба о плане. Самое важное: "Сначала не редактируй файлы. Дай план, риски, проверки и спроси подтверждение".

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

Какой артефакт должен вернуться вместо тумана

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

Хороший план конкретнее. Он должен содержать:

• 3-7 шагов работы;
• список мест, которые Codex собирается читать или менять;
• явные ограничения;
• риски и предположения;
• проверку результата;
• вопрос к человеку, если без него нельзя двигаться дальше.

Например, для статьи о Codex хороший первый артефакт может быть таким: "Я проверю официальный раздел документации, соберу карточку навыка, предложу H1 и H2, напишу черновик, прогоню текстовый аудит, сгенерирую V4-визуал, затем передам пакет в публикационный граф. До публикации покажу блокеры, если Silver или live-аудит остановят статью".

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

Как проверить план без программирования

Непрограммисту не нужно оценивать архитектуру кода на первом шаге. Ему нужно проверить управляемость.

План можно принять, если на пять вопросов есть нормальные ответы:

1. Codex правильно понял цель?
2. Он назвал источник или место, откуда будет брать контекст?
3. Он обозначил, что не будет менять?
4. Он объяснил, какой результат вернет?
5. Он написал, как этот результат проверить?

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

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

Когда разрешать выполнение

Разрешение на выполнение - это отдельное решение. Не стоит смешивать его с первым запросом.

Рабочая схема такая:

1. Вы даете Codex задачу и просите план.
2. Codex возвращает маршрут, риски и проверки.
3. Вы выбираете: подтвердить, сузить, добавить контекст или остановить.
4. Только после этого Codex получает команду выполнять.

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

Это и есть практический контроль: не руками делать работу, а руками принимать направление.

Готовая формула запроса

Можно использовать такой шаблон:

Мне нужно: [цель].

Контекст: [файлы, ссылки, ошибка, пример, текущая ситуация].

Ограничения:
- [что нельзя менять]
- [какие правила соблюдать]
- [какие проверки обязательны]

Готово, когда: [измеримый результат].

Сначала не редактируй файлы и не выполняй задачу.
Сначала дай план:
1. что ты понял как цель;
2. какие места будешь читать;
3. какие шаги предлагаешь;
4. какие есть риски и предположения;
5. как проверишь результат;
6. какой вопрос нужно решить человеку перед выполнением.
После плана остановись и жди подтверждения.

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

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