Юбилейная серия семинаров по FPF
По итогам первого года разработки (это как раз сегодня, 10 июня 2026, а проект начался 10 июня 2025) я решил провести серию семинаров, чтобы дать обзор FPF в его текущем юбилейном состоянии: чего удалось достичь в этом проекте, какая там излагается картина мира, как можно использовать задаваемое FPF мышление в рабочих проектах в самых разных предметных областях.
Каждый семинар будет идти три лекционных часа (всего 15 часов), у каждого – “слайдомент” от 45 слайдов (то есть по итогам серии семинаров будет ещё и книжка с картинками больше чем на 200 страниц), а ещё я буду выдавать задания после каждого семинара – ровно как мы это делаем в резидентурах, ибо надо же как-то пробовать рассказанное на практике! Выполнение заданий можно будет делать с использованием FPF (который что-то про себя может и сам рассказать на предпочитаемом языке, то есть это не “произнёс на семинаре много непонятных слов – и бросил в недоумении”). Также можно будет обсуждать выполнение заданий и практический опыт использования FPF на работе и для хобби в чатах семинаров, а после всех пяти семинаров можно уже рассчитывать, что появится некоторая FPF-интуиция. Главное – будет знакомство с той современной моделью мира, которая лежит в основе FPF и используется для формулирования проблем в рабочих проектах, а затем решения сформулированных проблем.
Рабочая проблема может быть не замечена вовремя, о ней могут не догадываться: если вы знаете арифметику, то вы понимаете, что деление на ноль – это проблемная ситуация. Но вот не знающие арифметики деление на ноль проблемой могут не считать, просто не знать о том, что это реальная проблема, что так делать нельзя. Всё то же самое верно для проблем системной инженерии, менеджмента и проблем исследовательской работы. Паттерны не только говорят о том, какой ход надо делать в проблемной ситуации, они подсказывают и сам факт того, что ваша ситуация – проблемная. А дальше вопрос к вам: понимаете ли вы, что указанная вам проблема – действительно проблема? Ваше понимание вы не можете делегировать AI-агенту!
Общая идея использования FPF (фреймворк первых принципов сильного общего мышления и действия, и к нему вы будете делать фреймворки вторых принципов сильного предметно-специфического мышления и действия – SPF) в рабочем проекте в том, что сильный интеллект не спасёт плохую постановку проблемы, не обеспечит конкурентоспособность продукта с плохой архитектурой, не удержит внимания в ходе цикла улучшений интересующей вас сущности. FPF в этом поможет, но всё-таки людям придётся познакомиться с FPF чуть поближе: вам нужно будет хотя бы чуть-чуть понимать, какой инженерный процесс FPF считает нормативным, какое мышление FPF считает сильным. И тогда вы будете получать советы по очередному ходу в проблемной ситуации, а если не знали о проблеме – то появится шанс, что не только AI-агент с FPF это заметит и предупредит, но и вы поймёте его предупреждение.
Максимальная польза – для инженеров-менеджеров с квалификацией от стратега (это те, которые прошли наши резидентуры R1-R4, Квалифицирование инженеров-менеджеров: измеряем агентность, масштаб, методологическую дисциплину: ailev — ЖЖ), но это может быть интересно и всем остальным – в том числе и тем, кто не проходил наших резидентур. Семинары должны сделать FPF не столько “чёрным ящиком”, который хорошо работает, но хотя бы немного "прозрачным ящиком. Семинар не будет опираться на материалы руководств МИМ, а сразу будет излагаться прямо “по FPF” (и если что осталось непонятным – можно будет спросить у своих любимых AI-агентов, а также потренироваться на своих же рабочих проектах).
Вот эти семинары:
- FPF как “прозрачный ящик” (итоги первого года разработки FPF как языка паттернов для смешанной работы людей и AI-агентов над проблемами в рабочих проектах) – 28 июня 2026
- От системного мышления к архитектурному мышлению.
- Рабочие процессы: от проблем через принципы к работе (transformation-flow structure и P2W).
- Как хватать за язык себя и других (управление точностью языка).
- Как сделать технический регламент для AI-агентов в форме языка паттернов для вашей предметной области (second principle framework, SPF на основе FPF).
Серия устроена как движение от общего фундаментального/трансдисциплинарного к прикладному/предметному: сначала разберём, что такое FPF, зачем он нужен, как устроен, а потом отдельно посмотрим на архитектурное мышление, рабочие процессы, точность языка, а в конце — как на этой базе делать SPF для своей предметной области. Дальше немного подробностей про каждый из этих семинаров:
1. FPF как “прозрачный ящик” (итоги первого года разработки FPF как языка паттернов для смешанной работы людей и AI-агентов над проблемами в рабочих проектах) – 28 июня 2026
28 июня 2026 года пройдёт юбилейный семинар, на котором будет рассказано не только о том, как использовать First Principles Framework в рабочих проектах, но и как он в целом устроен и почему оказывается так эффективен. Разработка FPF началась год назад (10 июня 2025 года), а с учётом применением самого FPF в ходе его разработки и выхода новых рабочих сред для AI-агентов, удалось резко поднять скорость самой разработки FPF. За последние три месяца FPF был существенно доработан: теперь его использовать можно и для проблематизации, и для архитектурной работы, и для работы с проектной документацией, и для организации цикла улучшений для победы над конкурентами. Тем не менее, работа FPF выглядит “чистой магией”: инженеры-менеджеры признают его эффективность, но не понимают, почему это так. Понимание делегировать AI нельзя, поэтому делаем семинар специально для этого.
FPF представляет собой “язык паттернов”, этих паттернов сейчас около 250, это паттерны/шаблоны наиболее успешных действий (ходов) в проблемных ситуациях. Какие это проблемные ситуации? Часть из них перечислены как “входные” прямо на странице проекта в GitHub (GitHub - ailev/FPF: First Principles Framework (FPF): Pattern language and core specification for admissible action in problematic engineering, research, and mixed human/AI work. · GitHub), например, разработать или проверить архитектуру; написать рабочие правила, методы и документы; сравнить варианты решений и принять итоговое решение; превратить мутную ситуацию в рабочую постановку проблемы (проблематизация); задать, что значит “лучше”, и запустить цикл улучшений; дать проектным сущностям хорошие имена; починить формулировки в технических документах до того, как они начнут менять ожидаемые действия; понять, нужна ли математика или формальная модель, или лучше пока без них; собрать текущее поле возможных решений и портфель вариантов решений. Конечно, это только примеры, а решаемых с помощью паттернов сильного мышления FPF проблем много больше. Примерно 250 паттернов – это описание примерно 250 видов проблемных ситуаций, в которых вам предлагается полезное первое действие (ход, move) по её решению. Для решения крупных проблем потребуется много ходов, вы задействуете много паттернов – они действуют не поодиночке, а совместно, как слова в языке, из них набираются осмысленные фразы – осмысленные цепочки действий. Поэтому и название формата, в котором составлен FPF – “язык паттернов” как язык, из которого в разных ситуациях вы будете составлять полезные фразы.
Не надо читать FPF, технические стандарты – не слишком увлекательное чтиво, там “кондовый канцелярит” вместо “художественной попсы”. Технические стандарты не читают, их используют. Вот и FPF не читают, его используют. Ситуация облегчается тем, что FPF читают главным образом не люди, а AI-агенты – им такой язык вполне понятен. Паттерны FPF составлены так, что ими пользоваться будут и люди (они написаны на английском языке), и AI-агенты. Типичный способ использования – положить его на диске в папку проекта рядом с другими документами проекта, как это обычно делают с техническими стандартами. Читать FPF необязательно, но обязательно иметь общее представление о той модели мира, которая в нём описана.
Мы предлагаем, чтобы FPF использовали ваши AI-агенты. FPF как набор технических стандартов будет фокусировать их на обнаружении и решении проблем в ваших рабочих проектах. Но чтобы это не выглядело “магией” и чтобы вы не теряли контроля за ходом решения этих проблем, надо как-то понимать: в чём же именно “магия” (по третьему закону Кларка любая продвинутая технология ведёт себя как “магия”), о чём можно разговаривать с AI-агентом, если у него в документах проекта доступен FPF как сборник около 250 технических стандартов поведения в проблемных ситуациях. Например, FPF использует онтики для основных своих понятий: холона, системы, эпистемы, и прочих фундаментальных понятий. Что это такое, зачем это в FPF, как влияет на “магию”? Вообще, почему и так заведомо умному и всезнающему AI-агенту помогает работа с паттернами FPF?
Об этом и будет первый семинар, он будет обзорный по текущему состоянию FPF. В том числе там будет и краткий обзор тем следующих четырёх семинаров, масштаба 1:10 – по двадцать минут на тему вместо трёх часов развёрнутого рассказа, так что появится шанс понять, как это всё такое разное в FPF скомпоновано и согласовано.
2. На семинаре «От системного мышления к архитектурному мышлению» разберём обобщение системного мышления до архитектурного мышления, которое нужно для выработки архитектурных решений.
Отдельно обсудим архитектурные характеристики, межуровневые структурные конфликты, неустроенности от этих конфликтов, компромиссы (в которых нет “лучших решений”), а также типовые ошибки архитектурного мышления. Один трёхчасовой семинар не сделает архитектором, но даст достаточно материала, чтобы не считать архитектурную работу разговором про красивые схемы и диаграммы.
Системное мышление удобно начинать со структурного отношения часть-целое: атом, молекула, органелла, клетка, организм, популяция — это разные масштабы, разные предметы рассмотрения и разная физика или биология, а на верхних системных уровнях это вообще социология. Системное мышление помогает удерживать связность рассуждения на всех этих уровнях. Между системными уровнями наличествуют неизбежные конфликты (например, клетки хотят размножаться, органы хотят расти, но если клетки печени начнут размножаться без меры и печень начнёт расти без меры, то организм сочтёт это опухолью, раком. Легко представить ту же ситуацию в организации: подразделения хотят расти, но компания легко может говорить как о необходимости роста себя в целом, так и считать рост подразделения организационной опухолью, раком). Без системного мышления такие ситуации обсуждать трудно, ибо надо удерживать внимание одновременно на разных системных уровнях. На физических объектах это объяснять проще: части и целые обычно видны. С описаниями, моделями, документами и знаниями (общее слово тут – “эпистема”) сложнее: является ли описание атома частью описания популяции, а глава — частью книги? Поэтому следующий ход – это переход к холоническому мышлению, где в центре холон: система или эпистема, которая является одновременно частью какого-то целого, но и сама является состоящей из частей.
Архитектурное мышление идёт дальше. Отношение часть-целое в холоническом мышлении — только один вид структуры. В работе важны и другие структуры: функциональные (вопрос “что каким способом делается”), модульно-интерфейсные (как собираемся из частей в целые), управляющие (кто начальник, а кто дурак), информационные (структура данных), финансовые (куда будут потрачены деньги). Архитектура — это выбранные в данном проекте (контексте) важные структуры, по которым принимают архитектурные решения. Если вы выбираете структуру подразделений как групп людей, функциональную структуру как “кто что делает в ходе работы”, то эти структуры и будут архитектурой организации. И конфликты можно будет обсуждать в терминах этих структур. Архитектура начинается там, где мы выбираем не все возможные структуры объекта, а те, по которым надо принимать решения (мы называем их архитектурными решениями): что в проекте менять, что сохранять, где провести границы проекта, какие потери ввиду неминуемых проблем принять, какие характеристики надо удержать. Так, вопросы о том, делать ли централизованную структуру управления организацией или децентрализованную, матричную структуру управления или функциональную – это типичные архитектурные вопросы. На какие части разделить авиационный двигатель, чтобы раздать его разработку разным подразделениям (правую и левую половину? топливный насос и всё остальное?) – тоже архитектурный вопрос.
Структура — это организация типизированных отношений, ограничений и инвариантов внутри рассматриваемого объекта. Архитектура — это выбранные в данном проекте (контексте) важные структуры, по которым принимают архитектурные решения. Поэтому архитектурное описание, диаграмма, схема, модель или даже текст архитектурного решения полезны, но они не являются самой архитектурой. Они помогают увидеть и сформулировать, обсудить и проверить архитектурное решение.
Материалы семинара опираются на архитектурные паттерны FPF, этот материал ещё нигде не рассказывался. После семинара можно будет не только самому аккуратнее думать об архитектуре, но и ставить такие задачи AI-агенту, давая ему файл с FPF: попросить его найти архитектурный вопрос, выбрать важную структуру, составить и/или проверить архитектурное описание, предложить архитектурные решения.
3. На семинаре «Рабочие процессы: от проблем через принципы к работе (transformation-flow structure и P2W)» разберём, как переводить проблемную ситуацию в рабочий ход, план, выполненную работу и проверку результата.
Этот семинар будет про то, как в рабочих проектах не перепрыгивать от красивого принципа сразу к выполнению работ на базе этого принципа. Принцип обычно даже не в начале. Между проблемой и успешным результатом работ обычно выполняется множество самых разных операций: надо понять, какая решается проблема в каком проекте (контексте), какой там будет математический аппарат, какие принципы связывают эту математику с реальностью, какое семейство методов будет выбрано на базе этого принципа, какой конкретный метод будет выбран для планирования работы исходя из текущего состояния рабочей ситуации, в том числе доступных ресурсов, затем разобраться с планами, выполнить работу по плану (даже если это было “планирование на лету”), разобраться с полученным результатом и решить – что делать с этим результатом дальше. В FPF эта цепочка поддержана паттернами онтики изменений/transformation. Изменение/преобразование – это операция изменения формы какого-то объекта, например, переход механической энергии в электрическую или перевод с одного языка на другой. Поток преобразований может быть описан как граф. Набор паттернов “от принципов к работе” (principles to work, P2W) помогает в самом общем виде описать все эти упомянутые переходы, из которых набирается поток.
Граф потока преобразований описывает самые разные потоки: от потоков электричества или жидкости, до потоков данных, документов и прочих сущностей, которые потока претерпевают разные обработки со стороны систем, которые в их роли в этом потоке называем преобразователями/создателями/transformers. Преобразования/изменения превращают спецификации в тесты, архитектурные описания — в задачи технического долга, экспериментальные данные — в принимаемые решения, запуски модели — в отчёт об исследованиях, телеметрию по итогам работ — в запрос на улучшение. Рабочий процесс (workflow) – это типовой поток преобразований, равно как и потоки работ из операционного менеджмента. Даже граф состояний альфы из OMG Essence – это тоже граф, описывающий изменение состояния каких-то объектов в ходе их преобразования по каким-то методам.
Важно не путать сам поток этих преобразований/изменений, его описание (например, диаграмму), планы работ, работу. Но ведь ещё в FPF есть и другие слова для описания преобразований: метод, механизм, морфизм. На семинаре разберём, как видеть в проекте такие преобразования, где проходят границы потоков преобразований (в том числе различения design time и run time), как устроены проверки в потоках работ, чтобы не проверять всё вообще после каждого шага.
P2W нужен в другой типовой ситуации: проблема уже вроде бы поставлена, но непонятно, какой следующий ход делать. Например, команда видит перегрев узла, сбой интеграции, плохую воспроизводимость эксперимента, медленное выполнение работ или слабое качество ответов AI-агента. Слабый ход — сразу назначить виновного, выбрать любимый метод или написать план работ. Сильный ход — спросить, что именно переносится из постановки проблемы в следующий шаг: физическое ограничение, математическая структура, требование к интерфейсу, архитектурная характеристика, ограничение по времени, свидетельство, шкала качества или необходимость вернуться к исходной проблеме. Вам подсказали, о чём следует подумать: дали чеклист построения workflow. P2W как раз такой “чеклист построения рабочего процесса”.
На семинаре будут разные рабочие примеры, а не один большой учебный случай “сквозного примера” – как раз чтобы подчеркнуть универсальность структуры потока преобразований и P2W. Инженер всё время разрабатывает функциональные архитектуры, принципиальные схемы – это как раз оно. Организатор разрабатывает рабочие процессы, операционный менеджер работает с потоками работ – это тоже оно. Семинар расскажет, как обо всём этом думать.
Практическая польза семинара в том, что после него можно будет ставить AI-агенту более точные задания не только о важных объектах проекта, о которых надо подумать, но и о важных процессах/изменениях/методах/механизмах и выполнении по ним работ. Для инженера-менеджера процессное мышление на основе потоковых структур преобразований и P2W даёт способ не терять связь между проблемой и результатами работ по её решению (там ведь может быть очень много промежуточных преобразований). По большому счёту, семинар будет уточнять понятия метода и работы, то есть это “методология в FPF”. После семинара можно будет брать свой рабочий проект и просить AI-агента с FPF помочь в работе и с рабочими процессами, и с принципиальными схемами.
4. На семинаре «Как хватать за язык себя и других (управление точностью языка)» разберём, как удерживать точность слов в рабочих разговорах, документах и заданиях AI-агентам.
Этот семинар будет про то, как замечать и искоренять мутную речь – когда вроде всё понятно в тексте, но при ближайшем рассмотрении оказывается, что выбранные вами или вашими собеседниками (людьми или не очень людьми) слова обозначают непонятно какие сущности. Как будто разговор идёт местоимениями и междометиями, в которых дети пересказывают мультфильмы (матерная речь с небольшим количеством корней, обозначающих что угодно устроена так же). В проектах так постоянно бывает с “готово”, “качество”, “поддерживает”, “система”, “согласовано”, “архитектура”, “процесс”, “уровень”, “эффективный”. Нет двух человек, которые одинаково понимают, что такое “согласовано” (это когда специалисты договорились, или когда начальник кивнул, или когда собрали все визы, или когда уже выпустили приказ?). Управление точностью языка в FPF поэтому сразу уходит от лексики в семантику (лексика плюс онтология).
Начинаем с понятизации: путь от “ощущения понятия” к точному слову, с которым уже можно работать. Иногда человек ещё не знает, как назвать, но уже чувствует: “что-то не то”, “вот, это как раз оно”, “ответ вроде гладкий, но ему нельзя верить”, “слова ужасные, но что-то в этом есть содержательное”. В FPF это поддержано паттернами работы со слабыми кинестетическими сигналами как с дополнительным интерфейсом к нейросети человеческого мозга. Это как раз то место, где “произнесённое Дао – ненастоящее Дао”, это учёт особенностей человеческой биологии. Методики focusing и учёта dynamic quality как раз работают с увеличением точности языка, когда ещё нет языка, когда вместо слов одно мычание (вот буквально – все эти “эээ” и “ммм”, когда “слов нет, одни эмоции”). Начинаем с допонятийного ощущения уместности или неуместности, которое надо удержать достаточно долго, чтобы оно стало проверяемым словом.
Продолжаем с восстановления точности словоупотребления на том самом “рабочем матерном”, когда AI-агент выдаёт страницами какой-то абсолютно пустой текст, в котором вроде всё правильно, но содержания нет. В FPF это поддержано паттернами восстановления точности словоупотребления (wording-use ontological precision restoration), и там хитрый алгоритм правки: сначала надо по описанию попытаться восстановить ситуацию (контекст), затем определить, какие типы объектов участвуют в этой ситуации (взять “онтику” – фрагмент онтологии и использовать её как чеклист “о чём надо подумать”), затем предположить математический аппарат и принципы (теорию), получить для выбранных типов (kinds) объектов подходящие имена, имеющие однозначную трактовку (не “мы получили оборудование”, а “станок M634 сейчас монтируется в цеху номер 3”).
Отдельно разберём канцелярит. Канцелярит часто появляется не от любви к длинным оборотам, а потому что автор прячет неуверенность в типе сущности: “осуществить актуализацию процесса обеспечения” вместо “обновить правила проверки”, “обеспечить согласование” вместо “получить решение от такой-то роли”, “провести мероприятия по повышению качества” вместо “выбрать характеристику, шкалу, целевой уровень и провести работы в цикле улучшений”.
Отдельная тема – AI-агенты. У них часто нет собственного устойчивого языка проекта: они подхватывают ближайший термин, сглаживают различия, делают гладкую фразу вместо точного хода. Их натаскивали на “понравиться”, а не на “точно сказать” – они могут точно говорить, но об этом их надо специально просить, а затем проверять, как они выполнили просьбу. FPF здесь полезен как кладовая практических приёмов для AI-агентов. Это совсем не “улучшить стиль”, это про важность онтологической работы там, где работа вроде бы идёт с языком.
Практическая польза семинара в том, что после него можно будет быстрее ловить ложные договорённости в документах проекта, писать более короткие рабочие документы, точнее ставить задачи людям и AI-агентам и проверять, выполнены ли эти задачи, или вам дали пустой текст ни о чём. Вряд ли вы сможете быстро это всё делать сами. Но с помощью FPF ваши шансы на то, что вы схватите кого-то за язык, выше (даже если этот “кто-то” – AI-агент и языка не имеет, pun intended).
5. На семинаре «Как сделать технический регламент для AI-агентов в форме языка паттернов для вашей предметной области (SPF на основе FPF)» разберём, как сделать для AI-агентов рабочий предметный регламент, а не ещё одну папку с промптами, даже обозванными skills.
FPF помогает не терять проблему и не принимать гладкий ответ AI-агента за решение. Но общего мышления мало. В любой предметной области есть свои рабочие приёмы, свои старые ловушки и свои признаки халтуры. AI-агент должен знать это так же, как новый сотрудник: какие решения здесь обычно проходят, какие советы звучат убедительно, но в жизни не работают, где нужен расчёт и по каким формулам, какие бывают типичные новичковые ошибки.
SPF (фреймворк вторых принципов) – это как раз такой предметный слой поверх FPF как фреймворка первых принципов. Он описывает не “вообще сильное мышление” (это удел первых принципов, фундаментальное знание), а профессиональную работу в конкретной предметной области. Вторые принципы мы задаём так же, как и первые: языком паттернов, предназначенных как раз для описания того, что делать в проблемных ситуациях. FPF и SPF устроены по форме одинаково (эта форма тоже описана паттернами, это паттерны части E в FPF), только FPF занимается фундаментальным мышлением и действием, общим для всех проектов, а SPF – прикладным, общим только для проектов в какой-то предметной области (выплавки стали, воспитания дошкольников, марикультуры). Для AI-агента этот SPF превращается в технический регламент: не фантазируй “по теме”, а работай по правилам предметной области.
Число прикладных предметных областей огромно, и каждый должен разобраться с предметными областями своих проектов (их ведь много разных в каждом проекте) сам. На семинаре покажем, как такой SPF собирать. Начинать надо не с красивой классификации области, а с реальных провалов и повторяющихся задач: где AI-агент даёт банальный совет, где команда каждый раз спорит заново, где новичок не видит важного ограничения, где эксперт сразу говорит “так в жизни не делают”. Дальше надо поднять современную рабочую практику области: не просто набрать ссылок, а понять, какие приёмы сегодня считаются рабочими и почему старые ответы уже не годятся (определить SoTA, лучшие из известных методов работы, state-of-the-art). После этого отформатировать собранный материал в формате паттернов, которые можно давать людям и AI-агентам.
Один пример уже был разобран в посте про организацию кастомизации без потери масштабирования (Организация кастомизации без падения масштабирования (пример SPF): ailev — ЖЖ). Продуктовая компания хочет помогать конкретному клиенту, но не хочет каждый раз превращаться в консалтинг. Это не решается общими словами про “клиентоориентированность” или “масштабирование”. Нужен предметный регламент: когда локальная доработка остаётся оплаченной работой под клиента, когда из неё надо вытаскивать продуктовую возможность, как не сломать дорожную карту продукта, кто принимает решение и как потом не забыть, зачем это решение приняли. Такой регламент уже можно дать AI-агенту, чтобы он помогал не абстрактным советом, а в логике продуктовой работы. И это, конечно, не общее знание, которое будет применимо во всех компаниях и во всех проектах – это прикладное знание, оно получит свой SPF, но не будет включено в состав FPF.
На семинаре будут и другие рабочие случаи. Как сделать предметный регламент для AI-агента, который помогает проверять проектные решения. Как настроить AI-агента для поддержки цикла улучшений продукта, а не для генерации общих рекомендаций. Как описать правила работы в исследовательской программе, где нормальный ответ часто не “выбери лучший вариант”, а “сохрани несколько конкурирующих линий и проверь их разными способами”. Смысл не в том, чтобы написать толстый стандарт. Смысл в том, чтобы AI-агент начал видеть вашу работу глазами нормального специалиста в нужной предметной области, а не глазами усреднённого “читателя интернетов”. AI-агент с SPF не становится инженером-металлургом или врачом, но перестаёт отвечать как Гугль.
Практический результат семинара – участники смогут начать делать свои SPF по самым разным предметным областям в своих рабочих проектах. Взять FPF, добавить предметные материалы и реальные случаи из своей области, попросить AI-агента провести исследования и сделать первый черновик паттернов, разложив материал по нескольким паттернам SPF, затем провести цикл улучшения этих паттернов. После этого AI-агента уже можно просить не “помоги по нашей теме”, а “работай по нашему предметному регламенту”. Впрочем, эти регламенты могут помочь и людям (читать их не так приятно, как художественную литературу, но это общее свойство всех технических регламентов: их читают вынужденно, “чтобы разобраться и затем им следовать”).
