16 KiB
16 KiB
layout, background
| layout | background |
|---|---|
| cover | https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=1920&q=80 |
第 2 天:TRAE 上下文工程与规则体系
让 TRAE 按团队规则改代码 — 从代码理解到研发治理
上下文决定 AI 看什么 · 规则决定 AI 怎么做 · 资产化决定团队怎么复用
第 1 天到第 2 天的跨越
第 1 天
让 TRAE 看懂若依代码
看结构 · 找入口 · 追链路 · 查依据
第 2 天
让 TRAE 按团队规则改代码
组织上下文 · 控制幻觉 · 编写 rules · 沉淀资产
核心变化:当团队多人都使用 AI 时,必须有统一上下文、统一 rules、统一验收标准,否则 AI 会带来不一致甚至风险。
若依场景下的团队规则问题
若依类后台项目常见风险
- 🚨 绕过权限,页面直接调接口
- 🚨 按钮权限当安全边界
- 🚨 接口缺少权限注解
- 🚨 操作日志缺失
- 🚨 代码生成后直接上线
- 🚨 敏感信息进入日志
- 🚨 数据权限范围不清
- 🚨 AI 修改未经复核
今天要把这些隐性开发要求写成规则,让 TRAE 长期遵守
今天三个关键词
🎯
上下文
决定 AI 看什么
整个项目 vs 单模块 vs 单文件
📏
规则
决定 AI 怎么做
不能绕过权限 · 不能遗漏日志
📦
资产化
决定团队怎么复用
Prompt · Rules · 模板
模块 1:上下文工程 — 好任务五要素
好任务 = 目标 + 范围 + 约束 + 输出格式 + 验收标准
❌ 坏 Prompt
@workspace 帮我检查若依权限有没有问题。
目标不清 · 范围不清 · 约束不清 · 输出不清
✅ 好 Prompt
@workspace 分析若依用户管理页面按钮权限调用链路
范围:只分析新增/修改/删除按钮
约束:不修改代码;标注文件和函数
输出:表格
验收:覆盖按钮/权限字符/前端判断/后端接口
模块 2:四类上下文工具
@workspace
找路
全局搜索入口、文件、模块
如:找 getInfo、getRouters、权限指令
#File
看文件
分析指定文件间的调用关系
如:分析用户 Controller 和 Service
#Code
抠细节
分析单个方法的参数、调用、异常
如:分析 handleLogin 函数
#Web
查外部
查询框架文档或最佳实践
但若依当前实现必须回到代码验证
模块 3:幻觉死循环切断
常见幻觉表现
AI 说所有接口都有权限校验
但不给 Controller 依据
但不给 Controller 依据
AI 说操作日志完整
但不给注解或 AOP 依据
但不给注解或 AOP 依据
AI 说按钮权限安全
但只看到前端代码
但只看到前端代码
1️⃣
先找证据
文件 · 类 · 方法 · 注解
2️⃣
再判断原因
区分事实和推测
3️⃣
最后给方案
修改 · 影响 · 验证
证据收集标准 Prompt
请先不要修改代码。
请围绕"用户管理删除按钮权限"收集证据:
1. 前端按钮在哪个页面
2. 使用了哪个权限字符
3. 前端如何判断按钮显示
4. 后端删除接口在哪里
5. Controller 是否有权限注解
6. 是否记录操作日志
7. 无法确认的内容
先收集证据,再判断风险,最后才给方案。
不要让 AI 跳过证据直接给结论。
不要让 AI 跳过证据直接给结论。
模块 4:.gitignore 与敏感配置
不应提交的文件
.env环境变量application-dev.yml真实密码- 数据库账号 / Redis 密码
target/编译产物node_modules//dist/- 日志文件
- IDE 本地配置
敏感配置规则
- 禁止硬编码数据库密码
- 禁止硬编码 Redis 密码
- 禁止硬编码 JWT 密钥
- 禁止硬编码第三方密钥
- 不得提交真实配置文件
- 示例配置必须使用占位符
模块 5:.trae/rules.md 安全规则
规则 1:前端按钮权限只能作为交互控制,不能作为安全边界。
规则 2:涉及用户、角色、菜单、部门、岗位等敏感接口时,必须检查后端 Controller 是否存在权限控制。
规则 3:涉及新增、修改、删除、导出等操作时,必须检查是否记录操作日志。
规则 4:禁止在源码中硬编码数据库密码、Redis 密码、JWT 密钥。
规则 5:列表查询必须确认是否需要数据权限过滤。
模块 6:编码与测试规则
编码规则重点
- 前端接口放
api目录,不在页面写请求 - 后端遵守 Controller → Service → Mapper 分层
- 敏感接口关注权限注解
- 敏感操作关注日志注解
- 列表查询关注数据权限
- 固定枚举值使用字典
- 代码生成结果必须人工检查
测试规则重点
- ✅ 登录成功 / 失败
- ✅ 无权限访问接口返回拒绝
- ✅ 按钮权限和权限字符匹配
- ✅ 角色授权变化后权限更新
- ✅ 数据权限范围正确
- ✅ 敏感操作有日志记录
- ✅ 代码生成 CRUD 完整性
模块 7:前端专项规则
用户管理页面规则示例
| 规则项 | 要求 |
|---|---|
| 按钮权限 | 新增/修改/删除/导出必须使用权限控制 |
| 删除操作 | 必须二次确认 |
| 提交失败 | loading 必须恢复 |
| 数据刷新 | 修改后必须刷新列表 |
| 敏感字段 | 不得明文展示或输出日志 |
| 接口调用 | 统一放 api 目录 |
| 动态路由 | 不能随意绕过 |
| 字典字段 | 使用统一字典显示 |
模块 8:规则可执行性检查
❌ 坏规则
- 「注意权限安全」
- 「代码要规范」
- 「日志要完整」
- 「数据权限要合理」
- 「生成代码要检查」
方向没错,但不可执行
✅ 好规则
- 涉及用户/角色/菜单/部门/岗位的新增/修改/删除/导出接口 → 必须检查后端权限和操作日志
- 涉及列表查询 → 必须确认数据权限过滤
- 代码生成结果上线前 → 必须检查权限、日志、校验、异常和测试
有触发场景 · 有必须动作 · 可被检查
模块 9:技能与规则资产化
ai-dev-assets/
├── prompts/若依/ # 若依相关 Prompt 模板
│ ├── 结构分析.md
│ ├── 登录权限链路.md
│ ├── 按钮权限检查.md
│ └── 操作日志检查.md
├── rules/若依/ # 若依 rules.md
├── templates/若依/ # 报告模板
├── checklists/若依/ # 检查清单
│ ├── 权限检查.md
│ ├── 日志检查.md
│ └── 代码生成Review.md
└── examples/若依/ # 优秀案例 & 反面案例
这些资产以后可以直接用于公司内部类似后台管理系统
若依版 rules.md 核心条款
1
前端按钮权限不是安全边界
2
敏感接口必须检查后端权限
3
敏感操作必须检查操作日志
4
列表查询必须考虑数据权限
5
代码生成结果不得直接上线
6
不确定内容必须标注
layout: center
第 2 天交付物
01 上下文组织清单
02 上下文引用模板
03 幻觉控制 Prompt
04 .gitignore 配置样例
05 若依安全规则
06 若依编码测试规则
07 若依前端规则
08 若依 AI 资产库目录
09 规则验收清单
10 若依版 rules.md v0.1
两天课程总结
第 1 天:读懂若依
- 看结构 — 全局目录与模块职责
- 找入口 — 登录、权限、菜单入口
- 追链路 — 完整调用链路分析
- 查依据 — 验证 AI 输出可信度
第 2 天:按规则参与若依
- 组织上下文 — 精准任务五要素
- 控制幻觉 — 证据→原因→方案
- 编写 rules — 可执行规则
- 沉淀资产 — 团队长期复用
最终能力
读得懂
问得准
查得实
改得稳
可复用