Долгие задачи через несколько окон контекста: как вести состояние

Осведомлённость о контексте

Современные модели Claude отслеживают остаток своего окна контекста на протяжении разговора - это помогает выполнять задачи и управлять контекстом эффективнее, понимая, сколько места ещё есть на работу. Если инструмент, в котором работает модель, автоматически сжимает контекст или позволяет сохранять его во внешние файлы (как в Claude Code), стоит явно сообщить об этом в промпте - иначе модель может естественным образом начать сворачивать работу по мере приближения к лимиту:

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

Первое окно контекста тратится иначе, чем следующие

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

Стоит попросить модель писать тесты в структурированном формате (например, в файле tests.json) заранее - это заметно улучшает способность продолжать работу в долгосрочной перспективе. Полезно прямо напомнить о важности тестов: «недопустимо удалять или редактировать тесты, поскольку это может привести к пропущенной или сломанной функциональности».

Установочные скрипты и чистый старт вместо сжатия

Стоит поощрять модель создавать установочные скрипты (например, init.sh) для аккуратного запуска серверов, набора тестов и линтеров - это избавляет от повторной работы при продолжении с чистого окна контекста.

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

• «Выполни pwd; ты можешь читать и писать файлы только в этой директории».
• «Просмотри progress.txt, tests.json и логи git».
• «Прогони вручную базовый интеграционный тест, прежде чем переходить к реализации новых функций».

Практики ведения состояния

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

Git стоит использовать как журнал состояния: он даёт лог сделанного и контрольные точки, к которым можно вернуться - современные модели Claude особенно хорошо умеют использовать git для отслеживания состояния между несколькими сессиями. И стоит явно подчёркивать важность инкрементального прогресса - прямо просить модель отслеживать прогресс и фокусироваться на пошаговой работе.

{
  "tests": [
    { "id": 1, "name": "authentication_flow", "status": "passing" },
    { "id": 2, "name": "user_management", "status": "failing" },
    { "id": 3, "name": "api_endpoints", "status": "not_started" }
  ],
  "total": 200,
  "passing": 150,
  "failing": 25,
  "not_started": 25
}

Прогресс сессии 3:
- Исправлена валидация токена аутентификации
- Обновлена модель пользователя для граничных случаев
- Дальше: разобраться с падающим тестом #2 (user_management)
- Важно: не удалять тесты - это может привести к пропущенной функциональности

Граница между автономностью и безопасностью

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

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

Примеры действий, которые требуют подтверждения:
- Разрушительные операции: удаление файлов или веток, удаление таблиц
базы данных, rm -rf
- Труднообратимые операции: git push --force, git reset --hard,
правка уже опубликованных коммитов
- Операции, видимые другим: публикация кода, комментарии в PR/issues,
отправка сообщений, изменение общей инфраструктуры

Столкнувшись с препятствием, не используй разрушительные действия как
обходной путь. Например, не обходи проверки безопасности (--no-verify)
и не удаляй незнакомые файлы, которые могут быть чьей-то незавершённой
работой.

Чек-лист