Один промпт разросся в регламент: как я разделяю ответственность внутри AI-навыка

У меня был рабочий AI-навык для инженерных задач. Сначала он выглядел как обычная инструкция: роль, задача, формат ответа и несколько ограничений. Этого хватало, пока сценарии были короткими: посмотреть фрагмент кода, подсказать план, разобрать очевидную ошибку ^[1].

Потом навык начал получать задачи сложнее. Например: “посмотри PR перед merge”. В такой фразе много скрытой работы. Нужно понять, что меняется, какие есть ограничения, где может быть риск, чем подтверждён вывод, какие замечания действительно блокируют принятие изменений, а какие остаются пожеланиями.

Каждая новая ошибка добавляла в инструкцию ещё одно правило. AI слишком быстро предлагал правку – появлялось требование сначала определить границу задачи. Смешивал важные замечания и вкусовые ^[2] правки – появлялось правило разделять блокеры, вопросы и предложения. Уверенно писал вывод без проверки – появлялся блок про evidence. Ответ становился технически верным, но тяжёлым для чтения – добавлялось редакторское правило.

Так обычный промпт постепенно превращается в регламент. В какой-то момент проблема уже в самой форме: один текст пытается удержать работу аналитика входа, разработчика, архитектора, проверяющего риски, QA и редактора результата.

Такую схему я для себя называю скилл-консилиумом: один AI-навык для пользователя, но несколько явно разделённых зон ответственности внутри него.

Что я называю AI-навыком

Под AI-навыком я понимаю устойчивую инструкцию для повторяющегося рабочего сценария.

Это может быть skill для Codex, отдельный ассистент, системный промпт, набор правил в репозитории или другой похожий механизм. Название инструмента вторично. Важен рабочий смысл: пользователь приносит задачу одного типа, а AI выполняет её по ожидаемому порядку.

Примеры таких сценариев:

• сделать ревью pull request;

• разобрать баг;

• подготовить план безопасной правки;

• проверить релизный список;

• собрать handoff после длинной задачи – то есть передать состояние задачи следующему человеку или следующей AI-сессии;

• привести черновик документации в рабочий вид.

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

Скилл-консилиум появляется в тот момент, когда внутри одного навыка становится полезно явно назвать разные виды проверки.

Почему большой промпт начинает мешать

Большой промпт часто растёт из правильных реакций ^[3] на ошибки.

Модель торопится менять код – добавляем правило сначала разобраться в задаче. Пропускает риск – добавляем отдельный блок про данные, права доступа и совместимость. Пишет слишком общий вывод – добавляем требование указывать, чем он подтверждён. Теряет тон ответа – добавляем редакторские требования.

Все эти правила сами по себе полезны. Сложность начинается, когда они лежат в одном общем потоке.

Модель должна одновременно читать вход, планировать действие, проверять архитектурные последствия, искать риск, думать о тестах и писать финальный ответ. Для маленькой задачи это терпимо. Для задачи с несколькими слоями ответ может выглядеть аккуратно, но ход проверки остаётся скрытым.

Пользователь видит итоговый текст. Ему приходится самому восстанавливать:

• какие факты AI считал надёжными;

• где AI увидел риск;

• почему замечание стало блокирующим;

• чем подтверждён вывод;

• что осталось предположением;

• можно ли принимать изменение.

Такой ответ может быть приятным для чтения и слабым как инженерный инструмент.

Как устроен скилл-консилиум

Снаружи всё остаётся привычным: пользователь обращается к одному AI-навыку и получает один итоговый ответ. Внутри задача проходит через несколько ролей.

Примерный набор ролей:

Названия можно менять под тип задачи. Для ревью кода акценты одни, для багфикса другие, для документации третьи. Главное, чтобы каждая роль делала отдельную работу: находила свой тип проблемы, принимала своё решение или добавляла свою проверку.

Для пользователя подробная внутренняя схема имеет смысл только тогда, когда она улучшает результат. Скилл-консилиум сохраняет один удобный итоговый ответ и добавляет к нему дисциплину: вход разобран, риск назван, проверка видна, итог пригоден для действия.

Пример: ревью pull request

Возьмём короткий запрос: “посмотри PR”.

В плохом варианте AI возвращает список замечаний:

- Стоит улучшить название переменной.
- Возможно, нужен тест.
- Проверьте обработку прав доступа.
- Код можно сделать читаемее.

Формально ревью есть. Практически в нём смешаны косметика, возможный тест, риск по доступам и общая фраза про читаемость. Автору PR всё равно нужно самому понять, что мешает merge, какой вопрос надо уточнить и какие пункты можно отложить.

В скилл-консилиуме тот же запрос проходит иначе.

Специалист по входу проверяет, есть ли описание задачи, diff, тесты и важные ограничения. Если входа мало, он просит недостающий контекст.

Предметный специалист смотрит, решает ли изменение заявленную проблему.

Архитектор действия оценивает масштаб: локальная это правка или изменение контракта.

Проверяющий риски ищет места, где маленькое изменение может повлиять на пользователей, данные, права доступа или обратную совместимость.

Проверка качества смотрит, чем подтверждён вывод: тестом, воспроизведением, ручной проверкой или только рассуждением.

Редактор собирает ответ в рабочий формат:

Блокеры:
- После ошибки авторизации код возвращает закэшированные данные. Это может показать пользователю устаревшее состояние или данные, к которым у него уже нет доступа.

Вопросы:
- Есть ли тест на сценарий authorization failure?

Предложения:
- Разделить fallback для технических ошибок и отказа в доступе.

Вывод:
- PR рано принимать: сначала нужно явно обработать отказ в доступе и подтвердить это тестом.

Ценность здесь в приоритизации. Серьёзное замечание получает свой вес. Неясность названа прямо. Человеку проще понять, что делать дальше.

Пример: багфикс

Другой частый запрос: “вот ошибка, почини”.

Такой запрос легко толкает AI сразу искать файл и предлагать правку. Иногда это срабатывает. В реальной разработке багфикс обычно начинается раньше: нужно понять симптом, воспроизведение, окружение, границы изменения и способ проверки.

В ролевой структуре специалист по входу отделяет факты от догадок: что именно произошло, где лог, какие шаги воспроизведения, какая версия окружения, что уже проверяли.

Предметный специалист ищет область причины.

Архитектор действия предлагает минимальный путь: где смотреть, что менять, какие варианты оставить за пределами текущей правки.

Проверяющий риски задаёт неприятные вопросы: затрагивает ли правка данные, миграции, права доступа, публичный API, фоновые задачи, продакшен.

Проверка качества требует сценарий подтверждения: тест, команда, повторение ^[4] бага до и после, ручная проверка или честная пометка, что проверка пока ограничена.

Финальный ответ должен быть коротким, но содержательным: что было причиной, что изменено, чем проверено, какой риск остался.

Здесь важнее всего удержание шагов, которые опытный разработчик обычно держит в голове.

Что меняется на практике

Первое изменение: у навыка становится меньше слепых зон.

Один общий ассистент часто оптимизирует ближайшую видимую цель. Попросили ревью – он пишет замечания. Попросили багфикс – предлагает правку. Попросили план – строит список шагов. Ролевая структура добавляет перед действием несколько обязательных вопросов: что известно, что непонятно, где риск, чем проверить результат.

Второе изменение: навык проще улучшать.

Когда всё лежит в одном промпте, трудно понять, что именно сломалось. Ответы стали сухими? Пропали проверки? Риски стали мягкими? Модель начала уверенно действовать при нехватке данных? Каждая новая правка в общий промпт может случайно задеть соседнее поведение ^[5].

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

Третье изменение: навык можно выращивать постепенно.

Сначала в нём может быть только исполнитель и простой формат ответа. Потом появляется проверка входа. Потом отдельная проверка рисков. Потом качество и доказательства. Потом редактор финального ответа. Новые роли появляются там, где повторяющаяся задача уже требует отдельной ответственности.

Такой рост понятнее, чем попытка сразу написать идеальный промпт на все случаи.

Когда это стоит использовать

Подход окупается там, где у задачи есть несколько слоёв ответственности.

Хорошие кандидаты:

• решение перед merge;

• баг с неясной причиной;

• изменение публичного API;

• релизная проверка;

• задача с пользовательскими данными;

• handoff после длинной работы;

• ревью материала, который пойдёт наружу.

Для маленьких задач ролевая структура будет лишним весом. Вспомнить команду git, объяснить ошибку компилятора, поправить одну фразу или набросать короткий пример кода обычно быстрее обычным запросом.

Есть ещё один риск: роли ради ролей. Если каждый “специалист” пишет одно и то же, пользователь получает шум. Если финальный ответ превращается в длинное обсуждение, навык мешает. Каждая роль должна либо находить отдельный тип проблемы, либо принимать отдельное рабочее решение.

Как попробовать без отдельного инструмента

Самый простой эксперимент можно сделать прямо в чате. Если ваш рабочий промпт уже превратился в простыню правил, попробуйте сначала выделить одну роль: проверку входа или проверку рисков.

Возьмите повторяющийся сценарий, например ревью PR или разбор бага, и попросите AI пройти задачу по ролям:

Разбери задачу как скилл-консилиум внутри одного AI-навыка:
1. Вход: что известно и чего не хватает.
2. Поведение: что меняется для системы или пользователя.
3. Риски: что может сломаться или потребовать осторожности.
4. Проверка: чем подтвердить вывод.
5. Итог: блокеры, вопросы, предложения, вывод.

После нескольких прогонов будет видно, где AI чаще ошибается.

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

Когда сценарий повторяется регулярно, эту схему можно оформить как устойчивый AI-навык.

Демо-пример

Для этой идеи я сделал небольшой демо-репозиторий:

https://github.com/zabarov/demo-codex-skill-dev-review

Это текстовый пример навыка для ревью кода. Если будете смотреть репозиторий, начните с SKILL.md: там видна общая инструкция навыка и разделение ролей. Потом откройте пример review output – он показывает, как итог раскладывается на блокеры, вопросы, предложения и вывод.

Репозиторий полезен как учебный материал. Его можно открыть, посмотреть структуру навыка, попробовать на своих маленьких примерах и изменить под собственный процесс ревью.

Главная идея там такая же, как в статье: AI-навык становится практичнее, когда внутри него явно разделены проверки, а финальный ответ остаётся удобным для человека.

Что я вынес из этого опыта

Скилл-консилиум помог мне остановить бесконечное утяжеление одного промпта.

Вместо добавления всё новых правил в общий текст я начал разделять ответственность: кто понимает вход, кто смотрит предметную часть, кто выбирает порядок действия, кто ищет риск, кто проверяет качество, кто собирает ответ.

AI всё ещё ошибается. Ответственность остаётся у человека. Но навык начинает вести себя спокойнее и понятнее: за уверенным текстом появляются видимые рабочие проверки.

В разработке это особенно важно. Хороший результат здесь редко сводится к одному правильному ответу. Важен путь: что считалось фактом, где был риск, чем подтверждён вывод и какое решение должен принять человек.

Полезные AI-навыки для инженерной работы, на мой взгляд, будут развиваться именно в эту сторону: от надежды на один идеальный промпт к ясному распределению ответственности внутри инструмента.

Мне интересно, как вы решаете похожую проблему у себя?