Два запуска одной задачи

Зачем

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

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

Стартовый набор

Работа индивидуальная. Нужен ноутбук и любой чат с LLM. Если вы пользуетесь агентом, можно провести эксперимент в нём. Готовый код, рабочий репозиторий, подписка и ключ API не нужны: подойдёт ситуация на этапе требований или проектирования.

Удобно взять проект, который вы представляли на прошлой паре.

Что нужно сделать

1. Выбрать ситуацию ~10 мин

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

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

   Запишите ожидаемый результат и 2–3 признака, по которым будете его проверять.

2. Первый запуск ~10–12 мин

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

3. Подготовить контекст ~15 мин

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

   Если есть репозиторий и агент, устойчивые сведения можно вынести в AGENTS.md, CLAUDE.md или аналог: как устроен проект, какими командами запускаются проверки, какие соглашения действительно соблюдаются. Сведения только про эту задачу передавайте в самом запросе. Для обычного чата достаточно карты проекта в карточке, файл правил не обязателен.

4. Второй запуск и проверка ~15 мин

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

   Сравните ответы по выбранным признакам. Если сервис показывает расход токенов, запишите его; если нет, пропустите. Более длинный ответ сам по себе не лучше.

5. Решить, что делать дальше ~10 мин

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

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

6. Обсуждение и сдача ~10–15 мин

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

Карточка результата

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

Первый запуск — исходный запрос и ссылка на диалог либо существенная выдержка из ответа.

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

Второй запуск — запрос и ссылка на диалог либо существенная выдержка из ответа.

Сравнение — 2–3 конкретных наблюдения по заранее выбранным признакам; расход токенов, только если он виден.

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

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

Что сдаём

• Карточку результата — одним Markdown-файлом или документом, в топик «Практики».

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

Зачтено, если

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

Балл	Когда ставится
1	Два сопоставимых запуска; выбор контекста обоснован; сравнение опирается на конкретные фрагменты ответов и заранее выбранные признаки; выделен сомнительный фрагмент и предложен проверяемый следующий шаг.
0.5	Оба запуска есть, но выбор контекста почти не объяснён, сравнение сводится к общей оценке без примеров или следующий шаг не связан с конкретным ответом.
0	Нет одного из запусков, нельзя понять задачу и разницу условий или нет анализа результата.

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

При оценке ниже 1 студент получает фидбек.

Типовые грабли

• Во втором запуске поменяли саму задачу. Сравнивать стало нечего: разница могла появиться из-за другой задачи, а не из-за контекста.
• Признаки качества придумали после того, как увидели ответы. Записывайте их до первого запуска.
• Второй запуск в том же диалоге. Модель уже видела первую попытку, и это не «подготовленный контекст», а продолжение разговора.
• В контекст положили всё подряд, «на всякий случай». Лишние сведения стоят токенов и внимания модели, а в карточке нечего написать в графу «что исключено и почему».
• «Второй ответ лучше, потому что длиннее». Длина — не признак качества.
• Приняли ответ, потому что он звучит уверенно. Уверенный тон не означает, что утверждение верно: проверьте его по документации или запуском.