# Как не дать долгой coding-сессии потерять контекст? > Чтобы не терять контекст, переносите устойчивые факты из чата в компактный журнал задачи, журнал решений, запись тестов и checkpoint репозитория. Перед сжатием или сменой модели загружайте состояние из этих артефактов. Долгие сессии обычно ломаются из-за постепенного дрейфа, а не внезапной амнезии. Агент помнит общую цель, но теряет небольшое ограничение, доверяет старому тесту, повторяет исследование или редактирует по плану, уже не соответствующему repository. Решение — устойчивое внешнее состояние, которое короче и надёжнее транскрипта. Считайте диалог рабочей памятью, а repository — источником истины. На каждом значимом checkpoint записывайте, что изменилось, что проверено, что остаётся неопределённым и что делать дальше. ## Отслеживайте четыре вида контекста Разделяйте факты по функции, чтобы резюме не превращалось в неструктурированную историю. | Тип контекста | Примеры | Постоянное место | |---|---|---| | Цель | Результат пользователя и критерии приёмки | Журнал задачи | | Ограничения | Совместимость, безопасность, стиль, объём | Журнал задачи | | Состояние repository | Изменённые файлы и текущая ветка | Version control | | Доказательства | Тесты, логи, снимки, benchmark | Журнал проверки | Добавляйте предположения как пятый тип только с явной меткой. Для каждого укажите самое дешёвое действие, способное подтвердить или опровергнуть его. ## Ведите компактный журнал задачи Полезный журнал помещается на одном экране. Обновляйте его после вех, а не после каждого сообщения. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` Сохраняйте точные пути, команды и имена ошибок. Не превращайте журнал в хронику обсуждения. ## Создавайте checkpoint вокруг проверенного состояния Checkpoint должен следовать за результатом, который следующая сессия может воспроизвести: прошедшей группой тестов, небольшой сохранённой правкой, подтверждённым API-ответом или решением с fixture. До смены модели или сжатия запишите изменённые файлы. Не считайте функцию готовой только потому, что код написан; свяжите утверждение с тестом, build или наблюдаемым артефактом. | Утверждение | Нужное доказательство | |---|---| | Parser поддерживает два вызова | Fixture с двумя связанными call ID | | Retry безопасен | Тест idempotency при разрыве | | Refactor сохраняет поведение | Старые и новые тесты проходят | | UI корректен | Render-проверка в целевых размерах | ## Читайте текущий источник вместо воспроизведения чата Когда важна деталь, заново откройте текущий файл, схему или официальный документ. Старый транскрипт может описывать уже изменившийся код. Дайте агенту пути и поисковые термины для проверки актуального состояния. Retrieval должен быть узким: сначала интерфейс, реализация, падающий тест и релевантный лог, а не весь repository. Это сохраняет место для рассуждений. ## Сжимайте, сохраняя решения и доказательства Хорошее сжатие удаляет повторы разговора, но сохраняет ограничения, труднообратимые решения, отвергнутые варианты и проверки. Разделяйте `verified`, `observed`, `assumed` и `pending`. Не описывайте неудачный эксперимент как финальный дизайн. Сохраняйте причину отказа, если тот же привлекательный подход может вернуться. ## Ограничивайте вывод инструментов до контекста Длинные логи и сгенерированные файлы быстро расходуют внимание. Запрашивайте релевантные диапазоны, количества или совпавшие строки. Полный вывод сохраняйте артефактом, а в контекст возвращайте краткое резюме с путём. Для ошибки теста достаточно первого полезного stack trace, упавшего assertion и параметров среды. Не отправляйте модели сотни повторяющихся строк. ## Возобновляйте работу детерминированным ритуалом После паузы, сжатия контекста или смены модели: * Прочитайте цель и ограничения. * Проверьте version control и последние изменения. * Откройте файлы из раздела текущего состояния. * Повторите последнюю релевантную проверку. * Подтвердите актуальность следующего действия. Этот ритуал обнаруживает устаревшее резюме до новых правок. ## Выбирайте модели без опоры на память транскрипта Gateway упрощает смену модели, но состояние остаётся вашей ответственностью. Atlas Cloud предлагает несколько LLM-протоколов на одном base URL; до переноса активного агента проверьте [матрицу протоколов](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) и актуальный [каталог моделей](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context). Передайте новой модели журнал задачи, релевантные исходники и свежий результат проверки. Не полагайтесь на специфический state handle без подтверждения того же протокола и поведения. ## Итог Долгая coding-сессия сохраняет контекст, когда устойчивое состояние компактно, подкреплено доказательствами и легко загружается. Ведите журнал на один экран, создавайте checkpoint вокруг проверенных изменений, читайте актуальные источники, ограничивайте вывод и используйте детерминированный ритуал продолжения. Большое context window помогает, но восстановимость обеспечивает дисциплинированное внешнее состояние. ## FAQ ### Достаточно ли большого context window для долгой coding-сессии? Нет. Больше места лишь откладывает давление и не гарантирует, что старые ограничения останутся заметными, а устаревшие наблюдения будут исправлены. ### Что должно быть в журнале coding-сессии? Цель, ограничения, текущий план, изменённые файлы, ключевые решения, результаты проверки, открытые риски и точное следующее действие. ### Как часто агенту создавать checkpoint? После значимого изменения состояния: успешного теста, завершённого шага миграции, решения по дизайну или открытия, меняющего план. ### Нужно ли вставлять весь транскрипт в новую модель? Обычно нет. Дайте отобранный checkpoint, релевантные исходные файлы и логи, затем позвольте модели проверить текущее состояние repository. ### Как не закрепить старую ошибку в резюме? Отделяйте проверенные факты от предположений, прикрепляйте доказательства вроде команд или путей и убирайте утверждения, опровергнутые новыми тестами. ### Как безопаснее всего продолжить работу после перерыва? Загрузите журнал задачи, проверьте version control, повторите последнюю релевантную проверку и начните с записанного следующего действия.