13 KiB
13 KiB
layout, background
| layout | background |
|---|---|
| cover | https://images.unsplash.com/photo-1555066931-4365d14bab8c?w=1920&q=80 |
第 1 天:TRAE 基础工作流与陌生代码库理解
真实项目案例:若依 RuoYi-Vue / RuoYi-Vue3
主线任务:理解「登录 → 用户信息 → 菜单路由 → 按钮权限」调用链路
为什么选若依作为案例?
若依的特点
- 🏢 足够真实 — 不是 demo,是完整后台管理系统
- 📋 足够典型 — 用户、角色、菜单、权限、日志、字典
- 🔗 足够复杂 — 前后端分离、多模块、多层级
适合训练的维度
- 陌生代码库理解
- 前后端分离结构分析
- 登录认证链路
- 动态菜单与路由
- 角色与权限体系
- 按钮权限控制
- 操作日志审计
今天训练四个动作
🏗️
看结构
目录、模块
分层、技术栈
分层、技术栈
🔍
找入口
登录、用户信息
菜单、权限入口
菜单、权限入口
🔗
追链路
从登录到路由
到按钮权限
到按钮权限
✅
查依据
每个结论
验证文件来源
验证文件来源
最终产出:若依权限与菜单模块代码理解报告
模块 1:TRAE 在真实研发中的定位
TRAE 适合辅助
- 检索代码
- 解释函数
- 梳理结构
- 生成链路初稿
- 生成文档初稿
不能直接替代
- 业务判断
- 权限决策
- 安全判断
- 上线决策
核心区分:
代码事实(代码现在怎么写) vs
业务事实(业务应该怎么规定)
TRAE 擅长发现代码事实,人工必须判断业务事实
TRAE 擅长发现代码事实,人工必须判断业务事实
模块 2:若依核心业务对象
graph LR
U[User 用户] -->|绑定| R[Role 角色]
R -->|授权| M[Menu 菜单]
M -->|包含| P[Permission 权限字符]
P -->|控制| A[页面/按钮/接口]
U -->|属于| D[Dept 部门]
R -->|数据权限| D
页面权限
能不能看到某个菜单页面
按钮权限
能不能操作新增/修改/删除
数据权限
能看到哪些部门范围的数据
模块 3:@workspace 理解全局结构
标准 Prompt:
@workspace 请分析若依项目全局结构。
维度:
1. 前端目录 2. 后端目录
3. 登录认证 4. 动态路由
5. API 封装 6. 权限控制
7. 操作日志 8. 代码生成
9. 测试与构建 10. 不确定点
每个结论标注依据文件。
⚠️ 不要问:「@workspace 帮我看看若依项目」— 太泛泛,会得到空洞总结
layout: two-cols layoutClass: gap-6
若依前后端结构重点
前端重点目录
| 目录 | 职责 |
|---|---|
src/api |
接口封装 |
src/router |
路由配置 |
src/store |
状态管理 |
src/views |
页面组件 |
src/directive |
权限指令 |
src/permission |
路由守卫 |
src/utils/request |
请求拦截 |
::right::
后端重点模块
| 模块 | 职责 |
|---|---|
ruoyi-admin |
启动+接口 |
ruoyi-framework |
框架配置 |
ruoyi-system |
业务逻辑 |
ruoyi-common |
公共工具 |
分层结构: Controller → Service → Mapper
模块 4:核心调用链路
graph TD
A[用户登录] --> B[获取 Token]
B --> C[获取用户信息 getInfo]
C --> D[获取菜单路由 getRouters]
D --> E[生成动态路由]
E --> F[进入系统页面]
F --> G[权限字符控制按钮]
登录页面
API 调用
后端 Controller
状态更新
登录认证链路
1. 用户输入账号密码
↓
2. Login 页面提交
↓
3. 调用 login API
↓
4. 后端认证用户
↓
5. 返回 Token
↓
6. 前端保存 Token
↓
7. Request 拦截器携带 Token
重点确认
- Token 存储在哪里?
- Request 拦截器在哪里带 Token?
- Token 失效后如何处理?
- 是否有刷新 Token 机制?
动态路由加载链路
1. 调用 getRouters
↓
2. 后端返回菜单树
↓
3. 前端转换为路由对象
↓
4. 动态挂载路由 (addRoute)
↓
5. 渲染侧边栏菜单
↓
6. 用户进入页面
菜单类型
| 类型 | 说明 |
|---|---|
| 目录 | M - 包含子菜单 |
| 菜单 | C - 对应页面组件 |
| 按钮 | F - 权限字符 |
按钮权限链路
graph LR
A[菜单配置权限字符] --> B[角色授权该字符]
B --> C[getInfo 返回 permissions]
C --> D[前端权限指令判断]
D --> E[按钮显示/隐藏]
⚠️ 关键警告
前端按钮权限 只能控制 UI 展示
如果用户绕过前端直接请求后端接口,安全由后端接口权限决定
必须确认
- Controller 是否有权限注解?
- Service 是否校验数据权限?
- 不能只看前端就下结论
模块 5:AI 输出可信度判断
❌ 不可信回答
「若依已经实现了完整权限控制,用户登录后会自动加载菜单和按钮权限,后端接口也都有权限校验,整体风险较低。」
无文件路径 · 无函数名 · 无依据 · 无不确定点
✅ 可信回答
「前端登录成功后调用 getInfo 获取用户信息和权限字符。随后调用 getRouters 获取动态路由菜单。可确认前端存在菜单和按钮权限控制。但仍需检查后端 Controller 权限注解。」
有依据 · 有调用关系 · 区分前后端 · 标注不确定点
可信结论四件套
📁
文件路径
前端 api 文件
后端 Controller
后端 Controller
⚙️
函数/类/注解
getInfo · getRouters
权限注解
权限注解
🔗
调用关系
登录→token→info
→routes→权限
→routes→权限
❓
不确定点
无法确认的内容
必须标注
必须标注
没有这四项内容的 AI 输出,不能轻易采纳进入报告
模块 6:代码理解报告结构
| 章节 | 内容要求 |
|---|---|
| 模块职责 | 具体说明,不能写空话 |
| 核心对象 | User / Role / Menu / Permission / Dept |
| 目录与文件 | 标注和权限主线的关系 |
| 核心调用链路 | 拆分子链路,标注依据 |
| 权限风险 | 风险描述 + 触发条件 + 影响 + 验证 |
| 操作日志风险 | 哪些操作缺失日志 |
| 改造建议 | 文件 + 方法 + 验收标准 |
| 不确定结论 | 必须单独列出 |
风险写法要求:不能写「权限有风险」,必须具体到触发条件 + 影响范围 + 验证方式
layout: center
第 1 天交付物
01
TRAE 使用边界清单
02
若依模块认知图
03
若依项目结构图
04
权限调用链路图
05
TRAE 输出校验清单
06
代码理解报告