Андрей Жаров, iOS-разработчик компании Doubletapp, опубликовал на Habr подробный разбор того, как управлять контекстным окном при ежедневной работе с локальными ИИ-агентами. Материал вырос из практики: автор заметил, что вежливые развёрнутые инструкции в духе «Please carefully analyze the project» работают хуже коротких телеграфных команд — и объяснил, почему это так устроено.
В основе подхода лежит разделение контекста на три слоя. Первый — постоянные правила: архитектурные решения, границы безопасности, предпочтительные инструменты. Второй — рабочий набор конкретной задачи: несколько файлов, дифф, фрагмент лога, скриншот, ссылка на документацию. Третий — шумные эпизодические данные: длинные логи, промежуточные tool outputs, большие таблицы, поисковая выдача. Проблема возникает, когда все три слоя сваливаются в один промпт: агент тратит токены на разбор мусора вместо решения задачи.
| Тип done-критерия | Пример | Оценка |
|---|---|---|
| Хороший | test passes | Объективен, проверяем автоматически |
| Хороший | no errors | Объективен, однозначен |
| Хороший | ui matches design | Проверяем визуально |
| Плохой | сделай хорошо | Субъективен, агент угадывает |
| Плохой | чтобы не сломалось | Размыт, нет критерия проверки |
| Плохой | сам поймёшь | Перекладывает понимание на агента |
Почему краткость работает технически. Нейросеть читает токены последовательно, слева направо. Академическая работа Lost in the Middle зафиксировала эффект: модели хуже используют информацию, спрятанную в середине длинного контекста. Из этого следует практическое правило — важные данные кладут в начало, вопрос или задачу — в конец. Кроме того, развёрнутые вежливые конструкции («Please, say to me, is our code okay?») требуют дополнительного парсинга: модель должна отбросить воду и добраться до смысла. Короткий вариант («code is okay?») передаёт тот же смысл за меньшее число токенов.
Для структурирования команд Жаров предлагает минималистичный шаблон с полями Task, Done, Context, Rules и If stuck. Пример из статьи:
Task: fix empty password validation in AuthScreen Done: AuthViewModelTests pass + new empty password test Context: AuthScreen.swift, AuthViewModel.swift, AuthViewModelTests.swift Rules: don't change backend API, don't touch registration, minimal patch If stuck: ask with exact blocker
Формат не обязателен дословно — автор подчёркивает, что важна сама идея: команда пишется для машины, а не для коллеги. Русскоязычные инструкции работают по тем же правилам: «почини валидацию пустого пароля / готово = тест проходит / API не менять / если непонятно → спроси».
Отдельный блок посвящён done-критериям. Без чёткой проверки завершения агент сам решает, когда остановиться, — и нередко продолжает «улучшать» соседние части кода, которых никто не трогал. Хорошие критерии объективны и проверяемы: «test passes», «no errors», «ui matches design». Плохие — субъективны: «сделай хорошо», «чтобы не сломалось». Жаров формулирует это жёстко: не учите агента понимать задачу за вас, поймите её сами и опишите ему.
Тот же принцип применяется к стартовым координатам. Вместо «где-то в auth сломалась кнопка, посмотри проект» — конкретные файлы и гипотеза: «Bug: login button stays disabled / Start here: AuthScreen.swift, AuthViewModel.swift». Агент всё равно может расширить поиск, если стартовая гипотеза не подтвердилась, но не начинает с хаотичного обхода всего репозитория. Это сокращает объём чтения и уменьшает шум в контексте.
Подход Жарова вписывается в более широкую дискуссию об эффективности prompt engineering при работе с кодовыми агентами — такими как Cursor, Aider или локальные решения на базе open-source LLM. Разница между «умным промптом» и «инфраструктурой контекста» становится заметной именно в длинных сессиях: когда задача занимает не один запрос, а десятки итераций, накопленный шум в окне начинает деградировать качество ответов. Контекстная гигиена — это не разовый приём, а постоянная практика управления тем, что агент видит в каждый момент времени.