Vibe Coding 是最近一段时间里编程圈讨论度最高的话题之一。很多人把它理解成“跟 AI 聊几句一个系统就出来了”但真正上手做过项目的人会明白事情远没有那么简单。Vibe Coding 改变的不是“代码由谁来写”而是开发者的注意力应该放在哪里你不再需要逐行敲样板代码但必须更清楚自己的系统要做什么、边界在哪里、出了问题之后从哪里开始定位。它更像是一种“意图管理 AI 生成 人工审查”的协作模式而不是把键盘丢给 AI 就算完事。这篇文章是“挑战 Vibe Coding 写 100 个项目”系列的第一篇。我选的这个项目——自研后台管理模板恰好是 Vibe Coding 最能体现价值、也最容易踩坑的一类工程目录结构多、重复页面多、权限模型绕、后续扩展需求多。它不像玩具 Demo 那样没有工程意义也不像大型业务系统那样复杂到不适合新工具介入。做完这个项目你会同时获得三样东西一套可以复用的后台管理系统骨架、一套配置驱动的低代码页面方案、一个可以嵌入任意后台的 AI 中心模块。接下来我会把“后台管理模板 低代码 AI 中心”三件事拆开讲为什么值得自研后台模板低代码模块怎么落地AI 中心该怎么接以及最终如何运行、验证和排错。读完这篇文章你既能得到一个可以直接照着跑的项目结构也能理解 Vibe Coding 在真实工程里的边界在哪里。1. Vibe Coding 到底解决了什么问题1.1 一个容易被低估的变化很多讨论把 Vibe Coding 简化成“AI 写代码”这个概括并不准确。传统开发模式下程序员的大部分精力消耗在需求翻译、页面布局调整、接口字段对接和重复 CRUD 代码上。Vibe Coding 模式下AI 负责把自然语言转化成代码并且可以根据反馈持续修改开发者的核心工作变成把需求描述清楚、判断 AI 输出是否符合预期、把关工程质量。这里真正容易踩坑的地方是很多人在第一步“描述需求”时就翻车了。Vibe Coding 不是魔法它要求你脑子里先有一个足够清晰的目标。比如你说“帮我做一个用户管理页面”生成出来的东西大概率很粗糙但如果你说“做一个用户管理页面支持按用户名和状态筛选表格列包含用户名、邮箱、状态、创建时间状态用标签展示新增和编辑用弹窗表单”AI 生成的代码质量会明显不同。所以Vibe Coding 的准确含义是开发者负责定义“要什么、不要什么、边界在哪”AI 负责把这种定义快速变成可运行的代码。它降低的是“从需求到代码”的翻译成本而不是“从想法到架构”的设计成本。1.2 适合解决什么不适合解决什么从实际工程经验来看Vibe Coding 在下面几类场景中价值最大后台管理系统、内部工具、运营平台。数据看板、报表系统、信息录入类系统。原型验证、快速 Demo、活动页面。工具类小应用、脚本、一次性数据迁移脚本。这几类场景的共性是业务逻辑相对常规页面和接口模式重复度高技术栈可以固定用户的容忍度也比较高。AI 生成这类代码的准确率已经相当不错人工审查成本也低。反过来下面几类场景不建议直接靠 Vibe Coding 生成核心代码高并发基础组件、消息队列、分布式事务。支付、财务、风控等强合规系统。涉及复杂状态机和强一致性的业务模块。安全边界极其严格的基础设施。这些系统的问题不在于 AI 写不好代码而在于风险控制、边界设计和异常处理需要极高的领域经验。AI 生成的“看起来正常”的代码可能在极端情况下才暴露出问题。对这类场景AI 可以辅助生成测试用例、解释代码、生成文档但核心代码仍然需要资深工程师逐行把关。1.3 对这个项目的影响后台管理模板正好落在 Vibe Coding 的甜区里。它的功能是高度可预测的登录、权限、用户管理、菜单配置、CRUD 页面、AI 对话。每个模块的技术模式都很固定但数量多、组合复杂非常适合用 AI 快速搭建骨架再由人工去补充工程细节。在后面的项目设计中我会坚持一个原则AI 参与生成和迭代但最终代码必须经过人工 review 和运行验证。这也是整个“100 个项目”系列的核心方法。2. 为什么要自研后台管理模板2.1 开源模板无法覆盖的最后一公里市面上的后台管理模板并不少vue-element-admin、Ant Design Pro 这些都是成熟方案。那为什么还要自研一个一个容易被忽略的事实是开源模板解决的是“页面外观和基础功能”问题但每个团队真正需要的是一个能承载业务扩展点的骨架。开源模板通常会带大量你可能用不到的页面、组件和规范接进来之后要么删东西要么被牵着走。更重要的是当你想在模板里加入定制化的低代码能力和 AI 中心时对开源模板的内部改造成本往往比自己写一个高得多。自研模板不会比开源模板更“全”但它会更“准”。它沉淀的是团队自己的技术约定、组件规范和扩展方式。前面提到的低代码和 AI 中心正是开源模板很少内置、又最需要深度定制的两个能力这也是选择自研最充分的理由。2.2 自研模板真正沉淀的是“开发约定”后台管理系统的技术难度不高真正的复杂度在于规范的一致性。一个几十人的团队如果没有统一的页面书写方式就会出现十个人写十种列表页、每个人都有自己的请求封装和权限判断逻辑。自研模板最重要的产物不是页面而是下面这些开发约定页面必须走统一的配置渲染器还是可以自由写页面权限标识如何命名、如何控制到按钮级别接口请求的错误处理怎么统一API Key 和敏感配置放在哪一层新增一个业务模块时需要改哪些文件当这些约定在模板里固化下来之后新成员上手速度、代码 review 效率、后续维护成本都会明显改善。这才是自研模板的真正价值。2.3 什么情况下不要自研这里也要说清楚自研的边界。如果团队已经有了稳定使用的后台模板或者业务系统已经上线多年最好的选择是在现有系统上扩展而不是推倒重来。自研有一个隐性成本模板本身也需要维护包括升级依赖、修复 bug、补充文档。如果只是为了“看看别人的代码”或者“不想用开源模板”这种理由自研是不划算的。所以这篇文章给自研模板设定的前提是你要么正在从零开始一个新项目要么现有的后台系统已经需要大规模重构。在这两种前提下先搭一个带有低代码和 AI 能力的骨架再让业务在骨架上生长效率会明显更高。3. 项目定位与功能规划3.1 项目定位这个项目命名为 vibe-admin定位是一个面向中小团队的后台管理系统基础模板。它的目标不是做成一个功能堆砌的大而全平台而是提供“常见后台都需要的那部分基础能力 两个增值模块低代码 AI”。项目结构上分为前端和后端两个部分前端负责页面渲染和交互后端负责 REST API、鉴权和 AI 代理。前后端分离可以让 AI 在生成前端页面时不用关心服务端细节也让后续替换某个模块的成本更低。3.2 功能模块清单模块核心功能说明登录认证账号密码登录、Token 管理后端签发 Token前端请求头携带权限管理用户、角色、菜单、按钮权限菜单权限控制侧边栏和路由按钮权限控制操作用户管理用户 CRUD、状态启停、角色分配用于演示低代码配置也是系统基础数据系统配置基础参数配置、字典管理一些通用下拉项做成字典避免硬编码低代码中心配置驱动的列表、表单、详情页面新增 CRUD 页面时不用写重复组件代码AI 中心对话工作台、内容生成、数据解读服务端代理大模型 API前端统一接入3.3 核心设计原则这个项目在设计上坚持三个原则第一页面配置优先。能通过配置描述的业务页面尽量不写重复代码。低代码渲染器会统一消耗配置保证页面风格一致。第二AI 能力“服务端代理”。所有大模型 API 调用都在后端完成前端只跟自己的后端交互。这样既不暴露敏感密钥也方便后续做调用日志和成本统计。第三可替换、可扩展。所有模块都通过明确的接口边界连接后续如果要把 Node.js 后端换成 Java Spring Boot或者把对话模型换成另一个厂商的服务改动范围都是可控的。4. 技术选型与整体架构4.1 前端技术栈前端选择 Vue 3 TypeScript Vite Element Plus Pinia Vue Router。这个组合在国内社区普及度高、资料多而且 Vite 的启动和热更新速度快很适合 Vibe Coding 场景下的频繁迭代。Element Plus 组件能力完整表格、表单、弹窗、分页这些后台高频组件都有现成实现能省去大量手写 UI 的时间。TypeScript 不是可有可无的选择。低代码配置的结构复杂没有类型约束很容易出现“配置写错一个字段页面直接白屏”的问题。给页面配置定义好接口类型在编译阶段就能拦住大部分低级错误。4.2 后端技术栈后端选择 Node.js Express简单直接。后台模板的接口以 CRUD 为主Express 足够胜任做 AI 代理时Node.js 的非阻塞特性也很适合转发流式响应。如果团队以 Java 为主完全可以把这一层替换成 Spring Boot因为低代码配置和 AI 代理的思路是一致的变的只是语言和框架。数据存储环节可以用 MySQL也可以先用 SQLite 本地文件撑起开发环境。这个项目里我建议开发阶段先用 SQLite减少环境依赖项目跑通后再切换到 MySQL。4.3 项目目录结构建议项目分成web和server两个目录前端后端互不干扰。vibe-admin/ ├── web/ │ ├── src/ │ │ ├── api/ # 接口请求封装 │ │ ├── assets/ # 静态资源 │ │ ├── components/ │ │ │ └── lowcode/ # 低代码渲染器组件 │ │ ├── layout/ # 后台布局框架 │ │ ├── router/ # 路由配置 │ │ ├── stores/ # Pinia 状态管理 │ │ ├── views/ │ │ │ ├── admin/ # 系统管理页面 │ │ │ ├── lowcode/ # 低代码测试页面 │ │ │ └── ai/ # AI 中心页面 │ │ ├── utils/ # 请求、鉴权等工具 │ │ ├── App.vue │ │ └── main.ts │ ├── package.json │ └── vite.config.ts └── server/ ├── src/ │ ├── routes/ # 路由定义 │ ├── services/ # 业务逻辑与 AI 服务 │ ├── middlewares/ # 鉴权、日志等中间件 │ ├── config/ # 配置读取 │ ├── app.js │ └── index.js ├── .env.example └── package.json这个结构的用意是让每一个新功能都有明确的落位。后续用 Vibe Coding 新增业务模块时我会先告诉 AI 这个目录约定再让它基于现有代码风格生成新内容。4.4 一次页面请求的完整调用链以用户管理列表为例完整链路是前端登录后拿到 Token访问用户管理页面时低代码渲染器读取该页面的配置pageConfig根据配置中的接口地址发起请求请求头携带 Token后端经过鉴权中间件后从数据库查询用户数据并返回最后渲染器把返回的数据渲染成表格。整个链路中页面代码不关心业务字段的具体含义只按照配置去渲染和请求。这意味着新增一个类似页面时核心工作只剩下“编写一份配置”。5. 低代码模块配置驱动 CRUD 页面5.1 低代码在这里的准确含义低代码是一个被用滥的词这里需要明确它的边界。vibe-admin 里的低代码不是拖拽式搭建平台而是一种“配置驱动页面”的实现思路用一份 JSON 结构描述页面长什么样、数据从哪里来、操作触发什么逻辑由统一的渲染器去消费这份配置。这种做法的价值非常实际。后台系统里 70% 以上的页面是“搜索区 表格 操作按钮 弹窗表单”的组合如果每个页面都手写一遍会产生大量重复代码。把重复的部分提取成渲染器之后新页面的开发成本会大幅降低页面风格也更容易保持一致。它不擅长处理的是高度定制的页面比如复杂的数据可视化大屏、带有特殊交互的流程编排页面。这类页面仍然需要手写组件低代码只负责在外层框架里预留一个“自定义组件”的出口。5.2 pageConfig 配置结构先看一份完整的用户管理页面配置{ pageName: 用户管理, api: { list: /api/user/list, create: /api/user/create, update: /api/user/update, delete: /api/user/delete }, searchFields: [ { prop: username, label: 用户名, component: Input, placeholder: 请输入用户名 }, { prop: status, label: 状态, component: Select, options: [ { label: 启用, value: 1 }, { label: 禁用, value: 0 } ] } ], tableColumns: [ { prop: username, label: 用户名, width: 120 }, { prop: email, label: 邮箱, width: 200 }, { prop: status, label: 状态, component: Tag, map: { 1: success, 0: info } }, { prop: createdAt, label: 创建时间, width: 180 } ], toolbarButtons: [ { key: create, label: 新增用户, type: primary } ], rowActions: [ { key: edit, label: 编辑 }, { key: delete, label: 删除 } ], formFields: [ { prop: username, label: 用户名, component: Input, rules: [{ required: true, message: 请输入用户名 }] }, { prop: email, label: 邮箱, component: Input, rules: [{ type: email, message: 邮箱格式不正确 }] }, { prop: status, label: 状态, component: Select, options: [{ label: 启用, value: 1 }, { label: 禁用, value: 0 }] } ] }这份配置描述了一个常规 CRUD 页面需要的所有关键信息数据接口、搜索条件、表格列、工具栏按钮、行内操作和表单字段。它没有大量连缀的修饰词结构很直接。新增一个类似的业务页面时只需要复制这份配置把字段名和接口地址改掉。5.3 通用列表页渲染器有了配置之后需要一个组件来“执行”这份配置。核心逻辑是根据pageConfig.searchFields渲染搜索表单根据tableColumns渲染表格列根据api.list发起数据请求再把返回结果绑定到表格上。下面是一个可运行的ListRenderer.vue核心实现!-- 文件路径web/src/components/lowcode/ListRenderer.vue -- template div classlist-renderer el-card el-form :inlinetrue :modelqueryParams el-form-item v-forfield in pageConfig.searchFields :keyfield.prop :labelfield.label el-input v-iffield.component Input v-modelqueryParams[field.prop] :placeholderfield.placeholder || 请输入 clearable / el-select v-else-iffield.component Select v-modelqueryParams[field.prop] :placeholderfield.placeholder || 请选择 clearable el-option v-foropt in field.options :keyopt.value :labelopt.label :valueopt.value / /el-select /el-form-item el-form-item el-button typeprimary clickhandleSearch查询/el-button el-button clickhandleReset重置/el-button /el-form-item /el-form /el-card el-card div classtoolbar el-button v-forbtn in pageConfig.toolbarButtons :keybtn.key :typebtn.type || default clickemit(toolbar, btn) {{ btn.label }} /el-button /div el-table v-loadingloading :datatableData border el-table-column v-forcol in pageConfig.tableColumns :keycol.prop :propcol.prop :labelcol.label :widthcol.width template #default{ row } el-tag v-ifcol.component Tag :typecol.map ? col.map[row[col.prop]] : info {{ row[col.prop] }} /el-tag template v-else{{ row[col.prop] }}/template /template /el-table-column el-table-column v-ifpageConfig.rowActions pageConfig.rowActions.length label操作 width160 template #default{ row } el-button v-foraction in pageConfig.rowActions :keyaction.key link typeprimary clickemit(row-action, { action, row }) {{ action.label }} /el-button /template /el-table-column /el-table el-pagination v-model:current-pagequeryParams.pageNum v-model:page-sizequeryParams.pageSize :totaltotal layouttotal, prev, pager, next, sizes current-changefetchData size-changehandleSizeChange / /el-card /div /template script setup langts import { onMounted, reactive, ref } from vue import request from /utils/request interface PageConfig { pageName: string api: Recordstring, string searchFields: any[] tableColumns: any[] toolbarButtons: any[] rowActions: any[] formFields?: any[] } const props defineProps{ pageConfig: PageConfig }() const emit defineEmits{ (e: toolbar, btn: any): void (e: row-action, payload: { action: any; row: any }): void }() const loading ref(false) const tableData refany[]([]) const total ref(0) const queryParams reactiveany({ pageNum: 1, pageSize: 10 }) const buildQuery () { const params: any { pageNum: queryParams.pageNum, pageSize: queryParams.pageSize } props.pageConfig.searchFields.forEach((field) { const value queryParams[field.prop] if (value ! undefined value ! null value ! ) { params[field.prop] value } }) return params } const fetchData async () { loading.value true try { const res: any await request.get(props.pageConfig.api.list, { params: buildQuery() }) tableData.value res.rows || [] total.value res.total || 0 } finally { loading.value false } } const handleSearch () { queryParams.pageNum 1 fetchData() } const handleReset () { Object.keys(queryParams).forEach((key) { if (key ! pageNum key ! pageSize) { queryParams[key] undefined } }) queryParams.pageNum 1 fetchData() } const handleSizeChange () { queryParams.pageNum 1 fetchData() } onMounted(fetchData) /script代码里的request是统一封装好的 axios 实例响应结构约定为{ rows: [], total: number }。渲染器通过defineProps接收页面配置通过defineEmits把操作事件抛给上层页面。上层页面可以只关心“点击了新增按钮之后弹什么对话框”而不需要关心列表页本身怎么渲染。5.4 表单与弹窗新增和编辑通常使用弹窗表单。渲染器会把pageConfig.formFields渲染成el-form字段并根据rules做校验。弹窗的打开和提交逻辑一般放在外层业务页面里!-- 文件路径web/src/views/admin/UserPage.vue -- template ListRenderer :page-configuserPageConfig toolbarhandleToolbar row-actionhandleRowAction / /template script setup langts import { ref } from vue import { ElMessage, ElMessageBox } from element-plus import ListRenderer from /components/lowcode/ListRenderer.vue import userPageConfig from ./userPageConfig.json const dialogVisible ref(false) const formMode refcreate | edit(create) const currentRow refany({}) const handleToolbar (btn: any) { if (btn.key create) { formMode.value create currentRow.value {} dialogVisible.value true } } const handleRowAction ({ action, row }: any) { if (action.key edit) { formMode.value edit currentRow.value { ...row } dialogVisible.value true } else if (action.key delete) { ElMessageBox.confirm(确认删除该用户, 提示) .then(() { ElMessage.success(删除成功) }) } } /script在这个文件里业务代码只处理按钮点击后的动作表格、搜索、分页全部交给ListRenderer。新增一个业务页面的工作量被压缩到复制一份 JSON 配置、复制一个几行代码的页面组件、改改接口和字段。6. AI 中心后台模板里的 AI 能力怎么做6.1 为什么把 AI 中心放进后台模板很多时候后台管理系统的使用者并不是程序员而是运营、客服、产品经理。这些人经常需要写系统公告、写活动文案、把一张报表翻译成通俗结论。传统的后台模板不会为这些场景准备能力但在大模型 API 逐渐普及的背景下在后台里内置一个 AI 中心就有了很实际的意义。从技术角度看AI 中心也是一个可以复用的基础设施。后台里任何模块都可能需要“生成一段文本”或“解读一组数据”与其每个模块单独对接大模型 API不如在模板层面统一做好代理、日志和权限控制后续业务模块直接复用。6.2 首批功能设计AI 中心第一版不做大而全优先实现三个立刻能用的功能第一是 AI 对话工作台。使用者可以跟模型对话也可以把对话结果一键复制到表单里。这是最通用的能力也是验证整个 AI 链路是否通畅的最小场景。第二是内容生成器。针对后台高频场景做模板化提示词比如“生成一条系统升级公告”“生成一条活动上线通知”“把这段技术描述改写成用户能看懂的话”。模板化提示词能显著提升输出稳定性让 AI 从“聊天玩具”变成“生产效率工具”。第三是数据分析解读。把后台已有的一些统计接口接入 AI 中心选中一个数据范围后让模型生成摘要结论。比如给出一组一周内的订单量数据AI 输出“本周订单量整体上升周末有明显高峰建议加大周末的推广投入”。这类结果对管理者和运营人员有直接的决策参考价值。6.3 服务端代理层所有大模型 API 的调用都必须在服务端完成。前端只需要请求自己的后端由后端转发到模型服务。这样做有三个原因密钥不暴露在浏览器端调用记录可以统一落日志后续切换模型厂商时前端代码完全不用改。下面是 Node.js 服务端的一个最小代理实现// 文件路径server/services/llm.js const axios require(axios) async function callLLM({ messages, temperature 0.7 }) { const response await axios.post( process.env.LLM_API_URL, { model: process.env.LLM_MODEL, messages, temperature }, { headers: { Content-Type: application/json, Authorization: Bearer ${process.env.LLM_API_KEY} }, timeout: 60000 } ) return response.data.choices[0].message.content } module.exports { callLLM }// 文件路径server/routes/ai.js const express require(express) const router express.Router() const { callLLM } require(../services/llm) router.post(/chat, async (req, res) { const { messages, temperature } req.body try { const content await callLLM({ messages, temperature }) res.json({ content }) } catch (error) { res.status(502).json({ message: AI 服务调用失败请稍后重试 }) } }) module.exports routerLLM_API_URL 和 LLM_API_KEY 从环境变量读取以.env文件形式维护不写入代码仓库。这种设计兼容目前市面上主流的 OpenAI 协议接口换成任何提供兼容 API 的模型服务都只需要改环境变量。给个.env.example的参考# 文件路径server/.env.example PORT3000 LLM_API_URLhttps://your-llm-api-endpoint/v1/chat/completions LLM_API_KEYplease-replace-with-your-key LLM_MODELyour-model-name这里真正要强调的安全边界是前端绝不能直接调用大模型接口更不要把 API Key 写进前端代码或打包产物里。浏览器的网络请求对用户完全可见密钥一旦泄露就可能被滥用产生真实的经济损失和安全风险。6.4 前端接入方式前端 AI 中心页面只跟server的/api/ai/chat交互。发送消息时把用户的输入包装成 messages 数组POST 到后端拿到返回值后展示在对话区。代码本身很简单但有几个体验细节值得注意第一对话历史由前端维护每次请求都携带完整上下文这样模型才能理解前面的对话。第二请求期间必须显示 loading 状态防止重复提交。第三考虑把上次对话存在本地或服务端用户刷新页面后还能恢复上下文。第四如果模型服务支持流式输出接入流式可以显著提升首字响应体验但流式会增加前端和后端的复杂度第一版可以先不做。7. 运行验证与效果检查7.1 环境准备开始运行之前建议先确认本机环境满足基本要求Node.js 18 或更高版本npm 或 pnpm 均可。可用的模型服务 API如果有对应环境变量配置。没有其他服务占用前端默认端口 5173 和后端默认端口 3000。如果本地暂时没有可用的模型服务AI 中心可以先跑通“请求失败并提示错误”的链路其余模块不受影响。7.2 启动步骤先启动后端服务cd server cp .env.example .env npm install npm run dev再启动前端开发服务cd web npm install npm run dev前端开发服务器启动后浏览器访问 http://localhost:5173使用初始化账号登录系统。如果前后端端口不一致需要在web/vite.config.ts里配置代理把/api前缀的请求转发到后端地址// 文件路径web/vite.config.ts import { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://localhost:3000, changeOrigin: true } } } })7.3 验证清单启动完成后可以按下面的顺序验证项目是否正常打开登录页输入初始化账号密码确认能正常登录并保存 Token。进入用户管理页面确认搜索区、表格、分页都能显示。在搜索框输入用户名关键字点击查询确认请求参数和列表结果会变化。点击新增按钮确认弹窗表单可以打开表单校验规则能生效。打开 AI 中心发送一条消息确认能收到模型返回结果。查看后端日志确认每个请求都有对应记录没有未捕获异常。如果第 2 步表格为空优先打开浏览器控制台检查接口请求和响应状态。如果第 5 步失败优先确认.env里的模型服务地址和密钥是否正确。8. 常见问题与排查思路问题现象可能原因排查方式解决方案页面请求返回 401Token 缺失或过期查看请求头是否携带 Token登录态是否正常重新登录或检查前端请求拦截器的鉴权逻辑低代码页面没有渲染出表格pageConfig 没有加载成功或接口跨域打开控制台看网络请求确认配置路径检查 JSON 导入路径为 vite 配置代理点击查询后列表没有变化查询参数没有传给后端查看 Network 里的请求 Query 参数检查 buildQuery 中字段拼接逻辑AI 中心请求返回 401服务端 API Key 未配置或已失效查看后端日志确认环境变量是否读取成功正确配置LLM_API_KEY重启后端服务AI 中心请求超时模型服务响应慢或网络不可达查看后端日志中的超时时间在 llm.js 中调整 timeout或检查服务地址是否正确npm run dev 提示端口被占用8080 或 5173 端口已被其他进程使用查看终端提示的端口冲突信息在 vite 或启动脚本中改成其他可用端口新增页面后菜单不显示菜单数据中未注册新页面路由检查菜单配置和动态路由注册逻辑在路由配置和菜单数据中加入新页面实际排错时我的习惯是先看网络请求再看后端日志最后才怀疑代码逻辑。大部分问题都能在请求链路里找到线索。9. 最佳实践与工程建议9.1 低代码配置管理第一版可以把 pageConfig 直接放在前端项目里用 JSON 文件维护。项目进入正式迭代之后更推荐把配置存到数据库并通过一个配置管理页面来维护。这样做的好处是业务人员可以在不发布前端代码的情况下修改页面字段后台系统才真正具备了“低代码”的运营能力。无论使用哪种存储方式都要给配置加校验。渲染器遇到缺失字段时应该有友好的兜底提示而不是直接白屏。可以在渲染器外层加一个配置校验函数不通过就渲染一个错误卡片把具体的字段名展示给维护者。9.2 AI 服务安全与成本控制AI 中心的密钥管理必须遵循最小权限原则。为模型服务创建独立 API Key并设置额度上限避免因为 Key 泄露或被内部滥用而产生高额账单。所有 AI 调用都要记录日志包括请求用户、模型名称、Token 消耗和时间。这样既能排查问题也能做成本分析。前端调用 AI 接口需要做频率限制至少避免同一个用户短时间内高频点击。如果团队规模大还应该考虑对普通用户和管管理员设置不同的调用权限。9.3 Vibe Coding 的工程红线用 Vibe Coding 写项目时有一点非常重要AI 生成的代码不是免检产品。下面几类代码必须由人工逐行 review涉及数据库增删改查的逻辑尤其是删除和批量操作。权限校验相关代码防止越权访问。鉴权和密钥处理逻辑。任何会向用户展示未经验证内容的代码。引入 AI 生成代码之后测试用例会比以前更重要。每次让 AI 改完一块功能就手动验证一遍