Cainex: исправляйте принцип Skill, а не пример

· 6 минут чтения · Любовь Черемисина · Skills Anthropic Маркетинг и аналитика AI-агенты · СегодняПродвинутый

20 августа 2026 в гайде Anthropic для стартапов описан принцип Cainex для развития Skills: когда эксперт находит ошибку агента, система не добавляет правило под один случай — исправляется общий принцип, который породил ошибку. Новая версия проверяется на проблемных примерах, эталонном наборе и случайной выборке; все изменения версионируются. Формула: «исправлять принцип, а не пример».

На кремовой бумаге цепь частных меток превращается в одну карточку принципа на редакционных весах рядом с эталонными папками тестов — метафора «исправлять принцип, а не пример» в Skills

Коротко

  • Что описали: в гайде Anthropic для стартапов — кейс Cainex: цикл улучшения Skills через правку принципа, а не добавление правила под один пример — 20 августа 2026.
  • Кому полезно: командам с библиотекой маркетинговых Skills — стратегия, сегментация, email, SEO, аналитика; тем, у кого SKILL.md раздувается частными костылями.
  • Главное ограничение: процесс требует эталонного набора тестов и дисциплины версий — без этого «исправление принципа» превращается в переписывание наугад.
  • Главное последствие: Skills остаются читаемыми и переносимыми; ошибки не накапливаются как археологический слой частных правил.

Что изменилось

Anthropic опубликовала гайд с принципом «доверяй, но проверяй» на примере Cainex — стартапа, который с помощью агентов читает медицинские записи и генерирует коды для больничного биллинга.

Uriah Israel, co-founder и CTO Cainex, формулирует жёстко: «В медицинском кодировании неверный код — не опечатка. Это событие биллинга и соответствия требованиям». Отсюда — культура проверки, которую Anthropic переносит на Skills.

Когда эксперт находит ошибку агента, система Cainex:

  1. Находит часть инструкций, которая породила ошибку.
  2. Переписывает её — или добавляет новое руководство, если случай действительно новый.
  3. Вносит изменение в версионированный набор инструкций.
  4. Прогоняет кандидата сначала на записях, где была ошибка.
  5. Затем — на эталонном наборе плюс случайной выборке.
  6. Выявляет регрессии до выпуска новой версии.

Правило, которое команда держит явно: «исправлять принцип, а не пример».

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

Тему оценочных тестов Skills мы уже разбирали — здесь другой акцент: не «как мерить», а как править, когда тест упал.

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

Плохой паттерн — знакомый многим владельцам SKILL.md:

``` ошибка ↓ частный костыль ↓ ещё ошибка ↓ ещё костыль ↓ SKILL.md = 4 000 строк ↓ никто не понимает, почему правило существует ```

Anthropic описывает правильный цикл Cainex:

``` ошибка ↓ найти причину ↓ исправить методологический принцип ↓ проверить проблемный кейс ↓ прогнать эталонный набор ↓ проверить регрессии ↓ новая версия Skill ```

Контраст на примере email-аналитики — редакционная иллюстрация, не текст Cainex:

ПлохоЛучше
«Если письмо №371884838, то обязательно проверить X»«Если анализируется рассылка, в выборку должны войти не менее N сопоставимых выпусков»
Правило живёт только для одного IDПравило переносится на класс задач
Нет статуса неполноты«Если данных недостаточно — результат помечается как неполный»

Для методологических Skills по стратегии, сегментации, email, SEO и аналитике это, пожалуй, самая полезная практика из сегодняшней сводки гайда — сильнее, чем очередной промпт-хак.

Что это означает для бизнеса

Три следствия для маркетинговой библиотеки Skills:

  1. SKILL.md — методология, не журнал инцидентов. Каждое правило должно отвечать на вопрос «какой класс задач это покрывает?», а не «какой баг мы поймали в вторник».
  1. Эксперт не чинит примеры — он чинит принципы. Cainex использует предметных экспертов не для правки по одному случаю, а чтобы их указания входили в цикл самоулучшения. Маркетолог, который дописывает «для кампании X делай Y», должен переформулировать в «для кампаний типа Z проверяй W».
  1. Версия Skill без регрессии — не версия. Cainex возвращает короткий список: предложенные правки, записи, которые не удалось разрешить, вопросы к эксперту. Инженер тратит время на сложные 20%, а не на механические 80%.

Стыкуется с корпоративной библиотекой Skills и программным интерфейсом Skills в общей доступности: когда навык — управляемый компонент с версиями, правило «не костылить» становится операционным, а не пожеланием.

Что протестировать

  1. Аудит одного раздутого Skill. Откройте SKILL.md с 500+ строк. Отметьте правила, привязанные к конкретным ID, датам или названиям кампаний. Задача: переписать три таких правила в обобщённые принципы. Метрика: число строк и число «уникальных сущностей» в тексте.
  1. Мини-эталонный набор. Для одного маркетингового Skill соберите 5–10 проверенных кейсов — «золотой» ответ известен. После правки принципа прогоните: сначала упавший кейс, потом весь набор. Критерий успеха: упавший прошёл, остальные не деградировали.
  1. Лимит частностей на изменение. Введите правило команды: одно изменение Skill — не более одной именованной сущности (кампания, клиент, отчёт). Если нужно больше — это сигнал, что правите пример, а не принцип.

Что это значит для ваших данных

Принцип Cainex особенно важен для Skills, которые ходят в MCP-коннекторы — Метрика, CRM, рассылки. Агент легко «запоминает» аномалию одного аккаунта как универсальное правило. Обобщение «если в выборке меньше N отправок — помечай результат как неполный» защищает и методологию, и отчётность.

Практический шаг: завести рядом с Skill каталог эталонных тестов или таблицу проверенных кейсов — как в skill-creator, но фокус на регрессии после правки, а не только на первичной оценке. Связка с Crazy Egg: там ценность дала не цепочка Skills сама по себе, а фильтр стратегического угла — принцип, а не 27 правил ради одного письма.

Главный вывод

Cainex в гайде Anthropic даёт формулу, которой не хватало многим маркетинговым Skills: ошибка → принцип → эталон → регрессия → версия. Не «ошибка → строка в SKILL.md».

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

Источники

← Все новости AI и MCP