Від промпту до розрахунку: як описати POS простою мовою

Опис POS простою мовою працює, але тільки якщо ви описуєте свій бізнес, а не програмне забезпечення. Найкращі описи виглядають так, ніби ви навчаєте нового співробітника під час його першої зміни: ось що ми продаємо, ось як люди платять, ось що має бути в чеку. Конструктор на основі промптів може перетворити такий опис на процес розрахунку, через який можна провести реальний продаж. Отримаєте ви робочу касу чи просто красиву демоверсію, залежить від п'яти деталей, і жодна з них не є технічною.

Як звучить опис POS простою мовою?

Це звучить так, ніби ви у вівторок показуєте комусь касову зону:

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

Жодних назв функцій, жодного опису екранів. Сім речень, які описують усю торгову зону: каталог, опції, типи оплати, податкові правила та чеки. Конструктор може з цим працювати. З чим він не зможе працювати, так це з промптом «зроби мені сучасний POS для пекарні», який описує настрій, а не бізнес.

Які п'ять деталей визначають, чи працюватиме розрахунок?

Ті, про які новий співробітник запитав би вже до обіду. Опишіть кожну своїми словами:

• Що ви продаєте та як воно згруповане. Не кожен товар, а лише структуру каталогу: ваші категорії та чи мають товари такі опції, як розмір або добавки. У POS ці опції називаються модифікаторами, і якщо їх випустити, це найчастіша причина, чому перша збірка здається незручною на касі.

• Як люди платять. Карткою, готівкою чи обома способами, і чи є чайові частиною обслуговування на вашій касі.

• Ваші податкові правила у тому вигляді, як ви їх застосовуєте на практиці. Не законодавство, а реальність вашого магазину: що обкладається податком, що звільнене від нього, і чи включено податок у ціну на ціннику, чи він додається на касі.

• Що має міститися в чеку. Надсилання на email, друкований чек чи обидва варіанти, а також обов'язкові елементи, як-от податковий номер підприємства чи правила повернення.

• Винятки. Застава за пляшки, вагові продукти, знижки для персоналу, постійний клієнт, який розраховується наприкінці місяця. По одному реченню на кожен випадок буде достатньо. Процес розрахунку, який обробляє звичайні продажі, але плутається на нестандартних, закидають уже за тиждень, що робить винятки найціннішими реченнями в усьому описі.

Чого не може зробити проста мова?

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

Саме тут зупиняються спроби зробити все власноруч. Генератор коду на основі ШІ створить переконливі екрани розрахунку з тих самих семи речень, і результат виглядатиме правильно, поки справа не дійде до реальних грошей і реальних товарів на складі. Ми описали межу цих можливостей у статті про вайб-кодинг касового термінала та про те, чому найкраща модель для кодингу все ще не може створити робочий POS самостійно. Проста мова — це повна специфікація для тих частин POS, які ви бачите. Але хтось все одно має побудувати ті частини, яких ви не бачите.

Як доопрацювати першу чернетку?

Так само, як ви виправляли б нового співробітника: конкретно та по одному пункту за раз. Проведіть тестовий продаж, щойно отримаєте попередній перегляд: спочатку найпопулярнішого замовлення, а потім найнезвичнішого. Якщо щось працює не так, виправте це простим реченням («для півдожини потрібно запитати, які саме шість тістечок»), замість того щоб заново описувати увесь магазин. Якщо доопрацювання потребує сам екран, використовуйте шаблони промптів для створення чудових макетів POS; опис самої транзакції, а не екрана, виконує більшу частину роботи.

У Final цей цикл відбувається у формі чату: описали, переглянули, виправили, розгорнули, причому кожна зміна зберігається як контрольна точка, до якої можна повернутися. Покрокову інструкцію розміщено в матеріалі як створити свій перший сценарій, а якщо ви волієте залишитися в інструменті ШІ, яким уже користуєтеся, ви можете підключити власний ШІ через MCP (стандартний спосіб підключення інструментів ШІ до іншого ПЗ) і будувати систему з тим самим інтерактивним попереднім переглядом. Детальніша історія про те, чому промптинг замінив візуальні конструктори, доступна, якщо вам цікаво, як ми до цього прийшли.

Тож чи справді проста мова може пройти шлях від промпту до розрахунку?

Так. Опис, який охоплює каталог, типи оплати, податкові правила, чек та винятки, є повною специфікацією для торгової зони магазину, і конструктор на основі промптів може перетворити його на робочу касу того ж дня. Жоден опис не може забезпечити внутрішню інфраструктуру електронної комерції, тому спрямовуйте свої речення на платформу, де ця частина вже існує. Золоте правило: описуйте свою касову зону так, ніби навчаєте нового співробітника, і дозвольте платформі подбати про все, чого новий співробітник ніколи не бачить.

Якщо ви хочете побачити, як опис перетворюється на працюючу касу, прочитайте п'ятихвилинну інструкцію Початок роботи з Build.