В режиме Код приложения Битрикс24 Коворк/Код можно описать приложение обычными словами, а AI-агент напишет код.
Чем точнее исходный запрос, тем ближе первая версия приложения будет к нужному результату. Для простого приложения может быть достаточно нескольких предложений. Если приложение должно работать с разными данными, выполнять несколько действий или учитывать роли пользователей, требования лучше описать подробнее.
В статье расскажем:
Как сформулировать запрос для создания приложения
Для простого приложения можно начать с короткого запроса. Укажите, что нужно создать, основные возможности и пожелания к интерфейсу.
Пример запроса:
Создай приложение для учета офисного оборудования. В нем сотрудники смогут находить оборудование и видеть, свободно оно или выдано. Сделай простой интерфейс со списком оборудования и поиском.
Такого описания достаточно, чтобы получить первую версию и посмотреть, подходит ли общая идея.
Для более сложного приложения лучше подробнее описать требования. Так агенту будет проще учесть нужные данные, действия и ограничения уже в первой версии.
Укажите в запросе:
- Цель — какую задачу должно решать приложение.
- Пользователей — кто будет работать с приложением.
- Роли — какие действия доступны разным пользователям.
- Источники данных — откуда приложение получает информацию.
- Возможности — что пользователь должен уметь делать.
- Результат — что приложение должно показывать или создавать.
- Интерфейс — какие экраны и основные блоки нужны.
- Обновление данных — когда приложение должно получать актуальные данные.
- Ограничения — что приложение не должно показывать, изменять или сохранять.
- Критерии готовности — по каким признакам можно проверить результат.
Начните с минимальной версии приложения и тестовых данных. Сначала проверьте основной сценарий: например, открывается ли список, работает ли поиск и меняется ли статус оборудования. Когда основная логика работает правильно, можно переходить к следующим возможностям и реальным данным.
Универсальный шаблон запроса:
Создай приложение [название].
Цель: [какую задачу решает приложение].
Пользователи: [кто будет пользоваться приложением].
Роли: [что разрешено каждой роли].
Источники данных:
- [источник 1];
- [источник 2].
Пользователь должен уметь:
- [действие 1];
- [действие 2].
Результат:
- [что должно отображаться или создаваться];
- [в каком виде].
Интерфейс: [основные экраны, блоки и требования к отображению].
Обновление данных: [при открытии / вручную / по расписанию].
Ограничения: [что нельзя показывать, изменять или сохранять].
Критерии готовности:
- [проверяемый результат 1];
- [проверяемый результат 2];
- [что должно происходить при ошибке или отсутствии данных].
Сначала создай минимальную рабочую версию на тестовых данных.
Не обязательно заполнять каждый блок. Оставьте только требования, которые важны для приложения.
Например, подробный запрос для приложения учета оборудования может выглядеть так:
Создай приложение «Учет оборудования».
Цель: сотрудники должны быстро находить офисное оборудование и проверять, свободно оно или выдано.
Пользователи: сотрудники компании и ответственный за оборудование.
Пользователь должен уметь:
- найти оборудование по названию или инвентарному номеру;
- отфильтровать свободное и выданное оборудование;
- открыть карточку оборудования.
Ответственный за оборудование должен уметь:
- добавлять оборудование;
- менять статус: «Свободно» или «Выдано»;
- указывать сотрудника, которому выдано оборудование.
Для первой версии используй тестовый список из 20 единиц оборудования.
Интерфейс:
- на главной странице размести поиск и список оборудования;
- для каждой позиции покажи название, инвентарный номер и статус;
- добавь фильтр по статусу.
Критерии готовности:
- поиск находит оборудование по названию и инвентарному номеру;
- фильтр показывает только оборудование с выбранным статусом;
- после изменения статуса он обновляется в списке.
Сначала создай минимальную рабочую версию на тестовых данных.
Запрос описывает желаемое поведение приложения, но сам по себе не гарантирует правильную настройку доступа к данным. Если в приложении есть разные роли, отдельно проверьте, какие данные и действия доступны каждой из них.
Как сформулировать критерии готовности приложения
Критерии готовности помогают проверить результат. По ним должно быть понятно, какое действие выполнить и что должно произойти. Например, «поиск работает правильно» — слишком общая формулировка. Нельзя однозначно определить, что именно нужно проверить.
Лучше описать конкретный результат:
При поиске по части названия приложение показывает все оборудование, в названии которого есть введенный текст.
Вместо «фильтр должен работать корректно» напишите:
Если выбрать статус «Свободно», в списке остается только оборудование с этим статусом.
Для каждого основного сценария добавьте хотя бы один проверяемый результат. Если приложение выполняет расчеты, сравните их с исходными данными. Если есть несколько ролей, проверьте доступ под каждой ролью. Добавьте критерии для ситуаций, когда данных нет или действие выполнить не удалось. Например, приложение должно показать понятное сообщение об ошибке.
Как улучшать приложение после первой версии
Сложное приложение удобнее создавать поэтапно. Сначала проверьте основной сценарий, затем исправляйте найденные проблемы и добавляйте следующие возможности.
Не обязательно каждый раз заново описывать все приложение. Если нужно изменить отдельную часть, укажите:
- где возникла проблема,
- что происходит сейчас,
- какой результат нужен,
- что именно можно изменить,
- какие готовые части менять не нужно.
Пример запроса:
В списке оборудования поиск сейчас работает только по полному названию.
Ожидаемый результат: поиск должен находить оборудование и по части названия.
Измени только поиск. Не меняй карточку оборудования, фильтр и внешний вид списка.
После изменения проверь поиск по полному и частичному названию.
Чем конкретнее требование к интерфейсу или поведению, тем легче проверить результат. Вместо «сделай страницу удобнее» укажите, что именно нужно изменить: расположение блоков, размер элементов, состояния кнопок или поведение на разных экранах.
Как описать ошибку
Если приложение работает неправильно, опишите ошибку: какое действие выполняете, какой результат получаете и что должно происходить вместо этого.
Например:
Проведи диагностику ошибки.
Когда ответственный меняет статус оборудования со «Свободно» на «Выдано», в карточке отображается новый статус, но в общем списке остается старый.
Ожидаемый результат: после изменения статуса в карточке тот же статус должен отображаться в общем списке.
Отдели подтвержденные факты от предположений. Определи, в какой части возникает проблема, и предложи способ проверки.
Не переписывай приложение целиком без необходимости.
После исправления измени статус тестовой позиции и проверь его в карточке и общем списке.
Так агент получает конкретный сценарий для диагностики и может искать причину в нужной части приложения, не меняя остальную логику.
После каждой правки проверяйте приложение во встроенном браузере — точечные изменения могут затронуть другие возможности.
Что проверить перед отправкой запроса
Перед отправкой запроса проверьте, что:
- понятно, какую задачу решает приложение,
- указано, кто будет им пользоваться,
- описаны основные данные и действия,
- понятно, какой результат должен получить пользователь,
- указаны важные ограничения,
- можно проверить критерии готовности,
- можно начать с минимальной версии и тестовых данных,
- в запросе нет ключей, паролей, токенов и реальных персональных данных.
Коротко
- Для простого приложения может быть достаточно короткого описания. Для рабочего приложения укажите цель, пользователей, данные, возможности, результат, ограничения и критерии готовности.
- Первую версию лучше делать минимальной и на тестовых данных. Так проще проверить основную логику до подключения реальных данных.
- Критерии готовности должны описывать результат, который можно проверить.
- Улучшайте приложение поэтапно в диалоге с агентом — укажите проблему и ожидаемый результат.
- При ошибке опишите конкретный сценарий и попросите сначала определить область проблемы, а после исправления — повторно проверить основной сценарий.
- Не добавляйте в запросы ключи, пароли, токены и реальные персональные данные.