Как я работаю в феврале 2026: 4-уровневая архитектура знаний + экзокортекс Claude Code, VS Code, Github

Я одновременно развиваю несколько разнотиповых проектов в разных предметных областях: экосистема развития интеллекта, цифровой двойник созидателя, ИТ-платформа и бот, руководства и эпистемы знаний. Каждый проект имеет свои знания, код, документацию. Как не потеряться?

Всё знание организовано по 4 уровням содержания:

Уровень 1: FPF (First Principles Framework)
│  Мета-онтология, базовые различения
│  "Что значит знать правильно"
│
▼
Уровень 2: SPF (Second Principles Framework)
│  Форма + процесс для создания знаний по предметным областям
│  "Как оформить знание инженерно"
│
▼
Уровень 3: Pack (Паспорт области)
│  Source-of-truth для конкретной области (ядро знаний), которые описаны определенным образом
│  "Что истинно в этой области"
│
▼
Уровень 4: Downstream (Реализации)
   Код, курсы, боты, документация и тп
   "Как применить знание"

Подробнее об этом в посте “Первые принципы ↔ FPF ↔ вторые принципы ↔ SPF ↔ паспорт/ядро области (pack)”.

Как это работает на практике

  1. Классифицированные репозитории

Каждый репозиторий имеет один тип:

Тип Роль Примеры
Framework Рамки корректности SPF, FPF
Pack Source-of-truth области spf-personal-pack, spf-ecosystem-pack
Format Протокол структуры s2r
Downstream/instrument Код и сервисы digital-twin-mcp, aist_bot
Downstream/governance Управление и планы ecosystem-development
Downstream/surface Курсы и гайды docs
  1. Все репозитории в одной локальной папке

Все репозитории лежат в одной папке на моём компьютере:

~/Github/
├── CLAUDE.md               # Общие инструкции для AI
├── SPF/                    # Framework
├── spf-personal-pack/      # Pack: созидатель
├── spf-ecosystem-pack/     # Pack: экосистема
├── spf-digital-platform-pack/  # Pack: ИТ-платформа
├── s2r/                    # Format упаковки знаний по проекту с целевыми и нашими системами
├── ecosystem-development/  # Downstream/governance
├── digital-twin-mcp/       # Downstream/instrument
├── aist_bot/               # Downstream/instrument
└── docs/                   # Downstream/surface

Открываю всю папку Github/ в VS Code — и получаю доступ ко всем репозиториям одновременно.

  1. Claude Code как мультипроектный ассистент

Claude Code читает:

  • ~/Github/CLAUDE.md — общие правила экосистемы
  • <repo>/CLAUDE.md — специфичные инструкции конкретного репозитория
  • <repo>/REPO-TYPE.md — тип и зависимости каждого репо

Это даёт Claude понимание:

  • Какой репозиторий для чего
  • Что является source-of-truth
  • Куда вносить какие изменения

Результат:

  • Могу сказать “обнови все README согласно новой классификации” — и Claude правильно обновит 9 репозиториев, соблюдая правила каждого
  • Могу переименовать понятие — и изменение пройдёт по всем нужным репо
  • Могу вписать новую идею — и она сразу появится во всех связанных местах
  1. Рабочие продукты = коммиты

Каждый коммит — это рабочий продукт:

  • Атомарное изменение
  • С описанием “что и зачем”
  • Привязан к конкретному репозиторию

Сначала делаю изменения локально (могу затронуть несколько репо), затем заливаю в GitHub.

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

  1. Итерации и инкременты

Работаю циклами:

Стратегирование → Планирование → Творческий конвейер → Изменения → Коммит
      ↑              (почти каждый день)                           │
      └────────────────────── Обратная связь ──────────────────────┘
  • Стратегирование: что важно сейчас, какие проекты двигать (почти каждый день)
  • Планирование: список рабочих продуктов на день/несколько дней
  • Творческий конвейер: идеи → заметки и формализация → промпты, заготовки и реализация
  • Инкременты: маленькие шаги, каждый из которых ценен сам по себе

Связь уровней с реальным миром

Pack (знание)
    ↓ реализуется в
Downstream/instrument (код)
    ↓ работает как
ИТ-система (MCP, бот)
    ↓ изменяет
Людей (созидателей)
    ↓ которые создают
Другие системы

Например:

  • spf-personal-pack описывает характеристики и состояния созидателя
  • digital-twin-mcp реализует это как MCP-сервис
  • aist_bot использует MCP для марафона новичков
  • Пользователь получает персональное задание и меняет свои практики (привычки)

Почему это хорошо работает, как я теперь вижу:

  1. Один источник истины: Pack содержит “что правильно”, downstream — “как применить”
  2. Трассируемость: изменение в pack → обновление downstream
  3. Параллельная работа: могу двигать несколько проектов, не путаясь
  4. AI-усиление: Claude Code понимает структуру и помогает соблюдать правила
  5. Локальная работа: все изменения сначала локально, потом push
  6. Скорость: изменения по всем репо за минуты, а не часы

Всем мои основные инструменты:

  • Claude Code — AI-ассистент с пониманием структуры проектов и знаний
  • GitHub — версионирование и рабочие продукты, хранение и синхронизация
  • VS Code — открываю всю папку Github/

Эта организация работы позволяет мне одновременно развивать фреймворк (SPF), описания предметных областей (pack’и), и конкретные реализации (downstream) — сохраняя целостность и трассируемость от первых принципов до изменений в реальном мире.

Главный вывод – у меня есть структурированное системное знание, которое:

  1. опирается на чётко определённую архитектуру знания — от мета-онтологии и первых принципов до конкретных реализаций (от FPF → SPF → Pack → Downstream),
  2. трассируемо и согласовано: изменения на уровне ядра знаний (Pack) автоматически переходят к всем downstream-реализациям,
  3. масштабируемо и многопроектно: единая структура + классификация репозиториев позволяет одновременно вести несколько разнотиповых проектов, не теряя целостности,
  4. обеспечивает source-of-truth: каждый Pack — это истинный источник доменной информации, а downstream — способ её применения,
  5. поддерживается практическими рабочими циклами и инструментами (VS Code, GitHub, Claude Code) — что делает знание живым и постоянно развивающимся.

То есть не просто «я могу развивать много проектов», а именно есть структура знаний, в которой архитектура + процессы + инструменты превращают это знание в рабочую, инкрементальную, адаптивную экосистему**, и эта система действительно растёт и развивается в тех направлениях, которые мне нужны, сохраняя при этом согласованность между основой и реализациями.

Если сформулировать вывод в виде короткого тезиса:

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

13 лайков

Мне как раз по работе надо создать claud.md файлы для всех наших репо. Ваша статья прямо кстати :slight_smile:

1 лайк

Уже пошел дальше. Все репо не просто вместе в VS Code, но все их Claude.md связаны через корневой Claude.md и Memory. Сделал отдельное личное репо по стратегированию и планированию, почти перенес Стратега, сейчас связываю с ботом. То есть переезжаю из coda в эту новую инфру. Не нужно самому отслеживать соответствие таблиц.

Сейчас например, корневой claude.md сразу смотрит есть ли РП в списке на неделю прежде чем давать мне ответ, и если его там нет, то предлагает сначала его сформулировать и записать. Он сам проходит ритуал и выдает мне варианты ролей, методов и РП.

3 лайка

было бы интересно посмотреть на описание этого процесса, когда он чуть устаканится. В виде схемы, или в виде небольшого вебинара, не знаю…

2 лайка

Да, будет описание и вебинар, вернее описание уже есть в моих репо. Тестирую четвертый день, и это космос)

3 лайка

Церен, а есть ли FPF на англ? Думаю использовать на работе.

Вообще-то FPF есть только на английском ))) Берите всегда свежую версию вот тут: GitHub - ailev/FPF: First Principle Framework

1 лайк

Спасибо! :slight_smile: