Автор: AI 产品阿颖
Прочитал блог команды Anthropic "Lessons from building Claude Code: How we use skills". Это, пожалуй, самое глубокое практическое резюме по теме Skill, которое я видел на данный момент.
Skill — вещь не сложная, но чтобы сделать их действительно хорошо, думаю, это не так уж и просто.
Помню, когда Skill только набирали популярность, все очень любили создавать различные стилистические Skill, Skill для письма. Казалось, достаточно вставить свой стиль письма, и модель стабильно будет выводить текст в этом стиле.
Но позже я сам попробовал и обнаружил, что во многих случаях это просто не работает.
Потому что один стилистический Skill может содержать несколько тысяч или даже десятки тысяч символов. При загрузке Skill контекст занимает большую часть. Когда контекст перегружен, способность модели к анализу, наоборот, снижается.
В итоге часто возникает ситуация: стиль усвоен, но содержание становится поверхностным, аналитические способности также ослабевают.
Еще одна распространенная ситуация.
Многие при написании Skill любят вставлять различные инструкции по выполнению. Первый шаг — сделать то, второй шаг — это, третий шаг — то. В результате при запуске обнаруживается, что выполнение модели нестабильно.
Позже я постепенно понял, что многие такие повторяющиеся задачи лучше подходят для оформления в виде Script (скрипта), а не написания длинных Instructions (инструкций).
После прочтения этой статьи от Anthropic, мое главное впечатление — многие на самом деле используют Skill, но не обязательно их действительно понимают.
По своей сути Skill — это Context Engineering (инженерия контекста). Когда следует помещать знания в Skill, когда следует разбивать на References (ссылки/справочники), когда следует писать Script, когда использовать Gotchas для ограничения модели — в этом есть много опыта.
Поняв принцип работы Skill и оглянувшись на те из них, что работают хорошо, обнаруживаешь, что они решают вовсе не проблему промптов (подсказок), а проблемы контекста, накопления опыта и повторного использования возможностей.
Если вы хотите глубоко изучить Skill, особенно рекомендую две статьи:
https://claude.com/blog/lessons-from-building-claude-code-how-we-use-skills
https://research.perplexity.ai/articles/designing-refining-and-maintaining-agent-skills-at-perplexity
#01 Не пишите лишнего
Skill по сути служат для накопления «неявных знаний» организации. Поэтому в Skill не нужно повторять общеизвестные факты. Ценность представляют именно те сведения, которых модель изначально не знает.
В Anthropic часто подчеркивают, что в Skill действительно нужно записывать Gotchas, то есть типичные подводные камни.
Например:
1. Эту таблицу нельзя сортировать по created_at
2. Возврат 200 от staging не означает успех
3. request_id и trace_id — это одно и то же
Потому что такая информация часто существует только в опыте сотрудников. Поэтому важно помнить, в чем суть Skill.
Skill = запись опыта мастера.
Через Skill можно систематизировать опыт, разбросанный в головах разных людей.
#02 Skill — это на самом деле Context Engineering
Это, пожалуй, одна из самых глубоких идей Anthropic.
Skill — это не markdown-файл, а папка. Для тех, кто пользовался Skill, это звучит как банальность.
Но, размышляя последние пару дней, я постепенно осознал: именно формой папки они хотят выразить концепцию Context Engineering.
Давайте снова посмотрим на типичную структуру Skill:
skill/ ├── SKILL.md ├── references/ размещаем подробные описания, API-справочники, граничные условия ├── scripts/ размещаем исполняемые скрипты ├── examples/ размещаем примеры ├── assets/ размещаем шаблоны, изображения, фиксированные материалы
При вызове определенного Skill модель сначала читает SKILL.md. Если мы запихнем всю информацию в этот файл, очень скоро произойдет перегрузка контекста.
Предположим, это Skill для устранения неполадок платежей, содержащий объяснения кодов ошибок Stripe, примеры прошлых инцидентов, скрипты для проверки и шаблоны итоговых отчетов.
Если все это свалить в SKILL.md, каждый раз при вызове Skill Клоду придется перечитывать это заново.
Даже если пользователь хочет просто уточнить значение кода ошибки или проверить, почему не обновился статус платежа. Множество совершенно ненужной информации также будет загружено в контекст.
А подход Anthropic совершенно иной.
SKILL.md больше похож на навигационную страницу. Его задача — сообщить модели, что при возникновении ошибки Stripe нужно искать соответствующее объяснение в references.
Когда нужны примеры из прошлого — смотреть аналогичные случаи в examples. Когда нужно выполнить действия по проверке — запускать скрипты из scripts. При создании отчета об устранении неполадок — использовать шаблоны из assets.
Весь процесс — это постепенное раскрытие информации.
Настоятельно рекомендую сохранить следующую картинку.
#03 По возможности используйте скрипты
Не заставляйте модель тратить ограниченный контекст и вычислительные ресурсы на рутинную работу. Поручите эти задачи скриптам.
Пример. Многие при написании Skill пишут так:
1. Запросить данные о регистрациях; 2. Запросить данные об оплатах; 3. Рассчитать конверсию; 4. Проанализировать причины аномалий.
Такой подход, конечно, возможен. Модель тоже справится. Но каждый раз при выполнении ей придется заново проходить весь аналитический процесс.
Запрос данных, их организация, обработка различных граничных случаев — все это повторяющаяся работа.
Раз эти возможности уже были проверены множество раз. Зачем заставлять модель изобретать их заново? Лучше предоставить конкретные скрипты.
Кроме того, использование скриптов делает выполнение Skill более точным и экономит токены.
С этой точки зрения Scripts в Skill фактически накапливают организационные возможности. За каждым скриптом часто стоит лучшая практика, выстраданная командой после множества ошибок.
После того, как эти возможности закреплены, Клод каждый раз может работать, опираясь на этот опыт, а не начинать с нуля снова и снова.
Поэтому я все больше чувствую, что в Skill Instructions и Scripts решают задачи на разных уровнях.
Instructions предоставляют опыт и суждения, Scripts предоставляют возможности и выполнение.
Например, в Skill для устранения неполадок платежей может быть такая запись:
Если Stripe возвращает 200, не думайте сразу, что платеж успешен, нужно дополнительно проверить таблицу payment_events.
Это относится к Instructions. Потому что это опыт. А check_payment_events() относится к Script, потому что это исполнительная способность.
Если есть только Script, модель знает, как проверить, но не обязательно знает, почему нужно проверять.
Если есть только Instructions, модель знает, что нужно проверить. Но каждый раз ей придется заново реализовывать проверку. Оба компонента необходимы.
#04 Description больше похож на правило маршрутизации
Многие люди изначально неправильно пишут Description (описание) Skill.
Потому что все привыкли писать его как описание функционала. Например: Skill управления PR помогает пользователю отслеживать статус PR, обрабатывать проблемы CI, автоматически выполнять Merge.
Но проблема в том, что модель ищет Skill не по функционалу. При запуске Claude Code сначала сканирует названия и описания всех Skill.
Затем, исходя из текущего вопроса пользователя, определяет, какой Skill следует загрузить.
Поэтому самая важная информация в Description — не то, что умеет этот Skill, а в какой ситуации его следует загружать.
Description фактически выполняет работу маршрутизации для всего Skill.
В реальном мире мало кто говорит: «Помоги мне вызвать инструмент управления PR». Скорее скажут: «Помоги отследить этот PR», «CI снова упал» и тому подобное.
Поэтому хорошее Description должно по возможности описывать намерение пользователя, а не перечислять функции.
Я даже думаю, что можно использовать очень простой метод проверки.
После написания Description удалите весь Skill, оставив только эту строку Description. Затем спросите себя: сможет ли модель, увидев вопрос пользователя, понять, когда нужно загрузить этот Skill.
Если нет, то, скорее всего, его еще нужно доработать.
#05 Управление и распространение Skill
Еще один момент касается управления Skill.
Когда Skill использует один человек, все просто. Написал несколько Skill, сам поддерживаешь, сам обновляешь. Но я верю, что большинство команд впоследствии столкнутся с одной и той же проблемой.
Когда Skill из нескольких превращаются в десятки или даже сотни, как ими управлять? Как обновлять? Как распространять среди членов команды?
Опыт Anthropic в этом отношении, на мой взгляд, весьма достоин внимания.
Когда команда небольшая, Skill напрямую следуют за репозиторием кода. Достаточно поместить их в каталог .claude/skills проекта. Все используют один и тот же набор Skill и один и тот же рабочий метод.
Но по мере роста количества Skill возникает новая проблема.
При запуске Claude Code сканирует названия и описания всех Skill, а затем определяет, какой Skill следует вызвать для текущей задачи. Чем больше Skill, тем выше стоимость маршрутизации.
Именно поэтому Anthropic позже начали создавать Marketplace. Но что еще интереснее, так это их подход к управлению Marketplace.
Многие компании, столкнувшись с такой проблемой, первой реакцией часто является создание процесса утверждения. Кто написал Skill — сначала подает заявку; после проверки и одобрения Skill попадает в официальную библиотеку. Мы внутри компании тоже так делали, но это очень громоздко. Управление ради управления.
Я обнаружил, что подход Anthropic очень гибкий.
Пусть новый Skill сначала распространяется в небольшом кругу, пусть коллеги сами устанавливают, сами пробуют.
Если пользователей становится все больше, значит, этот Skill действительно решает какую-то реальную проблему. На этом этапе автор может отправить его в официальный Marketplace.
Таким образом, они не обсуждают сначала, имеет ли Skill ценность, а сначала позволяют ему пройти проверку реальными сценариями использования. Чем больше людей его использует, тем естественнее он войдет в официальную систему. Таким образом, оставшиеся Skill — это, как правило, именно те Skill, которые действительно нужны команде.
