Cainex: исправляйте принцип Skill, а не пример
20 августа 2026 в гайде Anthropic для стартапов описан принцип Cainex для развития Skills: когда эксперт находит ошибку агента, система не добавляет правило под один случай — исправляется общий принцип, который породил ошибку. Новая версия проверяется на проблемных примерах, эталонном наборе и случайной выборке; все изменения версионируются. Формула: «исправлять принцип, а не пример».
Коротко
- Что описали: в гайде Anthropic для стартапов — кейс Cainex: цикл улучшения Skills через правку принципа, а не добавление правила под один пример — 20 августа 2026.
- Кому полезно: командам с библиотекой маркетинговых Skills — стратегия, сегментация, email, SEO, аналитика; тем, у кого SKILL.md раздувается частными костылями.
- Главное ограничение: процесс требует эталонного набора тестов и дисциплины версий — без этого «исправление принципа» превращается в переписывание наугад.
- Главное последствие: Skills остаются читаемыми и переносимыми; ошибки не накапливаются как археологический слой частных правил.
Что изменилось
Anthropic опубликовала гайд с принципом «доверяй, но проверяй» на примере Cainex — стартапа, который с помощью агентов читает медицинские записи и генерирует коды для больничного биллинга.
Uriah Israel, co-founder и CTO Cainex, формулирует жёстко: «В медицинском кодировании неверный код — не опечатка. Это событие биллинга и соответствия требованиям». Отсюда — культура проверки, которую Anthropic переносит на Skills.
Когда эксперт находит ошибку агента, система Cainex:
- Находит часть инструкций, которая породила ошибку.
- Переписывает её — или добавляет новое руководство, если случай действительно новый.
- Вносит изменение в версионированный набор инструкций.
- Прогоняет кандидата сначала на записях, где была ошибка.
- Затем — на эталонном наборе плюс случайной выборке.
- Выявляет регрессии до выпуска новой версии.
Правило, которое команда держит явно: «исправлять принцип, а не пример».
Первые версии Cainex, по словам Uriah, переобучались на частности: «исправляли» кейс, кодируя конкретный случай — и накапливали заплатки вместо того, чтобы становиться умнее. Подход сменили: принудительно обобщать принципы и ограничивать, сколько частностей может войти в одно изменение.
Тему оценочных тестов Skills мы уже разбирали — здесь другой акцент: не «как мерить», а как править, когда тест упал.
Почему это важно
Плохой паттерн — знакомый многим владельцам SKILL.md:
``` ошибка ↓ частный костыль ↓ ещё ошибка ↓ ещё костыль ↓ SKILL.md = 4 000 строк ↓ никто не понимает, почему правило существует ```
Anthropic описывает правильный цикл Cainex:
``` ошибка ↓ найти причину ↓ исправить методологический принцип ↓ проверить проблемный кейс ↓ прогнать эталонный набор ↓ проверить регрессии ↓ новая версия Skill ```
Контраст на примере email-аналитики — редакционная иллюстрация, не текст Cainex:
| Плохо | Лучше |
|---|---|
| «Если письмо №371884838, то обязательно проверить X» | «Если анализируется рассылка, в выборку должны войти не менее N сопоставимых выпусков» |
| Правило живёт только для одного ID | Правило переносится на класс задач |
| Нет статуса неполноты | «Если данных недостаточно — результат помечается как неполный» |
Для методологических Skills по стратегии, сегментации, email, SEO и аналитике это, пожалуй, самая полезная практика из сегодняшней сводки гайда — сильнее, чем очередной промпт-хак.
Что это означает для бизнеса
Три следствия для маркетинговой библиотеки Skills:
- SKILL.md — методология, не журнал инцидентов. Каждое правило должно отвечать на вопрос «какой класс задач это покрывает?», а не «какой баг мы поймали в вторник».
- Эксперт не чинит примеры — он чинит принципы. Cainex использует предметных экспертов не для правки по одному случаю, а чтобы их указания входили в цикл самоулучшения. Маркетолог, который дописывает «для кампании X делай Y», должен переформулировать в «для кампаний типа Z проверяй W».
- Версия Skill без регрессии — не версия. Cainex возвращает короткий список: предложенные правки, записи, которые не удалось разрешить, вопросы к эксперту. Инженер тратит время на сложные 20%, а не на механические 80%.
Стыкуется с корпоративной библиотекой Skills и программным интерфейсом Skills в общей доступности: когда навык — управляемый компонент с версиями, правило «не костылить» становится операционным, а не пожеланием.
Что протестировать
- Аудит одного раздутого Skill. Откройте SKILL.md с 500+ строк. Отметьте правила, привязанные к конкретным ID, датам или названиям кампаний. Задача: переписать три таких правила в обобщённые принципы. Метрика: число строк и число «уникальных сущностей» в тексте.
- Мини-эталонный набор. Для одного маркетингового Skill соберите 5–10 проверенных кейсов — «золотой» ответ известен. После правки принципа прогоните: сначала упавший кейс, потом весь набор. Критерий успеха: упавший прошёл, остальные не деградировали.
- Лимит частностей на изменение. Введите правило команды: одно изменение Skill — не более одной именованной сущности (кампания, клиент, отчёт). Если нужно больше — это сигнал, что правите пример, а не принцип.
Что это значит для ваших данных
Принцип Cainex особенно важен для Skills, которые ходят в MCP-коннекторы — Метрика, CRM, рассылки. Агент легко «запоминает» аномалию одного аккаунта как универсальное правило. Обобщение «если в выборке меньше N отправок — помечай результат как неполный» защищает и методологию, и отчётность.
Практический шаг: завести рядом с Skill каталог эталонных тестов или таблицу проверенных кейсов — как в skill-creator, но фокус на регрессии после правки, а не только на первичной оценке. Связка с Crazy Egg: там ценность дала не цепочка Skills сама по себе, а фильтр стратегического угла — принцип, а не 27 правил ради одного письма.
Главный вывод
Cainex в гайде Anthropic даёт формулу, которой не хватало многим маркетинговым Skills: ошибка → принцип → эталон → регрессия → версия. Не «ошибка → строка в SKILL.md».
Если ваша библиотека навыков растёт быстрее, чем растёт качество — скорее всего, вы кодируете примеры. Следующий шаг: один Skill, один упавший тест, одна правка принципа и прогон эталонного набора. Оценочные тесты без этого цикла покажут, что сломалось, но не научат как чинить, не превращая методологию в свалку.
Источники
- The Claude Code guide for startups — Anthropic, 2026-08-20