ИИ тихо стёр блок отправки отчёта. Три недели никто этого не заметил

Попросил ИИ-сессию немного причесать один из моих рабочих скриптов — убрать дублирование, привести код к единому стилю. Задача заняла пять минут, я бегло проверил результат по диагонали, всё выглядело чище прежнего. Через три недели заметил, что еженедельный отчёт по одной из зон перестал приходить. Не сломался с ошибкой — просто перестал отправляться, молча. При «причёсывании» блок отправки посчитали дублирующим кодом и убрали, потому что рядом было почти такое же по виду условие для другого отчёта.

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

Как было

У меня несколько отдельных ИИ-сессий на разные скрипты, и в начале задачи я обычно коротко объясняю контекст заново: что делает файл, что нельзя трогать, какие блоки критичны. Проблема в том, что «коротко объясняю» каждый раз означает немного по-разному: что-то забываю упомянуть, что-то формулирую иначе, чем в прошлый раз. Сессия, которая причёсывала код, честно не знала, что один из блоков — это не внутренняя логика расчёта, а точка, где результат уходит наружу, и её нельзя трогать ни при каком рефакторинге, даже если код выглядит избыточным.

Что сделал

Завёл в проекте отдельный файл с инструкциями, который любая новая ИИ-сессия обязана прочитать первым делом, прежде чем что-то менять в коде. Здесь было легко ошибиться на старте: моя первая версия такого файла была описанием того, что скрипт делает — списком функций и их назначения. Полезно для понимания, но бесполезно для защиты от инцидента вроде этого: файл-описание рассказывает, как код устроен сейчас, а не что с ним нельзя делать. Он не запрещает ничего — он просто информирует, и информация проходит мимо, если сессия сочтёт код избыточным.

Переписал файл как инструкцию, а не как выжимку. Разница не в объёме, а в глаголах: не «функция X отправляет отчёт в Telegram», а «этот блок нельзя удалять, переносить в другую функцию или объединять с похожими условиями — даже если он выглядит как дублирование». Файл-выжимка описывает состояние. Файл-инструкция запрещает действия.

Промт, который сработал:

Перед тем как менять что-либо в этом файле, прочитай CONTEXT.md в этой же папке и следуй его правилам без исключений. Если в CONTEXT.md сказано "не трогать" — не трогай, даже если код выглядит как дублирование, устаревший или неоптимальный. Если хочешь предложить изменение защищённого блока — не изменяй его сам, а напиши мне отдельным пунктом, что именно предлагаешь и почему, и жди подтверждения. После любого изменения в этом файле явно перечисли: какие блоки из списка "не трогать" в CONTEXT.md ты не редактировал — подтверди построчно, а не одной фразой "всё в порядке".

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

Честно про минусы

Файл с инструкциями сам может устареть. Если я добавлю новый критичный блок в код и забуду занести его в CONTEXT.md — защиты не будет, а ощущение защищённости останется, что хуже, чем полное отсутствие файла: без файла я хотя бы был осторожен сам.

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

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

Дальше — Цифры склада: официальный объём склада и реальная вместимость — две разные цифры.

У вас есть похожий файл с инструкциями для ИИ-сессий в рабочих проектах, или каждый раз объясняете контекст заново? Что из него оказалось нужнее всего на практике?

В Telegram выложил структуру этого файла — какие разделы в нём обязательны, а какие лишние: t.me/ii_na_skladah