最近我做了一个疯狂的决定：完全靠AI，从零开发一套电商小程序。主要功能：后台权限管理，商品管理，订单管理，会员管理，营销管理等常用功能。技术栈：后端用 ThinkPHP8，后台前端用 Vue3 + Element Plus，小程序端用uniapp。主力开发工具是 Qoder ，Trae 国际版辅助。全程不手写一行核心逻辑，只负责提需求、检查、测试、提 bug。
目前开发完成了后台登录、权限管理和商品管理的功能，耗时一天这些功能基本跑通了，这个效率比人工快多了。但是过程也是踩坑无数，但也真正摸清了"AI 全栈开发"的边界和正确姿势。今天就把这套流程和两个大坑完整分享出来，如果你也想让 AI 成为你的超级提效外挂，这篇应该能帮你少走很多弯路。
技术栈与开发工具
后端：ThinkPHP 8
前端：Vue 3 + Element Plus + uniapp
数据库：MySQL + Redis
主力工具：Qoder + Trae
后端：ThinkPHP 8，多应用模式，API 接口，JWT 鉴权
前端：Vue 3 + Element Plus，管理后台 SPA
数据库：MySQL + Redis
之所以主力用Qoder是因为我发现Qoder经济模式挺耐用的，而且写的质量还可以，Trae 国际版消耗比较快，但是用来解决复杂逻辑和bug比较好，很多时候都是一次搞好。
Qoder 我主要用来做高频生成：建表语句、模型、控制器、前端页面。它的速度很快，基本我给一句"给商品模块生成完整的 curd，包含分类筛选和规格 SKU"，它半分钟就能甩出一整套代码。
我的开发流程：文档先行，模块化推进
把主要功能和要用的技术栈发给AI让它写出技术文档，我再让它调整了一些字段和业务规则。然后按照文档功能模块推进：
1. 让 AI 生成某个模块的所有文件（数据库迁移、后端逻辑、前端页面）
2. 我本地跑起来，手动测试功能
3. 发现问题直接截图或描述 bug，丢回给 AI 修复
4. 修完后我再次验证，通过则进入下一个模块
这个循环听起来简单，但如果没有前面的文档，AI 各模块之间就会各自为政，前后端接口对不上、字段命名不统一、权限模型反复推翻。文档就是 AI 的"需求锚点"。
大坑一：分层架构写着写着就丢了
第一个让我崩溃的问题是：服务层凭空消失。我最开始的设计就是清晰的分层：Controller → Service → Model。控制器只做参数接收和响应，业务逻辑全部在服务层。一开始 AI 确实给我生成了非常漂亮的分层代码，Service 类有模有样。但是写到商品分类curd的时候，它就在控制器里直接写业务了。我检查代码时发现，控制器里直接调用模型了。
这样的话每次写 CRUD 的提示词，要加上请严格按照多层架构生成代码：控制器只做请求参数接收、调用 Service 并返回响应；所有业务逻辑写在 Service 层；数据库操作通过模型完成。不要直接在控制器写业务。
不过，Qoder的提示词加强功能还是比较好用的，直接写生成CRUD的提示词，提示词加强优化后会直接加上请严格按照多层架构生成代码，包括前端页面都会有详细的描述，加强后的提示词挺好用。
大坑二：权限管理差点让我重写整个后台
整个项目里耗费我最多心神的，就是 RBAC 权限管理。这也是前前后后让 Qoder 和 Trae 国际版来回修改次数最多的模块，没有之一。
需求其实很标准：管理员、运营、客服等角色，每个角色分配不同菜单和按钮权限。比如"客服"能看到订单列表，但看不到"删除订单"按钮。
第一次，AI 把菜单表和权限表建好了，角色也能绑定菜单。但当我点开"菜单编辑"时，发现编辑菜单并不会同步更新权限表。也就是说，我把"商品管理"改名为"货品管理"，权限记录里依旧是旧的，角色那边的菜单直接就挂了。来来回回改了好多遍都改不好，最后还是用Trae来修复了。
这个模块完成后，我整个人都通透了。不是自己会写权限了，而是终于明白了：复杂业务你需要的是一个能跟你深度对话、理解"为什么"的 AI，而不只是"代码生成器"。
总结：用 AI 全栈开发的真实体验
用 AI 全栈开发，听起来像是"你说需求，AI 现场给你变出一个系统"。但真实的体验是：你需要成为 AI 的产品经理、架构师、测试工程师和教练。
AI 可以写 80% 的代码，但你要定义清楚那 80% 长什么样。剩下的 20% 疑难杂症，你必须能看懂代码、定位问题，再准确地让 AI 修。这个过程对人的要求，其实并不比纯手写低，只是把"写代码"换成了"审查代码、设计流程、沟通表达"。
