Контекст для Codex: что приложить к задаче, чтобы агент не гадал

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

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

Официальная документация Codex постоянно возвращается к контексту: в workflow-примерах отдельно указывается, что пользователь дает Codex, что Codex видит сам и как потом проверять результат. Это не формальность. Контекст — это топливо задачи.

Контекст не равен "все подряд"

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

Хороший контекст отвечает на вопрос: что агенту нужно увидеть, чтобы выполнить именно эту работу?

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

Пять типов контекста

Тип Что дать Codex
Место файл, папка, URL, экран, строка, компонент
Симптом что не работает или что нужно получить
Источник документация, письмо, задача, таблица, макет
Ограничение что нельзя менять и где риск
Проверка команда, сценарий, визуальная приемка, human review

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

Пример контекстного пакета

Плохо:

Посмотри, почему страница странная.

Лучше:

Открой /pricing на ширине около 390px. Видимый симптом: кнопка в третьей карточке перекрывается текстом. Проверь только layout карточек тарифа. Не меняй цены, тексты и порядок блоков. После правки снова открой страницу и подтверди, что кнопка видна целиком.

В этой постановке нет сложной технической терминологии. Но Codex получает место, симптом, границу и проверку. Он может сам найти CSS или компонент, но не должен гадать, что считается успехом.

Контекст для текста и статей

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

Рабочая постановка:

Источник: официальная страница Codex Workflows. Читатель: владелец проекта без технического бэкграунда. Нужно не пересказать документацию, а объяснить навык: как ставить Codex задачу с проверкой результата. В статье должны быть вход, артефакт, проверка не-программистом и решение человека. Не использовать английский термин первым, если есть понятный русский.

Это уже не просьба "напиши красиво". Это контекстный пакет.

Что Codex должен вернуть после работы с контекстом

Если контекст дан правильно, Codex должен вернуть результат, привязанный к нему:

  • что он использовал как источник;
  • где нашел проблему или опору;
  • что изменил или написал;
  • как проверил результат;
  • что осталось на решении человека.

Если ответ не ссылается на исходный контекст, значит задача ушла в свободное сочинение.

Карточка контекста

Перед запуском задачи можно заполнить короткую карточку:

Поле Вопрос
Где работать? файл, URL, экран, документ, папка
Что видно или требуется? симптом, цель, желаемый результат
На что опираться? источник, документация, переписка, макет
Что нельзя трогать? границы, риск, запреты
Как проверить? сценарий, команда, визуальная проверка
Что решает человек? принять, вернуть, расширить, остановить

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

Минимальный контекст и достаточный контекст

Минимальный контекст отвечает только на вопрос "куда смотреть". Например: файл, URL или экран. Этого хватает для простой проверки, но редко хватает для качественной работы.

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

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

Так контекст становится не справкой для агента, а частью управления качеством. Codex получает не только материалы, но и рамку ответственности.

Где остается человек

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

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