Текст FPF последнюю неделю я не менял, но новости про него таки есть:
- на GitHub у него уже 207 stars, 41 forks, GitHub - ailev/FPF: First Principle Framework.
- есть восхитительный групповой отзыв от студентов Вячеслава Кунина: “Вчера со студентами обсудили, что именно из того, что я им дал в рамках курса как сильно подняло качество ответов в ChatGPT. … 3. Использование FPF (First Principles Framework) как документа, структурирующего ответы ИИ, чтобы не было общих, бесполезных ответов. … Было невероятное удивление, что теперь нет бестолковых ответов - или ответ есть, или чёткое обоснование того, что тут качественного ответа не может быть получено. … FPF – тут бомба, сказали, что на сложных задачах просто кратное улучшение” (https://www.facebook.com/veaceslav.cunev/posts/pfbid02mhiRDB6c6c3ZCNfzoGtWM3y9D5NghyUu3fQs8yiZfotiWszpPX8UhyLQMAJr1vu1l).
- Principled Claude Code как ещё одна попытка сделать skills на основе FPF – GitHub - m0n0x41d/principled-claude-code: Claude Code profile is doing its best to force our little friend to follow the First Principles Framework., и тут интересная история. Первый заход был обычный: “инструмент, обеспечивающий аудит” (и дальше показана цепочка hypotheses → predictions → evidence → decisions, которая мало похожа на аудит, а больше напоминает какой-то общий “исследовательский процесс”, даже не замкнутый в цикл), но если поглядеть в дерево файлов, то там да — просто расписана структура записи evidence, чистый аудит. Но тогда это не Principled Claude Code, а Evidenced Claude Code или Audited Claude Code. С учётом материалов семинара “Развитие для развитых” я дал совет развернуть уже всё от Agile (цепочки) в циклы (DevOps работа) и далее двойные циклы (фабрики проблем и решений) с опорой не на одиночные гипотезы и решения, а на работу с портфелями и явными операциями выбора в качестве решений. Предложил скормить не просто FPF для дистилляции, а FPF+слайдомент семинара “Развитие для развитых”. Без вот этого слайдомента всякие агенты плохо считывают развитие в FPF, они считывают это как “проверяемое и воспроизводимое творчество”, далее прокидывают творчество (ибо у них DevOps bias у всех — “проверить-записать”, это очень естественно!) и остаётся только вот эта “проверяемость”, от творчества только отсылки к “какие-нибудь девелоперы там сбоку пусть сами творят”, а всё новое про проблематизацию и стратегирование “не резонирует” с этим выученным DevOps менталитетом, за этим надо следить специально. Это всё было передано Claude Code, чтобы он там всё сам как-то переделал. И вот поглядите, как хорошо получилось – таки все фабрики на месте! Тут вдогонку надо, конечно, ещё заметить трудности текущего момента: LLM плохо сами разрабатывают skills, но очень выигрывают от использования skills. Это описано в статье “SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks”, [2602.12670] SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks. Self-generated Skills provide no benefit on average, showing that models cannot reliably author the procedural knowledge they benefit from consuming. Focused Skills with 2–3 modules outperform comprehensive documentation, and smaller models with Skills can match larger models without them – с оговоркой, что результаты сильно отличаются для разных предметных областей. Мой вывод: если не давать AI-агенту “самостоятельно разрабатывать skills”, но добавлять процедурное знание из FPF+слайдомента, получается всё более чем неплохо. Вот тут про то, как получить слайдомент и видео разъяснений к нему, если пропустили семинар “Развитие для развитых”: Telegram: View @modelcollect
- ещё один отзыв после семинара: Развитие для развитых (там вот так: “Что касается моих проектов, я по результатам этого текста написал 11 разных пунктов, где надо бы посмотреть NQD-характеристики и Парето-фронт. Просто приведу пример (который, конечно, для операционного использования требуется доработать), который даёт нейросетка с FPF и слайдами семинара: характеристики, по которым стоит оценивать партнерство с трейдинговыми командами” – и дальше пример).
- ещё и ещё раз обсуждается вопрос, должен ли я писать инструкцию, как использовать FPF (и слайдомент к нему по “Развитию для развитых”) в самых разных операционных системах, в которых самые разные приложения, в которых самые разные LLM и в которых ещё и какие-то лимиты и детали интерфейса меняются каждую неделю. Нет, я делаю FPF как стабильный концептуальный продукт – а дальше уж каждый сам пристраивается к именно своему любимому приложению в эти две недели, пока у него стабильный интерфейс и лимиты на размеры файлов, а потом пристраивается после своих инструментальных изменений ещё раз, опираясь на сообщество таких же пользователей конкретного инструментального окружения.
- мой план по FPF остаётся прежним, я пойду по нему с начала марта, как и планировал – вот тут я его написал наиболее подробно, 1 февраля 2026: Начинаем февраль 2026: громадьё планов по FPF: ailev — ЖЖ.
Выявили интересный паттерн в последних наших наборах: приходит инженер по специальности А (скажем, программист), занимающийся какой-то предметной областью Б (скажем, трейдинг). Дальше задаём вопрос про целевую систему – и обнаруживаем, что никаких рассуждений по поводу предметной области Б не происходит ввиду незнания носителем специальности А предметной области Б. Вот буквально: ни один учебник не читан, типовые решаемые проблемы неизвестны, типовые методы решения этих проблем неизвестны, что там на Парето-фронте и какие характеристики – непонятно. А как же работа?! А вот так, “по наитию” – опыт общения с коллегами, опыт чтения каких-то постов в блогах, документации к софту, и прочих обрывков знаний. Например, ещё ни разу не было, чтобы люди разобрались в том, что такое рынок ценных бумаг, какие там основные проблемы, чем занимается инфраструктура, чем именно торгуют (ибо не “бумагами” же! что такое “ценная бумага”, почему рынок “фондовый”?). Всё то же самое – с ERP, где по поводу “плана” и его характеристик, а также “что там меняется в ресурсах, и что это там за ресурсы в ERP”, “где тут у вас поток и как именно на него влияет ERP, если вы внутри ERP поправите какую-нибудь запятую или измените цифирку” ответов обычно нет. На это накладывается “недержание типов” и неточность в составлении текстов. Это не у каких-то конкретных людей, тут “ничего личного”, это типовой сценарий, там часто несколько человек участвуют в групповом обсуждении, с одинаковым примерно успехом – см., например, рассмотрение ERP и там мои комменты – Задания: системы в физическом мире из руководства R5. Системное мышление. Я предлагаю там пойти и почитать учебники, но почему-то до этого действия не доходит, продолжается “угадайка”, и это, повторюсь, не только конкретно эти участники диалога, по факту такое мы видим буквально со всеми, кто работает с ERP. Исключение я видел только один раз: когда ERP занимались люди, хорошо освоившие теорию ограничений Голдратта, но не те, кто “читали про теорию ограничений”, ибо все читали, мало кто освоил мышление согласно этой теории. У меня когда-то был способ входа в новую предметную область – прочесть три учебника разных авторов (всего три книжки, дел на неделю), что было упомянуто во всех трёх, то и считать “предметной областью”. Я понимаю, что “прочесть три учебника” – это заведомо невыполнимое действие для большинства нынешних инженеров-менеджеров (я не обижаю, я констатирую факт). Но работать, не зная предметной области – это тоже нехорошо. А как проверить, знает ли человек предметную область?! И какую? Скажем, в резидентурах R1-R4 моделируют предметную область – но надо бы разобраться, люди берут в моделирование предметную область А (своей специализации) или предметную область Б (и тут мы в довольно обширном графе создателей и надо разбираться – это предметная область нашей системы, целевой системы или какой-то ещё системы). Но так и хочется добавить какие-то замеры знания предметной области:
- основные объекты и отношения (на R1-R4 это точно моделируют, knowledge graph – онтологика как раз про это),
- что там “течёт”, что меняется в процессах (системное моделирование, R6: функциональные диаграммы или принципиальные схемы в этой предметной области какие?),
- типовые проблемы, типовые методы их решения (методология, R7) и дальше плавный переход к характеризации и Парето-фронту на этой характеризации (пока тут только слайдомент семинара “Развитие для развитых”).
Вообще, очень много пишу сейчас в самые разные чаты, в том числе закрытые чаты моих семинаров и резидентур R5 и R8. И мне кажется, что мы не решили до сих пор окончательно проблему с типами:
- она как-то решается лишь к R8, но я ведь ожидаю, что её нет уже на выходе R4! Реальность пока не соответствует моим ожиданиям: в ответах на отдельные прямо заданные вопросы типы удерживаются, но в длинном тексте всяческого “мышления письмом” – нет. Надо выяснить, что там происходит. Вот программист за типами в коде программы точно следит, в псевдокоде – неизвестно, в простом тексте – заведомо не следит. При этом “тип” – понятие растяжимое. Скажем, в FPF контроль kinds устроен примерно так же, как “промышленное использование ISO 15926” (то есть используется набор из 201 понятия ISO 15926-2:2003, а не из нескольких тысяч понятий), или примерно так же, как типизация была устроена в IBM Watson (там было примерно 160 типов при выигрыше в Jeopardy! – ESG currently uses approximately 160 semantic types, belonging to a type hierarchy, https://brenocon.com/watson_special_issue/03%20Deep%20parsing.pdf?utm_source=chatgpt.com). И дальше нужно восстанавливать точность текста, используя слова-триггеры и фрагменты онтик с понятной типизацией. Для этого у меня уже запланировано усиление FPF, вот прямо таки первой работой. Затем – отражение в руководствах и перестройка способа, которым мы это даём людям.
- И операции – буквально ведь люди не могут связать “подлежащее и сказуемое” и отследить связную цепочку “что какой объект делал”. Похоже, что надо отдельно учить “длинным точным письменным рассуждениям”, мы этому недоучиваем. Нужна какая-то теория про тексты, и я займусь этим буквально сегодня-завтра, чтобы обсудить на лаборатории по рабочему развитию: идея совмещения управления точностью текста, мышления письмом/моделированием на стадии “как из заметок собрать связный длинный текст и как убедиться, что он связный”, рассказа о длинных текстах от David Deutsch и Alan Kay и разбора “молекулярной теории рассуждений” из “The Molecular Structure of Thought: Mapping the Topology of Long Chain-of-Thought Reasoning”, [2601.06002] The Molecular Structure of Thought: Mapping the Topology of Long Chain-of-Thought Reasoning. Вот на эту последнюю работу я пялился ещё в январе (она мелькнула в лентах), сегодня утром мне на неё ткнули в чате поддержки программы исследовательского развития (Telegram: View @modelcollect), и пока я писал эти строки и кое-что уже прикидывал на эту тему – вышел gonzo-обзор, Telegram: View @gonzo_ML. Так что я тут опять приостановлю своё МИМописание (pun intended) и остановлюсь на денёк на разбирательстве содержания вот этого всего перечисленного. AI-агенты, конечно, научатся речам с управляемой точностью и написанию длинных эссе, но кто-то должен научить и людей, которые будут беседовать с AI-агентами.
Решил попробовать, правда ли, что “The new “AI Photoshop” Seedream 5.0 matches Nano Banana Pro in quality and gives you way more creative freedom”. Попробовал на том же промпте, который выдал картинку предыдущего поста (Мастерская инженеров-менеджеров: почему именно мастерская?: ailev — ЖЖ): “Нарисуй мастерскую инженеров-менеджеров (МИМ). Как устроен процесс развития в МИМ? Как МИМ растёт и масштабируется? Как обычно, в цикле бесконечного развития: осознание проблем → поиск SoTA методов мышления и работы → упаковка в руководства для людей и AI → освоение людьми с наставником → применение инженерами-менеджерами в их проектах → квалификация “мастера” (или даже “реформатора”) по предъявляемому результату → мастера и реформаторы масштабируют культуру как наставники/преподаватели/лидеры МИМ, а Мастерская даёт для этого необходимую инфраструктуру и культуру. Этот цикл прокручивается не годами, а месяцами: руководства обновляются новыми SoTA методами мышления и действия по нескольку раз в год. Стилистика художника Альфонса Мухи, яркие цвета (стилистику подписывать не надо)”. Нет, я не перейду на Seedream 5.0, останусь с Nano Banana Pro. Очередной пример того, что разные продукты занимают разные места на Парето-фронте. Прочтите вот этот обзор, удерживая в голове “разные места на Парето-фронте” – I matched Google's Nano Banana Pro AI image-maker against ByteDance's new Seedream 5.0 model and the real winner surprised me | TechRadar.
