How to Work and Compound with AI
Eugene Yan делится системой эффективной работы с ИИ, построенной на пяти принципах: качественный контекст, кодирование вкуса в конфигурацию, дешёвая верификация, делегирование всё более крупных задач и замыкание обратной связи. Автор организует рабочее пространство так, чтобы модель легко находила нужные файлы, использует иерархию CLAUDE.md для хранения предпочтений и INDEX.md для аннотированных ссылок. Для повторяющихся задач он создаёт «навыки» — markdown-процедуры, которые модель загружает по требованию. Верификация выстроена в виде лестницы: от автоматических хуков форматирования до LLM-ревью и параллельных сессий, где вторая модель следит за первой. Yan одновременно запускает от трёх до шести сессий Claude Code, используя git worktrees и tmux, а узким местом становится скорость написания спецификаций и ревью результатов. Он подчёркивает, что те же принципы применимы к работе с людьми и к проектированию агентных систем на уровне команды и организации.
Как работать с ИИ и получать накопительный эффект
[ ai productivity mechanism ] · 13 мин. чтения
Как эффективно работать с ИИ? Каков рабочий процесс, как он масштабируется и как улучшать систему со временем? В идеале всё должно накапливаться. Каждый готовый артефакт — код, документация, анализ, принятые решения — становится контекстом для следующей сессии. А каждое исправление обновляет конфигурацию, снижая число будущих ошибок. Я всё ещё учусь, но повторял свои ответы достаточно часто, чтобы записать их здесь — в следующий раз просто отправлю ссылку.
Если вы регулярно пользуетесь ИИ, многие из этих практик вам уже знакомы. Тем не менее базовые принципы применимы широко: давайте качественный контекст, кодируйте свой вкус в конфигурацию, упрощайте верификацию, делегируйте всё более крупные задачи и замыкайте обратную связь. Если какая-то практика не подходит — адаптируйте принцип и придумайте свою. И обратите внимание при чтении: ничего из этого не специфично именно для ИИ. Так вы вводите в курс дела и работаете с любым новым коллегой.
• • •
Контекст как инфраструктура
Помогайте моделям ориентироваться в вашем контексте. Например, весь мой код живёт в ~/src, а вся интеллектуальная работа — в ~/vault (организована в projects/, notes/, kb/ и т. д.). Когда работа организована, модели проще извлекать контекст с помощью grep или glob. А чистое дерево каталогов упрощает навигацию, поиск и использование предыдущего кода, проектных документов, аналитики и т. д. для улучшения текущей работы.
Подключайте модели к контексту вашей организации. Модели могут извлекать пользу из организационных знаний, которые, скорее всего, хранятся в Slack, Drive, Mail и т. д. Для большинства из них существуют MCP для Claude Code, Cowork, Claude.ai. Помимо этого, я веду INDEX.md для каждого проекта. Это аннотированный указатель релевантных документов и каналов: каждая запись включает URL, владельца и краткий абзац, объясняющий содержание и когда стоит читать. Аннотации очень помогают. Голый список URL заставляет модель открывать каждую ссылку, чтобы понять, что релевантно, — это трата времени и контекста. Аннотируя заранее, мы выполняем тяжёлую работу один раз и сохраняем её в индексе.
Вводите каждую новую сессию в курс дела как нового сотрудника. С каждой новой сессией модель начинает с чистого листа. Поэтому полезно относиться к проектному CLAUDE.md как к документу для онбординга, который мы вручили бы новому коллеге в первый день. Claude просканировал мои проектные CLAUDE.md-файлы и отметил, что они включают глоссарии аббревиатур, кодовые названия проектов и коллег с одинаковыми именами. Также у меня есть рекомендуемый порядок чтения в CLAUDE.md — например, сначала просмотреть INDEX.md, потом TODOS.md, и наконец конкретные тематические заметки.
Создайте свой слой памяти. По умолчанию модели не помнят, что происходило в прошлой сессии, поэтому всё ценное нужно записывать на диск. Мой слой памяти разделён на два сегмента. ~/vault хранит факты: состояние проекта, артефакты и доменные знания; ~/.claude (вместе с CLAUDE.md, skills/, guides/) содержит мои предпочтения, рабочие процессы и личный вкус. Первое обеспечивает контекст, второе — конфигурацию.
Вкус как конфигурация
Начните с ~/.claude/CLAUDE.md. Claude читает этот файл в начале каждой сессии. Я воспринимаю его как поведенческий контракт. Мой CLAUDE.md содержит предпочтения: насколько прямолинейным быть, когда возражать, как обрабатывать ошибки, чему меня учить и т. д. Вот сокращённая версия:
Задавайте область действия по каталогам: глобальная, затем репозиторий, затем проект. Предпочтения, которые действуют везде (поведение, долгосрочные цели, обучение), кладите в ~/.claude/CLAUDE.md. Конвенции для конкретного репозитория (линтинг, именование, пулл-реквесты) — в корень репозитория. Проектный контекст (структура каталогов, доменные знания) — в каталог проекта. Когда вы запускаете Claude Code в подкаталоге, он поднимается по дереву и загружает каждый CLAUDE.md. А когда модель переходит в подкаталог в процессе сессии, она подхватывает и его CLAUDE.md. Подробнее в документации.
Когда CLAUDE.md становится слишком длинным, выносите части наружу. Длинный CLAUDE.md может стать налогом на контекст. Он загружает всё в каждую сессию, даже если сессии это не нужно. Решение — рефакторинг фрагментов в гайды, которые загружаются лениво. Не используйте @import (потому что это просто инлайнит содержимое). Вместо этого укажите в CLAUDE.md, чтобы модель читала их по мере необходимости. Так сессия, в которой вы строите эвалы, пропустит гайд по написанию документации. Пример секции гайдов:
Если вы делаете что-то ≥ раза в неделю, сделайте это навыком. Навык (skill) — это markdown-файл с именем, триггером и процедурой, который модель загружает по требованию. Думайте о навыках как о рабочих процессах, написанных на markdown. Они могут включать логику. Например, мой навык /polish смотрит на дифф артефакта. Если он выдаёт метрику — запускает соответствующий эвал. Если рендерится в браузере — проверяет вывод через Claude in Chrome. Если ни то, ни другое — запускает код и читает вывод или ошибку. Навыки кодируют и шаги, и суждение о том, какие шаги применять. Вот несколько моих:
/polish: проверяет на баги, упрощает код, верифицирует вывод (через эвалы, Claude in Chrome или другим способом), итерирует, пока не останется критических замечаний, создаёт черновик PR /write: берёт у меня интервью для плана, запускает исследовательских субагентов, пишет черновик, даёт обратную связь через adversarial-критика, итерирует до отсутствия критических замечаний /daily: читает мой календарь, Slack, PR-ы, вчерашний лог и т. д. и составляет приоритеты на сегодня
Я стараюсь держать SKILL.md компактным и сфокусированным на рабочем процессе и маршрутизации. Знания — шаблоны и скрипты — хранятся в отдельных файлах, которые модель читает и запускает только по необходимости, как и лениво загружаемые гайды.
Создавайте навыки по принципу «сделай задачу один раз, потом попроси модель превратить это в навык». Так я создаю большинство навыков. Сначала я выполняю задачу один раз, интерактивно, в обычной сессии. Потом прошу модель превратить то, что мы только что сделали, в навык. Затем запускаю навык на той же или аналогичной задаче. Неизбежно приходится корректировать вывод — я делаю это в той же сессии, чтобы обратная связь осталась в транскрипте. Наконец, прошу модель обновить навык на основе исправлений и обратной связи. Также можно заполнить навык примерами желаемого результата. Попросите модель извлечь паттерны — как вы организуете код, структуру и тон документации.
Совершенствуйте навыки через транскрипт, а не редактируя файл напрямую. Первая версия навыка редко работает идеально, потому что она переобучена на исходную сессию. Это нормально. Когда вы запускаете навык и нужно поправить вывод — корректируйте прямо в сессии. Старайтесь не открывать и не редактировать SKILL.md напрямую. Обратная связь внутри сессии даёт модели пары «до и после», которые накапливаются в транскрипте — вот что мы сделали, вот чего я хотел и почему. Когда вывод станет правильным, попросите модель объединить обратную связь в навык. После нескольких раундов навык сходится, и вам почти не нужно редактировать финальный результат.
Тем не менее не каждой задаче нужен весь этот контекст. Для мозгового штурма, исследований и черновиков я люблю использовать простой режим (CLAUDE_CODE_SIMPLE=1 claude). Здесь CLAUDE.md по-прежнему загружается, но агентная обвязка — хуки, навыки, тяжёлые инструментальные циклы — нет. Так я оказываюсь ближе к модели, а это то, что нужно, когда думаешь вслух, а не отгружаешь готовое.
Верификация ради автономии
Сдвигайте верификацию влево — ловите ошибки на этапе написания. Я представляю верификацию как лестницу. Внизу — дешёвые детерминированные проверки; наверху — дорогие, требующие суждения. Мы хотим устранять проблемы на как можно более низкой ступеньке. Ближе к основанию — post-edit хуки, которые запускают ruff format, ruff check --fix на файлах, которые модель только что обновила. Это происходит детерминированно и не стоит токенов. Выше по лестнице — тесты, эвалы, LLM-ревью и т. д.
Упрощайте модели верификацию работы. Давайте модели петли обратной связи для улучшения результата. Если система выдаёт метрику — дайте модели запустить эвал и оптимизировать её. Если вывод рендерится в браузере — дайте модели проверить его через Claude in Chrome. Если ни то, ни другое — дайте модели запустить код и прочитать ошибку. Например, при сборке Docker-образов я позволяю модели собрать, прочитать ошибку, отредактировать Dockerfile и пересобрать. Если я настраиваю обвязку, модель запускает эвалы, читает транскрипты и исправляет сбои. При создании дашборда модель проверяет в Chrome, что тултипы рендерятся, подписи не наезжают друг на друга, а нарратив соответствует числам.
Для длительных задач пусть модели следят за моделями. Долгие сессии могут отклоняться по мере накопления ошибок. Одно из решений — запустить вторичную сессию со свежим контекстом, которая читает исходную спецификацию и последние ходы основной сессии. Мой минимальный сетап использует две панели tmux: одну для основного разработчика, вторую для парного программиста. Начальные инструкции и последующие промпты дописываются в общий файл. Периодически парный программист запускается, сверяет спецификацию с последним транскриптом основной сессии и, если что-то не так, даёт обратную связь для корректировки курса.
Это можно делать по-разному. Например, парный программист может отслеживать дрейф исполнения — правильно ли модель выполняет задачу? Это локальные и тактические проблемы: игнорирование ошибки, неверная метрика, отклонение от спецификации. Есть также дрейф направления — ту ли задачу решает модель? Это более масштабные стратегические вопросы, возникающие, когда модель неверно интерпретирует исходный замысел и часами строит не то. Дрейф исполнения проверяйте часто, дрейф направления — периодически.
Масштабирование через делегирование
Делегируйте всё более крупные блоки работы. Иногда мы программируем в паре с моделями: короткие задачи, быстрая обратная связь, постоянный контроль. Это хорошо работает для быстрых итераций, исследовательского анализа и прототипирования. Но с появлением всё более сильных моделей стоит стремиться к делегированию более крупных задач. Объясните свой замысел, ограничения и критерии успеха заранее, а потом дайте модели работать. Нельзя делегировать то, что нельзя верифицировать, поэтому сначала нужно определить критерии успеха и метрики. Суть сдвига — от пошаговых инструкций к проработке планов, которые модель выполняет от начала до конца:
«Имея эти наборы эвалов, собери изолированные контейнеры для каждого набора и проверь, что каждый собирается. Затем выполни полный запуск, запиши метрики эвалов и транскрипты, используй субагентов для чтения транскриптов и подтверждения корректности прогона. Запусти каждый эвал n раз для доверительных интервалов. Наконец, сгенерируй отчёт, проверь, что он соответствует гайду по отчётам, и отправь мне в Slack результаты и URL отчёта.»
Запускайте сессии параллельно и находите узкое место. Делегирование крупных задач означает, что можно запускать больше задач одновременно. Claude говорит, что я обычно веду от трёх до шести сессий параллельно. Узкое место сместилось от выполнения работы к написанию чётких спецификаций и достаточно быстрому ревью результатов, чтобы конвейер не простаивал — середина выхолащивается. Если параллельные сессии работают в одном репозитории, используйте git worktrees, чтобы каждая сессия получила свой checkout и не перезаписывала изменения других.
Обеспечьте простоту наблюдения за сессиями. При запуске нескольких сессий мне нужно знать их состояние и какая из них требует внимания. На моём Mac stop-хук проигрывает звук при завершении сессии (пример ниже). Заголовки моих tmux-окон используют статусный эмодзи (⏳ в работе; 🟢 завершено) и короткую метку от Haiku, чтобы я знал, чем занята каждая панель. Строка статуса Claude Code показывает расход контекста и текущий режим. Всё вместе: звук stop-хука сигнализирует о завершении задачи, заголовок tmux показывает какой именно, а строка статуса даёт детали.
# Пример stop-хука alert "Stop": [ { "hooks": [ { "type": "command", "command": "if command -v afplay >/dev/null 2>&1; then afplay -v 1.0 /System/Library/Sounds/Glass.aiff; else tput bel; fi" } ] }
Можно проверять прогресс, даже если вы не за компьютером. /remote-control в Claude Code делает это просто. По дороге на работу или в очереди я открываю вкладку кода в приложении Claude, чтобы увидеть, что запущено и что заблокировано, и при необходимости разблокировать застрявшую сессию дополнительным контекстом или новыми инструкциями. Это позволяет сессиям двигаться, а не простаивать часами. Но делайте это, только если есть что-то срочное — не когда стараетесь быть в моменте или вышли на прогулку.
Замыкание цикла
Поддерживайте богатство контекста, работая открыто. Когда мы ведём работу в общих документах, репозиториях и каналах, всем — включая модели — проще находить и извлекать пользу из контекста. То, чем мы делимся сегодня, завтра становится частью организационного контекста. Попробуйте простой тест: сможет ли новый коллега воспроизвести вашу работу за прошлую неделю, используя только общедоступный контекст? Если да — вы хорошо вносите вклад в контекст организации; если нет — ценный контекст застрял у вас в голове. Я частично автоматизирую это через инструкции в CLAUDE.md: публиковать короткие апдейты в канале рабочего журнала после завершения значительной задачи со ссылками на артефакт, PR или документ.
Добывайте обновления конфигурации из транскриптов. Пусть модель читает транскрипты прошлых сессий и находит пробелы. Когда я проанализировал ~2 500 своих прошлых реплик, заметная доля содержала фразы вроде «а можешь ещё…», «ты проверил…», «всё ещё неправильно» и т. д. Это говорит о том, что модель должна была сделать что-то без подсказки, и мне нужно обновить CLAUDE.md или навык, либо что шаг верификации отсутствует или сломан. Счётчики показывают, как часто происходит та или иная коррекция, а транскрипты — что именно пошло не так. Вот почему я вношу исправления внутри сессии — чтобы использовать транскрипт как входные данные для следующего обновления CLAUDE.md или навыков.
Периодически рефакторьте и чистите. По мере роста конфигурации правила могут пересекаться или противоречить друг другу. Если модель игнорирует правило, причиной может быть другое правило, которое ему противоречит. Решение — периодический рефакторинг. Каждое правило или предпочтение должно жить ровно в одном месте (хотя критически важные инструкции можно дублировать в основном CLAUDE.md). Также я проверяю наличие случайных settings.json на уровне каталогов и консолидирую их обратно в ~/.claude.
• • •
Хотя конкретный сетап, скорее всего, изменится по мере улучшения моделей, принципы останутся актуальными: давайте качественный контекст, кодируйте свой вкус, делайте верификацию дешёвой, делегируйте больше и замыкайте цикл. По сути, мы обучаем коллаборанта — по одной обратной связи за раз. И если задуматься, эти же принципы применимы к работе с командой из людей.
Чтобы начать, дайте модели прочитать этот SETUP.txt и помочь вам применить его. А ещё мне было бы интересно узнать, какие практики или принципы оказались ценными для вас — пишите в комментариях или свяжитесь со мной!
P.S. Это не только про персональные инструменты. Это также применимо к проектированию агентных обвязок, установлению командных норм и построению организационной инфраструктуры. Попробуйте перечитать с учётом этих уровней.
Если материал оказался полезен, пожалуйста, цитируйте его так:
Yan, Ziyou. (May 2026). How to Work and Compound with AI. eugeneyan.com. https://eugeneyan.com/writing/working-with-ai/.
или
@article{yan2026default, title = {How to Work and Compound with AI}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2026}, month = {May}, url = {https://eugeneyan.com/writing/working-with-ai/} }
Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.