Почему разработчики переходят от Prompt Engineering к Goal Engineering?

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

Почему разработчики переходят от Prompt Engineering к Goal Engineering?

Что делает /goal

Главная идея команды /goal очень проста. Вместо того чтобы объяснять модели, что нужно сделать прямо сейчас, вы описываете состояние, в котором задача считается завершенной. После этого Claude сам решает, какие действия необходимо выполнить, самостоятельно проверяет результат и продолжает работу до тех пор, пока цель не будет достигнута.

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

Почему Goal важнее самого промпта

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

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

Как агент понимает, что нужно продолжать

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

В режиме /goal работа выглядит иначе. После генерации первой версии агент начинает проверку. Он открывает ссылки, убеждается, что страницы существуют, сравнивает их содержание с текстом, удаляет неподходящие источники и ищет новые. Затем повторяет проверку еще раз. Если хотя бы одна ссылка не проходит проверку, цикл начинается заново. Пользователь получает не первую удачную попытку модели, а результат, который соответствует заранее заданным критериям.

Именно проверка делает Goal рабочим инструментом. Без нее агент просто генерировал бы новые версии текста, не понимая, стали ли они лучше.

Почему без проверки Loop не работает

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

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

Почему Claude хранит состояние

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

Именно поэтому в Claude Code используется файл LOOP-STATE.md. После каждой итерации агент сохраняет информацию о выполненной работе, найденных проблемах и задачах, требующих участия человека. При следующем запуске он сначала читает этот файл и только потом продолжает работу. Благодаря этому большие проекты можно выполнять постепенно, не начиная процесс заново после каждого запуска.

Когда Goal действительно нужен?

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

Именно поэтому разговор постепенно смещается с Prompt Engineering на Goal Engineering. Все меньше внимания уделяется идеальной формулировке запроса и все больше тому, как описать конечное состояние, критерии проверки и условия завершения работы. Именно эти три элемента сегодня определяют, насколько автономным сможет стать современный AI-агент.

2