В интернете всё чаще встречается один и тот же совет: если хотите получить от искусственного интеллекта больше, чем случайные ответы, сначала расскажите ему о себе. Соберите в одном месте информацию о своей работе, целях, принципах, предпочтениях, стиле общения. Добавьте примеры текстов, описание бизнеса, правила и другие сведения, которые приходится повторять из чата в чат. Получится что-то вроде внешней памяти или «второго мозга».
В этом совете есть здравое зерно. Когда ИИ понимает, кто вы, чем занимаетесь и какого результата ждёте, разговор действительно становится содержательнее. Не нужно каждый раз начинать с длинного вступления. Ответы меньше похожи на универсальные советы для неизвестного человека.
Но довольно быстро возникает следующий вопрос: что делать с этим «мозгом» дальше?
Сначала в рабочей папке лежит несколько понятных документов. Затем туда добавляются заметки, результаты исследований, клиентские материалы, черновики статей, инструкции, новые версии файлов, списки задач. Появляются вложенные папки и связи между ними. Система вроде бы знает всё больше, но работать с ней не обязательно становится проще. Искусственному интеллекту приходится проходить по растущему массиву, определять, что относится к текущей задаче, отличать действующее решение от старой версии и искать среди десятков файлов то самое зерно, которое нужно сейчас.
Проблема не в том, что файлов стало много. Проблема в том, что одна папка начинает отвечать сразу за всё.
Мы столкнулись с этим вопросом не после того, как успели создать большую свалку. Разделение было заложено ещё при первых экспериментах с файловой работой. Но по мере развития системы нам пришлось последовательно отвечать на более сложные вопросы: как самостоятельные проекты узнают друг о друге, что должно быть общим, где хранить текущее состояние, как передавать задачу из одного направления в другое и как продолжать работу в новом чате.
В этой статье я покажу архитектуру, которая сложилась у нас на практике. Она не является единственно правильной. Её не нужно копировать папка в папку. Это пример принципа: как разделить ответственность за контекст, сохранить связи между направлениями и не заставлять ИИ каждый раз изучать всю вашу жизнь ради одной конкретной задачи.
В конце статьи можно скачать два файла. Первый — визуальное PDF-руководство со схемами. Второй — подробный Blueprint в Markdown, рассчитанный в том числе на анализ другим ИИ. Их можно загрузить в свою рабочую среду и попросить помочь адаптировать систему под ваши задачи.
От обычного чата к рабочей системе
Моя работа с ИИ начиналась так же, как у большинства людей. Открыл чат, задал вопрос, получил ответ, что-то скопировал, что-то переписал. Если результат был полезным, использовал его дальше. Если разговор заканчивался, в следующий раз значительную часть контекста приходилось восстанавливать заново.
Для разовых задач этого достаточно. Узнать значение термина, придумать несколько вариантов заголовка или быстро структурировать заметку можно и в пустом чате. Но когда ИИ подключается к реальной работе, ограничения становятся заметнее. Чтобы обсудить сайт, нужно снова объяснить его структуру и принятые решения. Чтобы подготовить ответ клиенту — рассказать, как устроена коммуникация и какие условия уже согласованы. Чтобы вернуться к статье — напомнить, что в ней было решено и почему.
Следующим этапом стали проекты и связка ChatGPT с Claude. ChatGPT помогал обсуждать задачи, определять направление и собирать поручения. Claude на тот момент дал нам практическую возможность работать с локальной файловой структурой: читать проектные инструкции, обращаться к материалам и сохранять результаты так, чтобы следующий разговор мог продолжить работу.
Подробно об этом переходе я уже писал в статье «Как ИИ перестал быть просто чат-ботом». Тогда система только начинала развиваться. Главное изменение уже произошло: ИИ перестал быть отдельным окном для вопросов и стал частью рабочего процесса.
Важно уточнить одну деталь. Мы не складывали все сведения в одну папку, чтобы потом спасать её от хаоса. Когда начали проектировать первые рабочие направления, мы заранее разобрали мои задачи и решили, что работа с клиентами, сайт, контент и другие области должны существовать отдельно. У них разные источники, правила, состояния и результаты. Смешивать их было бы удобно только первые несколько недель.
Сложнее оказалось понять, как эти самостоятельные области будут взаимодействовать. Если полностью изолировать проекты, они начнут жить в собственных мирах. Проект сайта не узнает, что в клиентской работе появился новый кейс. Общее рабочее пространство не поймёт, куда направить задачу. Одно и то же правило придётся копировать в несколько мест, а затем следить, чтобы все копии обновлялись одновременно.
Поэтому архитектура развивалась в двух направлениях. Мы сохраняли самостоятельность проектов и одновременно создавали ограниченные общие слои: долгосрочный контекст, карту направлений и понятный способ передачи работы.
Позже эта конструкция была перенесена в локальную среду Work десктопного приложения ChatGPT с доступом к разрешённым папкам компьютера. Основной принцип не изменился. Изменились возможности и глубина интеграции: теперь одна рабочая среда могла не только обсуждать задачу, но и читать проектные правила, обновлять состояние, создавать файлы и связывать работу нескольких направлений.
Так появилась нынешняя версия системы. Не как законченный продукт, который однажды спроектировали и больше не трогали, а как рабочая архитектура, которая уточняется при появлении реальной проблемы.
Почему одной папки со знаниями становится мало
Представим простую конструкцию. В одной папке лежат восемь документов: кто вы, чем занимаетесь, как устроен бизнес, какой у вас стиль, какие услуги вы предлагаете и как предпочитаете работать. ИИ читает их, превращает содержание в связанные заметки и начинает отвечать по этой базе.
Это уже намного полезнее пустого чата. Агент может ссылаться на источники, видеть связи и честно говорить, когда нужной информации нет. К базе можно подключить сбор новых материалов, повторяемые навыки, бота или другие инструменты.
Но затем появляются реальные задачи.
Допустим, человек одновременно развивает сайт, работает с клиентами, ведёт образовательный проект и использует ИИ для личных решений. В общей папке оказываются правила публичных текстов, история переговоров, коммерческие предложения, структура сайта, материалы курса, финансовые заметки, исследования и бытовые предпочтения.
Формально всё это относится к одному человеку. Практически — это разные области ответственности.
Для статьи на сайте не нужна вся история клиентских переговоров. Для ответа клиенту не нужно читать архитектуру блога. Для выбора компьютерного кресла могут быть полезны сведения о росте, здоровье, рабочем месте и бюджете, но совершенно не нужны правила оформления коммерческого предложения.
Чем больше общий массив, тем дороже становится выбор контекста. Я говорю не только о технической стоимости обработки. Растёт время на поиск, вероятность прочитать лишнее, риск опереться на устаревшую копию и сложность понимания, куда сохранить новое решение.
Даже граф связей не решает эту проблему полностью. Он помогает увидеть отношения между заметками, но не определяет, кто отвечает за конкретный тип знания. Если в одной сети одновременно лежат общие принципы, временные задачи, черновики, клиентские данные и готовые материалы, система может лучше искать по этой массе, но сама масса продолжает расти.
Поэтому в какой-то момент важнее не научиться складывать больше, а провести границы.
Основа архитектуры: не папки, а ответственность
На схеме наша система может выглядеть как набор блоков: Foundation, проекты, карта, System Manager, Work Hub. Но если начать объяснение с названий, конструкция покажется сложнее, чем она есть.
В основе лежит один простой вопрос: какой контекст отвечает за какую работу?
Устойчивые сведения о человеке не должны растворяться внутри проекта сайта. Правила сайта не должны лежать в клиентском проекте. Текущее состояние задачи не стоит записывать в вечную инструкцию. Общая карта не должна превращаться в копию всех проектов. Каждый слой получает собственную функцию.
Foundation: общая основа
Foundation можно представить как ядро сохранённого контекста системы. Здесь находится то, что полезно сразу нескольким направлениям и сохраняет смысл со временем: профессиональный профиль, цели, принципы принятия решений, правила взаимодействия с ИИ, требования к публичным текстам.
В моём случае это позволяет ИИ-ассистенту понимать не только отдельную команду, но и человека, который её даёт. Если я обсуждаю сайт, он знает моё позиционирование и подход к работе. Если выбираю инструмент — учитывает, что я ценю практическую пользу и не хочу строить сложную систему ради самой системы. Если прошу отредактировать текст — использует согласованные принципы авторского голоса.
Это действительно похоже на разговор с партнёром, который давно с тобой работает, а не со случайным человеком на улице. Ему не нужно заново объяснять всю биографию перед каждым вопросом.
При этом Foundation — не склад всего известного обо мне. Подробности подключаются выборочно. Для статьи не нужны закрытые финансовые данные. Для технической задачи не обязательно читать личный контекст. ИИ рассуждает в текущем запуске, а Foundation только даёт ему устойчивую опору.
Именно поэтому я называю его мозгом системы с оговоркой. Это не один файл, который самостоятельно всем управляет. Полная картина складывается из рассуждения ИИ, общего контекста, знаний проектов, карты и сохранённого состояния работы.
Самостоятельные проекты
Вокруг общего ядра существуют проекты. Каждый проект — отдельная область с понятным назначением и собственной ответственностью.
Например, Site Work отвечает за работу над сайтом: архитектуру страниц, тексты, SEO, опубликованное состояние и следующие шаги. Client Work отвечает за клиентские проекты и коммуникацию. В другом направлении могут находиться обучение, финансы, разработка приложения или личные исследования.
Названия не важны. Важна самостоятельность.
У проекта должны быть ответы хотя бы на несколько вопросов:
- зачем он существует;
- что входит и не входит в его область;
- какие источники считаются актуальными;
- какие правила действуют именно здесь;
- что уже завершено;
- что происходит сейчас;
- какой следующий шаг;
- где находятся исходники и готовые результаты.
Внутренняя структура проектов может отличаться. Сайту нужна карта страниц и индекс статей. Клиентской работе — история договорённостей и правила расчёта. Приложению — код, тестовые данные и порядок выпуска версий. Создавать одинаковый набор папок ради симметрии не нужно.
Сам проект тоже не является отдельным постоянно работающим ИИ. Это сохранённая область знаний и ответственности. Исполнение начинается, когда человек приносит задачу и ИИ подключает нужные источники.
Управляющие файлы, а не бесконечные журналы
Одна из главных ошибок — превращать каждый файл в хронику всего происходящего.
Инструкция проекта должна содержать действующие правила, а не последовательность всех разговоров. Файл состояния отвечает на вопрос, где работа находится сейчас, а не пересказывает каждую попытку. Карта показывает, какие проекты существуют и за что отвечают, но не копирует их очереди задач. Подтверждённые решения хранятся там, где ими будут пользоваться.
Когда функция файла ясна, ИИ понимает, зачем его читать и что в нём искать. Когда один документ одновременно служит инструкцией, дневником, архивом идей и списком задач, его приходится каждый раз интерпретировать заново.
Мы стараемся сохранять не максимальный объём информации, а достаточный контекст для продолжения работы. Если решение важно, фиксируется само решение и причина, без которой оно может быть понято неверно. Временные подробности не превращаются в вечное правило автоматически.
Как проекты узнают друг о друге
Разделить направления недостаточно. Если каждый проект полностью замкнут, общая работа снова развалится на отдельные острова.
Для ориентации нужна краткая карта проектов. Она сообщает ИИ, какие направления существуют, за что каждое отвечает и где находятся его источники. Это скорее указатель в библиотеке, чем сама библиотека.
Проект сайта может увидеть, что клиентские кейсы принадлежат Client Work. Work Hub может понять, что задача относится к сайту, и направить её туда. System Manager видит общую архитектуру и помогает исправить границы, если два направления начинают дублировать друг друга.
Но знать о существовании проекта и знать весь его контекст — не одно и то же.
Карта не открывает автоматически все чаты и документы. Она даёт направление. Если для задачи нужны конкретные сведения, ИИ читает разрешённые источники выбранного проекта или получает подготовленный пакет передачи.
Обычно в таком пакете достаточно указать:
- цель;
- минимальный предметный контекст;
- уже принятые решения;
- актуальные источники;
- ограничения;
- ожидаемый результат;
- владельца общей задачи;
- место, куда вернуть результат;
- текущий статус.
Так Site Work может получить подтверждённый клиентский кейс для статьи, не забирая всю историю переписки и расчётов. Проект материалов может получить программу вебинара и требования к слайдам, но не весь контекст образовательного направления.
Файлы и папки при этом ничего не передают сами. Работу переносит человек или ИИ через доступный и разрешённый инструмент. Если прямой связи нет, система готовит понятный пакет, который можно перенести вручную.
Зачем нужны System Manager и Work Hub
Эти два названия легко перепутать, хотя они решают разные задачи.
System Manager отвечает за устройство самой системы. К нему обращаются, когда нужно создать новое направление, изменить границы проекта, разобраться с дублирующими правилами, понять, где должно храниться новое знание, или исправить механизм работы.
Он не обязан участвовать в каждой статье, письме или расчёте. Повседневная работа происходит внутри профильных проектов. System Manager нужен тогда, когда проблема находится не в содержании задачи, а в архитектуре.
Например, если новое направление постоянно появляется и в Site Work, и в Work Hub, не стоит просто копировать правила в два места. Нужно понять, появилось ли у него самостоятельное назначение и жизненный цикл. Если да — возможно, нужен отдельный проект. Если нет — достаточно уточнить владельца и маршрут.
Work Hub решает другую задачу. Это необязательная общая точка входа. В неё можно принести вопрос, когда непонятно, какому проекту он принадлежит, или когда задача затрагивает несколько направлений.
Но Work Hub не является начальником остальных проектов и не хранит их полное содержание. Пользователь может сразу открыть Site Work и обсуждать сайт. Обход через центральную точку не должен становиться обязательным ритуалом.
Хорошая архитектура допускает оба пути: прямую работу в профильном проекте и маршрутизацию через общий вход, когда она действительно нужна.
Как эта система собиралась с нуля
На готовой схеме всё выглядит так, будто Foundation, System Manager, карта и проекты появились одновременно. В реальности система собиралась последовательно — от пустой рабочей области к первому проекту, а затем к сети связанных направлений.
Сначала я создал на компьютере общую папку AI Workspace и подключил её к среде, в которой ИИ мог читать и изменять разрешённые файлы. Это важный технический нулевой шаг: недостаточно рассказать модели, что где-то существует рабочая папка. Нужно выбрать конкретное место, дать к нему доступ и заранее договориться, что именно ИИ может там делать.
Первым рабочим проектом внутри этой области стал System Manager. Мы не начинали с десятка папок и не пытались сразу предусмотреть всю будущую жизнь. Сначала обсудили, какие направления у меня уже есть, чем они отличаются, какие материалы накоплены и где проходят границы доступа. На основании этого System Manager помог определить общую архитектуру: где находится Foundation, где создаются проекты, из каких управляющих файлов состоит минимальный проект и как новые направления будут добавляться в систему.
Упрощённо начальная конструкция выглядела так:
Затем мы собрали Foundation. Для этого ИИ не просто получил команду «запомни всё обо мне». Он провёл со мной интервью, изучил относящиеся к задаче материалы и разобрал прежние наработки из других сред. Исходники сначала попадали во входящую папку `Inbox`: это временная зона приёма, а не постоянное место хранения знаний. ИИ мог увидеть всё, что уже существует, но не был обязан превращать каждый старый документ в новое правило. Из материалов выделялись устойчивые сведения, действующие принципы и действительно полезный общий контекст.
После этого появился первый профильный проект. Например, при создании Client Work мы сначала определили его назначение: какие клиентские задачи он ведёт, какие решения принимает, какие материалы использует и что не должно попадать в его область. Затем System Manager создавал минимальную структуру проекта. В `Inbox` загружались существующие договоры, таблицы расчётов, шаблоны и другие исходники. ИИ разбирал их, предлагал, что считать актуальным источником, что оставить оригиналом, какие правила вынести в управляющие файлы и где хранить готовые результаты.
У минимального проекта необязательно много документов. Обычно ему достаточно нескольких функций:
- локальные правила работы ИИ;
- описание назначения, границ и источников проекта;
- актуальное состояние и следующий шаг;
- место для входящих исходников;
- место для готовых материалов, если они нужны вне проекта.
Названия файлов могут отличаться. Важнее, чтобы каждый файл отвечал на свой вопрос и новый чат мог продолжить работу, не перечитывая весь архив.
Когда появились второй, третий и четвёртый проекты, возникла новая практическая задача: помочь им находить друг друга, не смешивая содержимое. Тогда появилась общая карта, правила передачи контекста и точные границы между направлениями. То есть карта не была нарисована заранее ради красивой архитектуры. Она стала нужна в тот момент, когда системе действительно потребовалась навигация.
Для человека, начинающего с нуля, последовательность может быть ещё проще:
- Создать или выбрать одну локальную рабочую папку и подключить её к ИИ-среде.
- Описать ИИ свои направления работы и вместе согласовать минимальную архитектуру.
- Собрать только тот общий контекст, который нужен нескольким направлениям.
- Создать один реальный проект под повторяющуюся задачу.
- Загрузить существующие материалы через входящую папку и разобрать их, не уничтожая оригиналы.
- Проверить проект на настоящей задаче и в новом чате.
- Добавлять карту, новые проекты и дополнительные среды только после появления реальной потребности.
В нашей системе роль архитектора с самого начала выполнял System Manager. Для небольшой конструкции его необязательно выделять в отдельный проект сразу. Но сама функция всё равно нужна: кто-то должен следить, чтобы новая папка решала понятную задачу, правила не дублировались, а изменение структуры не происходило незаметно.
Проект, чат, среда и агент — разные вещи
В разговорах об ИИ эти понятия часто смешиваются, из-за чего система кажется магической или, наоборот, неоправданно сложной.
Проект — долговременная область знаний и ответственности. Он может существовать годами и продолжаться в разных чатах.
Чат — одна цепочка сообщений и действий. Он помогает обсуждать конкретную задачу, но сам по себе не обязан содержать полное актуальное состояние проекта.
Среда исполнения — место, где ИИ работает сейчас и к каким инструментам имеет доступ. Здесь важно не путать приложение и среду. Сам по себе запуск ChatGPT на компьютере ещё не даёт чату доступ к локальным проектам, файлам и приложениям.
Агент — временный исполнитель ограниченного поручения. Он может исследовать вопрос, подготовить часть материала или провести проверку, но не становится отдельным проектом и не получает автоматически доступ ко всей системе.
Из этого следуют практические вещи.
Один проект может обсуждаться в нескольких чатах. Один чат может последовательно обратиться к нескольким проектам. Для одной задачи может понадобиться несколько временных исполнителей. Но пятьдесят проектов не означают пятьдесят постоянно работающих агентов.
Новый чат тоже не обязан помнить всё, что обсуждалось раньше. Он должен уметь прочитать актуальные правила, состояние и источники, чтобы понять подтверждённое, открытые вопросы и следующий шаг. Это надёжнее, чем надеяться, что нужная деталь случайно сохранилась в истории разговора или встроенной памяти.
Три разных способа начать работу
Чтобы понять роль облачных копий, нужно развести три сценария: обычный Chat вне проекта, Chat внутри облачного проекта и локальную рабочую среду Work.
Обычный Chat вне проекта
Такой разговор можно начать и на сайте ChatGPT, и в десктопном приложении. В обоих случаях это обычный облачный чат без привязки к конкретному проекту. Сам факт, что приложение открыто на компьютере, не даёт ИИ доступ к локальным папкам и не подключает инструкции Client Work, Site Work или другого направления.
У ИИ могут быть общие инструкции и отдельные сведения из памяти. Этого достаточно для универсального вопроса. Но такой чат не должен угадывать действующие цены, правила расчёта или устройство конкретного проекта.
Chat внутри облачного проекта
Облачный проект создаётся в ChatGPT и доступен через веб, телефон или десктопное приложение. В него загружаются выбранные копии управляющих файлов из основного локального проекта: назначение, правила работы, справочные данные, таблицы расчётов и другие материалы, которые нужны для самостоятельного начала разговора.
Для такой копии пишется отдельная проектная инструкция. Она объясняет, какому локальному проекту соответствует облачная версия, какие файлы являются копиями и какие упомянутые в них пути существуют только на компьютере. Облачный проект не пытается искать эти пути у себя и не выдаёт копию за канонический оригинал.
Например, облачный проект «Агент по работе с клиентами» получает выбранные источники из локального Client Work. Проект «Работа над сайтом» — управляющую часть Site Work. Универсальный облачный проект, который мы назвали Ivy, содержит разрешённый общий контекст обо мне: кто я, чем занимаюсь, как принимаю решения и какого подхода ожидаю от ИИ.
Это и есть осмысленные зеркала. Они созданы не ради ещё одной копии папки, а для того, чтобы обычный Chat получил нужный предметный контекст без запуска полного локального Work.
Практический смысл хорошо виден на первом сообщении клиента. Допустим, в WhatsApp приходит вопрос: «Здравствуйте, вы занимаетесь предметной съёмкой?» Обычный Chat вне проекта сможет предложить общий ответ. Но уже на вопросе о стоимости ему могут понадобиться мои действующие правила расчёта.
Поэтому я открываю новый Chat именно внутри «Агента по работе с клиентами». Он видит инструкции и загруженные источники проекта, помогает начать диалог в согласованной манере и при необходимости использует расчётные данные. Если задача остаётся простой, работа там и заканчивается.
Локальная рабочая среда Work
Если клиенту требуется подробный расчёт, бриф, техническое задание, коммерческое предложение или работа с другими материалами, задача переходит в локальный Client Work. Это уже не только разговор с загруженными файлами, а работа внутри разрешённой области компьютера.
ИИ может читать и изменять доступные папки, повторно открывать один и тот же документ после правок, сохранять результат в структуре проекта и использовать разрешённые приложения, браузер и другие инструменты. Пользователю не нужно после каждого изменения снова загружать файл в чат: достаточно указать, где он находится. Возможности зависят от предоставленного доступа — сам по себе Work не означает разрешение видеть весь компьютер.
Облачная версия тоже может создавать PDF, документы и другие файлы. Различие не в самом формате результата, а в доступе к рабочей среде. Облачный проект использует загруженные и подключённые источники. Локальный Work может работать с полным разрешённым массивом материалов и поддерживать каноническую структуру проекта.
Передавать из облачного чата всю переписку необязательно. Обычно достаточно короткого пакета: цель, уже принятые решения, использованные источники, открытые вопросы и ожидаемый результат. Локальный проект проверяет пакет по актуальным источникам и продолжает работу. Важное решение из облачного чата становится частью системы только после сохранения в каноническом месте.
Получается простая цепочка:
В нашей текущей конфигурации это также помогает не расходовать ресурс Work на элементарные ответы. Но конкретные тарифы, лимиты и названия режимов меняются. Устойчивый принцип другой: использовать минимальную среду, которой достаточно для задачи, и переходить в полный локальный контур тогда, когда действительно нужны его возможности.
Синхронизация разговора не означает, что локальная папка автоматически загружена в облако. После изменения канонического оригинала его облачная копия не обновляется только потому, что носит такое же имя. Поэтому для каждого типа сведений нужно понимать, где находится актуальная версия и кто отвечает за обновление копий. Источником истины при этом может быть не только локальный файл, но и календарь, CRM, облачный документ или другой сервис.
Как выглядит один сквозной маршрут
Рассмотрим нейтральный пример. Пользователь хочет подготовить открытый вебинар. Нужны программа, слайды и страница регистрации. Публикацию он планирует утвердить отдельно.
Запрос можно принести в Work Hub, который по карте определит профильный проект. Но можно сразу начать в проекте «Обучение». Главное — назначить владельца общего результата.
Проект «Обучение» уточняет аудиторию, цель и содержание вебинара. Он использует применимые принципы из Foundation и сохраняет согласованную программу. Затем две ограниченные части передаются дальше.
Проект «Материалы» получает программу, требования к оформлению и задачу подготовить слайды. Ему не нужна вся история образовательного проекта.
Проект «Сайт» получает подтверждённое название, описание, дату, программу и условие, что публикация требует отдельного решения. Он готовит черновик страницы регистрации по собственным правилам.
Оба результата возвращаются владельцу. «Обучение» сверяет, совпадают ли название, программа, дата и обещания на странице и в слайдах. Завершённый файл ещё не считается согласованным только потому, что хорошо выглядит сам по себе.
Состояние задачи фиксируется точно: программа согласована, слайды проверены, страница подготовлена, публикация ожидает решения пользователя.
В этом маршруте нет магии. Каждый проект делает свою часть, использует необходимый контекст и возвращает результат владельцу. Общая система нужна не для усложнения, а для того, чтобы эти связи не приходилось каждый раз изобретать заново.
Система должна экономить время, а не требовать обслуживания
Увлечься архитектурой легко. Можно бесконечно добавлять папки, роли, агентов, автоматизации и новые правила. В какой-то момент работа с системой начинает занимать больше времени, чем задачи, ради которых она создавалась.
Для меня критерий простой: конструкция должна уменьшать повседневную нагрузку.
Я не хочу часами объяснять ИИ одно и то же. Не хочу искать, где мы приняли решение. Не хочу вручную переносить весь контекст между направлениями. Не хочу проверять десять копий одного правила. Мне нужна система, которая помогает быстрее перейти от намерения к полезному результату.
Поэтому мы не улучшаем её ради самого процесса. Сначала в работе проявляется конкретная проблема. Например, два проекта начинают дублировать сведения, облачная копия отстаёт от оригинала или новый чат не понимает, на чём остановилась задача. Мы выясняем причину, вносим минимальное изменение и смотрим, стало ли действительно проще.
Иногда решением оказывается новый файл. Иногда — удаление лишнего слоя. Иногда достаточно точнее определить владельца или переписать одну инструкцию. Количество элементов не является показателем зрелости.
Система работает, если человек тратит меньше времени на её обслуживание и больше — на собственную работу, решения и творчество.
Как начать строить свою систему
Не нужно сразу создавать Foundation, System Manager, Work Hub и десять проектов. Если у вас одна повторяющаяся задача, начните с неё.
1. Выберите реальную работу
Не проектируйте систему «на будущее». Возьмите задачу, в которой сейчас приходится повторять одни и те же сведения: подготовка клиентских предложений, ведение контента, исследование рынка, обучение или работа над сайтом.
Определите, как выглядит хороший результат и что мешает получать его быстрее.
2. Найдите актуальные источники
Где лежат действующие правила, примеры, решения и исходники? Какие сведения приходится объяснять заново? Что можно разрешить ИИ читать, а что должно оставаться закрытым?
Не загружайте всё подряд. Больше контекста не всегда означает лучший ответ.
3. Создайте минимальный проект
Для начала достаточно определить назначение, границы, источники и текущее состояние. Возможно, часть этих функций уже выполняют существующие документы. Не создавайте дубли ради соответствия чужому шаблону.
4. Отделите устойчивое от временного
Общие принципы и сведения, которые пригодятся в нескольких направлениях, могут стать основой Foundation. Текущая задача, открытый вопрос и следующий шаг остаются в состоянии проекта. Черновик не превращается в постоянное правило только потому, что однажды оказался удачным.
5. Проведите один пилот
Выполните реальную задачу, сохраните результат и зафиксируйте продолжение. Затем откройте новый чат и проверьте, может ли ИИ по файлам понять, что уже решено и что делать дальше.
Если для продолжения приходится пересказывать весь прошлый разговор, состояние описано недостаточно. Если ИИ читает десятки ненужных файлов, границы слишком широкие.
6. Расширяйте только по необходимости
Второй проект появляется, когда возникает самостоятельная область с собственными правилами и жизненным циклом. Карта нужна, когда направлений стало несколько. System Manager полезен, когда приходится менять устройство системы. Облачная копия нужна, когда существует реальный сценарий работы без основного компьютера.
Архитектура должна расти вместе с практикой, а не опережать её.
Два файла для адаптации системы
Чтобы эту логику было проще понять и перенести, мы подготовили два самостоятельных материала.
Визуальное руководство в PDF
PDF рассчитан прежде всего на человека. В нём 24 страницы со схемами: общая карта, роли Foundation и проектов, работа System Manager и Work Hub, различие чата, проекта и среды, передача контекста, облачные копии и полный маршрут задачи на примере вебинара.
**[Скачать визуальное руководство AI Workspace в PDF — ссылка будет добавлена при сборке страницы]**
Blueprint в Markdown
Blueprint даёт точные определения, границы и критерии проверки. Его можно прочитать самостоятельно, но основная практическая ценность — загрузить вместе с PDF в свою ИИ-среду. Документ помогает модели понять не только внешний вид схемы, но и правила: что является источником истины, как передаётся задача, чем агент отличается от проекта и почему облачная копия не равна оригиналу.
**[Скачать AI Workspace Blueprint в Markdown — ссылка будет добавлена при сборке страницы]**
Внутри Blueprint уже есть готовый запрос для начала адаптации. Его логика проста: сначала попросить ИИ объяснить архитектуру своими словами, затем выбрать одну реальную повторяющуюся задачу, определить источники и предложить минимальный проект. Не нужно просить модель сразу воссоздать всю систему целиком.
Вместо заключения
Хорошая рабочая система с ИИ не обязана быть большой. Она должна отвечать на четыре вопроса:
- что сейчас нужно сделать;
- где находится актуальный контекст;
- кто отвечает за результат;
- как продолжить работу после паузы или в новом чате.
Одна папка со сведениями о человеке — хороший первый шаг. Она помогает ИИ перестать быть незнакомцем. Но если работа развивается в нескольких направлениях, следующим шагом становится разделение ответственности: общий устойчивый контекст, самостоятельные проекты, краткая карта и точная передача нужных сведений.
Наша архитектура продолжает меняться. Не потому, что хочется бесконечно что-то настраивать, а потому, что реальная работа показывает слабые места. Мы исправляем их, когда изменение экономит время, снижает количество повторных объяснений и делает результат устойчивее.
Именно поэтому я предлагаю относиться к приложенным материалам не как к готовому шаблону, который нужно скопировать, а как к карте. Загрузите PDF и Blueprint своему ИИ, покажите одну реальную задачу и начните с минимальной конструкции. Если она помогает работать — развивайте дальше. Если требует больше обслуживания, чем приносит пользы, упрощайте.
Система существует для работы. Не работа — для системы.
От коммерции к системе: как родился авторский арт-проект EDITIONS
Как составить техническое задание
Мастер-класс: Как снимать ювелирные изделия
Свет в фотографии: как он работает и почему предмет выглядит именно так
Жёсткий и мягкий свет: что на самом деле описывают эти слова
Как свет показывает форму, фактуру и материал
MIZEKEN: фарфор, орнамент и свет
Кто сказал, что лукбук — это скучно?
Моя работа получила Silver Award WPE Awards в категории Food
Нейросеть, вайб-кодинг или конструктор: как создать сайт, если ты не программист
Ювелирная съёмка для L’aroush: каталог и контент для digital-платформ
Как организовать предметную съёмку внутри компании: процессы и стандарты
Как ИИ перестал быть просто чат-ботом
Ювелирная съёмка для FARRO: каталог и рекламный визуал
