用 Vibe Coding 写 100 个项目，我先把第 1 个定成了自研后台管理模板。这个项目的定位很明确：不是一个只能改改颜色、换换 Logo 的静态后台，而是把低代码和 AI 中心一起做进去的完整模板。如果你也想用对话式编码去搭一套能长期使用的后台，这篇文章会更适合你。全文不讨论某个在线平台的按钮怎么点，而是按实际落地顺序拆一遍：先定边界，再搭骨架，然后做低代码配置能力，最后接 AI 中心。
为什么第 1 个项目选后台管理模板，而不是算法 Demo 或创意网页，我的判断是：后台管理模板是绝大多数业务系统的底座。登录、用户、角色、菜单、列表、表单、权限这些能力，做任何一个内部系统都绕不开。用 Vibe Coding 来写第 1 个项目，最好选一个“复杂度够但边界清晰”的目标，后台模板正好满足。它既有大量重复页面，又有需要设计的数据模型和权限逻辑，还方便后续扩展。
低代码和 AI 中心这两个模块放在同一个模板里，很多人会担心步子迈得太大。实际上它们并不冲突。低代码负责降低页面的生成成本，AI 中心负责降低使用者的操作成本。一个面向配置过程，一个面向使用体验。模板把这两件事都做掉，后面对接具体业务时才有底气。
1. 第 1 个项目为什么必须是后台管理模板
1.1 后台管理模板是所有业务系统里复用率最高的底座
不管你要做的内容管理系统、订单管理系统、用户运营平台，还是一个简单的数据报表后台，底层能力都高度相似。登录和登出，用户列表，角色分配，菜单权限，数据列表，新增编辑表单，删除确认，分页筛选。这些功能如果每次从零开始写，工作量不大，但非常琐碎。
Vibe Coding 很适合处理这种“琐碎但规则明确”的工作。因为它不需要很强的发明能力，只需要把常见模式快速生成出来。相比直接复制一套开源模板，用对话式编码自研的好处是每一行代码的来源你都清楚，后续改动时不会被历史包袱卡住。
1.2 低代码和 AI 中心在模板里怎么分工
很多项目把低代码和 AI 中心当成两个独立功能，但实际落地时它们应该咬合在一起。低代码中心解决“页面怎么少写代码”的问题，AI 中心解决“操作怎么更省事”的问题。
低代码中心可以包含页面配置、表单配置、列表配置、接口配置。用户不需要改前端源码，就能在界面上动态生成一个“客户管理”页面。AI 中心可以包含对话面板、辅助生成和智能建议。用户可以直接用自然语言描述需求，AI 再把需求转成低代码配置。
我在做这个项目时，把 AI 中心设计成低代码中心的“生成前端”。比如在表单配置页里，用户输入“新增一个字段叫合同金额，类型是数字，必填”，系统会调用 AI 能力生成一段配置，再让渲染器把配置渲染成表单。这样两个模块就不是摆设，而是能配合起来完成闭环。
1.3 和直接复制模板相比，自研模板的实际差异
直接下载一套现成后台模板，最快几分钟就能跑起来。但使用现成模板会遇到几个问题：部分代码是压缩混淆过的，改起来费劲；内置组件过多，无用代码占空间；权限模型不一定符合你的业务；样式和交互风格不调整就很突兀。
用 Vibe Coding 自研，前期会慢一些，但每一块逻辑都更容易掌握。尤其是模板要长期使用的情况下，代码结构清晰比“跑起来快”重要得多。我建议把第一版定位成“最小可用闭环”，不要一上来就填充大量示例页面。
2. Vibe Coding 前的准备：环境、提示词和任务边界
2.1 选技术栈之前先定运行环境
Vibe Coding 不是把需求扔给 AI 就完事，前提条件越明确，生成结果越能直接运行。我在做这一版时先定了三个约束。
第一，本地开发环境要尽量轻量。我用的组合是前端 Vue 3 加组件库 Element Plus，后端 Node.js 加 Express，数据库先用 SQLite。这个组合不一定是性能最优解，但优点是依赖少、启动快、容易跑通。换成 React 加 NestJS，或者把数据库换成 PostgreSQL，核心思路也成立，只要在提示词里说清楚就行。
第二，要预留部署路径。开发时用 SQLite 方便，但长期部署最好切换成 MySQL 或 PostgreSQL。所以代码里数据库连接地址要集中配置，不写死在业务代码里。
第三，权限模型要先想清楚。后台模板最怕后期加权限，那时候改表、改接口、改菜单，牵一发动全身。第一版我保留了最基础的用户、角色、菜单三级结构，后续再扩展数据权限。
2.2 让 AI 理解项目的提示词怎么组织
提示词不要写成长篇作文，而要像一份技术需求简报。我的常规结构是这样：
- 项目定位：这是一个后台管理模板。
- 技术栈：前端用 Vue 3 和 Element Plus，后端用 Node.js 和 Express。
- 目录结构：前后端分离，前端 src/views 下按模块组织页面，后端 routes 下按资源组织接口。
- 核心页面：登录页、首页、用户管理、角色管理、菜单管理。
- 数据模型：用户、角色、菜单、配置表。
- 交互约定：列表页使用分页，删除操作必须有二次确认，表单校验使用统一规则。
- 不做的事：不做支付、不做多租户、不做复杂工作流引擎。
把这些写进提示词后，AI 生成的第一版代码就不会太偏。如果只用“帮我写一个后台模板”这种模糊描述，生成结果大概率是拼凑出来的思路，修改成本很高。
2.3 单次对话和分步对话怎么取舍
一句话生成整个项目，听起来很爽，但实际效果不稳定。项目规模一大，单次对话很容易出现上下文丢失，前面生成的模型后面就忘了。我的做法是分阶段推进。
第一阶段只生成项目骨架，验证能不能启动。第二阶段生成登录和权限。第三阶段生成用户、角色、菜单三个管理页面。第四阶段做低代码配置模块。第五阶段接 AI 中心。每一阶段结束都先看运行结果，确认没问题再进入下一个阶段。
这样做看似慢，实际比一次生成 3000 行代码再回头改要快得多。因为在分阶段对话中，AI 对每部分的理解更准确，报错时也容易定位。
2.4 任务边界：第 1 个项目不做什么
用 Vibe Coding 写项目，最大的风险不是写不出来，而是没有边界。第 1 个项目很容易越做越大。
所以我在开始之前就写了一张“不做清单”：不做支付功能，不做多租户隔离，不做拖拽式页面设计器，不做 AI 模型训练，不做移动端适配。这个清单不是永远成立，而是在第一版里主动砍掉。低代码中心先做配置驱动渲染，不做可视化拖拽；AI 中心先做对话和辅助生成，不做复杂 Agent。
边界清楚之后，有个好处是出现问题不会被“范围蔓延”拖住。不管 Vibe Coding 听起来多智能，第 1 个项目的核心目标就是跑通闭环。
3. 从空白工程到可运行的后台骨架
3.1 先用一句话生成项目骨架
我习惯用一条很短的起点提示词开始：
“生成一个前后端分离的后台管理模板，前端用 Vue 3 和 Element Plus，后端用 Node.js 和 Express，数据库用 SQLite，包含登录、用户、角色、菜单四个基本模块。”
第一版不要急着把所有功能都生成。启动起来之后，先看看目录结构是否符合预期，再去填业务逻辑。初次生成的代码通常会有一些多余内容，比如示例组件、示例图标、没有被调用的工具函数。可以先保留，等骨架稳定后再清理。
3.2 登录、用户、角色、菜单要在同一个流程里打通
这四个模块看着独立，实际互相依赖。用户要分配角色，角色要关联菜单权限，登录后要判断用户能访问哪些菜单。如果分开独立开发，很容易出现登录成功但菜单渲染不出来，或者用户管理里找不到角色选择框。
这里我的经验是：把数据模型先固定下来，再写接口，最后写页面。顺序不要反过来。AI 一旦先生成页面，再补数据模型，经常会漏字段。
表结构大致是这样：
- 用户表：id、用户名、密码哈希、昵称、状态、创建时间
- 角色表：id、角色编码、角色名称、状态
- 菜单表：id、父级 ID、菜单名称、路由路径、权限标识、排序
- 用户角色关联表：用户 ID、角色 ID
- 角色菜单关联表：角色 ID、菜单 ID
登录接口返回 token 和用户信息，前端把菜单数据缓存起来，根据权限生成侧边栏。这是一套常见做法。
3.3 把数据模型和接口先固定下来
数据模型固定后，接口命名也尽量在一个文件里统一维护。我这一版保留了一组基础接口：
- POST /api/auth/login 登录
- POST /api/auth/logout 登出
- GET /api/auth/profile 获取当前用户信息
- GET /api/user/list 用户分页列表
- POST /api/user/save 新增或编辑用户
- DELETE /api/user/delete 删除用户
- GET /api/role/list 角色列表
- POST /api/role/save 新增或编辑角色
- GET /api/menu/tree 菜单树
- POST /api/menu/save 新增或编辑菜单
为什么要先把接口固定下来？因为 Vibe Coding 在生成页面时，会默认前端应该调用什么接口。如果后端接口没有提前约定，AI 很容易生成一个后端不存在的路径，前端请求就会 404。让提示词里包含接口清单，能大量减少这种问题。
3.4 本地启动后第一轮验证看什么
后端先启动，确认端口没被占用，SQLite 能正常初始化。前端启动后，第一件要做的事不是点功能，而是本地登录一次。
我验证时使用一个小样例账号，登录后看三件事：第一，token 是否正常返回；第二，用户信息里是否能拿到角色；第三，菜单树是否能按角色渲染出来。如果这三步都正常，说明骨架是通的。这时候再创建几个测试用户，测试角色不同导致的菜单差异。
如果登录后页面空白，不要急着让 AI 重写整个登录页。先打开浏览器控制台，看接口返回了什么，看是登录失败、token 解析失败，还是菜单数据为空。大部分问题都出在返回结构和前端预期不一致。
4. 把“低代码中心”做进后台
4.1 低代码中心的本质是配置驱动
很多后台模板把“低代码”做成了页面设计器，需要处理拖拽、缩放、组件对齐，复杂度很高。我的第一版没有做拖拽，而是做了一个更稳定的方案：配置驱动。
简单说，就是不用前端写死页面，而是由一条 JSON 配置描述页面长什么样。后端把配置存入数据库，前端读取配置后动态渲染。这样做的好处是：不需要设计复杂的可视化编辑器，也能实现“新增一个页面只改配置不改代码”的目标。
低代码中心这一版包含三种配置：表单配置、列表配置、页面配置。表单配置负责“新增和编辑弹窗”，列表配置负责“表格列、搜索项、操作按钮”，页面配置负责“把表单和列表组合成一个完整页面”。
4.2 表单配置和列表配置分开落地
表单配置的字段就是表单渲染元信息。一个字段通常包含这些属性：
- 字段名，对应后端字段名称
- 组件类型，下拉框、输入框、数字框、日期选择器等
- 标签，界面显示名称
- 校验规则，必填、最大长度、数字范围
- 默认值，新增时的默认内容
- 是否显示在新增、编辑场景
列表配置的字段包括列配置、搜索配置和操作配置。列配置决定表格显示哪几列，搜索配置决定顶部筛选区有哪些控件，操作配置决定行内按钮是编辑、删除还是其他扩展操作。
这两个配置分开维护，是因为它们的渲染位置和逻辑完全不同。放一起容易让配置结构变得臃肿。
4.3 一个低代码页面的配置结构示例
下面是一个简化的“客户管理”页面配置结构，作用不是直接能跑，而是帮助理解低代码配置长什么样。
{ "pageCode": "customer_manage", "pageName": "客户管理", "listConfig": { "api": "/api/customer/list", "columns": [ { "field": "name", "label": "客户名称" }, { "field": "contact", "label": "联系人" }, { "field": "level", "label": "客户等级" } ], "searchItems": [ { "field": "name", "label": "客户名称", "component": "input" } ] }, "formConfig": { "api": "/api/customer/save", "fields": [ { "field": "name", "label": "客户名称", "component": "input", "required": true }, { "field": "contact", "label": "联系人", "component": "input" }, { "field": "level", "label": "客户等级", "component": "select", "options": ["A", "B", "C"] } ] } }前端只需要一个通用渲染器，读取这个结构，就能生成搜索区、表格区、分页区和新增编辑弹窗。后端接口只要已经存在，页面就能跑起来。
4.4 用一条配置生成一个完整页面来验证效果
骨架完成后，我做的第一轮验证是在“页面配置”里新建一个“客户管理”页面，把上面的配置填入数据库。然后刷新左侧菜单，确认新页面出现，再点击新增，填写几个字段，保存后列表能正常显示。
这里要特别注意接口和配置字段的对应关系。如果新增成功但列表为空，先看保存的数据是否写入了同一张表。如果列表能显示但编辑回显失败，检查表单配置里是否缺少主键字段的回显逻辑。
对 Vibe Coding 来说，低代码中心是一个非常好的验证场景。因为它不是一次性生成某个固定页面，而是生成一个“能够按配置生成任意页面的渲染器”。渲染器一旦写好，后续新增业务页面就进入低代码模式，价值立竿见影。
5. 把“AI 中心”做进后台
5.1 AI 中心解决的是后台使用体验问题
AI 中心放在后台里，不是只为了展示一个聊天窗口。它的核心价值是让使用者在操作过程中少跳转、少查找、少复制粘贴。例如用户想知道“最近登录失败的用户有哪些”，后台里可能要先找日志、再看用户状态、再理解数据，而 AI 中心可以直接把问题转成查询条件或 SQL，返回结果。
这一版我把 AI 中心拆成三个入口：对话面板、辅助生成、操作建议。
对话面板是自由的问答入口，适合查资料、解释报错、生成文案。辅助生成和低代码中心联动，可以把自然语言转成表单或页面配置。操作建议则更多依赖后台的使用数据，例如发现某个用户连续登录失败，可以自动提示管理员关注账号安全。
5.2 对话面板、辅助生成和操作建议怎么落地
对话面板的核心是会话管理。用户发送一个问题，系统把问题和历史会话一起发给模型，再把回复返回。为了不丢失上下文，会话记录要保存到数据库。
辅助生成要定义好输出格式。例如输入“生成一个员工培训管理页面，包含培训主题、培训时间、讲师、参训人数”，AI 应该返回一个符合低代码中心要求的配置结构。这一步不能靠模型自由发挥，否则渲染器无法识别。比较好的方式是先给模型一段 JSON Schema 或示例，让它按照模板填充。
操作建议可以做成定时任务或主动触发。管理员进入后台时，如果系统检测到异常登录、长时间未处理的任务等，可以生成一条提示。
5.3 上下文和权限怎么处理
AI 中心接入到后台，最大的坑是权限。如果不加控制，任何用户都能通过 AI 中心读取到越权数据。第一版我做了两个约定。
第一，AI 中心请求时要带上当前用户信息。不管用外部模型 API 还是自建模型服务，都不能让 AI 脱离用户上下文独立查询数据。第二，AI 生成的查询和操作建议要经过后台权限过滤。
举个实际例子：普通用户问“导出一份全量用户名单”，系统不能直接生成一条 SELECT * FROM users 的语句。要先判断当前用户是否有导出权限，再决定是否执行。这个流程在代码里要明确写出来，不能完全托付给模型判断。
5.4 AI 中心接入方式的选型
接入 AI 能力有几种常见路径。
直接调用外部模型 API 是最快的方式，但要注意模型服务地址、接口 key、计费方式和数据隐私。内部系统如果只做简单问答，这种方式成本可控；如果频繁请求，要关注响应速度和费用。
自建模型服务更可控，适合对数据隐私要求高的场景。但需要额外准备推理环境和模型资源，低配置机器上运行效果会有明显差距，不建议一上来就追求本地大模型。
还有一些在线 Vibe Coding 平台内置了 AI 集成能力，方便快速验证。但如果你要长期部署，建议把接入层单独封装成一个接口模块，避免和平台绑定太深。这样后续替换模型服务时，只需要改一个内部适配层，不用动整个后台。
6. 性能、批量使用和发布判断标准
6.1 低代码渲染性能怎么看
低代码模式的短板通常是渲染效率。每打开一个页面，前端都要多一次配置请求，再动态渲染组件。如果每一条配置都实时解析，页面会变慢。
判断低代码性能不能只看一时感觉，要落到三个指标：
- 页面配置加载耗时
- 列表首屏渲染耗时
- 连续新增编辑操作是否卡顿
第一版我不建议做太重的优化。先把配置接口加一个缓存，列表配置和表单配置如果变化频率低，可以缓存到前端。只有当配置数量明显增大、打开页面出现明显延迟时，再考虑组件级缓存、虚拟滚动或按需渲染。
6.2 AI 中心运行时需要关注哪些资源
AI 中心的资源占用比普通后台功能高很多。尤其是有对话能力后，一个请求可能需要数秒甚至更久。这个体验问题和并发问题要在第一版就考虑。
单用户验证时，一个问题返回 10 秒可能还能接受。但多人同时使用时，后端如果不做超时控制，很容易拖垮进程。我建议在 AI 中心接口里显式设置超时时间，比如 30 秒，超过就返回错误，而不是让请求一直挂着。
另外，AI 请求属于外部不可控调用。如果模型服务不稳定，不能让一个异常请求影响整个后台。所以接入层要做好错误捕获，返回一个可读的提示，不能直接抛出一堆底层异常。
6.3 第 1 个项目要不要直接做成生产级
这个模板不一定第一天就达到生产级。第 1 个项目的目标是把闭环跑通。所谓闭环，就是“登录进入后台，用低代码中心配置一个页面，通过 AI 中心辅助生成配置，最后把页面发布出来”。
如果你打算把这个模板用于团队内部系统，我可以给你一个改进顺序：先补操作日志和登录日志，再补数据备份，然后补接口限流，最后再考虑多租户和复杂权限。日志是第一个要补的，因为没有日志，生产环境出问题后排查成本非常高。
7. 实际踩坑记录与排查顺序
7.1 最常见的几类问题
这一轮做完，遇到的很多问题并不是模型能力不够，而是上下文和约定没有对齐。
第一类是依赖版本冲突。AI 生成代码时，只会写“安装依赖”，但不会自动保证组件库版本和 Vue 版本完全兼容。启动时报语法错误或样式丢失，先看版本号，不要先怀疑代码逻辑。
第二类是接口路径不一致。前端生成后调用 /api/user/list，后端实际定义的是 /api/users/list。这类问题很隐蔽，因为页面能正常加载，只是请求 404。排查时优先看 Network 里的请求地址。
第三类是权限校验失效。登录后能进系统，但刷新页面就回到登录页。这通常是 token 存储或路由守卫逻辑出了问题。Vibe Coding 生成的路由守卫经常漏掉某些页面。
第四类是低代码页面渲染为空白。这种问题九成是配置结构不匹配。比如渲染器期待 fields 数组，但配置里写成了 fieldList。用 JSON 格式化工具比对一下就会很清晰。
7.2 先日志、后参数、再问 AI
排查顺序建议固定下来。
第一步看现象：是报错、卡住、还是无输出。如果报错，看后端控制台和前端控制台。如果卡住，看网络请求和进程资源占用。如果无输出，先确认输入和输出目录是否正确。
第二步看参数：接口入参、返回结构、配置项名称。很多时候 AI 生成的前端已经成功调用接口，但少传了一个参数，导致后端拿到的数据不完整。
第三步再回去问 AI。而且不要只贴一句“报错了”，要把控制台信息、请求参数、返回结果一起贴进去。比如“调用 /api/customer/save 时返回 500，后端日志显示 field level 不能为空，但前端已经传了 level 值。请检查后端接收参数的字段名是否匹配。”像这样描述，AI 才能快速定位。
7.3 模板后续迭代时保留哪些约定
能长期用下去的后台模板，一定要留下“约定文档”。我在项目根目录建了一个 docs 文件夹，里面记录三件事：接口命名规范、低代码配置结构、AI 中心对接方式。
接口命名规范是为了让 AI 后续生成时保持一致。低代码配置结构是要让后续新增页面都知道字段怎么填。AI 中心对接方式是为了防止后续换模型服务时无从下手。
文档不需要很长，但要让 AI 也能看懂。这样一来，下个项目继续用同一个模板时，我可以直接告诉 AI“按 docs 里的配置格式生成页面”，不用重新解释一遍。
第 1 个项目跑通之后，我对这套操作方式最大的感受是：Vibe Coding 的上限不在模型本身，而在于任务拆解、上下文约定和验证节奏。后台管理模板是个特别适合入门的项目，因为它边界清晰，每个模块都能独立验证，遇到问题也能快速定位。这个系列刚写第一个，后面还会有更多项目。我会继续把过程里踩过的坑和验证过的方法整理出来，给同样在尝试 Vibe Coding 的人做个参考。
