Контекст Codex: как не перегрузить поток и не потерять главное

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

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

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

Почему длинный поток начинает терять смысл

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

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

В обычном чате это воспринимается как усталость переписки. В рабочем Codex-потоке это уже риск управления. Длинный поток должен иметь не только историю, но и короткую рабочую память.

Что документация говорит о контексте

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

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

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

Не надо бороться с context window. Надо помочь Codex отличить рабочую память задачи от шума.

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

Хороший вход для длинной задачи состоит не из большой простыни, а из пяти ясных блоков.

Первый блок — цель. Одно предложение: что должно измениться в результате работы. Не «разберись с проектом», а «подготовь статью к публикации через Silver, V4 visual, Ghost и hosted ArticleFactory».

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

Третий блок — границы. Что нельзя делать: не публиковать без аудита, не отправлять Telegram напрямую, не менять старые пакеты, не использовать декоративный визуал, не обходить Silver.

Четвёртый блок — артефакт. Codex должен вернуть не просто «готово», а проверяемую вещь: draft, audit, patch, table, status report, context card, visual manifest.

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

Как выглядит контекстная карточка

Контекстная карточка — это не документация проекта. Это маленькая рабочая рамка для конкретной задачи.

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

Карточка не должна разрастаться в новую переписку. Её сила в короткости. Если в ней двадцать пунктов, она уже перестаёт быть рабочей памятью.

Как проверить карточку без кода

Непрограммисту не нужно считать токены или понимать внутреннее устройство модели. Достаточно проверить четыре вещи.

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

Второе: карточка отвечает на вопрос «где мы работаем». Для Codex это особенно важно: файлы, папки, статьи, очереди, URL и артефакты должны быть названы явно.

Третье: карточка отвечает на вопрос «что нельзя». Запреты и gates нельзя прятать в длинной истории. Они должны быть видны как отдельный блок.

Четвёртое: карточка отвечает на вопрос «как принять результат». Если нет проверки, Codex может красиво объяснить работу, но владелец не поймёт, можно ли ей доверять.

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

Когда нужно остановиться и пересобрать контекст

Контекст стоит пересобирать не только в начале. Есть несколько моментов, когда это нужно делать специально.

Первый момент — после длинной паузы. Если вы возвращаетесь к задаче через день, не надо надеяться, что вся переписка сама станет понятной. Лучше попросить короткий recap и новую карточку.

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

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

Четвёртый момент — когда Codex начинает отвечать слишком общо. Общий ответ часто означает, что рабочий контекст стал мутным. В этот момент лучше остановить выполнение и попросить сначала восстановить карту задачи.

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

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

Сначала не выполняй задачу.
Собери контекстную карточку для Codex.

Цель задачи:
[что должно быть готово]

Важный контекст:
[файлы, ссылки, решения, ошибки, документы]

Границы:
[что нельзя менять, публиковать, удалять или обходить]

Ожидаемый артефакт:
[что должно появиться в конце]

Проверка:
[как я пойму, что работа готова]

После этого:
1. отдели главный контекст от второстепенного;
2. назови, чего тебе не хватает;
3. предложи первый безопасный шаг;
4. остановись и жди подтверждения.

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