Оригинальный заголовок: Правила Karpathy’s 4 CLAUDE.md сокращают ошибки Claude с 41% до 11%. После 30 кодовых баз я добавил еще 8
Автор оригинала: @Mnilax
Перевод: Peggy, BlockBeats

Редакторский комментарий: В январе 2026 года Анджей Карпати высказал критику по поводу написания кода Claude, что привело к появлению файла, казалось бы, очень небольшого, но крайне важного в рабочем процессе AI-программирования: CLAUDE.md. Forrest Chang затем систематизировал эти проблемы в 4 поведенческих правила, пытаясь ограничить распространенные ошибки Claude при кодировании: молчаливые предположения, чрезмерная сложность, случайное повреждение несвязанных участков кода и отсутствие четких критериев успеха.

Но через несколько месяцев сценарии использования Claude Code уже перестали ограничиваться «позволить модели написать фрагмент кода». С появлением многошаговых агентов, цепочек hook, загрузки навыков и совместной работы с несколькими репозиториями, начали возникать новые модели сбоев: модель теряет управление в длинных задачах, проходит тесты, но не проверяет реальную логику, после миграции тихо пропускает ошибки, а разные стили кода ошибочно смешиваются.

Автор статьи за 6 недель протестировал 30 кодовых баз и на основе оригинальных 4 правил Карпати добавил еще 8 правил, чтобы покрыть новые проблемы, возникшие при переходе от одиночных дополнений к агентной кооперации в AI-программировании.

Ниже — оригинальный текст:

В конце января 2026 года Анджей Карпати опубликовал серию твитов, в которых высказал недовольство подходом Claude к написанию кода. Он выделил три типичных проблемы: ошибочные предположения без объяснений, чрезмерную усложненность и нанесение вреда коду, который не должен был изменяться.

Forrest Chang увидел эти твиты, систематизировал жалобы в 4 правила поведения, записал их в отдельный файл CLAUDE.md и разместил на GitHub. Этот проект за первый день получил 5828 звезд, за две недели — 60 000 закладок, а сейчас — 120 000 звезд, став самым быстрорастущим одностраничным репозиторием в 2026 году.

Затем я за 6 недель протестировал его на 30 кодовых баз.

Эти 4 правила действительно работают. Ошибки, которые раньше возникали примерно с вероятностью 40%, в задачах, где эти правила применимы, снизились до менее 3%. Но проблема в том, что изначальный шаблон предназначался для исправления ошибок, возникавших при написании кода Claude в январе.

К маю 2026 года экосистема Claude Code столкнулась с иными проблемами: конфликты между агентами, цепочки hook, конфликты загрузки навыков и прерывания многопроцессных рабочих потоков между сессиями.

Поэтому я добавил еще 8 правил. Ниже — полный набор из 12 правил для CLAUDE.md: почему каждое правило важно и в каких 4 местах оригинальный шаблон Карпати может тихо потерять эффективность.

Если хотите пропустить объяснения и сразу использовать, весь файл — в конце статьи.

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

CLAUDE.md в экосистеме AI-программирования — самый недооцененный файл. Большинство разработчиков совершают три типа ошибок:

Первое — воспринимать его как мусорную корзину предпочтений, засовывать туда все свои привычки, в результате получая более 4000 токенов, а уровень соблюдения правил падает до 30%.

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

Третье — скопировать шаблон и больше не следить за ним. Он может работать две недели, но при изменениях в кодовой базе со временем станет неактуальным.

Официальная документация Anthropic ясно говорит: CLAUDE.md — это рекомендация. Claude примерно в 80% случаев следует ей. Когда длина превышает 200 строк, уровень соблюдения заметно падает, потому что важные правила затмеваются шумом.

Шаблон Карпати решает эту проблему: один файл, 65 строк, 4 правила — это минимальный базовый уровень.

Но его можно улучшить. Добавив еще 8 правил, мы расширим охват не только проблем, о которых жаловался Карпати в январе 2026, но и новых сценариев, появившихся к маю 2026, — таких как оркестровка агентов, которых изначально не было в шаблоне.

Исходные 4 правила

Если вы еще не смотрели репозиторий Forrest Chang, начнем с базовой версии:

Правило 1: Перед кодированием подумайте.

Не делайте молчаливых предположений. Объясните свои предположения, укажите компромиссы. Перед тем как гадать, задайте вопрос. Если есть более простое решение — предложите его.

Правило 2: Простота превыше всего.
Используйте минимальный необходимый код. Не добавляйте ненужные функции. Не проектируйте абстракции для разовых задач. Если опытный инженер сочтет решение чрезмерно сложным — упростите.

Правило 3: Модификация по хирургическому принципу.
Меняйте только то, что обязательно нужно менять. Не оптимизируйте соседний код, комментарии или формат. Не рефакторите исправленное. Соблюдайте стиль существующего кода.

Правило 4: Действуйте по цели.
Сначала определите критерии успеха, затем итеративно проверяйте. Не говорите Claude, что делать на каждом шаге, — скажите, каким должен быть результат, и пусть он сам итеративно добивается его.

Эти 4 правила решают примерно 40% ошибок, которые я наблюдаю в неуправляемых сессиях Claude Code. Остальные 60% скрыты в следующих областях.

Почему я добавил еще 8 правил и зачем

Каждое правило основано на реальных сценариях: исходные 4 правила Карпати уже недостаточны. Ниже я расскажу о ситуации и дам соответствующее правило.

Правило 5: Не заставляйте модель выполнять неязыковые задачи

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

Правило Карпати не покрывало этот момент. В результате модель начала решать задачи, которые должны были обрабатываться детерминированным кодом: повторить API-запрос, маршрутизировать сообщение, решать, когда обновлять обработку. Итог — каждую неделю разные решения, а расходы на токены — около 0.003 доллара за токен, нестабильные.

Это было так: есть код, вызывающий Claude для «решения, стоит ли повторить при 503». Он работал две недели, потом стал нестабильным, потому что модель начала включать тело запроса в контекст. Стратегия повторов стала случайной, потому что prompt — тоже случайный.

Правило 6: Устанавливайте жесткий лимит токенов, без исключений

Бюджет по токенам на задачу: 4000.
Бюджет по токенам на сессию: 30000.
Если задача приближается к лимиту — подведите итоги, перезапустите. Не тяните. Четко обозначайте превышение бюджета, а не молча его превышайте.

Отсутствие лимитов — это как пустой чек. Каждая итерация может превратиться в «загружку» на 50 000 токенов, и модель не остановится сама.

Это было так: одна сессия длилась 90 минут. Модель бесконечно повторяла одни и те же ошибки в 8Кб логах, забывая, что уже пробовала. В конце она предлагала 40 решений, которые я уже отверг. Если бы был лимит — сессия бы завершилась на 12-й минуте.

Правило 7: Обнаруживайте конфликты, не усредняйте

Если в кодовой базе есть два противоречивых подхода — не смешивайте их. Выберите один, предпочтительно более новый или протестированный, объясните почему, отметьте другой для последующей очистки.
Попытка совместить два подхода — худший вариант.

Когда в коде есть противоречия, Claude пытается угодить обоим, что приводит к бессвязному коду.

Это было так: в базе есть два подхода обработки ошибок — асинхронный с try/catch и глобальный обработчик. Claude написал код, использующий оба, — ошибки перехватываются дважды. Мне пришлось 30 минут разбираться, почему ошибки исчезают дважды.

Правило 8: Читайте перед добавлением

Перед добавлением кода в файл — ознакомьтесь с экспортами, вызовами и общими утилитами.
Если не понимаете структуру — задайте вопрос, не добавляйте сразу.
«Это не связано» — опасная фраза.

«Хирургическая» модификация по Карпати учит не менять соседний код, но не учит сначала его понять. Без этого — новые функции могут конфликтовать с существующими.

Это было так: Claude добавил новую функцию, которая полностью дублировала существующую, потому что не ознакомился с оригиналом. В результате две функции делали одно и то же, а из-за порядка импортов новая перезаписала старую, которая уже полгода была единственным стандартом.

Правило 9: Тесты — не опция, а необходимость, но тесты — не цель

Каждый тест должен объяснять, почему важен этот сценарий, а не только что он проверяет.
Тест типа expect(getUserName()).toBe(‘John’) — бесполезен, если функция принимает жестко закодированный ID.
Если не можете написать тест, который сломается при изменениях — функция неправильная.

«Действуйте по цели» Карпати подразумевает, что тесты — критерий успеха. Но на практике Claude воспринимает «пройти тест» как единственную цель, пишет тесты, которые проходят, но при этом ломают логику.

Это было так: Claude написал 12 тестов для функции аутентификации, все прошли. Но в продакшене логика сломалась. Тесты лишь проверяли, что функция возвращает что-то, а не что именно. Функция проходила тесты, потому что возвращала константу.

Правило 10: Долгосрочные операции требуют контрольных точек

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

Шаблон Карпати предполагает однократное взаимодействие. В реальности же рабочие процессы Claude — многопроходные: рефакторинг из 20 файлов, построение функций в одной сессии, отладка через несколько коммитов. Без контрольных точек — ошибка на любом этапе может уничтожить весь прогресс.

Это было так: при 6-шаговой рефакторинге на 4-м шаге произошла ошибка. Когда я заметил — Claude уже выполнил 5-й и 6-й шаги, ошибочные. Исправление заняло больше времени, чем повторное выполнение всего задания. Если бы был контроль — ошибка на 4-м шаге обнаружилась бы сразу.

Правило 11: Конвенции важнее новшеств

Если в кодовой базе используется snake_case, а вы предпочитаете camelCase — используйте snake_case.
Если в проекте — классы, а вам нравятся хуки — используйте классы.
Разногласия — отдельная дискуссия. Внутри проекта важна консистентность.
Если считаете, что какое-то соглашение вредно — предложите его изменить, не создавайте ветки.

Когда в кодовой базе уже есть устоявшиеся стандарты, Claude склонен вводить свои стили. Даже если они лучше — это создает разногласия и усложняет поддержку.

Это было так: Claude добавил хуки в React-проект на классах. Работает, но ломает тесты, которые зависят от componentDidMount. В итоге пришлось долго исправлять.

Правило 12: Явное неудача лучше молчаливой

Если не уверены, что что-то завершено — скажите прямо.
Если пропущено 30 записей — не говорите «миграция завершена».
Если пропущены тесты — не говорите «программа работает».
Не скрывайте неопределенность, а делитесь ею.

Самые дорогие ошибки Claude — те, что выглядят как успехи. Функция «работает», но возвращает неверные данные; миграция «завершена», но пропущены 14% конфликтных записей; тест «пройден», но только потому, что он ошибочен.

Это было так: Claude заявил, что миграция базы данных «успешна». Но на самом деле он тихо пропустил 14% записей с конфликтами. Эти пропуски зафиксированы в логах, но не очевидны. Через 11 дней, когда начались аномалии в отчетах — обнаружили проблему.

Результаты

За 6 недель я проследил за 50 типовыми задачами, охватив 30 кодовых баз и протестировав три конфигурации.

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

Соответствие — это вероятность того, что при применении правила Claude явно его соблюдает.

Самое интересное — не только снижение ошибки с 41% до 3%. Важнее то, что расширение с 4 до 12 правил увеличило соблюдение с 78% до 76%, а ошибка снизилась на 8 пунктов. Новые правила покрывают те сбои, которые не решались исходными, и не конкурируют за тот же лимит внимания.

Где шаблон Карпати может тихо потерять эффективность

Даже без новых правил, исходный шаблон из 4 правил не подходит в 4 случаях.

Первое — длительные задачи с агентами.
Правила Карпати ориентированы на момент написания кода. Но что происходит, когда Claude запускает многошаговый pipeline? В шаблоне нет правил по бюджету, контрольным точкам или явным ошибкам. В результате pipeline медленно уходит в сторону.

Второе — согласованность между кодовыми базами.
«Соответствие стилю» предполагает один стиль. Но в монорепозитории из 12 сервисов Claude должен выбрать, какой стиль использовать. Исходные правила не дают подсказки. В итоге — случайный выбор или смешение стилей.

Третье — качество тестов.
«Действуйте по цели» подразумевает, что «пройти тест» — успех. Но не объяснено, что тест должен иметь смысл. В результате — тесты, которые ничего не проверяют, создают иллюзию уверенности.

Четвертое — разница между продакшеном и прототипом.
Те же 4 правила могут мешать быстрому прототипированию, где нужны быстрые эксперименты. Правило «простота» в ранних этапах может мешать.

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

Что не сработало

Перед финальной версией этих 12 правил я пробовал другие подходы.

Добавлял правила из Reddit / X.
Большинство — либо повторяли исходные 4 правила под другими словами, либо были узкоспециализированными, например «всегда используйте Tailwind». В итоге — удалил.

Больше 12 правил.
Максимум — 18. После 14 правил соблюдение снизилось с 76% до 52%. Ограничение в 200 строк — реально. Больше — модель начинает воспринимать правила как шаблон, а не как инструкции.

Зависимость от инструментов.
Например, «используйте eslint». Если в проекте его нет — правило молча не работает. Поэтому я заменил его на «следуйте стилю, уже закрепленному в проекте».

Размещение примеров вместо правил.
Примеры занимают больше контекста, чем правила, и легко вызывают переобучение. Поэтому лучше писать четкие правила.

«Будьте аккуратнее», «подумайте», «сконцентрируйтесь».
Эти фразы — шум. Их соблюдение падает до 30%, потому что их трудно проверить. Лучше — конкретные команды, например «ясно формулируйте предположения».

Говорите Claude, что он — «опытный инженер».
Это не помогает. Claude уже считает себя таким. Важна не самооценка, а поведение. Командные правила помогают, а роль — нет.

Полный набор из 12 правил для CLAUDE.md

Вот полный рабочий вариант, который можно сразу копировать и вставлять.

Пока что его нельзя показывать вне документации.

Сохраните его как CLAUDE.md в корень репозитория. Внизу добавьте свои правила — по стеку, тестам, ошибкам. Не превышайте 200 строк, иначе эффективность снизится.

Как установить

Два шага:

1. Добавьте 4 базовых правила Карпати в ваш CLAUDE.md
   curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

2. Вставьте правила 5–12 из этой статьи в конец файла

Сохраните файл в корень репозитория. Важно — символ >> добавляет правила в существующий файл, а не перезаписывает.

Модель мышления

CLAUDE.md — это не список желаний, а договор о поведении, чтобы избегать конкретных ошибок.

Каждое правило отвечает на вопрос: что оно предотвращает?

4 правила Карпати защищают от ошибок января 2026: молчаливых предположений, чрезмерной сложности, ненужных повреждений и слабых критериев успеха. Это основа, не пропускайте.

Добавленные 8 правил — это защита от новых ошибок после мая 2026: бесконтрольных циклов агентов, отсутствия контрольных точек, неэффективных тестов и скрытых ошибок. Это — постепенные улучшения.

Конечно, эффективность зависит от ситуации. Если вы не делаете многопроходных pipeline — правило 10 менее важно. Если в вашем проекте есть единый стиль, закрепленный линтингом — правило 11 избыточно. После прочтения этих 12 правил — оставляйте только те, что реально помогают вам избегать ошибок, остальные удаляйте.

Лучше иметь 6 правил, специально подобранных под ваши ошибки, чем 12, из которых половина не применима.

Заключение

Твит Карпати в январе 2026 — это в основном жалоба. Forrest Chang превратил ее в 4 правила. В итоге 120 тысяч разработчиков поставили им звезды. Большинство по-прежнему используют только эти 4.

Модель и экосистема изменились. Многошаговые агенты, цепочки hook, загрузка навыков, совместная работа — все этого не было в январе 2026. Исходные 4 правила не решали эти задачи. Они не ошиблись, а стали неполными.

Добавлены 8 правил. За 6 недель протестировано 30 репозиториев. Ошибки снизились с 41% до 3%.

Сохраните эту статью и вставьте эти 12 правил в ваш CLAUDE.md. Если это поможет вам сэкономить неделю — делитесь с коллегами.

[ссылка на оригинал]

Узнайте о вакансиях в律动BlockBeats

Присоединяйтесь к официальному сообществу律动BlockBeats:

Телеграм-канал подписки: https://t.me/theblockbeats

Телеграм-группа: https://t.me/BlockBeats_App

Официальный аккаунт в Twitter: https://twitter.com/BlockBeatsAsia