Черновик FPF как MVP
Главный успех First Principles Framework в том, что он вполне работает даже в текущей черновой версии, MVP как-то достигнуто. Начальная задумка была сделать что-то типа руководства по рабочему развитию AI для мышления AI в роли инженера-менеджера-исследователя, это уже как-то получилось. Каждый день мне присылают в личку примеры того, как это неожиданно хорошо работает (пользоваться очень просто: взять текущий файл FPF, который лежит вот тут: First Principles Framework — Core Conceptual Specification (holonic).md — Яндекс Диск (там .md на английском, примерно 1.5Мзнаков). Надо просто грузить этот файл, а потом просить решить свою задачу, используя FPF (и если не очень понятно, что там такое он отвечает на заумном языке, то просить рассказать простыми словами, как инженеру-менеджеру). Последнее из пришедшего в личку (ну, не совсем личку, это чат нашей группы стажировки): “FPF это просто шайтан-машина! [далее описание ситуации и решения] Как я до этого работал??”. Я примерно такого и хотел: в FPF сейчас сотня разных чеклистов, которые проверят ваши текущие идеи. Но ещё и сотня разных ходов, которые подсветят то, на что надо обратить внимание, чтобы получить ваши следующие идеи.
Выгоды примерно такие же, как от наших программ рабочего развития: быстрее разобраться в новом проекте, найти потенциальные источники ошибок, сфокусировать внимание на важном незаметном и проигнорировать очень заметное неважное. Только FPF пока не столько руководство для людей, сколько руководство для AI.
Надо также учитывать, что терминология и “картина мира” (онтология) FPF отличаются от того, что изложено в наших руководствах по рабочему развитию (про личное и исследовательское развитие мы пока не говорим). И что текущее состояние всё-таки черновик. И что нынешние модели AI всё-таки недостаточно умны и у них мало памяти для таких больших текстов (и лучше брать старшие думающие платные модели, они будут меньше галлюцинировать, чем какие-нибудь китайские бесплатные). И ещё много чего надо учитывать.
Но всё-таки FPF уже как-то работает и наносит непоправимую пользу инженерам-менеджерам.
Унификация в FPF: процедура приведения терминов из разных профессиональных языков к унифицированным нейтральным терминам
За последние несколько дней в FPF появилась огромная (аж 17 паттернов/подразделов) часть F, посвящённая технологии унификации, которой я пользовался последний десяток лет, чтобы создавать все мои руководства для инженеров-менеджеров, включая создание собственно FPF. Идея там в том, чтобы взять несколько разных предметных областей, которые задействуют какие-то понятия с абсолютно разной терминологией, но удивительно похожие по назначению, и предложить унифицированные нейтральные “смысловые” понятия. На выходе - чеклист того, что должно присутствовать при описании какой-то (часто не очень явной) предметной области. Например, есть огромное число стандартов, которые описывают работы, методы работы, описания работ (планы), описания методов работ (инструкции, методологии). И везде эти понятия, нужные для описания “делания” в целом, определяются по-разному, хотя они вроде бы об одном и том же. Я брал – и писал “нейтральное” описание с длинными “синонимическими с нюансами” рядами терминов, означающих “почти одно и то же”.
Дальше я заставил пройти со мной по этой технологии AI (их тут было несколько, но главным образом GPT-5 Pro), получив какую-то таблицу для унификации ровно вот этого: ролей, методов, работ, агентов, систем и т.д. на примере дюжины расхожих стандартов (от OMG Essence и PMI PMBoK до ITIL4, BPMN 2.0 и даже CMNN для case management). Дальше попросил изложить эту технологию в виде набора паттернов на языке паттернов (как раз это и стало частью F), дальше при помощи второго прохода набор понятий про роли-методы-работу был уточнён (не до конца, работа эта продолжается), но в FPF появилась технология унификации. Сегодня я её проверил, как обычно, на трудном примере: попросил Groq-4 (expert, ибо с простыми моделями всё работает много хуже) унифицировать понятия, описывающие пары и тройки шагов в социальных танцах. Сначала поговорил про эти шаги, чтобы сетка разобралась в контексте, а потом попросил выдать Unified Term Sheet по технологии части F. За чуть меньше 7 секунд сетка выдала более-менее интересную таблицу, которую даже непонятно, с кем из людей можно обсуждать, ибо унификация как раз требует экспертизы в огромном количестве тем, что возможно только при коллективной работе или только при обращении к крайне редким экспертам-полиматам (которым ваши разговоры про унификацию заведомо неинтересны). Результат – вот, https://grok.com/share/c2hhcmQtMw==_496d32a5-1566-494e-8437-2647214fddcc (custom instructions там – “Be a top world professional in domain at hand. User is also professional”, вот так просто). Там девять шагов диалога “про танцы”, где потихоньку раскрывается тема большого количества имён для разных “шагов” в разных стилях танцев (контексты), а затем вот такой коротенький промпт: Для всех этих рассмотренных в нашем чате шагов выполни процедуру унификации согласно части F приложенного рабочего файла FPF и выдай UTS согласно паттерну F.17". Всё, дальше короткий отчёт по шагам процедуры и итоговая таблица. Работает! Попробуйте и вы. Конечно, сделать так, чтобы AI думал за вас, не получится: FPF даёт “рельсы мышления” для AI и вас, чтобы результат был чуть более надёжным и получался чуть быстрей, чем без этих рельсов.
Островки твёрдой почвы надёжного мышления в открытом океане неожиданностей.
Я воткнул в предисловие кусок, подчёркивающий роль FPF как налаживание твёрдой почвы в вечном океане неопределённостей. Этот кусок говорит, что FPF создаёт контексты с посылкой закрытого мира (удобно для логических рассуждений) в мире, который заведомо недоопределён (посылка открытого мира, всякие agile и evolution обсуждаются тут).
Представьте, что вы составляете список гостей на вечеринку. Посылка «закрытого мира» (Closed-World Assumption, CWA) предполагает, что ваш список является полным и окончательным, “кто не вписан, того не существует”, человек не приглашён. Это мир определённости, который необходим для баз данных, списков пассажиров самолёта и юридических контрактов: всё, что не разрешено явно, считается запрещённым. Напротив, посылка «открытого мира» (Open-World Assumption, OWA) предполагает, что ваш список может быть неполным. Отсутствие имени в нём ничего не доказывает — возможно, приглашение было отправлено позже или вы просто забыли его внести, или вы уже договорились и поэтому человеку не надо присутствовать в списке. Это мир жизни с её неожиданностью как таковой, науки, исследований и интернета, где всегда можно обнаружить новые факты, а отсутствие доказательства не означает, что доказательства нет: возможно, его просто не привели! “Что не вписано, то просто не вписано”. В посылке закрытого мира “в вазе лежат две конфеты” и таки этих конфет две, а в посылке открытого мира “в вазе лежат две конфеты” это то, что там есть именно эти конфеты, но запросто могут лежать ещё три конфеты и пара яблок – об этом просто не сказано.
First Principles Framework (FPF) не заставляет выбирать между этими двумя подходами, сочетает оба. С одной стороны, FPF построен на посылке «открытого мира»: его принцип открытой эволюции (в паттерне A.4) признает, что любая система или единица знания (эпистема: теория, алгоритм) могут быть улучшены с появлением новых знаний. Фреймворк изначально спроектирован для работы в мире неполных знаний, для бесконечного развития, бесконечной эволюции. С другой стороны, для создания надёжных и предсказуемых систем инженерам нужны “островки определённости”, “комнаты смысла” с чётко наведёнными в явном виде “мостами” между этими островами/комнатами. FPF предоставляет для этого формальный инструмент — тип U.BoundedContext (паттерн A.1.1), это ровно тот самый bounded context, который взят из DDD (domain-driven design), но в FPF он вытащен на уровень общего принципа.
Это “твёрдые куски опоры в рассуждениях внутри ограниченного контекста по поводу жидкого мира из множества контекстов” – это тоже своего рода унификация. Так, в проекте CYC (помните такой проект? я помню!) было замечено, что рассуждения хорошо работают внутри так называемых “микротеорий” (те же boundedcontext), а вот между микротеориями – нет, надо принимать специальные меры по отождествлению понятий. Так, если проводить логическое рассуждение идей “Граф Дракула – вампир” и “Вампиров не существует”, то рассуждений не получится. Но если разделить контексты художественной литературы и научной картины мира, то всё вполне логично. Контексты – это как «комнаты смысла», внутри которых правила, термины и модели считаются полными (посылка закрытого мира), поэтому можно принимать какие-то однозначные решения. Но при этом есть возможность обсуждать, что там не вошло в контекст, чтобы порассуждать и про это тоже – это просто будет рассуждение в другом контексте.
Таким образом, FPF предлагает “рельсы мышления” (да-да, те самые, которые на обложке моего руководства по системному мышлению) для решения сложных задач с участием AI. Он не пытается превратить весь неопределённый мир в одну большую базу данных. Вместо этого он позволяет вам очерчивать чёткие границы (U.Boundary), внутри которых вы можете действовать с инженерной точностью и уверенностью (закрытый мир), при этом всегда осознавая, что за этими границами простирается постоянно меняющийся и полный открытий мир (открытый мир). Этот гибридный подход позволяет создавать надёжные системы, которые остаются гибкими и способными адаптироваться к новой информации.
По большому счёту, это очень похоже на DDD: вы приходите в организацию, в которой в каждой комнате говорят на своём особом рабочем сленге, исторически полученном из каких-то любимых в этой комнате регламентов, стандартов и BoK. А вам поручают сделать какое-то кольцо всевластья какой-то софт, который объединяет их всех. Вы начинаете с того, что строите софт-переводчик: пытаетесь определить для используемых в этих комнатах понятий нейтральные термины, которые конгруэнтны (“синонимы с нюансами”, то есть не полностью тождественны, но как-то похожи), хоть как-то понимаемые в разных этих комнатах. Вот U-Types (унифицированные) типы ровно таковы. В разных комнатах говорят про метод, культуру, способ работы, практику, деятельность, рабочий процесс, методологию и всякое такое, вам надо это отличить от работы, исполнения, прогона и их описаний, а затем обозначить каким-то одним термином, чтобы потом “практику” из одной комнаты отождествить как-то с “культурой” из другой. Весь FPF про это, это ведь и есть “междисциплинарность”.
Унификация вполне себе рабочая задача. Всем ведь знакомы бесконечные совещания, где отделы говорят на разных профессиональных языках (часто они отличаются для разных практик: что у конструкторов “комплектующее”, то у закупщиков – “предмет поставки”), а “единое видение” и “единомыслие” реализуются только как “единоневидение” и “единонемыслие”. Любая попытка что-нибудь сделать в большом проекте будет иметь из-за вот этой “междисциплинарности” огромный “налог на коммуникацию” в каждой попытке договориться. FPF с его унификационной частью F – это ни разу не академическое упражнение в глубокомыслии, это вполне прагматичный инструмент снижения коммуникационного налога. Вы получите “словарь” и понимание, что там “вообще то же самое”, что “не совсем то же самое”, а что “совсем разное”.
Роли как абстрактные маски
Роли и методы в FPF рассматриваются как абстрактные интенсиональные объекты, отличающиеся от описаний/эпистем. Роли и методы отличаются от своих описаний так же, как архитектуры и онтологии отличаются от архитектурных и онтологических описаний. Роль - это абстрактная маска холона (и системы, и эпистемы, и много чего ещё, участвующего в отношениях “часть-целое”), а вот метод - это абстрактная маска работы. Работу может выполнять только система, а не эпистема. Любая работа - это исполнение/execution/run/прогон/performance метода.
Это немного более радикально, чем выглядит на первый взгляд. Ибо агент и constructor/transformer не являются системами! Это роли как “маски системы”, при этом материальная система будет просто носителем/holder маски/роли, и в этой маске в каком-то (ограниченном! микротеория!) контексте будут проявляться некоторые специфические свойства системы, которые важны для роли. Грубо говоря, если у вас система-агент, то смотрите на её характеристики автономности и те методы, которые делает агент (например, агенты обычно планируют, хотя и в разной степени умеют это делать), а если у вас просто transformer (вроде станка, который преобразует какие-то детали, сам не разрушаясь), то вам умение планировать не нужно, но вот насколько в ходе преобразования система-преобразователь остаётся неизменной, а не расходуется и не ломается - вот это важно. Разные контексты подразумевают использование системы и её работы в разных “масках”. Дальше, конечно, алгебра ролей на совместимость.
Идея о том, что «агент — это не система, а роль», решает две вечные головные боли инженера-менеджера. Первая — гибкость. Вам не нужно менять должностную инструкцию инженера, чтобы он на неделю выполнил функцию аудитора. Вы просто «надеваете» на него AuditorRole, но не “навсегда” и “вообще”, а в контексте конкретного проекта. Человек как материальная система тот же, но его ответственность и полномочия временно (window – окно во времени) определены «маской». Вторая — подотчетность. Когда происходит сбой, обсуждение идёт не как «Вася не исправил конфиг, но почему?!», а с задействованием минимум тройки ВасяSystem#OperatorRole:ProductionDB (holder#role:context). Действие (работа/work) неразрывно связано с ролью и контекстом, в которых оно было совершено, а ещё и с моментом времени. Это позволяет создавать гибкие команды, где каждый точно знает, какую «маску» он носит в каком проекте (контексте) и за что отвечает в данный момент (window). Это основное, нюансов огромное количество, но на то и AI, чтобы помогать разбираться с этими нюансами.
