Большинство SaaS-продуктов собирают аналитику, которую невозможно использовать. Не из-за плохих инструментов, а потому что никто не договорился о правилах именования событий.
Один разработчик пишет
Эта проблема решается не инструментом, а event taxonomy — формализованной структурой именования и классификации событий.
Три уровня таксономии
Каждое событие описывается через три уровня:
Объект — сущность продукта. Account, Project, Subscription, Report. Для типичного SaaS достаточно 8-12 объектов. Больше — таксономия слишком гранулярна.
Действие — что произошло с объектом. Стандартный набор: Created, Updated, Deleted, Viewed, Completed, Started, Submitted, Exported.
Свойства — контекст. Без них
Naming conventions
Формула: Object + Action в Title Case и past tense.
Свойства — snake_case. Булевы с префиксом
Запрещено: глагольные события без объекта (`Clicked` — что именно?), вложенные свойства (`plan.name`), массивы в корне, PII в свойствах.
Как сгенерировать за час
Процесс из четырёх шагов:
0-10 минут — собрать список экранов продукта, сформулировать 10 бизнес-вопросов, выгрузить текущие события (если есть).
10-25 минут — подставить данные в структурированный промпт. AI генерирует первую версию за 2-3 минуты. Проверить покрытие lifecycle от acquisition до retention.
25-40 минут — прогнать результат через валидационный промпт. Типичные находки: пропущены события отмены подписки, слишком гранулярный engagement, нет события-маркера activation. Этот подход повторяет паттерн LLM-as-Judge: один AI генерирует, другой проверяет.
40-60 минут — оформить документацию и план имплементации. Naming conventions, таблица событий, super properties, governance rules.
Типичные ошибки
100+ событий для MVP — data swamp. 25-35 событий покрывают 90% вопросов. Трекинг
Мониторинг после запуска
Три метрики: schema compliance rate (цель 99%+), property fill rate (сколько обязательных свойств заполнено), event volume anomalies (алерты на отклонения >50% от среднего за 7 дней).
Event taxonomy — не разовый проект. Это живой документ. AI сокращает проектирование с дней до часа, но governance остаётся за командой.
Подробный гайд с промптами и шаблоном - в блоге: https://futurecraft.pro/ru/blog/event-taxonomy-ai/
Один разработчик пишет
signup_completed, другой — user_signed_up, третий — registration_done. Через полгода в системе 200+ событий, 60% из которых дубликаты или мусор. Аналитик не может построить воронку, потому что не знает, какое из трёх событий регистрации актуально.Эта проблема решается не инструментом, а event taxonomy — формализованной структурой именования и классификации событий.
Три уровня таксономии
Каждое событие описывается через три уровня:
Объект — сущность продукта. Account, Project, Subscription, Report. Для типичного SaaS достаточно 8-12 объектов. Больше — таксономия слишком гранулярна.
Действие — что произошло с объектом. Стандартный набор: Created, Updated, Deleted, Viewed, Completed, Started, Submitted, Exported.
Свойства — контекст. Без них
Subscription Created бесполезно: непонятно какой план, какой период, откуда пришёл пользователь. Свойства бывают обязательные (timestamp, user_id), объектные (plan_name, billing_cycle) и контекстные (source, device_type).Naming conventions
Формула: Object + Action в Title Case и past tense.
Subscription Created, не Create Subscription и не subscription.create.Свойства — snake_case. Булевы с префиксом
is_`/`has_. Количества с суффиксом _count. Идентификаторы с _id. Временные метки с _at.Запрещено: глагольные события без объекта (`Clicked` — что именно?), вложенные свойства (`plan.name`), массивы в корне, PII в свойствах.
Как сгенерировать за час
Процесс из четырёх шагов:
0-10 минут — собрать список экранов продукта, сформулировать 10 бизнес-вопросов, выгрузить текущие события (если есть).
10-25 минут — подставить данные в структурированный промпт. AI генерирует первую версию за 2-3 минуты. Проверить покрытие lifecycle от acquisition до retention.
25-40 минут — прогнать результат через валидационный промпт. Типичные находки: пропущены события отмены подписки, слишком гранулярный engagement, нет события-маркера activation. Этот подход повторяет паттерн LLM-as-Judge: один AI генерирует, другой проверяет.
40-60 минут — оформить документацию и план имплементации. Naming conventions, таблица событий, super properties, governance rules.
Типичные ошибки
100+ событий для MVP — data swamp. 25-35 событий покрывают 90% вопросов. Трекинг
Button Clicked вместо Task Created — это UX-аналитика, а не product analytics. Отсутствие governance — и таксономия деградирует за 3-6 месяцев. Игнорирование negative events (`Subscription Cancelled`, `Account Deleted`) — AI часто пропускает их, фокусируясь на happy path.Мониторинг после запуска
Три метрики: schema compliance rate (цель 99%+), property fill rate (сколько обязательных свойств заполнено), event volume anomalies (алерты на отклонения >50% от среднего за 7 дней).
Event taxonomy — не разовый проект. Это живой документ. AI сокращает проектирование с дней до часа, но governance остаётся за командой.
Подробный гайд с промптами и шаблоном - в блоге: https://futurecraft.pro/ru/blog/event-taxonomy-ai/
Magic number - это конкретное действие, совершённое конкретное число раз за конкретный период, после которого retention скачкообразно растёт. Не абстрактная метрика, а формула: "пользователь, который сделал X минимум N раз за первые D дней, остаётся с вероятностью Y%".
Классические примеры. Facebook - 7 друзей за 10 дней, retention в 3 раза выше. Slack - 2000 сообщений в команде, 93% команд продолжали платить. Twitter - 30 подписок, возвращаемость на 60% выше. Dropbox - 1 файл в shared folder, конверсия в платный план в 4 раза больше.
Звучит как серебряная пуля. Проблема в том, что найти magic number правильно - значительно сложнее, чем кажется из этих кейсов.
Методология поиска
Берёшь все события за последние 6 месяцев. Для каждого пользователя считаешь, сколько раз он совершил каждое действие в первые 14 дней после регистрации. Параллельно строишь таблицу 30-day retention: вернулся ли пользователь через месяц.
Почему именно 14 дней? Это активационное окно. Короче - отсечёшь пользователей с медленным онбордингом. Длиннее - перепутаешь причину и следствие. Пользователь не потому остался, что сделал действие на 25-й день. Он сделал его, потому что уже решил остаться.
Дальше - перебор порогов. Для каждого действия проверяешь: какой retention у тех, кто совершил его >= 1, >= 2, >= 3... до 20 раз. И сравниваешь с retention тех, кто не дотянул до порога. Чем больше разрыв - тем сильнее кандидат.
Пример вывода: invite_teammate >= 3 даёт 72% retention против 18% у тех, кто пригласил меньше. Разрыв в 54 п.п. — сильный сигнал.
Три ловушки, которые ломают анализ
Первая - принять корреляцию за каузацию. Пользователи, создавшие 10 проектов за первую неделю, пришли с сильным намерением. Заставить всех создать 10 проектов — не значит получить тот же retention. Единственный способ подтвердить причинно-следственную связь - A/B тест: одной группе стандартный онбординг, другой - с подталкиванием к magic number действию.
Вторая - игнорировать confounders. Если magic number работает только для органических пользователей, это свойство аудитории, а не продукта. Обязательно стратифицировать по источнику трафика, тарифу и времени регистрации.
Третья - зафиксировать число навсегда. Продукт меняется, аудитория меняется. То, что работало в прошлом году, может потерять значимость после редизайна. Пересчёт - каждый квартал.
Визуализация порогов
Для топ-5 кандидатов строишь график: ось X - порог, ось Y - retention rate. Ищешь точку перелома: где retention перестаёт расти. Retention растёт с 20% при threshold=1 до 65% при threshold=5, потом плато - 67% при threshold=6, 68% при threshold=7. Magic number = 5.
Что дальше
Найденный magic number превращается в операционную метрику. Activation rate - доля новых пользователей, достигших magic number за активационное окно. Падение - сигнал о проблеме в онбординге. Каждый экран, каждый email, каждое push-уведомление теперь направлено на одну цель: помочь пользователю дойти до этого числа.
Важно: цель не в том, чтобы заставить совершить N действий. Цель - помочь получить ценность, которую пользователь получает после N реальных действий. Magic number - инструмент фокусировки, не подмены смысла метрикой.
Подробный гайд с SQL-запросами и промптами - в блоге: https://futurecraft.pro/ru/blog/magic-number-retention/
Классические примеры. Facebook - 7 друзей за 10 дней, retention в 3 раза выше. Slack - 2000 сообщений в команде, 93% команд продолжали платить. Twitter - 30 подписок, возвращаемость на 60% выше. Dropbox - 1 файл в shared folder, конверсия в платный план в 4 раза больше.
Звучит как серебряная пуля. Проблема в том, что найти magic number правильно - значительно сложнее, чем кажется из этих кейсов.
Методология поиска
Берёшь все события за последние 6 месяцев. Для каждого пользователя считаешь, сколько раз он совершил каждое действие в первые 14 дней после регистрации. Параллельно строишь таблицу 30-day retention: вернулся ли пользователь через месяц.
Почему именно 14 дней? Это активационное окно. Короче - отсечёшь пользователей с медленным онбордингом. Длиннее - перепутаешь причину и следствие. Пользователь не потому остался, что сделал действие на 25-й день. Он сделал его, потому что уже решил остаться.
Дальше - перебор порогов. Для каждого действия проверяешь: какой retention у тех, кто совершил его >= 1, >= 2, >= 3... до 20 раз. И сравниваешь с retention тех, кто не дотянул до порога. Чем больше разрыв - тем сильнее кандидат.
Пример вывода: invite_teammate >= 3 даёт 72% retention против 18% у тех, кто пригласил меньше. Разрыв в 54 п.п. — сильный сигнал.
Три ловушки, которые ломают анализ
Первая - принять корреляцию за каузацию. Пользователи, создавшие 10 проектов за первую неделю, пришли с сильным намерением. Заставить всех создать 10 проектов — не значит получить тот же retention. Единственный способ подтвердить причинно-следственную связь - A/B тест: одной группе стандартный онбординг, другой - с подталкиванием к magic number действию.
Вторая - игнорировать confounders. Если magic number работает только для органических пользователей, это свойство аудитории, а не продукта. Обязательно стратифицировать по источнику трафика, тарифу и времени регистрации.
Третья - зафиксировать число навсегда. Продукт меняется, аудитория меняется. То, что работало в прошлом году, может потерять значимость после редизайна. Пересчёт - каждый квартал.
Визуализация порогов
Для топ-5 кандидатов строишь график: ось X - порог, ось Y - retention rate. Ищешь точку перелома: где retention перестаёт расти. Retention растёт с 20% при threshold=1 до 65% при threshold=5, потом плато - 67% при threshold=6, 68% при threshold=7. Magic number = 5.
Что дальше
Найденный magic number превращается в операционную метрику. Activation rate - доля новых пользователей, достигших magic number за активационное окно. Падение - сигнал о проблеме в онбординге. Каждый экран, каждый email, каждое push-уведомление теперь направлено на одну цель: помочь пользователю дойти до этого числа.
Важно: цель не в том, чтобы заставить совершить N действий. Цель - помочь получить ценность, которую пользователь получает после N реальных действий. Magic number - инструмент фокусировки, не подмены смысла метрикой.
Подробный гайд с SQL-запросами и промптами - в блоге: https://futurecraft.pro/ru/blog/magic-number-retention/
LLM сокращают время написания PRD с 8-16 часов до 1.5-3 часов. Это не прогноз и не рекламный слоган. Это результат workflow из 7 шагов, где каждая секция генерируется отдельным промптом с каскадным контекстом.
Почему классические PRD не работают в маленьких командах
В командах из 3-10 человек три проблемы убивают документацию.
Непропорциональные затраты. Описание фичи, которая делается за неделю, требует 2-3 дня на документирование. Команда выбирает "просто начнём делать". Итог: scope creep, переделки, разное понимание у разработчиков и дизайнеров.
Неполное покрытие. Даже опытные продакт-менеджеры пропускают секции: edge cases, error states, rollback plan, success metrics с порогами. Удерживать 15 секций в голове при описании каждой фичи физически невозможно.
Устаревание. PRD написан в понедельник, к пятнице половина решений поменялась. Обновить 15-страничный документ дороже, чем написать новый.
Структура из 8 модульных секций
Порядок принципиален: Problem Statement и Target Users задают контекст для LLM, а все следующие промпты получают output предыдущих.
- Problem Statement - текущее состояние, pain points с метриками, целевое состояние, impact hypothesis. Ключевое: "23% churn из exit survey" даёт конкретный output. "Высокий churn" даёт generic текст.
- Target Users через JTBD — максимум 3 persona. Ограничение обязательно, иначе LLM генерирует 7-10 типов и размывает фокус.
- Solution Overview - что строим, какие capabilities закрывают какие pain points, happy path. Без технических деталей и UI.
- User Stories с Acceptance Criteria в формате Given/When/Then. Максимальная экономия времени. Отдельный акцент на negative criteria: "система НЕ должна обновлять данные чаще раза в 5 минут".
- Technical Constraints - совместно с техлидом. LLM структурирует по категориям: инфраструктура, данные, интеграции, перформанс, безопасность.
- Edge Cases - пропускают чаще всего. Промпт генерирует 20-40 кейсов по пяти категориям. Половина нерелевантна, но отфильтровать за 15-20 минут проще, чем генерировать с нуля за 2-3 часа.
- Success Metrics - primary, secondary, guardrail (которые НЕ должны ухудшиться), exit criteria с числовыми порогами.
- Out of Scope - что не делаем, почему, когда может вернуться. Плюс допущения и открытые вопросы.
Три принципа качественной генерации
Реальные данные. LLM отлично структурирует, но плохо изобретает метрики. Конкретные числа из аналитики на входе дают конкретный output.
Жёсткие лимиты в промптах. "Максимум 3 persona", "3-5 pain points", "5-8 шагов". Без этого фильтровать дольше, чем писать вручную.
Negative constraints. "Не включай технические детали", "Не упоминай UI-элементы". Модель следует явным запретам точнее, чем неявным ожиданиям.
Минимальный жизнеспособный PRD: три секции - Problem Statement, Solution Overview, User Stories с Acceptance Criteria. Этого достаточно для команды из 3-5 человек. Остальные секции добавляются по мере роста сложности.
Промпты работают с любой LLM. Качество зависит от входных данных, не от модели.
Полный гайд с промптами для всех 8 секций и готовым шаблоном: https://futurecraft.pro/ru/blog/ai-powered-prd/
Почему классические PRD не работают в маленьких командах
В командах из 3-10 человек три проблемы убивают документацию.
Непропорциональные затраты. Описание фичи, которая делается за неделю, требует 2-3 дня на документирование. Команда выбирает "просто начнём делать". Итог: scope creep, переделки, разное понимание у разработчиков и дизайнеров.
Неполное покрытие. Даже опытные продакт-менеджеры пропускают секции: edge cases, error states, rollback plan, success metrics с порогами. Удерживать 15 секций в голове при описании каждой фичи физически невозможно.
Устаревание. PRD написан в понедельник, к пятнице половина решений поменялась. Обновить 15-страничный документ дороже, чем написать новый.
Структура из 8 модульных секций
Порядок принципиален: Problem Statement и Target Users задают контекст для LLM, а все следующие промпты получают output предыдущих.
- Problem Statement - текущее состояние, pain points с метриками, целевое состояние, impact hypothesis. Ключевое: "23% churn из exit survey" даёт конкретный output. "Высокий churn" даёт generic текст.
- Target Users через JTBD — максимум 3 persona. Ограничение обязательно, иначе LLM генерирует 7-10 типов и размывает фокус.
- Solution Overview - что строим, какие capabilities закрывают какие pain points, happy path. Без технических деталей и UI.
- User Stories с Acceptance Criteria в формате Given/When/Then. Максимальная экономия времени. Отдельный акцент на negative criteria: "система НЕ должна обновлять данные чаще раза в 5 минут".
- Technical Constraints - совместно с техлидом. LLM структурирует по категориям: инфраструктура, данные, интеграции, перформанс, безопасность.
- Edge Cases - пропускают чаще всего. Промпт генерирует 20-40 кейсов по пяти категориям. Половина нерелевантна, но отфильтровать за 15-20 минут проще, чем генерировать с нуля за 2-3 часа.
- Success Metrics - primary, secondary, guardrail (которые НЕ должны ухудшиться), exit criteria с числовыми порогами.
- Out of Scope - что не делаем, почему, когда может вернуться. Плюс допущения и открытые вопросы.
Три принципа качественной генерации
Реальные данные. LLM отлично структурирует, но плохо изобретает метрики. Конкретные числа из аналитики на входе дают конкретный output.
Жёсткие лимиты в промптах. "Максимум 3 persona", "3-5 pain points", "5-8 шагов". Без этого фильтровать дольше, чем писать вручную.
Negative constraints. "Не включай технические детали", "Не упоминай UI-элементы". Модель следует явным запретам точнее, чем неявным ожиданиям.
Минимальный жизнеспособный PRD: три секции - Problem Statement, Solution Overview, User Stories с Acceptance Criteria. Этого достаточно для команды из 3-5 человек. Остальные секции добавляются по мере роста сложности.
Промпты работают с любой LLM. Качество зависит от входных данных, не от модели.
Полный гайд с промптами для всех 8 секций и готовым шаблоном: https://futurecraft.pro/ru/blog/ai-powered-prd/
Forwarded from JourneyBay
JourneyBay 2.0 уже доступен 🚀
Не косметическое обновление. Мы переписали AI-движок и превратили JourneyBay в AI-платформу для путешествий — ту, где AI редактирует поездку, а не просто отвечает на вопросы.
Что нового внутри:
• Поездка из одной фразы — короткий запрос превращается в дни, места, карту и первый маршрут
• AI-чат с 25 инструментами: ищет, проверяет, показывает места карточками, переносит активности
• Импорт броней из PDF и фото — авторазбор и добавление в нужный день
• Подготовка рядом с маршрутом: чек-листы, документы и визовый контекст из официальных источников
• Свой LLM-ключ (OpenAI · Claude · Gemini) или MCP-доступ для Claude Desktop и Codex
• Планирование по всем странам и гражданствам
• Места под настроение — рекомендации с учётом темпа и предпочтений
Главная идея: вся поездка — один живой маршрут.
Подробнее: https://journeybay.co/
Скачать
iOS
Android
RuStore
MCP docs
Не косметическое обновление. Мы переписали AI-движок и превратили JourneyBay в AI-платформу для путешествий — ту, где AI редактирует поездку, а не просто отвечает на вопросы.
Что нового внутри:
• Поездка из одной фразы — короткий запрос превращается в дни, места, карту и первый маршрут
• AI-чат с 25 инструментами: ищет, проверяет, показывает места карточками, переносит активности
• Импорт броней из PDF и фото — авторазбор и добавление в нужный день
• Подготовка рядом с маршрутом: чек-листы, документы и визовый контекст из официальных источников
• Свой LLM-ключ (OpenAI · Claude · Gemini) или MCP-доступ для Claude Desktop и Codex
• Планирование по всем странам и гражданствам
• Места под настроение — рекомендации с учётом темпа и предпочтений
Главная идея: вся поездка — один живой маршрут.
Подробнее: https://journeybay.co/
Скачать
iOS
Android
RuStore
MCP docs
70% стартапов получают отказ не из-за продукта, а из-за бизнес-модели. Business Model Canvas заполняют один раз и считают задачу закрытой. Инвестор читает его как карту рисков и за 10 минут находит дыры, на закрытие которых уйдёт полгода.
AI может найти эти дыры до питча. Разберём, как проверить каждый из 9 блоков BMC.
Подготовка. BMC нужно заполнить текстом, а не набором ключевых слов. "B2B SaaS для HR" не даёт AI контекста. "Платформа автоматизации рекрутинга для IT-компаний 50-500 сотрудников, средний чек $200/мес, основной канал: контент-маркетинг" даёт. Для каждого блока хватит 2-3 предложений с указанием стадии, рынка и текущих метрик.
Что проверять в каждом блоке.
Customer Segments: сегмент конкретный (можно составить список из 100 компаний?), TAM/SAM/SOM обоснован, есть приоритизация. Типичная ошибка: "все малые бизнесы". Вопрос инвестора: почему магазин одежды на Shopify и дистрибьютор электроники на собственной платформе в одном сегменте? Рекомендация: сузить до "DTC бренды на Shopify с GMV $100K-$1M/год".
Value Propositions: связь с измеримой болью клиента, 10x improvement test, ответ на "почему сейчас". Типичная ошибка: описание технологии вместо выгоды. "Экономим время" vs. "сокращаем наём с 45 до 12 дней". Второе можно проверить, первое нет.
Channels: CAC по каждому каналу, масштабируемость при 10x росте бюджета, channel-market fit. Типичная ошибка: enterprise-продукт с привлечением через TikTok. Другая частая проблема: зависимость от одного канала. Что будет, если он закроется?
Customer Relationships: модель обслуживания совпадает с чеком, есть retention-стратегия. Типичная ошибка: high-touch onboarding при $20/мес не масштабируется. Ещё хуже: план привлечения есть, плана удержания нет.
Revenue Streams: подтверждённая готовность платить, expansion revenue, pricing привязан к value metric. Типичная ошибка: цена за "место", когда ценность в объёме обработанных данных. Net Revenue Retention ниже 100% при отсутствии upsell/cross-sell.
Key Resources: single points of failure (один разработчик знает всю кодовую базу), реальный moat (не "AI-алгоритм" без патента или уникальных данных), founder-market fit. Нет плана найма при 5x росте? Это красный флаг.
Key Activities: приоритизация (если 15 "ключевых" активностей, ничего не ключевое), метрики эффективности. Смешивание execution и strategy в одном списке говорит о том, что приоритеты не расставлены.
Key Partnerships: формализация (устная договорённость это не партнёрство), взаимная ценность, конкурентный риск. Что получает партнёр? Может ли он стать конкурентом? Работает ли партнёрство при 10x росте?
Cost Structure: fixed/variable split, скрытые расходы (compliance, legal, tech debt), burn rate trajectory. Типичная ошибка: занижение расходов на найм и инфраструктуру.
Мета-анализ: самое важное. Проблемы отдельных блоков найти легко. Опаснее несоответствия между блоками. Premium-сегмент с low-touch каналами и низким чеком. Enterprise-продукт с командой из 2 человек без планов найма sales. Ключевая активность "AI R&D" при нуле ML-инженеров в ресурсах.
Как приоритизировать результаты. AI находит 15-25 проблем в любом BMC. Это нормально. Разделите на три группы. Критические (исправить до питча): несоответствия, которые ломают модель, например CAC выше LTV. Важные (подготовить ответ): инвестор спросит, нужен план. Низкий приоритет (принять как факт стадии): отсутствие патентов на pre-seed.
Порядок работы. Начните с Customer Segments и Value Propositions. Это фундамент. Если здесь проблемы, остальные блоки не имеют значения. После исправления отдельных блоков запустите мета-анализ связей. Исправили критическое? Запустите тест снова. Одной итерации недостаточно.
AI-стресс-тест не заменяет разговоры с клиентами и финансовое моделирование. Он закрывает слепые зоны, которые основатель не видит из-за близости к продукту.
Полный гайд с готовыми промптами для всех 9 блоков и мета-анализа — https://futurecraft.pro/ru/blog/business-model-canvas-ai/
AI может найти эти дыры до питча. Разберём, как проверить каждый из 9 блоков BMC.
Подготовка. BMC нужно заполнить текстом, а не набором ключевых слов. "B2B SaaS для HR" не даёт AI контекста. "Платформа автоматизации рекрутинга для IT-компаний 50-500 сотрудников, средний чек $200/мес, основной канал: контент-маркетинг" даёт. Для каждого блока хватит 2-3 предложений с указанием стадии, рынка и текущих метрик.
Что проверять в каждом блоке.
Customer Segments: сегмент конкретный (можно составить список из 100 компаний?), TAM/SAM/SOM обоснован, есть приоритизация. Типичная ошибка: "все малые бизнесы". Вопрос инвестора: почему магазин одежды на Shopify и дистрибьютор электроники на собственной платформе в одном сегменте? Рекомендация: сузить до "DTC бренды на Shopify с GMV $100K-$1M/год".
Value Propositions: связь с измеримой болью клиента, 10x improvement test, ответ на "почему сейчас". Типичная ошибка: описание технологии вместо выгоды. "Экономим время" vs. "сокращаем наём с 45 до 12 дней". Второе можно проверить, первое нет.
Channels: CAC по каждому каналу, масштабируемость при 10x росте бюджета, channel-market fit. Типичная ошибка: enterprise-продукт с привлечением через TikTok. Другая частая проблема: зависимость от одного канала. Что будет, если он закроется?
Customer Relationships: модель обслуживания совпадает с чеком, есть retention-стратегия. Типичная ошибка: high-touch onboarding при $20/мес не масштабируется. Ещё хуже: план привлечения есть, плана удержания нет.
Revenue Streams: подтверждённая готовность платить, expansion revenue, pricing привязан к value metric. Типичная ошибка: цена за "место", когда ценность в объёме обработанных данных. Net Revenue Retention ниже 100% при отсутствии upsell/cross-sell.
Key Resources: single points of failure (один разработчик знает всю кодовую базу), реальный moat (не "AI-алгоритм" без патента или уникальных данных), founder-market fit. Нет плана найма при 5x росте? Это красный флаг.
Key Activities: приоритизация (если 15 "ключевых" активностей, ничего не ключевое), метрики эффективности. Смешивание execution и strategy в одном списке говорит о том, что приоритеты не расставлены.
Key Partnerships: формализация (устная договорённость это не партнёрство), взаимная ценность, конкурентный риск. Что получает партнёр? Может ли он стать конкурентом? Работает ли партнёрство при 10x росте?
Cost Structure: fixed/variable split, скрытые расходы (compliance, legal, tech debt), burn rate trajectory. Типичная ошибка: занижение расходов на найм и инфраструктуру.
Мета-анализ: самое важное. Проблемы отдельных блоков найти легко. Опаснее несоответствия между блоками. Premium-сегмент с low-touch каналами и низким чеком. Enterprise-продукт с командой из 2 человек без планов найма sales. Ключевая активность "AI R&D" при нуле ML-инженеров в ресурсах.
Как приоритизировать результаты. AI находит 15-25 проблем в любом BMC. Это нормально. Разделите на три группы. Критические (исправить до питча): несоответствия, которые ломают модель, например CAC выше LTV. Важные (подготовить ответ): инвестор спросит, нужен план. Низкий приоритет (принять как факт стадии): отсутствие патентов на pre-seed.
Порядок работы. Начните с Customer Segments и Value Propositions. Это фундамент. Если здесь проблемы, остальные блоки не имеют значения. После исправления отдельных блоков запустите мета-анализ связей. Исправили критическое? Запустите тест снова. Одной итерации недостаточно.
AI-стресс-тест не заменяет разговоры с клиентами и финансовое моделирование. Он закрывает слепые зоны, которые основатель не видит из-за близости к продукту.
Полный гайд с готовыми промптами для всех 9 блоков и мета-анализа — https://futurecraft.pro/ru/blog/business-model-canvas-ai/
42% питч-деков инвесторы отклоняют из-за неубедительной оценки рынка. Не потому что рынок маленький. Потому что «TAM $50B» без источника и методологии выглядит как число из воздуха.
TAM, SAM и SOM решают одну задачу: перевести абстрактное «рынок большой» в конкретные цифры, которые инвестор может проверить.
TAM (Total Addressable Market) показывает максимальный потолок. Сколько денег тратится на решение проблемы продукта во всём мире или в выбранном регионе.
SAM (Serviceable Addressable Market) сужает TAM до реальности. Часть рынка, которую продукт может обслужить с учётом географии, языка, ценовой категории и каналов дистрибуции.
SOM (Serviceable Obtainable Market) отвечает на вопрос «сколько вы реально получите». Доля SAM, которую стартап способен захватить за 1-3 года с текущими ресурсами.
Два метода расчёта
Top-down берёт общий размер рынка из аналитических отчётов (Gartner, Statista, Grand View Research) и сужает фильтрами до целевого сегмента. Bottom-up считает от конкретных клиентов: количество целевых компаний, умноженное на средний годовой контракт.
Лучшая практика: считать обоими методами и показать сравнение. Если результаты расходятся менее чем в 3 раза, это сильный сигнал адекватности. Расхождение в 5 раз и больше означает ошибку в допущениях.
Пример на реальном кейсе
Продукт: SaaS для автоматизации email-маркетинга. Целевой клиент: e-commerce, 100-1000 сотрудников, США + Западная Европа.
• TAM top-down: $5.67B (рынок email-маркетинга $12.6B x 45% доля автоматизации)
• TAM bottom-up: $936M (78K компаний x $12K ACV)
• SAM: $334M (top-down) vs $936M (bottom-up)
• SOM Year 1: $4.8M = 400 клиентов x $12K ACV
SOM расписан через воронку: 5000 лидов x 8% конверсия = 400 клиентов. 5000 лидов = контент-маркетинг (2000) + paid acquisition (2000) + partnerships (1000). Каждый слой проверяем. 1.4% SAM в первый год вполне адекватно для конкурентного рынка.
Пять типичных ошибок
Первая: TAM = весь рынок. «Рынок CRM составляет $80B» это не TAM для инструмента управления контактами в малом бизнесе. Инвесторы видят подмену мгновенно.
Вторая: один источник данных. Gartner оценивает рынок в $15B, Grand View Research в $22B, Mordor Intelligence в $11B. Три отчёта дают разброс в два раза. Один отчёт без объяснения выбора ослабляет позицию.
Третья: SOM без воронки. «Захватим 10% рынка за 3 года» без расчёта каналов привлечения, конверсий и unit economics. SOM строится снизу вверх: каналы, лиды, конверсия, клиенты, выручка.
Четвёртая: статичная модель. Рынок растёт или сжимается. Конкуренты появляются и уходят. Модель без CAGR и сценарного анализа устаревает за полгода. Три сценария (консервативный, базовый, оптимистичный) показывают чувствительность к допущениям.
Пятая: игнорирование конкурентов. Если топ-5 игроков занимают 70% SAM, получить 5% за первый год нереалистично. Модель должна учитывать конкурентный ландшафт.
Бенчмарки по стадиям
Для Pre-Seed: TAM $1-10B, SAM $100M-1B, SOM Year 1 $0.5-2M (0.1-0.5% SAM). Для Seed: TAM $5-50B, SAM $500M-5B, SOM $2-10M (0.2-1% SAM). Для Series A: TAM $10-100B, SAM $1-10B, SOM $10-50M (0.5-2% SAM).
Ключевые пропорции: SAM/TAM обычно 5-20%. Если SAM составляет 80% TAM, фильтры слишком широкие. SOM/SAM в первый год: 0.5-3%. Выше 5% за первый год неубедительно.
Как представлять инвестору
Один слайд. Оба метода расчёта рядом. Каждый множитель с объяснением. Не «SAM = $334M», а «SAM = $5.67B x 34% (mid-market) x 28% (e-commerce) x 62% (US+EU) = $334M». SOM привязан к операционному плану. Каждая внешняя цифра со ссылкой на источник в footnotes.
AI сокращает работу по оценке рынка с дней до часов. Промпты для расчёта TAM, bottom-up SAM, SOM через воронку и валидации допущений работают с Claude, GPT-4o и Gemini. Но каждое допущение проверяется вручную. AI помогает считать, не заменяет проверку.
Подробный гайд с формулами и промптами - на блоге: https://futurecraft.pro/ru/blog/tam-sam-som-calculator/
TAM, SAM и SOM решают одну задачу: перевести абстрактное «рынок большой» в конкретные цифры, которые инвестор может проверить.
TAM (Total Addressable Market) показывает максимальный потолок. Сколько денег тратится на решение проблемы продукта во всём мире или в выбранном регионе.
SAM (Serviceable Addressable Market) сужает TAM до реальности. Часть рынка, которую продукт может обслужить с учётом географии, языка, ценовой категории и каналов дистрибуции.
SOM (Serviceable Obtainable Market) отвечает на вопрос «сколько вы реально получите». Доля SAM, которую стартап способен захватить за 1-3 года с текущими ресурсами.
Два метода расчёта
Top-down берёт общий размер рынка из аналитических отчётов (Gartner, Statista, Grand View Research) и сужает фильтрами до целевого сегмента. Bottom-up считает от конкретных клиентов: количество целевых компаний, умноженное на средний годовой контракт.
Лучшая практика: считать обоими методами и показать сравнение. Если результаты расходятся менее чем в 3 раза, это сильный сигнал адекватности. Расхождение в 5 раз и больше означает ошибку в допущениях.
Пример на реальном кейсе
Продукт: SaaS для автоматизации email-маркетинга. Целевой клиент: e-commerce, 100-1000 сотрудников, США + Западная Европа.
• TAM top-down: $5.67B (рынок email-маркетинга $12.6B x 45% доля автоматизации)
• TAM bottom-up: $936M (78K компаний x $12K ACV)
• SAM: $334M (top-down) vs $936M (bottom-up)
• SOM Year 1: $4.8M = 400 клиентов x $12K ACV
SOM расписан через воронку: 5000 лидов x 8% конверсия = 400 клиентов. 5000 лидов = контент-маркетинг (2000) + paid acquisition (2000) + partnerships (1000). Каждый слой проверяем. 1.4% SAM в первый год вполне адекватно для конкурентного рынка.
Пять типичных ошибок
Первая: TAM = весь рынок. «Рынок CRM составляет $80B» это не TAM для инструмента управления контактами в малом бизнесе. Инвесторы видят подмену мгновенно.
Вторая: один источник данных. Gartner оценивает рынок в $15B, Grand View Research в $22B, Mordor Intelligence в $11B. Три отчёта дают разброс в два раза. Один отчёт без объяснения выбора ослабляет позицию.
Третья: SOM без воронки. «Захватим 10% рынка за 3 года» без расчёта каналов привлечения, конверсий и unit economics. SOM строится снизу вверх: каналы, лиды, конверсия, клиенты, выручка.
Четвёртая: статичная модель. Рынок растёт или сжимается. Конкуренты появляются и уходят. Модель без CAGR и сценарного анализа устаревает за полгода. Три сценария (консервативный, базовый, оптимистичный) показывают чувствительность к допущениям.
Пятая: игнорирование конкурентов. Если топ-5 игроков занимают 70% SAM, получить 5% за первый год нереалистично. Модель должна учитывать конкурентный ландшафт.
Бенчмарки по стадиям
Для Pre-Seed: TAM $1-10B, SAM $100M-1B, SOM Year 1 $0.5-2M (0.1-0.5% SAM). Для Seed: TAM $5-50B, SAM $500M-5B, SOM $2-10M (0.2-1% SAM). Для Series A: TAM $10-100B, SAM $1-10B, SOM $10-50M (0.5-2% SAM).
Ключевые пропорции: SAM/TAM обычно 5-20%. Если SAM составляет 80% TAM, фильтры слишком широкие. SOM/SAM в первый год: 0.5-3%. Выше 5% за первый год неубедительно.
Как представлять инвестору
Один слайд. Оба метода расчёта рядом. Каждый множитель с объяснением. Не «SAM = $334M», а «SAM = $5.67B x 34% (mid-market) x 28% (e-commerce) x 62% (US+EU) = $334M». SOM привязан к операционному плану. Каждая внешняя цифра со ссылкой на источник в footnotes.
AI сокращает работу по оценке рынка с дней до часов. Промпты для расчёта TAM, bottom-up SAM, SOM через воронку и валидации допущений работают с Claude, GPT-4o и Gemini. Но каждое допущение проверяется вручную. AI помогает считать, не заменяет проверку.
Подробный гайд с формулами и промптами - на блоге: https://futurecraft.pro/ru/blog/tam-sam-som-calculator/
💯2
Инвесторы задают одни и те же 20 вопросов на каждой встрече. Разница между "funded" и "passed" чаще определяется не продуктом, а глубиной и скоростью ответов.
Разобрал, как подготовить ответы на все 20 типовых вопросов инвестора с помощью Claude - с промптами, шаблонами и workflow.
Корень проблемы: фаундер и инвестор видят разное
Фаундер знает продукт. Инвестор оценивает бизнес. На вопрос "какой ваш CAC?" фаундер называет цифру из головы. Claude, получив реальные данные (расходы на маркетинг, конверсии, период атрибуции), считает CAC по каждому каналу. На выходе - не одна приблизительная цифра, а таблица с разбивкой, которую инвестор проверит прямо на встрече. Три причины, почему AI-ответы сильнее ручных:
Структура. Claude форматирует ответ по привычным инвестору frameworks: TAM-SAM-SOM, unit economics waterfall, cohort retention.
Полнота. На вопрос о конкурентах фаундер перечисляет 3-4 компании. Claude выдает матрицу: прямые, косвенные, потенциальные конкуренты плюс позиционирование. Вместо "мы отличаемся UX" появляется конкретика: "Competitor A обрабатывает запросы за 48 часов, мы за 12 минут."
Цифры вместо нарратива. "Мы растем быстро" превращается в "MoM revenue growth 18%, organic составляет 62% от total acquisition". Вторую инвестор записывает, первую забывает.
Четыре блока вопросов
Все 20 вопросов распределяются по четырем блокам. Каждый требует отдельного промпта с контекстом: попытка получить все 20 ответов одним запросом снижает качество каждого в 3-4 раза.
Блок 1 - рынок и возможность (вопросы 1-5): размер рынка, конкуренты, unfair advantage, why now, какую проблему решаете. Минимум $1B TAM для Series A. Промпт считает рынок bottom-up: количество клиентов на средний чек и частоту покупки.
Блок 2 - бизнес-модель и unit economics (вопросы 6-10): revenue model, юнит-экономика, каналы привлечения, ценообразование, burn rate. Здесь фаундеры проваливаются чаще всего - не потому что цифры плохие, а потому что не подготовили разбивку. Claude рассчитывает LTV, LTV/CAC ratio, payback period и sensitivity analysis: как метрики меняются при churn +2% и CAC +20%.
Блок 3 - traction и метрики роста (вопросы 11-15): traction slide, retention, ICP, cohort data, ключевые метрики. Промпт строит retention curve по месячным когортам и выделяет тренды.
Блок 4 - команда, стратегия, раунд (вопросы 16-20): почему именно эта команда, GTM strategy, use of funds, риски, конкретный ask. Инвестор хочет честный анализ рисков с планом mitigation по категориям: market, technology, execution, competitive, regulatory.
Workflow подготовки за 4-6 часов
Шаг 1: загрузить в Claude все данные - финансовые отчеты, метрики, customer interviews, competitive research. Чем больше данных, тем точнее.
Шаг 2: пройти все 20 вопросов с промптами, сохранить ответы в один документ. Время - 2-3 часа.
Шаг 3: stress-test. Попросить Claude сыграть скептичного партнера из top-tier VC и задать по два follow-up к каждому ответу - именно они вскрывают дыры, которые фаундер не видит.
Шаг 4: доработать слабые ответы. Обычно 3-4 прохода закрывают проблемы.
Шаг 5: сжать 20 ответов в one-page memo - он работает как follow-up.
Три ошибки, которые убивают подготовку
Нет реальных данных. Claude генерирует правдоподобные цифры - без реальных метрик ответы будут красивыми и пустыми. Каждую цифру нужно подтвердить источником.
Copy-paste без сокращения. Ответ Claude оптимизирован под полноту, а ответ на pitch-встрече - под 30-60 секунд. Каждый нужно сжать до формата "headline + proof point + one number."
Игнорирование слабых мест. Если Claude указывает, что moat слабый или unit economics не сходятся, это не баг в промпте, а сигнал менять стратегию.
Итого: 4-6 часов вместо 2-3 недель. 20 промптов покрывают 90% вопросов от pre-seed до Series A. Все промпты, шаблоны ответов и workflow целиком: https://futurecraft.pro/ru/blog/investor-questions-ai/
Разобрал, как подготовить ответы на все 20 типовых вопросов инвестора с помощью Claude - с промптами, шаблонами и workflow.
Корень проблемы: фаундер и инвестор видят разное
Фаундер знает продукт. Инвестор оценивает бизнес. На вопрос "какой ваш CAC?" фаундер называет цифру из головы. Claude, получив реальные данные (расходы на маркетинг, конверсии, период атрибуции), считает CAC по каждому каналу. На выходе - не одна приблизительная цифра, а таблица с разбивкой, которую инвестор проверит прямо на встрече. Три причины, почему AI-ответы сильнее ручных:
Структура. Claude форматирует ответ по привычным инвестору frameworks: TAM-SAM-SOM, unit economics waterfall, cohort retention.
Полнота. На вопрос о конкурентах фаундер перечисляет 3-4 компании. Claude выдает матрицу: прямые, косвенные, потенциальные конкуренты плюс позиционирование. Вместо "мы отличаемся UX" появляется конкретика: "Competitor A обрабатывает запросы за 48 часов, мы за 12 минут."
Цифры вместо нарратива. "Мы растем быстро" превращается в "MoM revenue growth 18%, organic составляет 62% от total acquisition". Вторую инвестор записывает, первую забывает.
Четыре блока вопросов
Все 20 вопросов распределяются по четырем блокам. Каждый требует отдельного промпта с контекстом: попытка получить все 20 ответов одним запросом снижает качество каждого в 3-4 раза.
Блок 1 - рынок и возможность (вопросы 1-5): размер рынка, конкуренты, unfair advantage, why now, какую проблему решаете. Минимум $1B TAM для Series A. Промпт считает рынок bottom-up: количество клиентов на средний чек и частоту покупки.
Блок 2 - бизнес-модель и unit economics (вопросы 6-10): revenue model, юнит-экономика, каналы привлечения, ценообразование, burn rate. Здесь фаундеры проваливаются чаще всего - не потому что цифры плохие, а потому что не подготовили разбивку. Claude рассчитывает LTV, LTV/CAC ratio, payback period и sensitivity analysis: как метрики меняются при churn +2% и CAC +20%.
Блок 3 - traction и метрики роста (вопросы 11-15): traction slide, retention, ICP, cohort data, ключевые метрики. Промпт строит retention curve по месячным когортам и выделяет тренды.
Блок 4 - команда, стратегия, раунд (вопросы 16-20): почему именно эта команда, GTM strategy, use of funds, риски, конкретный ask. Инвестор хочет честный анализ рисков с планом mitigation по категориям: market, technology, execution, competitive, regulatory.
Workflow подготовки за 4-6 часов
Шаг 1: загрузить в Claude все данные - финансовые отчеты, метрики, customer interviews, competitive research. Чем больше данных, тем точнее.
Шаг 2: пройти все 20 вопросов с промптами, сохранить ответы в один документ. Время - 2-3 часа.
Шаг 3: stress-test. Попросить Claude сыграть скептичного партнера из top-tier VC и задать по два follow-up к каждому ответу - именно они вскрывают дыры, которые фаундер не видит.
Шаг 4: доработать слабые ответы. Обычно 3-4 прохода закрывают проблемы.
Шаг 5: сжать 20 ответов в one-page memo - он работает как follow-up.
Три ошибки, которые убивают подготовку
Нет реальных данных. Claude генерирует правдоподобные цифры - без реальных метрик ответы будут красивыми и пустыми. Каждую цифру нужно подтвердить источником.
Copy-paste без сокращения. Ответ Claude оптимизирован под полноту, а ответ на pitch-встрече - под 30-60 секунд. Каждый нужно сжать до формата "headline + proof point + one number."
Игнорирование слабых мест. Если Claude указывает, что moat слабый или unit economics не сходятся, это не баг в промпте, а сигнал менять стратегию.
Итого: 4-6 часов вместо 2-3 недель. 20 промптов покрывают 90% вопросов от pre-seed до Series A. Все промпты, шаблоны ответов и workflow целиком: https://futurecraft.pro/ru/blog/investor-questions-ai/
👍2
Solo-фаундеры тратят в среднем 4-6 часов на одну SEO-статью. При темпе 8 статей в месяц это 32-48 часов чистого времени — половина рабочей недели уходит только на тексты. AI-pipeline сокращает это до 8-12 часов в месяц без потери качества по метрикам трафика.
Собрал production-ready pipeline от keyword research до публикации. Каждый этап — промпт, инструмент и метрика контроля качества.
Архитектура pipeline: 6 этапов
Шесть последовательных этапов, пропуск любого снижает итог:
Keyword Research (2 часа в месяц) - Content Brief (1.5 часа) - Draft Generation (2 часа) - SEO-оптимизация (1.5 часа) - Human Review (2 часа) - Публикация и дистрибуция (1 час).
Суммарно 10 часов на 8 статей против 40+ часов ручного производства. Разница в 4 раза.
Главный принцип: AI генерирует черновик, человек принимает решения. Обратная схема работает хуже — правки черновика занимают больше времени, чем валидация готового текста.
Этап 1: Keyword Research с AI-кластеризацией
AI автоматизирует три из четырех шагов: данные по volume и KD берутся из SEO-инструментов, кластеризацию и приоритизацию делает Claude.
Промпт группирует ключевые слова в кластеры (один кластер = одна статья), определяет primary keyword с максимальным volume при KD ниже 40, назначает search intent и формат. Сортировка: (volume / KD) * intent_weight, где informational = 1, commercial = 1.5, transactional = 2.
Метрика качества: суммарный monthly search volume кластера выше 500. Ниже порога производство не оправдано.
Этап 2: Content Brief
Brief определяет структуру статьи до написания. Без него AI генерирует generic-контент, неотличимый от выдачи.
Brief включает уникальный angle (не "полное руководство", а конкретное отличие от топ-10), outline с H2/H3, обязательные данные по секциям и места для internal links. Перед генерацией полезно скормить AI top-3 статьи из выдачи для анализа content gaps.
Этап 3: секционная генерация черновика
Частая ошибка: скормить brief целиком и попросить "напиши статью" — результат поверхностный. Правильно - генерация по секциям: каждый H2-блок отдельным промптом с контекстом предыдущих.
Это дает на 30-40% более глубокий контент при том же объеме: модель удерживает фокус на одной теме, плотность keywords контролируется по секциям, а при неудаче переделывается одна секция, а не весь текст.
Этап 4: SEO-оптимизация
Техническая оптимизация: title tag до 60 символов с keyword в начале, meta description до 155 символов, URL slug из 3-5 слов, keyword density 3-5 на 1000 слов, H2 под keyword-вариации, alt-тексты для изображений.
Внутренняя перелинковка - отдельная задача: AI находит связи между статьями, минимум 3 internal links на статью.
Этап 5: Human Review
AI не заменяет редактора. AI генерирует 80% контента, последние 20% определяют разницу между средней и сильной статьей.
Чеклист: факт-чекинг каждого числового утверждения, удаление AI-маркеров ("важно отметить", "давайте рассмотрим"), добавление tone of voice через примеры из практики и нестандартные мнения.
Целевое время ревью: 15-20 минут на статью. Больше 30 - проблема в качестве brief или промптов.
Стоимость и инструменты
Полный стек: Claude Pro ($20), Ahrefs Lite ($99-129), Surfer SEO ($69), Grammarly ($12). Итого $200-230 в месяц против $2000-4000 за SEO-копирайтера на тот же объем.
Минимальный стек для старта: Claude/GPT ($20) + Google Search Console (бесплатно), $2.50 за статью.
Масштабирование до 20 статей
Pipeline масштабируется до 15-20 статей без роста времени на ревью. Три условия: шаблонизация промптов (четыре шаблона — tutorial, listicle, comparison, case study — покрывают 90% задач), batch processing (keyword research и briefs в один сеанс, черновики пакетами по 3-4), quality gates между этапами (density checker, readability score, duplicate content scanner).
При 20 статьях стоимость одной падает до $1.50-2.00.
8 SEO-статей в месяц, $200-230, 10-12 часов работы. Полный pipeline с промптами для каждого этапа: https://futurecraft.pro/ru/blog/ai-content-engine/
Собрал production-ready pipeline от keyword research до публикации. Каждый этап — промпт, инструмент и метрика контроля качества.
Архитектура pipeline: 6 этапов
Шесть последовательных этапов, пропуск любого снижает итог:
Keyword Research (2 часа в месяц) - Content Brief (1.5 часа) - Draft Generation (2 часа) - SEO-оптимизация (1.5 часа) - Human Review (2 часа) - Публикация и дистрибуция (1 час).
Суммарно 10 часов на 8 статей против 40+ часов ручного производства. Разница в 4 раза.
Главный принцип: AI генерирует черновик, человек принимает решения. Обратная схема работает хуже — правки черновика занимают больше времени, чем валидация готового текста.
Этап 1: Keyword Research с AI-кластеризацией
AI автоматизирует три из четырех шагов: данные по volume и KD берутся из SEO-инструментов, кластеризацию и приоритизацию делает Claude.
Промпт группирует ключевые слова в кластеры (один кластер = одна статья), определяет primary keyword с максимальным volume при KD ниже 40, назначает search intent и формат. Сортировка: (volume / KD) * intent_weight, где informational = 1, commercial = 1.5, transactional = 2.
Метрика качества: суммарный monthly search volume кластера выше 500. Ниже порога производство не оправдано.
Этап 2: Content Brief
Brief определяет структуру статьи до написания. Без него AI генерирует generic-контент, неотличимый от выдачи.
Brief включает уникальный angle (не "полное руководство", а конкретное отличие от топ-10), outline с H2/H3, обязательные данные по секциям и места для internal links. Перед генерацией полезно скормить AI top-3 статьи из выдачи для анализа content gaps.
Этап 3: секционная генерация черновика
Частая ошибка: скормить brief целиком и попросить "напиши статью" — результат поверхностный. Правильно - генерация по секциям: каждый H2-блок отдельным промптом с контекстом предыдущих.
Это дает на 30-40% более глубокий контент при том же объеме: модель удерживает фокус на одной теме, плотность keywords контролируется по секциям, а при неудаче переделывается одна секция, а не весь текст.
Этап 4: SEO-оптимизация
Техническая оптимизация: title tag до 60 символов с keyword в начале, meta description до 155 символов, URL slug из 3-5 слов, keyword density 3-5 на 1000 слов, H2 под keyword-вариации, alt-тексты для изображений.
Внутренняя перелинковка - отдельная задача: AI находит связи между статьями, минимум 3 internal links на статью.
Этап 5: Human Review
AI не заменяет редактора. AI генерирует 80% контента, последние 20% определяют разницу между средней и сильной статьей.
Чеклист: факт-чекинг каждого числового утверждения, удаление AI-маркеров ("важно отметить", "давайте рассмотрим"), добавление tone of voice через примеры из практики и нестандартные мнения.
Целевое время ревью: 15-20 минут на статью. Больше 30 - проблема в качестве brief или промптов.
Стоимость и инструменты
Полный стек: Claude Pro ($20), Ahrefs Lite ($99-129), Surfer SEO ($69), Grammarly ($12). Итого $200-230 в месяц против $2000-4000 за SEO-копирайтера на тот же объем.
Минимальный стек для старта: Claude/GPT ($20) + Google Search Console (бесплатно), $2.50 за статью.
Масштабирование до 20 статей
Pipeline масштабируется до 15-20 статей без роста времени на ревью. Три условия: шаблонизация промптов (четыре шаблона — tutorial, listicle, comparison, case study — покрывают 90% задач), batch processing (keyword research и briefs в один сеанс, черновики пакетами по 3-4), quality gates между этапами (density checker, readability score, duplicate content scanner).
При 20 статьях стоимость одной падает до $1.50-2.00.
8 SEO-статей в месяц, $200-230, 10-12 часов работы. Полный pipeline с промптами для каждого этапа: https://futurecraft.pro/ru/blog/ai-content-engine/
🔥3
Большинство веб-приложений содержат хотя бы одну уязвимость из OWASP Top 10. Стандартный security-аудит занимает 2-3 недели и стоит от $10 000. LLM сокращает первичный аудит до нескольких часов: сканирует код на паттерны, а не ищет конкретные CVE.
Собрал 15 уязвимостей из аудита production-кода с помощью Claude.
Методология: три прохода
Первый — широкий скан: LLM получает весь проект и ищет паттерны уязвимостей. Второй — глубокий анализ: каждый паттерн проверяется в контексте (middleware, ORM, фреймворк). Третий — верификация: ручная проверка находок, LLM дает false positives.
Промпт задает структуру ответа и приоритет категорий — иначе LLM смешивает критические уязвимости с мелкими замечаниями.
Injection (A03) - три типа
SQL Injection через конкатенацию строк. Самая частая находка, встречается даже в проектах с ORM. Исправление: параметризованный запрос для значений, whitelist для идентификаторов.
NoSQL Injection в MongoDB. Передача req.body напрямую в запрос позволяет через оператор $ne обойти проверку пароля. Исправление: приведение к строке через String() и сравнение паролей через bcrypt.compare.
Command Injection через child_process. Пользовательский ввод в shell-команде позволяет выполнить произвольный код. Исправление: execFile вместо exec плюс regex-валидация ввода.
Broken Access Control (A01)
IDOR — небезопасная прямая ссылка на объект. Любой авторизованный пользователь видит чужой заказ через перебор ID. Исправление: добавить AND user_id = $2 в запрос.
Path Traversal при отдаче файлов. Запрос /api/files/../../etc/passwd дает доступ к системным файлам. Исправление: secure_filename, send_from_directory для ограничения директории, abspath-проверка.
Mass Assignment — перезапись полей через API. Пользователь отправляет в теле {"role": "admin"} и повышает себе роль. Исправление: деструктуризация выбирает только разрешенные поля.
Cryptographic Failures (A02)
JWT без проверки алгоритма. Атакующий создает токен с alg: "none" или alg: "HS256", подписывая публичным ключом сервера. Исправление: явно задать algorithms: ['RS256'], добавить issuer/audience.
Хранение секретов в коде. API-ключи, пароли, connection strings прямо в исходниках. Исправление: переменные окружения с валидацией при старте, которая падает при отсутствии переменной.
Security Misconfiguration и Insecure Design (A05, A04)
CORS с origin: '*' и credentials: true позволяет любому сайту делать запросы от имени авторизованного пользователя. Исправление: whitelist разрешенных origin.
Verbose Error Messages. Stack trace утекает клиенту, раскрывая структуру БД и пути файлов. Исправление: errorId вместо деталей, детали — в логах.
SSRF — сервер делает запрос по URL от пользователя, открывая доступ к AWS metadata API. Исправление: DNS-резолвинг проверяет, что IP не из приватной сети, плюс блокировка редиректов и таймаут.
Race Condition при платежах. Два одновременных запроса на вывод читают один баланс, оба проходят проверку, баланс уходит в минус. Исправление: транзакция с SELECT FOR UPDATE блокирует строку на время операции.
Authentication Failures и Integrity (A07, A08)
Timing Attack при сравнении токенов. Оператор === завершается на первом несовпадающем байте — timing-атака. Исправление: crypto.timingSafeEqual сравнивает все байты за одинаковое время.
Отсутствие rate limiting на аутентификации. Бесконечный перебор паролей. Исправление: rate limit по email (не только по IP) плюс account lockout.
Prototype Pollution через слияние объектов. Тело запроса {"__proto__": {"isAdmin": true}} заражает все объекты приложения. Исправление: блокировка ключей proto, constructor, prototype.
Автоматизация в CI
Минимальный pipeline: Semgrep для OWASP Top 10, npm audit для зависимостей, Gitleaks для секретов. LLM-аудит запускается отдельно на pre-merge review.
Полный чеклист из 15 пунктов, каждый с конкретной уязвимостью и вектором атаки: https://futurecraft.pro/ru/blog/ai-security-audit/
Собрал 15 уязвимостей из аудита production-кода с помощью Claude.
Методология: три прохода
Первый — широкий скан: LLM получает весь проект и ищет паттерны уязвимостей. Второй — глубокий анализ: каждый паттерн проверяется в контексте (middleware, ORM, фреймворк). Третий — верификация: ручная проверка находок, LLM дает false positives.
Промпт задает структуру ответа и приоритет категорий — иначе LLM смешивает критические уязвимости с мелкими замечаниями.
Injection (A03) - три типа
SQL Injection через конкатенацию строк. Самая частая находка, встречается даже в проектах с ORM. Исправление: параметризованный запрос для значений, whitelist для идентификаторов.
NoSQL Injection в MongoDB. Передача req.body напрямую в запрос позволяет через оператор $ne обойти проверку пароля. Исправление: приведение к строке через String() и сравнение паролей через bcrypt.compare.
Command Injection через child_process. Пользовательский ввод в shell-команде позволяет выполнить произвольный код. Исправление: execFile вместо exec плюс regex-валидация ввода.
Broken Access Control (A01)
IDOR — небезопасная прямая ссылка на объект. Любой авторизованный пользователь видит чужой заказ через перебор ID. Исправление: добавить AND user_id = $2 в запрос.
Path Traversal при отдаче файлов. Запрос /api/files/../../etc/passwd дает доступ к системным файлам. Исправление: secure_filename, send_from_directory для ограничения директории, abspath-проверка.
Mass Assignment — перезапись полей через API. Пользователь отправляет в теле {"role": "admin"} и повышает себе роль. Исправление: деструктуризация выбирает только разрешенные поля.
Cryptographic Failures (A02)
JWT без проверки алгоритма. Атакующий создает токен с alg: "none" или alg: "HS256", подписывая публичным ключом сервера. Исправление: явно задать algorithms: ['RS256'], добавить issuer/audience.
Хранение секретов в коде. API-ключи, пароли, connection strings прямо в исходниках. Исправление: переменные окружения с валидацией при старте, которая падает при отсутствии переменной.
Security Misconfiguration и Insecure Design (A05, A04)
CORS с origin: '*' и credentials: true позволяет любому сайту делать запросы от имени авторизованного пользователя. Исправление: whitelist разрешенных origin.
Verbose Error Messages. Stack trace утекает клиенту, раскрывая структуру БД и пути файлов. Исправление: errorId вместо деталей, детали — в логах.
SSRF — сервер делает запрос по URL от пользователя, открывая доступ к AWS metadata API. Исправление: DNS-резолвинг проверяет, что IP не из приватной сети, плюс блокировка редиректов и таймаут.
Race Condition при платежах. Два одновременных запроса на вывод читают один баланс, оба проходят проверку, баланс уходит в минус. Исправление: транзакция с SELECT FOR UPDATE блокирует строку на время операции.
Authentication Failures и Integrity (A07, A08)
Timing Attack при сравнении токенов. Оператор === завершается на первом несовпадающем байте — timing-атака. Исправление: crypto.timingSafeEqual сравнивает все байты за одинаковое время.
Отсутствие rate limiting на аутентификации. Бесконечный перебор паролей. Исправление: rate limit по email (не только по IP) плюс account lockout.
Prototype Pollution через слияние объектов. Тело запроса {"__proto__": {"isAdmin": true}} заражает все объекты приложения. Исправление: блокировка ключей proto, constructor, prototype.
Автоматизация в CI
Минимальный pipeline: Semgrep для OWASP Top 10, npm audit для зависимостей, Gitleaks для секретов. LLM-аудит запускается отдельно на pre-merge review.
Полный чеклист из 15 пунктов, каждый с конкретной уязвимостью и вектором атаки: https://futurecraft.pro/ru/blog/ai-security-audit/
💯2
Forwarded from JourneyBay
JourneyBay теперь работает внутри ChatGPT 🚀 -> 💬
Планирование поездки больше не требует десятка вкладок. Опишите поездку словами прямо в ChatGPT - и JourneyBay соберёт всё в диалоге:
• «Создай поездку в Барселону на 4 дня»
• «Собери маршрут по дням»
• «Найди места с рамэном в Токио»
• «Покажи мои поездки»
• «Какой у меня на завтра маршрут?»
И многое другое.
В ответ открываются интерактивные карты, расписания дня и карточки мест - прямо в чате.
Как подключить: найдите «JourneyBay» в каталоге приложений ChatGPT.
Ссылка на App в ChatGPT💬
Напоминаем также, что JourneyBay можно подключить и в других агентов через MCP-сервер.
Планирование поездки больше не требует десятка вкладок. Опишите поездку словами прямо в ChatGPT - и JourneyBay соберёт всё в диалоге:
• «Создай поездку в Барселону на 4 дня»
• «Собери маршрут по дням»
• «Найди места с рамэном в Токио»
• «Покажи мои поездки»
• «Какой у меня на завтра маршрут?»
И многое другое.
В ответ открываются интерактивные карты, расписания дня и карточки мест - прямо в чате.
Как подключить: найдите «JourneyBay» в каталоге приложений ChatGPT.
Ссылка на App в ChatGPT
Напоминаем также, что JourneyBay можно подключить и в других агентов через MCP-сервер.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Команды принимают десятки архитектурных решений в месяц, а документируют единицы. Через полгода новый разработчик спрашивает: "Почему здесь Redis, а не PostgreSQL?"
Никто не помнит — два часа раскопок по Git и Slack ради решения, которое исходно заняло 15 минут.
Architecture Decision Records решают эту проблему. Один документ, одно решение, семь секций. Концепцию предложил Michael Nygard в 2011 году, но в большинстве команд ADR не пишут — оформление занимает 30-40 минут, а разработчик уже на следующей задаче. AI сжимает это до 3-5 минут.
Семь секций: Status, Date, Context, Decision, Consequences, Alternatives Considered, References.
Context — самая важная. "Выбрали Redis для кэширования" — ноль информации. "Выбрали Redis, потому что PostgreSQL LISTEN/NOTIFY не давал sub-millisecond latency при 10K RPS" — полная картина для будущего читателя.
Alternatives Considered — секция, которую чаще всего пропускают и которая приносит больше всего пользы. Через год кто-то спросит "а почему не Kafka?" — ответ уже записан.
Базовый промпт: три входа (решение, контекст проекта, формат с семью секциями) плюс жёсткие правила — активный залог, конкретные метрики вместо "быстрее/лучше", каждый пункт Consequences верифицируем. Без этих ограничений модель генерирует воду. Закрывает 80% случаев.
Специализированные варианты для остальных 20%: миграции добавляют Migration Strategy, Rollback Plan и Success Criteria; выбор технологии — таблицу Evaluation Criteria с весами и Proof of Concept; отказ от решения — What Changed и Lessons Learned.
Ретроспективная генерация. Для команд без единого ADR: скормить AI diff и комментарии PR, попросить найти архитектурное решение по критериям (новая зависимость, изменение схемы БД, новый паттерн, изменение API). Закрывает решения, принятые месяцы назад и не записанные вовремя.
CI-автоматизация. GitHub Action детектит архитектурные изменения и выдаёт warning, если PR не содержит ADR-файла. Предупреждение, не блокировка — блокировка убивает adoption быстрее, чем отсутствие документации.
Компаунд-эффект. Ключевые ADR попадают в CLAUDE.md или .cursorrules — AI-агент использует event bus вместо REST, потому что ADR-005 зафиксировал event-driven архитектуру.
Частые ошибки: абстрактный Context вместо цифр, scope на 10 решений в одном файле, неактуальный Status после замены решения, отсутствие Alternatives.
Метрики: ADR coverage >70% PR, Time-to-ADR <24ч, Reference rate >2/мес.
Шаблон, промпты, CI-конфиг и пример на реальном проекте: https://futurecraft.pro/ru/blog/adr-template-ai/
Никто не помнит — два часа раскопок по Git и Slack ради решения, которое исходно заняло 15 минут.
Architecture Decision Records решают эту проблему. Один документ, одно решение, семь секций. Концепцию предложил Michael Nygard в 2011 году, но в большинстве команд ADR не пишут — оформление занимает 30-40 минут, а разработчик уже на следующей задаче. AI сжимает это до 3-5 минут.
Семь секций: Status, Date, Context, Decision, Consequences, Alternatives Considered, References.
Context — самая важная. "Выбрали Redis для кэширования" — ноль информации. "Выбрали Redis, потому что PostgreSQL LISTEN/NOTIFY не давал sub-millisecond latency при 10K RPS" — полная картина для будущего читателя.
Alternatives Considered — секция, которую чаще всего пропускают и которая приносит больше всего пользы. Через год кто-то спросит "а почему не Kafka?" — ответ уже записан.
Базовый промпт: три входа (решение, контекст проекта, формат с семью секциями) плюс жёсткие правила — активный залог, конкретные метрики вместо "быстрее/лучше", каждый пункт Consequences верифицируем. Без этих ограничений модель генерирует воду. Закрывает 80% случаев.
Специализированные варианты для остальных 20%: миграции добавляют Migration Strategy, Rollback Plan и Success Criteria; выбор технологии — таблицу Evaluation Criteria с весами и Proof of Concept; отказ от решения — What Changed и Lessons Learned.
Ретроспективная генерация. Для команд без единого ADR: скормить AI diff и комментарии PR, попросить найти архитектурное решение по критериям (новая зависимость, изменение схемы БД, новый паттерн, изменение API). Закрывает решения, принятые месяцы назад и не записанные вовремя.
CI-автоматизация. GitHub Action детектит архитектурные изменения и выдаёт warning, если PR не содержит ADR-файла. Предупреждение, не блокировка — блокировка убивает adoption быстрее, чем отсутствие документации.
Компаунд-эффект. Ключевые ADR попадают в CLAUDE.md или .cursorrules — AI-агент использует event bus вместо REST, потому что ADR-005 зафиксировал event-driven архитектуру.
Частые ошибки: абстрактный Context вместо цифр, scope на 10 решений в одном файле, неактуальный Status после замены решения, отсутствие Alternatives.
Метрики: ADR coverage >70% PR, Time-to-ADR <24ч, Reference rate >2/мес.
Шаблон, промпты, CI-конфиг и пример на реальном проекте: https://futurecraft.pro/ru/blog/adr-template-ai/
🔥1
Большинство промптов в production никогда не проходят формальное сравнительное тестирование — только правки по интуиции и деплой. Через неделю всплывает деградация на edge cases. Это не инженерия, а угадывание.
Три системные ошибки ручной оценки
Малые выборки — на 5 запросах шанс пропустить 20% деградацию 33%. Confirmation bias — автор промпта неосознанно выбирает примеры, где новая версия выглядит лучше; лечится только слепой оценкой на случайной выборке. Отсутствие baseline — «кажется, стало точнее» не метрика, 0.82 → 0.87 по faithfulness на 200 примерах — метрика.
Как устроен prompt A/B тест
В отличие от продуктового A/B (там измеряют поведение пользователей), здесь — качество выходов модели. Датасет — минимум 100 примеров из production, отражающих реальное распределение запросов (язык, сложность). Execution — оба варианта на одном датасете с зафиксированными model ID, temperature, seed. Evaluation — детерминированные метрики (ROUGE-L, exact match, latency) плюс LLM-as-Judge (Faithfulness, G-Eval) для семантики.
Статистическая значимость
p-value < 0.05 не значит «промпт лучше» — нужен effect size (Cohen's d): < 0.2 разница незначительна, > 0.5 существенна. Считать paired test (Wilcoxon или paired t-test), потому что оба промпта оценены на одних inputs. При нескольких метриках нужна поправка Бонферрони — иначе на пяти тестах вероятность ложного срабатывания вырастает до 23%.
Паттерны и антипаттерны
Одна переменная за тест. Сегментированный анализ по метаданным вскрывает то, что прячет общий score. Cost per quality point — промпт на 3% лучше, но на 40% дороже, не всегда стоит деплоя. Антипаттерны: тест на few-shot из того же датасета, игнорирование дисперсии, преждевременная остановка на первых 50 примерах.
Стек: Langfuse (версионирование промптов, датасеты, tracing) + DeepEval (14+ метрик), оба open-source, подключаются в CI/CD — pipeline падает, если candidate хуже baseline.
Полный pipeline с Python-кодом, статистическими функциями и GitHub Actions: https://futurecraft.pro/ru/blog/prompt-ab-testing/
Три системные ошибки ручной оценки
Малые выборки — на 5 запросах шанс пропустить 20% деградацию 33%. Confirmation bias — автор промпта неосознанно выбирает примеры, где новая версия выглядит лучше; лечится только слепой оценкой на случайной выборке. Отсутствие baseline — «кажется, стало точнее» не метрика, 0.82 → 0.87 по faithfulness на 200 примерах — метрика.
Как устроен prompt A/B тест
В отличие от продуктового A/B (там измеряют поведение пользователей), здесь — качество выходов модели. Датасет — минимум 100 примеров из production, отражающих реальное распределение запросов (язык, сложность). Execution — оба варианта на одном датасете с зафиксированными model ID, temperature, seed. Evaluation — детерминированные метрики (ROUGE-L, exact match, latency) плюс LLM-as-Judge (Faithfulness, G-Eval) для семантики.
Статистическая значимость
p-value < 0.05 не значит «промпт лучше» — нужен effect size (Cohen's d): < 0.2 разница незначительна, > 0.5 существенна. Считать paired test (Wilcoxon или paired t-test), потому что оба промпта оценены на одних inputs. При нескольких метриках нужна поправка Бонферрони — иначе на пяти тестах вероятность ложного срабатывания вырастает до 23%.
Паттерны и антипаттерны
Одна переменная за тест. Сегментированный анализ по метаданным вскрывает то, что прячет общий score. Cost per quality point — промпт на 3% лучше, но на 40% дороже, не всегда стоит деплоя. Антипаттерны: тест на few-shot из того же датасета, игнорирование дисперсии, преждевременная остановка на первых 50 примерах.
Стек: Langfuse (версионирование промптов, датасеты, tracing) + DeepEval (14+ метрик), оба open-source, подключаются в CI/CD — pipeline падает, если candidate хуже baseline.
Полный pipeline с Python-кодом, статистическими функциями и GitHub Actions: https://futurecraft.pro/ru/blog/prompt-ab-testing/
Полностью автономная AI-система в production допускает критические ошибки. Human-in-the-loop снижает их число в разы, но добавляет latency и стоимость. Вопрос не «нужен ли человек», а где его поставить, чтобы ловить опасные решения и не превратить систему в дорогой интерфейс для ручной работы.
Три фактора определяют границу автономности
Цена ошибки — чат-бот с неверным рейтингом ресторана не страшен, кредит на $50 000 по галлюцинации модели — судебный иск. Обратимость — push-уведомление не вернуть, черновик email можно поправить. Уверенность модели — даже confidence 0.95 это одна ошибка на двадцать решений; порог зависит от задачи: 0.7 для тикетов, 0.95+ для медицинской триажной, 0.99 для финансовых решений.
Confidence threshold и risk matrix
Порог калибруется на реальных данных: 500-1000 решений с confidence размечаются как правильные/неправильные, строится кривая error rate vs. escalation rate. При пороге 0.60 — 88% автономности и 8.2% ошибок; при 0.92 — 42% автономности и 0.3% ошибок. Для большинства B2B 0.85 (59% автономных, 1.4% ошибок) — рабочий баланс.
Confidence — одна ось. Risk matrix добавляет вторую: тип и последствия решения. Четыре зоны: AUTO (низкий риск, высокая уверенность — сразу), AUTO+AUDIT (высокий риск, высокая уверенность — автономно, но 10-20% проверяется постфактум), QUEUE (низкий риск, низкая уверенность — в очередь), ESCALATE (высокий риск, низкая уверенность — немедленно к человеку).
Пять паттернов для production
Pre-action Gate — модель предлагает, человек подтверждает необратимое действие. Post-action Audit — модель действует, выборка проверяется постфактум (20-30% на старте, 5-10% после стабилизации). Confidence-based Routing — три зоны вместо двух. Cascading Validation — автоправила ($0) → LLM-as-Judge ($0.002-0.01) → человек ($0.50-2.00 на 5-10% объёма). Feedback Loop — ревьюер указывает причину и правильный ответ, каждый месяц — рекалибровка порогов.
Главная ловушка
GPT-4 выдаёт confidence 0.95 на фактически неправильных ответах — logprobs отражают уверенность в токене, а не правильность ответа. Внешняя калибровка на реальных данных обязательна, доверять self-reported confidence нельзя.
Подробный гайд с кодом калибровки, risk assessment функциями и реализацией Pre-action Gate: https://futurecraft.pro/ru/blog/human-in-the-loop/
Три фактора определяют границу автономности
Цена ошибки — чат-бот с неверным рейтингом ресторана не страшен, кредит на $50 000 по галлюцинации модели — судебный иск. Обратимость — push-уведомление не вернуть, черновик email можно поправить. Уверенность модели — даже confidence 0.95 это одна ошибка на двадцать решений; порог зависит от задачи: 0.7 для тикетов, 0.95+ для медицинской триажной, 0.99 для финансовых решений.
Confidence threshold и risk matrix
Порог калибруется на реальных данных: 500-1000 решений с confidence размечаются как правильные/неправильные, строится кривая error rate vs. escalation rate. При пороге 0.60 — 88% автономности и 8.2% ошибок; при 0.92 — 42% автономности и 0.3% ошибок. Для большинства B2B 0.85 (59% автономных, 1.4% ошибок) — рабочий баланс.
Confidence — одна ось. Risk matrix добавляет вторую: тип и последствия решения. Четыре зоны: AUTO (низкий риск, высокая уверенность — сразу), AUTO+AUDIT (высокий риск, высокая уверенность — автономно, но 10-20% проверяется постфактум), QUEUE (низкий риск, низкая уверенность — в очередь), ESCALATE (высокий риск, низкая уверенность — немедленно к человеку).
Пять паттернов для production
Pre-action Gate — модель предлагает, человек подтверждает необратимое действие. Post-action Audit — модель действует, выборка проверяется постфактум (20-30% на старте, 5-10% после стабилизации). Confidence-based Routing — три зоны вместо двух. Cascading Validation — автоправила ($0) → LLM-as-Judge ($0.002-0.01) → человек ($0.50-2.00 на 5-10% объёма). Feedback Loop — ревьюер указывает причину и правильный ответ, каждый месяц — рекалибровка порогов.
Главная ловушка
GPT-4 выдаёт confidence 0.95 на фактически неправильных ответах — logprobs отражают уверенность в токене, а не правильность ответа. Внешняя калибровка на реальных данных обязательна, доверять self-reported confidence нельзя.
Подробный гайд с кодом калибровки, risk assessment функциями и реализацией Pre-action Gate: https://futurecraft.pro/ru/blog/human-in-the-loop/
💯2