Кастомизация Codex: как научить его правилам проекта, а не объяснять заново

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

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

Официальная документация OpenAI называет это customization: способ заставить Codex работать так, как работает ваша команда. Внутри этого слоя есть AGENTS.md, memories, skills, MCP и subagents. Для читателя важна не терминология сама по себе, а практический вопрос: куда записать повторяющееся знание, чтобы не объяснять его заново каждый раз.

Не всякая инструкция должна жить в одном месте

Главная ошибка — складывать все в один большой промпт. Туда попадает стиль общения, правила проекта, ссылки на сервисы, чеклисты проверки, требования к публикации, запреты, примеры хороших результатов и просьба "будь внимателен". Такой промпт быстро становится тяжелым и перестает быть управляемым.

Лучше думать не "как написать идеальную инструкцию", а "в какой слой положить это правило".

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

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

Что класть в AGENTS.md

AGENTS.md — это не дневник проекта и не вся база знаний. Это короткая инструкция, которая помогает Codex не делать повторяющиеся ошибки в конкретном рабочем пространстве.

Туда хорошо класть:

Плохой AGENTS.md пытается объяснить всю компанию. Хороший AGENTS.md снимает повторяющееся трение: где команды, какие границы, что обязательно проверить перед ответом.

Что превращать в skill

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

В отличие от обычной инструкции, skill может хранить не только текст. В нем могут быть references, scripts, assets, шаблоны и локальные проверки. Это делает навык похожим на маленькую рабочую процедуру, которую Codex подхватывает тогда, когда задача совпадает с описанием.

Если вы уже третий раз объясняете Codex один и тот же процесс, это кандидат в skill. Не потому что "так архитектурнее", а потому что иначе вы вручную изображаете систему обучения.

Когда нужен MCP

MCP нужен не для красивого слова "интеграция". Он нужен, когда Codex должен работать не только с локальными файлами, а с живой внешней системой: GitHub, Linear, Figma, базой знаний, документами, внутренним API, трекером задач.

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

Практический вопрос звучит так: нужен ли Codex внешний контекст или внешнее действие? Если да, думайте про MCP. Если нет, не усложняйте.

Когда нужен subagent

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

Хороший subagent имеет узкую зону: "проверь только Silver-блокеры", "собери визуальный концепт", "найди повторяющуюся ошибку в последних публикациях". Плохой subagent называется "архитектор всего" и начинает одновременно писать, публиковать, спорить, рисовать и принимать решения.

Для бизнеса здесь простая выгода: можно отделить производство от проверки. Автор пишет. Редактор проверяет. Визуальный агент делает изображение. Публикационный контур не подменяет автора.

Карточка настройки Codex

Перед тем как "дообучать" Codex, заполните короткую карточку:

Эта карточка защищает от главного соблазна: превращать каждый сбой в еще один длинный промпт.

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

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

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

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