Сценарии, с которых начинается проверка
Я выписываю фразы вида «какое приложение для» и дальше живая задача: учесть расход, записать тренировку, сдать отчёт, найти мастера. Брендовый запрос оставляю отдельной строкой. Если приложение видно только по имени и не видно по задаче, в рекомендательном ответе его нет.
Сценарий формулирую так, как его произносит пользователь, включая разговорные слова. Канцелярское «решение для оптимизации» в промпт не ставлю. Рядом записываю, для кого сценарий не подходит: другая страна, другая платформа, другой тип учёта.
- Какое приложение закрывает конкретную задачу
- Чем оно отличается от двух известных альтернатив
- Есть ли версия для нужной платформы
- Сколько стоит и где лежит оплата
- Какие данные нужно отдать на старте
- Кому сценарий не подойдёт
Промпт по задаче и промпт по имени приложения храню отдельно.
Страница продукта
На сайте одна основная страница отвечает, что делает приложение, на каких платформах оно есть и какой сценарий закрывает целиком. Функции списком лучше, чем абзац из прилагательных. У каждой функции, которую спрашивают в поддержке, есть одна фраза без двойного смысла.
Цену и модель оплаты пишу так, чтобы их нельзя было перепутать с покупкой внутри стора. Если есть бесплатный режим, я отмечаю, чего в нём нет. Дата сверки стоит у блока цены, потому что витрина стора меняется чаще, чем статья.
- Какую задачу приложение закрывает
- На каких платформах оно доступно
- Чего нет в бесплатном режиме, если он заявлен
- Где проходит оплата: на сайте или в сторе
- Кому этот сценарий не подходит
- Дата, на которую сверена цена
Страница продукта называется сценарием и ограничением, а не слоганом.
Сторы как источник, который мы не контролируем целиком
Карточка в сторе часто оказывается единственным текстом, который модель видела. Я сверяю название, иконку, короткий описание и список платформ с сайтом. Расхождение «на сайте есть функция, в сторе её нет» модель обычно решает в пользу стора.
Версию и дату обновления не прячу. Если в отзывах ругают уже исправленную ошибку, на странице продукта можно коротко сказать, с какой версии поведение другое. Без номера версии такая оговорка выглядит как отписка.
Сайт и карточка стора должны выдерживать сверку в один проход.
Сравнения без выдуманного рейтинга
Сравнение имеет смысл, когда оба продукта описаны по одному списку свойств: платформа, цена, ключевой сценарий, чего нет. Я не ставлю себе балл и не рисую место в «топе приложений». Если свойства конкурента не проверены по его публичной карточке, строки в таблице нет.
Дата просмотра чужой карточки обязательна. Функция, которую конкурент уже убрал, в сравнении не живёт месяцами. Такой материал я либо обновляю, либо снимаю с публикации, чтобы модель не цитировала мёртвую таблицу.
Нет проверенного свойства — нет строки в сравнении.
Отзывы
Отзывы из стора я читаю как источник повторяющихся сюжетов, а не как оценку «звёздами для модели». Если один и тот же провал всплывает в вопросах, его закрывают правкой продукта или ясной оговоркой на странице. Просьба друзьям написать восторги картину ответа не чинит.
На сайте отзыв публикую с контекстом: платформа, сценарий, чего человек хотел. Безымянная цитата «удобно и быстро» не даёт модели ничего, кроме шума. Её можно не ставить.
Повторяемый сюжет отзыва важнее средней оценки.
Чего модель не знает, пока мы этого не написали
Модель не знает актуальный состав подписки, внутренние ограничения страны и то, какая функция ещё в разработке. Догадку она заполнит по похожим приложениям. Поэтому всё, что нельзя путать, написано на странице продукта обычным текстом.
После правок задаю те же сценарии заново и смотрю, подтянулась ли карточка стора или только сайт. Если в ответе осталась старая цена, фиксирую, какой источник её держит. Пока источник старый, новую статью про «продвижение приложения» я не добавляю.
Пустое место в фактах модель заполняет похожим приложением.