От промпта до оплаты: как описать POS простыми словами

Описание POS простыми словами работает, но только если вы описываете свой бизнес, а не программное обеспечение. Лучшие описания выглядят так, будто вы обучаете нового сотрудника в его первую смену: вот что мы продаем, вот как нам платят, вот что должно быть в чеке. Конструктор на основе промптов может превратить такое описание в рабочую кассу для реальных продаж. Получите ли вы работающую кассу или просто красивую демоверсию — зависит от пяти деталей, и ни одна из них не является технической.

Как выглядит описание POS простыми словами?

Оно звучит так, будто вы обычным днем показываете кому-то работу за стойкой:

«У меня пекарня с одной кассой. Мы продаем хлеб, выпечку и фильтр-кофе. Выпечку покупают поштучно или по полдюжины. Кофе бывает двух объемов с выбором молока. Почти все платят картой бесконтактно, но мы принимаем и наличные. Целые буханки у нас не облагаются налогом, на все остальное начисляется налог с продаж. Чек клиенты обычно просят отправить на email».

Никаких названий функций, никаких описаний экранов. Семь предложений, которые описывают всю работу торговой точки: каталог, варианты товаров, типы оплаты, правила налогообложения и чеки. Конструктор сможет с этим работать. С чем он работать не сможет — так это с запросом «сделай мне современную POS для пекарни», который описывает настроение, а не бизнес.

Какие пять деталей определяют, будет ли касса работать?

Те самые, о которых новый сотрудник спросит еще до обеда. Опишите каждую из них своими словами:

• Что вы продаете и как товары сгруппированы. Не каждый отдельный товар, а лишь структуру каталога: ваши категории и наличие параметров у товаров (например, размер или добавки). В POS эти параметры называются модификаторами, и их отсутствие — самая частая причина, почему первая сборка кажется неудобной на кассе.

• Как люди платят. Картой, наличными или и тем и другим, а также предусмотрены ли чаевые.

• Ваши налоговые правила на практике. Не законодательство, а реальность вашего магазина: что облагается налогом, что освобождено от него и включен ли налог в ценник или добавляется на кассе.

• Что должно быть в чеке. Отправка на email, печать или оба варианта, а также обязательные реквизиты, такие как ИНН/номер компании или правила возврата.

• Исключения. Залог за тару, весовые товары, скидки для персонала, постоянный клиент, который платит в конце месяца. По одному предложению на каждое правило — этого достаточно. Касса, которая справляется с обычной продажей, но спотыкается на нестандартных случаях, забраковывается за неделю, поэтому исключения — самые ценные предложения во всем описании.

Чего нельзя сделать простыми словами?

Описание определяет поведение, но оно не может обеспечить правильную работу внутренних механизмов. Точный учет остатков при одновременной продаже одного и того же товара на двух кассах, вечерние отчеты, которые сходятся (совпадают с фактически прошедшими деньгами), налог, рассчитываемый одинаково на тысячной продаже и на первой, а также эквайринг, соответствующий стандартам безопасности PCI, — все это не то, что можно задать одним предложением. Платформа, на которой создается ваша система, либо предоставляет это, либо нет.

Именно здесь заходят в тупик самостоятельные попытки разработки. Генератор кода на базе ИИ создаст убедительные экраны кассы из тех же семи предложений, и результат выглядит правильно — ровно до тех пор, пока дело не дойдет до реальных денег и реальных товаров. Мы разобрали эту проблему в статьях о вайб-кодинге торговых точек и о том, почему передовая языковая модель все еще не может сама создать работающую POS. Описание простыми словами — это полная спецификация для той части POS, которую вы видите. Но кто-то должен создать ту часть, которую вы не видите.

Как доработать первый черновик?

Так же, как вы поправляли бы стажера: конкретно и по одному пункту за раз. Проведите тестовую продажу, как только появится предпросмотр: сначала самый частый заказ, затем самый необычный. Если что-то работает не так, исправьте это простым предложением («при выборе полдюжины нужно спросить, какие именно шесть изделий выбрать»), а не переписывайте описание всего магазина. Если доработки требует сам экран, используйте шаблоны промптов для создания отличных интерфейсов POS; описание самой транзакции, а не экрана, выполняет большую часть работы.

В Final этот цикл происходит в формате чата: описали, посмотрели предпросмотр, скорректировали, развернули — причем каждое изменение сохраняется как контрольная точка, к которой можно откатиться. Пошаговое руководство находится в статье как создать свой первый сценарий, а если вы предпочитаете использовать уже familiar ИИ-инструмент, вы можете подключить собственный ИИ через MCP (стандартный способ подключения ИИ-инструментов к стороннему ПО) и вести разработку с тем же живым предпросмотром. Также вы можете прочитать подробную историю о том, почему промпты вытеснили визуальные конструкторы.

Так можно ли действительно пройти путь от промпта до кассы с помощью простых слов?

Да. Описание, охватывающее каталог, способы оплаты, налоговые правила, чеки и исключения, представляет собой полную спецификацию торговой точки, и конструктор на основе промптов может превратить его в работающую кассу в тот же день. Единственное, что не может предоставить ни одно описание, — это лежащая в основе инфраструктура торговли, поэтому направляйте свои инструкции на платформу, где эта часть уже готова. Главное правило: описывайте работу за стойкой так, будто обучаете нового сотрудника, и позвольте платформе взять на себя все то, чего новый сотрудник никогда не видит.

Если вы хотите увидеть, как описание превращается в работающую кассу, прочтите пятиминутное руководство С чего начать работу с Build.