Claude — не сотрудник, пока вы его не обучили

Skill сработал один раз — и почти все на этом останавливаются: раз получилось, значит можно доверять и дальше. Дилан Дэвис в ролике «I Trained Claude to Work Exactly Like Me» показывает, почему это ловушка, и предлагает системный процесс: обучение skill в Claude Code через слепое тестирование и цикл точечных правок, а не разовую настройку по ощущениям.

Один удачный запуск ничего не доказывает

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

Обучение skill в Claude Code: как выглядит рабочий цикл

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

Слепое тестирование на двух наборах данных

Дальше — самое частое слабое место. Проверка «на глаз» или повторный прогон на том же примере, на котором skill строился, не считаются: модель могла запомнить нюансы конкретного кейса и выдать идеальный, но нерепрезентативный результат. Правильный подход — разделить примеры на две группы: build-пул, который модель видит при создании skill (вход и ваш готовый выход), и test-пул, который остаётся скрытым. На тесте модели дают только вход и просят выполнить задачу заново, а результат сравнивают с уже готовым «ручным» решением того же кейса.

Бинарный чек-лист и sub-agent-грейдер

Сравнение должно быть объективным, поэтому критерии оценки — строго бинарные: 7–10 вопросов да/нет, которые модель сама выводит, анализируя несколько ваших удачных примеров. А проверять по ним итоговый результат должен не тот же агент, который его написал, — иначе он необъективен и склонен ставить себе зачёт. Решение — отдельный sub-agent с чистым контекстом: он получает только готовый черновик и чек-лист, выставляет оценки по каждому пункту и для каждого «нет» коротко объясняет, в чём именно провал.

Цикл правок и почему его нельзя закрыть один раз

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

Ничего в этом процессе не требует специальных инструментов — только дисциплина: строить skill на живом диалоге, проверять на скрытых данных, судить по бинарным критериям чужими глазами sub-agent’а и чинить точечно. Именно эта рутина отличает AI-инструмент, которому действительно можно доверить повторяющуюся задачу, от того, который просто «вроде работает».