Anthropic нарешті оприлюднили свою внутрішню методологію навичок

Дивився блог-пост команди Anthropic «Lessons from building Claude Code: How we use skills». Це, мабуть, найглибше практичне резюме щодо навичок, яке я наразі бачив.

Навичка насправді не є складною річчю, але щоб справді зробити її хорошою, я вважаю, це не так просто.

Я пам’ятаю, коли навичка стала популярною, всі дуже любили створювати різні стилі письма навичок, навички писання. Здається, достатньо просто вставити свій стиль у модель, і вона стабільно буде його дотримуватися.

Але пізніше я сам спробував і зрозумів, що багато разів це просто не працює.

Тому що один стиль письма може займати кілька тисяч або навіть десятки тисяч слів. Коли навичка завантажується, контекст займає дуже багато місця. А коли контекст великий, здатність моделі до мислення навпаки знижується.

Зрештою, часто виникає ситуація: стиль засвоєно, але зміст стає поверхневим, аналітичні здібності слабшають.

Ще одна поширена ситуація.

Багато хто при створенні навичок любить вставляти різні інструкції щодо операцій. Що робити на першому кроці, що на другому, що на третьому. В результаті, при запуску модель працює нестабільно.

Пізніше я зрозумів, що багато таких повторюваних задач краще закріпити у скриптах, а не писати довгі інструкції.

Після прочитання статті Anthropic у мене склалося сильне враження: багато людей насправді використовують навички, але не завжди розуміють їхню суть.

Навичка по суті — це інженерія контексту. Коли слід вставляти знання у навичку, коли краще розбити її на посилання, коли писати скрипти, коли використовувати «Gotchas» для обмеження моделі — у цьому є багато досвіду.

Зрозумівши принцип роботи навичок, дивлячись на хороші приклади, можна побачити, що вони вирішують зовсім не проблему підказок, а питання контексту, накопичення досвіду та повторного використання здібностей.

Якщо хтось хоче глибше досліджувати навички, дуже рекомендую прочитати дві статті:

#01 Не писати нісенітниць

Навичка по суті — це накопичення «прихованих знань» організації. Тому не варто дублювати вже відомі факти. Справжньо цінними є ті дані, яких модель взагалі не знає.

Внутрішньо команда Anthropic часто наголошує, що навичка має містити саме «Gotchas», тобто поширені пастки.

Наприклад:

1. Цю таблицю не можна сортувати за created_at

2. Відповідь 200 у staging не означає успіх

3. request_id і trace_id — це одне й те саме

Оскільки ця інформація зазвичай є у досвіді співробітників, важливо пам’ятати, що суть навички — це саме це.

Skill = записати досвід майстрів.

За допомогою навички можна закріпити досвід, який раніше був розкиданий у головах різних людей.

#02 Навичка — це по суті інженерія контексту

Це, мабуть, один із найглибших висновків Anthropic.

Навичка — це не markdown-файл, а папка. Для тих, хто вже працював із навичками, це звучить як дурниця.

Але я останні дні багато думав і поступово зрозумів: вони саме цим способом, папкою, прагнуть передати ідею інженерії контексту.

Давайте ще раз подивимося на типову структуру навички:

skill/  ├── SKILL.md  ├── references/ — детальні описи, API, граничні умови  ├── scripts/ — виконувані скрипти  ├── examples/ — приклади  ├── assets/ — шаблони, зображення, статичні матеріали

Коли викликаємо навичку, модель спочатку читає SKILL.md. Якщо всі дані зберігати тільки в цьому файлі, швидко виникне проблема «вибуху контексту».

Припустимо, це навичка для вирішення проблем із платежами, у ній є і опис кодів помилок Stripe, і історичні кейси, і скрипти для діагностики, і шаблони звітів.

Якщо все це звалити в SKILL.md, кожного разу при виклику навички Claude доведеться знову читати цей файл.

Навіть якщо користувач просто хоче зрозуміти значення якогось коду помилки або подивитися, чому статус платежу не оновився — багато непотрібної інформації буде зчитано і додано до контексту.

Але ідея Anthropic зовсім інша.

SKILL.md — це швидше навігаційна сторінка. Вона має підказати моделі, що при появі помилок Stripe потрібно звернутися до references для отримання відповідної інформації.

Якщо потрібно подивитися історичні кейси — у examples. Якщо потрібно виконати діагностику — запустити скрипти з scripts. А для формування звіту — використати шаблони з assets.

Цей процес — поступовий і поступовий.

Нижче — дуже рекомендую зберегти цю ілюстрацію.

#03 Використовувати скрипти максимально

Не варто витрачати обмежений контекст і здатність до мислення моделі на повторну роботу. Це краще делегувати скриптам.

Наприклад. Багато хто при створенні навичок пише так:

1. Запитати дані реєстрації; 2. Запитати платіжні дані; 3. Обчислити конверсію; 4. Аналізувати причини аномалій.

Це цілком прийнятно. Модель може так зробити. Але кожного разу вона знову проходить весь аналіз з початку.

Запити даних, їх обробка, врахування крайніх випадків — усе це повторювані задачі.

Оскільки ці можливості вже багато разів перевірені, навіщо знову винаходити колесо? Краще надати конкретний скрипт.

Крім того, використання скриптів робить виконання навички більш точним і економить токени.

З цієї точки зору, скрипти в навичках — це закріплення організаційних навичок. За кожним скриптом стоїть досвід, накопичений командою після багатьох помилок і виправлень.

Закріпивши ці можливості, Claude зможе працювати на основі цих знань, а не з нуля щоразу.

Тому я все більше переконуюся, що Instructions і Scripts у навичках вирішують різні задачі.

Instructions — це досвід і судження, Scripts — це здатність і виконання.

Наприклад, у навичці для вирішення проблем із платежами може бути таке:

Якщо Stripe повернув 200, не вважайте платіж успішним без додаткової перевірки payment_events.

Це — Instructions, бо це досвід. А функція check_payment_events() — Script, бо це здатність виконати дію.

Якщо є тільки Script, модель знає, як зробити запит, але не знає, чому саме.

Якщо є тільки Instructions, модель знає, що потрібно зробити, але кожного разу доводиться повторювати.

Обидва компоненти — необхідні.

#04 Опис — це швидше маршрутне правило

Багато хто неправильно пише опис навички.

Бо зазвичай описують функціонал. Наприклад: PR Management Skill допомагає слідкувати за статусом PR, вирішувати проблеми CI, автоматично зливати.

Але проблема в тому, що модель не шукає навичку за функцією. При запуску Claude Code він спершу сканує назви та описи всіх навичок.

І вже на основі поточного запиту вирішує, яку навичку активувати.

Тому найважливіша інформація у описі — це не те, що ця навичка робить, а за яких умов її потрібно активувати.

Опис виконує роль маршрутизатора для навички.

У реальному світі мало хто просить допомоги у PR-менеджера. Люди швидше скажуть: «Подивися, цей PR або CI зламався».

Тому хороший опис має передавати саме намір користувача, а не просто перелік функцій.

Я навіть пропоную простий спосіб перевірки.

Написавши опис, видаліть саму навичку, залишивши тільки цю стрічку. І запитайте себе: чи зможе модель, побачивши запит користувача, зрозуміти, коли потрібно активувати цю навичку?

Якщо ні — потрібно ще доопрацювати.

#05 Управління та розподіл навичок

Ще один важливий аспект — управління навичками.

Коли один користувач створює кілька навичок, це просто. Пишеш кілька, підтримуєш і оновлюєш сам.

Але я впевнений, що більшість команд з часом стикнуться з питанням: як керувати десятками або сотнями навичок? Як їх оновлювати? Як ділитися з командою?

Досвід Anthropic у цьому дуже цінний.

У маленьких командах навички зазвичай зберігаються у репозиторії — у папці .claude/skills у проекті. Всі користуються однією колекцією навичок і методів.

Але з ростом кількості навичок виникає нова проблема.

При запуску Claude Code він сканує всі назви та описи навичок і визначає, яку активувати. Чим більше навичок, тим дорожче маршрутизація.

Саме тому Anthropic почали створювати Marketplace. Але цікаво, що вони роблять із управлінням Marketplace.

Багато компаній у такій ситуації створюють процес затвердження: хто створив навичку — подає заявку, її перевіряють і додають до офіційної бібліотеки. Ми теж так робили, але це дуже громіздко.

Anthropic ж обрали більш легкий підхід.

Нові навички спочатку поширюють у вузькому колі, колеги самі їх встановлюють і тестують.

Якщо навичка стає популярною і її починають активно використовувати — тоді її додають до офіційного Marketplace.

Вони не сперечаються, чи має навичка бути корисною спочатку, а дають їй пройти реальне застосування. Якщо вона потрібна — вона потрапить у систему. Це гарантує, що залишаться лише ті навички, які дійсно потрібні команді.