«Мы придаём форму нашим зданиям, а потом они придают форму нам».
— Уинстон Черчилль, 1943
«Какой ИИ лучше?» — частый и почти бесполезный вопрос. Модели сменятся через полгода, а проект держится не на одном сервисе, а на связке: где лежат входы, кто ищет источники, кто разбирает интервью, где живёт память, куда уходит повторяемая работа и кто проверяет на каждом стыке. Разбираю рабочее место консультанта как кухонную бригаду: семь модулей, роль каждого и место проверки.
Фразу из эпиграфа Черчилль сказал в октябре 1943 года, когда решали, как восстанавливать разрушенный бомбой зал палаты общин. Он настоял на старой тесной планировке со скамьями друг напротив друга: устройство зала, считал он, определяет, как в нём спорят. С рабочим местом консультанта то же самое. Как соберёшь, так потом и будешь работать.
Второй пример — кухня. В 1890-х, работая в отеле «Савой», Огюст Эскофье свёл ресторанную кухню в бригаду: у каждой станции — соусы, рыба, гарниры, выпечка — свой старший повар и своя зона ответственности, над ними шеф. Систему он закрепил в «Кулинарном путеводителе» 1903 года, и её наследие видно в профессиональных кухнях до сих пор. Сила бригады не в лучшем поваре, а в том, что каждый знает свою станцию и понятно, где блюдо переходит из рук в руки.
В AI-рабочем месте так же. Важен не лучший сервис, а роли модулей и стыки между ними: результат одного становится входом другого, и именно там нужна проверка. Для каждого модуля стоит ответить на пять вопросов: какую задачу он решает, что получает, что отдаёт, что в результате проверять и где риск для конфиденциальности.
Сквозной пример — та же условная диагностика, что в прошлой статье серии: две недели, причины внеплановых простоев, двенадцать интервью, выгрузка простоев за полгода, регламенты ТОиР, фото с обхода. Пример собирательный, а не про конкретного клиента. Посмотрим, через какие станции он проходит.
Семь модулей
1. Входы
Всё, что приходит от клиента и с площадки: запрос, записи интервью, выгрузки, регламенты, фото, заметки обхода. Задача модуля — не анализ, а порядок: одно место, понятные имена, у каждого файла источник, дата и уровень конфиденциальности. В примере выгрузка простоев лежит с пометкой, из какой системы и за какой период она взята, а фото — с участком и датой. Интервью записываются — с согласия собеседника — и расшифровываются. Для встреч самой команды в обзоре ИИ-инструментов для руководителя проектов я советовал договориться: «у нас по умолчанию пишется всё». Нерасшифрованная встреча для остальных модулей не существует.
Проверка на стыке: по любому файлу можно понять, откуда он и можно ли отдавать его модели.
2. Исследование
Поиск с источниками: отраслевой контекст, практики, типовые решения. Здесь работают сервисы, которые отвечают со ссылками, — Perplexity и аналоги. Выход модуля — не «ответ», а ответ со ссылками. В примере — типовые причины простоев похожего оборудования и устройство регламентов ТОиР. Это гипотезы для диагностики, а не факты о клиенте.
Проверка: открыть первоисточник, посмотреть дату, спросить себя, применимо ли это к этому клиенту.
3. Анализ интервью и документов
Модели с длинным контекстом — Claude, ChatGPT и аналоги — разбирают интервью, регламенты и протоколы: темы, противоречия, гипотезы, вопросы на следующий день. В разборе диагностики без аналитиков я писал, что лично мне лучше всего сработал Claude с общим контекстом, — но рейтинг тут вторичен.
Если нужно отвечать строго по своему набору документов — регламентам, протоколам, отчётам клиента, — подходит NotebookLM и похожие сервисы: они отвечают по загруженным документам и показывают, из какого источника цитата.
Проверка: каждая гипотеза ссылается на конкретное интервью или документ, а факт отделён от мнения.
4. Excel и PowerPoint
Числа и слайды. ИИ помогает с формулами, Парето, описанием графиков и черновиком управленческой истории. Генераторы слайдов и встроенные помощники хороши для первого черновика и стандартных форматов. Но итоговую презентацию всё равно приходится докручивать руками — и часто быстрее сделать это самому, чем объяснять агенту, что не нравится.
Проверка: формулы воспроизводимы, и каждую цифру на слайде можно проследить до строки данных.
5. Память проекта
Место, где живут факты, решения, гипотезы, источники и открытые вопросы, — общее для людей и для модели. Без него модули 2–4 каждый раз начинают с нуля, а команда вечером сверяет версии. Это отдельная тема, о ней следующая статья серии.
Проверка: новый участник за полчаса понимает, что уже известно и что решено.
6. GitHub и сервер
Модуль, который, по моим наблюдениям, часто пропускают. Когда одна и та же операция повторяется — разметка выгрузки, сводка интервью по шаблону, еженедельный отчёт, — её выгоднее превратить в маленький инструмент: скрипт, бота, простое веб-приложение. GitHub хранит код, версии и задачи. Сервер — место, где инструмент работает, а не лежит в чьём-то ноутбуке. В «Базовом минимуме» я называл сервер «штаб-квартирой» для агентов.
Свой пример. Отраслевые новости руками не отследить — источников сотни. Я собрал под это сервис, которым сам пользуюсь каждый день: он раз в день обходит источники, отбирает важное и даёт короткую повестку — в Telegram или на сайте. Потом тем же способом появился дайджест консалтингового рынка. Ровно эта логика: работа, которую руками каждый день не потянуть, уходит инструменту, а мне остаётся чтение.
Писать код самому для этого не обязательно — его пишет агент: Claude Code, Cursor и аналоги. Консультант ставит задачу и принимает результат.
Проверка: у инструмента есть README и тест-кейсы, и понятно, кто его чинит.
7. Доступы и контроль
Сквозной модуль, который касается всех остальных. Какие данные можно отдавать каким сервисам. Ключи доступа — в переменных окружения, а не в документах и не в репозитории. Публичное, внутреннее и конфиденциальное хранится раздельно. Понятно, у кого из команды к чему доступ и что в какой сервис уже отправлялось. Перед отправкой клиенту — пять проверок: подтверждены ли факты, воспроизводятся ли расчёты, следует ли вывод из доказательств, учтён ли контекст клиента, реализуемо ли предложенное.
Проверка: правила доступа записаны один раз на проект, а не придумываются в момент отправки файла.
Как модули связаны
Поток выглядит так: входы → исследование и анализ → Excel и слайды → клиенту. Память — в центре: все модули читают из неё и пишут в неё. Сервер подключается, когда работа начинает повторяться. Доступы стоят на каждом стыке.
Ошибки живут не внутри модулей, а на стыках. Расшифровка без пометки источника превращается в гипотезу без привязки, а та — в цифру на слайде, которую никто не может объяснить.
Как это выглядит в нашем примере:
- День 1. Интервью и выгрузка ложатся во входы с пометками. Исследование даёт список типовых причин простоев — в память, с пометкой «гипотеза».
- День 2. Анализ интервью находит расхождение: начальник смены винит запчасти, механик — поздний вызов. Оно уходит в память как открытый вопрос. В Excel — Парето по причинам и доля записей с пустым полем причины.
- День 3. Разметку выгрузки делают уже в третий раз — её отдают агенту сделать скриптом. Черновик истории для промежуточной встречи собирается из памяти, и у каждой цифры есть ссылка.
Итог примера — не набор чатов, а связка, в которой у любой цифры на слайде есть путь назад до файла.
С чего начать
Не со всех семи сразу. Минимум — входы, анализ, память и доступы: без них остальное ускоряет хаос. В записи про операционную модель я писал, что ИИ — усилитель: чёткие процессы становятся ещё чётче, хаотичные — хаотичнее и быстрее. С рабочим местом то же самое. Исследование добавляется, когда нужен внешний контекст. GitHub и сервер — когда появилась первая операция, которую вы делаете в третий раз.
Для честности — мой нынешний набор. Каждый день в работе Perplexity, Claude Cowork и Claude Code, OpenRouter, GitHub, VPS, Docker и Coolify. Это не рекомендация сервисов: через полгода список изменится, а модули останутся. Попробуйте разложить по семи модулям свой набор — пустые места видны сразу.
Риски и ограничения
- Зоопарк сервисов. Каждый новый модуль — ещё один стык и ещё одно место утечки. Модуль добавляется под задачу, а не потому, что вышел новый сервис.
- Конфиденциальность. Что в какой сервис можно отдавать, решается один раз на проект и записывается в модуль доступов, а не в момент отправки.
- Привязка к инструменту. Если контекст живёт внутри одного сервиса, его смена ломает работу. Шаблоны и память держите в простых файлах, которые прочитает любой.
- Сервер — это ответственность. Демо на своём сервере — не рабочая система клиента: резервные копии, доступы и вопрос «кто чинит» появляются в первый же день.
- Настройка без задачи. Рабочее место, которое собирают ради самого рабочего места, превращается в хобби. Собирайте под живой проект.
Как такое рабочее место работает на живом проекте, покажу на бесплатном практикуме 31 октября. Не обзор сервисов, а один процесс целиком — на трёхдневной диагностике на стройплощадке, которую наша команда провела в сентябре 2026 года: от интервью и Excel-файлов до управленческой истории и прототипа клиентского инструмента — и где мы проверяли за моделью выводы. После практикума придут запись, таймкоды и рабочий шаблон из демонстрации.
Записаться на бесплатный практикум — или в Telegram: @AI_native_reg_bot