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

Неправильный ответ, получивший «12 баллов из 12»

Первым испытанием в проекте была задача с трёхзначным паролем.

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

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

Однако, увидев реальные кадры, руководитель проекта пришёл к совершенно противоположному выводу: это не та игра, которую он хотел создать.

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

Самое примечательное не в том, что эта версия провалилась, а в том, что она когда-то прошла с максимальным баллом.

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

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

«Сделать правильно» на самом деле имеет три уровня

Многие воспринимают вопрос «Сделал ли Codex всё правильно?» как единый вопрос. На самом деле он включает в себя как минимум три уровня.

Первый уровень — правильность реализации: работает ли код? Пройдены ли тесты? Есть ли явные ошибки?

Второй уровень — правильность выполнения задачи: соответствует ли результат требованиям данной задачи? Было ли действительно удалено то, что требовалось удалить? Охвачены ли все указанные страницы, платформы и границы?

Третий уровень — правильность с точки зрения ценности: стоит ли выполнять эту задачу? Даже если все требования выполнены, действительно ли результат решает проблему пользователя?

Взаимосвязь между этими тремя уровнями можно сформулировать следующим образом:

Правильность реализации не означает правильность задачи; правильность задачи не означает правильность ценности.

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

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

Почему Codex так серьёзно ошибается

Просто свести проблему к тому, что «ИИ не разбирается в продукте», не приносит особой пользы. Более конструктивный вопрос заключается в том: чего же не хватило в этом сотрудничестве между людьми и Codex?

1. Люди задавали функциональные цели, но не задавали цели, связанные с игровым опытом

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

Если же настоящая цель заключается в том, чтобы:

•

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

•

процесс рассуждений происходит в основном в голове;

•

экран служит лишь для предоставления подсказок и получения окончательного ответа;

•

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

то «добавление контрольных точек» скорее всего с самого начала не должно было входить в план.

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

2. Локальные документы стали высшим авторитетом в вопросах ошибок

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

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

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

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

если эти данные противоречат друг другу, чье слово будет решающим?

3. Критерии приемки измеряют то, что можно измерить, но не измеряют то, что важно

Отображается ли кандидат, завершена ли аналитика, появляется ли звезда — всё это легко проверить автоматически. А вот «сможет ли игрок быстро понять», «есть ли на экране чёткий фокус» и «не прерывается ли процесс рассуждений интерфейсом» — автоматизировать гораздо сложнее.

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

12/12 PASS подтверждает, что двенадцать пунктов из старого набора доказательств верны, но не доказывает, что игровой опыт устроен правильно. Тестирование никогда не обладает интеллектом, превосходящим интеллект того, кто его определил.

4. Люди слишком поздно видят реальные результаты

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

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

По-настоящему эффективное исправление отклонений — это не просто сказать: «Сделайте проще»

Столкнувшись с неверной версией, люди чаще всего дают такую обратную связь:

«Слишком сложно, сделайте проще. Сделайте интерфейс красивее, игровой процесс — интереснее».

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

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

Приведённое ниже описание задачи было реконструировано на основе проектной документации и журнала изменений; это не дословная цитата из разговора:

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

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

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

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

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

В-четвертых, сначала нужно изменить высший авторитет, а уже потом — код. В противном случае старые документы в следующем задании снова вернут Codex в исходное русло.

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

Если сопоставить задания до и после исправления отклонений, разница станет более очевидной:

Аспект

Задачи, которые легко сбивают проект с курса

Задачи после исправления

Цель

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

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

Методы

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

Расширение пространства возможных ответов, общее оценивание, неразглашение частичной информации в случае неудачи

Авторитет

Продолжать следовать старым правилам Harness и старым наборам доказательств

Сначала обновляются правила самого верхнего уровня; старые спецификации теряют силу в случае конфликта с ними

Область применения

Одновременно с доработкой первого уровня продолжать расширение

Приостановить расширение, завершить только продольное разделение первого этапа и соглашение о совместном использовании

Приемка

Полный набор функций, все старые пункты проверки отмечены зеленым

Уникальность математических вычислений, правильное взаимодействие, скриншот на одном экране прошел проверку и подтверждён человеком Направление развития

Условия остановки

Четких условий нет, после завершения игра продолжается автоматически

Не допускается копирование на остальные уровни до ручного подтверждения

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

От простого требования к договору о выполнении задания

В руководстве по использованию Codex от OpenAI рекомендуется в более важных заданиях указывать цели, контекст, ограничения и условия завершения; сложные или неоднозначные задачи можно сначала спланировать или позволить Codex с помощью вопросов конкретизировать расплывчатые идеи. Это отличная отправная точка. [1]

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

1. Целевой результат

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

Цель данного примера — не «переработать интерфейс первого уровня», а:

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

2. Текущие факты и неизвестные

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

Факты на момент включают: в старой версии было 12 вариантов и семь шагов анализа, внутренний набор доказательств показал результат 12/12 PASS, а фактический скриншот был отклонен руководителем проекта.

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

3. Авторитетный контекст

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

Текущие PRODUCT_RULES имеют приоритет над старыми Harness; текущий код и результаты выполнения имеют приоритет над устаревшими скриншотами; рыночные рекомендации не должны перекрывать подтвержденные принципы продукта.

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

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

Описание области применения указывает, что необходимо изменить в данном случае; описание нецелей указывает, какие заманчивые сопутствующие задачи не следует выполнять «заодно».

На данный момент мы переделываем только первый уровень и его общие условия; не будем одновременно добавлять рейтинги, доску заданий, социальную систему или дополнительные уровни. Если не указать «нецели», чем способнее Codex, тем больше вероятность появления лишней работы.

5. Полномочия и риски

Какие операции можно выполнять автоматически, а какие должны подтверждаться человеком?

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

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

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

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

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

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

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

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

Когда исправлять, а когда начинать с нуля

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

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

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

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

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

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

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

Что должно подтверждать автоматическое тестирование, а что — нет

Первый уровень после переработки имеет более строгие автоматические проверки: система перебирает 720 комбинаций из трёх разных цифр и проверяет, что текущая подсказка содержит только один объявленный ответ; при ошибочной отправке возвращается только общий статус «неудача», без указания, какая цифра верна; при перезапуске ввод очищается; страница спроектирована как единый экран размером 720×1280; при выполнении обёртка не только проверяет код завершения, но и сканирует ошибки выполнения и метку «PASS».

Эти доказательства чрезвычайно важны. Без них «лаконичность» могла бы просто скрыть ошибки ещё глубже.

Однако они по-прежнему не могут доказать:

•

сможет ли человек, впервые столкнувшийся с игрой, быстро понять правила;

•

станет ли механический сейф действительно центром визуального внимания;

•

возникает ли у игрока при разгадке ощущение «а, вот в чём дело»;

•

насколько естественны сенсорные управления на реальных устройствах WeChat;

•

готовы ли данные по проверке платформы, обратным звонкам по рекламе и соблюдению нормативных требований.

Хорошая приемка — это не просто пометка «PASS» во всех результатах, а допущение трёх вариантов честной оценки:

•

PASS

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

•

FAIL

: имеются доказательства несоответствия;

•

PENDING / UNKNOWN: когда до статуса нет достаточных доказательств, и требуется дополнительная проверка вручную, на реальном устройстве или с помощью внешних систем.

«Неизвестно» — это не провал. Провал — это когда «неизвестно» маскируется под «завершено».

Эта проблема характерна не только для игровых проектов

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

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

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

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

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

Правильное распределение обязанностей между человеком и Codex

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

Однако сильные стороны человека и Codex находятся в разных областях.

Codex преуспевает в следующем:

•

выявлять затронутые области в большом количестве файлов;

•

воплощение чётких правил в коде, тестах и документации;

•

выполнение повторяющихся, но требующих согласованности изменений;

•

генерировать поддающиеся проверке отчеты о различиях и доказательствах проверки;

•

отслеживание технических последствий после обнаружения конфликтов.

Человек должен отвечать за:

•

определение проблем, которые действительно стоит решать;

•

определять, когда промежуточные показатели заменяют реальные цели;

•

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

•

отказывать в признании задачи «выполненной» при недостаточности доказательств;

•

принимать решение о продолжении, доработке или прекращении проекта.

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