Три шага чтобы попробовать pattern language Анатолия Левенчука на своём проекте. С двумя примерами Name Card и списком ловушек, в которые легко попасть с LLM.
В первом посте мы разобрали, что такое FPF: откуда он берётся, как устроен базовый словарь, чем он отличается от учебника. В каталоге ситуаций посмотрели 25 конкретных кейсов, где паттерны FPF решают реальные задачи.
Этот пост про третий вопрос: как начать. Без курса, без предварительного изучения файла на 7 мегабайт, без специального окружения. Три действия, два примера с разными контекстами, и список ловушек - особенно одной, в которую попадают почти все при первом знакомстве с LLM + FPF.
Важная установка перед началом: FPF - это не инструмент, который нужно освоить. Это инструкция, которую читает LLM. Вашей задачей остаётся задача: описать ситуацию, задать вопрос, получить ответ с дисциплинированной структурой вместо общих советов. Всё остальное делает модель.
Минимальный протокол: три шага
Шаг 1. Загрузить файл FPF в чат LLM
Спецификация FPF лежит в открытом репозитории: github.com/ailev/FPF. Это один большой markdown-файл. Скачиваешь, открываешь чат с любой LLM - ChatGPT, Claude, Gemini, что привычнее, - и прикладываешь файл как attachment.
Один нюанс, который влияет на качество ответов. Если работаешь со своим документом - PRD, спецификация, ТЗ, постмортем - сначала прикрепляй свой документ, потом FPF. Контекстное окно LLM читается в определённом порядке, и более ранние части получают чуть больший вес при генерации. Твоя задача должна быть в фокусе; FPF - инструкция для модели поверх неё.
Никакого специального промпт-инжиниринга делать не нужно. Просто файл + вопрос. Если видишь, что модель отвечает поверхностно - попробуй повторить вопрос и явно попросить «используй паттерны из FPF». Часто достаточно одного уточнения.
Шаг 2. Сразу формулировать задачу о своём проекте
Открыть разговор так: «У тебя подгружен файл FPF - спецификация для рассуждений. Помоги мне с задачей: [твоя задача своими словами]».
Не нужно сначала «изучать FPF». Задавай вопросы про свой проект прямо сейчас, и LLM начнёт применять паттерны из файла. В ответе появятся имена вроде A.6 Boundary Discipline или F.18 Name Card. Если имя незнакомо - это хорошо: теперь есть точка для следующего вопроса. «Расскажи подробнее про F.18 и как именно ты его применил к моей задаче». Так FPF осваивается не как абстрактный текст, а через конкретику своей работы.
Не пытайся за один разговор решить весь проект. FPF раскрывается на конкретике: одна задача - один разговор. Попытка вложить в один чат пять разных вопросов размывает контекст и снижает качество ответов.
Шаг 3. Работать кусками
Алгоритм одной рабочей итерации:
- Сформулировал задачу и отправил
- Получил ответ с паттернами FPF
- Уточнил то, что непонятно («покажи конкретнее», «а что если убрать это условие?»)
- Довёл до состояния, которое можно использовать
- Записал результат у себя - в документе, в спеке, в задаче
Фиксировать результат важно: чат не сохраняется навсегда, и через неделю LLM не будет помнить этот разговор. Полезное - нужно забирать из чата в свои артефакты.
Оптимальный размер одной итерации - задача, которую можно описать в одном абзаце. Если описание растягивается на страницу - задача слишком широкая, и стоит разбить её на части прежде чем идти в чат. LLM справляется лучше с конкретным «помоги переименовать роль X в контексте Y», чем с расплывчатым «помоги разобраться с командной структурой».
FPF при этом обновляется: авторы коммитят в репозиторий почти каждый день. Если используешь FPF в работе постоянно - имеет смысл раз в день удалять старый файл из чата и загружать свежий. Внутри могут появляться новые паттерны и меняться формулировки существующих.
Пример первый: переименование роли в бизнес-школе
Кейс из практики: бизнес-школа переименовала программу. Раньше были учебные занятия, преподаватели, учебники. Стало - стажировки, наставники, рабочие задания на собственных проектах участников. Возникла проблема: как теперь называть слушателей? Слово «стажёр» формально подходит, но самим участникам не нравится - несёт коннотацию неоплачиваемой работы при крупной компании.
Промпт в LLM после загрузки FPF:
Бизнес-школа переименована в "мастерскую для инженеров-менеджеров",вместо занятий - стажировки, вместо домашних заданий - рабочие заданияна собственных проектах, вместо преподавателей - наставники. Как называтьбывших студентов? "Стажёр" не подходит по коннотациям. Дай Name Card по F.18.LLM возвращает Name Card по паттерну F.18 - в FPF это карточный формат для проектирования терминов. Сокращённо:
Name Card: WorkshopResident / резидент мастерской
1. Row ID: UTS.EMStudio.Role.WorkshopResident.v12. Twin labels: - Tech: WorkshopResident - Plain: «резидент мастерской инженеров-менеджеров» - Short: «резидент мастерской»3. Context: EngineerManagerStudio.v2025 «Мастерская где обучение через стажировки на собственных проектах»4. Kind: U.Role (роль-маска, которую временно носит профессионал)5. Aliases / risky aliases: - «стажёр» - risky (несёт коннотацию неоплачиваемого труда)6. Boundary: WorkshopResident активен только в период программы; до и после - другая роль участникаЭто не финальный ответ. Это черновик для обсуждения: подходит ли слово «резидент», устраивает ли акцент на «мастерскую», не путается ли с другими ролями в экосистеме школы. Дальше - итерации через диалог: «дай вариант без слова “мастерская”», «покажи как изменится Name Card если убрать ограничение по времени», «какой риск у короткой формы “резидент” без контекста».
Ключевая разница между этим ответом и обычным советом от LLM: структура F.18 есть в спецификации FPF, её можно процитировать, сравнить, оспорить. У ответа есть форма - не только содержание. Это позволяет ревьюировать результат как рабочий артефакт, а не доверять ему на слово.
Практически: после того как LLM вернула Name Card, нести его на встречу с командой удобнее, чем нести «мы посовещались и подумали “резидент”». Поле risky aliases объясняет почему «стажёр» нельзя оставить даже как неформальное прозвище. Поле Boundary объясняет, что слово работает только внутри программы - выпускники уже не резиденты, и для них нужна отдельная карточка. Каждый пункт - отдельный разговор с командой, а не одно большое «нравится / не нравится».
Пример второй: переименование роли в IT-команде
Тот же паттерн, контекст ближе к продуктовым командам.
Ситуация: в SaaS-компании была роль «Developer Advocate». В ходе реструктуризации основной фокус сместился с marketing-driven контента на вклад в open-source проекты и community-driven контент. Старое название ассоциируется с маркетингом - нужно новое имя, которое отражает изменившуюся суть работы.
Промпт:
У нас была роль "Developer Advocate" - теперь её основная работа этоPR в open-source проектах и community-driven content, а не маркетинг.Как переименовать? Name Card по F.18.LLM возвращает (сокращённо):
Name Card: CommunityEngineer / community-инженер
1. Row ID: UTS.SaaSCo.Role.CommunityEngineer.v12. Twin labels: - Tech: CommunityEngineer - Plain: «инженер сообщества»3. Context: SaaSCo.DevRel.v20264. Kind: U.Role5. Aliases / risky: - «Developer Advocate» - выходящее, ассоциируется с marketing-driven работой - «Open Source Engineer» - не передаёт community-фокус, только OSS6. Boundary: вкладывается во внешние проекты и публикации, не в внутренний feature developmentЗдесь F.18 подсветил кое-что, что легко пропустить при обычном мозговом штурме: раздел risky aliases показывает, какие термины нельзя использовать как синонимы, потому что они тянут за собой старые смыслы. «Open Source Engineer» технически описывает часть работы - но режет важную половину. «Developer Advocate» - официально устаревшее название, которое при параллельном использовании будет создавать путаницу в организации.
Опять - это черновик, не приговор. Зато черновик со структурой: есть конкретные поля для обсуждения, есть форма для ревью.
Здесь же хорошо видна ещё одна вещь: паттерн F.18 одинаков для обоих кейсов - и для бизнес-школы, и для SaaS-компании. Это не потому что кейсы похожи, а потому что F.18 - про проектирование имён как таковое, независимо от отрасли. Меняется содержимое полей; форма остаётся. Это и есть суть pattern language: общий каркас, конкретное наполнение.
Анти-паттерн: LLM делает вид что использует FPF
Главная ловушка при работе с LLM + FPF - это не сложность паттернов. Это то, что LLM может генерировать ответы, которые внешне похожи на применение FPF, но реально являются маскировкой под него.
Признаки халтуры:
- В ответе много ID паттернов (
A.6,B.3.4,G.4), но они не объясняют ничего конкретного - просто украшения сверху общих советов - Структура ответа формальная, но содержание - общие места из любого учебника по менеджменту или системной инженерии
- На вопрос «покажи конкретный кусок паттерна X из спецификации» LLM пересказывает своими словами вместо цитирования
- Ответ одинаково «работает» для любой похожей задачи - он не привязан к специфике вашего кейса
Как проверять. Задавай вопросы про конкретные детали паттерна. Например: «В FPF в A.6 есть классификация на L/A/D/E - покажи как именно ты применил каждую из четырёх категорий к моему контракту, с конкретными строками». Если LLM начинает выкручиваться, даёт общий ответ без привязки к вашим данным - она импровизировала, а не работала с файлом.
Второй фильтр: задай тот же вопрос дважды с интервалом в несколько сообщений. Если получаешь два сильно разных ответа по структуре - первый был импровизацией. Когда LLM реально работает с паттерном из файла, структура остаётся стабильной: поля F.18 - это поля F.18, а не что-то, что можно переизобрести в каждом ответе.
Третий признак, который легко проверить самостоятельно: попроси LLM указать конкретную строку или заголовок в файле FPF, где описан применённый паттерн. Если она называет раздел - можешь найти его в скачанном файле и сверить. Если начинает уходить в объяснения вместо цитаты - скорее всего, паттерн был придуман на лету.
Это не повод избегать LLM. Это повод не принимать красиво оформленный ответ за верный автоматически. Верификация через конкретику занимает одну-две минуты и отсекает большинство случаев галлюцинации. Особенно часто это всплывает при первых попытках: модель видит большой файл, угадывает стиль и структуру ответа, но не привязывается к конкретным данным из него. Форма правильная, содержание - общее место.
Частые вопросы
Надо ли читать весь FPF перед тем как начать? Нет. Файл большой - около 3000 заголовков, работа с ним как с учебником займёт дни. И польза от чтения без задачи минимальна: FPF раскрывается в применении. Сформулируй реальную задачу, посмотри какие паттерны LLM использовала, и точечно изучи именно их. Если в ответе появился G.4 CAL Pack - прочитай про G.4 через запрос к той же LLM с тем же подгруженным файлом. Три вопроса по конкретным паттернам дают больше понимания, чем час чтения всего документа подряд.
FPF обновляется - нужно следить за изменениями? Если используешь FPF разово - нет. Если в регулярной работе - имеет смысл обновлять файл раз в день. Авторы коммитят активно, могут меняться формулировки и добавляться новые паттерны. Для большинства задач разница между вчерашней и сегодняшней версией незначительна, но если работаешь с конкретным паттерном долго - лучше держать актуальную версию.
FPF не дал ответа на мою задачу - это нормально? Скорее всего задача выходит за рамки FPF. FPF про дисциплину рассуждения: как структурировать, как именовать, как проверять логическую корректность. Если нужен прогноз, факт или оценка - это другие инструменты. Если задача про структуру, но ответ не получается - попробуй переформулировать более узко: вместо «помоги с продуктовой стратегией» - «помоги классифицировать утверждения в этом документе по A.6».
С чего начать прямо сейчас? Возьми реальный документ, который лежит у тебя в работе - спецификацию, ТЗ, постмортем, описание процесса. Загрузи его и FPF в чат. Спроси: «Найди категорные ошибки в этом документе и предложи правки по A.7». Через 10-15 минут поймёшь, нужен ли тебе FPF в работе.
Ссылки:
- Сам FPF: github.com/ailev/FPF
- Что такое FPF (длинный обзор): /blog/ru/what-is-fpf/
- Где помогает (25 ситуаций): /blog/ru/where-fpf-helps/