Кому с ИИ жить хорошо, и что этому мешает
Некоторые люди рождены для работы с ИИ, даже если сами этого еще не осознают.
Например, большинство «активистов» (термин от Хани и Мамфорда) — это прирожденные «AI-киборги», поскольку они открыты новому опыту. Такой склад ума отлично подходит для непредсказуемой природы ИИ: только практический опыт позволяет понять, при каких условиях ИИ стабильно выдает качественный результат. Но не только такой склад ума подходит.
Преимущество руководителей
Наиболее очевидная группа людей, легко осваивающая ИИ, — это опытные руководители. Эта статистика наглядно показывает, насколько руководители опережают остальных по темпам внедрения ИИ.
Руководители обычно действуют как «AI-кентавры». Они показывают высокую эффективность в других типах задач, нежели киборги — а именно там, где соблюдение общих правил практически гарантирует качество.
Оказывается, правила работы с ИИ гораздо ближе к принципам пипл-менеджмента, чем к руководствам по использованию ПО. Руководители уже знают эти правила и могут применять их без лишних усилий.
Продвинутые пользователи ИИ мастерски умеют декомпозировать сложные проблемы на простые задачи и готовить четкий контекст. Опытные руководители проектов и команд и без ИИ делают и то, и другое — быстрее большинства сотрудников.
Однако, чтобы полностью реализовать это преимущество, вам придется решить проблему, с которой вы наверняка уже справились при управлении людьми, но еще не решили при работе с ИИ.
Проблема микроменеджмента ИИ
Представьте блестящего стажера, который может справиться с любой задачей, если дать ему достаточно контекста. Чтобы качество его работы вас устраивало, вам придется постоянно ставить задачи, описывать вводные и проверять результаты. Пока стажер войдет в курс дела, этот микроменеджмент будет съедать львиную долю вашего времени.
Именно это происходит и с ИИ. Микроменеджмент пожирает то время, которое вы раньше тратили на самостоятельное выполнение работы. Хуже того, корпоративные чат-боты и даже ChatGPT не умеют учиться так, как человек-стажер, поэтому эффективность работы со временем почти не растет.

Проблемы микроменеджмента и обучения ИИ по-настоящему решаются лишь с помощью AI-агентов.
Если же вы работаете с чат-ботами или даже ассистентами, эти проблемы нельзя решить, можно лишь сгладить (см. ниже).
В следующих двух разделах я разберу методы борьбы с микроменеджментом искусственного интеллекта. А в разделе 3 вы найдете конкретные примеры и рецепты экономии времени за счет совместного с ИИ создания инструкций.
1. Организационные и индивидуальные методы экономии времени
На уровне компании время на подготовку контекста можно сократить как минимум тремя путями:
- использовать инструменты ИИ-ассистентов (куда уже встроен необходимый контекст),
- подготовить качественную базу знаний (где AI-агенты смогут сами находить контекст),
- внедрить агентов в рабочие каналы связи компании (где контекст «сырой», но зато актуальный).
С точки зрения индивидуальной работы с ИИ эти подходы приносят мало пользы, поскольку сэкономленное время уходит на настройку ассистентов и агентов. Необходимость самостоятельно изучать новые функции ИИ-инструментов также снижает эффективность. Сложные инструменты требуют больше времени на освоение, а агенты значительно сложнее обычных чат-ботов.
Вольный перевод: "Наверняка где-то есть парень, который использует кучу инструментов для ИИ, но при этом каждый день не завершает ни одной задачи"Существуют и более простые способы сэкономить личное время на подготовке контекста и промптов — в частности, голосовые инструменты и мета-промпты (промпты для написания промптов). Эти способы особенно полезны на первом уровне ИИ-мастерства.
Эта статья посвящена второму уровню, где «промпт-инжиниринг» становится менее важным, а на передний план выходит контекст-инжиниринг.
2. Контекст и инструкции в локальном рабочем пространстве (AI workspace)
На мой взгляд, ключевые методы экономии времени на втором уровне ИИ-мастерства строятся вокруг локальных ИИ-воркспейсов, таких как Claude Cowork, Codex, Cursor, Antigravity. Большинство описываемых ниже приемов сводятся к одной главной идее:
AI-агент должен работать с вами «бок о бок», используя широкий контекст с хранимыми инструкциями. Обычно контекст — это папка на ноутбуке с проектными документами и markdown-файлами.
- «Бок о бок» означает, что вы оба читаете и редактируете одни и те же файлы в понятной для вас обоих структуре.
- «Используя широкий контекст» означает, что агент ориентируется в проекте без ваших объяснений. Он сам найдет нужную подпапку для нового файла или точное место для правок. Такая базовая автономия агента критически важна для избавления от микроменеджмента.
Вот новые типы контекста, которые обеспечивают автономию ИИ:
- Чтобы ускорить работу и тратить меньше токенов, контекст должен содержать аннотации — указания и пояснения для агента о проекте. Для этого в папку проекта и ключевые подпапки помещаются т.н. «контекстные файлы» AGENTS.md или CLAUDE.md. Правила из этих файлов работают даже тогда, когда вы сами о них забыли.
- Помимо правил конкретного проекта, стоит создавать общие инструкции, применимые в разных проектах — лучше всего скиллы: Agent Skills. Скиллы не только экономят время на написание промптов, но и позволяют решать задачи, с которыми «голый» агент просто не справится. Эти markdown-файлы — "навыки" агента, но чтобы не путаться с человеческими навыками, я все-таки называю их англицизмом "скиллы".
- Чтобы не тратить время на ручное обновление markdown-файлов типа 1 и 2, поручите ИИ-агенту генерировать более 80% их содержимого. Например, агент может сам предлагать обновления для файлов своих скиллов после выполнения каждой задачи. И мета-инструкции о таких обновлениях могут находиться в тех же файлах!
Все эти 3 типа контекста я называю словом «инструкции» (guidelines). В отличие от обычных промптов, они хранятся в файлах и используются в совершенно разных ситуациях. В отличие от документов того же воркспейса (или иных артефактов вашей работы), файлы инструкций не представляют самостоятельной ценности — они просто делают воркспейс и работу с ним понятными для ИИ.

Далее я покажу, как применить на практике способы из правой нижней части этой схемы.
3. Как быстро дать ИИ необходимые инструкции
Возможно, вы уже знаете простейшие способы передать контекст ИИ за считаные минуты или секунды:
- показать примеры результатов или артефакты проекта для создания неявного контекста;
- загрузить нужные документы на уровне чата или проекта (Project в ChatGPT/Qwen, Gem в Gemini или Space в Perplexity);
- использовать RAG для извлечения кусков из слишком больших документов — любой современный чат-бот делает это «из коробки».
Однако такого контекста не всегда хватает. Хотя RAG порой отлично справляется, для действительно надежного результата часто требуются четкие хранимые инструкции.
3.1. Контекст проекта
Возьмем пример из продукт-менеджмента. Допустим, в вашем воркспейсе десятки папок: исследования рынка, анализ конкурентов, интервью с пользователями, спецификации фич и планы запуска. Вы просите агента собрать жалобы на удобство интерфейса из последней серии интервью.
Без подсказок агенту придется сканировать каждую папку в поисках интервью. Это тратит токены и время, а также создает риск зацепить похожие документы из других мест. Похоже на то, как дать задачу стажеру в первый же день, не показав, где что лежит.
Контекстные файлы проекта решают эту проблему. Считайте их файлами README.md, написанными для агентов, а не для людей. Эти markdown-файлы с именами AGENTS.md или CLAUDE.md размещаются в корне и ключевых подпапках. Корневой файл описывает общую структуру: «Этот воркспейс содержит материалы продукта Superdraft v2. Интервью с пользователями лежат в research/transcripts, спецификации фич — в backlog, материалы для запуска — в gtm/materials». Контекстный файл внутри папки research/transcripts добавляет детали: «Это расшифровки интервью об удобстве использования. Сосредоточься на жалобах на интерфейс, игнорируй пустую болтовню и мнения о цене».
Получив задачу, агент читает ближайший контекстный файл и сразу переходит в нужное место, не сканируя весь проект. Эта иерархическая структура делает подход невероятно мощным: каждая папка содержит ровно столько контекста, сколько нужно агенту для самостоятельной работы по данной теме.
Вы пишете эти файлы один раз, и они работают для десятков будущих задач. И вам даже не нужно писать их самостоятельно — об этом в следующем разделе.
3.2. Скиллы (Agent Skills) и непрерывное улучшение
Если контекстные файлы (AGENTS.md) описывают, где что лежит и что означает, то Agent Skills определяют, как с этим работать. Скиллы (навыки) — это стандартизированные наборы инструкций в формате markdown (а иногда и инструментов), которые активируются ровно в нужный момент.
Вернемся к нашему примеру: получив команду «организовать недавние интервью», агент находит расшифровки и понимает их суть по контекстному файлу. Затем он запускает скилл «Тематический анализ», который срабатывает на фразу в описании скилла «Используй, когда пользователь хочет структурировать или проанализировать фича-реквесты, отчеты об ошибках, транскрипты и т.д.». Скилл дает агенту четкую методику: сгруппировать отзывы по темам, расставить теги важности и выдать стандартную сводную таблицу. Без этого скилла вам пришлось бы каждый раз объяснять процесс с нуля или мириться с непредсказуемым результатом.
Скиллы могут быть заточены под конкретные профессии, типы данных (например, файлы .docx или .xlsx) или внешние инструменты (вроде браузера). Они также могут описывать общие процессы — например, предлагать обновления для самого скилла и других файлов контекста на основе опыта, полученного при выполнении текущей задачи.
Итак, как сэкономить время за счет совместной работы с ИИ над скиллами?
- Когда вы впервые решаете задачу с ИИ, ведите агента шаг за шагом в чате — например, объясняя, как группировать отзывы. Т.е. сначала все как в ChatGPT. Но затем попросите его сохранить этот процесс как многоразовый скилл. Бегло просмотрите созданный скилл, но не тратьте время на его серьезную переделку.
- Для повторяющихся задач, уже описанных в скилле, каждый следующий раз начинается со всё более высокой планки. Просто активируйте скилл коротким промптом. В худшем случае вы выбросите первый результат и попросите сделать заново с уточненными вводными. Но чаще нужно просто продиктовать агенту конкретные правки, которые нужно внести в результат (удобнее голосом, так как объем правок бывает большой).
- Самое главное: когда результат вас устроит, попросите агента обновить скилл и внести туда общие правила, чтобы избежать подобных ошибок в будущем. Обратите внимание: это не будет работать, если в пункте 2 вы будете вносить правки своими руками, а не попросите об этом агента.
- Более того, можно обойтись и без явного запроса на обновление — это будет надежнее, чем пункт 3. Например, вы просто выражаете одобрение, а агент автоматически (исходя из имеющихся у него мета-инструкций) обновляет нужные скиллы на основе вашей обратной связи.
Кстати, это не единственный способ научить ИИ учиться на правках и обратной связи от людей.
- Здесь описаны похожие идеи обучения ИИ на основе отклоненных вариантов.
- А подробное системное описание подобных идей с примерами вы найдете в методике Oper8. Ключевая идея Oper8 — это как раз двойной цикл обучения ИИ-системы компании.
Таким образом, совместная разработка повторно используемых скиллов с ИИ позволяет радикально сократить оверхед на микроменеджмент.
3.3. Типичные ошибки со скиллами
Некоторые пытаются создать идеальный скилл до его использования. Но вы можете потратить часы на составление подробных правил и все равно упустить реальные подводные камни, которые всплывут только на практике.
Другие пытаются редактировать скилл прямо по ходу работы. Этот подход ведет к постоянному переключению контекста в голове (переключение между SKILL.md и чатом), требует больше итераций и часто снижает качество.
Чтобы сэкономить время, сфокусируйтесь на конкретных задачах. Относитесь к инструкциям/скиллам как к побочному продукту этого непрерывного взаимодействия.
Хотя аудит созданных ИИ файлов контекста «глазами» и необходим, более 80% изменений должны рождаться в ходе обсуждения конкретных задач. Это гарантирует, что хранимые инструкции (скиллы, правила, контекстные файлы проекта) решают реальные проблемы, с которыми сталкивается ИИ, а не просто отражают ваши абстрактные пожелания.
Но при этом такие «изменения на будущее» должны фиксироваться в файлах не по ходу работы, а все-таки по окончанию.
Опытным пользователям ИИ во всем этом помогают мета-скиллы — руководства, помогающие ИИ создавать, оценивать и улучшать другие скиллы. О них я рассказываю здесь.
Резюме: От микроменеджмента к реальной экономии времени
Таким образом, вопрос «Почему у меня нет свободного времени, хотя использую умные модели?» похож на ситуацию начинающего руководителя «Почему у меня нет времени, хотя у меня умные подчиненные?».
Ответ прост: все дело в микроменеджменте. Если мы не задействуем способность AI-агентов к самообучению, огромное количество времени будет уходить на подготовку контекста, оценку результатов и бесконечные правки.
Применение классических приемов менеджмента к ИИ помогает устранить эти узкие места:
- Давайте агенту не только промпты, но и доступ к широкому контексту, причем этот контекст должен содержать не только документы, но и инструкции к ним. Это похоже на онбординг для живых сотрудников.
- Работайте с ИИ сообща, превращая контекст конкретной задачи и правки конкретных результатов в хранимые общие инструкции. Это подобно тому, как менеджер улучшает регламенты для сотрудников вместе с ними, причем по факту обнаруженных проблем, а не пишет их в одиночку «от балды».
- Совершенствуйте навыки оценки результатов и обратной связи, чтобы сократить число итераций. Впрочем, если вы менеджер, вы это и так уже умеете.

В следующей статье я более конкретно опишу применение мета-скиллов. На практике это оказывается отнюдь не просто: если вы через мета-скиллы дадите агенту слишком много бесконтрольной автономности, то почти гарантированно получите не улучшение, а ухудшение результатов со временем.
Подписывайтесь на наш
телеграм-канал Кактус, чтобы не пропускать митапы, статьи и другие материалы о лучших практиках применения ИИ в компаниях и для личной эффективности руководителей.