Зачем редакции Langfuse: версии промптов без переноса качества в продакшн
У редакции, которая много работает с Codex, быстро появляется странная болезнь: вчера заголовки стали лучше, сегодня статьи стали короче, завтра визуалы снова похожи друг на друга, а через неделю никто уже не помнит, какой промпт это сделал. Вроде бы все работали внимательно. Вроде бы были хорошие обсуждения. Но процесс держался на текущем чате, памяти участников и ощущении «мы же договорились».
Для маленького эксперимента этого достаточно. Для production уже нет. Если промпт влияет на заголовок, структуру статьи, тон, визуальный язык, SEO-поля или публикационный gate, у него должна быть версия. Не просто «новый хороший промпт», а понятная запись: что изменилось, почему, где активная версия, какие результаты она дала и когда ее надо откатить.
Здесь и появляется Langfuse. Но его важно правильно поставить в архитектуре. Langfuse не должен быть редактором, художником или заводом публикаций. Он не принимает финальное решение о качестве. Он нужен как слой управления версиями промптов и трассировки: какая версия использовалась, где она сработала, где сломала результат, какую версию считать активной.
В документации Langfuse по Prompt Management эта логика описана как управление промптами с версионированием, метками и получением нужной версии в приложении. В разделе про data model отдельно видно, что prompt имеет имя, версии, labels и config. А в разделе про prompt config полезна мысль: к промпту можно привязывать параметры и потом связывать generation с конкретной prompt version. Для редакции это ровно то, чего не хватает в хаотичном росте: не гадать, какая инструкция породила текст, а видеть след.
Где Langfuse полезен, а где опасен
Langfuse полезен там, где нужно помнить версии. Например, у нас есть разные семейства промптов: для заголовка, структуры, текста, SEO, визуального стиля, object-quality gate. Если заголовки стали слишком абстрактными, мы должны видеть, какая версия title prompt была активной. Если тексты внезапно стали короткими, нужно смотреть не только на автора, но и на article body prompt, длиновой gate и batch-скрипт. Если картинки снова стали декоративными, надо увидеть visual prompt id, version и QA notes.
Опасность начинается, когда Langfuse принимают за production-движок. Это соблазнительно: раз там хранятся промпты, пусть оттуда всё и рождается. Но качество не живет в базе версий. Качество рождается в рабочем контуре: Codex skill берет задачу, читает материалы, применяет правила, создает артефакт, проверяет его и честно пишет, что заблокировано. Langfuse только помогает понять, какая версия правил участвовала.
Именно поэтому правильная формула для редакции такая: canonical prompt lives in project memory, Langfuse mirrors and versions it, Codex skill executes it, human reviews the result, ArticleFactory distributes the ready package.
Как это выглядит для заголовков
| Слой | За что отвечает | Чего не должен делать |
|---|---|---|
| PROMPT_MEMORY.yaml | редакционный закон и принятые решения | не должен быть невидимой свалкой без active version |
| Langfuse | версии промптов, labels, config, trace | не должен решать, хороший ли текст или визуал |
| Codex skill | выполнение работы и создание артефакта | не должен скрывать fallback и обходить gate |
| ArticleFactory | публикация и очередь | не должен писать, рисовать или улучшать качество сам |
| Человек | активная версия, приемка, откат, публикационное решение | не должен вручную помнить всё, что обязана помнить система |
Возьмем простую боль: заголовки начали звучать как документация для программистов. «Codex dependency policy», «agent harness», «context compression». Внутри команды смысл понятен, но читателю уровня владельца проекта неясно, зачем это читать.
Без версионности мы спорим вкусами. Один говорит: «надо проще». Другой говорит: «надо SEO». Третий вспоминает, что раньше было лучше. С версионностью появляется нормальный цикл: есть article.title.codex_business.v1, где написано, что первые 45–60 символов должны назвать человеческую работу, страх, выбор или результат; Codex генерирует 3–5 вариантов; title reality gate проверяет, что заголовок не обещает лишнего; человек выбирает активный вариант; Langfuse хранит версию, по которой это было сделано.
То же самое со структурой. Если статья стала «три абзаца и всё», значит нужна версия structure prompt, где закреплено: вступление до первого H2, одна таблица, практическая карточка, источник внутри текста, блок человеческого решения, нормальный объем. Тогда проблема коротких статей перестает быть настроением и становится нарушением gate.
Рабочая карточка для редактора
Проверь prompt governance для новой статьи.
Тема:
[тема статьи]
Покажи:
1. какая версия title prompt использована;
2. какие были кандидаты заголовка;
3. какая версия structure prompt использована;
4. какие обязательные блоки есть в структуре;
5. какая версия body prompt использована;
6. какие gates пройдены;
7. где trace или ссылка на prompt version;
8. что нужно решить человеку.
Если версии нет, не публикуй как production. Сначала оформи prompt version.Это не бюрократия. Это нормальный способ не терять качество, когда работа стала повторяемой.
Что должен решить человек
Langfuse может показать, что версия изменилась. Codex может применить навык. ArticleFactory может поставить материал в очередь. Но человек всё равно решает главное: какая версия сейчас active, какой результат считать хорошим, где откатиться, где переписать, где заблокировать публикацию.
В сильной редакционной архитектуре Langfuse не заменяет редактора. Он освобождает редактора от плохой памяти. Вместо «почему опять заголовки поплыли?» появляется конкретный разговор: какая версия промпта, какой результат, какой gate, какое решение. И это уже не магия, а управляемое производство смысла.