JavaRush /Курсы /Claude code /Context pollution и recovery actions

Context pollution и recovery actions

Claude code
5 уровень , 3 лекция
Открыта

1. Проблема часто не в модели, а в состоянии сессии

Сессия странно себя ведёт — первая мысль: «Claude сегодня тупит». Бесполезно. Смотрите не на модель, а на рабочее окно, в котором она рассуждает.

Context pollution — загрязнение контекста: в окне накопились сигналы, мешающие текущей задаче. Не «сломалось внутри Claude».

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

Заметно в длинных сессиях. Чините в Commerce OS баг авторизации: после неверного пароля — пустой экран. Гипотеза про SessionService, потом новый лог, потом LoginController, потом вопрос про SSO callback, потом «глянь, почему тесты медленные». Через сорок минут Claude работает не с задачей, а с клубком полуразобранных мыслей.

Не «Claude стал хуже», а «сессия потеряла дисциплину». Назвали так — появилось лечение.

2. Признаки загрязнённой сессии

Поймать context pollution в начале дешевле, чем спасать сессию через час.

Самый частый признак: Claude возвращается к отвергнутой гипотезе, будто она жива. Вы проверили, что дело не в SessionService, — а он снова предлагает «на всякий случай» поправить там обработку ошибки. Второй: уверенный тон при плохой привязке к фактам — выводы расходятся с файлами, которые он уже читал. Третий: игнорирует свежие ограничения. Вы написали «не трогай SSO и public API» — а diff меняет обработчик авторизации вне scope.

Бытовые маркеры: диалог вязкий; много «извини, ты прав, сейчас исправлю» без улучшения; diff растёт, хотя задача не расширялась; просачивается «раз уж мы здесь, давай ещё…».

Видно на фрагменте рабочего лога:

10:05 — гипотеза: проблема в SessionService
10:14 — проверили AuthFlowTest.failed_login → гипотеза не подтверждена
10:22 — новый фокус: LoginController
10:29 — пользователь добавил: «кстати, ещё проверь SSO callback»
10:36 — в сессию вставлен большой application.log целиком
10:44 — Claude снова предлагает править SessionService
10:49 — Claude меняет LoginController, SessionService и SsoCallbackHandler сразу

Формально всё «логично». Но после 10:29 сессия поплыла: побочная тема залезла в главный поток, большой лог забил контекст, старая гипотеза всплыла. Pollution — серия мелких смещений, а не одна драматичная ошибка.

3. Загрязнение против нехватки контекста

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

Когда данных мало, Claude честен: задаёт уточняющий вопрос, просит файл, stack trace или reproduction steps, помечает вывод как гипотезу. Ответ — добавить файл, кусок лога, test output.

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

Держите эту таблицу под рукой:

Ситуация Что вы видите Что делать
Нехватка контекста Claude задаёт уточняющие вопросы, просит файл, лог или stack trace Добавить точечный источник: файл, фрагмент лога, тест, reproduction
Загрязнение контекста Claude игнорирует свежие ограничения, возвращается к старым гипотезам, diff расползается Чистить сессию: /compact, /clear, /rewind или fresh session
Смена задачи В диалоге уже обсуждаются два-три разных вопроса Не спасать разговор, а разделить рабочие потоки
Рискованный хаос Уже есть странные изменения в файлах Сначала остановиться и прочитать diff, а не просить «исправь ещё»

Рабочий вопрос: «Claude чего-то не знает — или знает слишком много лишнего?» Честный ответ делает recovery action очевидным.

4. Карта восстановления: команды и fresh session

Волшебной кнопки нет. Есть набор действий, каждое под свой тип проблемы. Имена слэш-команд и их поведение меняются от версии к версии: проверяйте /help, но мыслите задачей, а не названием.

Вся карта:

Recovery action Когда выбирать Что это делает Главный риск
/compact
Задача та же, но история стала длинной Сжимает разговор в сводку Теряются нюансы и детали формулировок
/clear
В сессию заехала другая задача или разговор стал слишком смешанным Начинает новый разговор в той же среде Нужно заново внести task spec и evidence
/rewind
Последняя ветка рассуждений явно увела не туда Откатывает сессию к более ранней точке Не все побочные эффекты можно «магически отменить»
Fresh session Несколько failed attempts подряд, противоречия, хаос Полный рестарт с чистым контекстом Если плохо пересобрать task spec, потеряете важные ограничения
Стоп и проверка diff Уже есть изменения в файлах, а логика сессии вызывает сомнения Вы ничего не продолжаете, пока не прочитаете изменения Кажется медленным, но спасает от наслаивания ошибок

Таблица говорит, когда что выбирать. Дальше — нюансы, которых в ней нет.

/compact: не выкидывать разговор, а убрать лишний вес. Полезна инструкция к compaction — заранее говорите, что сохранить.

/compact Сохрани: goal, scope, non-goals, текущую гипотезу,
stack trace excerpt и список уже отвергнутых причин.
Опусти: длинные промежуточные рассуждения и старые черновики.

/clear: не поражение, а «отрезал ненужный хвост». Дешевле открыть чистую беседу, чем тащить мусор.

/rewind работает на уровне сессии и ветки рассуждения. Если изменения затронули файлы — сначала читайте diff и опирайтесь на Git. История проекта живёт не в слэш-команде.

Fresh session боятся: кажется, «потеряешь всё». На деле теряете мусор, если перед стартом собираете короткий жёсткий пакет: цель, scope, non-goals, constraints, evidence.

И главное действие, про которое забывают: ничего не делать, пока не прочитали diff. Добавлять промпты поверх хаоса плохо — сначала смотрите, что поменялось.

5. Сценарий из Commerce OS: спасаем багфикс в auth

Давайте пройдём типичный сценарий. Задача знакомая: после неверного пароля — пустой экран вместо сообщения.

Был хороший task spec: исправить пустой экран, работать только в src/auth/*, public API не менять, SSO не трогать, проверить AuthFlowTest. Claude выдвинул гипотезу про SessionService. Несколько ходов, сверка с тестом — не подтверждается. Дальше классика: побочный вопрос про SSO callback, слишком большой лог, и Claude снова лезет править SessionService.

Взрослое действие — не «ну ладно, исправляй дальше», а остановиться, назвать диагноз и записать recovery-решение.

# SESSION_LOG.md

Задача: пустой экран после неверного пароля в Commerce OS
Область изменений: src/auth/*, AuthFlowTest
Признаки pollution:
- 3 неудачные коррекции подряд
- возвращение к отвергнутой гипотезе про SessionService
- в разговор заехал SSO callback вне scope
- diff затронул лишние файлы

Решение: fresh session
Переносим в новый контекст:
- цель
- текущее поведение / ожидаемое поведение
- фрагмент stack trace
- LoginController.java
- AuthFlowTest
- жёсткие ограничения

Открываете fresh session и переносите не весь разговор, а только суть.

Цель: исправить пустой экран после неверного пароля.
Текущее поведение: при неверных credentials страница рендерится пустой.
Ожидаемое поведение: пользователь видит сообщение об ошибке, redirect не ломается.
Область изменений: src/auth/LoginController.java и AuthFlowTest.
Не-цели: не трогать SSO, не менять public API, не добавлять зависимости.
Доказательства: фрагмент stack trace + failing UI behavior.
Сначала найди root cause и предложи минимальный fix без edits.

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

Менее романтично, чем «вытащить сессию из болота». Зато работает.

6. Task spec как аварийный комплект

Чем лучше оформлен task spec, тем проще переживать pollution. Восстанавливать задачу по памяти нельзя: кажется, что помните всё, но забудете один non-goal или размоете scope — и разговор снова уедет. Task spec — аварийный комплект: переносите goal, current behavior, desired behavior, scope, constraints, критерии приёмки и стартуете заново.

Особенно после /compact (сводка сглаживает нюансы — повторяете критичные ограничения) и fresh session (task spec — основа первого сообщения). Здесь видно, почему формулировки из модулей 3 и 4 были важными. Goal не даёт разговору расползтись. Scope отрезает лишние файлы. Non-goals защищают от «раз уж мы тут, давай ещё». Критерии приёмки — от красивого, но неправильного исправления.

Polluted session лечится не умным промптом, а дисциплиной. Task spec — зафиксированная дисциплина, которую переносишь из сессии в сессию.

7. Привычка зрелого процесса

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

Вместо «нет, не это, давай ещё раз» — спокойный цикл: заметили признаки pollution, остановились, при необходимости прочитали diff, выбрали /compact, /clear, /rewind или fresh session, пересобрали task spec, пошли дальше.

Со временем это автоматизм — как привычка смотреть git status перед работой. И тогда Claude Code ощущается не капризным собеседником, а предсказуемым инструментом.

1
Задача
Claude code, 5 уровень, 3 лекция
Недоступна
Диагноз и recovery action внутри Claude CLI
Диагноз и recovery action внутри Claude CLI
1
Задача
Claude code, 5 уровень, 3 лекция
Недоступна
Исправление policy-файла для борьбы с pollution
Исправление policy-файла для борьбы с pollution
Комментарии
ЧТОБЫ ПОСМОТРЕТЬ ВСЕ КОММЕНТАРИИ ИЛИ ОСТАВИТЬ КОММЕНТАРИЙ,
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ