В задаче для ИИ прежде всего нужен результат, который можно принять. «Ты лучший разработчик» может обозначить ожидаемую роль, но не объясняет, что нужно сделать. «Сделай хорошо» не даёт способа проверить ответ. А «исправь всё» оставляет исполнителю слишком много пространства для догадок.
Работа с ИИ делает особенно заметной обычную управленческую проблему: постановщик знает контекст и считает, что исполнитель тоже его знает. Но большая часть этого контекста остаётся у постановщика в голове. В разборе постановки задачи команде описана та же проблема в работе с людьми.
Конкретный пример из работы над Clix — сведения о месте занятия. Клиент выбирает групповую тренировку: день, время и ведущий видны, а где проходит занятие — до записи непонятно. На этой ситуации построен учебный пример постановки задачи. Он иллюстрирует подход, не воспроизводя дословную переписку с агентом.
Короткое поручение, в котором спрятано несколько решений
Начать можно так: «Добавь локации в групповые занятия».
Проблема здесь в недосказанности. Из поручения нельзя понять, кому нужна информация, в какой момент и что считать завершением. Агент может добавить поле в настройках, вывести адрес только после записи или предположить, что у всех занятий группы одно место.
Прежде чем обсуждать реализацию, стоит зафиксировать потребность: клиент должен понимать место конкретного занятия ещё во время выбора. Теперь понятно, ради чего меняется продукт.
Что нужно сообщить исполнителю
1. Цель и исходная ситуация
Постановщик описывает, кто столкнулся с проблемой и что сейчас мешает. В примере это человек, выбирающий тренировку. Место нужно ему до принятия решения о записи. Такая информация помогает оценить предложенный экран или техническое решение.
2. Ожидаемый результат
Постановщик определяет, что должно появиться в конце работы. Для исследования это может быть список подтверждённых причин и вариантов решения. Для реализации — работающее поведение на тестовом окружении. Для проверки — отчёт по оговорённым сценариям с найденными проблемами.
Эти результаты лучше не смешивать в неопределённое «разберись и сделай». Если правило ещё не согласовано, первым результатом будет предложение решения. Если всё известно, можно сразу поручить реализацию.
3. Контекст и исходные материалы
Исполнитель получает ссылки на нужный экран, обратную связь и относящуюся к задаче документацию. В задачу входит проверка существующего устройства продукта. Если сведения о месте уже хранятся в системе, это важно узнать до создания ещё одного поля.
Не обязательно пересказывать всю историю проекта. Полезен контекст, который влияет на решение. Общая база знаний помогает его передавать, если в ней можно найти актуальные сведения.
4. Ограничения и существенные неизвестные
В задании указываются границы: например, доработка групповых занятий не должна попутно менять правила индивидуальной записи. Если пока непонятно, как место связано с конкретным занятием, это нужно выяснить, а не оставлять на молчаливое усмотрение исполнителя.
Не всякая неопределённость требует остановки. Название временного файла агент может выбрать сам. Правило, от которого зависит показ адреса клиенту, требует осознанного решения. Полезно заранее разделить эти случаи.
5. Проверка и завершение
До начала работы определяется способ приёмки. Для этого подходят наблюдаемые действия: сохранить значение, повторно открыть страницу, пройти клиентский путь. «Сделано качественно» не помогает отличить верное выполнение от правдоподобного отчёта.
Отдельная задача должна сохранять концепцию
У задания есть ещё одна граница: оно не должно незаметно менять назначение продукта. Если поручено улучшить страницу записи к конкретному специалисту, добавление каталога, новых шагов или другого порядка выбора требует отдельного решения.
Поэтому исполнителю нужны сведения о том, что должно сохраниться. А проверяющему — исходная цель, а не только список внесённых правок. Иначе он может принять каждую часть и пропустить, что вместе они уже решают другую задачу. Этот риск подробно разобран в статье о сохранении замысла проекта при работе с ИИ.
Пример: сначала разобраться и предложить решение
Если устройство нужной части продукта ещё не установлено, первая задача агенту может выглядеть так:
Цель. Клиент Clix должен понимать, где состоится выбранное групповое занятие, до оформления записи.
Исходная ситуация. В расписании видны день, время и ведущий; сведений о месте для выбора недостаточно.
Текущий этап. Изучи путь клиента и настройки организатора. Найди, где уже задаётся и хранится место. Проверь, может ли оно отличаться у отдельных занятий.
Результат этапа. Опиши фактическое поведение, предложи подходящий способ показывать место и перечисли необходимые изменения. Отдельно назови неизвестные и решения, которые нужно согласовать.
Границы. На этом этапе не меняй код. Не считай предположение о связи группы, занятия и места установленным правилом. Учти существующие сценарии записи.
Остановка после исследования нужна здесь потому, что от ответа зависит устройство доработки. Это не универсальное требование согласовывать каждую мелочь. В понятной небольшой задаче можно сразу описать ожидаемое поведение и поручить изменение.
После решения — задача на реализацию и приёмку
Когда правило согласовано, его нужно перенести в задание следующего этапа. Исполнитель должен получить именно принятое решение, а не набор вариантов из предыдущего обсуждения.
Для примера с местом занятия подходят такие проверки. Это пример критериев; окончательные формулировки зависят от согласованной логики продукта:
- Клиент видит место выбранного занятия до оформления записи.
- После изменения и сохранения места организатором клиентская страница показывает актуальные сведения.
- Если занятия проходят в разных местах, сведения между ними не перепутаны.
- Если место не задано, интерфейс ведёт себя по заранее принятому правилу и не показывает выдуманный адрес.
- После повторного открытия нужные данные сохраняются.
- Изменение не ломает относящиеся к нему прежние сценарии записи.
Видно, что проверяется здесь не только наличие нового текста на экране. Нужно пройти путь от изменения данных до того, что увидит клиент.
Шаблон задачи для ИИ
Для следующего поручения можно взять этот каркас. Объём описания должен соответствовать задаче: для короткой правки достаточно нескольких предложений.
Зачем: кто получит пользу и какую проблему решаем.
Что известно: текущее поведение, материалы, данные и уже принятые решения.
Что сделать сейчас: конкретный этап и ожидаемый результат.
Границы: что входит в работу, что не входит и какие ограничения важны.
Что должно сохраниться: исходный смысл продукта и согласованные правила, которые нельзя менять в рамках этого поручения без отдельного решения.
Неизвестные: что можно решить самостоятельно, а что нужно уточнить до реализации.
Как проверить: действия и наблюдаемые признаки правильного выполнения.
Что передать: результат, выполненные проверки, ограничения и следующий шаг.
Для задачи на текст результатом будут материал и проверка фактов. Для аналитики — расчёт, исходные данные и объяснение допущений. Для изменения продукта — работающее поведение и подтверждение нужных сценариев. Каркас один, содержание приёмки разное.
Приёмка результата каждой роли
Если один агент исследует проблему, другой реализует решение, а третий проверяет, между ними возникают обычные зависимости. Ошибка первого может стать исходным условием для остальных. Поэтому у каждого этапа должен быть свой принимаемый результат.
После исследования проверяются основания выводов. После реализации — соответствие изменения принятому решению. После тестирования — проверка нужного сценария на нужной версии. Отдельный проверяющий полезен, но сам по себе не гарантирует независимость: он тоже может унаследовать ошибочное предположение.
В Clix для этого различаются «написано», «проверено», «выложено» и «принято». Это помогает увидеть оставшуюся работу. Если агент не смог выполнить проверку, это должно быть явно сказано в отчёте.
Если ответ не устраивает
Фраза «переделай нормально» обычно добавляет мало информации. Полезнее указать наблюдаемое расхождение: ожидали, что адрес виден до записи, а он появляется только на экране подтверждения. После этого попросить определить причину и исправить её в согласованных границах.
Иногда ошибка в выполнении. Иногда выясняется, что постановщик и исполнитель не договорились о правиле. Постановщик тоже участвует в работе: уточняет задачу, принимает промежуточные решения и соотносит результат с исходной целью.
Умение работать с ИИ начинается с умения поручить работу так, чтобы её можно было принять. А дальше — действительно принять её, проверив результат.
О том, как связать такие задачи в целый проект, — в статье про этапы, роли и контроль работы с ИИ.