В сообществе разработчиков активно обсуждают файл CLAUDE.md, который, по слухам, использует сам Андрей Карпати (Andrej Karpathy) — легенда мира AI и один из создателей OpenAI и Tesla Autopilot. После того как Карпати перешел в Anthropic, его активность в опенсорсе снизилась, но страсть к обучению осталась.

Этот документ — не просто набор советов, а жесткий свод правил для ИИ, который превращает Claude из своенравного «стажера» в идеального напарника.

Что такое CLAUDE.md?

Это специальный конфигурационный файл в корне проекта, который ИИ-ассистент считывает перед началом работы. Карпати (или авторы, вдохновленные его подходом) утверждает: нейросети совершают предсказуемые ошибки не случайно, а потому, что им не хватает контекста и рамок.

Вот основные принципы «правильного» взаимодействия с Claude, описанные в материалах:

1. Сначала читай, потом пиши

Самая частая ошибка ИИ — генерация кода без учета существующей базы.

Правило: перед правкой файла Claude обязан прочитать его целиком, изучить используемые библиотеки и стиль (например, если в проекте используется fetch, нельзя предлагать axios).

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

2. Думай до начала кодинга

Если задача звучит размыто (например, «добавь авторизацию»), Claude не должен гадать.

Правило: ИИ обязан проговорить свои предположения. «Я предполагаю, что нужен JWT в httpOnly cookie, это так?».

Выбор: если есть несколько решений, Claude должен предложить максимум 2-3 варианта с описанием плюсов и минусов, прежде чем писать сотни строк кода.

3. Борьба с «оверинжинирингом»

ИИ обожает усложнять. Вместо одной функции он может построить целую иерархию классов «на будущее».

Правило: писать минимально необходимый код для текущей задачи. Никаких абстрактных классов для одного наследника или обработки ошибок, которые никогда не возникнут. «На случай, если понадобится потом» — это не аргумент.

4. Хирургическая точность

Правки должны быть минимальными. Это упрощает код-ревью и сохраняет историю Git в чистоте.

Правило: не трогай то, о чем не просили. Видишь опечатку в соседней функции? Оставь её. Твоя задача — починить конкретный баг, а не переформатировать весь файл под свой вкус.

5. Тесты как доказательство

«Код работает» и «Ты думаешь, что код работает» — разные вещи.

Правило: сначала пишется тест, воспроизводящий баг. Затем — фикс. Затем — проверка. Это единственный способ доказать, что проблема решена.

6. Отказ от галлюцинаций и лишних зависимостей

Зависимости: не добавлять новые библиотеки без веской причины. Если задачу можно решить стандартными средствами языка — делай это стандартно.

Отладка: не гадать, почему код упал, а внимательно читать весь стек ошибок. Если Claude не уверен в API библиотеки, он должен признать это и посмотреть документацию, а не выдумывать методы.

Почему это важно?

Несмотря на то, что подлинность конкретного файла вызывает споры, его содержание на 100% отражает философию Карпати о «Vibe Coding» (программировании на уровне идей и атмосферы). По данным тестеров, использование подобных инструкций снижает уровень ошибок Claude с 41% до 11%.

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