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