# 第 1 天：TRAE 基础工作流与陌生代码库理解 ## 第 0 部分：AI 编程趋势、能效理念、高管破冰 --- ## Slide 0\-1：课程标题 ### PPT 页面内容 ```Plain Text TRAE 基础工作流与陌生代码库理解 真实开源项目案例： 若依 RuoYi-Vue / RuoYi-Vue3 主线任务： 理解“登录 → 用户信息 → 菜单路由 → 按钮权限”的调用链路 ``` ### 讲师逐字稿 各位领导、各位同事，大家好。 今天是 TRAE 系列课程第一天。今天我们不会从“让 AI 写代码”开始，而是从企业研发里更常见、更真实的场景开始：如何理解一个陌生代码库。 这次我们不用虚拟项目，而是使用真实开源项目若依。若依是国内研发团队非常熟悉的一类后台管理系统，包含用户管理、角色管理、菜单管理、权限控制、操作日志、代码生成等典型企业后台能力。 今天我们的主线任务是：使用 TRAE 理解若依中“用户登录后，系统如何加载用户信息、生成菜单路由，并控制页面按钮权限”的完整链路。 这个案例非常适合企业内训，因为它不是玩具项目，而是很多公司内部系统都会遇到的后台权限体系。 --- ## Slide 0\-2：为什么选若依作为案例？ ### PPT 页面内容 ```Plain Text 若依适合训练： 陌生代码库理解 前后端分离结构分析 登录认证链路 动态菜单与路由 角色与权限 按钮权限 数据权限 操作日志 代码生成 ``` ### 讲师逐字稿 我们为什么选若依？ 第一，若依足够真实。它不是 demo，而是一个完整后台管理系统。 第二，它足够典型。很多企业内部系统都有用户、角色、菜单、权限、日志、字典、代码生成这些模块。 第三，它非常适合讲 AI 辅助代码理解。因为若依既有前端，也有后端；既有页面，也有接口；既有权限，也有日志；既有业务模块，也有基础框架能力。 今天大家不是要记住若依所有代码，而是要学会一种方法：拿到一个陌生系统，如何让 TRAE 帮我们从结构、模块、链路和证据四个层面快速建立理解。 --- ## Slide 0\-3：AI 编程进入企业研发主流程 ### PPT 页面内容 ```Plain Text AI 编程不只是写代码 更重要的是： 读代码 找入口 追链路 查风险 写测试 生成文档 沉淀经验 ``` ### 讲师逐字稿 AI 编程早期给大家的印象，可能是补全代码、生成函数、写几个工具方法。 但在企业研发中，真正耗时的往往不是写几行代码，而是理解历史代码、追踪业务链路、判断影响范围、确认权限边界、补充测试和沉淀文档。 AI 对研发的价值，不只是让某个人写得快一点，而是让团队更快理解系统、更快交接、更快定位风险。 所以今天的重点不是“AI 会不会写”，而是“AI 能不能帮我们更快读懂一个真实项目”。 --- ## Slide 0\-4：AI 能效理念 ### PPT 页面内容 ```Plain Text AI 能效不是单点提速 不是只看： 代码写得更快 更要看： 理解更快 交接更快 定位更快 风险更早暴露 团队知识沉淀更快 ``` ### 讲师逐字稿 这里我们讲一个关键词：能效。 在企业里，研发能效不是单点速度，而是整个研发链条的效率。 如果新人接手若依这样的后台系统，以前可能要花很多时间搞清楚登录在哪里、权限从哪里来、菜单怎么生成、按钮怎么控制、后端接口如何校验。 如果 TRAE 能帮助我们快速定位这些文件和调用关系，它带来的价值就不是少写几行代码，而是降低理解成本、交接成本和维护成本。 这就是我们第一天从陌生代码库理解开始的原因。 --- ## Slide 0\-5：AI 替代人的现实判断 ### PPT 页面内容 ```Plain Text 不用过度乐观 也不用过度悲观 AI 会替代： 重复性、低上下文、低判断含量的工作方式 人必须负责： 业务规则 权限边界 安全责任 架构取舍 上线决策 ``` ### 讲师逐字稿 今天有管理层，也有工程师，所以我们也可以坦诚谈一下 AI 替代人的问题。 AI 会替代一部分重复性、低上下文、低判断含量的工作方式。 但它不能替代所有工程判断。 比如若依里一个按钮是否应该对某个角色开放，这不是 AI 单独决定的。AI 可以帮我们找出权限字符在哪里配置、前端如何判断、后端如何校验，但业务上谁应该拥有这个权限，必须由人判断。 未来真正的差距，不是用不用 AI，而是能不能把 AI 放进标准研发流程，让它帮助我们找证据、提效率，而不是让它替我们承担责任。 --- ## Slide 0\-6：第一天真正要学什么？ ### PPT 页面内容 ```Plain Text 今天训练四个动作： 看结构 找入口 追链路 查依据 最终产出： 代码理解报告 ``` ### 讲师逐字稿 今天不是学几个 Prompt。 今天训练四个动作。 第一，看结构。看若依前后端目录、模块分层、启动方式、技术栈。 第二，找入口。找登录入口、用户信息接口、菜单接口、权限判断入口。 第三，追链路。从登录开始，一路追到动态路由和按钮权限。 第四，查依据。AI 的每个关键结论，都要能回到文件、函数、接口或调用关系中验证。 今天最后的产出，是一份“若依权限与菜单模块代码理解报告”。 --- # 模块 1：TRAE 在真实研发流程中的定位 --- ## Slide 1\-1：TRAE 的定位 ### PPT 页面内容 ```Plain Text TRAE 是研发辅助工具 适合： 检索代码 解释函数 梳理结构 生成链路初稿 生成文档初稿 不能直接替代： 业务判断 权限决策 安全判断 上线决策 ``` ### 讲师逐字稿 我们先给 TRAE 定位。 TRAE 不是替代工程师的工具，而是研发辅助工具。 在若依项目里，TRAE 很适合帮我们找登录接口、找用户信息接口、找菜单加载逻辑、找权限判断指令、解释后端 Controller 和 Service 的职责。 但它不能替我们决定某个角色应该拥有什么权限，也不能替我们判断某个接口是否可以上线。 AI 可以帮我们找到代码事实，但不能替代业务和安全责任。 --- ## Slide 1\-2：代码事实 vs 业务事实 ### PPT 页面内容 ```Plain Text 代码事实： 代码现在怎么写 业务事实： 业务应该怎么规定 TRAE 擅长发现代码事实 人工必须判断业务事实 ``` ### 讲师逐字稿 在若依案例里，这个区分非常重要。 比如 TRAE 可能发现某个按钮使用了权限字符 `system:user:edit`。 这是代码事实。 但哪些角色应该拥有 `system:user:edit`，这是业务事实。 再比如，后端某个接口加了权限注解，这是代码事实。但这个接口权限设计是否合理，是否符合公司安全要求，这是业务事实。 所以我们用 TRAE 时，要明确它帮我们发现的是“当前系统怎么写”，不是“业务上一定应该这样”。 --- ## Slide 1\-3：适合 TRAE 的任务 ### PPT 页面内容 ```Plain Text 适合 TRAE 辅助： 理解前后端目录 查找登录入口 查找菜单接口 分析动态路由生成 解释按钮权限 梳理角色权限关系 生成代码理解报告初稿 ``` ### 讲师逐字稿 若依项目里，有很多任务适合 TRAE 辅助。 比如理解前后端目录结构，查找登录入口，查找获取用户信息和路由菜单的接口，分析前端动态路由生成逻辑，解释按钮权限如何生效，梳理角色、菜单、权限字符之间的关系。 这些信息主要都在代码库里，可以通过文件、函数、接口验证。 所以我们可以让 TRAE 先生成初稿，再人工校对。 --- ## Slide 1\-4：必须人工判断的任务 ### PPT 页面内容 ```Plain Text 必须人工判断： 角色权限是否合理 数据权限范围是否正确 接口是否应该开放 敏感操作是否必须审计 代码生成结果能否上线 权限变更是否影响生产 ``` ### 讲师逐字稿 有些任务不能直接交给 TRAE 决定。 比如某个角色是否应该拥有用户删除权限，某个部门的数据权限范围是否正确，某个接口是否应该开放，修改角色权限是否会影响生产用户。 这些涉及业务规则、安全边界和上线风险，必须人工判断。 TRAE 可以帮助我们列出当前权限链路和风险点，但不能直接给最终决策。 --- ## Slide 1\-5：产出：TRAE 使用边界清单 ### PPT 页面内容 ```Plain Text 实操产出： TRAE 使用边界清单 三类任务： 1. 适合 TRAE 辅助 2. 可生成初稿但必须人工复核 3. 不建议直接交给 TRAE 决定 ``` ### 讲师逐字稿 第一个实操是生成 TRAE 使用边界清单。 请大家围绕若依项目，列出哪些任务适合 TRAE 辅助，哪些可以让 TRAE 生成初稿但必须人工复核，哪些不建议直接交给 TRAE 决定。 比如“查找登录接口”适合 TRAE 辅助；“判断角色权限是否合理”可以生成初稿但必须人工复核；“判断能否上线”不建议交给 TRAE 决定。 --- # 模块 2：沙箱项目业务导览 ## 若依模块导览 --- ## Slide 2\-1：若依的核心业务对象 ### PPT 页面内容 ```Plain Text 若依核心对象： User 用户 Role 角色 Menu 菜单 Permission 权限字符 Dept 部门 Post 岗位 OperLog 操作日志 Dict 字典 GenTable 代码生成 ``` ### 讲师逐字稿 理解若依，不能只看目录，要先看核心对象。 若依最核心的是用户、角色、菜单和权限。 用户属于部门，可以拥有岗位，可以绑定角色。角色拥有菜单权限和数据权限。菜单不仅控制左侧菜单和动态路由，也关联按钮权限字符。操作日志记录关键操作。代码生成模块帮助生成 CRUD 代码。 今天我们重点看用户、角色、菜单、权限这条主线。 --- ## Slide 2\-2：若依模块总览 ### PPT 页面内容 ```Plain Text 核心模块： 登录认证 用户管理 角色管理 菜单管理 部门管理 岗位管理 权限控制 操作日志 登录日志 代码生成 ``` ### 讲师逐字稿 若依常见模块包括登录认证、用户管理、角色管理、菜单管理、部门管理、岗位管理、权限控制、操作日志、登录日志、代码生成。 这些模块组合起来，构成一个典型企业后台系统。 今天不是要讲完所有模块，而是通过权限和菜单这条主线，学习如何理解陌生项目。 --- ## Slide 2\-3：用户、角色、菜单、权限之间的关系 ### PPT 页面内容 ```Plain Text 用户 User ↓ 绑定 角色 Role ↓ 授权 菜单 Menu ↓ 包含 权限字符 Permission ↓ 控制 页面访问 / 按钮显示 / 接口访问 ``` ### 讲师逐字稿 若依权限体系可以先用这张图理解。 用户绑定角色。角色被授予菜单。菜单可以是目录、菜单页面，也可以是按钮权限。按钮权限通常通过权限字符表示，比如用户新增、用户修改、用户删除。 前端根据这些权限字符控制按钮显示，后端接口也应基于权限注解或权限判断控制访问。 今天我们要追踪的，就是这条链路从后端到前端如何生效。 --- ## Slide 2\-4：若依中的三类权限 ### PPT 页面内容 ```Plain Text 页面权限： 能不能看到某个菜单页面 按钮权限： 能不能看到新增、修改、删除按钮 数据权限： 能看到哪些部门或范围的数据 ``` ### 讲师逐字稿 若依里我们可以把权限分成三类。 第一，页面权限。也就是用户能不能看到某个菜单页面。 第二，按钮权限。比如用户管理页面上的新增、修改、删除、导出按钮是否显示。 第三，数据权限。比如某个角色只能看本部门数据，还是可以看全部数据。 这三类权限不能混在一起。页面能看到，不代表按钮能操作。按钮隐藏，也不代表后端接口安全。数据能看到多少，又是另外一套规则。 --- ## Slide 2\-5：若依业务导览 Prompt ### PPT 页面内容 ```Plain Text @workspace 请从业务视角分析若依项目。 重点说明： 1. 系统主要解决什么问题 2. 核心业务对象有哪些 3. 用户、角色、菜单、权限如何协作 4. 前端和后端分别负责什么 5. 哪些结论需要人工验证 ``` ### 讲师逐字稿 这一页是若依业务导览 Prompt。 注意我们不是让 TRAE 泛泛总结项目，而是指定业务视角。 我们让它说明系统解决什么问题，核心业务对象有哪些，用户、角色、菜单、权限如何协作，前端和后端分别负责什么。 同时必须列出需要人工验证的内容。 这能帮助我们快速建立若依的模块认知图。 --- ## Slide 2\-6：产出：若依模块认知图 ### PPT 页面内容 ```Plain Text 产出内容： 核心业务对象 核心模块 模块职责 模块依赖关系 权限链路 风险点 不确定点 ``` ### 讲师逐字稿 这一部分的产出是若依模块认知图。 大家要整理出核心业务对象、核心模块、模块职责、模块依赖关系、权限链路、风险点和不确定点。 例如用户模块依赖部门、岗位和角色；角色模块关联菜单和数据权限；菜单模块既影响动态路由，也影响按钮权限；操作日志模块记录关键操作。 --- # 模块 3：使用 @workspace 理解全局结构 --- ## Slide 3\-1：不要让 AI 泛泛总结项目 ### PPT 页面内容 ```Plain Text 不要问： @workspace 帮我看看若依项目 要问： 从前端、后端、认证、路由、API、权限、日志、测试、构建分析项目 并标注依据文件 ``` ### 讲师逐字稿 使用 @workspace 时，最常见的错误是问“帮我看看这个项目”。 这样 AI 会给一段泛泛总结。 我们要让它从明确维度分析：前端结构、后端结构、认证流程、路由菜单、API 封装、权限控制、日志记录、测试结构、构建方式。 并且要求每个结论标注依据文件。 --- ## Slide 3\-2：若依前后端结构怎么读？ ### PPT 页面内容 ```Plain Text 前端重点： src/api src/router src/store src/views src/directive src/permission.js / permission.ts src/utils/request 后端重点： ruoyi-admin ruoyi-framework ruoyi-system ruoyi-common Controller Service Mapper ``` ### 讲师逐字稿 若依是前后端分离项目，所以读结构时要分前端和后端。 前端重点看 api、router、store、views、directive、permission 文件、request 封装。 后端重点看 ruoyi\-admin、ruoyi\-framework、ruoyi\-system、ruoyi\-common，以及 Controller、Service、Mapper 分层。 如果使用 RuoYi\-Vue3，前端目录和状态管理方式可能不同，但分析方法一样。 --- ## Slide 3\-3：认证链路要看哪些文件？ ### PPT 页面内容 ```Plain Text 认证链路重点： 登录页面 login API token 存储 request 拦截器 getInfo 用户信息 getRouters 动态路由 权限 store 路由守卫 ``` ### 讲师逐字稿 若依权限主线从登录开始。 我们要看登录页面在哪里，login API 怎么调用，token 存在哪里，request 拦截器如何带 token，请求用户信息的 getInfo 在哪里，请求菜单路由的 getRouters 在哪里，权限 store 如何保存角色和权限，路由守卫如何判断是否已加载菜单。 这条链路是今天最重要的主线。 --- ## Slide 3\-4：动态菜单与路由怎么看？ ### PPT 页面内容 ```Plain Text 动态菜单 / 路由重点： 后端菜单表 菜单类型：目录 / 菜单 / 按钮 路由地址 组件路径 权限字符 前端动态路由转换 router.addRoute ``` ### 讲师逐字稿 若依的菜单不是单纯前端写死的。 后台菜单管理里配置菜单，菜单可以是目录、页面菜单，也可以是按钮权限。 菜单包含路由地址、组件路径、权限字符等信息。 前端获取后端返回的菜单数据后，会转换成前端路由，再动态挂载。 所以分析动态菜单，既要看后端菜单接口，也要看前端路由转换逻辑。 --- ## Slide 3\-5：全局结构分析 Prompt ### PPT 页面内容 ```Plain Text @workspace 请分析若依项目全局结构。 维度： 1. 前端目录 2. 后端目录 3. 登录认证 4. 动态路由 5. API 封装 6. 权限控制 7. 操作日志 8. 代码生成 9. 测试与构建 10. 不确定点 每个结论标注依据文件。 ``` ### 讲师逐字稿 这是若依全局结构分析的标准 Prompt。 大家注意，维度非常明确。 我们不是让 AI 自己决定讲什么，而是让它从前端目录、后端目录、登录认证、动态路由、API 封装、权限控制、操作日志、代码生成、测试与构建这些维度分析。 每个结论都要标注依据文件。 --- ## Slide 3\-6：产出：若依项目结构图 ### PPT 页面内容 ```Plain Text 项目结构图应包含： 前端目录职责 后端模块职责 认证与权限相关文件 菜单与路由相关文件 API 封装相关文件 操作日志相关文件 不确定点 ``` ### 讲师逐字稿 这一部分最终产出是若依项目结构图。 结构图不只是列目录，而是说明每个目录和权限主线有什么关系。 比如前端 views/system/user 是用户管理页面，api/system/user 是用户接口，store/modules/permission 或 permission 文件和动态路由有关，directive/permission 和按钮权限有关。 后端 sys 用户、角色、菜单 Controller、Service、Mapper 共同支撑权限管理。 --- # 模块 4：调用链路分析 --- ## Slide 4\-1：第一天核心链路 ### PPT 页面内容 ```Plain Text 主线链路： 用户登录 ↓ 获取 token ↓ 获取用户信息 ↓ 获取菜单路由 ↓ 生成动态路由 ↓ 进入系统页面 ↓ 根据权限字符控制按钮 ``` ### 讲师逐字稿 下午我们进入第一天最重要的部分：调用链路分析。 若依案例的主线链路是：用户登录，获取 token，获取用户信息，获取菜单路由，生成动态路由，进入系统页面，根据权限字符控制按钮。 这条链路覆盖前端页面、API 调用、后端接口、用户角色、菜单权限、动态路由和按钮权限。 它非常适合训练陌生代码库理解。 --- ## Slide 4\-2：调用链路 8 个检查点 ### PPT 页面内容 ```Plain Text 1. 页面入口 2. UI 组件 3. 事件函数 4. API 调用 5. 后端 Controller 6. Service / 权限逻辑 7. 前端状态更新 8. 路由 / 按钮生效 ``` ### 讲师逐字稿 若依的调用链路也可以拆成 8 个检查点。 页面入口，比如登录页或用户管理页。 UI 组件，比如登录表单或新增按钮。 事件函数，比如 handleLogin。 API 调用，比如 login、getInfo、getRouters。 后端 Controller，比如登录接口、菜单路由接口。 Service 或权限逻辑，比如用户信息、角色权限、菜单树。 前端状态更新，比如保存 token、roles、permissions、routes。 最后是路由和按钮权限生效。 --- ## Slide 4\-3：登录认证链路示例 ### PPT 页面内容 ```Plain Text 用户输入账号密码 ↓ Login 页面提交 ↓ 调用 login API ↓ 后端认证用户 ↓ 返回 token ↓ 前端保存 token ↓ request 拦截器携带 token ``` ### 讲师逐字稿 登录认证链路是第一条主线。 用户在登录页面输入账号密码，提交表单，前端调用 login API。 后端校验用户身份，成功后返回 token。 前端保存 token，后续请求通过 request 拦截器携带 token。 这里要重点看三个问题：token 存在哪里，request 拦截器在哪里带 token，token 失效后如何处理。 --- ## Slide 4\-4：用户信息与权限加载链路 ### PPT 页面内容 ```Plain Text 登录成功 ↓ 调用 getInfo ↓ 后端返回 user、roles、permissions ↓ 前端保存用户信息 ↓ 前端保存角色和权限字符 ↓ 后续用于按钮权限判断 ``` ### 讲师逐字稿 登录成功之后，系统通常会请求用户信息。 getInfo 这类接口会返回当前用户信息、角色列表、权限字符等。 前端保存这些数据后，后续按钮权限就会依赖这些权限字符进行判断。 这里要注意：前端拿到权限字符，只能控制页面展示，不能作为后端安全边界。 真正的接口安全仍然需要后端权限校验。 --- ## Slide 4\-5：动态路由加载链路 ### PPT 页面内容 ```Plain Text 调用 getRouters ↓ 后端返回菜单树 ↓ 前端转换为路由对象 ↓ 动态挂载路由 ↓ 渲染侧边栏菜单 ↓ 用户进入页面 ``` ### 讲师逐字稿 若依的菜单和路由通常是动态加载的。 前端调用 getRouters，后端根据当前用户角色和菜单权限返回菜单树。 前端把菜单树转换成路由对象，再动态挂载到 router 中。 侧边栏根据这些路由渲染菜单。 这条链路很适合训练“从后端数据到前端页面”的完整理解。 --- ## Slide 4\-6：按钮权限链路 ### PPT 页面内容 ```Plain Text 菜单中配置权限字符 ↓ 角色拥有该权限字符 ↓ getInfo 返回 permissions ↓ 前端权限指令 / 方法判断 ↓ 控制按钮显示或隐藏 ``` ### 讲师逐字稿 按钮权限的核心是权限字符。 在菜单管理中，按钮通常会配置类似“用户新增”“用户修改”“用户删除”这样的权限字符。 角色被授权后，用户登录时会拿到对应权限字符。 前端通过权限指令或权限判断方法，决定按钮是否显示。 但是再次强调：按钮隐藏只代表前端交互控制，不代表接口安全。 --- ## Slide 4\-7：后端接口权限链路 ### PPT 页面内容 ```Plain Text 前端按钮权限 ↓ 只能控制 UI 展示 后端接口权限 ↓ 必须控制真实访问 需要确认： Controller 是否有权限注解 Service 是否校验数据权限 ``` ### 讲师逐字稿 这一页是权限分析的关键。 前端按钮权限只能控制 UI 展示。 如果用户绕过前端，直接请求后端接口，那么真正决定是否安全的是后端接口权限。 所以在若依里，我们要检查 Controller 是否有权限注解，Service 是否处理数据权限。 如果 AI 只看到前端按钮权限，就说“权限安全”，这是错误结论。 报告里必须区分前端权限和后端权限。 --- ## Slide 4\-8：操作日志链路 ### PPT 页面内容 ```Plain Text 管理员修改用户 ↓ 调用后端接口 ↓ Controller 执行业务 ↓ 日志注解 / AOP 记录操作 ↓ 写入操作日志 ↓ 操作日志页面查询 ``` ### 讲师逐字稿 若依还有一个很适合训练的链路：操作日志。 比如管理员修改用户信息，前端调用后端接口，后端 Controller 执行业务逻辑。 如果接口上配置了日志注解或 AOP，系统会记录操作人、操作模块、操作类型、请求参数、结果等信息。 然后管理员可以在操作日志页面查看。 这条链路适合讲审计、日志脱敏和敏感操作追踪。 --- ## Slide 4\-9：调用链路分析 Prompt ### PPT 页面内容 ```Plain Text @workspace 请分析若依中“登录后菜单与按钮权限生效”的完整调用链路。 从用户登录开始，依次说明： 登录页面、登录 API、token、getInfo、getRouters、动态路由、侧边栏菜单、按钮权限、后端接口权限、不确定点。 每一步标注文件路径和函数名。 ``` ### 讲师逐字稿 这是若依调用链路分析 Prompt。 注意，这个 Prompt 不是让 AI 总结权限系统，而是让它从用户登录开始，按顺序追踪链路。 必须包含登录页面、登录 API、token、getInfo、getRouters、动态路由、侧边栏菜单、按钮权限、后端接口权限和不确定点。 每一步都要标注文件路径和函数名。 --- ## Slide 4\-10：产出：若依权限调用链路图 ### PPT 页面内容 ```Plain Text 产出内容： 登录认证链路图 用户信息加载链路图 动态菜单路由链路图 按钮权限链路图 后端接口权限链路图 操作日志链路图 ``` ### 讲师逐字稿 这一部分的产出是若依权限调用链路图。 不是只画一条线，而是可以拆成几条子链路：登录认证、用户信息加载、动态菜单路由、按钮权限、后端接口权限、操作日志。 每条链路都要有依据文件和不确定点。 --- # 模块 5：AI 输出可信度判断 --- ## Slide 5\-1：若依案例中的常见 AI 幻觉 ### PPT 页面内容 ```Plain Text 常见不可信结论： 若依权限系统很完善 所有接口都有后端校验 按钮权限已经保证安全 操作日志一定完整 代码生成结果可以直接上线 ``` ### 讲师逐字稿 在若依这种项目里，AI 很容易给出看起来正确但不严谨的结论。 比如“若依权限系统很完善”“所有接口都有后端校验”“按钮权限已经保证安全”“操作日志一定完整”“代码生成结果可以直接上线”。 这些话不能直接信。 我们要问：依据文件在哪里？哪个 Controller？哪个注解？哪个权限字符？哪个 AOP？哪个 Service？如果没有依据，就不能写成确定结论。 --- ## Slide 5\-2：可信输出四件套 ### PPT 页面内容 ```Plain Text 可信结论必须包含： 文件路径 函数 / 类 / 注解 调用关系 不确定点 ``` ### 讲师逐字稿 若依案例里，一条可信结论必须包含四件套。 文件路径，比如前端哪个 api 文件、后端哪个 Controller。 函数、类或注解，比如 getInfo、getRouters、权限指令、Controller 方法、权限注解。 调用关系，比如登录后先拿 token，再 getInfo，再 getRouters，再生成动态路由。 不确定点，比如无法确认某个接口是否有数据权限校验。 没有这些内容，就不能轻易采纳。 --- ## Slide 5\-3：不可信回答示例 ### PPT 页面内容 ```Plain Text 若依已经实现了完整权限控制， 用户登录后会自动加载菜单和按钮权限， 后端接口也都有权限校验， 整体风险较低。 ``` ### 讲师逐字稿 这段话看起来很顺，但不合格。 为什么？ 没有文件路径。没有函数名。没有说明菜单从哪个接口加载。没有说明按钮权限由哪个指令判断。没有说明后端接口权限在哪里校验。没有列出不确定点。 所以这种回答不能进入报告。 --- ## Slide 5\-4：可信回答示例 ### PPT 页面内容 ```Plain Text 前端登录成功后调用 getInfo 获取用户信息和权限字符。 随后调用 getRouters 获取动态路由菜单。 前端根据返回路由生成侧边栏菜单。 可以确认前端存在菜单和按钮权限控制。 但仍需检查后端 Controller 权限注解，才能确认接口级权限。 ``` ### 讲师逐字稿 这个回答更可信。 它说明了前端登录后的两个关键动作：getInfo 和 getRouters。 它说明了前端根据返回路由生成菜单。 同时它没有夸大结论。它说可以确认前端存在菜单和按钮权限控制，但仍需检查后端 Controller 权限注解，才能确认接口级权限。 这就是专业表达。 --- ## Slide 5\-5：产出：TRAE 输出校验清单 ### PPT 页面内容 ```Plain Text 检查项： 是否有文件路径 是否有函数 / 类 / 注解 是否说明调用关系 是否区分前端权限和后端权限 是否列出不确定点 是否给出验证方式 ``` ### 讲师逐字稿 这一部分产出是 TRAE 输出校验清单。 以后 AI 给出若依权限分析时，我们就按这些问题检查。 是否有文件路径？是否有函数、类或注解？是否说明调用关系？是否区分前端权限和后端权限？是否列出不确定点？是否给出验证方式？ 没有通过这些检查的内容，不写进报告。 --- # 模块 6：统一实战：代码理解报告 --- ## Slide 6\-1：报告主题 ### PPT 页面内容 ```Plain Text 代码理解报告： 若依权限与菜单模块 核心问题： 用户登录后，菜单、路由和按钮权限如何生效？ ``` ### 讲师逐字稿 今天最终实战，是生成一份代码理解报告。 报告主题是：若依权限与菜单模块。 核心问题是：用户登录后，菜单、路由和按钮权限如何生效？ 这份报告不是 AI 聊天记录，而是可交接、可复核的工程文档。 --- ## Slide 6\-2：报告结构 ### PPT 页面内容 ```Plain Text 报告包含： 模块职责 核心对象 目录与文件结构 核心调用链路 权限风险 操作日志风险 改造建议 不确定结论 ``` ### 讲师逐字稿 报告至少包含八部分。 模块职责、核心对象、目录与文件结构、核心调用链路、权限风险、操作日志风险、改造建议、不确定结论。 每个关键结论都要有依据文件或函数。 如果没有依据，就写到不确定点里。 --- ## Slide 6\-3：模块职责写法 ### PPT 页面内容 ```Plain Text 不要写： 权限模块用于权限控制。 要写： 权限与菜单模块负责用户登录后加载角色、权限字符和动态路由，并根据角色菜单关系控制页面访问和按钮显示。 ``` ### 讲师逐字稿 模块职责不能写空话。 “权限模块用于权限控制”没有信息量。 合格写法要具体说明：权限与菜单模块负责用户登录后加载角色、权限字符和动态路由，并根据角色菜单关系控制页面访问和按钮显示。 同时要说明前端权限和后端权限的边界。 --- ## Slide 6\-4：核心对象写法 ### PPT 页面内容 ```Plain Text 核心对象： User 用户 Role 角色 Menu 菜单 Permission 权限字符 Dept 部门 OperLog 操作日志 ``` ### 讲师逐字稿 若依权限模块的核心对象是用户、角色、菜单、权限字符、部门和操作日志。 用户绑定角色，角色拥有菜单权限，菜单中包含权限字符，部门影响数据权限，操作日志记录敏感操作。 这些对象共同构成权限体系。 --- ## Slide 6\-5：风险点写法 ### PPT 页面内容 ```Plain Text 不要写： 权限有风险。 要写： 风险：按钮权限只控制前端展示。 触发条件： 后端接口缺少权限校验。 影响： 用户可能绕过前端直接调用接口。 验证： 检查 Controller 是否有权限注解。 ``` ### 讲师逐字稿 风险点一定要具体。 “权限有风险”不是合格风险点。 合格风险点要包含风险描述、触发条件、影响范围和验证方式。 比如按钮权限只控制前端展示。触发条件是后端接口缺少权限校验。影响是用户可能绕过前端直接调用接口。验证方式是检查 Controller 是否有权限注解。 --- ## Slide 6\-6：改造建议写法 ### PPT 页面内容 ```Plain Text 建议： 确保用户、角色、菜单等敏感接口均有后端权限校验 原因： 前端按钮隐藏不能作为安全边界 验收： 无权限用户直接请求接口时返回 403 ``` ### 讲师逐字稿 改造建议也要具体。 比如建议确保用户、角色、菜单等敏感接口均有后端权限校验。 原因是前端按钮隐藏不能作为安全边界。 验收标准是无权限用户直接请求接口时返回 403。 这样的建议才可以进入工程评审。 --- ## Slide 6\-7：第 1 天最终交付物 ### PPT 页面内容 ```Plain Text 第 1 天交付物： 01_TRAE 使用边界清单 02_若依模块认知图 03_若依项目结构图 04_权限调用链路图 05_TRAE 输出校验清单 06_若依权限与菜单模块代码理解报告 ``` ### 讲师逐字稿 第 1 天最终交付六个产物。 第一，TRAE 使用边界清单。 第二，若依模块认知图。 第三，若依项目结构图。 第四，权限调用链路图。 第五，TRAE 输出校验清单。 第六，若依权限与菜单模块代码理解报告。 这些产物构成第一天的完整成果。 --- #