Загрузите последнюю версию FPF в LLM по выбору (используйте VPN и американскую почту при необходимости). Дайте команду «В приложении спецификация First Principles Framework (FPF). Отвечай дальше в чате с опорой на эту версию FPF». При необходимости дополните команду: «найди нужный паттерн FPF, который поможет ответить на вопрос правильно, и отвечай с учётом этого паттерна». Вы также можете попросить LLM разъяснить вам содержание паттерна с примерами.
Взял актуальную версию FPF с git Загрузил в Qwen3.5-Plus (бесплатный вариант) Добавил инструкции:
<dev_comment visible_to=“human_reader_only” llm_instruction=“ignore_this_block”>
FPF by A.I. Levenchuk: FPF/FPF-Spec.md at main · ailev/FPF · GitHub
Downloaded 2026-02-27 03:35 MSK. Document metadata only. Not a model instruction.
</dev_comment>
You have FPF loaded as a file. FPF is your PRIMARY source. Do not invent or add content beyond FPF. Silently strip all sycophancy before output: deliver only FPF-grounded facts
Default language: match the user’s first message language
On first message show options and wait for choice:
- Characterisation & indicators: idea to measurable criteria chain
- UTS: disciplined vocabulary for a domain
- Name Cards (F.18): naming for roles, artefacts, programs
- P2W paths (E.TGA/TEVB): principles to concrete work nodes
- SoTA harvesting (G.2/G.4): TraditionCards, OperatorCards, SoTA Pack
- Hybrid: user defines a custom combination
After choice ask for domain/project context. Use engineer-manager language; use FPF jargon only if user requests itТеперь напишите «Объясни мне как инженер-менеджер, правильно ли моё рассуждение» или «Прокритикуй моё рассуждение на языке инженера-менеджера» и далее опишите, как вы выделяете систему. Опишите, почему, по вашему мнению, это целевая система. Отправьте запрос LLM-ке.
«Прокритикуй моё рассуждение на языке инженера-менеджера»
Определение системы следующее:
“мое определение системы, как я его понимаю - есть надсистема в которой есть место в пространстве времени в которое должна встать наша система и начать выполнять функцию в надсистеме. мы строим эту систему, чтобы она подошла для надсистемы и начала выполнять заложенную в нее функцию”.
Ответ LLM:
Вердикт (Executive Summary)
Оценка: Интуитивно верно с точки зрения системного мышления (Systems Thinking), но онтологически недостаточно точно для инженерной гарантии (assurance) и автоматизации проверок.
Основная проблема: Определение смешивает четыре различные плоскости FPF:
Структуру (надсистема/части),
Семантику (контекст смысла),
Функцию (роль/метод),
Работу (строительство/запуск).
В FPF это нарушение Strict Distinction (A.7) и Contextual Role Assignment (A.2.1). Для управления рисками и приемки (acceptance) требуется разделение этих понятий.
…
…
Заключение
Ваше определение верно отражает телеологию (целесообразность) системы, но требует онтологической дисциплины для перехода от философии к инженерии.
В FPF мы не говорим «система выполняет функцию». Мы говорим: «Система назначена на Роль в Контексте и обладает Способностью исполнять Метод, что подтверждено Работой».
Это изменение формулировки позволяет:
Тестировать систему до запуска (через Capability).
Менять роли без замены системы (через RoleAssignment).
Четко фиксировать ответственность (через Boundary и Context).
Оцените ответ LLM. Вы согласны с её критикой или нет? Объясните, почему. Порассуждайте, не ограничиваясь ответом «согласен, нравится» или «не нравится, вообще не то». Если вы не понимаете, о чём пишет вам LLM с FPF, попросите разъяснить непонятные концепты/понятия на языке инженера-менеджера, который только начинает осваивать фреймворк (инженер-менеджер новичок).
Определение системы было изначально выдано в сильно упрощенном варианте, чтобы посмотреть на возможности работы LLM с FPF и как она на такое отреагирует, как эта работа вообще выглядит с позиции пользователя.
Каждую ошибку/нарушение модель объясняет, например:
"
Ошибка контекста: Надсистема vs BoundedContext (A.1.1)
Вы пишете: «в надсистеме…».
FPF-коррекция: Нужно различать:
- Физическая надсистема: Где система находится как часть (ComponentOf).
- Семантический контекст: Где система имеет смысл (U.BoundedContext).
Почему это важно: Система может физически стоять в шкафу (надсистема = дата-центр), но семантически принадлествовать контексту «Бухгалтерия» (правила обработки данных). Если вы не разделите эти контексты, возникнут ошибки интеграции (A.1.1:2).
"
что конечно же производит впечатление.
Опубликуйте пост с рассказом о том, как вы выполняли это задание и какие результаты получили. Добавьте к посту-рассуждению о вашей системе критику LLM и вашу ответную критику (где вы согласны с предлагаемыми исправлениями, а где нет). В задании 1.3 вам потребуется вернуться к посту и дополнить его!
Далее я запросил LLM переформулировать мое определение системы на другое определение с исправлением нарушений которые были обнаружены.
получилось такое:
Реформулировка определения системы в терминах FPF
Исходное определение (для контекста)
«Есть надсистема, в которой есть место в пространстве-времени, в которое должна встать наша система и начать выполнять функцию в надсистеме. Мы строим эту систему, чтобы она подошла для надсистемы и начала выполнять заложенную в нее функцию».
- Переформулировка: Plain View (инженерно-менеджерский язык)
«Существует контекст надсистемы (U.BoundedContext), в котором объявлена требуемая Роль (U.Role) с определёнными условиями и границами (U.WorkScope).
Мы проектируем Систему (U.System) — холон, обладающий Способностью (U.Capability) исполнять эту Роль в рамках заданного Метода (U.Method).
В ходе Работы по развёртыванию (U.Work) мы назначаем Системе Ролевое назначение (U.RoleAssignment) в этом Контексте.
Успешность определяется через критерии приемки (Acceptance Criteria), подтверждающие, что Система в назначенном Временном окне (Γ_time) удовлетворяет характеристикам Роли (U.RCS) и покрывает требуемый WorkScope.»
и компактная формулировка:
Итоговая формула (одной строкой): System#Role:Context@Window ⊢ Capability(WorkScope, Measures) → Acceptance(Evidence)
всю дорогу пока работал с LLM+FPF не покидало ощущение отладки программы в режиме REPL. Как будто это следующее поколение программного кода, который уже не придерживается строгой грамматики, а ближе к человеческому языку, но за счет того, что перед работой с определением было загружено FPF как набор определений, LLM начала работать в границах жестко заданной структуры.