Контекст в кеше, а не в кошельке: как платить за токены вдвое меньше на одном проекте

Вы пишете сервис аутентификации. Третий день подряд открываете новый диалог с нейросетью, вставляете туда кусок кода проверки пароля и просите: «Проверь уязвимости». Модель честно тратит время и ваши деньги (токены — это оплачиваемые порции текста) на то, чтобы заново понять ваш стек, структуру папок монорепозитория (проекта, где весь код лежит в одной огромной директории), правила оформления коммитов (записей об изменениях в коде) и формат контрактов API (описаний того, как фронтенд общается с бэкендом). Она делает эту работу по въезду в контекст сотни раз, пока вы правите одну функцию. В чеке провайдера это выглядит так: первые полминуты диалога стоят дороже всего остального дня вместе взятых.

Шаг 1. Что именно пересчитывает модель без кеша (и почему мы платим дважды)

Когда вы присылаете фрагмент кода, языковая модель сначала строит граф зависимостей. Ей нужно выяснить, откуда прилетает объект user, какие поля у него хешируются, какая библиотека отвечает за соль (случайную добавку к паролю для защиты от взлома), есть ли лимит попыток входа. Без общей рамки она гадает по именам переменных. Если вчера вы называли сущность UserEntity, а сегодня написали AuthUser, для машины это два разных мира. Она бросает оплаченные вычисления на сопоставление типов, перечитывает импорты (подключения внешних библиотек) и пытается восстановить архитектуру из обрывков. Это не просто медленнее — это прямой перевод ваших денег в тепло серверов провайдера. Вы покупаете один и тот же билет на трамвай десять раз подряд, потому что каждый раз заходите через новую дверь и не показываете проездной.

Шаг 2. Как работает переиспользование: знакомое начало подхватывается мгновенно

Современные платформы держат в памяти сессии активный граф смыслов. Если первые 8–15 строк вашего нового сообщения совпадают с тем, над чем модель уже работала, провайдер цепляется за готовый след. Ему не нужно снова собирать карту звездного неба, он сразу встает на проложенный маршрут. Технически это похоже на компиляцию: первый билд (сборка программы) длится пять минут, а инкрементальная пересборка после смены одной строчки занимает две секунды. Чтобы этот механизм включился, ему нужен стабильный якорь. Соберите блок ровно на 8–15 строк. Не больше, иначе модель начнет путаться в приоритетах, и не меньше, иначе зацепиться будет не за что. Положите его в заметки или сниппет (шаблон) вашей среды разработки: — Стек: Go 1.22, PostgreSQL 16, Gin, gRPC, Protocol Buffers v3. — Монорепо: /services/auth, /shared/models, /proto/contracts. — Кодстайл: табуляция, линтер revive, no panic in lib, context timeout 5s. — Формат коммита: feat(auth): add rate limit per IP [AUTH-104]. — Где лежат контракты: /proto/contracts/v1/auth.proto, тег auth-service. Копируйте эти строки самым первым сообщением в каждом новом чате про авторизацию. Модель увидит знакомые сигнатуры функций (заголовки методов), поймет расположение файлов и перестанет тратить токены на вопросы формата «где у вас хранится конфигурация?». Ответы начнут приходить почти мгновенно, потому что машина пропускает фазу разведки.

Шаг 3. Проверяем механику на себе: ставим честный эксперимент на неделю

Теория теорией, но нам нужны цифры со счета. С понедельника заводим правило: любой диалог про сервис аутентификации начинается строго с этого блока контекста. Чтобы замер был чистым, фиксируем базу. За прошлую неделю выгрузите статистику из личного кабинета провайдера: сколько ушло на input tokens (текст, который даете вы) и output tokens (текст, который генерирует ассистент) именно по этому проекту. Запишите среднее время генерации первого ответа до появления основного тела решения — обычно оно плавает от 8 до 15 секунд на холодном старте. На этой неделе повторяете те же задачи: ревью тех же фрагментов, написание тех же тестов, рефакторинг той же функции сброса пароля. Но теперь всегда с якорем. Через семь дней сравните отчеты. При сохранении объема работы ориентир падения затрат — минус 30–60% при том же количестве закрытых задач. Время первого отклика сократится до 1–3 секунд. Если экономия составила только 10%, значит, ваш контекст слишком короткий или меняется от чата к чату хотя бы на одно слово — проверьте, нет ли там динамических дат или случайных ID.

Шаг 4. Почему стиль кода перестает плыть и исчезает дрейф инструкций

Третья боль любого долгостроя — ассиметрия знаний. Вчера вы договорились писать обработку ошибок через errors.Wrap, сегодня модель предложила использовать fmt.Errorf, завтра вообще вернула панику (аварийную остановку программы). Каждый новый чат — это амнезия. Модель забывает негласные договоренности команды, если они не зафиксированы прямо перед глазами. Вшитые в самое начало 15 строк работают как конституция микросервиса. Когда там написано «обработка ошибок только через pkg/errors, никаких логов внутри бизнес-логики», модель держит этот паттерн неделями. Единый стиль держится сам собой, количество итераций «переделай, ты опять написал логгер внутри репозитория» падает практически до нуля. Вам больше не нужно быть нянькой для искусственного интеллекта и ловить его на нарушении собственного дизайн-документа (главного описания архитектуры).

Главные грабли, которые убьют всю экономию

Первое — перфекционизм. Если вы начнете дополнять контекст историей создания компании, философией REST и мемуарами прошлого релиз-инженера, модель решит, что это новая задача, построит свежий граф и кеш (временное хранилище данных для быстрого доступа) аннулируется. Только сухие факты о текущем сервисе. Второе — мусор в начале. Никогда не начинайте сообщение с приветствия («Привет, помоги»), даты или системного вывода терминала вроде bash-5.1$. Любой лишний символ сдвигает окно совпадений, провайдер считает, что это другой разговор, и начинает считать с нуля. Третье — смешение проектов. Решили быстро спросить про скрипты деплоя (развертывания) в середине диалога про авторизацию? Создайте отдельный файл контекста для деплоя. Смешивание двух архитектур в одном флаконе ломает предсказуемость графа, модель начинает метаться между ветками, скорость падает, а стоимость растет обратно.

Завтра утром создайте один текстовый файл project-auth-context.txt. Напишите в него ровно 12 строк описанного выше каркаса. Закиньте путь к нему в избранное вашего редактора. Перед каждым рабочим созвоном с нейросетью копируйте эти 12 строк в начало окна. Неделю работайте только так. В пятницу вечером откройте вкладку Billing (Счета) и посмотрите на разницу. Эти сэкономленные рубли переведите на общий счет команды — вы их честно не прокурили на лишнюю распаковку одного и того же архива.