Задача для Codex: как писать запрос, после которого можно принять работу
Многие начинают с Codex так же, как с обычным чатом: "сделай красиво", "посмотри проект", "почини ошибку", "напиши статью", "проверь сайт". Иногда это работает. Но часто результат получается таким, что его трудно принять: вроде что-то сделано, но непонятно, что именно, где проверка и можно ли отдавать дальше.
Проблема обычно не в том, что Codex не умеет работать. Проблема в том, что задача поставлена как разговор, а не как работа. В разговоре можно уточнять бесконечно. В работе нужен вход, ограничение, ожидаемый артефакт и критерий готовности.
Официальная документация Codex прямо ведет к этой привычке: Codex лучше работает, когда получает явный контекст и понятное определение "готово". В workflow-примерах OpenAI отдельно показывает, когда использовать задачу, какие шаги выполнить, какой контекст дать и как проверять результат. Для владельца проекта это главный навык: не просить Codex "помочь", а ставить ему проверяемую работу.
Плохой запрос похож на желание
Плохой запрос часто звучит естественно:
Проверь сайт и улучши его.
Для человека эта фраза понятна эмоционально. Для рабочего процесса она слишком широкая. Что значит "проверь"? Главную страницу, мобильную версию, форму, скорость, тексты, дизайн, SEO? Что значит "улучши"? Сделать красивее, быстрее, понятнее, безопаснее? Что нельзя трогать? Как понять, что задача выполнена?
Codex может начать действовать, но результат будет трудно оценить. Если агент поменял пять файлов, поправил стили и написал "готово", человеку все равно придется вручную разбирать, какая именно проблема решена.
Хорошая задача имеет четыре части
Минимальная рабочая постановка выглядит так:
| Часть | Что указать |
|---|---|
| Цель | что нужно изменить или понять |
| Контекст | где смотреть: файлы, URL, ошибка, экран, документ |
| Ограничения | что не менять, какие риски не трогать |
| Проверка | как Codex и человек поймут, что работа готова |
Это не бюрократия. Это способ сократить лишние круги. Codex не должен угадывать, где граница задачи. Он должен видеть ее с самого начала.
Пример: вместо просьбы — рабочая карточка
Плохо:
Почини форму заявки.
Лучше:
На странице /contacts кнопка "Отправить" показывает успех, но после обновления данные не сохраняются. Проверь обработчик формы и ближайший API-вызов. Не меняй дизайн и тексты. После исправления воспроизведи сценарий: открыть страницу, заполнить форму, нажать кнопку, обновить страницу, убедиться, что данные остались. В ответе укажи, какие файлы изменены и какой check прошел.Разница не в длине. Разница в структуре. Во втором варианте есть симптом, место, ограничение, способ проверки и ожидаемый отчет. Такую работу можно принять или вернуть.
Что Codex должен вернуть
Хороший результат Codex — это не просто измененный код или текст. Для приемки нужен маленький отчет:
- что было исходной проблемой;
- где Codex искал причину;
- что изменил;
- какие команды, сценарии или проверки запустил;
- что осталось на решении человека.
Если в ответе нет проверки, работа еще не закончена. Если Codex не может назвать измененные файлы или проверенный сценарий, значит задача была выполнена слишком мутно.
Как ставить задачу без технического языка
Не-программисту не нужно знать архитектуру проекта, чтобы поставить сильную задачу. Достаточно описать видимый симптом и критерий результата.
Например:
На мобильном экране карточки перекрывают кнопку. Проверь только этот экран. Нужно, чтобы карточки не перекрывали кнопку на ширине около 390px. Не меняй порядок карточек и тексты. После правки открой страницу в браузере и скажи, что именно изменилось.
Здесь нет названий компонентов и CSS-классов. Но есть рабочий вход: экран, симптом, ограничение, проверка. Codex может сам найти техническую причину, а человек может проверить результат глазами.
Когда задачу надо дробить
Если запрос содержит сразу "проверь сайт, исправь дизайн, улучши тексты, сделай SEO и опубликуй", это не одна задача. Это конвейер. Его нужно разделить:
- Найти видимые проблемы.
- Согласовать, что исправляем.
- Исправить один класс проблем.
- Проверить результат.
- Отдельно решать публикацию.
Так меньше риск, что Codex начнет менять все сразу. Для сложных работ лучше просить сначала план и границы, а не сразу выполнение.
Карточка задачи для Codex
Перед запуском можно заполнить короткую карточку:
| Поле | Вопрос |
|---|---|
| Что болит? | какой симптом или задача |
| Где смотреть? | файл, URL, экран, документ, ошибка |
| Что на выходе? | код, статья, отчет, чеклист, план, исправление |
| Что нельзя делать? | запреты и границы |
| Как проверить? | команда, сценарий, экран, human review |
| Что решает человек? | принять, вернуть, расширить задачу, остановить |
Эта карточка делает Codex управляемым. Она не гарантирует идеальный результат, но резко снижает число догадок.
Где остается человек
Codex может сам искать файлы, запускать проверки, править текст, открывать страницу и возвращать отчет. Но человек задает критерий ценности. Агент не должен сам решать, что "стало достаточно хорошо", если это связано с продуктом, риском, стилем, публичной публикацией или деньгами.
Хорошая задача для Codex — это не длинный промпт. Это договор о работе: вот вход, вот артефакт, вот граница, вот проверка. Когда этот договор есть, Codex перестает быть собеседником на удачу и становится исполнителем, чью работу можно принять.
