# Gemini 3.6 Flash может сгенерировать экран оформления заказа за секунды. Что должно работать идеально до принятия реального платежа?

> Published: 2026-07-31
> Updated: 2026-07-31
> Author: Mathias Nielsen
> Category: POS
> Canonical: https://finalpos.com/ru/blog/gemini-36-flash

Gemini 3.6 Flash делает создание макета экрана оформления заказа практически бесплатным. Но проведение реальной оплаты по-прежнему зависит от пяти вещей, которые модель не генерирует: учет запасов при параллельных запросах, сходящаяся отчетность, правильный расчет налогов, платежи по стандарту PCI и сертифицированное оборудование.

Скорость никогда не была недостающим звеном. Прежде чем касса, сгенерированная ИИ, примет реальную оплату, пять вещей должны работать идеально: учет товаров, выдерживающий одновременную продажу на двух кассах, сходящаяся отчетность (совпадающая с фактически поступившими деньгами), расчет налогов с учетом юрисдикции, обработка платежей по стандарту PCI и сертифицированное оборудование для приема карт. Gemini 3.6 Flash делает первый макет экрана оформления заказа быстрее и дешевле, чем когда-либо. Но модель ничего не меняет в остальных пяти пунктах. Прототип Gemini 3.6 Flash POS — это отличный старт, но готовая к развертыванию POS-система — это совсем другая финишная черта.

Названия моделей, цены и бенчмарки быстро меняются. Приведенные ниже данные актуальны на момент публикации; относитесь к ним как к снимку состояния на текущий момент.

## Что на самом деле изменила Gemini 3.6 Flash?

Она сделала быструю и дешевую генерацию кода еще дешевле и точнее. Google выпустила Gemini 3.6 Flash 21 июля 2026 года вместе с Gemini 3.5 Flash-Lite[¹](https://techcrunch.com/2026/07/21/google-releases-three-new-gemini-models-but-no-3-5-pro/). Она стоит $1,50 за миллион входных токенов и $7,50 за миллион выходных токенов, использует примерно на 17% меньше выходных токенов, чем ее предшественница, и демонстрирует реальный скачок в точности написания кода, набрав 49% в бенчмарке DeepSWE против 37% у 3.5 Flash[²](https://9to5google.com/2026/07/21/gemini-3-6-flash-launch/).

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

![Владелец магазина создает процесс оформления заказа с помощью текстового запроса на ноутбуке — то, что Gemini 3.6 Flash делает быстро](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/cd58dafac81e2afd-merchant-prompting-checkout-flow.jpg)

## Почему экран оформления заказа — это еще не POS-система?

Потому что экран оформления заказа — это лишь интерфейсный вывод, а POS-система — это мастер-система (единственное место, где ваши показатели продаж считаются достоверными). Экран — это видимые десять процентов. Под ним лежит состояние, которое должно оставаться точным на всех терминалах, при каждом возврате и при любых сбоях сети, плюс движение денег, подпадающее под регулирование независимо от того, был ли код написан вручную или сгенерирован. Мы разбирали это различие, когда [вышел GPT-5.6](/blog/can-chatgpt-5-6-build-a-working-pos), и оно остается верным для каждой быстрой модели с тех пор.

Очевидное возражение: эти модели теперь пишут код промышленного уровня, так почему бы не доверить Gemini 3.6 Flash еще и логику учета товаров и налогов? Она может ее написать. Проблема не в написании кода. Проблема в том, чтобы доказать корректность этого кода в условиях, которые вы никогда не увидите на демо-показе, и вовремя заметить, когда он незаметно сбоит. Экран кассы, срендеренный с ошибкой, замечают за секунды. Расхождение в реестре замечает бухгалтер в конце месяца, а до тех пор каждый отчет выглядит вполне нормально.

## Что должно работать идеально до первого реального списания?

Пять вещей, и ни одна из них не отображается в окне предпросмотра.

![Оборудование для торговли без бренда и кабели под кассовой стойкой — уровень инфраструктуры, который все еще нужен для Gemini 3.6 Flash POS](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/d0081e7fb4652968-commerce-infrastructure-under-counter-v2.jpg)

### Учет товаров, выдерживающий параллельные запросы

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

### Сходящаяся отчетность

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

### Расчет налогов в соответствии с юрисдикцией

Налог с продаж суммируется: национальная ставка поверх региональной, льготы для отдельных товаров, ставки, меняющиеся по решению законодателей, а не по вашему графику релизов. Ошибка здесь — это не просто баг-тикет, это юридическая ответственность. Настоящая система настраивает налоги один раз и применяет их везде одинаково, так же, как [работают группы налогов в Merchant Hub](https://finalpos.com/help/merchant-hub-settings).

### Обработка платежей, соответствующая PCI

Стандарт PCI DSS (стандарт безопасности индустрии платежных карт) существует для того, чтобы данные карт обрабатывались только аудированными системами. Сгенерированный код никогда не должен «видеть» номер карты. На практике это означает, что платежи проходят через сертифицированный стек платежного процессора, а данные карт токенизируются (заменяются временным токеном) до того, как ваше ПО вообще к чему-либо прикоснется. Это самый не подлежащий обсуждению пункт в списке, и он находится полностью за пределами того, что выдает любая модель.

### Сертифицированное оборудование для приема карт

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

![Покупатель прикладывает карту к сертифицированному платежному терминалу рядом с планшетом с пользовательским интерфейсом кассы](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/bccb5e0d11f6cdb1-certified-terminal-separate-checkout.jpg)

## В чем быстрая модель реально помогает?

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

Именно так Final Build работает с моделями: вы можете [подключить Gemini или любой другой MCP-клиент](https://finalpos.com/help/connect-your-own-ai-mcp) и позволить ему собрать ваш сценарий с интерактивным предпросмотром, пока Final Pay проводит платежи через платежный процессор и сертифицированные терминалы. Пошаговые инструкции см. в материале [как создавать системы с помощью Gemini 3.6 Flash](/blog/gemini-3-6-flash-no-code-pos) или [как три ведущие модели сравниваются при создании POS-систем](/blog/claude-vs-chatgpt-vs-gemini-pos).

## Итак, что должно работать идеально до того, как Gemini 3.6 Flash примет реальный платеж?

Учет товаров при параллельных запросах, сходящаяся отчетность, расчет налогов по юрисдикциям, обработка платежей по PCI и сертифицированное оборудование. Gemini 3.6 Flash сделала экран оформления заказа самой дешевой частью проекта, но не затронула ни один из этих пунктов. Золотое правило: если сбой отобразится на вашем банковском счете, а не на экране, не доверяйте его сгенерированному коду. Создавайте макеты с помощью самой быстрой модели, а затем разворачивайте их на инфраструктуре, созданной для прохождения аудита. Если вы хотите попробовать этот подход сегодня, [начните работу с Build](https://finalpos.com/build).

## FAQ

**Q: Может ли Gemini 3.6 Flash самостоятельно создать POS-систему?**
A: Она может быстро сгенерировать экраны оформления заказа и большую часть логики сценария. Но она не может обеспечить обработку платежей по стандарту PCI, сертифицированное оборудование для приема карт или сходящийся реестр транзакций. Все это предоставляет торговая инфраструктура, на которой работает сгенерированный сценарий.

**Q: В чем разница между интерфейсом оформления заказа и рабочей POS-системой?**
A: Интерфейс оформления заказа — это то, что вы видите на экране. Рабочая POS-система — это мастер-система: она поддерживает точный учет товаров на всех терминалах, формирует отчеты, совпадающие с реально поступившими деньгами, правильно рассчитывает налоги и проводит платежи через платежный процессор на сертифицированном оборудовании.

**Q: Почему код учета товаров, сгенерированный ИИ, сбоит в реальных магазинах?**
A: Из-за параллелизма (concurrency). Два терминала могут продать последнюю единицу товара в одну и ту же секунду, и примитивный сгенерированный код пропустит обе продажи. На демонстрациях это никогда не вылезает, так как там редко запускают две кассы одновременно с одним запасом.

**Q: Что означает соответствие PCI для кассы, созданной ИИ?**
A: PCI DSS — это стандарт безопасности индустрии платежных карт для работы с данными карт. На практике сгенерированный код никогда не должен «видеть» номер карты: платежи должны проходить через сертифицированный стек платежного процессора, а данные карт — токенизироваться до того, как к ним прикоснется ваше ПО.

**Q: Могу ли я использовать Gemini 3.6 Flash с Final?**
A: Да. Build поддерживает подключение вашего собственного ИИ через MCP: Build генерирует одноразовый блок настройки, который вы вставляете в свой инструмент, и модель создает ваш сценарий на инфраструктуре Final с интерактивным предпросмотром, а платежи обрабатываются через Final Pay.