Куда я исчез: никуда, руковожу бригадой нежити
Нет, я никуда не исчез, просто я много работаю - неожиданно (хотя вполне ожиданно) оказался втянутым в переделку интеллект-стека, будучи научным руководителем группы нежити от разных провайдеров.
Испытываю давно забытые ощущения “программирования” (я же был когда-то “суперпрограммистом”, как это тогда называлось, ещё в доперестроечные времена), и вот работа с AI-ассистентами вызывает примерно те же ощущения, прям ностальгия. С другой стороны, промпты не очень похожи на программы, они – промпты, а процесс можно называть по-разному, самое новомодное имя - context engineering (самый свежий guide на эту тему Context Engineering Guide - Google Документы, и да, я знаю все шутки на эту тему). По большому счёту это “артигогика”: настройка AI на какую-то предметную область, как настраиваются большие софтверные Suits, только терминология там чуть другая (я писал давно, что стал бы артигогом, ещё в 2012 году, когда понял, что зима искусственного интеллекта закончилась - Артигогика (artigogy): ailev — ЖЖ. Я не Шмитхубер, но похвастаться тем, что “занимался этим, когда это ещё не было модно” люблю не меньше).
Второе ощущение - это моё “несправедливое преимущество”, ибо LLM похожи на всех остальных людей, с кем я имел дело в ходе “генерального консультирования” (по факту - содержательного руководства группой консультантов в каком-нибудь большом проекте типа отраслевой реформы или реформы крупного предприятия, их там было у меня множество таких проектов в моей карьере консультанта), а также в ходе научного руководства ШСМ/МИМ и даже наставничества наших инженеров-менеджеров. Все ошибки - те же, что у инженеров-менеджеров, поэтому я их быстро замечаю и быстро отлавливаю. Так что дело происходит даже быстрее, чем я ожидал.
По факту нормальная работа наладилась только со свежими (июньскими) версиями LLM, работаю я с Gemini 2.5 Pro из AI-студии Гугла (за тамошнюю подписку не плачу, ибо интеграция в эко-систему инструментов Гугла мне не нужна), а также o3-pro (ощутимо умней o3, я сравнивал - и да, когда платил за Pro подписку $200 в месяц, жаба душила. Но это “по работе”, ничего не поделаешь. Там нет лимитов ни o3, а на Plus подписке я в них упёрся, ни в DeepResearch, а то я и тут тоже упирался) и DeepResearch (в Pro подписке там без лимитов, и совсем необязательно это сводится к Search, можно попросить синтезировать текст до 50Кзнаков, то есть примерно x10 от того, что обычно выдаёт o3 даже в Pro варианте). Двух AI-ассистентов мне хватает с головой (с третьим, хотя Claude 4 рекомендует каждый первый, я бы уже не справился в текущем инструментарии, слишком всё бы стало уже чисто логистически сложно). А меньше двух - не хватает, ибо разные LLM имеют совершенно разные особенности работы, по-разному ставят акценты в критике и даже болтливы по-разному. Всё как с людьми: без некоторого разнообразия голов в команде результаты будут похоже, разделение умственного труда полезно.
Ожиданная неожиданность: переработка интеллек-стека “первых принципов”, проводимая сама “от первых принципов”
Как я пришёл к необходимости работать над интеллект-стеком фундаментальных методов мышления? Напомню мой маршрут:
– надо обновлять руководство по инженерии личности, но там нужна посадка на естественнонаучную понятийную базу
– поэтому берём системное мышление и делаем его апдейт, “унифицированный системный подход”, куда включаем унификацию по ряду предметных областей (от термодинамики до системной инженерии, а learning sciences там только один из примеров). Дальше предлагаем AI предложить структуру оглавления для Руководства по инженерии личности.
– текст про унифицированный системный подход быстро разросся до полноценного фреймворка, при этом значительная часть его оказалась посвящена эпистемологической динамике (это ж всё про системы, описания систем и их взаимоотношение, а также про то, как мы унифицируем разные описания систем из разных предметных областей – что там считаем конгруэнтным, хотя термин поначалу был “функционально унивалентным”, конгруэнтность появилась позже). Поэтому проект был остановлен, когда объём текста стал примерно 85Кзнаков.
– следующий текст был про унифицированную эпистемологию, надо было описывать динамику (изменения) эпистем, определяемых по всем знакомой линии “синонимов с нюансами”: знания/теория/онтология/доказательство/алгоритм. Конечно, кроме проблемы формального описания конгруэнтности, немедленно всплыли старые боли, прежде всего - это мереология эпистем. Мы говорили много лет про идеи Kit Fine, но ничего не делали. А тут начали делать!
– дальше попытались разобраться с унификацией как таковой: кроме системного подхода и эпистемологии нам нужны какие ещё фундаментальные (безмасштабные, то есть одинаковые на каждом уровне композиции и трансдисциплинарные, то есть приложимые к предметам опять таки на разных уровнях мереологической иерархии) методы мышления? Дальше появился формальный FPF (First Principles Framework), где первые принципы понимались по факту как upper ontology, “элементарные понятия/концепты/типы”, до которых происходит декомпозиция обсуждения самых разных ситуаций - с последующей возможностью что-нибудь пересобрать, “исходя из первых принципов”.
– дальше договорились (кто договорился? Я и две нежити под моим чутким руководством), что будет формальная спецификация FPF в виде kernel про то, как оно там всё устроено, фреймворков (FPF как “фреймворк фреймворков”) вроде системного подхода и той самой эпистемологии, только их там оказалось штук семь разных - и ключевой принцип их выделения был в наличии объекта с иерархической композицией (вроде системы и эпистемы), а также фасет - обсуждение каких-то характеристик универсальных декомпозируемых типов, но сами эти характеристики устроены не иерархично, они не безмасштабны. По факту это результат работы методолога: содержание знания, которое потом будет использовано для научения людей, компьютеров и AI, и которое как-то формально проверяемо на полноту и непротиворечивость. В отличие от классических upper ontology, излагаемых в виде FOL knowledge graphs, тут изложение идёт в трёх лексических регистрах: на естественном языке (“для менеджеров”), операторном математическом языке (“для инженеров”), в языке теории категорий (“для спецов по формализации”). И ещё дополнительно в виде файлов для разных tools (скажем, YAML-файлы, чтобы можно было проверять compliance со спецификацией FPF из коробки). FPF получается унифицированием знания, раскиданного как в академической литературе (вроде понятия “эпистема” или “мема” как “эпистема с нюансом”), так и просто путём нахождения конгруэнтных объектов в разных предметных областях по мотивам процедуры, продемонстрированной в работах типа ванчуринской со товарищи таблички конгруэнтности понятий из термодинамики, теории эволюции и теории машинного обучения из статьи Thermodynamics of Evolution and The Origine of Life.
– дальше работа методиста: целевым тут является получение интеллекта как мастерства мышления по фундаментальным методам, описанным в kernel, фреймворках и фасетах FPF. Мышление определяем по методам, разложенным в стек (интеллект-стек фундаментальных методов мышления), а вместо “учебные материалы” говорим о guides, приспособленных для понимания людьми и мышление о которых осваивается в ходе какого-то curriculum, предусматривающего обучение. Это два объекта: Intellect Stack (методы мышления, входящие в интеллект и организованные в виде стека), а также их описания - Intellect Stack Guides. FPF же служит формальным методическим ядром, позволяя иметь самые разные curriculums и наборы Guides для изучения методов мышления интеллект-стека, которые все основаны на первых принципах.
Каждый проход по текстам начинается с предложения панели виртуальных экспертов следовать нормам (принципам, критериям и т.д.) мышления, изложенным в предыдущей версии текстов. Не слишком хорошо работает (приходится напоминать об этом каждый раз), но как-то работает. Разработка первых принципов на основе первых принципов, “раскрутка”, bootsrapping.
Почему нужна унифицированная эпистемология
В современном познании акценты уже давно сменились с метафизической онтологии на эпистемологию, со статики “как устроен мир” в вечных классах на динамику “как мы бесконечно познаём мир”, как меняются наши представления об этих классах. Акцент на инженерию знаний, оценку результатов познания “что мы узнали, и насколько хорошо” и методов познания “как мы это можем узнать”. Онтология и эпистемология оказываются неразрывно склеенными, это просто “знание о мире” (модели/теории/“онтологические описания”/алгоритмы/знания), а эпистемология оказывается “онтологической инженерией”. Знание в онтологии и методы работы со знанием (инженерия знаний, она же – эпистемологическая работа) неразрывны, как предмет метода и сам метод. Но у нас нет никакого способа говорить о знаниях в целом, оценивать какие-то архитектурные характеристики знаний. Архитектурные характеристики мы тут употребляем по весьма размытой аналогии ровно так, как их определяют в evolutionary software engineering: те характеристики знания, которые надо удерживать в ходе длинных коллективных agile open-ended процессов моделирования, чтобы знание продолжало быть evolvable.
Если мы занимаемся инструментарием инженерии знаний (сегодня это прежде всего AI-агенты и моделеры всех сортов, причём моделеры по необходимости склеиваются с AI-агентами), то мы должны понимать, какой инженерный процесс поддерживает этот инструментарий. Этот инженерный процесс (метод работы) базируется на эпистемологии. Беда в том, что эпистемология в таком заходе никак не описана. Есть множество научных статей, но они не носят прагматический характер, больше описывают “как оно бывает”, чем “как надо делать, чтобы получилось хорошо”. Прежде всего надо описать в общем виде знания, чтобы унифицировать изложение инженерного процесса для теорий, описаний непонятного назначения, алгоритмов, онтологий. Затем надо унифицировать изложение метода работы со знаниями, инженерного процесса, “эпистемологической работы”, работы познания. И это надо сделать “по форме”, чтобы абстрагироваться от собственно содержания знаний.
Наш подход тут – предложить пространство знаниевых объектов (эпистем, “письменное знание”, от “писем”, epistle), но не простое, а конфигурационное, как в физике. Это означает, что для каждого объекта в этом пространстве мы задаём не только его координаты, но и координаты точки, куда этот объект движется. Эпистемы становятся векторами в эпистемологическом пространстве, каждый вектор отражает какой-то шаг/операцию познания.
Дальше мы скармливаем эту идею и ещё пару десятков других идей нейросетке o3 Pro, и она выдаёт нам (не сама, но в интерактивном режиме) огромный (300Кзнаков) текст: что-то среднее между position paper, описанием фреймворка, программой исследований и манифестом. Ибо началось всё с описания содержательных моментов, потом продолжилось “а как эту идею воспримут в штыки”, после чего предложено переложить выполнение всех этих замеров архитектурных характеристик знаний (это аналогия! Про композициональность знаний и архитектуру можно много, долго и не очень продуктивно пока говорить) на виртуальные плечи AI-агентов, а в текст попало много “социального”, в том числе я несколько раз выкашивал из текста про учёт интересов женщин и полинезийских племён, равно как выбросы углекислоты в связи с заботой о климате. Увы, в текущей версии не всё оказалось выкошенным, ибо это как в СССР в концертах: хочешь или не хочешь, а песня о Партии и песня о Родине должны в начале концерта прозвучать, так и эти вопросы внимания западной цивилизации к учёту знания полинезийских племён, а также внимания к policy making, понимаемому как знаниевая работа в отношении законодательства. Без этого никак.
Итак, мы имеем вполне рациональный текст про обустройство эпистемологической работы (эпистемология эпистемологии, онтология эпистемологии), а также программу построения эпистемологических Нью-Васюков в условиях развитого AI-агентства. Повторюсь, что текст этот весь – на английском. Те немногие русскоязычные исследователи (впрочем, это ж про Нью-Васюки, поэтому и инженеры-менеджеры тоже), которые его будут листать (на прочтение я не надеюсь), полистают и на английском. Возможно, полистают и какие-то англоязычные коллеги, чего не могло бы быть с русским текстом. По-русски надо будет писать фрагменты в руководства, ибо результат получился чуть интересней, чем в наших руководствах прямо на сейчас. Не уверен, что надо будет делать руководство по эпистемологии, но в программе исследовательского развития – почему бы и нет. Но основной читатель - это разные AI-ассистенты.
Почему потребовалось и всё остальное: идея FPF и Intellect Stack
Конечно, никакого системного подхода не может быть, пока мы не обсудим и системы в их динамике (трансформациях), и их описания в их динамике (трансформациях). То есть системный подход и эпистемология будут в одной упряжке. Но как описывать эпистемологию без того, чтобы не описать иерархию типов и интерпретацию типов (семантику)? А как с описанием самих трансформаций (методов)? А как с …(тут надо вставить длинный список других необходимых для более-менее приемлемой общей картины мира унифицированных и взаимоувязанных понятийных кластеров – upper ontology, мета-мета-модель).
Это надо давать как:
– результат методологической унификационной работы, “чистый сок мысли”: спецификация, FPF (first principle framework, где first principles как раз определяются как унифицированные онтологические примитивы, над которыми будет надстроено обширное прикладное знание). FPF определяется текстом scpecification в четырёх лексических регистрах, отражающих одно и то же содержание на разных уровнях формальности: для менеджеров (“на пальцах”, естественный язык), для инженеров (классическая алгебра, “в терминах операторов”), для спецов-формалистов (теория категорий, “в терминах функторов”), для инструментальщиков (YAML-файлы). FPF – это “фреймворк фреймворков”, и даже больше “фреймворк фреймворков и фасетов”, ибо мы в первых принципах выделяем фреймворки на базе безмасштабных теорий, в которых вводятся какие-то иерархии (вроде системных или эпистемологических уровней, где рассуждение повторяется на любом из этих уровней) и фасеты, где об иерархиях не говорится, но вводятся разные важные характеристики для вводимых фреймворками унифицированных типов (U-Types), то есть это расширения для фреймворков. Например, Aesthetic Facet (AEF), цель которого – To enable the formal assessment of aesthetic qualities, such as elegance, harmony, or simplicity, which are often crucial in design and user experience. Функция AEF: Extends the Assurance Metrics Facet (AMF) by providing new MetricTemplate instances for aesthetic properties. It links to U.Value in the NOF to model aesthetic preferences and can be used to evaluate any U.Entity. Пример унифицированных типов, которые вводятся фасетом эстетики: U.AestheticValue: A subtype of U.Valuerepresenting a specific aesthetic preference (e.g., "minimalism", "symmetry");U.StyleMetric`: A quantifiable metric for assessing adherence to a specific style (e.g., code style, architectural style, visual design language). Как видите, это на вкус, цвет, запах и прочее не слишком отличимо от “ещё одной унифицированной/универсальной upper/top-level ontology”, но есть много особенностей в форме представления (например, FOL формализм не главный в выражении понятий этой онтологии, поэтому сторонники knowledge graphs как наследники semantic web и ранее semantic network подходов будут немного разочарованы).
– результат методической работы (instructional design): интеллект как мастерство фундаментального мышления по первым принципам, описанным в FPF. Это мышление интеллекта мы раскладываем в стек, разные слои которого описываются набором сильнозависимых фреймворков и фасетов FPF, intellect stack. Визуально это как граф фреймворков и фасетов с их взаимозависимостями, разбитый где-то на пять “слоёв” стека. Как прокси для этого результата (помним именно о целевом интеллекте, чьё мышление идёт по описанным в FPF методам, это цель!) будет набор руководств, которым надо следовать (а для этого разобраться в их материале, то есть они должны быть не просто “справочниками методов фундаментального мышления для инженеров-менеджеров” (для этих целей и FPF сойдёт), но и удобны для освоения, “объяснениями методов фундаментального мышления, путеводителем по FPF”. Можно было бы назвать “по содержанию” (FPF Guides), но мы берём функциональное название, “по назначению”, Intellect Stack Guides. Например, это Primer (описывающий всю эту сложную конструкцию, upper ontologies по определению получаются сложными) и пять Guides по слоям стека. Сейчас рассматриваем слои (подграфы всего графа зависимостей FPF) Structure & Reality, Knowledge & Reasoning, Action & Execution, Strategy & Rationality, Governance & Purpose.
– результат инструментальной работы: чтобы поддержать экзокортекс, надо дать более-менее формальное описание. В рамках Software 3.0 можно давать экзокортексу для его настройки прямо FPF или даже Guides. Но с учётом того, что у LLM пока плохо получается работа с отслеживанием формализмов на больших объёмах данных, хорошо бы поддержать и идеи вроде современного извода идей semantic web и knowledge graphs: сегодня это наборы файлов YAML-манифестов и разнообразные .md для документации, да ещё и обязательно в Git.
Конечно, это получается не “готовое решение для всех”, амбиции Нью-Васюков запредельны, но наиболее проницательные команды (в лице меня как минимум) начнут адаптировать эти идеи уже сегодня, “для получения решающего конкурентного преимущества”. Какого? Сначала у меня будет унифицированная версия системного и методологического мышления, потом - системной инженерии, а затем ход на инженерию личности и дальше инженерию организаций (системный менеджмент). Всё по плану, хотя планы по ходу дела могут изменяться. Как побочный эффект - получим тексты на английском, хотя вряд ли сегодня их будут читать люди, а для ботов язык становится непринципиальным, прочтут и на суахили, и на китайском.
Что удалось сделать
В текущей ситуации мы видим извилистый путь познания: много-много текста, которого нет шанса прочесть весь, и он ещё и быстро меняется. Я следую своей обычной стратегии: “сначала под одной обложкой собрать всё, чтобы стал понятен общий замысел: показать MVP. Потом будем долго-долго вычищать ошибки, добавлять фичи и бесконечно развивать”. Общего замысла в результирующих текстах пока ещё ясно не видно, но уже более-менее понятно, как его получить относительно быстро – но с кучей “дублирования с коллизиями”. Скажем, нельзя называть Type System Framework, ибо каждому первому новичку придётся доказывать, что эта System - это совсем не та System, что в Unified Systems Framework. UTF (unified typing framework) тоже нельзя назвать, все сойдут от UTF с ума. Замена - Types-Semantics Framework, но один неживой эксперт говорит, что это будет уже, чем Type System, а другой не менее аргументированно - что это будет шире. Type system это устоявшийся термин во всяких обсуждениях FOL и HoTT (и неживая экспертная панель настаивает, “выкиньте этих из системного подхода из головы, вас ведь перестанут понимать приличные люди, такие как мы”, а вот Type-Semantics это ровно то, что будет интересовать инженеров-менеджеров, и они не считают этих сухарей-формалистов приличными людьми, достойными уважить их интерес в названии фреймворка. Этот спор будет вечным, но неформальный совет от двух разных нейросеток - плюнуть на интересы формалистов, ибо целевая аудитория не “исследователи формальности”, а инженеры-менеджеры, удобно для них и называть, уменьшать число возможных их ошибок.
Галлюцинаций и грубых ошибок - до чёртиков. Так, в одной из итераций я попросил сгенерировать спецификацию CTF, concept taxonomy framework (продолжение размышлений про то, как это всё с типами называется, хотя по смыслу там меньше всего таксономия, но всё-таки и это было попробовано). И мне была в ответ сгенерирована спецификация CTF, content trust framework, но по оглавлению типового фреймворка FPF: модные идеи в самых продвинутых LLM перешибают точное знание узких предметов, как от этого ни защищайся промптами. Вместе с тем, ход на унификацию был вполне хорош – The primary output of CTF is a trust assessment for a content item. This may be a numerical score (e.g. 0 to 1, where 1 indicates maximum trust) and/or a categorical judgment (e.g. High Trust, Low Trust). The framework defines the data structures for these outputs and ensures that they can be interpreted uniformly by other modules. Importantly, CTF is domain-agnostic at its core – it provides generic mechanisms applicable to any kind of content (text, data, etc.), while allowing domain-specific customization via projections (Section 7). И всё было бы хорошо, если бы в эпистемологическом фреймворке не было бы уже шкалы Reliability для эпистем (универсальное имя, под которое попадают и content items), и не было бы замечания The choice of “Reliability” for the R-axis is a deliberate one, rooted in analytic epistemology and the philosophy of science, where the terms are not interchangeable. “Reliability” is the standard term for assessing the objective quality of a belief-forming process or artefact. Process-reliabilist theories hold that a source is epistemically justified when it systematically produces true outputs under well-specified conditions—whether that source is a measuring instrument, an experimental protocol, or a formal proof assistant. Because reliability is tied to repeatability, reproducibility, and consistency, it admits clear operational metrics: proof-replay success rates for formal systems, p-value stability and effect-size drift for empirical models, or mean-time-between-failure for engineered digital twins. In other words, the R-axis tracks the demonstrated track-record of an episteme’s resistance to refutation, independent of any particular user’s attitudes. By contrast, “epistemic trust” typically names a relation between agents and sources of information. It often embeds social and moral factors such as credibility, authority, and vulnerability. Contemporary work on “epistemic vigilance” shows that individual trust levels can fluctuate with context, incentives, and culture. Folding these psychosocial variables directly into a state-space axis would blur the critical distinction between what an artifact has objectively demonstrated and how much a community happens to rely on it. Using the label “Reliability” therefore keeps the KDF R-scale firmly anchored to auditable, domain-specific validation events, while leaving room for separate “trust badges” or network overlays where social dynamics are important. И такого там - на каждом шагу, продирание через терминологические и понятийные джунгли. Это типовое при унификационной работе.
Текущим результатом можно и похвастаться, и наоборот. Вот он, ужас-ужас-ужас онтологических Нью-Васюков (хорошо помним, что лет тридцать назад модно было иметь собственную upper ontology каждому университету, затем двадцать лет назад это было модно иметь для группы университетов и обязательно “на OWL” или “на Common Logic”, лет десять назад это полностью вышло из моды ввиду “непонятной полезности этой адовой ручной работы” и переключения внимания с knowledge graphs на deep learning и нейросети, а сейчас эту унификацию приходится специально обосновывать. Скажем, Our contribution is not a new set of facts or laws about the world. It is a practical, engineering-grade toolkit for thought that empowers you, the expert, to do your work more effectively. This toolkit consists of three concrete components:
-
A Common Language (The
U.Ontology): We provide a rigorously defined, yet intuitive, vocabulary of first principles (U.System,U.Objective,U.Reliability, etc.). This is a “lingua franca” that allows a physicist, a software architect, and a business strategist to communicate about complex system dynamics without losing precision. -
A Universal Checklist (The FPF Modules): The structure of the Intellect Stack itself serves as a powerful diagnostic and design tool. It provides a systematic checklist of questions that forces you to consider any problem from multiple, essential perspectives: What is the system (USF)? How good is my knowledge of it (KDF)? What is the best method to act (MDF)? What is my ultimate goal (NOF)? This prevents cognitive blind spots and ensures a holistic analysis.
-
A Set of Actionable Methods Description (The Guides & Playbooks):** We provide concrete, step-by-step procedures for applying these principles. Our guides are not philosophical treatises; they are operational playbooks that teach you how to model a system, how to assess the quality of evidence, how to structure a rational decision, and how to resolve goal conflicts.
In short, we are not trying to build a single, grand cathedral of knowledge. We are providing better scaffolding, architectural blueprints, and interoperable power tools for all the builders, no matter which part of the cathedral they are working on. Our goal is not to replace the expert, but to supercharge them—to transform deep specialists into more effective, T-shaped professionals who can seamlessly collaborate to solve the complex, interconnected challenges of our time.
Можно ли посмотреть? Если очень интересно, то можно. Но вряд ли вам это будет интересно. Хотя кто знает?!
Вот текущее месиво только двух текстов, которые получились из этого проекта. Там внутри уже много чего интересного, но общая конструкция пока не слишком проглядывает и число ошибок пока зашкаливает. Но, повторюсь: внутри там уже есть заготовки содержания и много чего интересного и нетривиального. Тексты в .md, держу я их в Obsidian, редактирую прямо там, поэтому можно смотреть их судьбу “в прямом эфире” (пока я не перенесу работу в какие-то другие файлы, что сейчас более чем регулярно. И помним, что там всё намеренно в четырёх регистрах, редкостный стиль):
– заготовки к основному тексту 0.75 Mзнаков, FPF specification (full).md — Яндекс Диск
– набор записок о разных аспектах этого проекта и предложения разных вставок (заготовки к заготовкам), 0.5 Мзнаков, Отчёт по мереологии и агрегации.md — Яндекс Диск.
Для сравнения: текущий объём наших Guides (на русском) – примерно 8 Мзнаков, так что есть ещё куда расти. Одна из задач проекта - определить именно понятийный минимум, first principles, дать основания почистить наши разбухшие текущие Guides, а также показать пути модуляризации (те же фреймворки и фасеты как вариант).
Всё это, конечно, интересно только по линии программы исследовательского развития. Те, кто интересуются рабочим развитием – им надо интересоваться позже, “прийти на готовенькое”. Исследования в этой области требуют быть хотя бы чуть-чуть полиматом (скажем, уже как-то одолеть материал текущего руководства по интеллект-стеку фундаментальных методов мышления). Делать FPF - запредельно сложно, слишком много предметных областей, из которых происходит дистилляция/сжатие знания. А программа рабочего развития наоборот: берёшь совсем немного знания из руководств (они уже готовы!) и быстро-быстро применяешь в конкретном проекте. Это как с беспилотным автомобилем: чтобы он управлялся простыми командами “отвези меня в парк потрогать траву”, этот автомобиль должен быть довольно сложно устроен, разработчики должны попотеть и решить множество проблем. И чем больше они проблем решат, тем проще будет потом управляться с таким автомобилем. А есть пользователи, их не волнует сложность устройства и сколько там проблем приходится решать инженерной команде. Их волнует, чтобы было проще пользоваться. Так вот этот текст и вся эта работа с командой нежити – она не должна быть интересна “пользователям”, это интересно только исследователям и инженерам интеллекта (целевого для наших Руководств). Остальным можно этот текст проигнорировать.
Промпт для иллюстрации идеи type system против typing-semantics
Style: Water-colour illustration in the manner of Alphonse Mucha (delicate washes, flowing Art-Nouveau lines, ornamental framing, pastel palette).
Layout: Two vertical panels inside one ornate Mucha-style frame, each panel crowned by a ribbon title in stylised Cyrillic:
• Left ribbon: «Разработка Type System»
• Right ribbon: «Разработка Typing-Semantics»
Left panel (Type System Development)
Foreground: A focused engineer in late 19th century attire, penning inference rules on a parchment. The paper unfurls into precise geometric shapes (squares, triangles) representing syntax trees.
Background motif: Angular gears and drafting tools subtly woven into floral patterns, symbolising formal rules and mechanical correctness.
Colour accents: Cool sapphires and muted gold.
Right panel (Typing-Semantics Development)
Foreground: A philosopher-scientist holding a translucent sphere that contains intertwined vines forming a lattice—concepts merging and branching. Symbols of categories and ontologies glow within the vines.
Background motif: Flowing organic curves, blooming flowers morphing into abstract type icons, hinting at meaning and interpretation.
Colour accents: Warm amethysts and soft greens.
Overall touches
– The central frame is an oval arch of lilies and laurel typical of Mucha, with subtle water‑colour bleeds at the edges.
– Light Art-Nouveau halos behind each figure emphasise their domains (logic vs. semantics).
– Gentle texture of water-colour paper visible throughout.
