Как сделать лид-магнит с ИИ по исходным материалам: выбрать одно первое действие клиента, отобрать подтверждённые правила, собрать одностраничную памятку с пустым шаблоном и заполненным обращением, дать модели копируемый промпт с запретом выдуманной цены и диагноза, затем вручную сверить каждое поле с исходным правилом. Ниже — рабочий порядок на учебном примере веломастерской.
Выбрать одно первое действие клиента
Лид-магнит работает как обмен: человек отдаёт контакт за полезный материал. В обзоре на nagent.ai это сформулировано прямо: лид-магнит — сделка, где покупатель отдаёт контактные данные за что-то полезное, а в B2B покупатель обычно эксперт в своей работе, поэтому «полезное» означает конкретное. Отсюда первое решение: у материала одно действие, которое читатель совершает сразу после прочтения.
Для веломастерской это действие — первое обращение перед визитом. Владелец велосипеда открывает памятку, понимает, что отправить, и пишет мастеру. Памятка полезна ровно настолько, насколько она сокращает путь до этого сообщения.
Проверка выбора: назовите действие одним глаголом. «Отправить мастеру тип велосипеда, описание поломки и фото» — годится. «Узнать больше о ремонте» — нет, это не действие, а намерение. Второй тест: если читатель закроет памятку и ничего не сделает, материал бесполезен, и это видно сразу.
DocsAura в своей инструкции предлагает перед открытием любого ИИ-инструмента записать фразу о том, что обычно спрашивают лучшие клиенты. Подставьте туда вопрос, который ведёт к выбранному действию. Для мастерской это звучит как «что отправить, чтобы записаться на осмотр». Такой черновик темы становится рамкой для всего остального.
Одно действие задаёт и объём. Памятка на одну страницу покрывает один шаг. Попытка уместить в неё весь ремонтный цикл размывает фокус и снижает шанс, что читатель дойдёт до конца.
Отобрать три подтверждённых правила обращения
Правила берутся из практики мастерской. В учебном примере их три: перед визитом назвать тип велосипеда, описать поломку, приложить фото. Четвёртое правило — мастерская подтверждает цену только после осмотра — работает как ограничение для текста.
Nagent.ai советует загружать в генератор продуктовые документы, исследования, кейсы и расшифровки, а письмо ограничивать ими. Тот же принцип применим к трём правилам: они становятся исходным материалом, за пределы которого модель не выходит.
Отбор идёт по двум признакам. Правило подтверждено: мастер действительно просит эти данные у каждого клиента. Правило влияет на первое действие: без него обращение неполное и мастер задаёт уточняющий вопрос.
| Правило | Что даёт читателю | Что проверяет мастер |
|---|---|---|
| Назвать тип велосипеда | Понятный контекст обращения | Подходит ли мастерская под этот класс |
| Описать поломку | Формулировка проблемы своими словами | Стоит ли осмотр |
| Приложить фото | Снимок общего вида и детали | Видна ли зона ремонта |
| Цена после осмотра | Честное ожидание | Стоимость подтверждается на месте |
Четвёртая строка таблицы задаёт ограничение. Она снимает у читателя ожидание мгновенной цены и защищает мастерскую от спора о цифре, названной по фотографии.
Honiq в своём разборе предлагает относиться к ИИ как к управляемому слою обработки: сначала определить профессиональные правила, расчёты, оценку и ограничения, и только потом писать промпт. Три правила и ограничение по цене — ровно такой слой. Модель получает готовую рамку и работает внутри неё.
Собрать памятку, шаблон и заполненное обращение
Готовая учебная памятка «Что отправить мастеру»:
- Назовите тип велосипеда.
- Опишите, что произошло и когда.
- Приложите фото общего вида и нужной детали.
- Спросите о возможности осмотра.
По фото стоимость не подтверждается.
Пустой шаблон обращения:
Тип велосипеда: [заполните]
Что произошло и когда: [заполните]
Фото общего вида и детали: [приложите]
Когда возможен осмотр?
Заполненный учебный пример: «Городской велосипед, цепь слетает со вторника; приложил два фото. Когда возможен осмотр?» Стоимость подтверждается после осмотра.
Nagent.ai отдельно называет формат выдачи: DOCX или похожий, чтобы следующую редакцию можно было подготовить правкой исходного файла. Это практическое требование к хранению исходника. Держите текст памятки в редактируемом файле, а PDF собирайте из него при каждой публикации.
Промпт для сборки трёх частей выглядит так:
Ты собираешь одностраничную памятку для клиента веломастерской.
Исходные правила, за пределы которых выходить нельзя:
1. Перед визитом клиент называет тип велосипеда.
2. Клиент описывает, что произошло и когда.
3. Клиент прилагает фото общего вида и детали.
4. Мастерская подтверждает цену только после осмотра.
Сделай три блока:
- памятка «Что отправить мастеру» из четырёх пунктов;
- пустой шаблон обращения с полями под заполнение;
- заполненный пример обращения для городского велосипеда.
Запрещено: ставить диагноз, называть стоимость, обещать сроки ремонта,
добавлять правила, которых нет в списке выше.
Финальная строка памятки: «По фото стоимость не подтверждается».
Что менять под себя: список правил, название мастерской и пример поломки. Пункт про цену остаётся на месте, пока мастерская действительно называет стоимость после осмотра.
Копируемый промпт с запретом цены и диагноза
Запреты формулируются явно и стоят в промпте отдельным блоком. Модель склонна дописывать правдоподобные детали: срок ремонта, диапазон цены, предполагаемую причину поломки. Каждая такая деталь создаёт обязательство, которого у мастерской нет.
Honiq предупреждает: хороший промпт не устраняет галлюцинации надёжно, а беглая формулировка не равна профессиональной проверке. Запрет снижает вероятность лишних утверждений, а ручная сверка ловит то, что прошло.
Рабочий промпт для проверки готового текста:
Проверь текст памятки по исходным правилам.
Правила: тип велосипеда; что произошло и когда; фото общего вида и детали;
цена подтверждается только после осмотра.
Для каждой строки текста ответь:
- ведёт ли она к первому обращению клиента;
- опирается ли она на одно из правил;
- содержит ли она диагноз, стоимость или срок ремонта.
Выведи таблицу: строка текста, правило, вердикт «оставить» или «убрать»,
причина. Ничего не переписывай, только оценивай.
Что менять под себя: список правил и перечень запрещённых типов утверждений. Если в вашей сфере нельзя обещать наличие товара, добавьте это в третий пункт проверки.
Второй промпт полезен, когда черновик уже написан человеком. Он не создаёт текст заново, а раскладывает его по правилам и показывает лишнее.
Проверить каждое поле против исходного правила
Проверка идёт построчно. Возьмите памятку и напротив каждого пункта поставьте номер правила, из которого он выведен. Пункт без номера — кандидат на удаление.
| Поле памятки | Правило | Как проверить |
|---|---|---|
| Тип велосипеда | Назвать тип | Есть ли отдельная строка под класс |
| Что произошло и когда | Описать поломку | Указано ли время события |
| Фото общего вида и детали | Приложить фото | Понятно ли, какие изображения приложить |
| Вопрос об осмотре | Первое действие | Заканчивается ли текст вопросом |
| Строка о цене | Ограничение | Стоит ли она после пунктов |
Honiq замечает: схема не гарантирует правду, но делает ошибки заметнее. Таблица выше работает так же. Она не доказывает, что памятка полезна, зато показывает каждое поле, которое ни к чему не привязано.
Отдельно проверьте количественные сведения и даты. «Два фото» и «со вторника» заданы только в заполненном учебном обращении. Исходное правило требует приложить фото, но не устанавливает обязательное число снимков. Цена и срок ремонта требуют отдельного подтверждения.
Содержание, форма выдачи и автоматизация
Три слоя разделяются по моменту работы. Содержание — это правила и текст памятки. Форма выдачи — файл, страница или PDF, который читатель получает. Автоматизация — сбор контакта и передача заявки, например через Zapier.
Для создания содержания Nagent.ai советует сначала согласовать структуру, где каждый раздел привязан к источнику. DocsAura показывает похожий порядок со своей стороны: сначала черновик, потом оформление в инструменте дизайна документов и экспорт в PDF.
Практический смысл разделения прост. Пока памятка не проверена вручную, подключать форму и автоматизацию рано: вы начнёте собирать контакты под материал, который ещё меняется. Сначала текст, потом выдача, потом передача заявок.
Honiq добавляет требование к версионированию: системный промпт, база знаний, модель оценки и идентификатор модели хранятся отдельно. Иначе необычный результат не восстановить. Для памятки это означает, что список правил и текст промпта стоит держать в одном месте с датой правки.
Ручная приёмка полезности перед оформлением
Приёмка — это чтение памятки глазами клиента. Пройдите четыре вопроса. Первый: понятно ли из первой строки, что делать. Второй: хватает ли полей, чтобы мастер ответил без уточнений. Третий: нет ли утверждений о цене, диагнозе и сроках. Четвёртый: заканчивается ли текст действием.
Honiq советует планировать запасные варианты: детерминированный стандартный текст, повторную попытку, явное состояние ошибки или ручную проверку. Применительно к памятке это значит, что при сомнительном результате вы возвращаетесь к утверждённому списку правил и собираете текст вручную.
Полезно проверить материал на противоречивом случае. Возьмите обращение, где клиент описывает поломку неточно, и посмотрите, устоит ли памятка. Если текст начинает додумывать причину, запрет в промпте сформулирован слабо.
Финальный шаг — прогон заполненного примера через таблицу проверки. Каждое поле получает номер правила, лишние строки уходят. После этого памятку можно оформлять и отдавать читателю.
Частые вопросы
Сколько правил брать за основу?
Трёх достаточно для одностраничной памятки. Каждое правило превращается в поле, которое читатель заполняет перед обращением. Большее число правил удлиняет текст и снижает шанс, что человек дойдёт до конца.
Что делать, если модель придумала цену?
Уберите строку и усильте запрет в промпте. Honiq предупреждает, что промпт не устраняет галлюцинации надёжно, поэтому финальную сверку делает человек. Цена называется только после осмотра, и это правило стоит в тексте памятки.
Можно ли сразу подключить Zapier?
Автоматизацию разумно ставить после ручной приёмки текста. Пока памятка меняется, собранные контакты ведут к устаревшей версии материала. Сначала утвердите правила и поля, затем форму выдачи, затем передачу заявок.
Как понять, что памятка полезна?
Проверьте, заканчивается ли она действием и хватает ли мастеру присланных данных для ответа. Если после первого обращения приходится задавать уточняющие вопросы, поле пропущено. Таблица проверки показывает такие пропуски.
Нужен ли заполненный пример обращения?
Пример снимает вопрос «как это выглядит». Читатель видит готовую формулировку и переносит её на свою ситуацию. Пустой шаблон даёт структуру, пример показывает тон и объём сообщения.