Как составить бриф и проверить приложение для клиентских запросов, созданное ИИ
Опишите форму запроса, хранение в базе данных и представление для сотрудников для Leina, затем проверьте сохранение, валидацию и контроль доступа перед публикацией.
Приложение для клиентских запросов начинается с простой идеи: позволить людям сообщить вам, что им нужно, а затем дать вашей команде единое место для просмотра запросов.
Чтобы это было полезно, форма должна сохранять отправленные данные, объяснять отсутствующие поля и обеспечивать доступ к представлению для сотрудников только нужным людям.
С помощью App Builder от Leina вы можете создавать полноценные веб-приложения — с серверной логикой и хранением в базе данных — через диалог. Используйте приведённый ниже пример брифа, чтобы запросить первую версию, а затем проверьте её фактическое поведение, прежде чем делиться ею с реальными пользователями.
Определите объём минимальной первой версии
При генерации приложений с помощью ИИ сопротивляйтесь желанию запросить всё сразу (например, уведомления, синхронизацию с CRM, вложения файлов и теги приоритета). Начните с компактной, проверяемой основы:
| Компонент | Необходимые требования v1 | Что пока не включать |
|---|---|---|
| Публичная форма | Имя клиента и детали запроса; валидация обязательных полей | Вложения файлов и многошаговые мастера |
| База данных | Постоянное хранение записей с автоматическими временными метками отправки | Автоматическая оценка приоритета или теги настроений ИИ |
| Панель сотрудников | Список отправленных записей только для чтения в обратном хронологическом порядке | Двусторонняя синхронизация с CRM, автоматические письма с ответами клиентам |
| Обратная связь | Явный баннер подтверждения только после успешной записи в базу данных | Предположительные состояния успеха до подтверждения базы данных |
Решите, кто должен видеть каждое представление. В этом примере посетители отправляют запросы, а авторизованные сотрудники читают их. Спросите Leina, как она может реализовать такое разделение; это требования для проверки, а не список встроенных средств контроля.
Дайте Leina бриф с наблюдаемыми спецификациями
Скопируйте и адаптируйте этот стартовый бриф в Leina App Builder:
Создай веб-приложение для клиентских запросов с двумя отдельными представлениями:
- Публичная форма запроса:
- Поля: «Customer Name» и «Request Details» (оба поля обязательны).
- Валидация на стороне клиента и сервера: отклонять пустые отправки или ввод только из пробелов с встроенным сообщением об ошибке.
- Показывать баннер подтверждения успеха только после подтверждения записи в базе данных.
- Панель сотрудников:
- Отображать все отправленные запросы в аккуратной таблице или списке, упорядоченные от новых к старым.
- Показывать имя клиента, временную метку отправки и полный текст запроса.
- Контроль доступа:
- Форма отправки должна быть доступна всем публичным посетителям.
- Панель сотрудников должна быть ограничена только аутентифицированными членами команды.
Объясни средства контроля доступа, доступные для этих двух представлений, и отметь любое требование, которое ты не можешь реализовать. Используй вымышленные тестовые записи во время разработки. Подготовь приложение к проверке перед публикацией.
Выполните четыре основных приёмочных теста
Выполните эти четыре проверки на тестовом приложении. Они выявляют полезные проблемы первого запуска; доступ и обработка данных всё ещё требуют проверки для вашего предполагаемого использования.
1. Проследите отправку до хранилища
Отправьте характерный запрос, например «Test: Weekly digest feature». Проверьте его значения в представлении для сотрудников, перезагрузите страницу, а затем найдите ту же запись в серверном хранилище или через отдельный авторизованный сеанс браузера.
Перезагрузка — это первая проверка, а не доказательство записи в базу данных: хранилище браузера, такое как localStorage, также переживает перезагрузки. Изучите сохранённую запись, чтобы убедиться, где оказались данные. Если вы не можете её изучить, отметьте эту часть проверки как нерешённую. Добавьте второй запрос и убедитесь, что первый остался неизменным.
2. Тест пустой отправки (валидация)
Попробуйте отправить форму с пустыми полями или только с пробелами.
Ожидаемое поведение: Форма должна подсветить отсутствующие поля, заблокировать отправку и создать никаких пустых записей в базе данных.
3. Тест многострочности и специальных символов (форматирование)
Отправьте запрос, содержащий переносы строк, маркеры списка, кавычки и символы (&, <, #). Изучите представление для сотрудников, чтобы убедиться, что форматирование сохранено без искажённых символов или ошибок экранирования.
4. Тест в режиме инкогнито (контроль доступа)
Скопируйте URL панели сотрудников и откройте его в приватном / инкогнито-окне браузера, где вы не авторизованы.
Ожидаемое поведение: Приложение должно запросить аутентификацию или отказать в доступе. Также проверьте авторизованную учётную запись, у которой не должно быть доступа сотрудника. Скрытая страница или только экран входа сами по себе не доказывают, что запросы к базовым данным защищены. Если требуемое ограничение недоступно, держите приложение на вымышленных данных, пока это не будет решено.
Записывайте свои наблюдения с помощью контрольного списка проверки приложения для клиентских запросов.
Исправляйте по одному поведению за раз
Когда вы сталкиваетесь с проблемой, не просите конструктор «исправить всё». Давайте конкретные инструкции по одному поведению:
Когда я отправляю пустой запрос, форма показывает сообщение об успехе, хотя запись не сохраняется. Пожалуйста, вместо этого показывай встроенную ошибку об обязательном поле, сохрани работу успешных отправок и сохрани существующие тестовые записи.
После каждого исправления проверяйте как исправленный путь ошибки, так и обычную отправку, чтобы убедиться, что исправление не внесло регрессий.
Публикация и развёртывание
После того как вы устранили замечания и подтвердили, что приложение подходит для предполагаемой аудитории:
- Проверьте тестовые данные: Определите и удалите только вымышленные записи, созданные вами для тестирования.
- Проверьте доступ: Убедитесь, кто может отправлять запросы и кто может читать сохранённые записи, используя средства контроля, фактически доступные в приложении.
- Опубликуйте и проверьте: Найдите приложение в My Apps и следуйте доступному процессу публикации. Повторите отправку и проверки доступа на опубликованной версии, прежде чем делиться ссылкой на её форму.
Выберите человека для проверки входящих запросов и ведите учёт нерешённых ограничений. Добавляйте функции после того, как команда использовала небольшую версию и знает, что ей нужно дальше.