用Kiro AI IDE一小时搞定全栈Admin系统：实操与避坑指南

上周接到一个内部管理后台的开发任务，领导只给三天时间要求出一个能演示的版本。放在以前，光搭前后端工程、实现登录鉴权、把用户和角色表建起来，一天半就没了，剩下时间根本不够写业务页面。这次我换了思路，直接用 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，数据库用 MySQL，ORM 层用 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_SECRET=xxx，这个密钥是敏感信息，绝对不能提交到代码仓库。第二是登录成功后的返回数据，我要求它除了 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、keyword，keyword 模糊匹配用户名和昵称。支持新增用户、编辑用户、删除用户（逻辑删除，把 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，再生成一个 refreshToken，accessToken 过期时前端带 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 常见问题排查速查表

最后说点实际的体会

这次全流程做完，我个人对“用 AI 开发全栈项目”有了新的理解。过去我总觉得“AI 写代码”是一种炫技，直到自己真的在一个限时任务里靠着 Kiro 把整套 Admin 系统做出来，才意识到这类工具的定位是“效率放大器”而不是“替代品”。

具体到我个人的工作习惯上，有两点体会很深。第一，和 AI 对话前必须先想清楚数据结构。如果没想清楚用户和角色是“一对多”还是“多对多”，不管问多少次 AI，生成的代码都会在后续频繁返工。所以哪怕是让 AI 代劳，自己该做的设计一步都不能省。第二，不要让 AI 一口气生成整个系统，模块化分步推进，每一步运行确认后再进入下一步，这样出了问题永远能定位到最近一轮的改动，排查成本最低。

我还想分享一个后续可以扩展的方向：Admin 系统做出来只是第一步，下一步可以在 Kiro 里继续要求它生成 Dockerfile 和 docker-compose 编排文件，把 MySQL、前端 Nginx、后端服务一键打包。AI 对这个场景已经很熟悉，生成的部署文档基本可以直接用。

最后送大家一个实用小技巧：在 Kiro 里每完成一个模块，都让它给你列出“如何手工验证这个模块”的运行步骤，比如用什么命令启动、打开哪个 URL、用什么账号密码登录。把这些验证步骤存到项目根目录的CHECKLIST.md里。这样你会发现，AI 不仅仅帮你写了代码，连验收路径都帮你规划清楚了。这个习惯，比多生成几十行代码珍贵得多。