用AI编程实战：Laravel 12+Livewire 3打造多商户POS系统

当AI成为你的结对程序员

一位开发者用Google的AI编程工具，从零开始构建了一个功能完整的多商户POS（销售点）系统。技术栈选用Laravel 12、Livewire 3、MySQL和Tailwind CSS。整个过程展示了当前AI辅助开发的实际能力边界——它能做什么，以及哪里还需要人类介入。

这个系统最终实现了多商户管理、角色权限控制（管理员/收银员）、库存追踪、实时货币切换等功能，并且能够部署在VPS或共享主机上。开发者表示接下来还要加入支付网关、商品图片和原生移动端支持。

多商户POS系统指一套软件同时服务多个独立商户，每个商户拥有自己的商品、库存、员工和销售数据，且彼此隔离。与单商户系统相比，它需要多租户架构来保证数据不串户，并支持平台方统一管理商户入驻、审核与计费。这类系统通常面向餐饮、零售、连锁门店等场景，对权限控制和实时性要求较高。

技术栈方面，Laravel 12是PHP生态中最流行的全栈Web框架，提供ORM、队列、认证等基础设施；Livewire 3是其官方生态的响应式组件库，允许开发者用PHP写前端交互，无需大量JavaScript；MySQL负责持久化存储；Tailwind CSS提供原子化样式，加快界面搭建。这套组合适合快速构建中小型后台系统。

PRD文档：AI编程的"北极星"

这位开发者的核心方法论是：先写PRD，再让AI写代码。他创建了一个名为prd.md的Markdown文件，详细描述产品需求、技术栈、功能模块和业务规则，然后将其作为AI的持续参考文档。

"PRD是你用AI编程时最重要的文档之一，"他在视频中强调。这份文档定义了AI每次执行任务的边界——就像给一个能力很强但缺乏上下文的工程师一份详细的需求说明书。

技巧提示：在每次让AI执行修改之前，先预览它的变更计划，确认方向正确后再提交。这位开发者坚持"永远不让AI直接执行，我要先看它打算改什么"。

这种方法的效果在后期得到验证：当需要添加货币管理功能时，AI能够理解现有架构并生成一致的代码，而不是每次重新发明轮子。

PRD（Product Requirements Document，产品需求文档） 是产品开发中用于对齐需求的标准化文档，通常包含目标用户、功能列表、业务流程、数据规则和验收标准。在AI编程场景中，PRD的作用从“给人看”扩展为“给模型看”：它相当于一个持久化的系统提示，让AI在每次生成或修改代码时都能参考同一份事实来源，减少“上下文窗口”丢失导致的漂移。

与传统的口头需求或零散注释相比，结构化PRD能显著降低AI的幻觉概率，因为它明确限定了技术栈、模块边界和业务规则。开发者把PRD放在项目根目录并持续更新，本质上是在为AI构建一个可检索的“项目记忆”，这也是当前AI辅助开发中较为成熟的最佳实践之一。

多商户架构与角色权限设计

系统的核心设计是多租户架构。每个商户通过唯一的业务代码（如1001）登录，进入各自独立的管理后台。权限层级清晰分为三层：

• 平台管理员：创建和管理商户，审核KYC信息
• 商户管理员：管理产品、库存、团队和收银员，配置业务设置
• 收银员：仅能访问POS结账界面和销售记录

角色的边界在实现上被严格执行。收银员登录后看不到管理菜单，无法修改价格或库存数据，只能进行销售操作。商户管理员则拥有完整的业务控制权，包括增删团队成员。

这种设计确保了系统的安全性——一家商户的数据和操作不会影响到其他商户。

多租户架构是SaaS系统的核心设计模式，常见实现有共享数据库加租户ID字段、独立数据库、独立Schema三种。本文采用的多商户POS系统很可能属于共享数据库方案，通过商户业务代码在查询层自动过滤数据，从而在成本与隔离性之间取得平衡。

KYC（Know Your Customer，了解你的客户） 是金融与支付领域常见的合规流程，要求平台在商户入驻前核实其身份、营业执照和银行账户信息，以防范洗钱和欺诈。在POS系统中，平台管理员审核KYC意味着系统需要支持资料上传、审核状态流转和驳回原因记录等功能，这通常比单纯的增删改查更复杂，也是AI生成代码后需要人工重点验证的环节。

实测中暴露的问题与修复

开发者在演示过程中遇到了几个具体问题：

购物车清除时的模态框闪烁——当点击清空购物车时，一个确认弹窗反复出现又消失。开发者指出这不是响应式布局的问题，而是状态管理逻辑的缺陷。

侧边菜单在登录后未即时加载——需要刷新页面才能看到完整的导航菜单，说明认证状态和菜单渲染之间存在时序问题。

货币设置的位置不合理——最初货币配置被放在商户设置下的一个子页面中，开发者认为更好的做法是将其作为独立设置项，方便快速访问。

这些问题的共性是什么？都是UI状态管理和页面逻辑衔接层面的问题。AI生成的代码在架构层面是合理的，但在交互细节的边界情况上需要人工测试和修正。

AI编程的真实效率与局限

这位开发者有一句很坦诚的总结："五年前，这些东西我全是手动写的，遇到bug就去Stack Overflow翻帖子。现在AI确实让工作变简单了。"

但他也展示了AI的局限。虽然AI可以在几分钟内生成完整的项目骨架，包括数据库迁移、模型、控制器和Blade模板，但以下环节仍然需要开发者深度参与：

• 架构决策：多租户的实现方式、权限的粒度设计
• PRD编写：将业务需求转化为AI可理解的结构化文档
• 代码审查：每次AI修改前需要人工确认
• 调试与优化：运行时暴露的交互问题需要人工定位

实测发现，同一个项目使用AI后，开发时间主要消耗在了"描述需求→审查代码→测试→修正"这个循环上。AI替代的更多是代码输入环节，而非系统设计思考。

代码审查在AI辅助开发中尤为关键，因为大模型生成的代码可能表面可运行，却隐藏逻辑漏洞或安全风险。开发者坚持“先预览变更计划再执行”，实际上是在用人类判断力弥补AI对业务上下文理解的不足。

UI状态管理指前端组件对用户操作、数据变化和页面生命周期的响应逻辑。在Livewire这类框架中，状态往往保存在服务端组件中，前后端交互通过AJAX完成，因此容易出现“模态框闪烁”“菜单延迟加载”等时序问题。这类缺陷通常无法靠静态代码分析发现，必须在真实浏览器中反复操作才能暴露，也是当前AI编程最难自动覆盖的领域之一。

一个值得尝试的实践方向

这个案例最值得借鉴的不是某个具体技术点，而是**"PRD驱动+AI执行+人工审查"**的工作流。它解决了AI编程中最大的痛点：上下文丢失。有了持续存在的PRD文档，AI在后续的每次修改中都能保持对项目全貌的理解。

开发者计划在后续迭代中加入支付网关集成、商品图片上传、GitHub版本管理和商户订阅付费系统。这些功能将进一步检验AI在处理复杂业务逻辑时的表现。

对于想尝试AI编程的开发者，这个项目的启示是：与其纠结于"AI能不能替代程序员"，不如把精力放在如何编写高质量的需求文档上——那才是决定AI产出质量的关键变量。