Цели в ChatGPT и Claude

Одна цель работала больше двух суток

Одна из задач, которые мы запускали в Isty, заняла чуть больше двух дней и потратила 287 224 439 токенов. Дела.

Здесь и дальше «мы» — это я, Никита Архипов, и команда Isty. В статье собраны мой личный опыт и опыт студии: собственные проекты, клиентские задачи и внутренние эксперименты с Codex и Claude.

За эти двое суток внутри задачи успели поработать 206 ИИ-исполнителей. Основной агент делил поручение на части, отдавал их дополнительным агентам, собирал результаты, проверял их и продолжал работу. В конце он сообщил: цель достигнута.

В Codex и Claude Code — рабочих инструментах ChatGPT и Claude — такой режим называется Goal, то есть «цель». Вы описываете конечный результат, агент выполняет много шагов и продолжает работу через несколько циклов. Одна цель может прожить двадцать минут, несколько часов или пару дней.

Мы запускали цели для аналитики, подготовки документов, исследований и разработки сервисов. Самая показательная история — istranscribe, небольшое Windows-приложение для записи встреч. Мы попросили Codex довести его до релизного состояния. Через 20 часов 24 минуты цель была выполнена: приложение появилось в том виде, в котором мы его задумали. За время работы основной агент создал ещё 79 дополнительных веток.

Выглядит это заманчиво: написал большое поручение, запустил и дождался готового результата. Дальше начинаются вопросы. Что значит «релизное состояние»? Как агент поймёт, что приложение готово? Какие части продукта можно менять? Сколько времени и попыток ему дать? Что он должен показать в конце?

Мы изучили актуальную документацию Codex и Claude Code, публичный опыт других пользователей и, главное, собственную практику. Только за последнюю неделю наши цели потратили больше 2 млрд токенов. Среди них были длинные запуски с принятым результатом и случаи, где агент написал complete, а мы результат не приняли.

Мы пробовали ставить цели по-разному и смотрели, какие формулировки приводят к нужному результату. Постепенно у нас появилась какая-то универсальная формула. Потом мы к ней присмотрелись, а это оказалась… SMART — многим известная аббревиатура для постановки целей, изначально придуманная для людей. Щас разберёмся, как она работает с ИИ-агентами.

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

Небольшая оговорка. Эта статья начинается после нажатия кнопки. Здесь мы разбираем, как поставить и контролировать большую задачу. Если вы ещё не запускали Goal, спросите у ChatGPT или Claude: «Как включить цель в моей версии приложения?» Интерфейс меняется, поэтому сам ассистент подскажет актуальный путь.

Маршрут по статье

Выберите что читать

Это мощный лонгрид: 12 разделов с кучей примеров и разборов. Необязательно прям всё изучать

Читать всёПройти статью целиком: от механики Goal до выбора модели и Ultra12 разделов · около 45 минут Пробежаться короткоПонять механику, связь со SMART и первый шаг3 раздела · около 8 минут Как правильно ставить цельСобрать формулировку и подготовить первый запуск2 раздела · около 10 минут Как добиться выполнения целиЗадать результат, проверку, ресурсы и границы работы6 разделов · около 15 минут Как экономить токеныВыбрать лимиты, модель и режим работы агентов2 раздела · около 10 минут

Выберите результат — здесь появится ваш маршрут.

Что вообще за цель такая

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

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

В Claude Code это происходит буквально: после рабочего захода подключается отдельный ИИ-проверяющий — evaluator. Он читает переписку и решает, выполнено условие или нужен ещё один заход. У проверяющего нет собственных рук: он сам не открывает файлы и не запускает тесты. Поэтому Claude приносит доказательства в переписку — перечисляет готовые пункты и показывает результаты последних проверок.

В Codex механика описана чуть иначе. Текст Goal становится одновременно первым поручением и критерием завершения. ChatGPT сверяет с ним собственный прогресс и выбирает следующий шаг. Для пользователя схема выглядит так же: промежуточного результата пока недостаточно — работа продолжается; критерии выполнены — появляется финальный ответ.

Пока Goal работает, ей можно писать

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

Здесь есть важная особенность: последнее сообщение пользователя становится новой точкой отсчёта для очередного круга. Сохранённая Goal продолжает действовать. Свежая реплика задаёт ближайшее действие. Даже короткое «продолжай» оказывается последним пользовательским запросом.

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

Вернёмся к istranscribe из начала статьи. Это небольшое приложение для Windows, которое живёт в системном трее и следит за признаками встречи. Когда приложение замечает созвон, оно спрашивает: «Записать?» После завершения встречи istranscribe сохраняет готовый аудиофайл в выбранную папку.

К моменту запуска Goal у нас были продуктовые спецификации, доска проекта и части приложения. Агенту предстояло собрать из них готовый релиз для Windows x64: установщик, интерфейс, определение встречи, запись звука, сохранение файла, обновление и удаление приложения. Он прочитал спецификации, пошёл по доске задач и после каждого этапа запускал проверки. Часть работы разошлась по дополнительным веткам, а основной агент собирал результаты обратно и снова сверялся с общей целью.

Главное свойство Goal — настойчивость. Формулировка живёт дольше одного ответа, проходит через несколько кругов приёмки и может разрастись на десятки подзадач. Поэтому слова «готово», «качественно» и «сделай всё» требуют расшифровки заранее. И здесь появляется SMART.

Причём здесь SMART

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

• Конкретность
  Specific · S
  Что именно должно получиться?

• Измеримость
  Measurable · M
  Как мы поймём и докажем, что результат готов?

• Достижимость
  Achievable · A
  Есть ли для этой работы материалы, доступы, инструменты и полномочия?

• Значимость
  Relevant · R
  Какую задачу человека или продукта решает результат?

• Ограниченность во времени
  Time-bound · T
  Сколько времени, попыток и ресурсов можно потратить и когда пора остановиться?

Если приложить эти вопросы к istranscribe, короткая фраза «доведи приложение до релиза» начинает раскрываться. Нужен релиз для Windows x64, который устанавливается на чистый компьютер. Приложение замечает встречу, спрашивает разрешение, записывает звук и сохраняет файл. Этот путь нужно пройти целиком и показать результаты проверок. Агент работает по готовым спецификациям и доске проекта. Пользователь в конце получает запись встречи. У работы есть предел и понятные причины остановиться.

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

Поэтому SMART для агента удобнее воспринимать как пять проверочных вопросов. Они помогают найти дыры в постановке до того, как агент размножит их на десятки задач и несколько часов работы. Дальше разберём каждую букву отдельно — на той же Goal istranscribe и на случаях из нашей практики.

Конкретность: что должно получиться

Specific · S

Конкретная цель отвечает на первый вопрос агента: «Что именно я должен принести в конце?» Фраза «подготовь к встрече» оставляет широкий выбор — от одной заметки до папки документов. «Доведи приложение до релиза» может означать рабочую сборку на компьютере разработчика, установщик для пользователей или публикацию в магазине.

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

В конкретности полезно зафиксировать три вещи:

1. Что должно появиться. Какой результат увидит человек: приложение, отчёт, набор документов, таблица, исследование.
2. Где проходят границы задачи. Какие части проекта можно менять и какие направления сейчас не входят в работу.
3. Что должно сохраниться. Какие функции, данные, стилистика и пользовательские сценарии продолжают работать после изменений.

В документации для агентов эти части часто называются outcome, scope и invariants. По-русски смысл укладывается в три простых вопроса: что получить, куда можно заходить и что нельзя потерять по дороге.

Когда мы забыли указать форму результата

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

У нас была расшифровка предыдущей встречи. Информации в ней не хватало: остальной контекст был разбросан по заметкам, отчётам и другим разговорам. Часть данных находилась в связанной таблице, до которой у агента не было доступа.

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

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

Через 8 минут 43 секунды агент собрал всё в одну большую справку и отметил Goal как выполненную. Все запрошенные темы действительно находились внутри. В нашей голове финал выглядел иначе: четыре самостоятельных документа, каждый со своей задачей чтения.

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

Пришлось запускать корректирующую Goal и прямо перечислять четыре самостоятельных документа:

1. Саммари прошлой встречи.
2. Текущая структура.
3. Возможная будущая структура.
4. Заметка для подготовки к разговору.

В исправленной формулировке появилось ещё одно условие: делать документы по очереди и в финале дать четыре отдельные ссылки. На второй заход ушло ещё 11 минут 23 секунды.

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

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

Перед запуском Goal конкретность можно проверить четырьмя вопросами:

1. Что должно появиться? Какие вопросы закроет результат, сколько будет файлов или других объектов и в каком формате.
2. Где брать контекст? Какие документы служат источниками и где лежит подробный контракт задачи.
3. Куда можно заходить? Какие части проекта агенту разрешено менять и где проходит граница работы.
4. Что нужно сохранить? Какие функции, данные, стиль и привычные сценарии должны пережить изменения.

Как закрыть S: пример istranscribe

Перед разработкой istranscribe мы собрали конкретность в трёх слоях.

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

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

Что должно сохраниться. Обновление приложения и его удаление не затрагивают пользовательские записи. Приложение остаётся лёгким, а запись начинается только после согласия пользователя.

Эти решения лежали в спецификациях проектаМы используем spec-driven подход: сначала фиксируем требования в отдельных документах, затем поручаем агенту реализацию. Когда-нибудь расскажем и о нём — попросите Никиту в Telegram.. Поэтому сама Goal могла звучать коротко: «Доведи istranscribe до релизного состояния. Сначала делаем Windows x64. Веди задачи на доске». Агент открывал указанные документы и видел ту же картинку готового продукта, что и мы.

Подробности можно хранить в самой Goal или в отдельном файле-контракте. Для S важно назвать этот источник и убедиться, что в нём описан один узнаваемый финал.

Так буква S даёт агенту узнаваемый образ финала. Следующая буква отвечает за приёмку: как доказать, что этот финал действительно достигнут.

Измеримость: как понять, что всё готово

Measurable · M

Однажды мы поставили Claude Code цель из трёх слов:

давай всё это фиксить

Перед этим Claude разобрал интерфейс и перечислил проблемы. Казалось, ссылка на предыдущий разговор вполне понятна: бери список и исправляй. Агент сделал часть работы и собрался заканчивать. Встроенный проверяющий прочитал переписку, нашёл оставшиеся пункты и вернул задачу в работу. Затем это случилось ещё раз.

В итоге Claude дошёл до результата. На активную работу ушло около 18 минут. Формулировка всё это время заставляла проверяющего восстанавливать список требований из большой предыдущей переписки и самостоятельно решать, что означает «фиксить».

Для нового запуска мы бы сначала сохранили пункты аудита в отдельный файл. Тогда измеримая версия Goal могла бы выглядеть так:

Сначала выведи в переписку нумерованный список всех пунктов из UI-AUDIT.md. Затем исправь каждый. Цель достигнута, когда приложение запускается, основные сценарии проходят, а в последнем сообщении повторён весь список и напротив каждого пункта приведён результат проверки после последнего изменения.

Файл служит контрактом для рабочего агента: Claude читает его и выполняет пункты. Встроенный проверяющий файл не открывает, поэтому короткий чек-лист сначала появляется в переписке, а в конце возвращается вместе с доказательствами.

У завершения есть три ступени

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

В предыдущем разделе агент собрал все темы подготовки к встрече в одном файле и закончил Goal. По содержанию работа проходила формальную проверку. Мы ожидали четыре документа и результат не приняли. Статус, проверка и приёмка описывают разные моменты.

Поэтому буква M отвечает сразу за три вещи:

1. Признаки готовности: какие наблюдаемые условия должны выполняться.
2. Способ проверки: как агент или отдельный проверяющий подтвердит каждое условие.
3. Подтверждения: какие результаты, ссылки, файлы или снимки экрана агент покажет в финальном сообщении. В документации это часто называют evidence.

Для разных задач подтверждения будут разными:

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

Представим, что приложение успешно прошло проверку. Затем агент внёс ещё одну правку и сразу написал complete. Предыдущий результат уже относится к другой версии приложения.

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

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

Как выглядят хорошие подтверждения

В одной из наших двухдневных Goal финальный отчёт содержал результаты полного чистого прогона по 15 источникам. Одиннадцать пользовательских случаев прошли без ошибок значений и процесса. Ещё четыре проверки подтвердили ожидаемые преобразования. Рабочий промпт и навык во время прогона оставались неизменными; исполнители работали независимо.

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

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

Как закрыть M: пример istranscribe

Для istranscribe одного требования «приложение готово» было бы мало. Мы могли проверить релиз через полный путь пользователя:

1. Установить приложение на чистую Windows x64.
2. Запустить его и дождаться обнаружения встречи.
3. Подтвердить запись и получить аудиофайл.
4. Открыть файл и убедиться, что в нём есть звук встречи.
5. Обновить приложение и проверить сохранность записей.
6. Удалить приложение и снова проверить папку с записями.

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

Перед запуском Goal букву M можно проверить четырьмя вопросами:

1. По каким наблюдаемым признакам результат готов?
2. Как проверить каждый признак?
3. Что агент покажет в финальном сообщении?
4. Выполнены ли проверки после последнего изменения?

Теперь у агента есть образ результата и способ доказать его готовность. Для работы ему ещё понадобятся материалы, доступы и подходящие инструменты — это уже буква A.

Достижимость: есть ли у агента всё необходимое

Achievable · A

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

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

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

1. Материалы. Файлы, переписка, расшифровки, спецификация и другие источники, из которых можно восстановить задачу.
2. Доступы. Права на папки, таблицы, сайты, аккаунты и сервисы, которые придётся открыть или изменить.
3. Инструменты и среда. Подходящая модель, программы для работы и устройство, на котором можно проверить результат.
4. Разрешённые действия. Понимание, какие файлы можно менять, можно ли устанавливать программы, создавать дополнительных агентов или публиковать результат.
5. Решения человека. Выборы, которые нельзя достоверно восстановить из контекста: платформа первого релиза, бюджет, приоритет аудитории или допустимый риск.

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

Одна деталь может закрывать несколько букв

В агентных задачах буквы SMART пересекаются. Спецификация помогает с S, когда описывает точный результат, и с A, когда даёт агенту нужный контекст. Доступ к чистой Windows относится к A; результат проверки на этой Windows становится частью M. Разрешённая область изменений задаёт границы в S и одновременно подтверждает полномочия агента в A.

Смысл букв меняется вместе с вопросом:

• S: что именно строим и где проходят границы;
• M: чем докажем готовность;
• A: есть ли всё необходимое, чтобы построить и проверить.

Такой повтор полезен. Один и тот же файл или доступ рассматривается с разных сторон, и дыра становится заметнее до запуска.

Короткая Goal может опираться на большой контекст

В нашей истории встречались задачи длиной всего в несколько слов:

реализовать FEAT-008

FEAT-008 — номер задачи внутри проекта. Эта формулировка работала благодаря подробной спецификации в репозитории. В ней уже лежали описание функции, границы изменений и способы проверки. Агенту оставалось открыть названный файл и выполнить зафиксированный контракт.

Короткая Goal требует точного указателя: название документа, задачи или версии. Фраза «сделай по спецификации» снова заставляет искать подходящий файл и решать, какая из версий актуальна.

Для длинной работы полезно указать:

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

Когда агенту нужно остановиться

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

В Goal можно сразу записать правило:

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

Так агент сохраняет готовую часть работы и задаёт конкретный вопрос. Пользователю не приходится разбирать длинный отчёт, чтобы понять, какую кнопку нажать или какой вариант выбрать.

Как закрыть A: пример istranscribe

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

Несколько важных решений пришлось принять нам. Первый релиз выпускаем для Windows x64. Транскрибацию пока откладываем, а возможность подключить её позже сохраняем в архитектуре. Приложение должно распознавать встречи в Zoom, Teams, браузерах и других программах. Для проверки нужны работающие вход и выход звука, несколько типов встреч и отдельная среда Windows.

После этих уточнений Goal «доведи сервис до релизного состояния» получила рабочую опору:

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

Перед длинной Goal букву A можно проверить пятью вопросами:

1. Какие материалы агент прочитает перед началом?
2. Есть ли у него доступ ко всем обязательным источникам и сервисам?
3. На чём он выполнит и проверит работу?
4. Какие действия ему разрешены?
5. Какой вопрос или зависимость требуют остановки и участия человека?

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

Значимость: какую задачу это решает

Relevant · R

К моменту запуска большой Goal istranscribe уже существовал. Приложение умело следить за аудио, запускать запись и обрабатывать файл. За время разработки интерфейс успел обрасти тремя крупными разделами, шестью вкладками настроек, десятками технических параметров и повторяющимися кнопками.

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

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

Пользовательский результат работает как компас

У длинной Goal полезно записать, что изменится в жизни человека после завершения. Для istranscribe это звучало так:

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

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

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

Техническая задача должна вести к действию человека

Связь удобно записывать одной строкой:

Мы делаем [результат], чтобы [конкретный человек] смог [действие или изменение].

Например:

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

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

R помогает выбрать, что делать сейчас

Во время длинной Goal агент постоянно находит новые проблемы и идеи. Каждую можно сверить с пользовательским результатом: без этой работы человек получит обещанный результат?

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

Так S описывает текущую версию, а R помогает расставить работу внутри неё по порядку.

Как закрыть R: пример istranscribe

Для Goal istranscribe значимость можно было зафиксировать тремя строками:

Задача пользователя: сохранить встречу, даже если он не включил запись вручную.
Главный путь: обнаружить встречу → спросить разрешение → записать → сохранить файл.
Приоритет: сначала всё, что делает этот путь надёжным и простым; остальные улучшения складывать в следующие версии.

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

Перед длинной Goal букву R можно проверить четырьмя вопросами:

1. Кто будет пользоваться результатом?
2. Что этот человек сможет сделать после завершения?
3. Какой путь или свойство сейчас важнее всего?
4. Какие найденные улучшения можно оставить следующей Goal?

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

Ограниченность во времени: сколько времени и попыток дать агенту

Time-bound · T

В классической SMART-цели буква T обычно задаёт дату. Агенту чаще полезнее ограничить объём работы: какие карточки закрыть, сколько объектов обработать, какими пачками двигаться и после скольких неудачных попыток сменить подход.

Время важно, когда результат нужен скоро

Временной предел пригодится для срочной задачи: через 15 минут начинается встреча или через полтора часа нужно показать промежуточный результат. Тогда агенту можно прямо задать таймбокс:

Работай 60 минут. Затем остановись и покажи лучший проверенный результат, что осталось и что делать следующим шагом.

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

Маленькие пачки повышают фокус и увеличивают расход

Мы часто просим агента обрабатывать по пять сделок, делать по пять слайдов или собирать по одному документу. В такой пачке он держит внимание на нескольких конкретных объектах и глубже разбирает каждый. Формулировка «обработай 100 сделок» подталкивает быстрее пройти весь массив и распределить внимание между сотней строк.

Лучше разделить ритм и условие завершения:

Обработай все 100 сделок. Работай по пять сделок за проход: отдельно изучай историю каждой, записывай решение и проверяй готовую пятёрку. Заверши Goal после обработки всех 100 сделок.

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

Поэтому в T нужны две величины:

• размер пачки — сколько объектов агент держит в фокусе за один проход;
• общий объём — сколько объектов, карточек или этапов закрывает вся Goal.

Как Goal расходует лимит

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

В одной из наших Goal успели поработать 206 ИИ-исполнителей. Их измеренный расход составил 287 224 439 токенов. В istranscribe основной агент создал 79 дополнительных веток; вместе с родительской Goal они использовали 848 349 464 токена.

Токены здесь показывают масштаб расхода лимита. Денежную стоимость по этим числам мы не рассчитываем: тарифы, кэширование и внутренний учёт продуктов устроены сложнее.

Почему цифра внутри Goal может быть намного меньше общего расхода?

Например, встроенный счётчик одной Goal показал 19 055 568 токенов. Когда мы отдельно попросили посчитать расход всех 206 исполнителей, общий результат вырос до 287 224 439 токенов. В istranscribe разница была ещё заметнее: родительская Goal показала 15 253 642 токена, а вместе с 79 дополнительными ветками получилось 848 349 464 токена.

Счётчик родительской Goal и реестр всех исполнителей описывают разные уровни работы. Поэтому рядом с числом токенов полезно подписывать, что именно посчитано.

и вся команда

Дополнительные агенты ускоряют работу и расширяют расход

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

Перед запуском полезно решить:

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

Ограничение «не больше пяти дополнительных веток одновременно» управляет параллельностью. Ограничение «не больше двадцати веток за всю Goal» задаёт общий масштаб делегирования. Для задач с Ultra или похожим режимом второй предел особенно важен.

Длинная Goal должна уметь заметить, что застряла

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

Для такого случая полезно задать правило смены подхода:

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

Лимит попыток не превращает незавершённую работу в готовую. В момент остановки агент возвращает безопасное состояние:

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

На тарифе за 20 долларов Goal почти не успевает раскрыться

На 13 июля 2026 года ChatGPT Plus стоит 20 долларов в месяц и описан как план для нескольких сфокусированных сессий Codex в неделю. ChatGPT Pro начинается со 100 долларов и даёт в 5 или 20 раз более высокие лимиты Codex. У Claude план Pro стоит 20 долларов, Max 5x — 100 долларов, Max 20x — 200 долларов. Использование обычного Claude и Claude Code расходует общий лимит подписки.

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

Функция начинает раскрываться на тарифах от 100 долларов — ChatGPT Pro или Claude Max 5x. Самый сок начинается на старших планах в 200 долларов: там хватает запаса на многочасовую работу, повторные проверки и дополнительные ветки. Даже такой тариф остаётся конечным, поэтому размер пачек и правила делегирования всё равно имеют значение.

Как закрыть T: пример istranscribe

У istranscribe был понятный предел объёма: доска проекта с карточками текущего релиза. Агент шёл по ней последовательно, закрывал и проверял карточки. Goal завершалась, когда на доске не оставалось незакрытой работы для Windows-релиза.

Эта граница оказалась полезнее таймера. Задача могла занять 20 часов активной работы, потому что условием служило готовое приложение. При этом в Goal не было ограничения на количество дополнительных веток, поэтому общий расход вырос до 848,3 млн токенов.

Для следующего запуска мы бы сохранили доску как предел работы и добавили правило делегирования:

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

Перед длинной Goal букву T можно проверить шестью вопросами:

1. Какой общий объём нужно завершить: объекты, карточки или этапы?
2. Какими пачками агент будет двигаться внутри этого объёма?
3. Нужен ли результат к конкретному времени и что вернуть по таймбоксу?
4. Сколько дополнительных агентов разрешено и что им делегировать?
5. После какого повторения нужно сменить подход?
6. Что агент покажет, если лимит тарифа или таймбокс закончатся раньше?

Пять букв SMART собраны. Дальше разберём случаи, где наши Goal получили статус завершённых, а результат всё равно пришлось переделывать.

Две завершённые Goal, которые мы не приняли

Самый неприятный момент наступает, когда агент долго работает, пишет complete, а вы открываете результат и понимаете: он решил соседнюю задачу. Все файлы на месте, отчёт выглядит убедительно, время и лимит уже потрачены. Теперь нужно объяснять ожидания заново.

У нас так бывало и в целом это рабочая ситуаия. Разберём два случая. В обоих мы прямо написали, что результат не подходит, и запустили корректирующую Goal. Они хорошо показывают цену поздней сверки: в одном случае расхождение обнаружилось через восемь минут, в другом — только после двух часов работы.

Два часа на общий список вместо ручного разбора

В одном клиентском проекте нужно было изучить сделки, прочитать комментарии менеджеров и дать индивидуальную рекомендацию по каждой. Агент обработал список, поставил complete и отчитался о завершении. Goal использовала 1 084 240 токенов и 2 часа 2 минуты активной работы.

После просмотра результата мы ответили:

ну нет, это никуда не годится. Мне нужно, чтобы ты обработал вручную каждую сделку с комментариями…

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

Корректирующая Goal уже задавала сам процесс:

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

Второй запуск использовал ещё 439 260 токенов и 27 минут 56 секунд.

Первая Goal провалилась сразу по трём буквам:

• S: глубина «индивидуального» разбора осталась в нашей голове;
• M: не было примера одной принятой строки и проверки каждой рекомендации;
• T: работа шла по всему списку сразу, ритм по десять сделок появился после обратной связи.

Цена ошибки — два часа работы и больше миллиона токенов до первой содержательной приёмки.

Все темы были на месте, а документов оказалось мало

Второй случай уже встречался в разделе про S. Для срочной встречи мы запросили саммари прошлого разговора, текущую структуру, возможную будущую схему и заметку для подготовки. Агент собрал все четыре темы в одну большую справку и завершил Goal за 8 минут 43 секунды.

Мы ожидали четыре самостоятельных файла. После прямой обратной связи пришлось перечислить их по одному и запустить новую Goal. Коррекция заняла ещё 11 минут 23 секунды.

Здесь подвели S и M: содержание было перечислено, а единица результата, количество файлов и способ финальной проверки остались неявными.

Сначала принять образец, затем запускать весь объём

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

• разобрать первые пять сделок;
• подготовить один документ из комплекта;
• оформить одну карточку исследования;
• собрать первые пять слайдов.

Пользователь проверяет глубину, форму и полезность примера. После принятия образец становится частью Goal для всего объёма:

Обработай оставшиеся 95 сделок по принятому образцу. Работай пачками по пять и после каждой пачки проверяй те же поля. Заверши Goal после обработки всех 100 сделок.

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

Перед дорогой повторяемой Goal полезно проверить:

1. Есть ли один пример результата, который пользователь уже принял?
2. Понятна ли глубина работы над каждым объектом?
3. Заданы ли количество, формат и обязательные поля?
4. На какой пачке пользователь впервые увидит реальный результат?
5. Сколько работы придётся переделать, если ожидания разойдутся?

Следующий шаг — собрать все пять букв SMART в один шаблон и заполнить его для istranscribe.

Три способа собрать Goal по SMART

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

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

1. Самостоятельно заполнить SMART

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

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

## S. Конкретность
_Specific_

- Что должно получиться:
- Что входит в текущую задачу:
- Что оставить за её границами:
- Что должно сохраниться после изменений:

## M. Измеримость
_Measurable_

- По каким признакам результат готов:
- Как проверить каждый признак:
- Что агент должен показать в финале:
- Какие проверки нужно повторить после последних изменений:

## A. Достижимость
_Achievable_

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

## R. Значимость
_Relevant_

- Кто будет пользоваться результатом:
- Что этот человек сможет сделать после завершения:
- Что сейчас важнее всего:
- Какие улучшения оставить следующей Goal:

## T. Ограниченность
_Time-bound_

- Какой общий объём нужно завершить:
- Какими пачками или этапами работать:
- Нужен ли результат к конкретному времени:
- Сколько дополнительных агентов можно использовать:
- Когда сменить подход и что показать при остановке:

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

## S. Конкретность
_Specific_

Доведи istranscribe до релизного состояния для Windows x64.

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

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

macOS, аккаунты, облачная синхронизация и встроенная транскрибация
остаются для следующих версий.

Обновление и удаление приложения сохраняют записи пользователя.
Запись начинается только после его согласия.

## M. Измеримость
_Measurable_

Релиз готов, когда на версии после последних изменений:

1. Приложение устанавливается и запускается на Windows x64.
2. Оно обнаруживает тестовую встречу и показывает запрос на запись.
3. После подтверждения создаётся аудиофайл со звуком встречи.
4. Файл открывается в обычном проигрывателе.
5. Обновление и удаление приложения сохраняют папку с записями.

В финале перечисли результат каждого шага и приложи созданные артефакты.

## A. Достижимость
_Achievable_

Сначала прочитай спецификации релиза и карточки доски проекта.
Используй существующий код, Windows-среду, доступные аудиоустройства
и программы для тестовых встреч.

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

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

## R. Значимость
_Relevant_

Пользователь должен получить запись встречи, даже если заранее
не вспомнил включить диктофон.

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

## T. Ограниченность
_Time-bound_

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

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

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

2. Поручить подготовку цели агенту

Для большой работы это хороший базовый сценарий. Сначала агент изучает материалы, раскладывает задачу по SMART и готовит среду для длинной работы. Человек проверяет его решения и разрешает запуск.

Средой может быть одна заметка с целью и планом. Для длинных Goal мы обычно заводим отдельную рабочую папку из пяти частей:

• Цель (GOAL.md) — результат, границы и условие завершения.
• План (PLAN.md) — крупные этапы и порядок работы.
• Доска (BOARD.md) — карточки в колонках «Запланировано», «В работе», «На проверке», «Готово» и «Заблокировано».
• Проверка (VERIFY.md) — как принимать отдельные карточки и всю Goal.
• Прогресс (PROGRESS.md) — последний проверенный результат, текущий шаг, блокеры и ближайшее действие.

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

Доска особенно полезна во время длинного запуска. Агент берёт одну карточку, выполняет её, проверяет результат и переносит дальше. На карточке записаны ожидаемый результат и способ проверки. После паузы или перезапуска доска показывает, где остановилась работа и что уже принято. А количество оставшихся карточек задаёт Goal понятное условие завершения.

Начать можно обычным запросом:

Подготовь эту задачу к запуску Goal. Изучи доступные материалы и собери контракт по SMART: ожидаемый результат, признаки готовности, доступные ресурсы, главный приоритет и границы работы. Создай рабочую папку с целью, планом, канбан-доской, способами проверки и текущим прогрессом. На каждой карточке доски укажи ожидаемый результат и способ проверки. Отдельно перечисли недостающие данные и решения, которые должен принять я. Покажи всё на проверку до начала реализации.

Человек смотрит, правильно ли агент понял задачу, дополняет пропуски и утверждает материалы. После этого запускается сама Goal:

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

Именно так готовился istranscribe. До длинного запуска агент изучил состояние приложения, уточнил список программ для встреч, выбрал Windows x64 для первого релиза, отложил встроенную транскрибацию и собрал работу на доске. Затем Goal получила понятный маршрут и конечное число карточек.

3. Запустить Goal одним предложением

Короткой формулировки достаточно, когда подробный контекст уже собран: закончено планирование, утверждена спецификация, заполнена доска или в документе перечислены критерии приёмки. SMART в этом случае хранится рядом с задачей, а сообщение указывает агенту, какой контракт выполнить.

Например:

Доведи istranscribe до релизного состояния для Windows x64 по утверждённым спецификациям и доске; заверши Goal после закрытия и проверки всех карточек текущего релиза.

Для небольшой задачи хватит ещё более компактной версии:

Подготовь четыре документа по утверждённому плану и заверши Goal, когда каждый пройдёт проверку из листа приёмки.

В Claude Code проверяющий не открывает файлы, поэтому короткая Goal должна сначала вынести чек-лист в переписку:

Сначала выведи в переписку краткий нумерованный чек-лист всех критериев из GOAL.md. Считать цель достигнутой, когда в последнем сообщении повторён весь чек-лист, а напротив каждого пункта приведены результаты актуальных проверок и ссылки на артефакты.

Получается простое правило выбора. Если вы хотите сами принять все важные решения — заполните SMART вручную. Если задача требует изучения материалов — сначала поручите агенту подготовку и проверьте её. Если утверждённый контракт уже существует — запускайте Goal одной строкой.

С формулировкой разобрались. Перед запуском остаётся выбрать модель и глубину рассуждения — от этого зависит, как агент пройдёт длинную дистанцию и сколько работы сможет отдать дополнительным исполнителям.

Какую модель и глубину выбрать для Goal

У длинной Goal есть три настройки. Модель определяет способности и расход. Глубина рассуждения задаёт, сколько усилий агент тратит на планирование и проверку каждого шага. Режим Ultra, доступный и в Codex, и в Claude, меняет ещё и организацию работы: основной агент активнее раздаёт части задачи дополнительным исполнителям.

Сначала определите характер работы

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

Глубина показывает, сколько усилий дать одному шагу

Для обычной Goal подходит средняя глубина. Агент читает план, выполняет несколько связанных действий и проверяет результат. Повышать её стоит по конкретной причине:

• Низкая или лёгкая (Low, Light) — короткие и однозначные действия.
• Средняя (Medium) — обычная многошаговая работа с готовым планом.
• Высокая и очень высокая (High, Extra High) — много связей, источников и решений с последствиями.
• Максимальная (Max) — одна особенно трудная задача, где глубина важнее скорости и расхода.
• Ультра (Ultra) — большая задача, которую агент может самостоятельно разделить на множество веток.

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

Дополнительных агентов можно вызывать в любом режиме

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

Например:

Создай трёх дополнительных агентов. Первому передай проверку исходных данных, второму — поиск пропущенных случаев, третьему — независимую проверку готового результата. Собери их выводы и сам прими финальное решение.

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

В Ultra команда появляется сама

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

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

Автоматическое делегирование можно ограничить прямо в Goal: разрешить только определённые виды работы, задать число одновременных исполнителей и общий предел созданных веток. Эти правила работают и в Codex, и в Claude.

Для istranscribe мы выбрали Sol + Ultra. Родительская Goal работала 20 часов 24 минуты и создала 79 дополнительных веток. В результате приложение дошло до задуманного релизного состояния. Общий измеренный расход вместе с ветками составил 848,3 млн токенов.

Поэтому перед Ultra стоит ответить на три вопроса:

1. Есть ли в задаче несколько частей, которые можно выполнять независимо?
2. Может ли основной агент проверить и собрать их в один результат?
3. Хватит ли лимита на работу всех дополнительных исполнителей?

Если ответы положительные, в Goal полезно сразу задать предел параллельности и общий предел веток. Такое ограничение подходит для Ultra в обоих продуктах: и у Antrhropic и у OpenAI. Для istranscribe следующая формулировка могла бы звучать так:

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

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

Как поставить цель ИИ-агенту: с чего начать

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

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

Сначала напишите, как выглядит готовность

Начните с буквы M — измеримости. Запишите, что должно появиться и какое подтверждение позволит принять результат.

Например:

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

После этого остальные буквы SMART заполняются легче:

• S уточняет содержание, форму и границы;
• A перечисляет материалы, доступы и разрешённые действия;
• R задаёт главный пользовательский результат;
• T определяет объём, размер пачек, делегирование и остановку.

Поручите агенту подготовить первый запуск

Для старта достаточно одного обычного сообщения:

Я хочу запустить Goal для следующей задачи: [опишите задачу]. Сначала подготовь её по SMART. Создай цель, план, канбан-доску, способы проверки и запись прогресса. Раздели работу на несколько проверяемых карточек. Покажи недостающие данные и решения, которые должен принять я. До моего подтверждения Goal не запускай.

Проверьте подготовку по четырём пунктам:

1. Понятно ли, что именно появится в конце?
2. Можно ли проверить результат без доверия к слову complete?
3. Есть ли у агента материалы и доступы для каждой карточки?
4. Видно ли на доске, где работа заканчивается?

Если ответы устраивают, запускайте:

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

Для первого раза подойдёт стандартная модель и обычная глубина: Sol с Medium в Codex или Sonnet с настройкой по умолчанию в Claude. После завершения станет видно, где именно не хватило мощности, контекста или проверки. Следующую Goal уже можно расширить, поднять глубину или разрешить больше дополнительных агентов.

Последнее слово всё равно остаётся за человеком

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

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

Коротко: ответы на вопросы

Если вы только знакомитесь с Codex, Claude Code и средой вокруг них, начните с «Бытовой грамотности вайбкодера». Там простым языком разобраны редактор, терминал, Git, Docker, сервер и другие части работы с ИИ-агентами.

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