Karpathy CLAUDE.md, объяснение: один файл, стоящий за поиском навыков

В Google Trends во всём мире за последние семь дней, по состоянию на 23 октября 2026 года, «karpathy skills» отображается как растущий запрос под исходным запросом «claude skills». Любой, кто переходит по этому поиску, попадает в одно и то же место: github.com/multica-ai/andrej-karpathy-skills — репозиторий, у которого на GitHub было 222 612 звёзд по состоянию на 23 октября 2026 года. В его описании вообще нет слова skill. Там написано: «Один файл CLAUDE.md для улучшения поведения Claude Code, основанный на наблюдениях Andrej Karpathy о подводных камнях программирования с LLM».

Разрыв между запросом и объектом — не мелкая техническая деталь. Навык и файл CLAUDE.md — это разные механизмы, которые выполняют разную работу, и почти каждое утверждение, которое люди делают об этом репозитории, либо зависит от понимания того, о каком именно механизме идёт речь, либо молча предполагает не тот. Само руководство внутри — это один файл. Репозиторий вокруг этого файла также содержит манифест плагина и папку в каталоге skills — вероятно, именно оттуда берётся слово в строке поиска. Отделить упаковку от полезной нагрузки — первый полезный шаг здесь.

Цифры, все с GitHub, по состоянию на 23 октября 2026 года: 222 612 звёзд, 22 321 форк, создан 27 января 2026 года, последний push — 20 апреля 2026 года, лицензия MIT. Последняя пара — самое интересное. Репозиторий не получал push примерно шесть месяцев, а количество звёзд всё равно продолжало расти.

Файл выполняет работу; упаковка объясняет поисковый запрос.

Откройте репозиторий — и по списку файлов несоответствие сразу бросается в глаза. В корне есть CLAUDE.md, а рядом с ним CURSOR.md, EXAMPLES.md, папка .cursor/rules, содержащая те же рекомендации в виде правила проекта Cursor, папка .claude-plugin и каталог skills/karpathy-guidelines. Рекомендуемый в README способ установки — через маркетплейс плагинов, и там сказано, что в результате «навык становится доступным во всех ваших проектах».

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

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

Жалобы, против которых это было написано

В README указано, что источник — пост Андрея Карпати в X, который README цитирует в связи с тремя жалобами на то, как модели пишут код. Их стоит прочитать полностью, потому что четыре принципа соотносятся с ними почти один к одному.

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

Второе: они «очень любят усложнять код и API, раздувать абстракции, не чистят мёртвый код… пишут раздутую конструкцию более чем на 1000 строк, когда хватило бы 100». Это знакомо каждому, кто просил функцию, а получил фреймворк.

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

Четыре принципа — и проверка, которую каждый из них оставляет после себя

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

Думай, прежде чем писать код

Инструкция в заголовке звучит так: «Не делайте допущений. Не скрывайте замешательство. Выявляйте компромиссы». Под ней: явно формулируйте допущения и спрашивайте, а не угадывайте; при неоднозначности запроса предлагайте несколько интерпретаций; возражайте, если существует более простой подход; останавливайтесь при замешательстве, называйте, что именно непонятно, и просите уточнений. Это направлено прямо на первую жалобу. Механизм здесь не «быть внимательнее» — он состоит в превращении молчаливых решений в видимые, чтобы рецензент мог не согласиться до появления кода, а не после.

Простота прежде всего

Правило — минимум кода, решающего задачу, без ничего спекулятивного: никаких функций сверх запрошенного, никаких абстракций для одноразового кода, никакой гибкости или настраиваемости, которую никто не просил, никакой обработки ошибок для невозможных сценариев, и «если 200 строк можно свести к 50, перепишите это». Проверка — один вопрос: сказал бы старший инженер, что это переусложнено? — и это вопрос суждения, причём открыто.

Хирургические изменения

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

Целеориентированное исполнение

Определите критерии успеха и повторяйте цикл, пока результат не будет подтверждён. В README это преобразование показано в виде пар. Вместо «добавить валидацию» напишите тесты для некорректных входных данных, а затем добейтесь их прохождения. Вместо «исправить ошибку» напишите тест, воспроизводящий её, а затем добейтесь его прохождения. Вместо «отрефакторить X» убедитесь, что тесты проходят до и после. Для многошаговой работы предлагается краткий план, в котором каждый шаг называет собственную проверку. Здесь README снова цитирует Karpathy: «LLM исключительно хорошо умеют работать в цикле, пока не достигнут конкретных целей… Не говорите им, что делать, дайте им критерии успеха и наблюдайте, как они действуют».

Файл, навык и плагин — это три разные вещи.

Стоит уточнить, как именно всё устроено, поскольку практическое поведение различается. CLAUDE.md — это файл инструкций проекта: текст, который Claude Code читает как постоянный контекст репозитория и который присутствует независимо от того, запрашивал ли его кто-либо в текущем ходе. Навык (skill) — это папка с файлом SKILL.md, в котором описано, когда следует использовать эту возможность; он загружается, когда задача этого требует, и не раньше. Плагин — это распространяемый пакет, устанавливаемый через маркетплейс, который может содержать навыки, команды и другие компоненты. Различия касаются того, когда инструкции попадают в контекст и кто принимает решение, а не качества.

CLAUDE.md в этом смысле — самый прямолинейный из трёх. Он всегда включён в этом проекте, применяется к каждой задаче в нём и занимает контекст при каждом обращении, будь то исправление опечатки в одной строке или миграция. README самого файла признаёт эту цену в разделе под названием Tradeoff Note: рекомендации смещают баланс в сторону осторожности, а не скорости, и в тривиальных задачах — простых исправлениях опечаток, очевидных однострочниках — следует руководствоваться здравым смыслом. Там говорится, что цель — сократить дорогостоящие ошибки в нетривиальной работе, а не замедлить простые задачи.

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

Что измеряют 222,612 звёзд

Они измеряют внимание. Это не отмашка и не пустяк: репозиторий, созданный в январе 2026 года и последний раз обновлённый в апреле, к 23 октября 2026 года на GitHub — по данным, прочитанным в тот день, — набрал 222 612 звёзд и 22 321 форк, а значит, им широко делились и его форкали люди, желавшие получить собственную копию. Количество звёзд — разумный приблизительный показатель того, скольким людям нечто показалось достойным закладки.

Это не замена доказательству эффекта, и репозиторий не делает вид, что это не так. В нём нигде не опубликовано: ни бенчмарков, сравнивающих результаты с файлом и без него, ни методологии измерения того, работает ли он, ни сравнения с контрольной группой. Нет ни сравнения «до и после» на реальной кодовой базе, ни исследования с рецензентами, ни статистики инцидентов. Такой файл — это изящно сформулированная гипотеза о поведении модели, и никто не провёл эксперимента.

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

Что вы на самом деле вводите, чтобы установить это

В README описаны два пути. Рекомендуемый выполняется внутри Claude Code: добавьте маркетплейс, затем установите плагин, после чего руководства будут доступны во всех проектах, а не в каждом репозитории отдельно. Второй — на уровне проекта: загрузите исходный CLAUDE.md в новый репозиторий или добавьте его в существующий. Есть также закоммиченное правило проекта Cursor, поэтому те же руководства применяются при открытии папки в Cursor — деталь, которая показывает, что файл написан переносимым между инструментами, читающими файл инструкций уровня проекта, а не привязан к загрузчику одного вендора.

Одна шероховатость, о которой стоит предупредить, потому что вы на неё наткнётесь, если будете следовать README в точности. Команда маркетплейса называется forrestchang/andrej-karpathy-skills, а URL репозитория в верхней части страницы — multica-ai/andrej-karpathy-skills. Обе строки встречаются в одном и том же README, прочитанном 23 октября 2026 года. Я вижу это несоответствие и не могу сказать, почему оно возникло, поэтому честный совет — попробовать другой путь, если один не сработает, и считать одну из двух строк устаревшей.

Еще одна вещь, на которую стоит обратить внимание на главной странице: репозиторий поддерживается multica-ai, а вступительная цитата в README рекламирует Multica — «открытую платформу для запуска и управления агентами для программирования с переиспользуемыми навыками». Это законное раскрытие информации, а также подсказка о том, почему упаковка выглядит именно так. Проект, заинтересованный в переиспользуемых навыках, скорее всего, будет поставлять собственное руководство в виде чего-то устанавливаемого — чем и является плагин.

Использовать это, не наследуя его допущения

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

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

И провести его аудит вам действительно стоит. Это короткий документ с поведенческими инструкциями, который будет применяться к каждому запросу в репозитории. Правильный вопрос не в том, могут ли 222 612 человек ошибаться — такая постановка ничего не решает, — а в том, соответствует ли каждое правило сбою, который вы действительно видели. Если в ваших диффах никогда не было попутных переписываний комментариев, раздел «Surgical Changes» напрасно расходует ваш контекст. Удалите его. Файл распространяется по лицензии MIT и предназначен для редактирования.

Уровнем ниже всё это не меняет того, какая модель отвечает. Файл CLAUDE.md определяет, как обрабатывается запрос, когда он попадает к модели; он ничего не говорит о том, какая модель его получает. Это второе решение принимает то, что стоит перед моделью. Один из способов организовать это — единая конечная точка, совместимая с OpenAI, которая предоставляет более 200 моделей по одному ключу, с автоматическим переключением при сбое между провайдерами и передачей цен из прайс-листов провайдеров без наценки — 0%. Мы размещаем модели; мы не создаём Claude Code, и нам не видно ничего в вашем репозитории.

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