init
This commit is contained in:
smart
+11
@@ -0,0 +1,11 @@
|
||||
.history/*
|
||||
node_modules
|
||||
.DS_Store
|
||||
dist
|
||||
*.local
|
||||
.vite-inspect
|
||||
.remote-assets
|
||||
components.d.ts
|
||||
.history/*
|
||||
slidev/pnpm-lock.yaml
|
||||
slidev/pnpm-workspace.yaml
|
||||
@@ -0,0 +1,8 @@
|
||||
node_modules
|
||||
.DS_Store
|
||||
dist
|
||||
*.local
|
||||
.vite-inspect
|
||||
.remote-assets
|
||||
components.d.ts
|
||||
.history/*
|
||||
@@ -0,0 +1,11 @@
|
||||
# Welcome to [Slidev](https://github.com/slidevjs/slidev)!
|
||||
|
||||
To start the slide show:
|
||||
|
||||
- `npm install`
|
||||
- `npm run dev`
|
||||
- visit <http://localhost:3030>
|
||||
|
||||
Edit the [slides.md](./slides.md) to see the changes.
|
||||
|
||||
Learn more about Slidev at the [documentation](https://sli.dev/).
|
||||
@@ -0,0 +1,37 @@
|
||||
<script setup lang="ts">
|
||||
import { ref } from 'vue'
|
||||
|
||||
const props = defineProps({
|
||||
count: {
|
||||
default: 0,
|
||||
},
|
||||
})
|
||||
|
||||
const counter = ref(props.count)
|
||||
</script>
|
||||
|
||||
<template>
|
||||
<div flex="~" w="min" border="~ main rounded-md">
|
||||
<button
|
||||
border="r main"
|
||||
p="2"
|
||||
font="mono"
|
||||
outline="!none"
|
||||
hover:bg="gray-400 opacity-20"
|
||||
@click="counter -= 1"
|
||||
>
|
||||
-
|
||||
</button>
|
||||
<span m="auto" p="2">{{ counter }}</span>
|
||||
<button
|
||||
border="l main"
|
||||
p="2"
|
||||
font="mono"
|
||||
outline="!none"
|
||||
hover:bg="gray-400 opacity-20"
|
||||
@click="counter += 1"
|
||||
>
|
||||
+
|
||||
</button>
|
||||
</div>
|
||||
</template>
|
||||
@@ -0,0 +1,16 @@
|
||||
[build]
|
||||
publish = "dist"
|
||||
command = "npm run build"
|
||||
|
||||
[build.environment]
|
||||
NODE_VERSION = "20"
|
||||
|
||||
[[redirects]]
|
||||
from = "/.well-known/*"
|
||||
to = "/.well-known/:splat"
|
||||
status = 200
|
||||
|
||||
[[redirects]]
|
||||
from = "/*"
|
||||
to = "/index.html"
|
||||
status = 200
|
||||
@@ -0,0 +1,19 @@
|
||||
{
|
||||
"name": "slidev",
|
||||
"type": "module",
|
||||
"private": true,
|
||||
"scripts": {
|
||||
"build": "slidev build",
|
||||
"dev": "slidev --open",
|
||||
"export": "slidev export"
|
||||
},
|
||||
"dependencies": {
|
||||
"@iconify-json/logos": "^1.2.11",
|
||||
"@slidev/cli": "^52.16.0",
|
||||
"@slidev/theme-default": "latest",
|
||||
"@slidev/theme-seriph": "latest",
|
||||
"slidev-theme-penguin": "^2.3.1",
|
||||
"vite-svg-loader": "^5.1.1",
|
||||
"vue": "^3.5.33"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,517 @@
|
||||
---
|
||||
layout: cover
|
||||
background: https://images.unsplash.com/photo-1555066931-4365d14bab8c?w=1920&q=80
|
||||
---
|
||||
|
||||
# 第 1 天：TRAE 基础工作流与陌生代码库理解
|
||||
|
||||
<div class="text-lg text-gray-300 mt-4">
|
||||
真实项目案例：若依 RuoYi-Vue / RuoYi-Vue3
|
||||
</div>
|
||||
|
||||
<div class="mt-6 text-sm text-gray-400">
|
||||
主线任务：理解「登录 → 用户信息 → 菜单路由 → 按钮权限」调用链路
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 为什么选若依作为案例？
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-8">
|
||||
|
||||
<div>
|
||||
<div class="card-blue">
|
||||
<div class="font-semibold mb-3">若依的特点</div>
|
||||
<div class="space-y-2 text-sm">
|
||||
|
||||
- 🏢 足够**真实** — 不是 demo，是完整后台管理系统
|
||||
- 📋 足够**典型** — 用户、角色、菜单、权限、日志、字典
|
||||
- 🔗 足够**复杂** — 前后端分离、多模块、多层级
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div>
|
||||
<div class="card">
|
||||
<div class="font-semibold mb-3">适合训练的维度</div>
|
||||
<div class="space-y-1 text-sm text-gray-300">
|
||||
|
||||
- 陌生代码库理解
|
||||
- 前后端分离结构分析
|
||||
- 登录认证链路
|
||||
- 动态菜单与路由
|
||||
- 角色与权限体系
|
||||
- 按钮权限控制
|
||||
- 操作日志审计
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 今天训练四个动作
|
||||
|
||||
<div class="grid grid-cols-4 gap-6 mt-12">
|
||||
|
||||
<div class="text-center">
|
||||
<div class="w-16 h-16 rounded-2xl bg-blue-900/50 border border-blue-500/50 flex items-center justify-center mx-auto text-2xl">
|
||||
🏗️
|
||||
</div>
|
||||
<div class="mt-4 font-bold">看结构</div>
|
||||
<div class="text-xs text-gray-400 mt-2">目录、模块<br/>分层、技术栈</div>
|
||||
</div>
|
||||
|
||||
<div class="text-center">
|
||||
<div class="w-16 h-16 rounded-2xl bg-emerald-900/50 border border-emerald-500/50 flex items-center justify-center mx-auto text-2xl">
|
||||
🔍
|
||||
</div>
|
||||
<div class="mt-4 font-bold">找入口</div>
|
||||
<div class="text-xs text-gray-400 mt-2">登录、用户信息<br/>菜单、权限入口</div>
|
||||
</div>
|
||||
|
||||
<div class="text-center">
|
||||
<div class="w-16 h-16 rounded-2xl bg-amber-900/50 border border-amber-500/50 flex items-center justify-center mx-auto text-2xl">
|
||||
🔗
|
||||
</div>
|
||||
<div class="mt-4 font-bold">追链路</div>
|
||||
<div class="text-xs text-gray-400 mt-2">从登录到路由<br/>到按钮权限</div>
|
||||
</div>
|
||||
|
||||
<div class="text-center">
|
||||
<div class="w-16 h-16 rounded-2xl bg-red-900/50 border border-red-500/50 flex items-center justify-center mx-auto text-2xl">
|
||||
✅
|
||||
</div>
|
||||
<div class="mt-4 font-bold">查依据</div>
|
||||
<div class="text-xs text-gray-400 mt-2">每个结论<br/>验证文件来源</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-10 text-center text-sm text-gray-400">
|
||||
最终产出：若依权限与菜单模块代码理解报告
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 1：TRAE 在真实研发中的定位
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-8">
|
||||
|
||||
<div class="card-green">
|
||||
<div class="text-emerald-400 font-semibold mb-3">TRAE 适合辅助</div>
|
||||
<div class="space-y-1 text-sm">
|
||||
|
||||
- 检索代码
|
||||
- 解释函数
|
||||
- 梳理结构
|
||||
- 生成链路初稿
|
||||
- 生成文档初稿
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="card-red">
|
||||
<div class="text-red-400 font-semibold mb-3">不能直接替代</div>
|
||||
<div class="space-y-1 text-sm">
|
||||
|
||||
- 业务判断
|
||||
- 权限决策
|
||||
- 安全判断
|
||||
- 上线决策
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-6 p-4 rounded-lg bg-white/5 border border-white/10 text-sm">
|
||||
<strong>核心区分：</strong>
|
||||
<span class="text-blue-300">代码事实</span>（代码现在怎么写） vs
|
||||
<span class="text-amber-300">业务事实</span>（业务应该怎么规定）<br/>
|
||||
TRAE 擅长发现代码事实，人工必须判断业务事实
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 2：若依核心业务对象
|
||||
|
||||
<div class="mt-6">
|
||||
|
||||
```mermaid {scale: 0.85}
|
||||
graph LR
|
||||
U[User 用户] -->|绑定| R[Role 角色]
|
||||
R -->|授权| M[Menu 菜单]
|
||||
M -->|包含| P[Permission 权限字符]
|
||||
P -->|控制| A[页面/按钮/接口]
|
||||
U -->|属于| D[Dept 部门]
|
||||
R -->|数据权限| D
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<div class="grid grid-cols-3 gap-4 mt-8 text-sm">
|
||||
|
||||
<div class="card">
|
||||
<div class="font-semibold text-blue-300 mb-2">页面权限</div>
|
||||
能不能看到某个菜单页面
|
||||
</div>
|
||||
|
||||
<div class="card">
|
||||
<div class="font-semibold text-emerald-300 mb-2">按钮权限</div>
|
||||
能不能操作新增/修改/删除
|
||||
</div>
|
||||
|
||||
<div class="card">
|
||||
<div class="font-semibold text-amber-300 mb-2">数据权限</div>
|
||||
能看到哪些部门范围的数据
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 3：@workspace 理解全局结构
|
||||
|
||||
<div class="mt-4">
|
||||
|
||||
<div class="card-blue text-sm">
|
||||
|
||||
**标准 Prompt：**
|
||||
|
||||
```
|
||||
@workspace 请分析若依项目全局结构。
|
||||
|
||||
维度：
|
||||
1. 前端目录 2. 后端目录
|
||||
3. 登录认证 4. 动态路由
|
||||
5. API 封装 6. 权限控制
|
||||
7. 操作日志 8. 代码生成
|
||||
9. 测试与构建 10. 不确定点
|
||||
|
||||
每个结论标注依据文件。
|
||||
```
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="mt-4 p-3 rounded-lg bg-red-900/20 border border-red-500/30 text-sm">
|
||||
⚠️ <strong>不要问：</strong>「@workspace 帮我看看若依项目」— 太泛泛，会得到空洞总结
|
||||
</div>
|
||||
|
||||
---
|
||||
layout: two-cols
|
||||
layoutClass: gap-6
|
||||
---
|
||||
|
||||
# 若依前后端结构重点
|
||||
|
||||
<div class="mt-4 text-sm">
|
||||
|
||||
### 前端重点目录
|
||||
|
||||
| 目录 | 职责 |
|
||||
|------|------|
|
||||
| `src/api` | 接口封装 |
|
||||
| `src/router` | 路由配置 |
|
||||
| `src/store` | 状态管理 |
|
||||
| `src/views` | 页面组件 |
|
||||
| `src/directive` | 权限指令 |
|
||||
| `src/permission` | 路由守卫 |
|
||||
| `src/utils/request` | 请求拦截 |
|
||||
|
||||
</div>
|
||||
|
||||
::right::
|
||||
|
||||
<div class="mt-14 text-sm">
|
||||
|
||||
### 后端重点模块
|
||||
|
||||
| 模块 | 职责 |
|
||||
|------|------|
|
||||
| `ruoyi-admin` | 启动+接口 |
|
||||
| `ruoyi-framework` | 框架配置 |
|
||||
| `ruoyi-system` | 业务逻辑 |
|
||||
| `ruoyi-common` | 公共工具 |
|
||||
|
||||
<div class="mt-4">
|
||||
|
||||
**分层结构：** Controller → Service → Mapper
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 4：核心调用链路
|
||||
|
||||
<div class="mt-4 text-center">
|
||||
|
||||
```mermaid {scale: 0.8}
|
||||
graph TD
|
||||
A[用户登录] --> B[获取 Token]
|
||||
B --> C[获取用户信息 getInfo]
|
||||
C --> D[获取菜单路由 getRouters]
|
||||
D --> E[生成动态路由]
|
||||
E --> F[进入系统页面]
|
||||
F --> G[权限字符控制按钮]
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-4 grid grid-cols-4 gap-2 text-xs text-center">
|
||||
<div class="p-2 rounded bg-blue-900/30">登录页面</div>
|
||||
<div class="p-2 rounded bg-blue-900/30">API 调用</div>
|
||||
<div class="p-2 rounded bg-blue-900/30">后端 Controller</div>
|
||||
<div class="p-2 rounded bg-blue-900/30">状态更新</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 登录认证链路
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-6">
|
||||
|
||||
<div class="space-y-2 text-sm">
|
||||
|
||||
<div class="p-2 rounded bg-blue-900/20 border-l-2 border-blue-500">1. 用户输入账号密码</div>
|
||||
<div class="text-blue-400 text-center">↓</div>
|
||||
<div class="p-2 rounded bg-blue-900/20 border-l-2 border-blue-500">2. Login 页面提交</div>
|
||||
<div class="text-blue-400 text-center">↓</div>
|
||||
<div class="p-2 rounded bg-blue-900/20 border-l-2 border-blue-500">3. 调用 login API</div>
|
||||
<div class="text-blue-400 text-center">↓</div>
|
||||
<div class="p-2 rounded bg-emerald-900/20 border-l-2 border-emerald-500">4. 后端认证用户</div>
|
||||
<div class="text-blue-400 text-center">↓</div>
|
||||
<div class="p-2 rounded bg-emerald-900/20 border-l-2 border-emerald-500">5. 返回 Token</div>
|
||||
<div class="text-blue-400 text-center">↓</div>
|
||||
<div class="p-2 rounded bg-blue-900/20 border-l-2 border-blue-500">6. 前端保存 Token</div>
|
||||
<div class="text-blue-400 text-center">↓</div>
|
||||
<div class="p-2 rounded bg-blue-900/20 border-l-2 border-blue-500">7. Request 拦截器携带 Token</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-4">
|
||||
<div class="card">
|
||||
<div class="font-semibold mb-3">重点确认</div>
|
||||
<div class="space-y-2 text-sm text-gray-300">
|
||||
|
||||
- Token 存储在哪里？
|
||||
- Request 拦截器在哪里带 Token？
|
||||
- Token 失效后如何处理？
|
||||
- 是否有刷新 Token 机制？
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 动态路由加载链路
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-6">
|
||||
|
||||
<div class="space-y-2 text-sm">
|
||||
<div class="p-2 rounded bg-emerald-900/20 border-l-2 border-emerald-500">1. 调用 getRouters</div>
|
||||
<div class="text-emerald-400 text-center">↓</div>
|
||||
<div class="p-2 rounded bg-emerald-900/20 border-l-2 border-emerald-500">2. 后端返回菜单树</div>
|
||||
<div class="text-emerald-400 text-center">↓</div>
|
||||
<div class="p-2 rounded bg-blue-900/20 border-l-2 border-blue-500">3. 前端转换为路由对象</div>
|
||||
<div class="text-emerald-400 text-center">↓</div>
|
||||
<div class="p-2 rounded bg-blue-900/20 border-l-2 border-blue-500">4. 动态挂载路由 (addRoute)</div>
|
||||
<div class="text-emerald-400 text-center">↓</div>
|
||||
<div class="p-2 rounded bg-blue-900/20 border-l-2 border-blue-500">5. 渲染侧边栏菜单</div>
|
||||
<div class="text-emerald-400 text-center">↓</div>
|
||||
<div class="p-2 rounded bg-blue-900/20 border-l-2 border-blue-500">6. 用户进入页面</div>
|
||||
</div>
|
||||
|
||||
<div class="mt-4">
|
||||
<div class="card">
|
||||
<div class="font-semibold mb-3">菜单类型</div>
|
||||
<div class="space-y-3 text-sm text-gray-300">
|
||||
|
||||
| 类型 | 说明 |
|
||||
|------|------|
|
||||
| 目录 | M - 包含子菜单 |
|
||||
| 菜单 | C - 对应页面组件 |
|
||||
| 按钮 | F - 权限字符 |
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 按钮权限链路
|
||||
|
||||
<div class="mt-6 text-center text-sm">
|
||||
|
||||
```mermaid {scale: 0.85}
|
||||
graph LR
|
||||
A[菜单配置权限字符] --> B[角色授权该字符]
|
||||
B --> C[getInfo 返回 permissions]
|
||||
C --> D[前端权限指令判断]
|
||||
D --> E[按钮显示/隐藏]
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-8">
|
||||
|
||||
<div class="card-amber">
|
||||
<div class="text-amber-400 font-semibold mb-2">⚠️ 关键警告</div>
|
||||
<div class="text-sm">
|
||||
|
||||
前端按钮权限 **只能控制 UI 展示**
|
||||
|
||||
如果用户绕过前端直接请求后端接口，安全由后端接口权限决定
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="card-blue">
|
||||
<div class="text-blue-300 font-semibold mb-2">必须确认</div>
|
||||
<div class="text-sm">
|
||||
|
||||
- Controller 是否有权限注解？
|
||||
- Service 是否校验数据权限？
|
||||
- 不能只看前端就下结论
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 5：AI 输出可信度判断
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-6">
|
||||
|
||||
<div class="card-red">
|
||||
<div class="text-red-400 font-semibold mb-3">❌ 不可信回答</div>
|
||||
<div class="text-sm p-3 rounded bg-red-900/20 italic">
|
||||
「若依已经实现了完整权限控制，用户登录后会自动加载菜单和按钮权限，后端接口也都有权限校验，整体风险较低。」
|
||||
</div>
|
||||
<div class="text-xs text-gray-400 mt-2">
|
||||
无文件路径 · 无函数名 · 无依据 · 无不确定点
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="card-green">
|
||||
<div class="text-emerald-400 font-semibold mb-3">✅ 可信回答</div>
|
||||
<div class="text-sm p-3 rounded bg-emerald-900/20 italic">
|
||||
「前端登录成功后调用 getInfo 获取用户信息和权限字符。随后调用 getRouters 获取动态路由菜单。可确认前端存在菜单和按钮权限控制。但仍需检查后端 Controller 权限注解。」
|
||||
</div>
|
||||
<div class="text-xs text-gray-400 mt-2">
|
||||
有依据 · 有调用关系 · 区分前后端 · 标注不确定点
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 可信结论四件套
|
||||
|
||||
<div class="grid grid-cols-4 gap-4 mt-10">
|
||||
|
||||
<div class="text-center card p-6">
|
||||
<div class="text-3xl mb-3">📁</div>
|
||||
<div class="font-bold">文件路径</div>
|
||||
<div class="text-xs text-gray-400 mt-2">前端 api 文件<br/>后端 Controller</div>
|
||||
</div>
|
||||
|
||||
<div class="text-center card p-6">
|
||||
<div class="text-3xl mb-3">⚙️</div>
|
||||
<div class="font-bold">函数/类/注解</div>
|
||||
<div class="text-xs text-gray-400 mt-2">getInfo · getRouters<br/>权限注解</div>
|
||||
</div>
|
||||
|
||||
<div class="text-center card p-6">
|
||||
<div class="text-3xl mb-3">🔗</div>
|
||||
<div class="font-bold">调用关系</div>
|
||||
<div class="text-xs text-gray-400 mt-2">登录→token→info<br/>→routes→权限</div>
|
||||
</div>
|
||||
|
||||
<div class="text-center card p-6">
|
||||
<div class="text-3xl mb-3">❓</div>
|
||||
<div class="font-bold">不确定点</div>
|
||||
<div class="text-xs text-gray-400 mt-2">无法确认的内容<br/>必须标注</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-8 text-center text-sm text-gray-400">
|
||||
没有这四项内容的 AI 输出，不能轻易采纳进入报告
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 6：代码理解报告结构
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
| 章节 | 内容要求 |
|
||||
|------|---------|
|
||||
| 模块职责 | 具体说明，不能写空话 |
|
||||
| 核心对象 | User / Role / Menu / Permission / Dept |
|
||||
| 目录与文件 | 标注和权限主线的关系 |
|
||||
| 核心调用链路 | 拆分子链路，标注依据 |
|
||||
| 权限风险 | 风险描述 + 触发条件 + 影响 + 验证 |
|
||||
| 操作日志风险 | 哪些操作缺失日志 |
|
||||
| 改造建议 | 文件 + 方法 + 验收标准 |
|
||||
| 不确定结论 | 必须单独列出 |
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-4 card-red text-sm">
|
||||
<strong>风险写法要求：</strong>不能写「权限有风险」，必须具体到触发条件 + 影响范围 + 验证方式
|
||||
</div>
|
||||
|
||||
---
|
||||
layout: center
|
||||
---
|
||||
|
||||
# 第 1 天交付物
|
||||
|
||||
<div class="grid grid-cols-3 gap-4 mt-8 text-sm max-w-3xl mx-auto">
|
||||
|
||||
<div class="card-blue p-4 text-center">
|
||||
<div class="text-lg mb-1">01</div>
|
||||
TRAE 使用边界清单
|
||||
</div>
|
||||
|
||||
<div class="card-blue p-4 text-center">
|
||||
<div class="text-lg mb-1">02</div>
|
||||
若依模块认知图
|
||||
</div>
|
||||
|
||||
<div class="card-blue p-4 text-center">
|
||||
<div class="text-lg mb-1">03</div>
|
||||
若依项目结构图
|
||||
</div>
|
||||
|
||||
<div class="card-green p-4 text-center">
|
||||
<div class="text-lg mb-1">04</div>
|
||||
权限调用链路图
|
||||
</div>
|
||||
|
||||
<div class="card-green p-4 text-center">
|
||||
<div class="text-lg mb-1">05</div>
|
||||
TRAE 输出校验清单
|
||||
</div>
|
||||
|
||||
<div class="card-amber p-4 text-center">
|
||||
<div class="text-lg mb-1">06</div>
|
||||
代码理解报告
|
||||
</div>
|
||||
|
||||
</div>
|
||||
@@ -0,0 +1,243 @@
|
||||
# 为什么选若依作为案例？
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
**若依适合训练：** 陌生代码库理解 · 前后端分离结构 · 登录认证链路 · 动态菜单与路由 · 角色与权限 · 按钮权限 · 数据权限 · 操作日志 · 代码生成
|
||||
|
||||
- 足够**真实** — 不是 demo，是完整后台管理系统
|
||||
- 足够**典型** — 很多企业内部系统都有这些模块
|
||||
- 足够**复杂** — 前后端分离、多模块、多层级
|
||||
</div>
|
||||
|
||||
<!--
|
||||
我们为什么选若依？
|
||||
|
||||
第一，若依足够真实。它不是 demo，而是一个完整后台管理系统。
|
||||
第二，它足够典型。很多企业内部系统都有用户、角色、菜单、权限、日志、字典、代码生成这些模块。
|
||||
第三，它非常适合讲 AI 辅助代码理解。因为若依既有前端也有后端、既有页面也有接口、既有权限也有日志、既有业务模块也有基础框架能力。
|
||||
|
||||
今天大家不是要记住若依所有代码，而是要学会一种方法：拿到一个陌生系统，如何让 TRAE 帮我们从结构、模块、链路和证据四个层面快速建立理解。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# AI 编程不只是写代码
|
||||
|
||||
<div class="mt-6">
|
||||
|
||||
更重要的是：**读代码 · 找入口 · 追链路 · 查风险 · 写测试 · 生成文档 · 沉淀经验**
|
||||
|
||||
<div class="mt-6 p-4 rounded-xl bg-white/5 border border-white/10 text-sm">
|
||||
AI 对研发的价值，不只是让某个人写得快一点，而是让团队更快理解系统、更快交接、更快定位风险。
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
AI 编程早期给大家的印象，可能是补全代码、生成函数、写几个工具方法。
|
||||
|
||||
但在企业研发中，真正耗时的往往不是写几行代码，而是理解历史代码、追踪业务链路、判断影响范围、确认权限边界、补充测试和沉淀文档。
|
||||
|
||||
AI 对研发的价值，不只是让某个人写得快一点，而是让团队更快理解系统、更快交接、更快定位风险。今天的重点不是"AI 会不会写"，而是"AI 能不能帮我们更快读懂一个真实项目"。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# AI 能效理念
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-6">
|
||||
<div class="p-4 rounded-xl bg-red-500/10 border border-red-500/30">
|
||||
|
||||
**不是只看：** 代码写得更快
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
|
||||
**更要看：**
|
||||
- 理解更快 · 交接更快
|
||||
- 定位更快 · 风险更早暴露
|
||||
- 团队知识沉淀更快
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这里讲一个关键词：能效。在企业里，研发能效不是单点速度，而是整个研发链条的效率。
|
||||
|
||||
如果新人接手若依这样的后台系统，以前可能要花很多时间搞清楚登录在哪里、权限从哪里来、菜单怎么生成、按钮怎么控制、后端接口如何校验。
|
||||
|
||||
如果 TRAE 能帮我们快速定位这些文件和调用关系，它带来的价值就不是少写几行代码，而是降低理解成本、交接成本和维护成本。这就是我们第一天从陌生代码库理解开始的原因。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# AI 替代人的现实判断
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-6">
|
||||
<div>
|
||||
|
||||
**AI 会替代：** 重复性、低上下文、低判断含量的工作方式
|
||||
</div>
|
||||
<div>
|
||||
|
||||
**人必须负责：** 业务规则 · 权限边界 · 安全责任 · 架构取舍 · 上线决策
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
今天有管理层也有工程师，所以可以坦诚谈一下 AI 替代人的问题。
|
||||
|
||||
AI 会替代一部分重复性、低上下文、低判断含量的工作方式，但不能替代所有工程判断。比如若依里一个按钮是否应该对某个角色开放，这不是 AI 单独决定的。AI 可以帮我们找出权限字符在哪里配置、前端如何判断、后端如何校验，但业务上谁应该拥有这个权限，必须由人判断。
|
||||
|
||||
未来真正的差距，不是用不用 AI，而是能不能把 AI 放进标准研发流程，让它帮助我们找证据、提效率，而不是让它替我们承担责任。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 第一天真正要学什么？
|
||||
|
||||
<div class="grid grid-cols-4 gap-4 mt-8">
|
||||
<div class="text-center p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||||
<div class="text-2xl mb-2">🏗️</div>
|
||||
<div class="font-bold">看结构</div>
|
||||
</div>
|
||||
<div class="text-center p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
<div class="text-2xl mb-2">🔍</div>
|
||||
<div class="font-bold">找入口</div>
|
||||
</div>
|
||||
<div class="text-center p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
|
||||
<div class="text-2xl mb-2">🔗</div>
|
||||
<div class="font-bold">追链路</div>
|
||||
</div>
|
||||
<div class="text-center p-4 rounded-xl bg-red-500/10 border border-red-500/30">
|
||||
<div class="text-2xl mb-2">✅</div>
|
||||
<div class="font-bold">查依据</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="mt-6 text-center text-sm text-gray-400">最终产出：若依权限与菜单模块代码理解报告</div>
|
||||
|
||||
<!--
|
||||
今天不是学几个 Prompt，今天训练四个动作。
|
||||
|
||||
第一，看结构。看若依前后端目录、模块分层、启动方式、技术栈。
|
||||
第二，找入口。找登录入口、用户信息接口、菜单接口、权限判断入口。
|
||||
第三，追链路。从登录开始，一路追到动态路由和按钮权限。
|
||||
第四，查依据。AI 的每个关键结论，都要能回到文件、函数、接口或调用关系中验证。
|
||||
|
||||
今天最后的产出，是一份"若依权限与菜单模块代码理解报告"。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 模块 1：TRAE 的定位
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-6">
|
||||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
|
||||
**适合：** 检索代码 · 解释函数 · 梳理结构 · 生成链路初稿 · 生成文档初稿
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-red-500/10 border border-red-500/30">
|
||||
|
||||
**不能直接替代：** 业务判断 · 权限决策 · 安全判断 · 上线决策
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
我们先给 TRAE 定位。TRAE 不是替代工程师的工具，而是研发辅助工具。
|
||||
|
||||
在若依项目里，TRAE 很适合帮我们找登录接口、找用户信息接口、找菜单加载逻辑、找权限判断指令、解释后端 Controller 和 Service 的职责。
|
||||
|
||||
但它不能替我们决定某个角色应该拥有什么权限，也不能替我们判断某个接口是否可以上线。AI 可以帮我们找到代码事实，但不能替代业务和安全责任。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 代码事实 vs 业务事实
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-8">
|
||||
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||||
|
||||
**代码事实：** 代码现在怎么写
|
||||
|
||||
TRAE 擅长发现代码事实
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
|
||||
|
||||
**业务事实：** 业务应该怎么规定
|
||||
|
||||
人工必须判断业务事实
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
在若依案例里，这个区分非常重要。
|
||||
|
||||
比如 TRAE 可能发现某个按钮使用了权限字符 system:user:edit，这是代码事实。但哪些角色应该拥有 system:user:edit，这是业务事实。
|
||||
|
||||
再比如，后端某个接口加了权限注解，这是代码事实。但这个接口权限设计是否合理、是否符合公司安全要求，这是业务事实。
|
||||
|
||||
所以我们用 TRAE 时，要明确它帮我们发现的是"当前系统怎么写"，不是"业务上一定应该这样"。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 适合 TRAE 辅助的任务
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
- 理解前后端目录
|
||||
- 查找登录入口
|
||||
- 查找菜单接口
|
||||
- 分析动态路由生成
|
||||
- 解释按钮权限
|
||||
- 梳理角色权限关系
|
||||
- 生成代码理解报告初稿
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依项目里，有很多任务适合 TRAE 辅助。比如理解前后端目录结构、查找登录入口、查找获取用户信息和路由菜单的接口、分析前端动态路由生成逻辑、解释按钮权限如何生效、梳理角色、菜单、权限字符之间的关系。
|
||||
|
||||
这些信息主要都在代码库里，可以通过文件、函数、接口验证。所以我们可以让 TRAE 先生成初稿，再人工校对。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 必须人工判断的任务
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
- 角色权限是否合理
|
||||
- 数据权限范围是否正确
|
||||
- 接口是否应该开放
|
||||
- 敏感操作是否必须审计
|
||||
- 代码生成结果能否上线
|
||||
- 权限变更是否影响生产
|
||||
</div>
|
||||
|
||||
<!--
|
||||
有些任务不能直接交给 TRAE 决定。
|
||||
|
||||
比如某个角色是否应该拥有用户删除权限，某个部门的数据权限范围是否正确，某个接口是否应该开放，修改角色权限是否会影响生产用户。
|
||||
|
||||
这些涉及业务规则、安全边界和上线风险，必须人工判断。TRAE 可以帮助我们列出当前权限链路和风险点，但不能直接给最终决策。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 产出：TRAE 使用边界清单
|
||||
|
||||
<div class="mt-6">
|
||||
|
||||
| 分类 | 说明 |
|
||||
|------|------|
|
||||
| 适合 TRAE 辅助 | 查找登录接口、分析调用链路 |
|
||||
| 可生成初稿但必须人工复核 | 判断角色权限是否合理 |
|
||||
| 不建议直接交给 TRAE 决定 | 判断能否上线 |
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
第一个实操是生成 TRAE 使用边界清单。
|
||||
|
||||
请大家围绕若依项目，列出哪些任务适合 TRAE 辅助，哪些可以让 TRAE 生成初稿但必须人工复核，哪些不建议直接交给 TRAE 决定。
|
||||
|
||||
例如"查找登录接口"适合 TRAE 辅助；"判断角色权限是否合理"可以生成初稿但必须人工复核；"判断能否上线"不建议交给 TRAE 决定。
|
||||
-->
|
||||
@@ -0,0 +1,152 @@
|
||||
# 模块 2：若依核心业务对象
|
||||
|
||||
<div class="mt-4 text-sm">
|
||||
|
||||
```mermaid {scale: 0.8}
|
||||
graph LR
|
||||
U[User 用户] -->|绑定| R[Role 角色]
|
||||
R -->|授权| M[Menu 菜单]
|
||||
M -->|包含| P[Permission 权限字符]
|
||||
P -->|控制| A[页面/按钮/接口]
|
||||
U -->|属于| D[Dept 部门]
|
||||
```
|
||||
|
||||
核心对象：User 用户 · Role 角色 · Menu 菜单 · Permission 权限字符 · Dept 部门 · Post 岗位 · OperLog 操作日志 · Dict 字典 · GenTable 代码生成
|
||||
</div>
|
||||
|
||||
<!--
|
||||
理解若依，不能只看目录，要先看核心对象。
|
||||
|
||||
若依最核心的是用户、角色、菜单和权限。用户属于部门，可以拥有岗位，可以绑定角色。角色拥有菜单权限和数据权限。菜单不仅控制左侧菜单和动态路由，也关联按钮权限字符。操作日志记录关键操作。代码生成模块帮助生成 CRUD 代码。
|
||||
|
||||
今天我们重点看用户、角色、菜单、权限这条主线。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依模块总览
|
||||
|
||||
<div class="mt-6 grid grid-cols-2 gap-4 text-sm">
|
||||
<div>
|
||||
|
||||
- 登录认证
|
||||
- 用户管理
|
||||
- 角色管理
|
||||
- 菜单管理
|
||||
- 部门管理
|
||||
</div>
|
||||
<div>
|
||||
|
||||
- 岗位管理
|
||||
- 权限控制
|
||||
- 操作日志
|
||||
- 登录日志
|
||||
- 代码生成
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依常见模块包括登录认证、用户管理、角色管理、菜单管理、部门管理、岗位管理、权限控制、操作日志、登录日志、代码生成。
|
||||
|
||||
这些模块组合起来，构成一个典型企业后台系统。
|
||||
|
||||
今天不是要讲完所有模块，而是通过权限和菜单这条主线，学习如何理解陌生项目。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 用户、角色、菜单、权限关系
|
||||
|
||||
<div class="mt-6 text-center text-sm">
|
||||
|
||||
用户 User → 绑定 → 角色 Role → 授权 → 菜单 Menu → 包含 → 权限字符 Permission → 控制 → 页面访问 / 按钮显示 / 接口访问
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依权限体系可以先用这张图理解。
|
||||
|
||||
用户绑定角色。角色被授予菜单。菜单可以是目录、菜单页面，也可以是按钮权限。按钮权限通常通过权限字符表示，比如用户新增、用户修改、用户删除。
|
||||
|
||||
前端根据这些权限字符控制按钮显示，后端接口也应基于权限注解或权限判断控制访问。今天我们要追踪的就是这条链路从后端到前端如何生效。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依中的三类权限
|
||||
|
||||
<div class="grid grid-cols-3 gap-4 mt-8">
|
||||
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
|
||||
|
||||
**页面权限**
|
||||
|
||||
能不能看到某个菜单页面
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
|
||||
|
||||
**按钮权限**
|
||||
|
||||
能不能看到新增、修改、删除按钮
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
|
||||
|
||||
**数据权限**
|
||||
|
||||
能看到哪些部门或范围的数据
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依里我们可以把权限分成三类。
|
||||
|
||||
第一，页面权限。用户能不能看到某个菜单页面。
|
||||
第二，按钮权限。比如用户管理页面上的新增、修改、删除、导出按钮是否显示。
|
||||
第三，数据权限。比如某个角色只能看本部门数据，还是可以看全部数据。
|
||||
|
||||
这三类权限不能混在一起。页面能看到不代表按钮能操作。按钮隐藏也不代表后端接口安全。数据能看到多少又是另外一套规则。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依业务导览 Prompt
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
|
||||
|
||||
```
|
||||
@workspace 请从业务视角分析若依项目。
|
||||
|
||||
重点说明：
|
||||
1. 系统主要解决什么问题
|
||||
2. 核心业务对象有哪些
|
||||
3. 用户、角色、菜单、权限如何协作
|
||||
4. 前端和后端分别负责什么
|
||||
5. 哪些结论需要人工验证
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一页是若依业务导览 Prompt。注意我们不是让 TRAE 泛泛总结项目，而是指定业务视角。
|
||||
|
||||
我们让它说明系统解决什么问题、核心业务对象有哪些、用户、角色、菜单、权限如何协作、前端和后端分别负责什么。同时必须列出需要人工验证的内容。
|
||||
|
||||
这能帮助我们快速建立若依的模块认知图。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 产出：若依模块认知图
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
产出内容：核心业务对象 · 核心模块 · 模块职责 · 模块依赖关系 · 权限链路 · 风险点 · 不确定点
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一部分的产出是若依模块认知图。
|
||||
|
||||
大家要整理出核心业务对象、核心模块、模块职责、模块依赖关系、权限链路、风险点和不确定点。
|
||||
|
||||
例如用户模块依赖部门、岗位和角色；角色模块关联菜单和数据权限；菜单模块既影响动态路由，也影响按钮权限；操作日志模块记录关键操作。
|
||||
-->
|
||||
@@ -0,0 +1,128 @@
|
||||
# 模块 3：不要让 AI 泛泛总结项目
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-6 text-sm">
|
||||
<div class="p-4 rounded-xl bg-red-500/10 border border-red-500/30">
|
||||
|
||||
**不要问：**
|
||||
```
|
||||
@workspace 帮我看看若依项目
|
||||
```
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
|
||||
**要问：** 从前端、后端、认证、路由、API、权限、日志、测试、构建分析项目，并标注依据文件
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
使用 @workspace 时，最常见的错误是问"帮我看看这个项目"。这样 AI 会给一段泛泛总结。
|
||||
|
||||
我们要让它从明确维度分析：前端结构、后端结构、认证流程、路由菜单、API 封装、权限控制、日志记录、测试结构、构建方式。并且要求每个结论标注依据文件。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依前后端结构怎么读？
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-4 text-sm">
|
||||
<div>
|
||||
|
||||
**前端重点：** src/api · src/router · src/store · src/views · src/directive · src/permission · src/utils/request
|
||||
</div>
|
||||
<div>
|
||||
|
||||
**后端重点：** ruoyi-admin · ruoyi-framework · ruoyi-system · ruoyi-common · Controller · Service · Mapper
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依是前后端分离项目，所以读结构时要分前端和后端。
|
||||
|
||||
前端重点看 api、router、store、views、directive、permission 文件、request 封装。
|
||||
|
||||
后端重点看 ruoyi-admin、ruoyi-framework、ruoyi-system、ruoyi-common，以及 Controller、Service、Mapper 分层。
|
||||
|
||||
如果使用 RuoYi-Vue3，前端目录和状态管理方式可能不同，但分析方法一样。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 认证链路要看哪些文件？
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
登录页面 → login API → token 存储 → request 拦截器 → getInfo 用户信息 → getRouters 动态路由 → 权限 store → 路由守卫
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依权限主线从登录开始。
|
||||
|
||||
我们要看登录页面在哪里、login API 怎么调用、token 存在哪里、request 拦截器如何带 token、请求用户信息的 getInfo 在哪里、请求菜单路由的 getRouters 在哪里、权限 store 如何保存角色和权限、路由守卫如何判断是否已加载菜单。
|
||||
|
||||
这条链路是今天最重要的主线。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 动态菜单与路由怎么看？
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
- 后端菜单表
|
||||
- 菜单类型：目录 / 菜单 / 按钮
|
||||
- 路由地址 · 组件路径 · 权限字符
|
||||
- 前端动态路由转换
|
||||
- router.addRoute
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依的菜单不是单纯前端写死的。
|
||||
|
||||
后台菜单管理里配置菜单，菜单可以是目录、页面菜单，也可以是按钮权限。菜单包含路由地址、组件路径、权限字符等信息。
|
||||
|
||||
前端获取后端返回的菜单数据后，会转换成前端路由，再动态挂载。所以分析动态菜单，既要看后端菜单接口，也要看前端路由转换逻辑。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 全局结构分析 Prompt
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
|
||||
|
||||
```
|
||||
@workspace 请分析若依项目全局结构。
|
||||
维度：1.前端目录 2.后端目录 3.登录认证 4.动态路由
|
||||
5.API封装 6.权限控制 7.操作日志 8.代码生成
|
||||
9.测试与构建 10.不确定点
|
||||
每个结论标注依据文件。
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这是若依全局结构分析的标准 Prompt。大家注意，维度非常明确。
|
||||
|
||||
我们不是让 AI 自己决定讲什么，而是让它从前端目录、后端目录、登录认证、动态路由、API 封装、权限控制、操作日志、代码生成、测试与构建这些维度分析。
|
||||
|
||||
每个结论都要标注依据文件。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 产出：若依项目结构图
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
项目结构图应包含：前端目录职责 · 后端模块职责 · 认证与权限相关文件 · 菜单与路由相关文件 · API 封装相关文件 · 操作日志相关文件 · 不确定点
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一部分最终产出是若依项目结构图。
|
||||
|
||||
结构图不只是列目录，而是说明每个目录和权限主线有什么关系。比如前端 views/system/user 是用户管理页面，api/system/user 是用户接口，store/modules/permission 或 permission 文件和动态路由有关，directive/permission 和按钮权限有关。
|
||||
|
||||
后端 sys 用户、角色、菜单 Controller、Service、Mapper 共同支撑权限管理。
|
||||
-->
|
||||
@@ -0,0 +1,217 @@
|
||||
# 模块 4：第一天核心链路
|
||||
|
||||
<div class="mt-4 text-center text-sm">
|
||||
|
||||
```mermaid {scale: 0.75}
|
||||
graph TD
|
||||
A[用户登录] --> B[获取 token]
|
||||
B --> C[获取用户信息]
|
||||
C --> D[获取菜单路由]
|
||||
D --> E[生成动态路由]
|
||||
E --> F[进入系统页面]
|
||||
F --> G[根据权限字符控制按钮]
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
下午我们进入第一天最重要的部分：调用链路分析。
|
||||
|
||||
若依案例的主线链路是：用户登录→获取 token→获取用户信息→获取菜单路由→生成动态路由→进入系统页面→根据权限字符控制按钮。
|
||||
|
||||
这条链路覆盖前端页面、API 调用、后端接口、用户角色、菜单权限、动态路由和按钮权限，非常适合训练陌生代码库理解。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 调用链路 8 个检查点
|
||||
|
||||
<div class="mt-6 grid grid-cols-4 gap-3 text-sm">
|
||||
<div class="p-2 rounded bg-blue-900/20 text-center">1. 页面入口</div>
|
||||
<div class="p-2 rounded bg-blue-900/20 text-center">2. UI 组件</div>
|
||||
<div class="p-2 rounded bg-blue-900/20 text-center">3. 事件函数</div>
|
||||
<div class="p-2 rounded bg-blue-900/20 text-center">4. API 调用</div>
|
||||
<div class="p-2 rounded bg-emerald-900/20 text-center">5. 后端 Controller</div>
|
||||
<div class="p-2 rounded bg-emerald-900/20 text-center">6. Service/权限</div>
|
||||
<div class="p-2 rounded bg-amber-900/20 text-center">7. 前端状态更新</div>
|
||||
<div class="p-2 rounded bg-amber-900/20 text-center">8. 路由/按钮生效</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依的调用链路可以拆成 8 个检查点。
|
||||
|
||||
页面入口，比如登录页或用户管理页。
|
||||
UI 组件，比如登录表单或新增按钮。
|
||||
事件函数，比如 handleLogin。
|
||||
API 调用，比如 login、getInfo、getRouters。
|
||||
后端 Controller，比如登录接口、菜单路由接口。
|
||||
Service 或权限逻辑，比如用户信息、角色权限、菜单树。
|
||||
前端状态更新，比如保存 token、roles、permissions、routes。
|
||||
最后是路由和按钮权限生效。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 登录认证链路示例
|
||||
|
||||
<div class="mt-4 text-sm">
|
||||
|
||||
用户输入账号密码 → Login 页面提交 → 调用 login API → 后端认证用户 → 返回 token → 前端保存 token → request 拦截器携带 token
|
||||
|
||||
**重点：** token 存在哪里？拦截器在哪里带 token？token 失效后如何处理？
|
||||
</div>
|
||||
|
||||
<!--
|
||||
登录认证链路是第一条主线。
|
||||
|
||||
用户在登录页面输入账号密码，提交表单，前端调用 login API。后端校验用户身份，成功后返回 token。前端保存 token，后续请求通过 request 拦截器携带 token。
|
||||
|
||||
这里要重点看三个问题：token 存在哪里，request 拦截器在哪里带 token，token 失效后如何处理。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 用户信息与权限加载链路
|
||||
|
||||
<div class="mt-4 text-sm">
|
||||
|
||||
登录成功 → 调用 getInfo → 后端返回 user/roles/permissions → 前端保存用户信息 → 前端保存角色和权限字符 → 后续用于按钮权限判断
|
||||
|
||||
**注意：** 前端拿到权限字符只能控制页面展示，不能作为后端安全边界
|
||||
</div>
|
||||
|
||||
<!--
|
||||
登录成功之后，系统通常会请求用户信息。
|
||||
|
||||
getInfo 这类接口会返回当前用户信息、角色列表、权限字符等。前端保存这些数据后，后续按钮权限就会依赖这些权限字符进行判断。
|
||||
|
||||
这里要注意：前端拿到权限字符只能控制页面展示，不能作为后端安全边界。真正的接口安全仍然需要后端权限校验。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 动态路由加载链路
|
||||
|
||||
<div class="mt-4 text-sm">
|
||||
|
||||
调用 getRouters → 后端返回菜单树 → 前端转换为路由对象 → 动态挂载路由 → 渲染侧边栏菜单 → 用户进入页面
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依的菜单和路由通常是动态加载的。
|
||||
|
||||
前端调用 getRouters，后端根据当前用户角色和菜单权限返回菜单树。前端把菜单树转换成路由对象，再动态挂载到 router 中。侧边栏根据这些路由渲染菜单。
|
||||
|
||||
这条链路很适合训练"从后端数据到前端页面"的完整理解。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 按钮权限链路
|
||||
|
||||
<div class="mt-4 text-sm">
|
||||
|
||||
菜单中配置权限字符 → 角色拥有该权限字符 → getInfo 返回 permissions → 前端权限指令/方法判断 → 控制按钮显示或隐藏
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
按钮权限的核心是权限字符。
|
||||
|
||||
在菜单管理中，按钮通常会配置类似"用户新增"、"用户修改"、"用户删除"这样的权限字符。角色被授权后，用户登录时会拿到对应权限字符。前端通过权限指令或权限判断方法，决定按钮是否显示。
|
||||
|
||||
再次强调：按钮隐藏只代表前端交互控制，不代表接口安全。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 后端接口权限链路
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-6">
|
||||
<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
|
||||
|
||||
**前端按钮权限** → 只能控制 UI 展示
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
|
||||
|
||||
**后端接口权限** → 必须控制真实访问
|
||||
|
||||
需要确认：Controller 是否有权限注解？Service 是否校验数据权限？
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一页是权限分析的关键。
|
||||
|
||||
前端按钮权限只能控制 UI 展示。如果用户绕过前端、直接请求后端接口，那么真正决定是否安全的是后端接口权限。
|
||||
|
||||
所以在若依里，我们要检查 Controller 是否有权限注解，Service 是否处理数据权限。如果 AI 只看到前端按钮权限，就说"权限安全"，这是错误结论。
|
||||
|
||||
报告里必须区分前端权限和后端权限。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 操作日志链路
|
||||
|
||||
<div class="mt-4 text-sm">
|
||||
|
||||
管理员修改用户 → 调用后端接口 → Controller 执行业务 → 日志注解/AOP 记录操作 → 写入操作日志 → 操作日志页面查询
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依还有一个很适合训练的链路：操作日志。
|
||||
|
||||
比如管理员修改用户信息，前端调用后端接口，后端 Controller 执行业务逻辑。如果接口上配置了日志注解或 AOP，系统会记录操作人、操作模块、操作类型、请求参数、结果等信息。然后管理员可以在操作日志页面查看。
|
||||
|
||||
这条链路适合讲审计、日志脱敏和敏感操作追踪。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 调用链路分析 Prompt
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
|
||||
|
||||
```
|
||||
@workspace 请分析若依中"登录后菜单与按钮权限生效"的完整调用链路。
|
||||
从用户登录开始，依次说明：
|
||||
登录页面、登录API、token、getInfo、getRouters、
|
||||
动态路由、侧边栏菜单、按钮权限、后端接口权限、不确定点。
|
||||
每一步标注文件路径和函数名。
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这是若依调用链路分析 Prompt。
|
||||
|
||||
注意，这个 Prompt 不是让 AI 总结权限系统，而是让它从用户登录开始，按顺序追踪链路。必须包含登录页面、登录 API、token、getInfo、getRouters、动态路由、侧边栏菜单、按钮权限、后端接口权限和不确定点。
|
||||
|
||||
每一步都要标注文件路径和函数名。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 产出：若依权限调用链路图
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
- 登录认证链路图
|
||||
- 用户信息加载链路图
|
||||
- 动态菜单路由链路图
|
||||
- 按钮权限链路图
|
||||
- 后端接口权限链路图
|
||||
- 操作日志链路图
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一部分的产出是若依权限调用链路图。
|
||||
|
||||
不是只画一条线，而是可以拆成几条子链路：登录认证、用户信息加载、动态菜单路由、按钮权限、后端接口权限、操作日志。
|
||||
|
||||
每条链路都要有依据文件和不确定点。
|
||||
-->
|
||||
@@ -0,0 +1,107 @@
|
||||
# 模块 5：常见 AI 幻觉
|
||||
|
||||
<div class="mt-6 p-4 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
|
||||
|
||||
**常见不可信结论：**
|
||||
- 若依权限系统很完善
|
||||
- 所有接口都有后端校验
|
||||
- 按钮权限已经保证安全
|
||||
- 操作日志一定完整
|
||||
- 代码生成结果可以直接上线
|
||||
</div>
|
||||
|
||||
<!--
|
||||
在若依这种项目里，AI 很容易给出看起来正确但不严谨的结论。
|
||||
比如“若依权限系统很完善”“所有接口都有后端校验”“按钮权限已经保证安全”“操作日志一定完整”“代码生成结果可以直接上线”。
|
||||
这些话都不能直接信。
|
||||
要追问：依据文件在哪里？哪个 Controller？哪个注解？哪个权限字符？哪个 AOP？哪个 Service？
|
||||
没有依据，就不能写成确定结论。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 可信输出四件套
|
||||
|
||||
<div class="grid grid-cols-4 gap-4 mt-8">
|
||||
<div class="text-center p-4 rounded-xl bg-white/5 border border-white/10">
|
||||
<div class="text-2xl mb-2">📁</div>
|
||||
<div class="font-bold text-sm">文件路径</div>
|
||||
</div>
|
||||
<div class="text-center p-4 rounded-xl bg-white/5 border border-white/10">
|
||||
<div class="text-2xl mb-2">⚙️</div>
|
||||
<div class="font-bold text-sm">函数/类/注解</div>
|
||||
</div>
|
||||
<div class="text-center p-4 rounded-xl bg-white/5 border border-white/10">
|
||||
<div class="text-2xl mb-2">🔗</div>
|
||||
<div class="font-bold text-sm">调用关系</div>
|
||||
</div>
|
||||
<div class="text-center p-4 rounded-xl bg-white/5 border border-white/10">
|
||||
<div class="text-2xl mb-2">❓</div>
|
||||
<div class="font-bold text-sm">不确定点</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依案例里，一条可信结论必须包含四件套。
|
||||
文件路径：前端哪个 api 文件、后端哪个 Controller。
|
||||
函数、类或注解：getInfo、getRouters、权限指令、Controller 方法、权限注解。
|
||||
调用关系：登录后先拿 token，再 getInfo，再 getRouters，再生成动态路由。
|
||||
不确定点：比如无法确认某个接口是否有数据权限校验。
|
||||
四件套不全的回答，不能轻易采纳。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 不可信回答示例
|
||||
|
||||
<div class="mt-6 p-4 rounded-xl bg-red-500/10 border border-red-500/30 text-sm italic">
|
||||
「若依已经实现了完整权限控制，用户登录后会自动加载菜单和按钮权限，后端接口也都有权限校验，整体风险较低。」
|
||||
</div>
|
||||
|
||||
<div class="mt-4 text-sm text-gray-400">问题：没有文件路径 · 没有函数名 · 没有调用关系 · 没有不确定点</div>
|
||||
|
||||
<!--
|
||||
这段话看起来很顺，但不合格。
|
||||
为什么？没有文件路径。没有函数名。没有说明菜单从哪个接口加载。没有说明按钮权限由哪个指令判断。没有说明后端接口权限在哪里校验。没有列出不确定点。
|
||||
这种回答不能进入报告。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 可信回答示例
|
||||
|
||||
<div class="mt-6 p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm italic">
|
||||
「前端登录成功后调用 getInfo 获取用户信息和权限字符。随后调用 getRouters 获取动态路由菜单。前端根据返回路由生成侧边栏菜单。可以确认前端存在菜单和按钮权限控制。但仍需检查后端 Controller 权限注解，才能确认接口级权限。」
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这个回答更可信。
|
||||
它说明了前端登录后的两个关键动作：getInfo 和 getRouters。
|
||||
它说明了前端根据返回路由生成菜单。
|
||||
同时它没有夸大结论：可以确认前端存在菜单和按钮权限控制，但仍需检查后端 Controller 权限注解，才能确认接口级权限。
|
||||
这就是专业表达。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 产出：TRAE 输出校验清单
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
| 检查项 | 要求 |
|
||||
|--------|------|
|
||||
| 文件路径 | 必须有 |
|
||||
| 函数/类/注解 | 必须有 |
|
||||
| 调用关系 | 必须说明 |
|
||||
| 前后端区分 | 必须区分 |
|
||||
| 不确定点 | 必须列出 |
|
||||
| 验证方式 | 必须给出 |
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一部分的产出是 TRAE 输出校验清单。
|
||||
以后 AI 给出若依权限分析时，就按这些问题检查：
|
||||
是否有文件路径？是否有函数、类或注解？是否说明调用关系？是否区分前端权限和后端权限？是否列出不确定点？是否给出验证方式？
|
||||
没有通过这些检查的内容，不写进报告。
|
||||
-->
|
||||
@@ -0,0 +1,140 @@
|
||||
# 模块 6：报告主题
|
||||
|
||||
<div class="mt-8 text-center">
|
||||
|
||||
<div class="p-6 rounded-xl bg-blue-500/10 border border-blue-500/30 inline-block">
|
||||
|
||||
**代码理解报告：若依权限与菜单模块**
|
||||
|
||||
核心问题：用户登录后，菜单、路由和按钮权限如何生效？
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
今天最终实战，是生成一份代码理解报告。
|
||||
报告主题：若依权限与菜单模块。
|
||||
核心问题：用户登录后，菜单、路由和按钮权限如何生效？
|
||||
这份报告不是 AI 聊天记录，而是可交接、可复核的工程文档。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 报告结构
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
报告包含：模块职责 · 核心对象 · 目录与文件结构 · 核心调用链路 · 权限风险 · 操作日志风险 · 改造建议 · 不确定结论
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
报告至少包含八部分：模块职责、核心对象、目录与文件结构、核心调用链路、权限风险、操作日志风险、改造建议、不确定结论。
|
||||
每个关键结论都要有依据文件或函数。
|
||||
如果没有依据，就写到不确定点里。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 模块职责写法
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-6 text-sm">
|
||||
<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">
|
||||
|
||||
**不要写：** 权限模块用于权限控制。
|
||||
</div>
|
||||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
|
||||
**要写：** 权限与菜单模块负责用户登录后加载角色、权限字符和动态路由，并根据角色菜单关系控制页面访问和按钮显示。
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
模块职责不能写空话。
|
||||
“权限模块用于权限控制”没有信息量。
|
||||
合格写法要具体说明：权限与菜单模块负责用户登录后加载角色、权限字符和动态路由，并根据角色菜单关系控制页面访问和按钮显示。
|
||||
同时要说明前端权限和后端权限的边界。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 核心对象写法
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
User 用户 · Role 角色 · Menu 菜单 · Permission 权限字符 · Dept 部门 · OperLog 操作日志
|
||||
|
||||
用户绑定角色，角色拥有菜单权限，菜单中包含权限字符，部门影响数据权限，操作日志记录敏感操作。
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依权限模块的核心对象是用户、角色、菜单、权限字符、部门和操作日志。
|
||||
用户绑定角色，角色拥有菜单权限，菜单中包含权限字符，部门影响数据权限，操作日志记录敏感操作。
|
||||
这些对象共同构成权限体系。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 风险点写法
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-6 text-sm">
|
||||
<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">
|
||||
|
||||
**不要写：** 权限有风险。
|
||||
</div>
|
||||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
|
||||
**要写：**
|
||||
- 风险：按钮权限只控制前端展示
|
||||
- 触发条件：后端接口缺少权限校验
|
||||
- 影响：用户可能绕过前端直接调用接口
|
||||
- 验证：检查 Controller 是否有权限注解
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
风险点一定要具体。
|
||||
“权限有风险”不是合格风险点。
|
||||
合格风险点要包含风险描述、触发条件、影响范围和验证方式。
|
||||
比如按钮权限只控制前端展示；触发条件是后端接口缺少权限校验；影响是用户可能绕过前端直接调用接口；验证方式是检查 Controller 是否有权限注解。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 改造建议写法
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
- **建议：** 确保敏感接口均有后端权限校验
|
||||
- **原因：** 前端按钮隐藏不能作为安全边界
|
||||
- **验收：** 无权限用户直接请求接口时返回 403
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
改造建议也要具体。
|
||||
比如建议确保用户、角色、菜单等敏感接口均有后端权限校验。
|
||||
原因是前端按钮隐藏不能作为安全边界。
|
||||
验收标准是无权限用户直接请求接口时返回 403。
|
||||
这样的建议才可以进入工程评审。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 第 1 天最终交付物
|
||||
|
||||
<div class="grid grid-cols-3 gap-3 mt-8 text-sm">
|
||||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-center">01 TRAE 使用边界清单</div>
|
||||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-center">02 若依模块认知图</div>
|
||||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-center">03 若依项目结构图</div>
|
||||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-center">04 权限调用链路图</div>
|
||||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-center">05 TRAE 输出校验清单</div>
|
||||
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-center">06 代码理解报告</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
第 1 天最终交付六个产物：
|
||||
TRAE 使用边界清单、若依模块认知图、若依项目结构图、权限调用链路图、TRAE 输出校验清单、若依权限与菜单模块代码理解报告。
|
||||
这些产物构成第一天的完整成果。
|
||||
-->
|
||||
@@ -0,0 +1,553 @@
|
||||
---
|
||||
layout: cover
|
||||
background: https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=1920&q=80
|
||||
---
|
||||
|
||||
# 第 2 天：TRAE 上下文工程与规则体系
|
||||
|
||||
<div class="text-lg text-gray-300 mt-4">
|
||||
让 TRAE 按团队规则改代码 — 从代码理解到研发治理
|
||||
</div>
|
||||
|
||||
<div class="mt-6 text-sm text-gray-400">
|
||||
上下文决定 AI 看什么 · 规则决定 AI 怎么做 · 资产化决定团队怎么复用
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 第 1 天到第 2 天的跨越
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-10">
|
||||
|
||||
<div class="card">
|
||||
<div class="text-blue-400 text-sm font-semibold mb-3">第 1 天</div>
|
||||
<div class="text-xl font-bold mb-3">让 TRAE 看懂若依代码</div>
|
||||
<div class="text-sm text-gray-400">
|
||||
看结构 · 找入口 · 追链路 · 查依据
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="card-green">
|
||||
<div class="text-emerald-400 text-sm font-semibold mb-3">第 2 天</div>
|
||||
<div class="text-xl font-bold mb-3">让 TRAE 按团队规则改代码</div>
|
||||
<div class="text-sm text-gray-400">
|
||||
组织上下文 · 控制幻觉 · 编写 rules · 沉淀资产
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-8 card-amber text-sm">
|
||||
<strong>核心变化：</strong>当团队多人都使用 AI 时，必须有统一上下文、统一 rules、统一验收标准，否则 AI 会带来不一致甚至风险。
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 若依场景下的团队规则问题
|
||||
|
||||
<div class="mt-6">
|
||||
<div class="card-red">
|
||||
<div class="text-red-400 font-semibold mb-3">若依类后台项目常见风险</div>
|
||||
<div class="grid grid-cols-2 gap-4 text-sm">
|
||||
|
||||
<div class="space-y-2">
|
||||
|
||||
- 🚨 绕过权限，页面直接调接口
|
||||
- 🚨 按钮权限当安全边界
|
||||
- 🚨 接口缺少权限注解
|
||||
- 🚨 操作日志缺失
|
||||
|
||||
</div>
|
||||
|
||||
<div class="space-y-2">
|
||||
|
||||
- 🚨 代码生成后直接上线
|
||||
- 🚨 敏感信息进入日志
|
||||
- 🚨 数据权限范围不清
|
||||
- 🚨 AI 修改未经复核
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="mt-6 text-sm text-gray-400 text-center">
|
||||
今天要把这些隐性开发要求写成中文规则，让 TRAE 长期遵守
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 今天三个关键词
|
||||
|
||||
<div class="grid grid-cols-3 gap-8 mt-12">
|
||||
|
||||
<div class="text-center">
|
||||
<div class="w-20 h-20 rounded-2xl bg-blue-900/50 border border-blue-500/50 flex items-center justify-center mx-auto">
|
||||
<span class="text-3xl">🎯</span>
|
||||
</div>
|
||||
<div class="mt-4 text-xl font-bold">上下文</div>
|
||||
<div class="text-sm text-gray-400 mt-2">决定 AI 看什么</div>
|
||||
<div class="text-xs text-gray-500 mt-1">整个项目 vs 单模块 vs 单文件</div>
|
||||
</div>
|
||||
|
||||
<div class="text-center">
|
||||
<div class="w-20 h-20 rounded-2xl bg-emerald-900/50 border border-emerald-500/50 flex items-center justify-center mx-auto">
|
||||
<span class="text-3xl">📏</span>
|
||||
</div>
|
||||
<div class="mt-4 text-xl font-bold">规则</div>
|
||||
<div class="text-sm text-gray-400 mt-2">决定 AI 怎么做</div>
|
||||
<div class="text-xs text-gray-500 mt-1">不能绕过权限 · 不能遗漏日志</div>
|
||||
</div>
|
||||
|
||||
<div class="text-center">
|
||||
<div class="w-20 h-20 rounded-2xl bg-amber-900/50 border border-amber-500/50 flex items-center justify-center mx-auto">
|
||||
<span class="text-3xl">📦</span>
|
||||
</div>
|
||||
<div class="mt-4 text-xl font-bold">资产化</div>
|
||||
<div class="text-sm text-gray-400 mt-2">决定团队怎么复用</div>
|
||||
<div class="text-xs text-gray-500 mt-1">Prompt · Rules · 模板</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 1：上下文工程 — 好任务五要素
|
||||
|
||||
<div class="mt-8 text-center">
|
||||
|
||||
<div class="inline-block card-blue px-8 py-4 text-lg font-bold">
|
||||
好任务 = 目标 + 范围 + 约束 + 输出格式 + 验收标准
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-8">
|
||||
|
||||
<div class="card-red text-sm">
|
||||
<div class="text-red-400 font-semibold mb-2">❌ 坏 Prompt</div>
|
||||
|
||||
```
|
||||
@workspace 帮我检查若依权限有没有问题。
|
||||
```
|
||||
|
||||
<div class="text-xs text-gray-400 mt-2">目标不清 · 范围不清 · 约束不清 · 输出不清</div>
|
||||
</div>
|
||||
|
||||
<div class="card-green text-sm">
|
||||
<div class="text-emerald-400 font-semibold mb-2">✅ 好 Prompt</div>
|
||||
|
||||
```
|
||||
@workspace 分析若依用户管理页面按钮权限调用链路
|
||||
|
||||
范围：只分析新增/修改/删除按钮
|
||||
约束：不修改代码；标注文件和函数
|
||||
输出：表格
|
||||
验收：覆盖按钮/权限字符/前端判断/后端接口
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 2：四类上下文工具
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-8">
|
||||
|
||||
<div class="card p-5">
|
||||
<div class="flex items-center gap-2 mb-2">
|
||||
<span class="tag">@workspace</span>
|
||||
<span class="font-bold">找路</span>
|
||||
</div>
|
||||
<div class="text-sm text-gray-400">全局搜索入口、文件、模块</div>
|
||||
<div class="text-xs text-gray-500 mt-1">如：找 getInfo、getRouters、权限指令</div>
|
||||
</div>
|
||||
|
||||
<div class="card p-5">
|
||||
<div class="flex items-center gap-2 mb-2">
|
||||
<span class="tag-green">#File</span>
|
||||
<span class="font-bold">看文件</span>
|
||||
</div>
|
||||
<div class="text-sm text-gray-400">分析指定文件间的调用关系</div>
|
||||
<div class="text-xs text-gray-500 mt-1">如：分析用户 Controller 和 Service</div>
|
||||
</div>
|
||||
|
||||
<div class="card p-5">
|
||||
<div class="flex items-center gap-2 mb-2">
|
||||
<span class="tag-amber">#Code</span>
|
||||
<span class="font-bold">抠细节</span>
|
||||
</div>
|
||||
<div class="text-sm text-gray-400">分析单个方法的参数、调用、异常</div>
|
||||
<div class="text-xs text-gray-500 mt-1">如：分析 handleLogin 函数</div>
|
||||
</div>
|
||||
|
||||
<div class="card p-5">
|
||||
<div class="flex items-center gap-2 mb-2">
|
||||
<span class="px-3 py-1 rounded-full text-xs font-semibold bg-purple-500/20 text-purple-300">#Web</span>
|
||||
<span class="font-bold">查外部</span>
|
||||
</div>
|
||||
<div class="text-sm text-gray-400">查询框架文档或最佳实践</div>
|
||||
<div class="text-xs text-gray-500 mt-1">但若依当前实现必须回到代码验证</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 3：幻觉死循环切断
|
||||
|
||||
<div class="mt-6">
|
||||
|
||||
<div class="card-red mb-4">
|
||||
<div class="text-red-400 font-semibold mb-2">常见幻觉表现</div>
|
||||
<div class="grid grid-cols-3 gap-3 text-sm">
|
||||
<div class="p-2 rounded bg-red-900/20">AI 说所有接口都有权限校验<br/><span class="text-xs text-gray-500">但不给 Controller 依据</span></div>
|
||||
<div class="p-2 rounded bg-red-900/20">AI 说操作日志完整<br/><span class="text-xs text-gray-500">但不给注解或 AOP 依据</span></div>
|
||||
<div class="p-2 rounded bg-red-900/20">AI 说按钮权限安全<br/><span class="text-xs text-gray-500">但只看到前端代码</span></div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="grid grid-cols-3 gap-4 mt-6">
|
||||
|
||||
<div class="card-blue text-center p-4">
|
||||
<div class="text-2xl mb-2">1️⃣</div>
|
||||
<div class="font-bold">先找证据</div>
|
||||
<div class="text-xs text-gray-400 mt-1">文件 · 类 · 方法 · 注解</div>
|
||||
</div>
|
||||
|
||||
<div class="card-green text-center p-4">
|
||||
<div class="text-2xl mb-2">2️⃣</div>
|
||||
<div class="font-bold">再判断原因</div>
|
||||
<div class="text-xs text-gray-400 mt-1">区分事实和推测</div>
|
||||
</div>
|
||||
|
||||
<div class="card-amber text-center p-4">
|
||||
<div class="text-2xl mb-2">3️⃣</div>
|
||||
<div class="font-bold">最后给方案</div>
|
||||
<div class="text-xs text-gray-400 mt-1">修改 · 影响 · 验证</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 证据收集标准 Prompt
|
||||
|
||||
<div class="mt-4 card-blue text-sm">
|
||||
|
||||
```
|
||||
请先不要修改代码。
|
||||
|
||||
请围绕"用户管理删除按钮权限"收集证据：
|
||||
|
||||
1. 前端按钮在哪个页面
|
||||
2. 使用了哪个权限字符
|
||||
3. 前端如何判断按钮显示
|
||||
4. 后端删除接口在哪里
|
||||
5. Controller 是否有权限注解
|
||||
6. 是否记录操作日志
|
||||
7. 无法确认的内容
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-4 text-sm text-gray-400">
|
||||
先收集证据，再判断风险，最后才给方案。<br/>不要让 AI 跳过证据直接给结论。
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 4：.gitignore 与敏感配置
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-6">
|
||||
|
||||
<div class="card-red">
|
||||
<div class="text-red-400 font-semibold mb-3">不应提交的文件</div>
|
||||
<div class="text-sm space-y-1">
|
||||
|
||||
- `.env` 环境变量
|
||||
- `application-dev.yml` 真实密码
|
||||
- 数据库账号 / Redis 密码
|
||||
- `target/` 编译产物
|
||||
- `node_modules/` / `dist/`
|
||||
- 日志文件
|
||||
- IDE 本地配置
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="card-green">
|
||||
<div class="text-emerald-400 font-semibold mb-3">敏感配置规则</div>
|
||||
<div class="text-sm space-y-2">
|
||||
|
||||
- 禁止硬编码数据库密码
|
||||
- 禁止硬编码 Redis 密码
|
||||
- 禁止硬编码 JWT 密钥
|
||||
- 禁止硬编码第三方密钥
|
||||
- 不得提交真实配置文件
|
||||
- 示例配置必须使用占位符
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 5：.trae/rules.md 中文安全规则
|
||||
|
||||
<div class="mt-4 space-y-3 text-sm">
|
||||
|
||||
<div class="p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">
|
||||
<strong class="text-blue-300">规则 1：</strong>前端按钮权限只能作为交互控制，不能作为安全边界。
|
||||
</div>
|
||||
|
||||
<div class="p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">
|
||||
<strong class="text-blue-300">规则 2：</strong>涉及用户、角色、菜单、部门、岗位等敏感接口时，必须检查后端 Controller 是否存在权限控制。
|
||||
</div>
|
||||
|
||||
<div class="p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">
|
||||
<strong class="text-blue-300">规则 3：</strong>涉及新增、修改、删除、导出等操作时，必须检查是否记录操作日志。
|
||||
</div>
|
||||
|
||||
<div class="p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">
|
||||
<strong class="text-blue-300">规则 4：</strong>禁止在源码中硬编码数据库密码、Redis 密码、JWT 密钥。
|
||||
</div>
|
||||
|
||||
<div class="p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">
|
||||
<strong class="text-blue-300">规则 5：</strong>列表查询必须确认是否需要数据权限过滤。
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 6：编码与测试规则
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-6">
|
||||
|
||||
<div>
|
||||
<div class="font-semibold text-blue-300 mb-3">编码规则重点</div>
|
||||
<div class="text-sm space-y-2">
|
||||
|
||||
- 前端接口放 `api` 目录，不在页面写请求
|
||||
- 后端遵守 Controller → Service → Mapper 分层
|
||||
- 敏感接口关注权限注解
|
||||
- 敏感操作关注日志注解
|
||||
- 列表查询关注数据权限
|
||||
- 固定枚举值使用字典
|
||||
- 代码生成结果必须人工检查
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div>
|
||||
<div class="font-semibold text-emerald-300 mb-3">测试规则重点</div>
|
||||
<div class="text-sm space-y-2">
|
||||
|
||||
- ✅ 登录成功 / 失败
|
||||
- ✅ 无权限访问接口返回拒绝
|
||||
- ✅ 按钮权限和权限字符匹配
|
||||
- ✅ 角色授权变化后权限更新
|
||||
- ✅ 数据权限范围正确
|
||||
- ✅ 敏感操作有日志记录
|
||||
- ✅ 代码生成 CRUD 完整性
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 7：前端专项规则
|
||||
|
||||
<div class="mt-6">
|
||||
|
||||
<div class="card text-sm">
|
||||
<div class="font-semibold mb-3">用户管理页面规则示例</div>
|
||||
|
||||
| 规则项 | 要求 |
|
||||
|--------|------|
|
||||
| 按钮权限 | 新增/修改/删除/导出必须使用权限控制 |
|
||||
| 删除操作 | 必须二次确认 |
|
||||
| 提交失败 | loading 必须恢复 |
|
||||
| 数据刷新 | 修改后必须刷新列表 |
|
||||
| 敏感字段 | 不得明文展示或输出日志 |
|
||||
| 接口调用 | 统一放 api 目录 |
|
||||
| 动态路由 | 不能随意绕过 |
|
||||
| 字典字段 | 使用统一字典显示 |
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 8：规则可执行性检查
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-8">
|
||||
|
||||
<div class="card-red">
|
||||
<div class="text-red-400 font-semibold mb-3">❌ 坏规则</div>
|
||||
<div class="space-y-2 text-sm">
|
||||
|
||||
- 「注意权限安全」
|
||||
- 「代码要规范」
|
||||
- 「日志要完整」
|
||||
- 「数据权限要合理」
|
||||
- 「生成代码要检查」
|
||||
|
||||
</div>
|
||||
<div class="text-xs text-gray-500 mt-3">方向没错，但不可执行</div>
|
||||
</div>
|
||||
|
||||
<div class="card-green">
|
||||
<div class="text-emerald-400 font-semibold mb-3">✅ 好规则</div>
|
||||
<div class="space-y-2 text-sm">
|
||||
|
||||
- 涉及用户/角色/菜单/部门/岗位的新增/修改/删除/导出接口 → **必须检查后端权限和操作日志**
|
||||
- 涉及列表查询 → **必须确认数据权限过滤**
|
||||
- 代码生成结果上线前 → **必须检查权限、日志、校验、异常和测试**
|
||||
|
||||
</div>
|
||||
<div class="text-xs text-gray-500 mt-3">有触发场景 · 有必须动作 · 可被检查</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 模块 9：技能与规则资产化
|
||||
|
||||
<div class="mt-6">
|
||||
|
||||
```
|
||||
ai-dev-assets/
|
||||
├── prompts/若依/ # 若依相关 Prompt 模板
|
||||
│ ├── 结构分析.md
|
||||
│ ├── 登录权限链路.md
|
||||
│ ├── 按钮权限检查.md
|
||||
│ └── 操作日志检查.md
|
||||
├── rules/若依/ # 若依 rules.md
|
||||
├── templates/若依/ # 报告模板
|
||||
├── checklists/若依/ # 检查清单
|
||||
│ ├── 权限检查.md
|
||||
│ ├── 日志检查.md
|
||||
│ └── 代码生成Review.md
|
||||
└── examples/若依/ # 优秀案例 & 反面案例
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-4 text-sm text-gray-400 text-center">
|
||||
这些资产以后可以直接用于公司内部类似后台管理系统
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 若依版 rules.md 核心条款
|
||||
|
||||
<div class="mt-6 space-y-4">
|
||||
|
||||
<div class="flex items-center gap-4 p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">
|
||||
<div class="w-8 h-8 rounded-full bg-blue-500/30 flex items-center justify-center flex-shrink-0 text-sm font-bold">1</div>
|
||||
<div class="text-sm">前端按钮权限<strong class="text-red-300">不是</strong>安全边界</div>
|
||||
</div>
|
||||
|
||||
<div class="flex items-center gap-4 p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">
|
||||
<div class="w-8 h-8 rounded-full bg-blue-500/30 flex items-center justify-center flex-shrink-0 text-sm font-bold">2</div>
|
||||
<div class="text-sm">敏感接口<strong class="text-emerald-300">必须</strong>检查后端权限</div>
|
||||
</div>
|
||||
|
||||
<div class="flex items-center gap-4 p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">
|
||||
<div class="w-8 h-8 rounded-full bg-blue-500/30 flex items-center justify-center flex-shrink-0 text-sm font-bold">3</div>
|
||||
<div class="text-sm">敏感操作<strong class="text-emerald-300">必须</strong>检查操作日志</div>
|
||||
</div>
|
||||
|
||||
<div class="flex items-center gap-4 p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">
|
||||
<div class="w-8 h-8 rounded-full bg-blue-500/30 flex items-center justify-center flex-shrink-0 text-sm font-bold">4</div>
|
||||
<div class="text-sm">列表查询<strong class="text-emerald-300">必须</strong>考虑数据权限</div>
|
||||
</div>
|
||||
|
||||
<div class="flex items-center gap-4 p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">
|
||||
<div class="w-8 h-8 rounded-full bg-blue-500/30 flex items-center justify-center flex-shrink-0 text-sm font-bold">5</div>
|
||||
<div class="text-sm">代码生成结果<strong class="text-red-300">不得</strong>直接上线</div>
|
||||
</div>
|
||||
|
||||
<div class="flex items-center gap-4 p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">
|
||||
<div class="w-8 h-8 rounded-full bg-blue-500/30 flex items-center justify-center flex-shrink-0 text-sm font-bold">6</div>
|
||||
<div class="text-sm">不确定内容<strong class="text-emerald-300">必须</strong>标注</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
layout: center
|
||||
---
|
||||
|
||||
# 第 2 天交付物
|
||||
|
||||
<div class="grid grid-cols-2 gap-3 mt-8 text-sm max-w-3xl mx-auto">
|
||||
|
||||
<div class="card-blue p-3">01 上下文组织清单</div>
|
||||
<div class="card-blue p-3">02 上下文引用模板</div>
|
||||
<div class="card-blue p-3">03 幻觉控制 Prompt</div>
|
||||
<div class="card-blue p-3">04 .gitignore 配置样例</div>
|
||||
<div class="card-green p-3">05 若依中文安全规则</div>
|
||||
<div class="card-green p-3">06 若依编码测试规则</div>
|
||||
<div class="card-green p-3">07 若依前端规则</div>
|
||||
<div class="card-amber p-3">08 若依 AI 资产库目录</div>
|
||||
<div class="card-amber p-3">09 规则验收清单</div>
|
||||
<div class="card-amber p-3">10 若依版 rules.md v0.1</div>
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 两天课程总结
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-8">
|
||||
|
||||
<div class="card">
|
||||
<div class="text-blue-400 font-semibold mb-3">第 1 天：读懂若依</div>
|
||||
<div class="text-sm space-y-1">
|
||||
|
||||
- 看结构 — 全局目录与模块职责
|
||||
- 找入口 — 登录、权限、菜单入口
|
||||
- 追链路 — 完整调用链路分析
|
||||
- 查依据 — 验证 AI 输出可信度
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="card-green">
|
||||
<div class="text-emerald-400 font-semibold mb-3">第 2 天：按规则参与若依</div>
|
||||
<div class="text-sm space-y-1">
|
||||
|
||||
- 组织上下文 — 精准任务五要素
|
||||
- 控制幻觉 — 证据→原因→方案
|
||||
- 编写 rules — 中文可执行规则
|
||||
- 沉淀资产 — 团队长期复用
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-8 text-center">
|
||||
<div class="inline-block card-blue px-8 py-4">
|
||||
<div class="text-xl font-bold mb-2">最终能力</div>
|
||||
<div class="grid grid-cols-5 gap-4 text-sm">
|
||||
<div>读得懂</div>
|
||||
<div>问得准</div>
|
||||
<div>查得实</div>
|
||||
<div>改得稳</div>
|
||||
<div>可复用</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,178 @@
|
||||
# 第 1 天到第 2 天
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-8">
|
||||
<div class="p-4 rounded-xl bg-white/5 border border-white/10">
|
||||
|
||||
**第 1 天：** 让 TRAE 看懂若依代码
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
|
||||
**第 2 天：** 让 TRAE 按团队规则改若依代码
|
||||
|
||||
核心变化：从代码理解到研发治理
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
昨天我们使用若依作为真实开源项目，学习了如何让 TRAE 理解陌生代码库。
|
||||
今天我们进入第二阶段：上下文工程与规则体系。
|
||||
如果说第一天是“让 AI 看懂若依”，今天就是“让 AI 按团队规则分析、修改和检查若依”。
|
||||
当团队多人都使用 AI 时，必须有统一上下文、统一 rules、统一验收标准，否则 AI 会带来不一致甚至风险。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依场景下的团队规则问题
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
**若依类后台项目常见风险：**
|
||||
- 绕过权限，页面直接调接口
|
||||
- 按钮权限当安全边界
|
||||
- 接口缺少权限注解
|
||||
- 操作日志缺失
|
||||
- 代码生成后直接上线
|
||||
- 敏感信息进入日志
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依这类后台系统，最容易出现的问题不是页面不好看，而是权限、日志、接口边界和生成代码质量。
|
||||
AI 可能在页面里直接新增接口调用；只做前端按钮隐藏；没有检查后端权限注解；新增敏感操作但没有操作日志；用代码生成器生成 CRUD 后直接上线。
|
||||
今天要把这些隐性开发要求写成中文规则，让 TRAE 在后续协作中长期遵守。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 今天三个关键词
|
||||
|
||||
<div class="grid grid-cols-3 gap-6 mt-10">
|
||||
<div class="text-center p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||||
<div class="text-2xl mb-2">🎯</div>
|
||||
<div class="font-bold">上下文</div>
|
||||
<div class="text-xs text-gray-400">决定 AI 看什么</div>
|
||||
</div>
|
||||
<div class="text-center p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
<div class="text-2xl mb-2">📏</div>
|
||||
<div class="font-bold">规则</div>
|
||||
<div class="text-xs text-gray-400">决定 AI 怎么做</div>
|
||||
</div>
|
||||
<div class="text-center p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
|
||||
<div class="text-2xl mb-2">📦</div>
|
||||
<div class="font-bold">资产化</div>
|
||||
<div class="text-xs text-gray-400">决定团队怎么复用</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
今天仍然是三个关键词。
|
||||
上下文决定 AI 看什么：看整个若依项目，还是只看用户管理模块，还是只看某个 Controller。
|
||||
规则决定 AI 怎么做：不能绕过权限、不能遗漏操作日志、不能把前端权限当安全边界。
|
||||
资产化决定团队怎么复用：好的 Prompt、rules、报告模板都应该进入团队资产库。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 模块 1：若依任务为什么要讲清楚？
|
||||
|
||||
<div class="mt-6 p-4 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
|
||||
|
||||
**模糊任务：** 帮我优化用户管理模块
|
||||
|
||||
**问题：** 目标不清 · 范围不清 · 约束不清 · 输出不清 · 验收不清
|
||||
</div>
|
||||
|
||||
<!--
|
||||
在若依项目里，如果你直接问“帮我优化用户管理模块”，AI 很难给出可靠结果。
|
||||
优化什么？权限？接口？页面？表单？数据权限？操作日志？代码结构？测试？
|
||||
范围不清，AI 就会自由发挥。
|
||||
所以若依这种后台系统，更需要上下文工程。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 好任务五要素
|
||||
|
||||
<div class="mt-8 text-center">
|
||||
<div class="inline-block p-4 rounded-xl bg-blue-500/10 border border-blue-500/30 px-8 text-lg font-bold">
|
||||
好任务 = 目标 + 范围 + 约束 + 输出格式 + 验收标准
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
一个合格的 AI 编程任务，必须包含五要素。
|
||||
目标：到底要分析或修改什么。
|
||||
范围：只看哪些模块，不看哪些模块。
|
||||
约束：不能做什么，必须遵守什么。
|
||||
输出格式：报告、表格、代码 diff、测试用例。
|
||||
验收标准：什么结果算合格。
|
||||
这五项越清楚，AI 输出越稳定。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依坏 Prompt 示例
|
||||
|
||||
<div class="mt-6 p-4 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
|
||||
|
||||
```
|
||||
@workspace 帮我检查若依权限有没有问题。
|
||||
```
|
||||
|
||||
问题：权限包含页面权限、按钮权限、接口权限、数据权限。"有没有问题"太泛。
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这个 Prompt 看起来合理，但其实太大。
|
||||
“权限”包含页面权限、按钮权限、接口权限、数据权限。
|
||||
“有没有问题”也太泛：是安全风险、实现缺陷、配置问题，还是调用链路不清？
|
||||
没有范围，没有约束，没有输出格式，也没有验收标准。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依好 Prompt 示例
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
|
||||
|
||||
```
|
||||
@workspace 请分析若依"用户管理页面按钮权限"的调用链路。
|
||||
范围：只分析用户管理页面的新增、修改、删除按钮权限。
|
||||
约束：不修改代码；结论标注文件和函数；区分前端权限和后端接口权限。
|
||||
输出：表格。
|
||||
验收：覆盖按钮、权限字符、前端判断、后端接口、权限注解、不确定点。
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这个 Prompt 就清楚很多。
|
||||
目标是用户管理页面按钮权限，不是整个权限系统。
|
||||
范围限定新增、修改、删除按钮。
|
||||
约束要求不修改代码，结论标注文件和函数，区分前端权限和后端权限。
|
||||
验收标准要求覆盖按钮、权限字符、前端判断、后端接口、权限注解和不确定点。
|
||||
这就是合格任务。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 上下文组织清单
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
| 要素 | 说明 |
|
||||
|------|------|
|
||||
| 目标 | 到底要分析或修改什么 |
|
||||
| 范围 | 只看哪些模块 |
|
||||
| 输入文件 | 提供哪些文件 |
|
||||
| 约束 | 不能做什么 |
|
||||
| 输出格式 | 报告/表格/diff |
|
||||
| 验收标准 | 什么结果算合格 |
|
||||
| 不确定点 | 需要人工判断的 |
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
以后大家在若依项目里使用 TRAE，可以先填这张清单。
|
||||
比如分析角色权限保存链路，需要提供角色页面、角色 API、后端角色 Controller、Service、菜单关系表、操作日志相关代码。
|
||||
同时要约束 AI：不要改代码，不要猜，不要把按钮权限当安全边界。
|
||||
-->
|
||||
@@ -0,0 +1,76 @@
|
||||
# 若依版 rules 核心条款
|
||||
|
||||
<div class="mt-4 space-y-2 text-sm">
|
||||
<div class="p-2 rounded-lg bg-blue-900/20 border border-blue-500/30">1. 前端按钮权限不是安全边界</div>
|
||||
<div class="p-2 rounded-lg bg-blue-900/20 border border-blue-500/30">2. 敏感接口必须检查后端权限</div>
|
||||
<div class="p-2 rounded-lg bg-blue-900/20 border border-blue-500/30">3. 敏感操作必须检查操作日志</div>
|
||||
<div class="p-2 rounded-lg bg-blue-900/20 border border-blue-500/30">4. 列表查询必须考虑数据权限</div>
|
||||
<div class="p-2 rounded-lg bg-blue-900/20 border border-blue-500/30">5. 代码生成结果不得直接上线</div>
|
||||
<div class="p-2 rounded-lg bg-blue-900/20 border border-blue-500/30">6. 不确定内容必须标注</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依版 rules 的核心条款可以浓缩成六句：
|
||||
前端按钮权限不是安全边界。
|
||||
敏感接口必须检查后端权限。
|
||||
敏感操作必须检查操作日志。
|
||||
列表查询必须考虑数据权限。
|
||||
代码生成结果不得直接上线。
|
||||
不确定内容必须标注。
|
||||
只要这六条落实，AI 在若依项目里的使用风险会明显降低。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 第 2 天交付物
|
||||
|
||||
<div class="grid grid-cols-2 gap-3 mt-6 text-sm">
|
||||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">01 上下文组织清单</div>
|
||||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">02 上下文引用模板</div>
|
||||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">03 幻觉控制 Prompt</div>
|
||||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">04 gitignore 忽略配置样例</div>
|
||||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">05 若依中文安全规则</div>
|
||||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">06 若依编码测试规则</div>
|
||||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">07 若依前端规则</div>
|
||||
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">08 若依 AI 资产库目录</div>
|
||||
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">09 规则验收清单</div>
|
||||
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">10 若依版 rules.md v0.1</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
第 2 天最终交付十个产物。
|
||||
它们不是零散作业，而是一套若依项目 AI 协作规范资产。
|
||||
以后团队在若依或类似后台系统中使用 TRAE，就可以复用这些清单、Prompt、规则和模板。
|
||||
-->
|
||||
|
||||
---
|
||||
layout: center
|
||||
class: text-center
|
||||
---
|
||||
|
||||
# 两天课程总结
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-8 text-left max-w-3xl mx-auto">
|
||||
<div class="p-4 rounded-xl bg-white/5 border border-white/10">
|
||||
|
||||
**第 1 天：用 TRAE 看懂若依**
|
||||
- 看结构 · 找入口 · 追链路 · 查依据
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
|
||||
**第 2 天：让 TRAE 按规则参与若依研发**
|
||||
- 组织上下文 · 控制幻觉 · 编写 rules · 沉淀资产
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<br/>
|
||||
|
||||
> **最终能力：读得懂 · 问得准 · 查得实 · 改得稳 · 可复用**
|
||||
|
||||
<!--
|
||||
两天课程到这里形成闭环。
|
||||
第一天，我们学习如何用 TRAE 看懂若依代码：看结构、找入口、追链路、查依据。
|
||||
第二天，我们学习如何让 TRAE 按团队规则参与若依研发：组织上下文、控制幻觉、编写 rules、沉淀资产。
|
||||
最终目标是五个字：读得懂，问得准，查得实，改得稳，可复用。
|
||||
这就是 AI 编程在企业研发里的真正价值。
|
||||
-->
|
||||
@@ -0,0 +1,106 @@
|
||||
# 模块 2：四类上下文
|
||||
|
||||
<div class="grid grid-cols-2 gap-4 mt-6 text-sm">
|
||||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||||
|
||||
**@workspace：找路** — 找入口、文件、模块
|
||||
</div>
|
||||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
|
||||
**#File：看文件** — 分析文件间调用关系
|
||||
</div>
|
||||
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">
|
||||
|
||||
**#Code：抠细节** — 分析某个方法
|
||||
</div>
|
||||
<div class="p-3 rounded-xl bg-purple-500/10 border border-purple-500/30">
|
||||
|
||||
**#Web：查外部** — 查框架文档，但必须回代码验证
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依项目比较大，所以更要正确选择上下文。
|
||||
@workspace 用来找入口，比如找 getInfo、getRouters、按钮权限指令。
|
||||
#File 用来分析相关文件，比如用户管理页面和用户 Controller。
|
||||
#Code 用来分析某个方法，比如 handleLogin 或某个权限判断函数。
|
||||
#Web 用来查框架文档或最佳实践，但不能替代项目代码依据。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# @workspace 找路示例
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
|
||||
|
||||
```
|
||||
@workspace 请找出若依中与"用户登录后菜单路由生成"相关的前后端文件。
|
||||
要求：标注文件路径 · 标注函数或类名 · 区分事实和推测 · 列出不确定点
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这个 Prompt 适合任务早期。
|
||||
我们不知道具体文件在哪里，就让 @workspace 先找入口。
|
||||
它应该帮我们找出前端登录、权限 store、路由守卫、getRouters API，以及后端菜单路由接口相关文件。
|
||||
但所有结论都必须标注依据。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# #File 聚焦示例
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
|
||||
|
||||
```
|
||||
#File 请分析这些文件中登录、用户信息、菜单路由的调用关系。
|
||||
重点：谁调用login · 谁调用getInfo · 谁调用getRouters ·
|
||||
权限信息保存在哪里 · 路由在哪里动态生成
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
当我们找到相关文件后，就用 #File 聚焦。
|
||||
这时目标不是全局找，而是分析这些文件之间的调用关系。
|
||||
谁调用 login，谁调用 getInfo，谁调用 getRouters，权限信息保存在哪里，路由在哪里动态生成。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# #Code 抠细节示例
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
|
||||
|
||||
```
|
||||
#Code 请分析 handleLogin 函数。
|
||||
重点：参数来源 · 调用哪个API · token如何保存 ·
|
||||
失败如何处理 · loading是否恢复 · 登录成功后跳转哪里
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
如果我们只分析登录函数，就用 #Code。
|
||||
重点看参数来源、API 调用、token 保存、失败处理、loading 恢复和登录成功后的跳转。
|
||||
这类函数级分析非常适合发现细节风险。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# #Web 使用边界
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
**可查：** Spring Security 权限实践 · Vue Router 动态路由 · 前端按钮权限最佳实践
|
||||
|
||||
**但：** 若依当前实现必须回到代码验证。外部资料只能提供参考，不能替代项目事实。
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
#Web 可以查外部资料，比如 Spring Security 权限实践、Vue Router 动态路由、按钮权限最佳实践。
|
||||
但若依当前实现如何，必须回到代码里验证。
|
||||
外部资料只能提供参考，不能替代项目事实。
|
||||
-->
|
||||
@@ -0,0 +1,113 @@
|
||||
# 模块 3：若依场景中的幻觉死循环
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
**常见表现：**
|
||||
- AI 说所有接口都有权限校验 → 但不给 Controller 依据
|
||||
- AI 说操作日志完整 → 但不给注解或 AOP 依据
|
||||
- AI 说按钮权限安全 → 但只看到前端代码
|
||||
</div>
|
||||
|
||||
<!--
|
||||
在若依项目里，AI 很容易因为它“知道若依是权限系统”就过度自信。
|
||||
它说所有接口都有权限校验，但不给 Controller 依据。
|
||||
它说操作日志完整，但不给注解或 AOP 依据。
|
||||
它说按钮权限安全，但只看到了前端按钮隐藏。
|
||||
这就是需要切断的幻觉。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 幻觉控制顺序
|
||||
|
||||
<div class="grid grid-cols-3 gap-4 mt-10">
|
||||
<div class="text-center p-6 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||||
<div class="text-2xl mb-2">1️⃣</div>
|
||||
<div class="font-bold">先找证据</div>
|
||||
</div>
|
||||
<div class="text-center p-6 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
<div class="text-2xl mb-2">2️⃣</div>
|
||||
<div class="font-bold">再判断原因</div>
|
||||
</div>
|
||||
<div class="text-center p-6 rounded-xl bg-amber-500/10 border border-amber-500/30">
|
||||
<div class="text-2xl mb-2">3️⃣</div>
|
||||
<div class="font-bold">最后给方案</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
遇到这种情况，不要继续让 AI 给结论。
|
||||
先让它找证据：文件、类、方法、注解、调用关系。
|
||||
然后再判断问题。
|
||||
最后才给方案。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依证据收集 Prompt
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
|
||||
|
||||
```
|
||||
请先不要修改代码。请围绕"用户管理删除按钮权限"收集证据：
|
||||
1. 前端按钮在哪个页面
|
||||
2. 使用了哪个权限字符
|
||||
3. 前端如何判断按钮显示
|
||||
4. 后端删除接口在哪里
|
||||
5. Controller 是否有权限注解
|
||||
6. 是否记录操作日志
|
||||
7. 无法确认的内容
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这是若依场景下的证据收集 Prompt。
|
||||
它没有直接问“有没有风险”，而是先要求 AI 找证据。
|
||||
前端按钮在哪里，权限字符是什么，前端怎么判断，后端删除接口在哪里，Controller 是否有权限注解，是否记录操作日志，哪些无法确认。
|
||||
这些证据收集完，才能判断风险。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 原因判断 Prompt
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
|
||||
|
||||
```
|
||||
请基于证据判断风险：
|
||||
- 每个风险必须对应文件、函数或注解
|
||||
- 区分已确认事实和推测
|
||||
- 无法确认的内容写入不确定点
|
||||
- 不要直接下安全结论
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
第二步是原因判断。
|
||||
比如发现前端按钮有权限字符，但后端删除接口没有找到权限注解。
|
||||
这时可以说“存在接口级权限待确认风险”，但不能直接说“系统不安全”。
|
||||
如果没有看到后端文件，也要写无法确认，而不是猜测。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 方案生成 Prompt
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
|
||||
|
||||
```
|
||||
请基于已确认风险给出方案：
|
||||
修改文件 · 修改方法 · 新增或调整权限注解 ·
|
||||
是否需要操作日志 · 影响范围 · 验证方式 · 测试建议
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
第三步才给方案。
|
||||
如果确认证据显示后端接口缺少权限注解，才建议补权限注解。
|
||||
如果敏感操作缺少日志，才建议补操作日志。
|
||||
每个方案都要说明文件、方法、影响范围、验证方式和测试建议。
|
||||
-->
|
||||
@@ -0,0 +1,34 @@
|
||||
# 模块 4：若依项目哪些文件不能提交？
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
- .env · application-dev.yml 中真实密码 · 数据库账号 · Redis 密码
|
||||
- target/ · node_modules/ · dist/
|
||||
- 日志文件 · IDE 本地配置
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依项目里，忽略配置同样重要。
|
||||
后端可能有 application-dev.yml、本地数据库账号、Redis 密码。前端有 node_modules、dist。后端有 target。还有日志文件和 IDE 配置。
|
||||
这些都不应该进入仓库，更不应该进入 AI 上下文。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依忽略配置检查 Prompt
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
|
||||
|
||||
```
|
||||
@workspace 请检查若依项目的 .gitignore 是否完整。
|
||||
重点检查：后端target · 前端node_modules/dist ·
|
||||
日志文件 · 本地配置 · 数据库密码 · Redis密码 · IDE配置
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
可以让 TRAE 检查若依项目的 .gitignore。
|
||||
重点看后端 target、前端 node_modules 和 dist、日志文件、本地配置、数据库密码、Redis 密码、IDE 配置。
|
||||
同样，不要让 AI 直接改，先给审查报告。
|
||||
-->
|
||||
@@ -0,0 +1,49 @@
|
||||
# 模块 5：若依安全规则重点
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
账号密码 · Token · 接口权限注解 · 菜单与按钮权限 · 数据权限 · 操作日志 · 敏感配置 · 日志脱敏
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依安全规则和一般前端项目不完全一样。
|
||||
它必须重点关注账号密码、token、接口权限注解、菜单与按钮权限、数据权限、操作日志、敏感配置、日志脱敏。
|
||||
尤其是权限与日志，是后台管理系统的核心。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 中文安全规则示例
|
||||
|
||||
<div class="mt-4 space-y-3 text-sm">
|
||||
<div class="p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">前端按钮权限只能作为交互控制，不能作为安全边界</div>
|
||||
<div class="p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">涉及用户、角色、菜单、部门、岗位等敏感接口时，必须检查后端 Controller 是否存在权限控制</div>
|
||||
<div class="p-3 rounded-lg bg-blue-900/20 border border-blue-500/30">涉及新增、修改、删除、导出等操作时，必须检查是否记录操作日志</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这些规则可以直接写进 .trae/rules.md。
|
||||
第一，前端按钮权限只能作为交互控制，不能作为安全边界。
|
||||
第二，涉及用户、角色、菜单、部门、岗位等敏感接口时，必须检查后端 Controller 是否存在权限控制。
|
||||
第三，涉及新增、修改、删除、导出等操作时，必须检查是否记录操作日志。
|
||||
这些规则非常适合若依。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 敏感配置规则
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
- 禁止在源码中硬编码数据库密码、Redis 密码、JWT 密钥、第三方密钥
|
||||
- 不得提交真实 application-dev.yml、.env、本地配置文件
|
||||
- 示例配置必须使用占位符
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依项目通常有后端配置文件，所以敏感配置规则也很重要。
|
||||
禁止在源码中硬编码数据库密码、Redis 密码、JWT 密钥、第三方密钥。
|
||||
不得提交真实 application-dev.yml、.env、本地配置文件。
|
||||
示例配置必须使用占位符。
|
||||
-->
|
||||
@@ -0,0 +1,43 @@
|
||||
# 模块 6：若依编码规则重点
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
前端 api 分层 · 后端 Controller/Service/Mapper 分层 · 权限注解 · 操作日志注解 · 数据权限 · 字典使用 · 代码生成规范
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依的编码规则要结合它的项目结构。
|
||||
前端接口应放在 api 目录，不应该页面里直接写请求。
|
||||
后端要遵守 Controller、Service、Mapper 分层。
|
||||
敏感接口要关注权限注解和操作日志注解。
|
||||
列表查询要关注数据权限。
|
||||
固定枚举值尽量使用字典。
|
||||
代码生成结果不能直接上线，要人工检查权限、日志、校验和测试。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依测试规则重点
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
- 登录成功/失败
|
||||
- 无权限访问接口
|
||||
- 按钮权限显示
|
||||
- 角色授权变化
|
||||
- 数据权限范围
|
||||
- 操作日志记录
|
||||
- 代码生成 CRUD
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依测试规则应该围绕权限和后台管理流程。
|
||||
登录要测成功和失败。
|
||||
无权限访问接口要返回拒绝。
|
||||
按钮权限显示要和权限字符匹配。
|
||||
角色授权变化后，菜单和按钮权限应变化。
|
||||
数据权限要验证不同角色看到的数据范围。
|
||||
敏感操作要验证操作日志记录。
|
||||
代码生成 CRUD 要验证增删改查、权限和日志。
|
||||
-->
|
||||
@@ -0,0 +1,41 @@
|
||||
# 模块 7：若依前端规则重点
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
api 目录调用 · 权限指令 · 动态路由 · 列表 loading · 表单校验 · 删除二次确认 · 导出权限 · 字典显示
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依前端规则应覆盖这些点。
|
||||
接口调用要放 api 目录。
|
||||
按钮权限要使用项目已有权限指令或权限方法。
|
||||
动态路由不能随意绕过。
|
||||
列表页必须有 loading、空状态、错误处理。
|
||||
表单必须有校验。
|
||||
删除必须二次确认。
|
||||
导出按钮要有权限控制。
|
||||
字典字段要使用统一字典显示。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 用户管理页面规则示例
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
- 新增、修改、删除、导出按钮必须使用权限控制
|
||||
- 删除必须二次确认
|
||||
- 提交失败后恢复 loading
|
||||
- 修改用户后刷新列表
|
||||
- 敏感字段不得明文展示或输出日志
|
||||
</div>
|
||||
|
||||
<!--
|
||||
以用户管理页面为例。
|
||||
新增、修改、删除、导出按钮必须使用权限控制。
|
||||
删除必须二次确认。
|
||||
提交失败后 loading 必须恢复。
|
||||
修改用户后列表必须刷新。
|
||||
密码、手机号、邮箱等敏感字段不得随意明文展示或输出日志。
|
||||
-->
|
||||
@@ -0,0 +1,39 @@
|
||||
# 模块 8：若依资产库建议
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
建议沉淀：若依结构分析 Prompt · 登录权限链路 Prompt · 菜单路由分析 Prompt · 按钮权限检查 Prompt · 操作日志检查 Prompt · 代码生成 Review 清单 · 若依 rules.md
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
若依案例非常适合沉淀资产。
|
||||
比如若依结构分析 Prompt、登录权限链路 Prompt、菜单路由分析 Prompt、按钮权限检查 Prompt、操作日志检查 Prompt、代码生成 Review 清单、若依 rules.md。
|
||||
这些资产以后可以直接用于公司内部类似后台管理系统。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依资产库目录
|
||||
|
||||
<div class="mt-4 text-sm">
|
||||
|
||||
```
|
||||
ai-dev-assets/
|
||||
├── prompts/若依/
|
||||
├── rules/若依/
|
||||
├── templates/若依/
|
||||
├── checklists/若依/
|
||||
└── examples/若依/
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
建议企业资产库里单独有一个若依目录。
|
||||
prompts 存若依相关 Prompt。
|
||||
rules 存若依 rules.md。
|
||||
templates 存若依代码理解报告、权限链路报告模板。
|
||||
checklists 存权限检查、日志检查、代码生成检查清单。
|
||||
examples 存优秀案例和反面案例。
|
||||
-->
|
||||
@@ -0,0 +1,76 @@
|
||||
# 模块 9：若依坏规则示例
|
||||
|
||||
<div class="mt-6 p-4 rounded-xl bg-red-500/10 border border-red-500/30 text-sm">
|
||||
|
||||
- 注意权限安全
|
||||
- 代码要规范
|
||||
- 日志要完整
|
||||
- 数据权限要合理
|
||||
- 生成代码要检查
|
||||
|
||||
方向没错，但不可执行。
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这些话方向没错，但不可执行。
|
||||
“注意权限安全”太泛。
|
||||
“日志要完整”没有说明哪些操作必须记录。
|
||||
“数据权限要合理”没有判断标准。
|
||||
“生成代码要检查”没有检查项。
|
||||
所以要改成明确规则。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依好规则示例
|
||||
|
||||
<div class="mt-6 p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
|
||||
|
||||
- 涉及用户、角色、菜单、部门、岗位的新增、修改、删除、导出接口时，必须检查后端权限控制和操作日志记录
|
||||
- 涉及列表查询时，必须确认是否需要数据权限过滤
|
||||
- 代码生成结果上线前，必须检查权限、日志、表单校验、异常处理和测试
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这就是更好的规则。
|
||||
它有触发场景：用户、角色、菜单、部门、岗位相关接口。
|
||||
它有必须动作：检查后端权限控制和操作日志。
|
||||
它能被检查：看 Controller、注解、Service 和日志配置。
|
||||
这类规则才适合写进 .trae/rules.md。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依 rules 检查 Prompt
|
||||
|
||||
<div class="mt-4 p-4 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
|
||||
|
||||
```
|
||||
@workspace 请检查当前 .trae/rules.md 是否适合若依项目。
|
||||
重点检查：权限规则 · 操作日志规则 · 数据权限规则 ·
|
||||
前端按钮权限规则 · 代码生成规则 · 敏感配置规则
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这是让 TRAE 检查若依 rules 的 Prompt。
|
||||
重点检查权限规则、操作日志规则、数据权限规则、前端按钮权限规则、代码生成规则和敏感配置规则。
|
||||
要求 AI 先给审查报告，不要直接改文件。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 若依版 rules.md 结构
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
0.基础原则 · 1.安全规则 · 2.权限规则 · 3.操作日志规则 · 4.编码规则 · 5.前端规则 · 6.测试规则 · 7.代码生成规则 · 8.不确定性处理规则
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
今天最终产出是若依版 .trae/rules.md v0.1。
|
||||
它比通用 rules 多了几个若依特色部分：权限规则、操作日志规则、代码生成规则。
|
||||
这份 rules 后续可以作为团队后台管理系统 AI 协作规范的基础。
|
||||
-->
|
||||
@@ -0,0 +1,215 @@
|
||||
# AI 编程已进入主流阶段
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-6">
|
||||
<div class="space-y-4">
|
||||
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||||
<div class="text-2xl font-bold">84%</div>
|
||||
<div class="text-sm text-gray-400">受访者已使用或计划使用 AI 工具（Stack Overflow 2025）</div>
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||||
<div class="text-2xl font-bold">51%</div>
|
||||
<div class="text-sm text-gray-400">职业开发者每天使用 AI 工具</div>
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||||
<div class="text-2xl font-bold">80%</div>
|
||||
<div class="text-sm text-gray-400">新开发者第一周使用 Copilot（GitHub 2025）</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="mt-4 space-y-3 text-sm">
|
||||
|
||||
**过去** → 少数人尝鲜 AI 补全
|
||||
|
||||
**现在** → 大量开发者日常使用 AI 工具
|
||||
|
||||
**趋势** → AI 编程从"工具能力"变成"研发基础设施"
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
Stack Overflow 2025 调查显示，84% 的受访者已经在使用或计划使用 AI 工具，其中 51% 的职业开发者每天使用 AI 工具。GitHub 2025 Octoverse 也显示新加入 GitHub 的开发者中，接近 80% 会在第一周使用 Copilot。
|
||||
|
||||
这里我们不需要把 AI 神化，但它的普及速度很快，正在改变研发人员的基本工作方式。以前一个工程师的能力更多体现在自己写代码、自己查资料、自己读项目；现在逐渐变成会不会描述问题、会不会给 AI 足够上下文、会不会判断 AI 输出是否可信、会不会把 AI 产出转化成可交付成果。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# AI 编程工具三阶段演进
|
||||
|
||||
<div class="flex items-center justify-between mt-12 px-4">
|
||||
<div class="text-center flex-1">
|
||||
<div class="w-16 h-16 rounded-full bg-blue-900/50 border-2 border-blue-500 flex items-center justify-center mx-auto text-xl">📝</div>
|
||||
<div class="mt-3 font-bold">阶段 1：代码补全</div>
|
||||
<div class="text-sm text-gray-400">帮你补几行代码</div>
|
||||
</div>
|
||||
<div class="text-blue-400 text-xl">→</div>
|
||||
<div class="text-center flex-1">
|
||||
<div class="w-16 h-16 rounded-full bg-emerald-900/50 border-2 border-emerald-500 flex items-center justify-center mx-auto text-xl">💬</div>
|
||||
<div class="mt-3 font-bold">阶段 2：对话助手</div>
|
||||
<div class="text-sm text-gray-400">解释、生成、改写</div>
|
||||
</div>
|
||||
<div class="text-blue-400 text-xl">→</div>
|
||||
<div class="text-center flex-1">
|
||||
<div class="w-16 h-16 rounded-full bg-amber-900/50 border-2 border-amber-500 flex items-center justify-center mx-auto text-xl">🤖</div>
|
||||
<div class="mt-3 font-bold">阶段 3：研发 Agent</div>
|
||||
<div class="text-sm text-gray-400">计划·修改·测试·验证·提交</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
早期的 AI 编程主要是代码补全，你写一半，它帮你补几行。后来变成聊天式助手，你可以问它这个函数是什么意思、这个报错怎么解决、帮我写一个测试用例。现在进入第三个阶段：Agent 化。
|
||||
|
||||
Agent 不是简单回答问题，而是可以围绕一个任务执行多步操作：理解需求、检索代码、制定修改计划、改代码、运行检查、解释变更、辅助提交。
|
||||
|
||||
GitHub Copilot 已强调 agent mode，Gartner 对 AI code assistants 的定义覆盖生成、分析、调试、测试、修复、重构、文档、依赖搜索、代码评审等研发环节。所以今天我们学习 TRAE，不能只学"怎么让它写一段代码"，更重要的是学怎么让 AI 读懂一个项目、找到正确上下文、追踪调用链路、判断 AI 的回答是否可信。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# AI 能效不是单点提速
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-6">
|
||||
<div>
|
||||
|
||||
### 不是只看
|
||||
|
||||
- 代码写得更快
|
||||
|
||||
### 更要看
|
||||
|
||||
- 理解更快 · 交接更快
|
||||
- 测试更快 · 文档更快
|
||||
- 风险发现更早
|
||||
- 知识传递成本更低
|
||||
</div>
|
||||
<div class="space-y-4">
|
||||
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||||
<div class="text-3xl font-bold text-blue-400">55.8%</div>
|
||||
<div class="text-sm text-gray-400">使用 Copilot 完成编程任务速度提升（Microsoft Research）</div>
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
|
||||
<div class="text-3xl font-bold text-amber-400">75%</div>
|
||||
<div class="text-sm text-gray-400">预计 2028 年企业工程师使用 AI（Gartner）</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一页讲的是"能效"。过去讲研发效率通常看个人效率：一个人一天写多少代码、一个需求几天完成、一个 bug 多久修复。但 AI 进入研发之后，能效的核心不只是"写代码更快"，而是新人理解项目更快、老项目维护成本下降、重复性编码减少、测试和文档生成成本降低、跨模块知识获取更快、代码评审和风险识别前置。
|
||||
|
||||
Microsoft Research 与 GitHub 的受控实验显示，使用 Copilot 的开发者完成指定编程任务的速度比对照组快 55.8%。Gartner 预测到 2028 年，75% 的企业软件工程师将使用 AI code assistants。
|
||||
|
||||
要点：不要把 AI 提效理解成单纯"多写代码"。真正的组织价值在于降低理解成本、沟通成本、质量成本和维护成本。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 积极拥抱，但不盲目乐观
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-6">
|
||||
<div>
|
||||
|
||||
**AI 会替代：**
|
||||
|
||||
- 重复性编码
|
||||
- 低上下文任务
|
||||
- 模板化文档
|
||||
- 简单测试生成
|
||||
- 初步代码解释
|
||||
</div>
|
||||
<div>
|
||||
|
||||
**AI 仍需要人负责：**
|
||||
|
||||
- 业务判断
|
||||
- 架构取舍
|
||||
- 安全边界
|
||||
- 质量责任
|
||||
- 上线决策
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一页要稳。不要制造恐慌，也不要说 AI 没影响。
|
||||
|
||||
建议表达：我们不用把 AI 看成一个马上替代所有工程师的东西，也不能把它看成一个可有可无的插件。更现实的判断是——会使用 AI 的工程师，会逐渐替代不会使用 AI 的工作方式；会组织 AI 工作流的团队，会逐渐替代低效率的传统研发流程。
|
||||
|
||||
核心表达：被替代的不是"工程师这个人"，而是低效、重复、缺乏判断的工作方式。AI 会替代一部分重复性、低上下文、低判断含量的工作，但不会在短期内替代所有工程判断、业务理解和系统责任。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 工程师角色正在变化
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-8">
|
||||
<div class="p-4 rounded-xl bg-white/5 border border-white/10">
|
||||
|
||||
**过去：**
|
||||
|
||||
- 主要靠自己写、查、改、测
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
|
||||
**现在：**
|
||||
|
||||
- 会描述任务
|
||||
- 会提供上下文
|
||||
- 会拆解问题
|
||||
- 会验证 AI 输出
|
||||
- 会把 AI 结果工程化
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这是从"编码执行者"向"AI 协同工程师"的变化。
|
||||
|
||||
以前一个工程师的核心能力是自己写、自己查、自己改、自己测；现在工程师的核心能力变成会不会把问题描述清楚、会不会把上下文组织好、会不会把大任务拆成 AI 可执行的小任务、会不会判断 AI 输出是否可信、能不能把 AI 产出最终工程化交付。
|
||||
|
||||
这是今天我们整门课程要训练的底层能力，也是 AI 时代研发人员的新基本功。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# AI 时代
|
||||
|
||||
<div class="mt-6 space-y-4 text-sm">
|
||||
<div class="p-3 rounded-lg bg-white/5 border border-white/10">AI 编程不是单个工具采购问题，而是研发能效体系升级问题</div>
|
||||
<div class="p-3 rounded-lg bg-white/5 border border-white/10">AI 不只是提升个人编码速度，更重要的是降低组织的知识传递成本和项目理解成本</div>
|
||||
<div class="p-3 rounded-lg bg-white/5 border border-white/10">未来的差距，不一定是用不用 AI，而是能不能把 AI 嵌入标准研发流程</div>
|
||||
<div class="p-3 rounded-lg bg-white/5 border border-white/10">不是盲目追求 AI 替代人，而是让 AI 替代低价值重复劳动，让人聚焦业务判断</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一页是面向高管和决策层的话术收口。
|
||||
|
||||
这四句话比较稳，既能让高管听到能效趋势，也不会让工程师产生强烈抵触。核心表达：AI 编程不是单个工具采购问题，而是研发能效体系升级问题；不只是提升个人编码速度，更重要的是降低组织的知识传递成本和项目理解成本；未来的差距，不一定是用不用 AI，而是能不能把 AI 嵌入标准研发流程；不是盲目追求 AI 替代人，而是让 AI 替代低价值重复劳动，让人聚焦业务判断、架构质量和交付责任。
|
||||
|
||||
衔接下一节：所以今天我们不从"让 AI 写代码"开始，而是从"让 AI 帮我们理解代码"开始。因为在企业真实研发里，理解陌生项目、识别调用链路、判断风险影响，是比写几行代码更底层的能力。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 为什么第一天先讲陌生代码库理解？
|
||||
|
||||
<div class="mt-6">
|
||||
|
||||
企业研发最常见的成本：
|
||||
|
||||
- 接手旧项目 · 理解陌生模块
|
||||
- 追踪调用链路 · 判断影响范围
|
||||
- 识别风险点 · 沉淀文档
|
||||
|
||||
<div class="grid grid-cols-3 gap-4 mt-6">
|
||||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-center font-bold">AI 提效能力</div>
|
||||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-center font-bold">工程理解能力</div>
|
||||
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-center font-bold">风险判断能力</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
企业研发里，真正消耗大量时间的，往往不是从零写一个 demo，而是接手旧项目、理解陌生模块、定位调用链路、判断改动影响面、识别风险点、补测试、写交接文档。这些工作恰恰是 AI 最适合辅助、但也最需要人工判断的地方。
|
||||
|
||||
所以今天从"理解陌生代码库"开始，是因为它同时覆盖三个能力：AI 提效能力、工程理解能力、风险判断能力。这正是 TRAE 这类 AI IDE 最适合切入的地方，也是工程师最需要掌握的新基本功。
|
||||
|
||||
对管理层来说，它关系到组织能效；对工程师来说，它关系到个人能力升级；对公司来说，它关系到研发质量和交付速度。
|
||||
-->
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
theme: penguin
|
||||
colorSchema: light
|
||||
title: AI 编程时代的研发能效升级
|
||||
info: |
|
||||
## TRAE 企业内训课程
|
||||
从工具使用到研发工作方式变化
|
||||
transition: slide-left
|
||||
mdc: true
|
||||
drawings:
|
||||
persist: false
|
||||
themeConfig:
|
||||
twitter: ''
|
||||
twitterUrl: ''
|
||||
layout: intro
|
||||
---
|
||||
|
||||
# AI 编程时代的研发能效升级
|
||||
|
||||
从工具使用到研发工作方式变化
|
||||
|
||||
<div class="pt-4 text-sm op-60">TRAE 企业内训系列课程 · 沉浸式 · 实战驱动 · 可交付</div>
|
||||
|
||||
|
||||
|
||||
---
|
||||
src: ./pages/preface.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day1/m1-trae-positioning.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day1/m2-ruoyi-objects.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day1/m3-workspace-structure.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day1/m4-call-chain.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day1/m5-ai-reliability.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day1/m6-code-report.md
|
||||
---
|
||||
|
||||
---
|
||||
layout: new-section
|
||||
---
|
||||
|
||||
# 第 2 天：TRAE 上下文工程与规则体系
|
||||
|
||||
---
|
||||
src: ./pages/day2/m1-context-engineering.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day2/m2-four-references.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day2/m3-hallucination.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day2/m4-gitignore.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day2/m5-security-rules.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day2/m6-coding-rules.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day2/m7-frontend-rules.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day2/m8-asset-library.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day2/m9-rules-check.md
|
||||
---
|
||||
|
||||
---
|
||||
src: ./pages/day2/m10-summary.md
|
||||
---
|
||||
@@ -0,0 +1,12 @@
|
||||
/* eslint-disable no-console */
|
||||
|
||||
// #region snippet
|
||||
// Inside ./snippets/external.ts
|
||||
export function emptyArray<T>(length: number) {
|
||||
return Array.from<T>({ length })
|
||||
}
|
||||
// #endregion snippet
|
||||
|
||||
export function sayHello() {
|
||||
console.log('Hello from snippets/external.ts')
|
||||
}
|
||||
@@ -0,0 +1,17 @@
|
||||
/* Penguin Light 主题企业风格微调 */
|
||||
|
||||
.slidev-layout {
|
||||
font-family: 'PingFang SC', 'Microsoft YaHei', 'Noto Sans SC', sans-serif;
|
||||
}
|
||||
|
||||
.slidev-layout h1 {
|
||||
font-weight: 700 !important;
|
||||
}
|
||||
|
||||
.slidev-layout li {
|
||||
margin-bottom: 0.4rem;
|
||||
}
|
||||
|
||||
.slidev-layout pre {
|
||||
border-radius: 0.5rem;
|
||||
}
|
||||
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"rewrites": [
|
||||
{ "source": "/(.*)", "destination": "/index.html" }
|
||||
],
|
||||
"buildCommand": "npm run build",
|
||||
"outputDirectory": "dist"
|
||||
}
|
||||
@@ -0,0 +1,5 @@
|
||||
import svgLoader from 'vite-svg-loader'
|
||||
|
||||
export default {
|
||||
plugins: [svgLoader()],
|
||||
}
|
||||
@@ -0,0 +1,535 @@
|
||||
# 前言
|
||||
|
||||
|
||||
```Plain Text
|
||||
AI 编程已经从“尝鲜工具”进入“研发基础设施”阶段。
|
||||
AI 不只是提高个人写代码速度，而是在重构研发组织的能效模型。
|
||||
今天学习 TRAE，不是为了替代工程师，而是让工程师掌握被 AI 放大的工作方式。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 第 0 部分：AI 编程行业趋势与能效变革破冰
|
||||
|
||||
# 一、开场定位
|
||||
|
||||
## 讲师开场话术
|
||||
|
||||
各位领导、各位同事，今天这门课表面上是 TRAE 工具培训，但我更希望大家把它理解成一次研发工作方式升级的起点。
|
||||
|
||||
过去我们讲研发效率，更多讲的是：
|
||||
|
||||
```Plain Text
|
||||
流程优化
|
||||
组件复用
|
||||
低代码平台
|
||||
DevOps 自动化
|
||||
测试自动化
|
||||
```
|
||||
|
||||
但从 2023 年之后，AI 编程工具开始进入研发现场，研发效率的提升方式发生了变化。
|
||||
|
||||
它不再只是“工具帮人少点几下”，而是开始进入：
|
||||
|
||||
```Plain Text
|
||||
需求理解
|
||||
代码阅读
|
||||
代码生成
|
||||
测试生成
|
||||
重构建议
|
||||
代码评审
|
||||
文档生成
|
||||
故障排查
|
||||
```
|
||||
|
||||
这些环节。
|
||||
|
||||
也就是说，AI 编程的影响，不只是让某个工程师写代码快一点，而是开始改变研发组织的能效结构。
|
||||
|
||||
---
|
||||
|
||||
# 二、行业趋势：AI 编程已经进入主流阶段
|
||||
|
||||
## 讲师讲法
|
||||
|
||||
第一点，我们先看行业趋势。
|
||||
|
||||
AI 编程已经不是少数极客在尝鲜，而是正在变成开发者的日常工具。
|
||||
|
||||
Stack Overflow 2025 开发者调查显示，**84% 的受访者已经在使用或计划在开发流程中使用 AI 工具**，其中 **51% 的职业开发者每天使用 AI 工具**。这说明 AI 编程已经从“可选项”变成很多研发团队的“默认工作方式”之一。\([Stack Overflow Insights](https://survey.stackoverflow.co/2025/ai)\)
|
||||
|
||||
GitHub 2025 Octoverse 也显示，生成式 AI 已经成为开发中的标准能力之一：超过 **110 万个公开仓库使用 LLM SDK**，其中近 **69\.4 万个项目是在过去 12 个月创建的**；GitHub 还观察到，新加入 GitHub 的开发者中，接近 **80% 会在第一周使用 Copilot**。\([The GitHub Blog](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/)\)
|
||||
|
||||
## 屏幕展示
|
||||
|
||||
```Plain Text
|
||||
AI 编程已经进入主流阶段
|
||||
|
||||
过去：
|
||||
少数人尝鲜 AI 补全
|
||||
|
||||
现在：
|
||||
大量开发者日常使用 AI 工具
|
||||
|
||||
趋势：
|
||||
AI 编程从“工具能力”变成“研发基础设施”
|
||||
```
|
||||
|
||||
## 讲师补充
|
||||
|
||||
这里我们不需要把 AI 神化。
|
||||
|
||||
AI 不是今天用上，明天整个研发效率就翻倍。
|
||||
|
||||
但它的普及速度很快，而且正在改变研发人员的基本工作方式。
|
||||
|
||||
以前一个工程师的能力更多体现在：
|
||||
|
||||
```Plain Text
|
||||
自己写代码
|
||||
自己查资料
|
||||
自己读项目
|
||||
自己定位问题
|
||||
```
|
||||
|
||||
现在逐渐变成：
|
||||
|
||||
```Plain Text
|
||||
会不会描述问题
|
||||
会不会给 AI 足够上下文
|
||||
会不会判断 AI 输出是否可信
|
||||
会不会把 AI 产出转化成可交付成果
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 三、技术发展：从代码补全到 Agent 工作流
|
||||
|
||||
## 讲师讲法
|
||||
|
||||
第二点，AI 编程工具本身也在升级。
|
||||
|
||||
早期的 AI 编程主要是代码补全。
|
||||
|
||||
你写一半，它帮你补几行。
|
||||
|
||||
后来变成聊天式助手。
|
||||
|
||||
你可以问它：
|
||||
|
||||
```Plain Text
|
||||
这个函数是什么意思？
|
||||
这个报错怎么解决？
|
||||
帮我写一个测试用例。
|
||||
```
|
||||
|
||||
现在进入第三个阶段：**Agent 化**。
|
||||
|
||||
Agent 不是简单回答问题，而是可以围绕一个任务执行多步操作：
|
||||
|
||||
```Plain Text
|
||||
理解需求
|
||||
检索代码
|
||||
制定修改计划
|
||||
改代码
|
||||
运行检查
|
||||
解释变更
|
||||
辅助提交
|
||||
```
|
||||
|
||||
GitHub Copilot 当前已经强调“agent mode”，可以在编辑器中解释概念、补全代码、提出修改并验证文件；Gartner 对 AI code assistants 的定义也已经覆盖生成、分析、调试、测试、修复、重构、文档、依赖搜索、代码评审等研发环节。\(GitHub\)
|
||||
|
||||
## 屏幕展示
|
||||
|
||||
```Plain Text
|
||||
AI 编程工具演进
|
||||
|
||||
阶段 1：代码补全
|
||||
帮你补几行代码
|
||||
|
||||
阶段 2：对话助手
|
||||
帮你解释、生成、改写
|
||||
|
||||
阶段 3：研发 Agent
|
||||
围绕任务完成多步研发动作
|
||||
```
|
||||
|
||||
## 讲师补充
|
||||
|
||||
所以今天我们学习 TRAE，不能只学“怎么让它写一段代码”。
|
||||
|
||||
更重要的是学：
|
||||
|
||||
```Plain Text
|
||||
怎么让 AI 读懂一个项目
|
||||
怎么让 AI 找到正确上下文
|
||||
怎么让 AI 追踪调用链路
|
||||
怎么判断 AI 的回答是否可信
|
||||
```
|
||||
|
||||
这才是企业研发里真正有价值的能力。
|
||||
|
||||
---
|
||||
|
||||
# 四、能效理念：AI 不是单点提效，而是组织能效重构
|
||||
|
||||
## 讲师讲法
|
||||
|
||||
第三点，我们讲“能效”。
|
||||
|
||||
过去讲研发效率，通常是看个人效率：
|
||||
|
||||
```Plain Text
|
||||
一个人一天写多少代码
|
||||
一个需求几天完成
|
||||
一个 bug 多久修复
|
||||
```
|
||||
|
||||
但 AI 进入研发之后，能效的核心不只是“写代码更快”，而是：
|
||||
|
||||
```Plain Text
|
||||
新人理解项目更快
|
||||
老项目维护成本下降
|
||||
重复性编码减少
|
||||
测试和文档生成成本降低
|
||||
跨模块知识获取更快
|
||||
代码评审和风险识别前置
|
||||
```
|
||||
|
||||
也就是说，AI 影响的是整个研发链条。
|
||||
|
||||
Microsoft Research 和 GitHub 曾做过一个受控实验，使用 Copilot 的开发者完成指定编程任务的速度比对照组快 **55\.8%**。这个数字不应该被简单理解成“所有研发工作都快 55%”，但它说明在特定编码任务中，AI 对效率提升是真实存在的。\([微软](https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot/)\)
|
||||
|
||||
Gartner 也预测，到 2028 年，**75% 的企业软件工程师将使用 AI code assistants**，而 2023 年初这一比例还不到 10%；同时 Gartner 特别提醒，企业不应只从“降本”角度看 AI 编程工具，还要看价值创造、开发者能力提升和研发体验改善。\([gartner\.com](https://www.gartner.com/en/newsroom/press-releases/2024-04-11-gartner-says-75-percent-of-enterprise-software-engineers-will-use-ai-code-assistants-by-2028)\)
|
||||
|
||||
## 屏幕展示
|
||||
|
||||
```Plain Text
|
||||
AI 能效不是单点提效
|
||||
|
||||
不是只看：
|
||||
代码写得更快
|
||||
|
||||
更要看：
|
||||
理解更快
|
||||
交接更快
|
||||
测试更快
|
||||
文档更快
|
||||
风险发现更早
|
||||
知识传递成本更低
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 五、关于“AI 替代人”：点到为止，积极但不盲目
|
||||
|
||||
## 讲师讲法
|
||||
|
||||
当然，今天有董事和管理层在场，我们也需要正视一个问题：AI 会不会替代人？
|
||||
|
||||
我的建议是不要回避，但也不要把它讲得过度悲观。
|
||||
|
||||
更准确的说法是：
|
||||
|
||||
```Plain Text
|
||||
AI 会替代一部分重复性、低上下文、低判断含量的研发工作。
|
||||
AI 会改变岗位结构和团队用人方式。
|
||||
但 AI 不会在短期内替代所有工程判断、业务理解和系统责任。
|
||||
```
|
||||
|
||||
目前行业里已经出现一些信号：企业在评估 AI 对招聘、团队规模和岗位结构的影响，一些公司也公开谈到 AI 工具带来的生产率提升和招聘节奏变化。比如近期关于 Uber 的报道中提到，公司内部使用 Claude Code 和 ChatGPT 带来约 25% 的生产率提升，但管理层也强调，这种效率提升和最终用户价值之间并不是简单线性关系。\(The Times of India\)
|
||||
|
||||
同时，Stack Overflow 2025 调查也显示，虽然 AI 工具使用率很高，但开发者对 AI 输出准确性的信任并没有同步上升；面向领导者的解读中还提到，工具数量增加可能让工作流变复杂，而不是自动变简单。\(Stack Overflow Insights\)
|
||||
|
||||
## 推荐措辞
|
||||
|
||||
这一段建议你在课堂上这样说：
|
||||
|
||||
```Plain Text
|
||||
我们不用把 AI 看成一个马上替代所有工程师的东西，
|
||||
也不能把它看成一个可有可无的插件。
|
||||
|
||||
更现实的判断是：
|
||||
会使用 AI 的工程师，会逐渐替代不会使用 AI 的工作方式；
|
||||
会组织 AI 工作流的团队，会逐渐替代低效率的传统研发流程。
|
||||
```
|
||||
|
||||
这句话比较稳，既能让高管听到能效趋势，也不会让工程师产生强烈抵触。
|
||||
|
||||
---
|
||||
|
||||
# 六、为什么今天从“陌生代码库理解”开始讲？
|
||||
|
||||
## 讲师讲法
|
||||
|
||||
既然 AI 编程有这么多方向，为什么第一天不是讲“让 AI 写代码”，而是讲“陌生代码库理解”？
|
||||
|
||||
原因很简单。
|
||||
|
||||
企业研发里，真正消耗大量时间的，往往不是从零写一个 demo，而是：
|
||||
|
||||
```Plain Text
|
||||
接手旧项目
|
||||
理解陌生模块
|
||||
定位调用链路
|
||||
判断改动影响面
|
||||
识别风险点
|
||||
补测试
|
||||
写交接文档
|
||||
```
|
||||
|
||||
这些工作恰恰是 AI 最适合辅助，但也最需要人工判断的地方。
|
||||
|
||||
所以今天我们从“理解陌生代码库”开始，是因为它同时覆盖了三个能力：
|
||||
|
||||
```Plain Text
|
||||
AI 提效能力
|
||||
工程理解能力
|
||||
风险判断能力
|
||||
```
|
||||
|
||||
这也是高管和工程师都关心的交叉点。
|
||||
|
||||
对管理层来说，它关系到组织能效。
|
||||
|
||||
对工程师来说，它关系到个人能力升级。
|
||||
|
||||
对公司来说，它关系到研发质量和交付速度。
|
||||
|
||||
---
|
||||
|
||||
# 七、15 分钟开场完整结构
|
||||
|
||||
## 0 \- 2 分钟：开场破冰
|
||||
|
||||
```Plain Text
|
||||
今天不是一场单纯的工具培训，而是一场研发工作方式升级课。
|
||||
我们要讨论的是：AI 进入研发后，工程师、团队和组织能效会发生什么变化。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2 \- 5 分钟：行业趋势
|
||||
|
||||
```Plain Text
|
||||
AI 编程已经进入主流阶段。
|
||||
Stack Overflow 2025 调查显示，84% 的受访者已经使用或计划使用 AI 工具，51% 的职业开发者每天使用。
|
||||
GitHub 2025 Octoverse 也显示，AI 已经成为开发活动中的标准能力之一。
|
||||
```
|
||||
|
||||
配套引用：\(Stack Overflow Insights\)
|
||||
|
||||
---
|
||||
|
||||
## 5 \- 8 分钟：技术发展
|
||||
|
||||
```Plain Text
|
||||
AI 编程工具正在从代码补全，发展到对话助手，再到 Agent 工作流。
|
||||
今天的工具已经不只是帮你补几行代码，而是可以帮助理解项目、制定修改计划、生成测试、辅助评审。
|
||||
```
|
||||
|
||||
配套引用：\(GitHub\)
|
||||
|
||||
---
|
||||
|
||||
## 8 \- 12 分钟：能效理念
|
||||
|
||||
```Plain Text
|
||||
AI 的价值不只是让个人写代码更快，而是降低整个研发链条中的理解成本、交接成本、测试成本和文档成本。
|
||||
但企业不能只从降本角度看 AI，而要看价值创造、质量提升和研发体验。
|
||||
```
|
||||
|
||||
配套引用：\(微软\)
|
||||
|
||||
---
|
||||
|
||||
## 12 \- 15 分钟：替代与拥抱
|
||||
|
||||
```Plain Text
|
||||
AI 会替代一部分重复性、低上下文、低判断含量的工作。
|
||||
但企业真正需要的，不是简单减少人，而是提升每个人和每个团队的产出质量。
|
||||
|
||||
今天我们学习 TRAE，就是为了让大家掌握 AI 时代新的研发基本功：
|
||||
会提问、会给上下文、会追链路、会验证结果。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 八、PPT 页面建议：开场 6 页
|
||||
|
||||
## Slide 0：标题页
|
||||
|
||||
**标题：**
|
||||
AI 编程时代的研发能效升级
|
||||
|
||||
**副标题：**
|
||||
从工具使用到研发工作方式变化
|
||||
|
||||
**讲师备注：**
|
||||
今天不是单纯学习 TRAE，而是以 TRAE 为入口，学习 AI 时代研发团队的新工作方式。
|
||||
|
||||
---
|
||||
|
||||
## Slide 1：AI 编程已经进入主流阶段
|
||||
|
||||
**页面内容：**
|
||||
|
||||
```Plain Text
|
||||
AI 编程不再是尝鲜工具
|
||||
|
||||
趋势：
|
||||
- 开发者日常使用率快速上升
|
||||
- AI 从个人插件进入研发流程
|
||||
- 新人默认接触 AI 编程
|
||||
```
|
||||
|
||||
**讲师备注：**
|
||||
Stack Overflow 2025 显示，84% 的受访者使用或计划使用 AI 工具，51% 的职业开发者每天使用；GitHub 也观察到新开发者快速采用 Copilot。\([Stack Overflow Insights](https://survey.stackoverflow.co/2025/ai)\)
|
||||
|
||||
---
|
||||
|
||||
## Slide 2：AI 编程工具的三阶段演进
|
||||
|
||||
**页面内容：**
|
||||
|
||||
```Plain Text
|
||||
1. 代码补全
|
||||
补几行代码
|
||||
|
||||
2. 对话助手
|
||||
解释、生成、改写
|
||||
|
||||
3. 研发 Agent
|
||||
计划、修改、测试、验证、提交
|
||||
```
|
||||
|
||||
**讲师备注：**
|
||||
今天的 AI 编程工具已经从“补代码”走向“协同完成研发任务”。GitHub Copilot 等工具已经强调 agent mode，Gartner 对 AI code assistants 的功能定义也覆盖调试、测试、重构、文档和代码评审等环节。\([GitHub](https://github.com/features/copilot)\)
|
||||
|
||||
---
|
||||
|
||||
## Slide 3：AI 带来的不是单点提效，而是能效重构
|
||||
|
||||
**页面内容：**
|
||||
|
||||
```Plain Text
|
||||
过去关注：
|
||||
一个人写代码有多快
|
||||
|
||||
现在更要关注：
|
||||
理解项目有多快
|
||||
交接成本有多低
|
||||
测试文档能否自动生成
|
||||
风险能否更早暴露
|
||||
团队知识能否复用
|
||||
```
|
||||
|
||||
**讲师备注：**
|
||||
不要把 AI 提效理解成单纯“多写代码”。真正的组织价值在于降低理解成本、沟通成本、质量成本和维护成本。
|
||||
|
||||
---
|
||||
|
||||
## Slide 4：积极拥抱，但不盲目乐观
|
||||
|
||||
**页面内容：**
|
||||
|
||||
```Plain Text
|
||||
AI 会替代：
|
||||
重复性编码
|
||||
低上下文任务
|
||||
模板化文档
|
||||
简单测试生成
|
||||
初步代码解释
|
||||
|
||||
AI 仍需要人负责：
|
||||
业务判断
|
||||
架构取舍
|
||||
安全边界
|
||||
质量责任
|
||||
上线决策
|
||||
```
|
||||
|
||||
**讲师备注：**
|
||||
这一页要稳。不要制造恐慌，也不要说 AI 没影响。核心表达是：被替代的不是工程师这个人，而是低效、重复、缺乏判断的工作方式。
|
||||
|
||||
---
|
||||
|
||||
## Slide 5：工程师角色正在变化
|
||||
|
||||
**页面内容：**
|
||||
|
||||
```Plain Text
|
||||
过去：
|
||||
主要靠自己写、查、改、测
|
||||
|
||||
现在：
|
||||
会描述任务
|
||||
会提供上下文
|
||||
会拆解问题
|
||||
会验证 AI 输出
|
||||
会把 AI 结果工程化
|
||||
```
|
||||
|
||||
**讲师备注：**
|
||||
这是从“编码执行者”向“AI 协同工程师”的变化。
|
||||
|
||||
---
|
||||
|
||||
## Slide 6：为什么第一天先讲陌生代码库理解？
|
||||
|
||||
**页面内容：**
|
||||
|
||||
```Plain Text
|
||||
企业研发最常见的成本：
|
||||
|
||||
接手旧项目
|
||||
理解陌生模块
|
||||
追踪调用链路
|
||||
判断影响范围
|
||||
识别风险点
|
||||
沉淀文档
|
||||
```
|
||||
|
||||
**讲师备注：**
|
||||
这正是 TRAE 这类 AI IDE 最适合切入的地方，也是工程师最需要掌握的新基本功。
|
||||
|
||||
---
|
||||
|
||||
# 九、高管在场时的推荐表达
|
||||
|
||||
|
||||
|
||||
```Plain Text
|
||||
AI 编程不是单个工具采购问题，而是研发能效体系升级问题。
|
||||
```
|
||||
|
||||
```Plain Text
|
||||
AI 不只是提升个人编码速度，更重要的是降低组织的知识传递成本和项目理解成本。
|
||||
```
|
||||
|
||||
```Plain Text
|
||||
未来的差距，不一定是用不用 AI，而是能不能把 AI 嵌入标准研发流程。
|
||||
```
|
||||
|
||||
```Plain Text
|
||||
我们不是盲目追求 AI 替代人，而是让 AI 替代低价值重复劳动，让人聚焦业务判断、架构质量和交付责任。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 十、和后续课程的衔接话术
|
||||
|
||||
开场最后可以这样收：
|
||||
|
||||
```Plain Text
|
||||
所以今天我们不从“让 AI 写代码”开始，而是从“让 AI 帮我们理解代码”开始。
|
||||
|
||||
因为在企业真实研发里，理解陌生项目、识别调用链路、判断风险影响，是比写几行代码更底层的能力。
|
||||
|
||||
接下来，我们会进入今天的正式主题：
|
||||
|
||||
如何用 TRAE 快速理解一个陌生代码库，并且判断 AI 给出的结论是否可信。
|
||||
```
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user