Виктор Кросс – Как заставить Codex работать правильно. Постановка задач, контроль и проверка результата (страница 4)
1. Люди задавали функциональные цели, но не задавали цели, связанные с игровым опытом
«Увеличить количество этапов рассуждений», «предотвратить беспорядочные нажатия игроков», «сделать уровни более целостными» — всё это похоже на цели, но на самом деле они описывают средства, а не конечный опыт, который получает игрок.
Если же настоящая цель заключается в том, чтобы:
•
игрок в течение десяти секунд понимает, что ему нужно делать;
•
процесс рассуждений происходит в основном в голове;
•
экран служит лишь для предоставления подсказок и получения окончательного ответа;
•
сложность обусловлена самой задачей, а не операционной нагрузкой;
то «добавление контрольных точек» скорее всего с самого начала не должно было входить в план.
Codex может оптимизировать записанные цели, но не способен стабильно выявлять те цели, о которых не было сказано вслух. Фраза «Я хочу создать простую, но глубокую мини-игру», возникшая в голове человека, если она не разбита на наблюдаемые критерии пользовательского опыта, в процессе реализации легко заменяется такими прокси-показателями, как «функциональная полнота», «насыщенность страниц» и «строгость игрового процесса».
2. Локальные документы стали высшим авторитетом в вопросах ошибок
В проекте уже имеются старые спецификации уровней, Harness и пакет доказательств. Они сообщают Codex, что такое «полнота» и что такое «прохождение». Таким образом, у Codex есть все основания продолжать дополнять процессы выбора кандидатов, проверки и анализа.
Проблема заключается не в том, что Codex не учитывает контекст, а именно в том, что он слишком внимательно учитывает контекст не того уровня.
В одном репозитории могут одновременно присутствовать принципы продукта, старые требования, тесты, исторические решения, рыночные рекомендации и временные записи. Они не являются равнозначными по своей природе. Когда порядок авторитетности не прописан чётко, наиболее конкретные и легко реализуемые локальные файлы часто перевешивают расплывчатые намерения продукта.
Поэтому «передача всех данных в Codex» не равнозначна предоставлению эффективного контекста. Эффективный контекст также должен давать ответ на вопрос:
если эти данные противоречат друг другу, чье слово будет решающим?
3. Критерии приемки измеряют то, что можно измерить, но не измеряют то, что важно
Отображается ли кандидат, завершена ли аналитика, появляется ли звезда — всё это легко проверить автоматически. А вот «сможет ли игрок быстро понять», «есть ли на экране чёткий фокус» и «не прерывается ли процесс рассуждений интерфейсом» — автоматизировать гораздо сложнее.
В результате команда легко допускает естественную ошибку: принимает показатели, которые можно измерить автоматически, за действительно важные цели.
12/12 PASS подтверждает, что двенадцать пунктов из старого набора доказательств верны, но не доказывает, что игровой опыт устроен правильно. Тестирование никогда не обладает интеллектом, превосходящим интеллект того, кто его определил.
4. Люди слишком поздно видят реальные результаты
Если руководитель впервые просматривает скриншоты только после того, как уровень написан, документация заполнена и пакет доказательств одобрен, ошибки в направлении уже привели к накоплению затрат на доработку.
В сложных проектах не следует спрашивать только в конце: «Готово ли это?», а нужно как можно раньше задать вопрос: «Это то направление, в котором мы должны двигаться?». Играбельный первый экран часто лучше, чем десятистраничный план, выявляет отклонения в понимании.
По-настоящему эффективное исправление отклонений — это не просто сказать: «Сделайте проще»
Столкнувшись с неверной версией, люди чаще всего дают такую обратную связь:
«Слишком сложно, сделайте проще. Сделайте интерфейс красивее, игровой процесс — интереснее».
Такая обратная связь выражает недовольство, но не устанавливает новых критериев оценки. Следующим шагом Codex может стать просто удаление двух панелей, сокращение нескольких абзацев текста, смена цветовой гаммы — и в результате снова будет сдана «более лаконичная сложная версия».
Отзыв, который действительно меняет направление проекта, должен преобразовывать интуицию человека в выполнимое соглашение.
Приведённое ниже описание задачи было реконструировано на основе проектной документации и журнала изменений; это не дословная цитата из разговора:
Приостановить расширение уровня. Сначала переделать первый уровень и сделать его стандартом игрового опыта для последующих уровней. Со стороны игрока оставить только три необходимых подсказки, три поля для ввода кода, цифровую клавиатуру, подсказку, кнопку сброса и кнопку отправки. Рассуждения игрока происходят в его голове, а система проверяет только окончательный ответ. Защита от перебора не должна полагаться на увеличение количества шагов проверки. Со стороны системы необходимо доказать, что пространство допустимых ответов достаточно велико, что при наличии текущей подсказки существует только один правильный ответ, а ошибочная отправка не раскрывает информацию о частичном совпадении. Удалить полосу кандидатов, узлы доказательств, выбор обоснований, связь доказательств, задачи с принудительным переходом и штрафы в виде звезд. Задача должна выполняться на одном экране в вертикальной ориентации, без прокрутки. Сначала обновите правила продукта на самом высоком уровне, а затем измените данные, код, тесты и скриншоты первого уровня. Только после ручной проверки изображений первого уровня можно приступать к расширению остальных уровней.
Эта инструкция эффективна не потому, что она длиннее, а потому, что в ней выполнены пять ключевых действий.
Во-первых, она останавливает привычку допускать ошибки. Речь идет не о том, чтобы одновременно расширять старую версию и заниматься косметическими доработками, а о том, чтобы четко «приостановить дальнейшее расширение».
Во-вторых, преобразование оценок пользовательского опыта в структурные ограничения. «Простота» больше не является просто прилагательным, а определяет, какие элементы разрешено оставлять на экране, а какие — запрещено.
В-третьих, разделяем задачи игроков и проверку со стороны разработчиков. Доказательство уникальности по-прежнему важно, но его должны обеспечивать перечислители и тесты со стороны разработчиков, а не перекладывать на игроков.
В-четвертых, сначала нужно изменить высший авторитет, а уже потом — код. В противном случае старые документы в следующем задании снова вернут Codex в исходное русло.
В-пятых, установите условия продолжения работы. Не «после завершения изменений автоматически добавить тридцать уровней», а сначала предоставить минимальный срез, чтобы можно было подтвердить правильный вектор развития.
Если сопоставить задания до и после исправления отклонений, разница станет более очевидной:
Аспект
Задачи, которые легко сбивают проект с курса
Задачи после исправления
Цель
Усовершенствовать процесс рассуждений, чтобы игроки не нажимали наугад
Создать головоломку, которая позволит новичкам быстро приступить к мыслительному процессу и отправить только окончательный ответ
Методы
Добавление вариантов ответов, узлов доказательств, выбора обоснований и анализа
Расширение пространства возможных ответов, общее оценивание, неразглашение частичной информации в случае неудачи
Авторитет
Продолжать следовать старым правилам Harness и старым наборам доказательств
Сначала обновляются правила самого верхнего уровня; старые спецификации теряют силу в случае конфликта с ними
Область применения
Одновременно с доработкой первого уровня продолжать расширение
Приостановить расширение, завершить только продольное разделение первого этапа и соглашение о совместном использовании
Приемка
Полный набор функций, все старые пункты проверки отмечены зеленым
Уникальность математических вычислений, правильное взаимодействие, скриншот на одном экране прошел проверку и подтверждён человеком Направление развития
Условия остановки
Четких условий нет, после завершения игра продолжается автоматически
Не допускается копирование на остальные уровни до ручного подтверждения
Слева — не просто «плохая подсказка», справа — не какая-то волшебная формулировка. Настоящее изменение заключается в том, что человек начинает нести ответственность за цели, авторитет, границы и доказательства.
От простого требования к договору о выполнении задания
В руководстве по использованию Codex от OpenAI рекомендуется в более важных заданиях указывать цели, контекст, ограничения и условия завершения; сложные или неоднозначные задачи можно сначала спланировать или позволить Codex с помощью вопросов конкретизировать расплывчатые идеи. Это отличная отправная точка. [1]
Однако в реальных проектах обычно требуются ещё три дополнительных элемента: текущие факты и неизвестные переменные, полномочия и риски, а также условия прекращения. В совокупности они составляют «Семь элементов задания Codex», которые проходят красной нитью через всю книгу.