自助终端、点餐屏与查价机：一个构建器，多种工具

自助结账终端、自助点餐屏和查价机表面上看是三种不同的产品，传统 POS 厂商也是这样打包销售的：三份报价单、三个软件模块、三个管理后台。然而在底层，它们本质上是同一种东西换了三套外衣。每一个都是连接到商品目录、价格、库存以及（其中两个涉及的）支付系统的屏幕界面。只要屏幕展示是唯一的变量，一个构建器就能通过自然语言描述生成所有这些工具。

以下是这些工具走向融合的原因，以及真正的工程核心所在。

为什么这些工具通常意味着三次独立的采购？

因为行业惯常的打包销售方式就是如此。自助终端通常包含独立的软硬件组合；点餐屏往往作为绑定特定终端的附加模块提供；而查价机大部分是作为接入企业级库存系统的专用设备卖给大型卖场。每一项工具都有各自的配置流程、独立合同以及一套专属的商品数据副本。

对于小商家而言，这种成本账很难算得过来。自助终端可能还算物有所值（让自助终端物超所值的功用早已广为人知），但独立的查价机几乎很难证明其投资价值。于是，顾客关于货架商品的疑问（“这个多少钱？”）依然只能依靠店员解答，午餐高峰期的排队人群依然挤在单个收款台前。这些工具并非毫无用处，只是它们的定价方式仿佛每个工具都是一项独立的商业决策。

自助终端、点餐屏和查价机有哪些共同点？

抛开外壳不谈，它们每一个都是对同一套商业数据的轻量展示界面：

• 自助结账终端可让顾客浏览目录、添加购物车并完成支付。

• 自助点餐屏完成同样的前置流程，然后将订单发送给店员接单履约。

• 查价机读取单个商品并显示其价格。无需购物车，无需支付，仅仅是一次目录查询。

显而易见的差异在于每个屏幕开放了哪些功能。然而隐性的要求则是，所有这些设备都必须与柜台收款机保持一致：统一的库存计数、统一的计税逻辑以及统一的销售数据汇总点，以便于日结核算（汇总所有设备的数据）。独立的系统之间会出现偏差，这与两个工具各自管理独立库存时门店与线上库存出现偏差是同一个道理。搭建屏幕界面并不难，难的是如何让多台屏幕的数据与同一套记录完全精准匹配——这才是真正的产品力所在。

一个构建器如何生成所有这三种工具？

在 Final 上，每个工具都是一个“流程”（flow）：即在部署它的站点上运行的结账体验。您只需用自然语言描述所需的工具，在实时预览中查看成型效果，通过对话进行微调，然后即可将其部署到站点（支持 iPhone、Android 设备或浏览器）。（正因如此，Final 放弃了早期通过点击拼接的构建器，全面转向基于提示词的构建方式：描述一个工具比拼装一个工具要快得多。）自助终端流程、点餐屏流程和查价机流程只是三种不同的描述，而不是三次采购周期。

实现这一点得益于两个关键要素：

• 每个流程背后共享同一个目录。 商品、价格、税费和库存均统一保存在商家中心（Merchant Hub）中，因此新工具无需重新录入数据。查价机显示的商品价格与收款台完全一致，因为两者读取的是同一条记录。

• 复用现有硬件。 支架上的平板电脑就是自助终端；挂在过道墙上的同一台平板电脑就是查价机。无需租赁设备，也无需购买专有外壳。

如果您不想从零开始编写提示词，流程库（Flow Library）提供了预设流程，您可以直接安装并进行调整。我们还详细介绍了如何构建查价机终端以及如何将草图一步步转化为平板自助终端。如果您倾向于使用自己的工具，还可以通过 MCP 连接您自己的 AI（一种允许 AI 工具与其他软件连接的标准），让它为您自动生成流程。

AI 生成的界面在收银柜台上值得信赖吗？

这取决于 AI 实际生成的内容。在 Final 的模式中，构建器生成的是前端展示层：包括界面、布局以及顾客操作的步骤。它并不涉及底层基础设施的生成。支付环节由认证的终端硬件（经过批准用于线下支付的读卡器）通过 Final Pay 处理，税费计算来自平台本身，而库存更新则与其他所有销售一样写入相同的记录。任何流程都无法擅自更改刷卡扣款的底层方式。

这种职责划分也控制了每个工具的风险上限。查价机完全不涉及支付环节，它只读取商品目录，因此即使提示词写得不够精准，最坏的结果不过是界面不美观，而绝不会发生错扣款项的情况。此外，任何变更都不会随意上线：每次部署都有版本控制，需经过上线前检查，且每一次修改都会保存为可还原的检查点，方便随时回滚。

那么，您到底需要一个构建器还是三款产品？

只需要一个构建器。自助终端、点餐屏和查价机本质上都是同一种“屏幕+商品目录”模式，只是启用的功能有所差别；将它们作为三款独立产品采购，意味着您需要支付三次费用来复制同一套记录。只需描述每个工具，将其部署到现有的设备上，让共享平台保持各屏幕数据同步一致。经验法则：如果某个工具仅仅是在另一台屏幕上展示您的商品目录，它应该是一句提示词，而不是一次采购。准备好尝试了吗？立即开始使用构建器。