用AI从零搭建手机店POS系统：Laravel实战

一位YouTube创作者用AI编程工具从零构建了一套面向手机零售店的POS管理系统，完整演示了从需求定义到功能落地的全过程。这个项目不仅展示了AI辅助编程的实际能力，也引发了关于"工具与技能孰重孰轻"的讨论。

项目概览：手机店专属POS系统

这套系统的核心定位是服务单一手机零售门店，帮助店主管理日常销售、库存和人员权限。从演示来看，系统包含登录入口、老板仪表盘、收银员工作台、库存管理员面板等多个角色视图，具备典型的POS功能模块。

项目初始化

创作者在视频开头展示了系统的完整界面，包括产品图片展示、购物车结算、小计与合计计算等。值得一提的是，产品图片是由AI工具（nano banana）自动生成的，而非手动上传，这为快速搭建演示环境提供了便利。

POS（Point of Sale，销售点终端）系统 是零售门店用于完成交易结算的核心软件，通常涵盖商品扫码或选择、购物车管理、金额计算、支付处理、小票打印，以及与库存、会员、报表等模块的联动。现代 POS 已从早期单一的收银机演变为集销售、库存、人员权限和经营分析于一体的管理系统。

对手机零售店而言，POS 还需处理 IMEI/序列号追踪、以旧换新、配件搭售等场景。本文所述系统聚焦于门店日常运营，通过角色视图划分把收银、库存、供应商管理等职能拆分开来，属于典型的轻量级自建 POS 方案，适合单店或小规模连锁使用。

角色权限设计：分权管理的核心逻辑

系统最突出的设计亮点是完整的基于角色的访问控制（RBAC）。老板登录后可以看到全部菜单和功能，而收银员登录后仅能访问销售相关的界面，无法触及库存管理、供应商设置等敏感模块。

角色权限演示

这种设计在实际门店运营中非常实用——收银员专注于结账和退货，库存管理员负责商品入库和调整，各司其职的同时也形成了天然的审计隔离。创作者在视频中多次强调，这种权限隔离是系统安全性的基础。

RBAC（Role-Based Access Control，基于角色的访问控制） 是一种主流的权限管理模型，其核心思想是：不直接把权限授予用户，而是先定义“角色”，将权限绑定到角色上，再把角色分配给用户。这样当门店新增员工或调整岗位时，只需更改其角色，无需逐个修改权限配置。

RBAC 通常包含三个关键概念：用户（User）、角色（Role）和权限（Permission）。在本项目的场景中，老板、收银员、库存管理员即三个角色，每个角色对应一组可访问的菜单和操作（如“创建销售单”“调整库存”“修改供应商”）。更复杂的 RBAC 还支持角色继承和权限粒度控制（如“只能查看”与“可编辑”之分）。相比给每个用户单独配置权限的 ACL 模型，RBAC 在中小型系统中更易维护，也更符合零售门店岗位分明的组织形态。

技术选型：Laravel + MySQL + Tailwind CSS

技术栈方面，该项目采用了Laravel 12作为后端框架，MySQL作为数据库，Tailwind CSS负责前端样式。创作者特别提到，没有使用Supabase等热门BaaS服务，而是回归传统MySQL方案。

开发过程

他的观点是：并非每个项目都需要Supabase，MySQL完全够用，而且后续可以平滑迁移到PostgreSQL。对于预算有限的小型项目，这种方案可以部署在共享主机或VPS上，成本更加可控。需要注意的是，由于Laravel依赖PHP环境，Vercel并不适合此类项目部署。

Laravel 与 BaaS 的区别：Laravel 是一个基于 PHP 的开源 Web 应用框架，提供路由、ORM（Eloquent）、认证、队列、迁移等一体化后端能力，开发者需要自行准备服务器和数据库环境。而 Supabase 属于 BaaS（Backend as a Service），它把数据库、认证、存储、实时订阅等打包成托管服务，开发者通过 SDK 直接调用，无需管理服务器。

两者取舍的核心在于控制权与成本：BaaS 上手快、免运维，但存在供应商锁定、按量计费可能随规模上涨、数据存放在第三方等问题；Laravel + MySQL 这类自托管方案则需要自己维护服务器，但对数据、部署位置和长期成本拥有完全掌控，且可迁移到任意支持 PHP 的主机。对于预算有限、数据敏感或希望长期自主运营的小型门店系统，自托管方案往往更具性价比。

AI编程工具之争：工具重要还是技能重要？

视频中一个颇有争议的观点是：创作者认为当前AI编程领域"讨论哪个工具最好"的风气有些跑偏。他使用了Google的Antigravity作为主要开发工具，但同时表示Claude Code、Codex、Lovable、Casa等工具各有千秋。

开发流程

"It's all about the skill, not really the tool you use."（关键在于技能，而非你使用的工具。）

他认为，无论是用哪个AI编程助手，核心能力在于开发者能否清晰地定义需求、编写有效的提示词（prompt），以及快速定位和修复AI生成代码中的问题。视频中确实出现了销售模块报错的情况，创作者通过截图反馈给AI工具后成功修复，这本身就验证了"人机协作"的工作模式。

提示词工程（Prompt Engineering） 指通过精心设计输入给大模型的指令，以获得更准确、更符合预期的输出。在 AI 辅助编程中，有效的提示词通常包含：明确的目标（要实现什么功能）、上下文（技术栈、现有代码结构）、约束条件（不要引入哪些依赖、遵循什么规范）以及验收标准（怎样算完成）。

除了单次提示，实践中还常用“需求文档引用”的方式——先把完整 PRD 作为上下文提供给 AI，让每次代码生成都锚定同一份基准，从而减少前后不一致。当 AI 生成的代码出错时，把报错信息或界面截图作为新提示反馈回去，让模型自行诊断修复，构成“生成—验证—反馈”的迭代循环。提示词工程并非万能技巧，它的上限取决于开发者对问题本身的理解深度，这也是“技能比工具更重要”这一观点的技术依据。

开发中的实际问题与解决

项目并非一帆风顺。演示过程中出现了销售功能报错、部分图片未生成、分页缺失等问题。创作者的处理方式值得参考：将错误截图粘贴回AI对话中，让工具自行诊断和修复。

另一个值得关注的实践是：他提前用ChatGPT生成了完整的产品需求文档（PRD），然后在AI编程工具中引用该文件，确保每次代码生成都围绕统一的需求基准。这种做法可以有效减少AI"跑偏"的概率。

局限与后续计划

当前版本仍处于第一阶段，支付网关尚未集成，部分内部链接和图片存储权限需要进一步调试。创作者计划在后续视频中完善支付功能、进行安全审查，并演示如何将系统部署到共享主机和VPS上。

此外，他还表示会尝试用Python、React Native等技术栈重新实现类似功能，探索不同技术路线下AI辅助开发的效率差异。

对开发者的启示

这个项目的价值不仅在于展示了一个可运行的POS系统，更在于呈现了AI辅助开发的真实工作流：需求文档先行、提示词工程、错误反馈循环、多工具灵活切换。对于想尝试AI编程的开发者来说，与其纠结哪个工具更强，不如先把手头的业务需求拆解清楚——工具会迭代，但结构化思维能力始终是核心竞争力。