Виктор Кросс – Как заставить Codex работать правильно. Постановка задач, контроль и проверка результата (страница 1)

Виктор Кросс

Как заставить Codex работать правильно. Постановка задач, контроль и проверка результата

Введение

Когда я впервые собирал эти примеры, мне тоже было легко понять проблему как «какие «ловушки» встречались Codex при написании кода».

В игре не сбрасывается состояние, настольное ПО проходит компиляцию, но не запускается, «Smoke Test» плагина запускается в неправильном каталоге, веб-агент случайно нажимает кнопку, а сайт с инструментами генерирует слишком много страниц, не имеющих самостоятельной ценности. Если перечислить все эти проблемы по пунктам, получится практическое руководство по устранению неисправностей.

Но между ними есть одна, более важная общая черта.

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

В результате неверные цели могут привести к созданию большого количества правильного кода, локальные «зеленые огни» могут быть интерпретированы как общее завершение, а статус входа в систему — как бизнес-авторизация.

Поэтому эта книга не сосредоточена на «универсальных подсказках».

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

Другими словами, мы обсуждаем не то, как сказать ИИ что-то более умное, а то, как построить сотрудничество, способное работать в долгосрочной перспективе.

Что дают шесть проектов

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

PixCloak демонстрирует, как реальный поиск данных изменил задачу с «сделать ещё 64 страницы» на утилизацию старых запасов, что в итоге привело к сокращению на 168 индексных страниц.

ClipDock демонстрирует, как «более полная функциональность» превратилась во второй поисковый продукт, а также показывает разрыв в доказательствах, когда созданный «полностью зелёный» реальный EXE-файл не открывается.

Market Intelligence Core и Platform продемонстрировали, почему исходный код Smoke, кэш установки, нативный MCP, реальный Canary, Production и потребности пользователей представляют собой разные проблемы, а также показали, как независимая проверка опровергает полный «зеленый» статус общего доступа.

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

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

Ключевое суждение книги

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

На протяжении всей книги этот вывод воплощается в виде «Договора о задаче», состоящего из семи элементов:

целевой результат;

текущие факты и неизвестные;

контекст полномочий;

Объем и нецелевые задачи;

полномочия и риски;

Этапы выполнения и контрольные точки;

доказательства приемки и условия прекращения.

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

Человек по-прежнему незаменим

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

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

Ценность человека заключается не в том, чтобы построчно указывать Codex, как писать код, а в том, чтобы принимать решения на нужном уровне.

Если эта книга поможет читателю реже говорить «продолжаем оптимизацию» и чаще задавать вопросы «что в конечном итоге должен сделать пользователь, каковы текущие факты, какие доказательства могут это подтвердить», то она выполнила свою задачу.

Руководство по чтению: примените эту книгу в следующем задании

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

Если Codex часто отклоняется от темы

сначала прочтите главы 1, 5, 7, 8 и 10.

Вы поочерёдно рассмотрите целевые результаты, список функций, авторитетные данные, нецелевые задачи и полное задание. Не спешите искать более длинные подсказки — сначала проверьте, не оптимизирует ли Codex какой-то промежуточный показатель, который вам на самом деле не нужен.

Если задания всегда приходится переделывать на полпути

Сначала прочтите главы 2, 11, 12, 14 и 15.

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

Если система всегда сообщает о завершении, но вы не уверены

Сначала прочтите главы 13, 16, 17, 18, 19 и 20.

Вы создадите иерархию доказательств, разграничите статусы PASS, FAIL, PENDING, BLOCKED и UNKNOWN, а также разделите исходный код, установку, выполнение, платформу и бизнес-состояние.

Если Codex будет работать с реальным сайтом или учетной записью

сначала прочтите главы 3, 9, 16, 20, 21 и 26.

Перед началом работы создайте матрицу прав доступа, точные объекты, сравнения «до/после», бизнес-послесловия и пакеты для ручного утверждения. Статус входа в систему не означает авторизацию, всплывающее окно об успешном выполнении не является конечным состоянием; не следует слепо повторять попытки, если побочные эффекты неопределенны.

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

сначала прочтите главы 4, 7, 10, 22 и приложение.

Размещайте разовые требования в подсказках и соглашениях о задачах, долгосрочные правила репозитория — в файле AGENTS.md, правила, поддающиеся автоматическому выполнению, преобразуйте в тесты или средства контроля доступа, а повторяющиеся задачи — в навыки (Skill) или стабильные рабочие процессы.

В каждой задаче выполняйте только три действия

Если у вас пока нет времени применять все методы, по крайней мере придерживайтесь следующих трёх шагов:

Перед началом работы попросите Codex повторить: каковы, по его мнению, цель, объем и условия завершения;

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

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

Как использовать приложения

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

•

локальное исправление: контракт на легкие задачи + многоуровневый отчет о выполнении;

•

Новая функциональность: карта результатов пользователя + минимальная карта по вертикали;

•

Долгосрочный проект: полный контракт на задачу + карта авторитетных данных + промежуточная проверка;

•

Внешние операции: матрица полномочий + карта утверждения действий + тройная проверка;