Не просите модель умнее: как собрать для Codex рабочий контур до замены инструмента

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

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

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

Что такое рабочий контур

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

Минимальный контур состоит из шести элементов:

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

Как это выглядит в Codex

В Codex рабочий контур можно собрать простыми файлами и правилами. Не обязательно начинать с тяжелой автоматизации. Достаточно завести карточку задачи, папку исходников, ожидаемый формат результата и review gate.

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

Подготовь черновик статьи для владельца проекта, не для программиста. Используй только перечисленные источники. В draft.md пиши только текст для читателя. SEO вынеси отдельно. Если не хватает визуала, не публикуй, а поставь статус blockedforvisual_media. В конце укажи, какие проверки пройдены и что осталось человеку.

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

Как понять, что проблема не в модели

Перед заменой модели задайте пять вопросов.

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

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

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

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

Пятый: был ли стоп-сигнал? Хороший агент должен не только продолжать, но и уметь остановиться: нет источника, нет права публиковать, нет визуала, конфликт требований, риск для данных.

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

Рабочая карточка для владельца проекта

Не-программисту удобнее думать не промптами, а карточками. Карточка говорит Codex не "будь умным", а "вот как устроена работа".

Эта карточка может быть в Markdown, YAML, Google Doc или просто в начале задачи. Важно не место хранения, а повторяемость. Если каждый запуск Codex получает разную кашу из намерений, стабильного качества не будет.

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

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

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

Вывод

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

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