Практика GrantTap · · 12 мин чтения
Как поставить задачу coding-агенту до первого запуска
От неопределённой просьбы к проверяемому результату: момент ошибки, окружение, полномочия, исходные свидетельства и приёмка, которую удобно оценить с телефона.
Одна из самых дорогих инструкций coding-агенту звучит уверенно, но остаётся неопределённой: «доделай приложение». Агенту приходится самостоятельно решать, что сломано, какой результат считать завершением, какой репозиторий менять и разрешена ли публикация. Когда человек находится далеко от компьютера, такие догадки могут долго направлять работу до первого замеченного расхождения. Полезное описание задачи уменьшает неопределённость заранее, до первой существенной команды, а затем помогает оценивать продвижение по наблюдаемому результату вместо количества выполненных инструментов и написанных сообщений.
GrantTap делает такой подход удобным: телефон передаёт точную инструкцию и последующее решение компьютеру, который владеет работой. Телефону не обязательно становиться настольным редактором. Ему нужно сообщить достаточный контекст, чтобы агент действовал в нужных границах и вернул проверяемый итог. Здесь разобран способ подготовки такой инструкции на вымышленном примере задержанного разрешения. Это учебный сценарий, а не сообщение о проведённой проверке конкретного проекта, новой сборке или уже исправленном дефекте, который автоматически закрывает похожую проблему у любого пользователя.
Опишите момент, который работает неправильно
Начните с действия пользователя и видимого результата. «После разрешения запроса на телефоне окно остаётся Applying, а компьютер не продолжает работу» полезнее общего утверждения о сломанных разрешениях. Здесь названы запуск сценария, поверхность интерфейса и ожидаемое продолжение. При этом остаются возможными разные причины. Экран мог устареть, решение могло не дойти до хоста, а провайдер мог ожидать другого условия. Такое описание даёт исследованию направление, не навязывая заранее исправление компонента, который ещё не признан источником проблемы по фактическим наблюдениям.
Добавьте известные условия: затронутую Task, нужный компьютер, провайдера и примерное время. Скриншот полезен, когда уточняет интерфейс, однако он не должен объяснять всю последовательность вместо текста. Обрезанное изображение может не содержать маршрут или идентичность ожидающего запроса. Короткое письменное воспроизведение позволяет исследователю повторить путь, не угадывая его по визуальным фрагментам. Отдельно назовите, какие действия вы уже пробовали: повторное открытие, обновление статуса, отправку сообщения или перезапуск приложения. Это уменьшает вероятность повторения тех же бесполезных шагов без нового основания.
Отделяйте наблюдение от диагноза. Если подозреваете relay, назовите это гипотезой. Не требуйте переписать транспорт только потому, что сообщение задержалось. Сначала агент должен установить, какого подтверждения не хватает. Сильное описание ограничивает желаемый результат, оставляя исследованию возможность следовать за свидетельствами. Преждевременно назначенная причина способна заставить вполне компетентного агента быстро и тщательно чинить компонент, который вообще не участвовал в исходном сбое. Пользователь после такой работы получает большой diff, прежний симптом и ещё более сложную систему для следующего расследования.
Назовите желаемое поведение
Опишите, что должно произойти после исходного действия. В примере с разрешением решение относится к правильному ожидающему запросу, компьютер подтверждает результат, а телефон перестаёт показывать действие незавершённым после свежего наблюдения. Это проверяемое поведение. Оно устойчивее требования вызвать определённую функцию или установить конкретный флаг, потому что устройство реализации может измениться в процессе исправления. Пользователь обычно заинтересован именно в завершённом сценарии, а не в сохранении заранее угаданной внутренней архитектуры, которая могла оказаться причиной части проблемы.
Добавьте важные отрицательные случаи. Ответ на истёкший запрос не должен разрешать более новый. Переподключение не должно дублировать решение. Открытие старого уведомления не должно создавать видимость нового действующего разрешения. Эти случаи определяют границы правильного поведения и помогают выбрать содержательные проверки. Иначе агент может написать тест, который лишь подтверждает форму добавленного поля, но не способен обнаружить исходную ошибку. Хорошие критерии описывают, что система обязана принять, что должна отвергнуть и какое свидетельство позволит человеку отличить оба результата.
Не назначайте универсальный предел задержки без описания среды. Требование своевременно обновлять экран после подтверждения компьютера подходит как начало. Точный бюджет времени следует связать с базовым измерением на нужных устройствах и сети. Если фиксированный предел действительно обязателен, укажите условия и метод проверки. Это защищает от подмены: быстрая локальная модель клиента не является доказательством такого же поведения на физическом телефоне через мобильное соединение. Число становится полезным требованием только вместе с объяснением, что именно измеряется и где заканчивается область сделанного вывода.
Сохраняйте объём, который можно проверить
Исследование может затронуть несколько репозиториев и всё равно иметь одну понятную цель. В доставке разрешения участвуют интерфейс, bridge и relay. Назовите относящиеся к задаче репозитории и границы, которые агент может исследовать. Также обозначьте соседние системы, которые пока не требуют изменений. Это помогает не превратить конкретный дефект в переписывание входа, развёртывания и хранения проектов. Чем яснее связь между изменением и исходным сценарием, тем проще проверить необходимость работы и тем меньше вероятность случайно затронуть другие продукты.
Объём задачи не запрещает обнаруживать зависимости. Если необходимое исправление пересекает первоначальную границу, агент должен объяснить связь и сделать результат обозримым. Важно различать обязательную связанную работу и предположительное расширение. Новая возможность не становится частью поручения только потому, что нужный для неё файл уже открыт. Видимая цель помогает человеку и агенту принимать такое решение. Когда возникают два действительно независимых улучшения, их полезно различать в описании и проверках, чтобы успех одного не скрывал незавершённость другого в итоговом отчёте.
Для удалённой работы небольшой объём review улучшает общение. Человек может понять конкретное поведение до и после, посмотреть короткое объяснение изменений и ответить на предметный вопрос с телефона. Большая необъяснённая пачка правок затрудняет ответственное решение. Если ремонт содержит несколько независимых частей, попросите сохранить их границы проверки. Не следует объявлять весь набор неделимым успехом только потому, что все файлы попали в один коммит. У каждой существенной части должно быть понятное основание и свидетельство, относящееся именно к ней.
Уточните рабочее окружение
Назовите нужный репозиторий или каталог проекта, если он известен. При нескольких копиях добавьте ветку или revision. Один репозиторий может одновременно находиться в release checkout, экспериментальном worktree и основной рабочей папке пользователя. Знакомого имени каталога недостаточно для определения назначения изменений. Описание должно помочь найти окружение без молчаливой подмены другим проектом. Если точный путь неизвестен, лучше явно сообщить неизвестность, чем угадывать и позднее трактовать результат работы с чужой копией как исправление нужной задачи на компьютере.
Укажите условия, влияющие на воспроизводимость. Ошибка физического телефона может не повторяться в симуляторе. Проверка без сети отличается от обычного сетевого запуска. Провайдер, открытый непосредственно в терминале, иногда получает другое окружение, чем управляемый сервис. Эти различия должны направлять первоначальный осмотр. Их неудобно сообщать поздним замечанием после того, как агент завершил ремонт в неподходящих условиях. Чем раньше названа значимая зависимость, тем меньше времени уйдёт на убедительное, но не относящееся к реальному пользовательскому сценарию доказательство успеха.
Если работу действительно нужно переместить, полезно руководство по передаче Task. Передача является отдельной операцией с состояниями источника и назначения. Она не заменяет выяснение местоположения файлов. До смены хоста или провайдера сохраните цель, рабочую копию, локальные изменения и оставшиеся проверки. Хорошая постановка делает продолжение возможным, не предполагая одинаковых файлов и credentials во всех средах. Получатель должен понимать, что уже перенесено, что осталось на источнике и какое действие требуется до начала следующего исполнения.
Опишите полномочия конкретными действиями
Агенту важно знать, что уже разрешено. Чтение исходников, локальное исправление, проверки, push ветки, merge, публикация пакета и развёртывание сервиса являются разными операциями. В описании можно явно разрешить нужную последовательность. После этого агент должен пользоваться существующим поручением, а не регулярно отвлекать человека одинаковым вопросом. Ясные полномочия поддерживают самостоятельность и ответственность одновременно. Они также помогают следующему исполнению сохранить принятую авторизацию, вместо того чтобы после сокращения истории начинать весь разговор о допустимых действиях с нуля.
Для существенных операций используйте точные формулировки. Подготовка кандидата релиза с отчётом отличается от публикации проверенного кандидата в существующую внутреннюю группу TestFlight. Очистка сгенерированных файлов данной сборки отличается от удаления старых архивов всех проектов на диске. Такая конкретность позволяет закончить действительно порученную работу и представить обозримый результат. Она также уменьшает вероятность вопроса о разрешении слишком рано, когда человеку ещё нечего предметно оценить. Сначала должно появиться конкретное исправление или артефакт, к которому относится последнее значимое решение о выпуске.
Полномочия сохраняют область действия. Поручение починить один сервис не означает разрешения писать посторонним людям или менять production-базу другого продукта. Если обнаружилась новая существенная зависимость, агент должен сделать её конкретной и объяснить необходимость. Цель состоит в уменьшении ненужных остановок благодаря ясной записи задачи. Неопределённое разрешение на всё, которое можно растянуть на любую будущую идею, хуже помогает сотрудничеству. Гораздо полезнее заранее связать допустимые действия с продуктом, назначением, типом результата и проверкой, после которой становится возможен следующий шаг.
Дайте сведения, которые сужают первый поиск
Хорошие исходные материалы включают точную ошибку, идентификатор запроса в приватной записи, короткое воспроизведение и последнее известное правильное поведение. Время помогает сопоставить наблюдения устройств. Версия связывает симптом с исходниками и работающим runtime. Ни один такой факт не доказывает причину самостоятельно. Вместе они сокращают исследование от всего продукта до конкретного пути и интервала. Отдельно полезно назвать источник каждого наблюдения: экран телефона, окно провайдера, журнал компьютера или отчёт сборки. Это мешает смешивать факты разной надёжности и свежести.
Не перегружайте первое описание всеми логами. Большой неотфильтрованный вывод скрывает нужный переход, расходует контекст и может раскрыть лишние сведения. Начните с минимального полного материала, объясняющего симптом, а глубокие данные оставьте доступными по ссылке. Агент тогда выбирает следующий источник по текущему вопросу вместо постоянного обхода огромной коллекции без правила остановки. Такая подготовка особенно помогает на телефоне: человеку проще увидеть, какое свидетельство действительно нужно добавить, чем читать многостраничный список технических сообщений с неизвестным отношением к проблеме.
Если свидетельств не хватает, скажите прямо. Отсутствие проверки терминала важно: последующий пересказ не должен считать получение провайдером установленным фактом. Скриншот предыдущей сборки имеет другой смысл, чем снимок текущего кандидата. Явные неизвестные помогают спроектировать следующую проверку. Простой точный рассказ полезнее отполированного, но неоднозначного отчёта. В нём должны различаться увиденное поведение, выполненные попытки, предположительная причина и непроверенные условия. Тогда агент сможет продолжать исследование без незаметного превращения пользовательской догадки в обязательную техническую истину проекта.
Определите завершение через пользовательский сценарий
Критерии приёмки должны описывать путь человека. Для ошибки разрешения откройте новый запрос, примите решение на телефоне, получите подтверждение компьютера и убедитесь, что провайдер продолжает только при разрешающем ответе. Затем проверьте устаревший запрос и переподключение. Задача заканчивается демонстрацией соответствующего поведения, а не редактированием правдоподобной функции. Уверенный итоговый текст агента полезен как объяснение, однако не заменяет свидетельство результата. Человек должен понимать, какая конкретная проверка отличает исправление от ещё одной хорошо оформленной гипотезы.
Выбирайте проверки, способные обнаружить исходную ошибку. Тест, сравнивающий новое поле с ним самим, даёт мало уверенности. Управляемая гонка между старым ответом и новым запросом полезнее, поскольку затрагивает настоящую границу. Глубина проверки должна соответствовать риску. Маленькая правка текста обычно не требует большой новой тестовой системы, а маршрутизация решений заслуживает содержательной регрессии. Описание задачи может прямо назвать опасное межсобытийное условие. Тогда реализация теста останется делом разработчика, но цель проверки будет понятна до появления кода.
Сохраняйте видимое различие между выполненными и запланированными проверками. Успех симулятора является настоящим результатом для этой среды. Он не является проверкой физического телефона. Сборка не доказывает принятие решения провайдером. Загрузка релиза не доказывает доступность тестировщикам. Хорошее поручение поощряет такую точность отчёта. Пользователь тогда может принять следующее решение без восстановления ограничений из разрозненных оговорок. Если обязательная среда недоступна, она должна остаться явной незавершённой зависимостью, а не исчезнуть из формулировки успеха после окончания локальных проверок.
Просите прогресс, который меняет понимание
Полезный промежуточный отчёт объясняет найденное, неизвестное и следующий шаг, который устранит неопределённость. Сообщение о созданном решении на телефоне при отсутствии соответствующего подтверждения хоста сужает проблему. Поток одинаковых Working ничего не уточняет. Человек должен понимать, продвигается ли задача, ждёт ли внешнего условия или возвращается к уже опровергнутому предположению. Такая связь особенно важна в долгой удалённой работе, когда отсутствие новых сообщений легко принять за остановку, хотя на компьютере может продолжаться полезная проверка или ожидаться конкретный результат команды.
Для длинной задачи попросите сохранить краткую запись продолжения. В ней нужны текущая revision, изменения, выполненные проверки и обязательный следующий шаг. Это мешает новой сессии повторять старые эксперименты или считать незавершённый выпуск готовым. Запись должна переносить существующие полномочия и ограничения. Для компетентного продолжения ей не требуется содержать приватные рассуждения модели или каждую строку терминала. Достаточно проверяемых решений и ссылок на основания, чтобы другой агент мог понять текущее положение, проверить значимый вывод и сделать следующий осмысленный шаг.
Вопрос человеку должен быть самостоятельным и касаться действительно отсутствующих сведений. Если ответ уже есть в истории, конфигурации или доступном подключённом источнике, сначала нужно прочитать его. На телефоне повторные вопросы нередко мешают больше самой разработки. Описание может требовать самостоятельного выполнения обычной работы, оставляя уточнения для решений, меняющих объём, риск или желаемое поведение продукта. Так автономность получает понятную опору: агент продолжает в существующих границах и обращается к владельцу тогда, когда новая информация действительно необходима для следующего решения.
Используйте описание, которое переживёт передачу
Итоговый brief можно написать связным текстом: воспроизвести зависшее Applying, проверить названные Task и компьютер, сохранить идентичность запроса при переподключении, исправить нужный путь, выполнить регрессию со старым ответом, подготовить разрешённый выпуск и сообщить точную сборку с оставшимися проверками устройства. Добавьте актуальные источники. Такое поручение сообщает следующему исполнению и требуемый результат, и свидетельства завершения. При смене агента не придётся догадываться, что означало слово «доделай» и какие действия уже были разрешены в предыдущей части разговора.
Проверьте описание на случайные противоречия. Немедленное исполнение при запрете прерывать работающего провайдера требует безопасной очереди или реально поддерживаемого пути уточнения. Требование результата физического телефона при отключённом устройстве сохраняет зависимость от его доступности. Хорошая инструкция не отменяет ограничения среды. Она делает их достаточно конкретными для обработки без потери цели и повторения одного вопроса. Если условия несовместимы, полезно сначала определить допустимый порядок действий, а затем предоставить агенту самостоятельность внутри этой последовательности, сохранив наблюдаемый критерий завершения работы.
Результатом становятся более точная работа и меньшее число сообщений. Агент исследует самостоятельно, потому что понятны цель, окружение, полномочия и сценарий приёмки. Человек проверяет прогресс с телефона, поскольку каждое обновление относится к конкретной границе. GrantTap переносит инструкции и решения между устройствами, сохраняя понятную Task. Качество общей записи задачи является одним из самых практичных улучшений ещё до добавления новой модели или автоматизации. Оно помогает завершать работу, возвращаться к ней после паузы и честно различать выполненное действие, подтверждённый результат и оставшуюся неизвестность.