---
layout: cover
background: https://images.unsplash.com/photo-1555066931-4365d14bab8c?w=1920&q=80
---
# 第 1 天:TRAE 基础工作流与陌生代码库理解
真实项目案例:若依 RuoYi-Vue / RuoYi-Vue3
主线任务:理解「登录 → 用户信息 → 菜单路由 → 按钮权限」调用链路
---
# 为什么选若依作为案例?
若依的特点
- 🏢 足够**真实** — 不是 demo,是完整后台管理系统
- 📋 足够**典型** — 用户、角色、菜单、权限、日志、字典
- 🔗 足够**复杂** — 前后端分离、多模块、多层级
适合训练的维度
- 陌生代码库理解
- 前后端分离结构分析
- 登录认证链路
- 动态菜单与路由
- 角色与权限体系
- 按钮权限控制
- 操作日志审计
---
# 今天训练四个动作
最终产出:若依权限与菜单模块代码理解报告
---
# 模块 1:TRAE 在真实研发中的定位
TRAE 适合辅助
- 检索代码
- 解释函数
- 梳理结构
- 生成链路初稿
- 生成文档初稿
不能直接替代
- 业务判断
- 权限决策
- 安全判断
- 上线决策
核心区分:
代码事实(代码现在怎么写) vs
业务事实(业务应该怎么规定)
TRAE 擅长发现代码事实,人工必须判断业务事实
---
# 模块 2:若依核心业务对象
```mermaid {scale: 0.85}
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:核心调用链路
```mermaid {scale: 0.8}
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 - 权限字符 |
---
# 按钮权限链路
```mermaid {scale: 0.85}
graph LR
A[菜单配置权限字符] --> B[角色授权该字符]
B --> C[getInfo 返回 permissions]
C --> D[前端权限指令判断]
D --> E[按钮显示/隐藏]
```
⚠️ 关键警告
前端按钮权限 **只能控制 UI 展示**
如果用户绕过前端直接请求后端接口,安全由后端接口权限决定
必须确认
- Controller 是否有权限注解?
- Service 是否校验数据权限?
- 不能只看前端就下结论
---
# 模块 5:AI 输出可信度判断
❌ 不可信回答
「若依已经实现了完整权限控制,用户登录后会自动加载菜单和按钮权限,后端接口也都有权限校验,整体风险较低。」
无文件路径 · 无函数名 · 无依据 · 无不确定点
✅ 可信回答
「前端登录成功后调用 getInfo 获取用户信息和权限字符。随后调用 getRouters 获取动态路由菜单。可确认前端存在菜单和按钮权限控制。但仍需检查后端 Controller 权限注解。」
有依据 · 有调用关系 · 区分前后端 · 标注不确定点
---
# 可信结论四件套
📁
文件路径
前端 api 文件
后端 Controller
⚙️
函数/类/注解
getInfo · getRouters
权限注解
🔗
调用关系
登录→token→info
→routes→权限
没有这四项内容的 AI 输出,不能轻易采纳进入报告
---
# 模块 6:代码理解报告结构
| 章节 | 内容要求 |
|------|---------|
| 模块职责 | 具体说明,不能写空话 |
| 核心对象 | User / Role / Menu / Permission / Dept |
| 目录与文件 | 标注和权限主线的关系 |
| 核心调用链路 | 拆分子链路,标注依据 |
| 权限风险 | 风险描述 + 触发条件 + 影响 + 验证 |
| 操作日志风险 | 哪些操作缺失日志 |
| 改造建议 | 文件 + 方法 + 验收标准 |
| 不确定结论 | 必须单独列出 |
风险写法要求:不能写「权限有风险」,必须具体到触发条件 + 影响范围 + 验证方式
---
layout: center
---
# 第 1 天交付物