上周接到一个内部管理后台的开发任务领导只给三天时间要求出一个能演示的版本。放在以前光搭前后端工程、实现登录鉴权、把用户和角色表建起来一天半就没了剩下时间根本不够写业务页面。这次我换了思路直接用 Kiro AI IDE 来干这件事。从对话框里下指令到代码落地、本地跑通、页面联调整个全栈 Admin 系统前端 后端 数据库基本在一个小时内成型后面花的时间全在调细节和补权限逻辑上。整个过程给我最大的感受是AI IDE 类工具的真正价值不是替你写代码而是把项目“从零到能跑”的时间压缩到极限。这篇文章不会讲太多 UI 设计和花哨功能重点记录我自己从零到部署的实操过程先拆解一个 Admin 系统需要什么再讲技术选型和目录规划然后完整展示我在 Kiro 里的一步步操作和提示词写法最后把几天里踩过的坑整理出来。无论你是刚接触全栈开发的新手还是想用 AI 工具提升效率的熟练开发里面提到的思路和排错方法应该都能直接套用。1. 先拆解 Admin 系统它远不止是几个页面很多第一次做后台管理系统的人容易把这件事想简单以为只要做一个登录页加几张数据表格就是 Admin 系统了。真实业务里的后台远比这复杂尤其是内部管理系统核心本质是“让不同身份的人看到不同数据、执行不同操作”。1.1 Admin 系统的共性功能清单市面上无论开源还是商业的后台管理系统无论叫 vben admin、pear admin boot 还是 spring boot admin最终都逃不开下面几个模块用户管理新增用户、编辑资料、重置密码、启用或禁用账号角色与权限把用户划分成管理员、运营、只读访客等角色按角色控制菜单和按钮菜单管理后台左侧栏目录的配置包括路由、图标、排序数据表格与 CRUD对业务数据进行增删改查、分页、搜索、导出仪表盘展示统计数字、图表让管理员一眼看到系统状态审计日志记录谁在什么时间改了什么数据这是内部系统争议排查的关键这里要特别说明一点spring boot admin 和 Admin 业务系统不是一回事。Spring Boot Admin 是监控 Spring Boot 应用运行状态内存、接口健康度、日志的运维工具而我们说的是带用户管理和业务数据的后台管理系统。这个区别在跟 AI 对话时要表述清楚不然生成的骨架会完全偏掉。1.2 为什么不用现成模板而是让 AI 生成我知道有人会问vben admin antd、pear admin boot 这种现成后台模板已经很成熟了为什么还要自己生成我承认模板功能全权限模型、主题切换、代码生成器都有但用起来有两个很现实的问题。第一是学习成本。这些模板为了适配各种业务场景封装层很厚打开项目你会看到一堆抽象类、工厂函数、接口泛型。如果只是做一个简单内部系统大部分代码根本用不到光搞清楚目录结构和依赖关系就要花一两天。第二是定制时的“改造成本”。模板里已经写死了一套路由和状态管理逻辑你改一个需求往往要连带改好几处最后只想做个内部工具却被迫维护一套复杂框架。让 AI 生成则是“按需生长”要什么模块就生成什么模块代码路径清晰出了问题容易定位。1.3 为什么最终选了 Kiro AI IDE选择 Kiro 不是因为它有什么独家魔法而是因为它把“对话生成代码”和“实际开发环境”放在了一起。普通 AI 编程插件只能在你已经建好的项目里做补全和问答而 Kiro 本身就是一个完整的 IDE我可以直接在对话里让它“创建一个新项目”“生成某某文件”“修改某个接口的实现”它真的会在左侧文件树里创建对应目录和文件而不是只给我一段建议代码。更实用的是它能读取终端输出和文件内容。我在本地运行项目时如果报错把终端信息贴回去它能结合项目文件判断问题出在哪里直接提出修改方案这比把代码一段段复制到网页版 ChatGPT 里问高效得多。另外如果对英文界面不习惯Kiro 可以在设置里切换语言对国内开发者比较友好。我实际用下来在联网可用且配置好模型的前提下从项目骨架到核心模块一条完整链路基本半小时到一小时就能跑通。2. 开工前的技术选型与目录规划无论你用不用 AI写全栈应用前都得先解决技术选型。有人觉得选型无所谓反正 AI 都能写。但 AI 生成的代码质量和你提供的信息详细程度强相关选型越明确、限定条件越清晰生成的内容越贴合你的需求。2.1 一个顺手的组合Vue 3 Element Plus Node.js/Express MySQL我这次选的是前后端分离的经典组合。前端用 Vue 3 搭配 Element Plus后端用 Node.js 加 Express 和 TypeScript数据库用 MySQLORM 层用 Prisma。选这套组合有几个原因。前端方面Element Plus 是中文社区生态最成熟的后台组件库之一表格、表单、弹窗、树形控件都有现成的Kiro 对它也非常熟悉生成的代码风格稳定。后端方面Node.js 和前端同为 JavaScript/TypeScript 语言全栈只用一种语言上下文切换成本低AI 生成的一致性和可维护性都比混用 Java 或 Python 要好。数据库用 MySQL 是因为企业内部系统最常遇到的就是它招聘、部署、运维资料都多如果你只是本地学习可以先改成 SQLite连接字符串一换就能跑。这里有个很关键的决策要不要用 TypeScript。我强烈建议全栈都用 TypeScript。AI 生成代码时类型定义本身就是一种“约束”有了类型它不太容易把字符串当数字用接口字段传错也能在编译期发现。代价是配置多一点但对“安全了很多”这件事来说完全值。2.2 项目目录结构按“前端 后端 共享定义”来切启动项目之前我先在 Kiro 里确定了目录结构。我习惯用一个总目录包两个子应用结构大致是这样的admin-system/ ├── frontend/ │ ├── src/ │ │ ├── api/ # 调用后端的接口封装 │ │ ├── components/ # 公共组件 │ │ ├── router/ # 路由配置 │ │ ├── stores/ # 状态管理Pinia │ │ ├── views/ # 页面 │ │ └── main.ts │ ├── package.json │ └── vite.config.ts ├── backend/ │ ├── src/ │ │ ├── controllers/ # 接口逻辑 │ │ ├── middleware/ # 鉴权、日志等中间件 │ │ ├── routes/ # 路由定义 │ │ ├── services/ # 业务逻辑 │ │ └── index.ts │ ├── prisma/ # 数据库模型 │ └── package.json ├── docs/ # 部署说明 └── docker-compose.yml # 一键拉起依赖MySQL、Redis工作目录按前后端分离来组织是考虑到最终要部署在不同的服务上前端静态文件由 Nginx 托管后端接口独立跑两边通过 HTTP 通信。如果你把前后端代码全混在一个目录里到部署阶段会非常痛苦。2.3 数据库表设计RBAC 权限模型在动笔写代码之前先把数据库表结构想清楚是这三天里最正确的一个决定。Admin 系统的权限模型我建议直接采用最经典的 RBAC基于角色的访问控制。它的核心思想是用户不直接拥有权限而是拥有一个或多个角色角色再绑定权限。我这次的表设计包含六张核心表用户表、角色表、权限表、用户角色关联表、角色权限关联表、审计日志表外加一张菜单表用来动态生成左侧导航。CREATE TABLE users ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password_hash VARCHAR(255) NOT NULL, nickname VARCHAR(50), status TINYINT DEFAULT 1, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE roles ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL UNIQUE, code VARCHAR(50) NOT NULL UNIQUE, sort INT DEFAULT 0 ); CREATE TABLE permissions ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, code VARCHAR(100) NOT NULL UNIQUE, type VARCHAR(20) NOT NULL ); CREATE TABLE user_roles ( user_id BIGINT NOT NULL, role_id BIGINT NOT NULL, PRIMARY KEY (user_id, role_id) ); CREATE TABLE role_permissions ( role_id BIGINT NOT NULL, permission_id BIGINT NOT NULL, PRIMARY KEY (role_id, permission_id) );为什么要把关联表单独拎出来而不是在用户表里放一个 role_id 字段因为真实业务里一个用户往往有多个角色比如张三是“运营”同时又是“内容审核员”。如果只有一个角色字段要么建两行重复用户要么被迫做字符串拼接后续查权限都麻烦。多对多关联表虽然写起来多一张表但扩展性是最好的而且 AI 对这套模型非常熟悉提示词里稍微一提它就能完整补全。2.4 统一 API 返回结构和鉴权方式前后端联调最怕各写各的格式。这次我在后端强制统一了一个返回结构{ code: 0, message: ok, data: {} }code 为 0 表示成功非 0 表示业务错误比如 1001 是参数错误、1002 是未登录、1003 是无权限。这个约定在开始写接口前就让 Kiro 按这个格式生成所有返回后端中间件里做了统一处理前端 axios 响应拦截器也统一解包。这样所有页面的请求逻辑都能收敛成很短的代码出错时定位也很直接。鉴权用 JWT。登录接口校验用户名密码成功后返回一个带签名和过期时间的 token前端存在 localStorage 里每次请求在 header 里带Authorization: Bearer token后端中间件校验 token 并解析出用户 ID 和角色。密码不用明文存储用 bcrypt 哈希。这个方案是所有全栈 Project 里最主流的AI 训练的语料也最丰富生成出来基本不会跑偏。3. Kiro 实操从一句话到完整可运行系统这一章是全文的核心。我把自己在 Kiro 里操作的关键步骤、提示词写法和前后端联调的细节都记录下来了。3.1 第一步用自然语言让 AI 生成项目骨架我在 Kiro 中建立工作区后第一句话就直接给出完整项目要求。提示词写得越具体生成的初始目录越规整。我的写法是这样的请帮我创建一个全栈 Admin 系统。前端使用 Vue 3 Vite TypeScript Element Plus Pinia Vue Router。后端使用 Node.js Express TypeScript Prisma MySQL。包含用户管理、角色管理、权限管理、菜单管理和审计日志五个模块。鉴权使用 JWT密码使用 bcrypt 存储。请先搭建项目骨架不用实现具体业务给出目录结构和 package.json 依赖。注意我特别强调“先搭建骨架不用实现具体业务”。这是经验之谈。如果你第一次对话就让它“把整个系统写完”它会一次性生成大量未经验证的代码目录混乱、依赖缺失、类型对不上调试成本反而比从零写还高。我宁可让它分步来先出骨架再逐个填模块。Kiro 收到指令后会在右侧文件树里直接创建目录和文件。这一步大概两分钟就完成了。我检查了生成的package.json确认 Vue 和 Express 依赖都没问题然后分别进入frontend和backend目录执行npm install。第一次安装依赖可能稍慢装完后先跑一遍npm run dev确认两个服务能起来再继续下一步。3.2 登录鉴权模块的生成与联调骨架跑通之后我从最核心的登录模块开始。提示词这样写为 backend 写一个用户登录接口。请求方法 POST /api/auth/login入参为 username 和 password。用 bcrypt 校验密码哈希。校验通过后用 JWT 生成 token有效期为 2 小时。同时让前端生成一个登录页面路径 /login调用该接口并把 token 存入 localStorage。给前端加一个 vue-router 全局导航守卫检测不到 token 就跳转登录页。这里有个细节值得所有用 AI IDE 的人注意你不需要一次把所有逻辑描述得面面俱到Kiro 会在对话上下文中记住你之前让它定义过普拉isma 模型和目录结构。所以这里我只要提到“用 bcrypt”“JWT 有效期 2 小时”它就能从之前的上下文里找到用户表结构生成对应的查询和校验代码。它生成的代码里有两个地方我做了调整。第一是 JWT 密钥它默认写死在代码里。我把它改成了环境变量在.env文件里放JWT_SECRETxxx这个密钥是敏感信息绝对不能提交到代码仓库。第二是登录成功后的返回数据我要求它除了 token 之外同时返回用户的 id、用户名、昵称和角色列表这样前端拿到之后可以直接存到 Pinia不需要再单独调用一次“获取当前用户信息”接口。前端部分Kiro 生成的登录页是一个居中的卡片表单带用户名、密码输入框和登录按钮。Element Plus 的表单自带校验规则用户名密码为空时会有提示。登录接口调用完axios 拦截器会自动把 token 加到后续请求头里。这个拦截器代码由 AI 生成结构大差不差。它生成的类似这样// frontend/src/utils/request.ts import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 0) { ElMessage.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response?.status 401) { localStorage.removeItem(token) router.push(/login) } else { ElMessage.error(error.message || 请求失败) } return Promise.reject(error) } ) export default request我在实际项目里就是这么用的。拦截器统一处理了所有接口的响应解包和 401 跳转这段代码放上去之后后面所有业务页面都省掉了重复的错误处理逻辑。3.3 用户管理模块后端 CRUD 生成登录搞定后开始做用户管理。这是所有 Admin 系统里最典型的一个 CRUD 模块我建议先从这种“标准模块”入手练手因为 AI 对它的掌握程度最高生成代码的稳定度也最好。我的提示词是给用户管理模块生成后端 CRUD 接口。路径为 /api/users。支持分页查询参数为 page、pageSize、keywordkeyword 模糊匹配用户名和昵称。支持新增用户、编辑用户、删除用户逻辑删除把 status 设为 0。新增和编辑时要校验用户名唯一。新增时密码用 bcrypt 加密。普通读者可能觉得这段话没什么特别的但里面每一个词都是我自己反复试出来的关键约束。先说“逻辑删除”。如果你不指定删除方式AI 大概率会生成DELETE /api/users/:id然后数据库里真删掉这一行。但在内部管理系统里带审计日志的权限系统绝不能物理删除用户因为历史日志里保存的 user_id 会变成悬空引用。所以一定要说清楚用 status 字段标记 0/1 实现逻辑删除。再说分页。AI 生成的默认分页接口通常返回{ list, total }但有的版本会返回{ rows, count }在前端对接时容易对不上字段。我让 AI 统一返回{ list, total }并在前端分页组件里也按这个结构配置。一旦前后端数据结构不一致联调时要改的就不止一处。后端代码生成后Kiro 会在backend/src/controllers/userController.ts里给出完整的实现。我重点检查了三个地方密码是否只在校验时使用、查询是否带分页条件、返回值是否包在统一结构里。如果发现问题我不用自己改直接把问题扔给它“列表接口的返回结构缺少 total请和前端分页对应起来”它就能自动修正。3.4 前端用户列表页与表单弹窗后端接口就绪后让 AI 生成用户列表页。这里我要特意说明 Kiro 的一个用法它不是简单的文件追加而是能在已有文件基础上修改代码。之前骨架阶段已经生成了一个views/users.vue空文件它会在这个文件里填充内容。提示词为前端生成用户管理页面。页面顶部是搜索栏包含关键字输入框和查询、重置按钮。表格展示用户名、昵称、角色名、状态、创建时间。状态用 tag 标签显示启用是绿色禁用是灰色。表格右上角有新增按钮每行有编辑和删除按钮。新增和编辑共用一个弹窗表单表单校验用户名为必填且 3-20 个字符密码不少于 6 位。删除前用 ElMessageBox.confirm 二次确认。我特别看重“新增和编辑共用一个弹窗表单”这一点因为这是后台管理页面最常见的交互模式也是 AI 容易出错的地方。它经常会把新增和编辑做成两套完全独立的组件导致后面改一个字段要改两遍。明确要求共用一个弹窗生成的代码结构会整洁很多。生成完页面后我发现表格里的角色名没有显示。原因是我上一轮只让后端返回了用户字段没有关联角色表。解决方式很简单我让后端用户查询时同时查出该用户关联的角色名在前端表单里加入角色多选下拉框。这个过程又用了两轮对话。这种“发现问题 - 让 AI 修 - 再验证”的循环就是使用 AI IDE 的常态习惯之后效率会高很多。3.5 菜单、仪表盘与审计日志剩下的几个模块我基本沿着同一条路走。菜单管理生成了可排序的树形列表前端用 Element Plus 的 el-table 配合树形数据展示。审计日志模块记录用户登录和增删改操作后端写了一个简单中间件每次请求时查一下请求路径和用户角色把关键操作写入audit_logs表。仪表盘页面调用了几个统计接口比如用户总数、角色总数、今日新增登录用户数前端用卡片加趋势图展示。整个会话前后涉及约二十轮对话生成和修改的文件超过六十个。到这一步系统的核心模块已经能完整跑通管理员登录、维护用户和角色、分配权限、查看日志。实际花在这部分的时间不到一小时大量时间反而是花在前面规划表的关联关系上。3.6 本地运行验证与自动修复全部生成完后我把前后端服务都启动起来打开浏览器开始过功能。这个阶段 Kiro 最强的地方在于我可以直接把终端里的报错贴回去问它。例如我第一次运行就遇到 MySQL 连接失败错误信息显示Access denied for user root。我把完整报错贴进对话框它会先判断是不是环境变量配置问题告诉我检查.env里的数据库密码然后生成新的数据库连接配置。这个交互方式让我在本地调试时很少需要去搜索引擎找答案因为大部分报错它都能结合项目文件直接定位。我实际记录过从生成骨架到全部模块跑通大概用了五十分钟。这个速度在传统开发流程里是很难想象的。4. 避坑指南这些错误我基本都踩过用 AI IDE 不等于不用排错只是排错方式变了。这一章把我这几天遇到最典型的五个问题整理成一个速查表每个都有原因和解决思路。4.1 打开 AI 对话时遇到的 “api error: 400 this organization has been disabled”这个错误是使用过程中最值得注意的一个现象。当 Kiro 调用云端模型能力时如果请求返回 HTTP 400 并且提示this organization has been disabled. an organization admin ca...基本可以断定不是项目代码问题而是账号所在组织被禁用了。我查证后的理解是Kiro 这类 AI IDE 本身负责 IDE 能力和编辑器功能但对话、代码补全这些能力通常还需要调用模型服务。如果组织层面的权限出问题比如组织被管理员禁用、账号没有有效额度、组织套餐到期模型服务就不会响应IDE 会通过 API 层把 400 错误返回给用户。遇到这个提示正确的处理顺序是先看账号所属组织的状态是否正常确认套餐有没有欠费或超出用量再问组织管理员确认组织是否被启用如果是自己的个人账号尝试退出登录后重新认证。这些操作都处理完之后在 Kiro 里刷新或重启会话功能通常就能恢复。这个错误本质上属于账号与配额问题和项目代码没有关系所以不要花时间去改代码。4.2 跨域请求被拦截前后端分离开发时前端跑在 5173 端口后端跑在 3000 端口前端发请求到http://localhost:3000会遇到 CORS 跨域问题。这是全栈项目新手最常见的报错。解决方式有两层。后端要允许跨域Kiro 生成的 Express 项目里可以用cors中间件import cors from cors app.use(cors({ origin: [http://localhost:5173], credentials: true }))前端如果通过 Vite 开发服务运行更推荐的方法是在vite.config.ts里配置代理这样前端代码里所有接口路径写成/api由 Vite 转发到后端避免浏览器直接进行跨域请求server: { proxy: { /api: { target: http://localhost:3000, changeOrigin: true } } }只用后端 cors 的话生产环境浏览器依然会拦截除非你把允许的域名写成*但*配合 JWT 有风险。所以我的建议是开发环境用 Vite 代理生产环境用 Nginx 代理后端尽量不开放跨域。4.3 401 不是代码 bug可能是 token 过期有几次我在页面里操作刚点完保存就跳回登录页。排查后发现不是接口写错而是 JWT 的 2 小时有效期到了前端 axios 拦截器检测到 401 就自动清 token 并跳转。这其实是预期行为但体验不好。我的处理办法是把 JWT 有效期改长一点比如 8 小时同时在后端加一个“刷新令牌”机制。简单点说登录成功后除了 accessToken再生成一个 refreshTokenaccessToken 过期时前端带 refreshToken 调一次刷新接口换取新的 accessToken用户无感续期。这个功能听起来复杂但把需求描述清楚后AI 生成起来很快。至少在企业内部系统中频繁要求用户重新登录是很影响使用感受的。4.4 AI 生成的垃圾代码与结构膨胀AI 不是每次都靠谱。我遇到过它在用户管理页面里生成了一个从来没有用过的userFormRules.ts文件也遇到过同一个工具函数在utils/和helpers/目录下各生成一份。这类“重复代码”和“幽灵文件”不会导致系统跑不起来但会严重增加后续维护负担。我的经验是不要让 AI 一次性生成多个页面一次只做一个模块并且在对话里锁定文件路径。比如我会说“把代码更新到frontend/src/views/roles.vue不要新建其他文件”。如果发现生成了多余文件直接让它删除。必须养成审查 AI 生成物 diff 的习惯。AI 写 1000 行代码你至少要把新增的文件逐个点开看一眼心里有数不然这个系统就会变成只有 AI 能看懂、谁接手谁想骂的项目。4.5 数据库字段类型与时区的问题最后一个坑属于全栈项目的常客时间字段。数据库里created_at用 MySQL 的TIMESTAMP但在 JSON 返回时会被序列化成2024-01-01T08:00:00.000Z这种 UTC 格式。前端直接显示会差八个小时尤其在做仪表盘“今日新增用户”统计时数字可能莫名其妙少几个。我的处理建议是后端统一用 UTC 存储前端在展示层做本地时区格式化。Element Plus 表格里可以用一个格式化函数统一处理所有时间字段const formatTime (val: string) { if (!val) return - const date new Date(val) return date.toLocaleString(zh-CN, { hour12: false }) }布尔值与枚举字段我建议直接用数字 0/1 表示因为不同 SQL 方言对布尔类型的支持差异很大AI 生成代码时容易在 MySQL 的TINYINT和 PostgreSQL 的BOOLEAN之间摇摆。固定用 0/1 后代码在切换数据库时基本不用改。4.6 常见问题排查速查表现象可能原因处理方式接口返回 400 organization disabledAI 服务的组织被禁用/额度不足检查组织状态、联系管理员、重新登录前端请求后端报 CORS端口不同未配置跨域开发环境用 Vite 代理生产用 Nginx 代理登录几分钟后自动登出JWT 有效期太短延长有效期或引入刷新令牌机制表格时间比本地时间少 8 小时UTC 时间未转本地时区前端格式化展示后端统一 UTC 存储AI 生成的代码里有重复文件提示词未限定文件路径提示词中明确“更新到 xx 文件不要新建文件”列表分页后总数不对前端 total 取错字段统一返回结构{ list, total }前端对应解析MySQL 连接拒绝密码或端口配置不正确检查.env和 docker-compose 配置重启容器最后说点实际的体会这次全流程做完我个人对“用 AI 开发全栈项目”有了新的理解。过去我总觉得“AI 写代码”是一种炫技直到自己真的在一个限时任务里靠着 Kiro 把整套 Admin 系统做出来才意识到这类工具的定位是“效率放大器”而不是“替代品”。具体到我个人的工作习惯上有两点体会很深。第一和 AI 对话前必须先想清楚数据结构。如果没想清楚用户和角色是“一对多”还是“多对多”不管问多少次 AI生成的代码都会在后续频繁返工。所以哪怕是让 AI 代劳自己该做的设计一步都不能省。第二不要让 AI 一口气生成整个系统模块化分步推进每一步运行确认后再进入下一步这样出了问题永远能定位到最近一轮的改动排查成本最低。我还想分享一个后续可以扩展的方向Admin 系统做出来只是第一步下一步可以在 Kiro 里继续要求它生成 Dockerfile 和 docker-compose 编排文件把 MySQL、前端 Nginx、后端服务一键打包。AI 对这个场景已经很熟悉生成的部署文档基本可以直接用。最后送大家一个实用小技巧在 Kiro 里每完成一个模块都让它给你列出“如何手工验证这个模块”的运行步骤比如用什么命令启动、打开哪个 URL、用什么账号密码登录。把这些验证步骤存到项目根目录的CHECKLIST.md里。这样你会发现AI 不仅仅帮你写了代码连验收路径都帮你规划清楚了。这个习惯比多生成几十行代码珍贵得多。
