Интервью с Codex: как превратить смутную идею в рабочую задачу

С Codex легко начать слишком быстро. Возникает мысль: «сделай сайт лучше», «разберись с этой статьёй», «наведи порядок в проекте», «подумай над архитектурой». Codex послушно начинает работать, но через несколько шагов становится видно: задача была не готова. Результат вроде полезный, но не совсем туда.

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

Поэтому один из самых полезных навыков — не просить Codex сразу делать. Сначала попросить его провести короткое интервью.

Почему плохая задача часто начинается слишком быстро

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

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

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

Что документация говорит про интервью перед работой

В официальной документации OpenAI Codex есть простая рекомендация: если задача сложная, неоднозначная или её трудно хорошо описать, попросите Codex сначала спланировать работу. Вариант для большинства пользователей — Plan mode: Codex собирает контекст, задаёт уточняющие вопросы и строит более сильный план до реализации.

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

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

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

Для интервью не нужно готовить идеальное ТЗ. Достаточно дать Codex сырой материал.

Хороший вход выглядит так:

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

Например, вместо длинного объяснения можно сказать:

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

Этого достаточно, чтобы Codex начал не с выполнения, а с уточнения.

Какой артефакт должен получиться после интервью

Интервью без артефакта быстро превращается в разговор. Поэтому заранее стоит попросить Codex вернуть конкретную форму.

После интервью должен появиться короткий рабочий пакет:

Главное здесь — финальный prompt. После интервью Codex должен не просто сказать «понял», а собрать такую формулировку, которую пользователь может прочитать и утвердить.

Как проверить формулировку без кода

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

Первый вопрос: понятно ли, что именно будет сделано? Если формулировка всё ещё звучит как «улучшить», «разобраться», «сделать нормально», значит интервью не закончено.

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

Третий вопрос: понятно ли, что нельзя делать? В хорошем запросе ограничения видны сразу. Например: не публиковать без audit, не менять старые файлы, не использовать fallback-изображения, не отправлять соцсети напрямую.

Четвёртый вопрос: понятно ли, как принять результат? Если Codex должен вернуть статью, нужен draft и проверки. Если должен поправить интерфейс, нужен скриншот или тест. Если должен сделать архитектуру, нужен документ и список решений.

Если эти четыре ответа есть, задача уже стала рабочей.

Где остаётся человеческое решение

Интервью не снимает с человека ответственность. Наоборот, оно делает её видимой.

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

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

То же самое с ограничениями. Если пользователь говорит «публикуем всё», Codex всё равно должен спросить: какие gates нельзя обходить? Где нужна остановка? Что считается готовым?

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

Шаблон запроса

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

У меня есть сырая идея:
[опишите мысль как есть]

Сначала ничего не выполняй.
Проведи короткое интервью и помоги превратить идею в рабочую задачу.

Задай мне до 7 вопросов:
- о цели;
- об аудитории или пользователе;
- о материалах и контексте;
- об ограничениях;
- о критерии готовности;
- о том, что точно не надо делать.

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

Не переходи к выполнению, пока я не скажу: делаем.

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