Навык без персоны — это команда без командира. Вы можете наполнить файл определений ограничениями, форматами вывода и правилами стиля, но если вы не скажете ИИ, кем он должен быть, вы просто просите талантливого, но не имеющего направления работника угадать название своей должности. Результат будет именно таким, как вы и ожидаете: шаблонный вывод, колеблющийся между разными тонами, уровни экспертизы, которые резко меняются от запуска к запуску, и процесс отладки, напоминающий погоню за дымом.
Это важно, потому что современные рабочие процессы разработки с ИИ — это уже не разовые промпты. Это модульные системы, состоящие из множества мелких навыков, связанных в цепочку. Когда каждому навыку не хватает четкой идентичности, страдает весь пайплайн.
Почему отсутствие персон ломает ваш рабочий процесс
Когда вы пропускаете объявление роли, вы заставляете модель импровизировать в вопросах собственной компетенции. В одну минуту она пишет код как осторожный стажер, старающийся не сломать сборку. В следующую — проектирует распределенную систему как ведущий инженер, видевший все возможные граничные случаи. Такая непоследовательность не просто раздражает. Она делает ваш рабочий процесс ненадежным.
Проблемы накапливаются быстро. ИИ выбирает случайный голос, и ваша кодовая база начинает выглядеть так, будто ее писала комиссия, которая никогда не встречалась. Результаты меняются каждый раз, когда вы запускаете навык, а это значит, что вы не можете доверять автоматизированным тестам или diff-ревью. Аудит становится невозможным, потому что вы не знаете, с какой точки зрения был получен результат. Был ли этот код сгенерирован инженером, ориентированным на безопасность, или универсальным специалистом по продукту? Если ответ — «как захотелось модели», у вас нет возможности проверить логику.
Цепочки навыков усугубляют ситуацию. Представьте, что один навык генерирует API-контракты, а другой пишет реализацию. Если первый действует как дотошный старший архитектор, обеспечивающий строгую валидацию, а второй ведет себя как младший разработчик, пропускающий обработку ошибок, ваша интеграция рухнет. Цепочка держится только тогда, когда каждое звено знает свою идентичность. Без этого ответственность исчезает. Когда что-то ломается, вы не можете указать на «линзу», которая дала сбой, потому что никакая линза не была определена.
Как это исправить
Решение простое, но конкретное. Добавьте объявление роли в качестве самой первой инструкции в файле навыка. Не прячьте его под правилами форматирования или схемами вывода. Начинайте с идентичности.
Используйте четкую структуру: «Вы — [роль] с экспертизой в [область]». Затем добавьте одно или два предложения о том, что эта роль на самом деле делает в контексте задачи. Например: «Вы — старший бэкенд-инженер с экспертизой в распределенных системах. Ваша задача — проверять pull requests на наличие рисков параллелизма и проблем с согласованностью данных. Вы ставите под сомнение предположения об управлении состоянием и отказываетесь одобрять код, в котором отсутствует надлежащая обработка ошибок».
Этого достаточно. Не более трех предложений. Длинные биографии создают лишний шум. Модели не нужна история детства или список хобби. Ей нужен профессиональный якорь, который будет формировать её суждения.
Придерживайтесь реальных профессиональных ролей. Staff software engineer или технический писатель дает модели узнаваемую структуру обязанностей. Просьба вести себя как Шерлок Холмс или средневековый волшебник может показаться креативной, но это вносит непредсказуемые ассоциации, которые не имеют никакого отношения к вашему пайплайну код-ревью. Реальные роли несут в себе реальные ограничения.
Что меняется, когда вы делаете всё правильно
Как только каждый навык обретает свою персону, весь ваш пайплайн стабилизируется.
Первая награда — предсказуемость. ИИ перестает гадать о своем уровне квалификации. Персона старшего специалиста будет задавать более сложные вопросы. Она будет оспаривать расплывчатые требования, указывать на пропущенные граничные случаи и требовать контекст, который дефолтный или «младший» голос мог бы проигнорировать. Когда вы определяете роль, вы определяете стандарт.
Ревью проходят быстрее. Когда коллега читает результат, помеченный четкой персоной, он понимает точку зрения, стоящую за каждым предложением. Он знает, следует ли рассматривать отзыв как жесткое архитектурное требование или как мягкое стилистическое предпочтение. Контекст становится явным, а не подразумеваемым.
Цепочки навыков наконец-то работают так, как задумано. Каждый