Ура, всё работает, причём не только у меня!
У репо, где лежит FPF (GitHub - ailev/FPF: First Principle Framework), уже 59 звёзд и 18 форков, я принял один PR и решил один issue.
Не обо всех форках мне известно, но вот Иван Закутний в закрытом чате семинара по FPF рассказал о том, как он дистиллировал при помощи Claude FPF в небольшой размер (порядка 5% от исходного) и дальше использует его в Claude Code для целей принятия архитектурных решений и их документирования при программировании сложных задач (GitHub - m0n0x41d/quint-code: Structured reasoning commands for Claude Code, Gemini, Cursor and Codex — hypothesis-driven decision making with auditable evidence trails), A set of slash commands for AI coding tools that implement hypothesis-driven reasoning. You generate competing ideas, verify them logically, test them empirically, and document the rationale. Based on the First Principles Framework (FPF). У этого проекта уже самого 41 звезда и 2 форка!
Он пишет: “Несколько дней и над разными дежурными и не дежурными, большими задачами (в том числе инженерно-менеджерскими) я поработал с таким Claude Code. Результаты впечатляющие, дороги назад - нет”. The core loop:
- Generate multiple hypotheses
- Verify them logically
- Test them empirically
- Audit for blind spots
- Decide with full rationale documented
Ещё Иван пишет интересные эвристики, когда использовать FPF в его Quint Code, а когда просто использовать vanilla Claude Code:
Use FPF WhenЕщё один проект у Станислава Недбайлова, GitHub - venikman/ACP-inspector: A holon‑centric, model‑based protocol conformance harness that acts as a passive proxy between ACP clients and agents., A holon-centric, model-based protocol conformance harness that acts as a passive proxy between ACP clients and agents. FPF найти там трудно, но в ReadMe есть строчка: This repo adds a First Principles Framework (FPF) view on assurance and observability.
Architectural decisions — Long-term consequences need documented rationale
Multiple viable approaches — Systematic comparison prevents anchoring bias
Team decisions — Auditable trail for async review and future onboarding
Unfamiliar territory — Structured research reduces “confident but wrong” outcomes
Decisions you’ll need to defend — Evidence is stored; re-evaluation becomes trivialDon’t Use FPF When
Quick fixes — Just fix it
Genuinely obvious solutions — Implement directly. But be honest: is it actually obvious, or just familiar? Obvious to whom?
Easily reversible choices — Try it, iterate, learn
Time-critical situations — Use Claude’s built-in plan mode instead
Well-understood patterns — Apply known patterns. Same caveat as “obvious” applies.Decision Heuristic
Is this decision:
□ Hard to reverse?
□ Affecting more than a few days of work?
□ Involving multiple unknowns?
□ Likely to be questioned later?If any checked → Consider FPF
If none → Skip FPF, use Claude’s plan mode or just decide
И ещё один проект – прямо внутри мастерской, FPF уже используется в программе рабочего развития. Предварительный план резидентуры по “распожаризации” (6 недель):
0. Установочная встреча – знакомство, настройка на прохождение резидентуры
- Отличать модели и физический мир
- Отслеживать трату ресурсов на выполнение работ
- Различать метод и работу
- Общаться на правильно выбранном языке (рабочее название)
- Концентрироваться на важном
За время прохождения этой резидентуры вы:
– выделите себе время на разбирательство с вашими проектами
– начнёте понимать, что такое First Principles Framework (FPF) и будете применять его для решения ваших рабочих задач с LLM
– разберётесь с основными причинами, почему вы не понимаете ваших менеджеров, а они не понимают вас
– начнёте лучше понимать важное
Second Principles Framework начинается с выплаты архитектурного долга
Довольно много времени потратил на архитектурные изыскания вокруг “инструкции по созданию SPF”, second principles framework. Если FPF - это нулевые и первые принципы, то дальше должны быть фреймворки прикладные, по вторым, третьим и так далее принципам (я об этом рассказывал на семинаре). Танцы, медицина, теплообменники, программная инженерия – мало ли что, главное, что прикладное. Сказано – сделано, какой-то драфт инструкции уже есть, но пока не верьте ему, он даже не в формате языка паттернов, просто “большой текст”. Чтобы отладиться, я даже добавил туда сгенерированное по инструкции SFP-Min-EA (минимальный вариант для evolutionary architecture), пропмты там вроде таких: “В файле у тебя спецификация FPF, а ниже в тексте SPF-задание и SPF-Min-EA. Найди, какие проблемы в SPF-задании приводят к проблемам полезности SPF-Min-EA в реальных проектах. Текст SPF-Min-EA разрабатывался в соответствии с SPF-заданием. По итогам дай правки в unified diff в code block в SPF-задание и краткий коммент о том, что сделал и что надо делать дальше”. И дальше два текста, всё вместе сейчас где-то на 80Кзнаков. Эксперименты с этими SPFs для разных дисциплин делаю не только я, это ж “производственные регламенты”, это всем нужно. Это только я тренируюсь на чём-то более-менее абстрактном типа той же evolutionary architecture, остальные – сразу “быка за рога”, поближе к корпоративным стандартам.
Сейчас у меня задача превратить инструкцию по созданию SPF в просто паттерн G.14 с подпаттернами, а для этого нужно выполнить довольно большой рефакторинг FPF в целом. Так что день-два повожусь ещё с архитектурными долгами (принцип телевизора, который чем сложнее устроен, тем меньше кнопок в его управлении и настройках – а самый сложный телевизор управляется вообще с голоса и всегда знает, что надо показывать и какой громкости должен быть звук, и с каких входов или антенн брать сигнал и какой канал показывать):
– удаление ATS harness (E.11) отовсюду в пользу GateCrossing hooks (а A.21, задающий гейты в TGA, я уже сгенерировал)
– доделка механизмов скоринга, индикатризации и так далее, одновременно вытаскивание универсальной части из паттернов G
– и только после этого можно думать о переходе с трансдисциплин и дисциплин на иерархию нулевых, первых, вторых и так далее принципов.
В этой работе прямо в промпты приходится писать и вот такие фразы, ибо мы не можем подойди сейчас нормально к понятию архитектуры, оно ведь многоуровнево: “замечание про плохую модульность схемы, где есть только трансдисциплины и прикладные дисциплины. По идее, есть в ядре часть про “нулевые принципы”, про первые принципы (условно это всё было трансдисциплинами), а дальше будут SPF, но может быть и TPF, фреймворк третьих принципов, знание ведь иерархично, а не строго дихотомично. С этим бы тоже разобраться. В частности, где есть структура и значимые решения агента, там есть и архитектура (понятие, очень похожее на нулевой принцип), где есть архитектура, там есть evolutionary architecture как первый принцип, относящийся к любой архитектуре, ибо эволюция пронизывает все картины мира, а ещё есть evolutionary software architecture по мотивам ThoughtWorks, как в примере SPF, это как раз будет удобно представлять как SPF. Тут тоже нужно решение”.
Результаты даже с этими ни разу не модульными черновиками получаются более чем убедительные у всех, кто с ними пробовал работать (пока они лежат вот тут: SPF-задание.md — Яндекс Диск). Скажем, грузите FPF, свой прикладной SPF (корпоративный регламент) и просите проверить какую-нибудь докладную записку. Всё, ловится “несоответствие корпоративному стандарту”. А как писать корпоративный стандарт? Это и есть SPF-задание. Вот этот кейс я не сам придумал, это мне прислали уже успешный успех: докладная записка от ChatGPT по поводу несоответствия проекта документа корпоративному стандарту. Так что “работает даже на черновиках”.
Но итоговый DoD (definition of done) – мы можем сказать “возьми FPF и сгенерируй набор паттернов SPF для <дисциплина>” (например, повторить генерацию для evolutionary architecture и получить уже не “просто текст”, а как набор прикладных паттернов-плагинов SPF-EA к FPF. Это если без нюансов, но нюансы есть, и они существенно замедляют работу.
Строгаем мастерство SoTA-мышления новым рубанком
Переехал с Obsidian на Sublime Text, набитый плагинами. Obsidian хорош для персонального использования для маленьких файлов, над которыми навешан Zettelkasten (граф ссылок, табличная база данных и т.д.), а мне нужно профессиональное использование для редактирования больших (3MB) файлов, на которых Obsidian виснет, и будет виснуть, там движок показа файлов Electron. Про Sublime Text мне напомнил Михаил Гусаров, а ведь я уже когда-то работал с Sublime Text, но потом перешёл на книжные редакторы (нужен был WYSIWYG с вёрсткой), затем книжные редакторы не выжили по тем же причинам – медленно жевали большие файлы, перешёл на Word с заметками в Evernote, затем переполз на Obsidian.
Но теперь вздохнул полной грудью: в Sublime Text мой трёхмегабайтный FPF просто летает. Ну, и повайбкодил немного: питоновский плагин для накатывания unified diff, получаемого от LLM. Там оказалось в итоге 1127 строк (38Кзнаков, ибо строчки дают плохое представление об объёме текста, питоновский код – это ж как стихи Маяковского, который придумал писать “лесенкой” для увеличения суммы при построчной оплате). Я хочу, чтобы было всё хорошо с UX, но ещё и LLM выдаёт редкостно плохого качества unified diff, поэтому плагин настроен на “полуручное” накатывание: то, что в hunks есть, но не удалось найти и накатить, показывается рядом – отфильтрованное уже от накаченных hunks и тех hunks, которые ничего не меняют (такие “удалить и тут же вставить то же самое, изменений поэтому нет” hunks обычно имеются в изобилии). Git теперь работает через плагин GitSavvy. В любом случае, “у плотника новый рубанок”, примерно такой настрой, заодно чуток попрограммировал, “никогда этого не было, и вот опять”. В итоге в части ручной работы с текстом всё стало происходить много быстрей и надёжней. Хотя какое-то количество проблем в текст недоотлаженный плагин накатки diff внёс (что-то он не заменял в тексте, а просто вставлял где-то рядом), я их постепенно найду и закрою.
Разгон RAG
На прошлой неделе подъехала GPT-5.2, но по факту никаких улучшений, кроме вечного перескока с Pro на Auto (очень раздражало!), я не заметил. Вероятно, я не математик и у меня нет олимпиадных задач. Картинки генерирует такие же безобразные по сравнению с Nano Banana Pro, как и раньше. И создаёт ложное впечатление, что режима GPT-5.2 Thinking хватает, но что это не так, осознаёшь только когда возвращаешься на Pro. При этом Pro в этой версии оказалась удивительно болтлива, она вываливает все мысли, только успевай читать. И я вроде бы разобрался, почему надо именно Pro: сетка занимается tinkering с инструментами, в том числе с RAG, решая 90% времени задачи не содержательные, а добычи информации из окружения (RAG прежде всего в мой немаленький файл) и подготовки ответа (требую unified diff, чтобы быстро накатывать изменения). И вот содержательная работа идёт быстро, а работа с RAG и созданием набора патчей – медленно. У Thinking банально не хватает времени сделать её хорошо, а у Pro – хватает.
Но это не должно быть так! И я начал принимать меры. Много спрашивают, как у меня там внутри устроено: файл FPF ведь явно не лезет в контекст! Конечно, я надеюсь на RAG – рассказывал подробно на семинаре. И тут тонкости. Так, ChatGPT очень качественно работает с RAG для некачественных текстов вроде FPF. За счёт чего? А просто там этим занимается “могучий ум”, который решает всякие недоработки в интерфейсах. Недоработок там тьма, некоторые параметры машинки RAG, например, не присутствовали при обучении сетки, бедная тварь каждый раз тыкается в это – и делает открытия после десятка неудачных попыток воспользоваться старым известным ей описанием, забавно читать это, но это занимает драгоценные минуты размышления дорогой модели, а не доли секунды. Но главная недоработка – это сам текст FPF, который “для людей”. Поэтому его надо оптимизировать для RAG.
Долго у меня висел вопрос о том, как же делать человеко-машинночитаемый Markdown на 3MB, ибо там сразу запредельно большое число уровней заголовков, человекочитаемость не признаёт никаких JSON, а ещё надо хоть как-то помогать RAG разных производителей и даже Markdown разных рендеров, ибо нам неизвестен целевой pipeline. Представьте паттерн второго уровня в кластере какой-то части, и у него четыре подуровня, а вытаскиваете вы это клочками на 4К максимум, хотя эти клочки и с перекрытием. Всё машинное время уходит на сборку паззла, так не должно быть.
Ключевое соображение тут в том, чтобы в каждом подзаголовке надо человекомашиночитаемо указывать, из какого это паттерна – это и люди прочтут (у них на экране откроется обрывок текста, и сразу будет понятно, из какого паттерна какой части и какое примерно место этого паттерна), и не совсем люди с их RAG тоже. Поэтому заголовки будут формата вроде “#### E.8:4.1 - Canonical Pattern Template” – и ожидается, что LLM с ним разберётся получше, чем с JSON или HTML тегами-комментариями, ибо для них “заголовки” являются первичными источниками информации, а все эти “разметки” – вторичными. Ну, и заголовок ни один пайплайн не отрежет, а вот “разные теги” отрезаются запросто. Там ещё немного разного синтаксического сахара для RAG (и для людей), вроде явного маркирования конца паттерна как ### E.8:End.
Части становятся первым уровнем Markdown (# E), а паттерны принудительно все выводятся на второй уровень (## E.8), подпаттерны идут через точки уровнево вниз, а разделы паттерна идут дальше через двоеточие.
Сам E.8 я уже поправил, а дальше оказалось что заголовки и маркер End проще всего сделать вообще “руками”, прямо в Sublime Text. Основная проблема теперь – перелопатить всё. Это надо сделать через не могу, и с автоматизмами тут явно будут проблемы (я смотрю иногда, как LLM пытается находить начало и конец паттерна, и понимаю, что я точно всё сделаю руками и точнее, и быстрее, и попорчу по пути всего поменьше).
Из новинок – паттерн E.19, который проверяет паттерны и результат выдаёт в unified diff по промпту “В файле спецификация FPF, которую мы улучшаем. Проверь паттерн A.1 по нормам паттерна E.19. Прочти сначала полностью текст этих паттернов”. Про “прочти полностью текст” – это не моя отладка для RAG, это просто очень полезная напоминалка, без неё LLM читит.
. Это очень удобно. Я взял паттерн A.1 и проверил, как он вытаскивается без разметки и с разметкой. Разница доходила до пяти минут! При этом рассуждение тоже пошло быстрее, ибо ссылка пошла на тег/номер раздела, а не на его полное имя.
Так что часть работы я уже выполнил: все паттерны уже на одном уровне ##. Если надо искать какой-то паттерн, то искать надо с regex примерно вот так: “^## B.2.5” – и всё быстренько и точно находится уже сейчас. Но дальше надо будет сделать апдейт всех вообще паттернов, чтобы они соблюдали нормы нового E.8 (а заодно проверить там и всё остальное), это будет большое и долгое приключение. Увы, пока у меня скорость работы поменьше, чем один паттерн в день.
Почему это всё надо делать? Я всех учу с того, что надо первым делом наладить управление конфигурацией. А кто у нас главный пользователь, которому надо точно знать, что есть и что где лежит? Этот пользователь – RAG, он разбирается с бардаком в файле в силу своего суперинтеллекта, как и люди, которые тоже вполне могут работать в бардаке, только долго из-за неминуемых переделок/re-works. Поэтому идём lean, но без этих ваших нечитабельных JSON.
