Иногда, когда работаешь с ИИ над проектом кажется что он начинает понимать тебя с полуслова, и начинаешь сокращать просьбы, говорить короче, давать меньше данных и он вроде отлично справляется. Потом переходишь в новый чат и продолжаешь по привычке делать так же и сразу ловишь ошибки. Причём ИИ уверенно сообщает что всё сделал так, как ты просил, но получилось совсем не то. В этой статье я попробую разобрать на примере своего опыта почему это случается. И что необходимо делать, для того чтобы повысить вероятность получения нужного результата.
Ложная определённость
Для себя я называю это ложной определённостью.
Формально ИИ действует в рамках указанных заданий, но на практике он либо не владеет достаточным контекстом, либо не обладает понятным конечным результатом. В итоге он уверенно делает то что сам себе придумал. Иногда команда простая и понятная но недостаточная рамка для действия и в результате мы получаем большое количество возможных вариантов. При работе с ИИ надо всегда помнить что это генеративные модели и они каждый раз генерируют по-разному. И мне лично хотелось бы уменьшить вероятность отклонения от намеченного плана.
Есть задачи, где короткая инструкция подходит, например:
Исправь опечатку в заголовке кнопки и проверь, что текст помещается в интерфейсе.
Здесь нам известно где что и как можно изменить и как это проверить. Для реализации таких примеров (часто это точечные правки) не нужен большой запрос. Достаточно кода и небольших и точных указаний.
На практике обычно всё немного по-другому. Мы видим проблему или желаемый результат, а что именно произошло не совсем ясно:
после обновления сломалась авторизация;
релиз нужно сделать безопаснее;
страница стала медленно открываться;
большой модуль пора привести в порядок;
команда хочет добавить проверку качества, а место этой проверки ещё только предстоит выбрать.
Если просто указать исправить или сделать, то ИИ уверенно возьмётся за работу. Ответ может быть грамотным и технически аккуратным. Польза при этом останется случайной.
Границы задания
Для неопределённых задач я начинаю с открытой рамки: сначала разбираю проблемное место, затем перехожу к первой правке.
В этом случае важно оградить модель от прямых указаний к действиям и побудить её к разбору ситуации и созданию нужного контекста для дальнейшей работы:
Страница каталога стала медленно открываться. Разбери, где искать причину: компонент, запрос к API, размер ответа, пагинация, изображения, кэш или состояние приложения. Сначала покажи варианты, риски и критерий готовности. К изменениям переходи после выбора подхода.
Такой запрос удерживает модель в рабочем коридоре. У него есть цель, границы и следующий шаг. Место правки пока остаётся вопросом, который надо решить перед изменениями.
После формирования границ мы уже можем переходить к более точной диагностике и формированию плана действий.
Здесь важна последовательность действий. Сначала я показываю симптом и нужный результат. Потом явно оставляю место поиска открытым: компонент, API, размер ответа, пагинация, изображения, кэш, состояние приложения. После этого прошу назвать риски и критерий выбора. Только в конце разрешаю переходить к изменениям.
В этом случае до редактирования кода мы создаём необходимый контекст, точную диагностику и коридор действий. Это все позволяет снизить вероятность неверных результатов и значительно повысить шансы на удачный исход
Когда нужен короткий запрос, а когда рамка
Я разделяю такие задачи по одному признаку: понятно ли место действия.
Если место понятно, длинный запрос только мешает. Опечатка в заголовке кнопки, неверный текст в интерфейсе, очевидная маленькая правка - всё это лучше отдавать короткой командой с простой проверкой результата.
Если известен только желаемый результат, то команда должна оставить путь открытым. Например, для безопасного обновления приложения я сначала прошу сравнить варианты: проверки перед релизом, rollback, changelog, инструкцию обновления и smoke-тесты. Здесь главную роль играют критерии выбора: польза, риск и минимальный объём.
Если ломается система связей, задача начинается с диагностики. После обновления может сломаться авторизация, и тогда надо смотреть API, frontend, cookies, домены и миграции. В таком режиме ИИ помогает быстрее разложить связи, но инженерная проверка всё равно остаётся обязательной.
Поле реальности ИИ
ИИ обожает вопросы. Я серьёзно - лучше решения ИИ даёт когда ты прикидываешься не знающим нубом и начинаешь спрашивать как это делается, что для этого нужно, какие шаги нужно предпринять, раскрой мою мысль и т.д. В этом случае ИИ формирует поле своей реальности в котором всё как она пожелает. И как показывает практика в этом поле она работает лучше всего.
Я для себя объясняю тем (это лично моё видение) что ИИ имеет определённый язык и порядок и когда весь материал создан ею, то это представляет для неё отражением её реальности. Но когда мы в эту реальность вставляем свои неадаптированные замечания то они как красные флаги втыкаются в эту реальность и создают турбулентность в работе ИИ.
Для того чтобы использовать эту особенность работы ИИ в своих целях я использую такой подход: я описываю своё мнение замечание и все данные которые необходимо дать ИИ для работы, а в конце прошу её или развить мою мысль или высказать своё мнение или сделать другие действия где она сможет переварить мою информацию и превратить её в своё видение.
В случае необходимости продолжения каких-либо действий я просто говорю что на её взгляд стоит делать дальше? И если всё ок соглашаюсь, а если есть замечания даю их и через вопросы также конвертирую эту информацию в карту мира ИИ модели.
Рельсы, рельсы, шпалы, шпалы…
Модель для своей работы использует историю вашей работы и материалы которые вы присылали. Это позволяет с одной стороны лучше вас понимать и что необходимо сделать с другой может служить препятствием в работе.
Если ИИ встал на нужные рельсы - всё идёт гладко, она вас понимает всё делает хорошо, вы нашли общий язык и совместная работа идёт отлично!
Но если вдруг вам в голову пришла какая-то мысль вне этого пути и вы написали её, то иногда всё ломается. ИИ как будто сходит с ума и начинает творить дичь.
Чтобы такого не происходило нужно представлять работу ИИ как путь из точки А в точку Б и стараться работать в этом пути - не подмешивать лишние данные или инструкции которые могут сбить её с этого пути и стараться поддерживать движение в нужном направлении.
Если же всё-таки модель сбилась с пути то почти везде теперь можно сделать форк - продолжить общение или работу с моделью с места где всё ещё было хорошо, отсекая дальнейшие неверные действия как с вашей стороны так и со стороны ИИ.
Горшочек не вари!
В последних моделях вложен механизм предсказания будущего шага. Это сильно помогает в большинстве случаев тем что модель предлагает следующий шаг и снимает с человека необходимость лишний раз напрягаться.
Но когда ИИ создаёт код или работает над проектом у которого чётко не прописан сценарий завершения (критерии готовности) то модель безудержно продолжает что-то придумывать без конца и края, постоянно предлагая что-то новое и (на её взгляд) полезное.
Тут важно засечь этот момент и постоянно двигать ИИ к завершению. Если мы знаем как всё должно завершиться то указываем критерии готовности. Если нет - задаём вопросы о том что ещё осталось для того чтобы получить результат. Несколько таких вопросов и её ответов и она поймёт когда пора остановиться и будет двигаться к определённой цели и завершению.
Рабочий цикл
Для задач с неопределённой рамкой у меня получается такой порядок:
открытая рамка -> анализ связей -> цель и критерий готовности -> план -> подтверждение -> выполнение -> проверка -> вопрос "готово ли?" -> закрытие или точечный следующий шаг
Открытая рамка нужна до реализации, когда место решения ещё ищется. Критерий готовности нужен после анализа, чтобы работа дошла до проверяемого конца.
Если оставить только открытые вопросы, задача расползётся. Если оставить только команды, можно быстро получить аккуратную правку слабого решения. Сильный результат обычно находится между этими режимами: сначала найти рамку, потом довести её до готового результата.
