Как организовать рабочий контекст для Codex

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

Чем больше файлов получает агент, тем важнее не объём, а навигация. Без неё сильная модель тратит внимание на восстановление структуры, смешивает старое с новым и уверенно продолжает не тот маршрут. Хороший контекст сокращает не количество вопросов вообще, а количество вопросов, на которые проект уже должен уметь отвечать сам.

Коротко

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

Контекст — это управляемый выбор

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

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

Поэтому контекст — не все доступные данные. Это набор выбранных источников и правил их интерпретации, достаточный для конкретной работы.

Сначала ограничьте рабочий объект

Плохая постановка звучит так: «Вот папка компании. Разберись и помогай со всем». Хорошая начинается с границы:

Проект: подготовка еженедельного маркетингового отчёта
Вход: выгрузки за установленный период
Результат: проверенный отчёт по согласованному шаблону
Не входит: изменение рекламных кампаний и финансовые обещания

Ограниченный объект легче проверить, повторить и улучшить. Если вы ещё не выбрали его, начните с материала о выборе первой функции для автоматизации.

Дайте проекту одну точку входа

У нового участника команды обычно есть вводная встреча. У агента должна быть вводная страница. Это может быть README.md или другой короткий файл, который отвечает на основные вопросы:

что это за проект;
какую ценность он создаёт;
кто владеет решением;
как выглядит результат;
где находятся канонические источники;
что происходит сейчас;
какие действия запрещены;
что проверить перед завершением.

Точка входа не должна пересказывать каждый документ. Её задача — дать карту и порядок чтения. Подробные постоянные правила можно вынести в AGENTS.md, а повторяемые процедуры — в Skills. Различие между ними разобрано в статье про AGENTS.md, Skills и память проекта.

Разделите пять классов информации

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

1. Цель и границы

Здесь хранится ответ на вопрос, ради чего существует проект и чего он не делает. Этот слой меняется редко и защищает от расширения задачи по инерции.

2. Источники правды

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

3. Текущая ситуация

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

4. Рабочие материалы

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

5. Результаты и решения

Готовые артефакты, принятые решения, проверки и история изменений. Именно здесь виден наблюдаемый результат работы, а не только активность.

Соберите реестр источников

Даже небольшая таблица резко повышает управляемость:

Источник	Для чего используется	Актуальность	Статус	Ограничение
Интервью с владельцем	цели и ограничения	28.08.2026	подтверждено	внутреннее
Выгрузка канала	расчёт показателей	25–27.08.2026	подтверждено	не публиковать
Старая презентация	история формулировок	2025	справочно	не источник текущей цены

Такой реестр помогает Codex отвечать не только «что я прочитал», но и «почему этому можно доверять». Он также показывает недостающие данные до того, как агент заполнит пробел правдоподобной догадкой.

Зафиксируйте правила работы

Контекст сообщает, что известно. Инструкция сообщает, как действовать. В проектных правилах стоит закрепить только устойчивые договорённости:

порядок приоритетов;
владельцев разных типов решений;
разрешённые и запрещённые действия;
требования к источникам;
обязательные проверки;
формат изменения файлов;
правила работы с конфиденциальными данными;
команды или процедуры верификации.

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

Отделите память от текущего состояния

Память отвечает на вопрос: «Что из прошлого должно влиять на будущую работу?» Состояние отвечает: «Где находится работа сейчас?»

В памяти уместны:

устойчивые решения;
проверенные способы;
повторяющиеся ошибки;
принятые определения;
важные ограничения;
происхождение метода.

В состоянии уместны:

текущая цель;
последний подтверждённый результат;
активный фронт;
блокеры;
ожидания от других людей;
следующий шаг.

Если складывать туда стенограммы целиком, память превращается в склад. Если не обновлять состояние, проект продолжает жить в прошлой реальности.

Настройте минимальное чтение

Хороший проект не требует читать весь архив перед каждой задачей. В точке входа можно задать маршрут:

1. Прочитать цель и текущую ситуацию.
2. Открыть только источник, соответствующий задаче.
3. Проверить правила нужной папки.
4. Не читать архив без отдельной причины.

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

Добавьте критерий готовности

Контекст не завершён, пока агент не знает, как выглядит достаточный результат. Для задачи стоит определить:

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

Например, статья считается готовой к вёрстке не потому, что текст написан, а когда заполнены метаданные, существует один H1, проверены ссылки, нет заглушек и видим статус проверки. Это превращает субъективное «вроде готово» в рабочий контракт.

Проверьте контекст контрольным запуском

Не оценивайте структуру только по красоте папок. Дайте Codex ограниченное поручение и после выполнения спросите:

Какие источники были использованы?
Что было признано канонической правдой?
Какие противоречия обнаружены?
Что осталось неизвестным?
Какие файлы изменены?
Чем подтверждается готовность результата?

Если ответы невозможно восстановить, контекст пока неуправляем. Исправлять нужно не финальную формулировку, а навигацию, статус источников или критерии.

Не стройте идеальную систему заранее

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

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

Следующий шаг

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

Автор: Александр Шаров, основатель x10sion и автор практикума «Цифровая зрелость».