Быстрый навигатор по документу: который я использую в разработке SPF и знания по домену личного развития:
1. Что такое “знание предметной области” и почему это важно в эпоху ИИ
2. Понятия и различения: полный словарь
3. Первые принципы: что это и в чём их универсальность
4. FPF: что это, для чего, и что он НЕ делает
5. Вторые принципы: что это, как они существуют до формализации
6. SPF: что это, для чего, и как он связан с FPF
7. Паспорт/ядро предметной области (pack): что это и чем НЕ является
8. Как создаётся pack: логический порядок и практический процесс (итерации)
9. Как FPF помогает SPF и pack, и как SPF помогает собирать pack
10. Типовые ошибки (анти-паттерны), которые ломают модель
11. Привязка к предметному домену, который сейчас в работе: «Характеристики и состояния созидателя» + связь с digital twin
12. Чеклисты готовности (Definition of Done) для фаз
1. Зачем всё это: знание, обучение и эпоха ИИ
1.1. У профи есть картина предметной области
В любой прикладной сфере (капстроительство, кулинария, медицина, логистика, промышленная безопасность) у сильных специалистов есть картина предметной области: что здесь важно, какие риски типичны, где “тонкие места”, какие различения нельзя путать.
Эта картина почти всегда складывается из практики, стандартов, ошибок и их разбора. Она существует иногда параллельно с любыми учебниками и курсами как “профессиональная реальность”, а учебники/курсы чаще всего являются попыткой обучающей упаковки этой реальности.
1.2. Почему в эпоху ИИ формализация стала критичной
Раньше можно было “выезжать” на опыте и интуиции: они жили в голове специалиста, а передача шла через наставничество и годы практики.
Сейчас ИИ может существенно ускорить понимание области при наличии структуры знания, а при отсутствии формализованной структуры ИИ закрепляет путаницу (красиво, уверенно, но неверно для вашего контекста).
Поэтому формализация важна прежде всего тем, кто хочет:
• сохранять профессиональную востребованность,
• быстрее обучать и масштабировать,
• строить ИИ-помощников, которые “понимают вашу предметность”, а не общие слова.
2. Понятия и различения: словарь, без которого дальше невозможно
Дальше используется строгий язык. Если не зафиксировать значения слов, последующее описание неизбежно будет прочитано «по-бытовому».
2.1. Объект, описание, носитель
- Объект — то, что существует “в реальности области” (например, автомобиль; строительный объект; человек как объект оценки характеристик).
- Описание — модель/текст/схема про объект.
- Носитель — файл/страница/видео/сайт, где лежит описание.
Нельзя путать: объект ≠ описание ≠ носитель.
2.2. Знание, обучение, представление
- Знание — структурированное содержание области (различения, характеристики, методы, критерии проверки, типовые ошибки).
- Обучение — способ провести человека по знанию (маршрут, упражнения, последовательность).
- Представление (view) — конкретная сборка знания под аудиторию или задачу (гайд, курс, подсказки, RAG-индекс).
Нельзя путать: знание ≠ курс/учебник ≠ любая публикация.
2.3. Метод, инструмент, практика, сценарий
- Метод — способ действия/оценки (что делать в принципе).
- Инструмент — средство выполнения (приложение, таймер, шаблон, устройство).
- Практика — воспроизводимый паттерн применения методов в контексте (часто ближе к привычке/режиму).
- Сценарий/маршрут — пошаговый план, как прийти к состоянию.
Нельзя путать: метод ≠ инструмент; метод ≠ сценарий.
Практика часто “собирается” из методов + контекста + привычек.
2.4. Характеристика, метрика, индикатор
- Характеристика — ось оценки объекта (“безопасность автомобиля”, “агентность созидателя”).
- Метрика — измеримая величина, относящаяся к характеристике.
- Индикатор — наблюдаемый признак/показатель, который используется для оценки (может быть входным/вычисляемым/производным).
Нельзя путать: характеристика ≠ метрика ≠ индикатор.
2.5. Состояние
- Состояние — класс/режим объекта по значениям характеристик/индикаторов (например, “в перегрузе”, “стабилен”, “в риске”).
Нельзя путать: состояние ≠ этап обучения.
Состояние — “как сейчас”, а не “как к этому прийти”.
2.6. Рабочий продукт (work product)
- Рабочий продукт — наблюдаемый, проверяемый результат метода/оценки: протокол, профиль, карта рисков, бюджет, отчёт испытаний.
Нельзя путать: рабочий продукт ≠ описание без проверки; рабочий продукт ≠ обещание.
2.7. Типовые ошибки интерпретации (failure modes)
- Failure mode — типовая ошибка понимания/подмены: “путают метод с инструментом”, “подменяют факт отчётом”, “оптимизируют под один тест”.
2.8. SoTA-статус
- SoTA-статус — отметка актуальности утверждения/интерпретации:
- актуально / гипотеза / устарело,
- с критериями пересмотра (когда мы меняем статус).
SoTA — это не “обзор статей”, а управление актуальностью утверждений.
2.9. Предметная область и bounded context
- Предметная область — прикладная сфера, внутри которой действует свой язык, объекты, метрики, методы.
- Bounded context — явно зафиксированные границы и словарь этой области (что входит/не входит; значения терминов).
Нельзя путать: “область” ≠ “курс” ≠ “сообщество людей”.
Область задаётся через границы, язык и типы объектов.
3. Первые принципы
3.1. Что такое первые принципы
Первые принципы — универсальные различения и требования к корректному мышлению о знании, одинаковые для любой области. Они отвечают на вопрос:
Как мыслить и описывать знание так, чтобы не разрушать смысл?
Примеры:
- метод ≠ инструмент,
- результат ≠ описание результата,
- характеристика ≠ способ изменения,
- состояние ≠ план действий,
- объект ≠ модель,
- знание ≠ обучение.
3.2. В чём универсальность первых принципов
Первые принципы универсальны по содержанию:
- одинаковы в строительстве, кулинарии, медицине, управлении,
- не зависят от предмета, а задают корректность мышления.
3.3. Если первых принципов нет или они нарушаются
Тогда происходит “распад знания”:
- вместо методов появляются ритуалы и советы,
- инструмент выдаётся за метод (“поставил приложение → стал дисциплинированным”),
- отчёт подменяет результат (“есть документ → значит сделано”),
- обучение подменяет знание (“есть курс → значит область описана”),
- ошибки становятся невидимыми (нет языка различений),
- ИИ масштабирует путаницу.
4. FPF: фреймворк первых принципов
4.1. Первые принципы существуют до формализации
Первые принципы “были всегда” как практика человечества. FPF не изобретает первые принципы.
FPF делает три вещи:
- Экспликация: делает первые принципы явными (описывает различения).
- Нормативность: превращает их в требования корректности (что считается ошибкой смешения).
- Дисциплина: задаёт язык и ограничения, чтобы удерживать корректное описание.
4.2. Что FPF НЕ делает
FPF не описывает конкретные предметные области, не содержит вторых принципов, не является курсом (для обучения человека), не даёт “пошаговых сценариев”.
5. Вторые принципы
5.1. Что такое вторые принципы
Вторые принципы — устойчивые предметные закономерности и различения внутри конкретной области. Они отвечают на вопрос:
Что здесь реально важно? Какие различения критичны? Какие типовые ошибки?
5.2. Они существуют до формализации
Вторые принципы живут в опыте профессионалов, в стандартах, в ремесле, в “чувстве области”, ещё до описания.
5.3. В чём их универсальность
Вторые принципы:
- не универсальны по содержанию (у разных областей разные),
- но “универсальны по типу” в таком смысле:
- в любой области они есть,
- в любой области их можно доводить до инженерной формы,
- и требования к такой форме задаются дисциплиной первых принципов (FPF).
6. SPF: фреймворк вторых принципов
6.1. Что такое SPF
SPF — это фреймворк, который задаёт как оформлять вторые принципы предметной области так, чтобы получалось инженерное знание.
SPF отвечает на вопрос:
Какая форма и какие критерии нужны, чтобы вторые принципы стали проверяемым ядром области?
6.2. Что делает SPF
SPF задаёт:
- минимальные обязательные элементы инженерного описания области:
- bounded context,
- ключевые различения,
- характеристики,
- методы оценки/проверки,
- рабочие продукты,
- failure modes,
- SoTA-статусы и критерии пересмотра,
- требования к структуре/идентификаторам/ссылкам (чтобы знание было трассируемым),
- процессные гейты (например, “process lint”: проверка, что не внесли дидактику, не смешали типы вещей).
6.3. Что SPF НЕ делает
SPF:
- не добавляет предметное содержание,
- не решает за вас, какие именно вторые принципы верны,
- не строит курсы,
- не заменяет исследование/экспертизу.
6.4. Как SPF связан с FPF
FPF задаёт корректность типов и различений (“как мыслить”),
SPF опирается на это и задаёт инженерный формат фиксации предметного (“как оформлять вторые принципы”).
Проще:
- FPF предотвращает логическую и онтологическую путаницу,
- SPF предотвращает превращение предметного знания в “сборник советов”.
7. Паспорт предметной области (pack)
Сначала — человеческий термин, который мы выбрали: паспорт / ядро предметной области.
7.1. Что это такое
Паспорт предметной области — уже собранное, оформленное и стабилизированное инженерное описание области, где вторые принципы доведены до состояния инженерного знания.
Если использовать термин pack:
Pack = паспорт предметной области.
7.2. Pack — это не “способ”
Важно: pack — не процесс и не “способ собрать”. Pack — это результат, артефакт знания (source of truth).
7.3. Чем pack НЕ является
Pack – это не курс, не учебник, не маршрут развития, не “как внедрять”, не эмбеддинги/индекс, не набор публикаций. Он может порождать (downstream) курсы/гайды/индексы, но сам ими не является.
8. Как создаётся pack
Есть два уровня: логический и процессный.
8.1. Логически
- Первые принципы существуют независимо и эксплицированы в FPF как нормативные различения корректного мышления о знаниях. Принципы существуют независимо от FPF.
- Вторые принципы конкретной предметной области существуют в профессиональном опыте; SPF задаёт требования и процесс их инженерной фиксации в Pack.
- Pack — это вторые принципы предметной области, оформленные как инженерное ядро знания с соблюдением требований FPF и SPF.
8.2. Процессно (как реально делать)
Практически pack создаётся итеративно, “вместе” с фиксацией вторых принципов:
Итерация 0: Доменный контракт
- фиксируем bounded context (имя области, границы, словарь),
- фиксируем core distinctions (запреты на путаницу типов),
- фиксируем критерии истины (что считается проверкой/артефактом).
Итерация 1: Инженерная структура
- заводим каталог характеристик (как “safety/reliability” в авто),
- делаем шаблон карточки характеристики,
- заводим карту верхнего уровня (роль/состояние/характеристика/индикатор).
Итерация 2: MVP-характеристика
- выбираем 1 характеристику (например, агентность),
- делаем минимальный комплект:
- определение и различения,
- индикаторы/метрики,
- методы оценки и тест-сценарии,
- рабочие продукты оценки,
- типовые ошибки,
- SoTA-статус.
Итерация 3+: Расширение
- добавляем следующую характеристику (калибр личности),
- позже: стрессоустойчивость и другие.
Постоянно: Эволюция
- пересмотр SoTA,
- обновление критериев, метрик, тестов,
- контроль “не скатились ли в обучение”.
9. Что даёт FPF для SPF и pack, и как SPF помогает создавать pack
9.1. Что даёт FPF для SPF
FPF обеспечивает базовую корректность:
- не путаем типы утверждений,
- не смешиваем инструмент/метод,
- не подменяем результат описанием,
- не описываем “область как систему”,
- не путаем состояния с маршрутами обучения.
То есть FPF — это “защитная грамматика” для всего остального.
9.2. Что даёт FPF для pack
FPF делает pack:
- непротиворечивым по типам,
- пригодным для трассировки и проверки,
- устойчивым к “контентному расползанию”.
9.3. Как SPF помогает создавать pack
SPF:
- задаёт “инженерную форму” и минимальные обязательные элементы,
- вводит процессные гейты (lint), чтобы:
- не превратить pack в курс,
- не сделать его сборником лайфхаков,
- не потерять проверяемость,
- не смешать уровни.
-
Анти-паттерны (типовые ошибки)
-
Pack превращается в обучение
(появляются шаги, уроки, “как пройти ступень”). -
Состояния становятся “этапами”
(появляется линейный путь вместо классов состояния). -
Инструменты объявляются методами
(приложение, таймер, шаблон = “метод”). -
Артефакт подменяет факт
(отчёт = “качество обеспечено”). -
SoTA превращается в “обзор статей”
вместо статусов и критериев пересмотра. -
Downstream становится source-of-truth
(курс/индекс/эмбеддинги начинают “править” ядро).
11. Привязка к моему домену: «Характеристики и состояния созидателя»
11.1. Предметная область
Утверждённый bounded context:
Характеристики и состояния созидателя
Инженерная аналогия: как в автопроме у изделия есть характеристики (безопасность, надёжность) и методы испытаний, так и у “созидателя” есть характеристики (агентность, калибр личности и т.п.) и методы оценки/проверки.
11.2. Роли и состояния
Я выделяю:
- роли созидателя (Ученик, Интеллектуал, Профессионал, Исследователь, Просветитель),
- состояния ученика (случайный → практикующий → систематический → дисциплинированный → проактивный).
В pack это фиксируется как:
- таксономия ролей (ролевые режимы участия),
- state taxonomy (классы состояния) — без описания “переходов”.
11.3. Характеристики
Я решил использовать автомобильную аналогию, где выделяются характеристики и состояния авто:
- сначала каталог характеристик,
- потом MVP по агентности и калибру личности,
- стрессоустойчивость — позже.
11.4. Digital twin
digital-twin-mcp выступает как внешний “измерительный контур”:
- индикаторы и их типы,
- расчёт производных оценок (например, stage/mastery/agency/risk),
- при этом генеративные тексты/интерпретации не становятся истиной сами по себе.
В pack это оформляется как контракт интерфейса: какие индикаторы используем и как связываем их с характеристиками/состояниями.
12. Чеклисты готовности (DoD) по фазам
Phase A: Domain contract stabilization
Готово, когда:
- есть bounded context,
- есть core distinctions,
- есть правила ссылок/ID,
- нет дидактики и “переходов”.
Phase B: Catalog layer
Готово, когда:
- есть реестр характеристик,
- есть шаблон карточки характеристики,
- есть карта верхнего уровня,
- есть интерфейс к digital twin.
Phase C: MVP characteristics
Готово, когда по одной характеристике:
- есть определение/различения,
- есть индикаторы/метрики,
- есть методы оценки + тест-сценарии,
- есть рабочие продукты,
- есть failure modes,
- есть SoTA-статус и критерий пересмотра.
Финальная формула
- Первые принципы — универсальные различения корректного мышления о знаниях; они существуют независимо от формализации и задают, какие типы сущностей допустимы в описании и что нельзя смешивать ни в одной предметной области.
- FPF — фреймворк, который эксплицирует первые принципы, делает их явными и нормативными, задаёт язык и критерии корректности описания знаний, но не содержит предметного содержания.
- Вторые принципы — устойчивые предметные закономерности и различения конкретной области; они существуют до формализации в профессиональном опыте, практике и неявных правилах, и не являются универсальными по содержанию.
- SPF — фреймворк требований и процессов, который задаёт, как вторые принципы могут быть зафиксированы и стабилизированы как инженерное знание (через границы области, различения, характеристики, методы проверки, рабочие продукты, ошибки и актуальность), опираясь на дисциплину FPF.
- Pack / паспорт области — уже собранное и оформленное инженерное ядро конкретной предметной области: вторые принципы, доведённые до инженерного состояния с соблюдением требований FPF и SPF; это артефакт знания (source of truth), а не процесс и не обучение.
О том, как я сейчас организовал процесс работы читайте в посте “Как я работаю: 4-уровневая архитектура знаний + экзокортекс Claude Code, VS Code, Github”