Как заставить 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 повторить: каковы, по его мнению, цель, объем и условия завершения;

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

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

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

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

•

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

•

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

•

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

•

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

•

Устранение инцидентов: UNKNOWN — сверка + карта анализа взаимодействия человека и машины;

•

Выпуск и сдача: список сдачи + форма утверждения «человек ».

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

Рекомендуемый подход

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

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

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

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

Когда «создать ещё 64 страницы» кажется вполне разумным

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

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

Если бы задача звучала как «продолжить расширение SEO-страниц», Codex вполне способен был бы выполнить её на высоком уровне.

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

«Количество новых страниц» измерить легко, а вот для оценки «роста эффективного поискового инвентаря» приходится ждать внешних данных. В результате первое незаметно заменяет второе, становясь прокси-показателем проекта.

В этот момент чем эффективнее работал Codex, тем больше было растрачиваемых ресурсов.

Впоследствии задача изменилась с «продолжать генерировать» на «сначала прочитать реальное состояние индекса, определить, какие страницы следует сохранить, объединить, перенаправить, запретить к индексации или удалить». Из 202 URL-адресов, находившихся в старом онлайн-режиме, в итоге осталось 34 индексированных URL-адреса, а затем их число увеличилось до 37 только благодаря появлению трёх реальных рабочих процессов, имеющих самостоятельную ценность.

Этот поворот стал не просто корректировкой SEO-стратегии, а исправлением самого определения задачи: от «производить больше контента» к «улучшать реальные результаты, которые видят пользователи и поисковые системы».

Неясность не означает краткость

Многие считают, что краткая инструкция — это неясность, а длинная — ясность. На самом деле это не так.

Следующее предложение очень короткое, но при этом достаточно чёткое:

Исправить проблему, при которой приложение иногда не запускается при запуске из панели задач. Ориентироваться на запуск из реальной установленной версии; задача считается выполненной, если удалось 10 раз подряд запустить и закрыть приложение без остаточных процессов.

В нём указаны проблема, объект, сценарий и условия завершения.

Следующее предложение довольно длинное, но при этом остаётся неясным:

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

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

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

Codex ищет реализуемые альтернативные цели

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

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

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

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

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

В шести примерах неоднократно встречались подобные заменители:

Результат, который действительно волнует людей

Простые для оптимизации прокси-показатели

Игроки быстро понимают и получают удовольствие от процесса рассуждений

Панели, шаги, узлы доказательств и внутренние оценки

Инструментарий для получения эффективного поискового трафика

Количество страниц, ключевых слов и слов в контенте

Программное обеспечение действительно работоспособно и готово к поставке

Количество успешных компиляций, прохождений единичных тестов и отправленных версий

Плагины могут быть реально установлены и использованы пользователями

«Smoke Test» в репозитории разработки

Поведение платформы соответствует условиям бизнес-соглашения

Все показатели доступа — «зеленые»

Правильные товары находятся в правильном бизнес-статусе

Успешное нажатие или появление уведомления об успешном выполнении

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

Четыре наиболее распространённых вида неясности целей

Неизвестно, для кого вносятся изменения

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

Целевой пользователь — это не просто маркетинговый портрет, а реальные пользователи и сценарии, определяющие решение.

Неизвестно, какое состояние нужно изменить

«Сделать плагин» не описывает ни отправную точку, ни конечный результат. Речь идет о том, запустится ли исходный код или удастся ли установить установочный пакет? Сможет ли новая задача вызывать нативные инструменты, или реальный пользователь на втором компьютере захочет воспользоваться им снова?

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

Неизвестно, что важнее чего

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

Ограничения — это не список пожеланий. Настоящие ограничения должны позволять отсеивать варианты.

Непонятно, когда остановиться

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

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

Сначала опишите результат, а потом — функциональность

Перед тем как приступить к работе, попробуйте сформулировать следующее предложение:

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

Возьмём в качестве примера сайт с инструментами:

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

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

Рассмотрим пример с программным обеспечением:

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

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

Пусть Codex сначала продемонстрирует своё понимание

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

какой результат, по его мнению, действительно нужен пользователю;

какие прокси-показатели он будет использовать;

какие неопределённости могут привести к изменению решения;

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

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

Пока не приступайте к реализации. Переформулируйте мои требования в виде «изменения состояния пользователя», не заменяя конечный результат количеством страниц, функций, объемом кода или количеством тестов.

Пожалуйста, укажите: 1. Целевой пользователь, сценарий использования, текущее состояние, целевое состояние; 2. Показатели, которые вы планируете использовать для оценки прогресса; 3. какие из них являются лишь прокси-показателями и не могут самостоятельно служить доказательством успеха; 4. Не более 5 неизвестных факторов, которые могут существенно изменить проект; 5. Минимальный срез, позволяющий как можно раньше проверить правильность выбранного направления; 6. Четкие условия прекращения проекта.

Только после того, как я подтвержу повторение целей, приступайте к разработке плана реализации.

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

Ясно ли сформулирована цель: самопроверка с помощью шести вопросов

•

[ ] Я описал изменения в состоянии пользователя или бизнеса, а не просто перечислил функции;

•

[ ] Я описал целевых пользователей и конкретные сценарии использования;

•

[ ] Я могу указать хотя бы один прокси-показатель, который может ввести проект в заблуждение;

•

[ ] Я описал наиболее важные ограничения на случай конфликтов;

•

[ ] Я знаю, какой минимальный результат нужно реализовать в первую очередь, чтобы определить направление;

•

[ ] Я описал, когда следует приостановить работу, задать вопросы или отказаться от дальнейшего расширения.

Если вы не можете ответить на два из этих вопросов, не просите Codex «продолжать оптимизацию».

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

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

Основания и ограничения данной главы

•

Цифры и состояние инструментов, веб-сайтов и примеров взяты из реального проекта PixCloak, реализованного лично автором, а также из соответствующей документации (C02) и матрицы взаимодействия примеров; данные относятся только к соответствующему временному периоду и не отражают текущее состояние онлайн.

•

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

•

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

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