Контекст в коде: как перепечатать изменения

Что такое контекст в коде?

Представь фрагмент кода, который запускается внутри программы. Он не существует в пустоте. Рядом есть значения, доступные функции, настройки и данные. Они влияют на то, что произойдёт при выполнении.

Такой набор доступных значений, функций и настроек называют контекстом фрагмента.

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

Anthropic называет контекстное окно рабочей памятью модели:

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

Отсюда две разные ситуации:

• файл лежит на диске, но модель его ещё не читала;
• файл прочитан и его содержимое попало в текущий контекст.

Для первой ситуации файл существует в проекте. Для второй он доступен конкретному ответу.

Если агент переписал половину проекта, причина часто не в том, что он «ничего не понимает». Он мог получить другой набор инструкций, файлов и сообщений. Контекст изменился, поэтому изменился и результат.

Я бы держал в голове короткую формулу:

Контекст = что доступно операции прямо сейчас

Для обычного кода объект контекста задаёт окружение выполнения. Для Claude - содержимое запроса и накопленная история работы.

Как появляется контекст вызова?

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

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

У Claude последовательность видна ещё нагляднее:

1. Ты отправляешь сообщение.
2. Claude формирует ответ.
3. Claude может создать блок tool_use.
4. Программа запускает инструмент.
5. Результат добавляется как tool_result.
6. Новый запрос отправляется с обновлённой историей.

Anthropic описывает это так:

Anthropic объясняет, что предыдущая история разговора передаётся через параметр messages, а модель генерирует следующее сообщение разговора.

• Anthropic, Create a Message

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

В API разговор не хранится сам по себе. Приложение передаёт историю заново в каждом запросе. Текущий ответ добавляется к этой истории, затем отправляется следующий запрос.

Получается цепочка:

сообщение
  -> ответ Claude
  -> tool_use
  -> tool_result
  -> новый запрос

Если результат инструмента собран неправильно или оказался не на своём месте, продолжение разговора может сломаться. В документации Anthropic есть отдельное требование: блок tool_result должен сразу идти после соответствующего tool_use.

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

В каком контексте выполняется этот код?

Начни с самого фрагмента. Потом двигайся наружу.

Проверь:

• какие инструкции действуют;
• какие файлы уже прочитаны;
• какие прошлые сообщения влияют на задачу;
• какие зависимости доступны;
• какие инструменты подключены;
• какие результаты инструментов появились;
• не было ли сжатия или очистки истории.

Файл в папке ещё не означает, что он входит в текущий контекст. Модель должна получить его содержимое через сообщение, чтение файла или другой доступный механизм.

В Claude Code я передаю нужные файлы явно. Перед началом такой проверки можно свериться с разбором работы Claude Code над проектом:

Разбери изменение, код не меняй.
Прочитай @src/auth/login.ts, @src/auth/session.ts и @tests/auth/login.test.ts.
Сначала перечисли зависимости между файлами.

Такой запрос задаёт границу проверки. Агент не получает расплывчатую задачу «посмотри весь проект», а работает с названными файлами.

Для управления контекстом я задаю пять вопросов:

1. Что попросили сделать?
2. Какие правила действуют?
3. Какие файлы прочитаны?
4. Что вернули инструменты?
5. Что именно модель предлагает изменить?

Если на один вопрос нет ответа, я останавливаюсь и не принимаю правку автоматически.

У Claude Code есть отдельная проверка загруженных файлов инструкций:

/memory

Команда показывает, какие CLAUDE.md и CLAUDE.local.md попали в текущую сессию. Если нужного файла в списке нет, его содержание не доступно модели как инструкция этой сессии.

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

Одна и та же строка кода поэтому может вести себя по-разному в двух местах. Не потому, что строка изменилась. Изменилось окружение вокруг неё.

Из чего складывается контекст программы?

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

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

История сообщений. Сюда входят твои запросы и ответы Claude. Предыдущий ответ не исчезает сразу. Он может стать входом для следующего хода.

Изображения и документы. Они тоже занимают место в запросе. Контекст не ограничен обычным текстом.

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

Ответы модели. Сгенерированный текст становится частью дальнейшей истории. Extended thinking тоже учитывается в размере хода и контекстного окна.

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

CLAUDE.md. Файлы с таким именем загружаются в начале сессии. Они занимают место рядом с диалогом. В них часто лежат правила проекта, команды запуска и ограничения для агента.

Auto memory. Это отдельный способ переносить знания между сессиями Claude Code. Новая сессия ИИ-агента получает свежий контекст, а устойчивые сведения могут попасть туда через CLAUDE.md и auto memory.

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

Я бы различал рабочую историю и сохранённое решение:

• рабочая история нужна текущему ходу;
• CLAUDE.md хранит устойчивые правила;
• auto memory переносит отдельные знания между сессиями;
• журнал изменений хранит человеческие решения и проверки.

Это разные вещи. Резюме после compaction помогает модели продолжить работу. Оно не заменяет журнал, в котором записано, почему конкретная правка принята.

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

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

Как перепечатать изменение и не потерять смысл?

1. Попроси небольшой фрагмент.

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

   В первоисточнике этот режим описан прямо:

   «Я прошу помощника по программированию сгенерировать код в чате, а затем сам вручную вношу все изменения».

   • Анкур Сети, Prevent cognitive debt by manually retyping LLM-generated code

   Используй такой промпт:

   Сначала объясни, потом предложи небольшой фрагментСкопировать промпт

   Прочитай только указанные файлы и не меняй проект.
   
   Задача: добавить одно небольшое изменение.
   Сначала:
   1. назови файл и место изменения;
   2. объясни, какие данные и зависимости использует фрагмент;
   3. покажи только нужный код;
   4. перечисли, что проверить после переноса.
   
   Не создавай, не редактируй, не перемещай и не удаляй файлы.
   Не запускай команды, которые меняют файлы, зависимости или состояние проекта.

2. Получи объяснение до кода.

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

   Я не принимаю предложение, если не понимаю три вещи: что оно меняет, откуда берёт данные и что должно произойти после выполнения.

3. Перенеси код руками.

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

   Автор первоисточника объясняет эффект так:

   «Пока я вручную набираю каждую строку кода, созданного LLM, я строю мысленную модель того, как он работает и как вписывается в существующую кодовую базу».

   • Анкур Сети, Prevent cognitive debt by manually retyping LLM-generated code

   Здесь нет обещания максимальной скорости. Автор связывает ручную перепечатку с тем, что ответственность за каждую строку остаётся у человека.

4. Адаптируй код к проекту.

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

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

   Для проверки оставь запускаемое состояние проекта после переноса. Так связь между изменением и результатом можно проверить отдельно.

5. Запиши принятое решение.

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

   markdown

   Скопировать

   # Журнал изменений
   
   ## Дата и задача
   
   - Источник:
   - Файл или фрагмент:
   - Что изменилось:
   - Почему выбран этот вариант:
   - Что теперь понятно:
   - Как проверил:
   - Результат:

   Журнал не должен превращаться в копию всего диалога. Запиши только принятое решение и наблюдаемый результат. Если решение потеряется после новой сессии или compaction, этот файл останется внешним носителем контекста.

6. Выполни проверку.

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

   Проверка в журнале должна быть конкретной:

   Скопировать

   Проверка: запустил сценарий с существующим значением и сценарий с неизвестным значением.
   Результат: оба сценария дали ожидаемый ответ.

   Не пиши «всё работает» без результата команды или описанного сценария. Фактура не даёт универсального чек-листа качества, поэтому я не буду притворяться, что один список подходит для любого проекта. Минимум здесь один: проверить именно то поведение, ради которого переносился код.

7. Остановись после одного изменения.

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

   Если агент предлагает переписать большую часть проекта, верни его к границе задачи:

   Верни изменение к одному фрагментуСкопировать промпт

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

Что меняется, когда меняется контекст?

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

Ты добавил инструкцию. Она заняла место в запросе.

Ты передал файл. В следующем ответе появился новый источник данных.

Ты запустил команду. В историю добавился её результат.

Ты получил ответ Claude. Он стал частью следующего хода.

Anthropic описывает этот цикл так: после действия инструмента программа добавляет ответ Claude и результат инструмента в историю, затем отправляет новый запрос.

Поэтому изменение контекста не всегда означает изменение исходного кода. Иногда меняется только то, что доступно следующему ответу.

Пример с проектными инструкциями. Если в истории есть правило «не меняй файлы», а потом появляется другая инструкция с просьбой применить правку, агент получает конкурирующие указания. Инструкции проекта тоже занимают место рядом с историей диалога и могут менять объём доступного контекста.

Пример с thinking tokens. Длинное рассуждение учитывается в лимитах хода и контекстного окна. Чем больше места занято таким ответом, тем меньше его остаётся для кода и следующих ходов.

Я бы разбирал неожиданную правку в таком порядке:

1. Что добавилось после предыдущего ответа?
2. Какой файл или результат инструмента появился?
3. Не изменилась ли инструкция проекта?
4. Не произошёл ли compaction?
5. Не стало ли thinking tokens больше, чем в прошлый ход?

После этого сравнивай не только два куска кода. Сравни два набора входных данных.

Программа реагирует на изменившееся состояние. Ассистент реагирует на изменившуюся историю, инструкции и результаты инструментов. В обоих случаях новый результат начинается с нового окружения.

Что ломается без полного контекста?

Решения между Claude.ai и Claude Code. Контекст Claude.ai не переносится автоматически в Claude Code. Если решение важно для проекта, я сохраняю его в PLAN.md или DECISIONS.md, как в схеме журнала решений между сессиями.

Фраза «запомни» тоже не означает запись на диск. Постоянные правила я кладу в CLAUDE.md, а состояние проекта храню в STATUS.md.

Минимальная запись выглядит так:

# Решения

- Используем pnpm вместо npm.
- Следующее изменение вручную внести в middleware.
- После переноса проверить сценарий с пустым токеном.

Инструкции после /compact. Инструкция, оставленная только в чате, может потеряться после сжатия. Корневой CLAUDE.md переживает compaction, но вложенные инструкции не переинъектируются автоматически.

Перед сжатием укажи, что сохранить:

/compact keep the current plan, accepted changes, rejected approaches, test output, and the next manual edit

Критичное решение всё равно запиши в файл. Резюме модели не заменяет внешний журнал.

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

Неподходящий файл инструкций. CLAUDE.md может лежать на диске, но не загружаться в текущую сессию. Проверь рабочую директорию и выполни /memory.

Если контекст потерялся, не пытайся чинить результат новым длинным сообщением. Сначала зафиксируй имя контекста и восстанови опорные данные: Сначала восстанови опорные данные:

1. найди журнал решений;
2. передай нужные файлы;
3. повтори правило коротко;
4. попроси объяснить текущий код без изменений;
5. только потом запроси следующий фрагмент.

Так случайная правка превращается в проверяемое продолжение работы.

Что делать, если контекст стал слишком большим?

Есть два разных сбоя.

Если вход уже слишком большой, API отклоняет запрос с ошибкой:

400 invalid_request_error
prompt is too long

Если запрос принят, но генерация упирается в предел, ход останавливается с причиной:

model_context_window_exceeded

Не путай эти случаи. В первом надо уменьшить вход до отправки. Во втором генерация дошла до ограничения уже во время хода.

Сначала проверь состав запроса, а для длинной сессии используй схему разделения запроса на этапы:

• системные инструкции;
• историю сообщений;
• изображения и документы;
• определения инструментов;
• ответы Claude;
• результаты инструментов;
• thinking tokens;
• добавленные файлы.

Токен тоже занимает место в контекстном окне, а кэш не расширяет это окно. Он сохраняет префикс конкретного запроса, но закэшированные токены всё равно занимают место в контекстном окне. Поэтому фраза «кэш включён, лимит больше не важен» ошибочна.

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

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

Вопросы и ответы