Что ИИ делает не так при проектировании процесса оплаты (и как это исправить)

ИИ совершает одну предсказуемую ошибку при проектировании процесса оплаты: он проектирует для демонстрации, а не для десятитысячной транзакции. Попросите конструктор приложений на базе ИИ создать процесс оплаты, и вы получите нечто убедительное за пару минут. Чистая корзина, аккуратные кнопки, понятный экран оплаты. Ошибки кроются во всем, что невозможно показать на скриншоте: как процесс справляется с возвратом средств, разделением платежа, налоговыми правилами или очередью покупателей в субботу в полдень.

Решение заключается не в улучшении промптов. Оно в том, чтобы решить, какими частями процесса оплаты должен управлять ИИ, а в каких ему категорически нельзя позволять импровизировать. Вот где на самом деле ломаются созданные ИИ процессы оплаты и что с этим делать.

Почему спроектированный ИИ процесс оплаты выглядит правильно, но подводит в работе?

На то есть две причины. Во-первых, ИИ учится проектированию оплаты на основе существующих решений, а они весьма посредственны. Институт Baymard оценивает средний зафиксированный уровень брошенных корзин в интернете в 70,22%¹ и отмечает, что средний процесс оплаты в США содержит 23,48 элемента форм, тогда как идеальному процессу требуется от 12 до 14¹. Модель, обученная на средних показателях, воспроизводит эти средние показатели вместе со всеми ошибками.

Во-вторых, предвзятость «идеального сценария» (happy-path bias). Сгенерированное ПО оценивают так же, как демоверсию: работает ли стандартный сценарий? Процесс же оплаты оценивают как кассовый аппарат: работает ли любой сценарий, каждый раз, на глазах у покупателя? Это совершенно разные планки, и разрыв между ними остается незаметным до тех пор, пока через систему не пойдут реальные деньги.

Что именно ИИ делает не так в процессе оплаты?

Пять ошибок повторяются снова и снова. (О более глубоком инфраструктурном разрыве, стоящем за ними, читайте в статье Можно ли создать POS с помощью Lovable или Replit?. Этот список касается непосредственно процесса оплаты.)

• Расчет денег. Сгенерированный код обычно выполняет валютные вычисления с плавающей запятой (десятичная математика с непредсказуемым округлением), из-за чего копейки теряются при расчете скидок, налогов и разделении платежей. Симптом проявляется при закрытии смены: итоговые суммы не сходятся (до копейки) с вашим отчетом на конец дня.

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

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

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

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

Как исправить спроектированный ИИ процесс оплаты?

Разделите задачу на две части. ИИ действительно хорош в дизайне: макет, последовательность шагов, формулировки и адаптация экрана под то, как на самом деле продает ваш магазин. Пусть он отвечает за это. Финансовая же часть (арифметика, налоги, обработка платежей, запись транзакций) должна опираться на детерминированную торговую инфраструктуру (которая каждый раз дает один и тот же правильный результат), а не на код, придуманный под конкретный промпт.

Фраза «просто напиши промпт, чтобы налоги считались правильно» не решает проблему, потому что по внешнему виду нельзя понять, сработало ли это. Процесс оплаты может ошибаться на несколько центов в каждой транзакции месяцами, прежде чем кто-то это заметит. Поэтому решение должно быть структурным:

• Ограничивайте вместо того, чтобы писать промпты. Используйте платформу, где расчеты, налоги и способы оплаты уже встроены, а ИИ может лишь компоновать их, но не изобретать заново.

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

• Проведите сверку в первый же день. Сравните итоговые суммы вашего процесса оплаты с отчетами платежного процессора после первого реального дня продаж. Расхождения в копейках проявятся сразу же.

• Следите за обходными путями. Если на первой же неделе сотрудники начинают придумывать обходные пути, дизайн не удался. Исправьте его до того, как обходные пути превратятся в систему.

Итак, что же ИИ делает не так при проектировании процесса оплаты?

Он правильно создает картинку, но ошибается в «инженерных коммуникациях»: идеальные сценарии, импровизированный расчет денег, угадывание налогов и отсутствие решений для возвратов, разделения платежей или оплаты картой на месте. Ничто из этого не исправить более качественным промптом — это решается размещением ИИ поверх инфраструктуры, которая уже умеет работать с деньгами. Золотое правило: позвольте ИИ проектировать процесс, но никогда не позволяйте ему импровизировать с деньгами.

Это разделение лежит в основе конструкторов на базе промптов, таких как Build от Final, где вы описываете желаемый процесс оплаты, а расчеты, налоги и транзакции Final Pay под капотом обеспечиваются системой, в которой все всегда сходится. Чтобы увидеть это на практике, создайте свой первый сценарий примерно за десять минут или посмотрите на картину шире со статьей ИИ для бизнеса: что он может (и чего не может) делать.