lytdybr

Архитектурно пересобрал библиотеку FPF (https://github.com/ailev/FPF/), там теперь: * FPF Core огромным файлом, и примерно 40 паттернов методологии и open-endedness подняты из DPFs в Core из-за их трансдисциплинарности. * почистили, теперь акцент там на библиотеке FPF, а не просто на FPF Core. Переписали все readme. * справочник по всей библиотеке в корне, FPF Core и дальше большая папка с DPFs. Там лежат отдельные DPF Suites по привычной для человека рубрикации: инженерии (92 паттерна, 2.5MB), менеджменту (182 паттерна, 4.9MB -- да, вот так много, у нас же недаром когда-то МИМ назывался Школой системного менеджмента), инженерии человеческих возможностей (34 паттерна, 1.2MB), фундаментальному (физматвычислительному, с мат. моделированием и нотациями -- 70 паттернов, 2MB) мышлению, а ещё дюжина отдельных DPFs вроде Decision Design (18 паттернов, 0.8MB) или Explanation Design (6 паттернов, 0.1MB), финансового моделирования, экономического мышления, нарративистики и т. д. Под обновившуюся библиотеку FPF сделал апдейт программы резидентуры (опубликована в https://ailev.livejournal.com/1811938.html и обновлена сегодня, начнётся 25 октября 2026) и апгрейд слайдов бесплатного семинара, который будет уже через три дня -- 18 октября, в 11:30, на канале рабочего развития, с названием "AI сэкономил нам кучу времени. Кто-нибудь видел, куда оно делось?" (https://t.me/mim_workdev/288). Там ничего не изменилось, только уточнены паттерны (часть из них успела измениться) и чуть-чуть усилен акцент на развитие. Но ещё для программы резидентуры как "прикладной части", собранной на основе системной мантры, была сделана "теоретическая часть" программы. И вот дальше интересно: я начал генерировать текст русскоязычного руководства D1 (от development) специально под эту резидентуру, целюсь примерно в два томика A5 по 700 страниц с картинками. Это немного, ибо четыре месяца, 350 страниц в месяц, меньше сотни страниц в неделю. Может, и ещё меньше сделаю (и там ведь ещё много картинок весёлых будет). Задача на руководство сложная, ибо надо учесть практический нарратив, теоретический нарратив, а также обеспечить interleaving-изложение и spaced repetition. Сгенерировать такой текст сложно, ибо мне надо мой опыт написания руководств передать не очень живым писателю, художнику, а также проверяющему их редактору. Так, подход "давай сделаем первые два раздела и посмотрим, что получилось" не работает, ибо какой-то сюжет надо ведь тянуть через много разделов, spaced repetition ведь так работает. Ещё и разные контексты и связи в каждом разделе должны быть, чтобы была генерализация знания. Но это уже не первый эксперимент с длинными текстами. И я думаю, что получу текст, который будет отражать свежее состояние FPF Library и который мне не написать за оставшееся короткое время до резидентуры. А мог бы я начать писать раньше? Нет, не мог, поскольку был занят самой FPF Library -- ответом на вопрос "чему учить", а также созданием методов самого обучения, их там в этой библиотеке залежи, и все они активно используются. Сделан сайт библиотеки https://fpf.tools -- и там уже довольно много поправлено в интерфейсе поиска и выдачи для чтения. А с MCP случилась забавная история, которая продолжает разговоры о том, как быстрее отгружать знания, об этом было много в "Тридцать мегабайт мышления: как скормить библиотеку FPF нейросети", https://ailev.livejournal.com/1812981.html. С progressive disclosure — «раскрывать подробности по мере необходимости» — мы оттолкнулись от статьи "Code Mode у Cloudflare" (https://blog.cloudflare.com/code-mode-mcp/): зачем гонять каждое техническое действие через рассуждения модели, если можно объединить обращения и вернуть нужный результат? И там убедительные замеры выигрыша. Полный исполнитель программ копировать не стали, но к нашему MCP добавили пакетный поиск и чтение. На доставке текстов цифры были красивые: большой паттерн E.10 вместо пятнадцати обращений к MCP можно было получить одним. Успех? Конечно -- и это немедленно было вставлено в движок MCP, инструкции все быстро переписали, я ойкнуть не успел. Дальше я попросил измерить не доставку, а решение задачи целиком, причём сравнивать с обычными вызовами, которые тоже можно выполнять параллельно, но ещё и не надо тратить токенов и времени на планирование. Получили двенадцать прогонов трёх задач: устойчивого ускорения не обнаружили, а учтённые входные и выходные токены, включая кэшированный вход, выросли во всех трёх сравнениях. Подготовку пакета измерили отдельно: устойчивого преимущества там тоже не получилось. Обычному подключению вернули его семь простых инструментов, пакетный вариант удалять не стали, но оставили отдельным режимом для программ с заранее известным набором запросов. Но это не всё! Обнаружился источник множества запросов к MCP: из самых благих побуждений запросы выполнялись с ограничением на 18K знаков, поэтому, если агент решил, что ему нужен паттерн целиком, ему надо всё равно планировать 18 запросов. И это не полезное progressive disclosure, а техническая работа, навязанная кривой организацией нашего MCP (не спрашивайте, почему так -- делали ведь из лучших побуждений!). Исправили: теперь обычный вызов возвращает выбранный паттерн, раздел, диапазон разделов или целый файл какого-то DPF полностью, а порции остались -- но только по явному запросу клиента, если у него и впрямь какие-то ограничения. Заодно восстановили определения ссылок и сносок, находящиеся вне выбранного фрагмента (а то фрагмент берётся, а сноска остаётся где-то в другом месте), и исправили чтение диапазонов с повторяющимися заголовками. Всё работает, в очередной раз отлаженный порядок доступа описан в инструкции подключения https://fpf.tools/connect. Если у кого-то есть плагин FPF Library в ChatGPT, то вам хорошо бы зайти через настройки на страницу этого плагина и выполнить там Refresh, чтобы ваш агент смог воспользоваться новым, более удобным для него вариантом MCP. У нас ещё один инженер-менеджер стал директором по развитию, задача -- подготовиться к выходу на IPO. Первый же запрос к FPF -- к Organization Change Engineering, и всё для начала ориентации в сложном проекте вполне заработало (конечно, там начали делать карточки -- "мышление письмом" -- про важные объекты, на которых надо удерживать внимание в проекте). Как всегда, на эти темы мы можем говорить удивительно мало. На вопрос "продемонстрируйте ваше могущество, покажите ваших директоров по развитию" мы можем только разводить руками, ибо большинство из них предпочитают оставаться в тишине, "на всякий случай". По паре раз за день объясняю, что FPF Library -- это не онтология и не инструмент для создания онтологии. Слово "онтология" за последнюю пару десятков лет все выучили, но за это время поезд фундаментальных знаний опять ушёл куда-то на фронтир. Библиотека FPF и сам FPF Core -- не онтологические фреймворки (сравнение с OBO, FIBO и т. д. неверно, хотя какая-то своя подобная онтология в FPF есть, шила в мешке не утаишь). FPF Library -- это методологический фреймворк (ответ на вопрос "что нам делать", а не на онтологический вопрос "что у нас тут есть"), более того, это методологический фреймворк развития (ответ на вопрос "мы тут всё уже сделали, но что нам делать следующим?"), и это не просто развитие, а бесконечное развитие по линии рассуждений open-endedness. Не открытое, как обычно переводят, а бесконечное (проверьте у David Deutsch, у него даже книжка называется "В начале бесконечности", и это та самая бесконечность развития -- отсутствие каких бы то ни было пределов развития). В МИМ мы как раз пытаемся развивать сообщество, практикующее культуру бесконечного развития -- развития личности человека, человека с AI-агентом, команды, организации как команды команд, экосистемы организаций (на общество в целом пока не замахиваемся). Согласно паттерну C.36 в культурной эволюции важную роль играет канон, и вот этот канон -- как раз библиотека FPF. Канон здесь -- не окончательная истина, которую остаётся заучить один раз и на всю жизнь, а общее знание, позволяющее передавать способы работы, обсуждать их и развивать дальше. Это довольно быстро меняющийся канон. И вот теперь канон есть, и можно было выпустить начальный, ещё не очень полный и не очень отлаженный набор стратегических документов для Мастерской инженеров-менеджеров, смотрите его тут: https://github.com/MimEcoSys/mim-strategy. Там начинается так: "MIMDEV — комплект документов о развитии Мастерской инженеров-менеджеров (МИМ) и её способности помогать людям и организациям развиваться. Он предназначен для сотрудников МИМ, участников сообщества, инженеров-менеджеров и компаний, рассматривающих совместную работу. Под бесконечным развитием здесь понимается приобретение новых возможностей с инициативным продолжением после успеха: человек или коллектив замечает следующую стоящую проблему, выбирает или строит способ её решения, осваивает недостающее и начинает новый шаг. Рассматриваются человек, его работа с AI, команды, организация, сообщество и внешняя среда, включая конфликты между их интересами". Вот это важно: "инициативное продолжение после успеха".