feat(slidev): update 3 4
This commit is contained in:
smart
@@ -2,7 +2,7 @@
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
Commands 把常用话术封装成快捷入口，Skills 把完整能力封装成可复用资产。
|
||||
Commands 解决高频输入，Skills 解决可复用交付。两者都不是“把 Prompt 存起来”这么简单，而是把团队经验变成可触发、可验收、可维护的资产。
|
||||
|
||||
</div>
|
||||
|
||||
@@ -10,25 +10,26 @@ Commands 把常用话术封装成快捷入口，Skills 把完整能力封装成
|
||||
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||||
<div class="font-bold mb-2">Commands</div>
|
||||
|
||||
- `.trae/commands/`
|
||||
- Markdown 定义
|
||||
- 斜杠触发
|
||||
- 适合固定提示词
|
||||
- 固定入口
|
||||
- 固定输入
|
||||
- 固定输出
|
||||
- 低风险、短流程
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
<div class="font-bold mb-2">Skills</div>
|
||||
|
||||
- `.trae/skills/`
|
||||
- 描述按需加载
|
||||
- 可带脚本、模板、示例
|
||||
- 适合完整工作流
|
||||
- 多步流程
|
||||
- 可带模板和检查清单
|
||||
- 可沉淀项目经验
|
||||
- 适合交付给团队或客户
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
Commands 是第一代封装，核心是把常说的话存起来。
|
||||
Skills 是第二代封装，核心是把完成任务所需的说明、脚本、模板和示例放在一起。
|
||||
这页让学员建立两个概念的关系。
|
||||
这一页要先帮学员纠偏：Command 和 Skill 都不是“更长的 Prompt”。
|
||||
Command 的核心是减少重复输入，让同一类轻量任务有统一入口。
|
||||
Skill 的核心是把完成任务所需的判断流程、输入要求、输出标准、模板和检查清单放在一起。
|
||||
所以今天讲能力封装，不是为了多造几个文件，而是让团队经验以后可以被重复触发、重复验收、重复维护。
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -37,23 +38,47 @@ Skills 是第二代封装，核心是把完成任务所需的说明、脚本、
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
| 场景 | 示例 |
|
||||
|---|---|
|
||||
| 固定问法 | 总结当前 PR |
|
||||
| 固定格式 | 生成 commit message |
|
||||
| 固定检查 | 跑一次代码审查 |
|
||||
| 固定输出 | 生成日报、周报、变更说明 |
|
||||
| 判断标准 | 适合 Command 的特征 | 示例 |
|
||||
|---|---|---|
|
||||
| 问法固定 | 每次提问差异很小 | 生成 PR 说明 |
|
||||
| 输入固定 | 只需要 diff、日志或单个文件 | 总结当前变更 |
|
||||
| 输出固定 | 表格或固定段落即可 | commit message |
|
||||
| 风险较低 | 不直接改核心逻辑 | 生成日报 |
|
||||
| 不需要多步判断 | 不需要跨多个规则来决策 | 格式化说明 |
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-4 p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
|
||||
Command 的关键价值是降低重复输入成本。
|
||||
Command 的关键价值是降低重复输入成本，并让轻量任务输出稳定。
|
||||
</div>
|
||||
|
||||
<!--
|
||||
Commands 很适合固定流程。
|
||||
比如每次都要总结 PR、写 commit message、生成日报，就可以做成命令。
|
||||
它的边界也清楚：主要封装 prompt，适合轻量场景。
|
||||
这里要把 Command 的边界讲清楚。
|
||||
它适合“同一句话每天都要说”的场景，比如总结 PR、生成 commit message、提取 CI 日志摘要。
|
||||
但是如果一个任务需要先读项目规则、再判断风险、再套模板、最后给验收标准，Command 就不够了。
|
||||
不要把所有事情都做成斜杠命令，否则命令库会变成另一种噪声。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Command 的坏味道
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
| 坏 Command | 问题 | 更好的方向 |
|
||||
|---|---|---|
|
||||
| `/检查代码` | 范围太大，输出不可控 | `/代码生成Review` |
|
||||
| `/优化一下` | 没有目标和验收标准 | `/按性能规则检查列表页` |
|
||||
| `/生成文档` | 不知道文档对象和读者 | `/生成PR说明` |
|
||||
| `/帮我看看` | 没有输入边界 | 改成带输入材料的 Skill |
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一页可以直接拿来点评学员写的命令。
|
||||
坏 Command 的共同特点是“看起来方便，实际上不可控”。
|
||||
AI 收到 `/检查代码` 以后，可能检查格式、可能检查 bug、可能检查权限，也可能给一段空泛评价。
|
||||
进入团队资产库的 Command 必须收敛：什么时候用、需要什么输入、输出什么格式、怎么验收。
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -64,71 +89,115 @@ Commands 很适合固定流程。
|
||||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
<div class="font-bold mb-2">按需加载</div>
|
||||
|
||||
Agent 先扫描 skill 描述，任务相关时再读取完整说明。
|
||||
Agent 先看 Skill 描述，任务相关时再读取完整说明。
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
|
||||
<div class="font-bold mb-2">可携带资源</div>
|
||||
<div class="font-bold mb-2">携带资源</div>
|
||||
|
||||
Skill 可以包含脚本、模板、示例、参考文件和检查清单。
|
||||
Skill 可以带模板、Prompt、检查清单、反例和脚本。
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="mt-6 p-3 rounded-xl bg-gray-500/10 border border-gray-500/30 text-sm">
|
||||
Skill 不是单个 Markdown，而是一组能被复制、安装和维护的工作流资产。
|
||||
</div>
|
||||
|
||||
<!--
|
||||
Skills 的两个升级非常关键。
|
||||
按需加载能减少上下文干扰，可携带资源能把经验固化成工具包。
|
||||
所以 Skill 更适合企业培训后的标准化落地。
|
||||
Skills 的关键升级有两个。
|
||||
第一是按需加载，避免把所有团队知识一次性塞进上下文。
|
||||
第二是携带资源，避免每次都重新发模板、检查清单和示例。
|
||||
所以 Skill 更适合企业培训后的标准化落地：它把老师讲过的流程变成团队以后可以继续使用的能力包。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Skill 的两种气质
|
||||
# 什么值得做成 Skill？
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-6 text-sm">
|
||||
<div class="p-4 rounded-xl bg-purple-500/10 border border-purple-500/30">
|
||||
<div class="font-bold mb-2">文科型 Skill</div>
|
||||
<div class="mt-5 text-sm">
|
||||
|
||||
- 品牌风格
|
||||
- 文档结构
|
||||
- 设计规范
|
||||
- 沟通口径
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-cyan-500/10 border border-cyan-500/30">
|
||||
<div class="font-bold mb-2">理科型 Skill</div>
|
||||
| 判断问题 | 是，就更适合 Skill |
|
||||
|---|---|
|
||||
| 是否需要多步判断？ | 权限、状态、审计、异常态、看板需要串起来 |
|
||||
| 是否需要项目证据？ | 需要读源码、配置、规则和验收记录 |
|
||||
| 是否需要多个输出？ | 矩阵、清单、Review 报告、修复记录 |
|
||||
| 是否需要资产复用？ | 客户或团队下次还会做类似任务 |
|
||||
| 是否有质量门槛？ | 必须能验收，不只是生成文字 |
|
||||
|
||||
- 自动化脚本
|
||||
- 构建命令
|
||||
- 测试流程
|
||||
- 数据处理工具链
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这个分类方便学员理解。
|
||||
文科型 Skill 主要封装风格、结构和判断标准。
|
||||
理科型 Skill 主要封装工具、脚本和执行流程。
|
||||
企业团队通常两类都需要。
|
||||
这一页是判断标准。
|
||||
表格、清单、Prompt 本身不一定要做成 Skill。
|
||||
真正适合 Skill 的，是“怎么判断、怎么生成、怎么验收、怎么闭环”。
|
||||
例如 RBAC 权限矩阵只是一个模板；但“复杂业务模块设计”需要先定角色、再定权限、再定状态、再补审计和看板，这就是 Skill。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# MCP 的价值
|
||||
# Skill 交付结构
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
<div class="mt-5 text-sm">
|
||||
|
||||
MCP 的历史价值是推动工具面向 AI 开放接口，让 Agent 能连接浏览器、数据库、文件系统、设计工具和内部平台。
|
||||
```text
|
||||
skill-name/
|
||||
├── SKILL.md
|
||||
├── agents/
|
||||
│ └── openai.yaml
|
||||
└── assets/
|
||||
├── templates/
|
||||
├── checklists/
|
||||
├── prompts/
|
||||
└── examples/
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<div class="grid grid-cols-3 gap-4 mt-8 text-sm">
|
||||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-center">打开连接可能性</div>
|
||||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-center">统一工具描述方式</div>
|
||||
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-center">推动工具生态改造</div>
|
||||
<div class="mt-5 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
|
||||
给客户交付 Skill 时，交付的是完整文件夹，不是单个 `.md`。
|
||||
</div>
|
||||
|
||||
<!--
|
||||
MCP 要讲它的历史功绩。
|
||||
它让很多原本封闭的工具开始考虑给 AI 使用的接口。
|
||||
对企业来说，MCP 的意义是把内部工具、流程系统和 Agent 连接起来。
|
||||
这一页补一个非常落地的知识点。
|
||||
客户拿到 Skill 后，不应该只拿到一段 Prompt，而应该拿到完整目录。
|
||||
SKILL.md 说明什么时候触发、怎么执行、输出什么。
|
||||
agents/openai.yaml 是工具识别和展示用的元数据。
|
||||
assets 里放模板、检查清单、Prompt、反例和案例。
|
||||
这也是为什么培训产物最后可以打包给客户，而不是只发聊天记录。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Skill 的三种交付形态
|
||||
|
||||
<div class="grid grid-cols-3 gap-4 mt-6 text-sm">
|
||||
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
|
||||
<div class="font-bold mb-2">知识型</div>
|
||||
|
||||
- 项目约束
|
||||
- 编码规范
|
||||
- 业务口径
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
<div class="font-bold mb-2">流程型</div>
|
||||
|
||||
- 复杂业务设计
|
||||
- 阶段 Review
|
||||
- 修复闭环
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
|
||||
<div class="font-bold mb-2">工具型</div>
|
||||
|
||||
- 脚本
|
||||
- CLI
|
||||
- 测试和报告
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
原来的二分法课堂里容易理解，但交付给客户时不够工程化。
|
||||
这里改成三种交付形态：知识型、流程型、工具型。
|
||||
项目约束生成属于知识型，复杂业务模块设计和 Review 属于流程型，自动跑测试或生成报告属于工具型。
|
||||
企业团队通常三类都会有，但不要混在一个 Skill 里。
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -139,16 +208,17 @@ MCP 要讲它的历史功绩。
|
||||
|
||||
| 接入方式 | 适合场景 | 课堂判断 |
|
||||
|---|---|---|
|
||||
| CLI | 命令稳定、脚本成熟、团队已有运维习惯 | 优先做轻量封装 |
|
||||
| MCP | 需要交互式工具、长连接、结构化能力描述 | 适合平台化接入 |
|
||||
| Skill | 需要把使用方法、模板、脚本一起交付 | 适合团队复用 |
|
||||
| Command | 固定话术、固定格式 | 降低重复输入 |
|
||||
| CLI | 命令稳定、脚本成熟 | 优先轻量封装 |
|
||||
| MCP | 交互式工具、结构化能力描述 | 适合平台化接入 |
|
||||
| Skill | 需要流程、模板、检查清单和示例 | 适合团队复用 |
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
底层理念是：只要工具能被命令行或接口驱动，Agent 就能接入。
|
||||
MCP 是一种协议形态，CLI 是一种通用执行方式，Skill 是一种知识和流程封装方式。
|
||||
课堂里要帮助学员选接入方式。
|
||||
MCP 是一种协议形态，CLI 是一种执行方式，Command 是轻量入口，Skill 是知识和流程封装。
|
||||
课堂里要帮助学员判断，不是所有能力都上 MCP，也不是所有能力都做 Skill。
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -160,13 +230,15 @@ MCP 是一种协议形态，CLI 是一种通用执行方式，Skill 是一种知
|
||||
| 需求 | 推荐封装 | 理由 |
|
||||
|---|---|---|
|
||||
| 每天生成日报 | Command | 固定话术、固定格式 |
|
||||
| 代码审查流程 | Skill | 需要规则、模板、示例 |
|
||||
| 项目约束生成 | Skill | 需要扫描源码、配置、规则并输出验收清单 |
|
||||
| 复杂业务模块设计 | Skill | 权限、状态、审计、看板需要串联判断 |
|
||||
| 内部平台查询 | CLI 或 MCP | 取决于现有接口形态 |
|
||||
| 设计规范落地 | Skill | 需要风格、样例、检查清单 |
|
||||
| 代码审查报告 | Skill | 需要规则、模板、反例和风险分级 |
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这个练习让学员判断同一个需求适合 command、skill、CLI 还是 MCP。
|
||||
判断标准是任务复杂度、资源依赖、团队复用和工具接入方式。
|
||||
这个练习让学员把封装方式和交付物对应起来。
|
||||
可以提醒大家：最后客户能复用的不是“今天课堂上写过的某一句 Prompt”，而是一组可安装、可复制、可维护的 Skill 包。
|
||||
判断标准是任务复杂度、资源依赖、团队复用、工具接入方式和验收成本。
|
||||
-->
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
<div class="mt-6 text-sm">
|
||||
|
||||
工单模块不是普通 CRUD。不同角色看到的数据不同、能做的动作不同、承担的责任也不同。
|
||||
工单模块不是普通 CRUD。复杂度不在字段多少，而在谁能看、谁能改、什么条件下能改，以及出问题后能否追溯。
|
||||
|
||||
</div>
|
||||
|
||||
@@ -15,9 +15,42 @@
|
||||
</div>
|
||||
|
||||
<!--
|
||||
第四天从权限矩阵开始。
|
||||
工单模块看起来像 CRUD，但真实业务里管理员、负责人、研发、测试、只读用户的权限边界完全不同。
|
||||
如果不先设计矩阵，AI 很容易按默认 CRUD 生成所有按钮。
|
||||
第四天从权限矩阵开始，不是因为权限最容易写，而是因为权限最容易被 AI 简化成 CRUD 默认逻辑。
|
||||
工单模块看起来只是增删改查，但真实企业系统里，不同角色看到的数据、能执行的动作、承担的责任完全不同。
|
||||
如果不先设计矩阵，AI 很容易把新增、编辑、删除、指派、关闭这些按钮都生成出来，后面再补权限就会很被动。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 先矩阵，后代码
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-7 text-sm">
|
||||
<div class="p-4 rounded-xl bg-red-500/10 border border-red-500/30">
|
||||
<div class="font-bold mb-2">错误顺序</div>
|
||||
|
||||
1. 先生成页面和接口
|
||||
2. 再临时隐藏按钮
|
||||
3. 最后补权限说明
|
||||
</div>
|
||||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||||
<div class="font-bold mb-2">推荐顺序</div>
|
||||
|
||||
1. 先定义角色和动作
|
||||
2. 再生成权限矩阵
|
||||
3. 最后落到菜单、按钮、接口、数据范围
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="mt-6 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
|
||||
权限矩阵是后续代码生成、Review 和验收的依据，不是交付后的补充说明。
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这里要强调开发顺序。
|
||||
AI 辅助开发最常见的问题，是先让它把 CRUD 做出来，再问“怎么加权限”。
|
||||
这样会导致权限变成页面装饰，而不是业务规则。
|
||||
正确做法是先用矩阵约束代码生成：哪些角色能看、能改、能流转、能删除、能看审计。
|
||||
后面所有页面按钮、后端接口、数据范围和测试账号，都要回到这张矩阵。
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -28,23 +61,47 @@
|
||||
|
||||
| 功能 | 管理员 | 负责人 | 研发 | 测试 | 只读 |
|
||||
|---|---|---|---|---|---|
|
||||
| 查看列表 | Y | Y | Y | Y | Y |
|
||||
| 新增工单 | Y | Y | N | Y | N |
|
||||
| 编辑工单 | Y | Y | 条件允许 | 条件允许 | N |
|
||||
| 查看列表 | Y | 条件允许 | 条件允许 | 条件允许 | 条件允许 |
|
||||
| 查看详情 | Y | 条件允许 | 条件允许 | 条件允许 | 条件允许 |
|
||||
| 新增工单 | Y | Y | Y | Y | N |
|
||||
| 编辑工单 | Y | 条件允许 | 条件允许 | 条件允许 | N |
|
||||
| 删除工单 | Y | N | N | N | N |
|
||||
| 指派工单 | Y | Y | N | N | N |
|
||||
| 提交验证 | Y | Y | Y | N | N |
|
||||
| 关闭工单 | Y | Y | N | Y | N |
|
||||
| 驳回工单 | Y | Y | N | Y | N |
|
||||
| 查看审计 | Y | Y | 条件允许 | 条件允许 | N |
|
||||
| 查看看板 | Y | Y | N | N | N |
|
||||
| 指派工单 | Y | 条件允许 | N | N | N |
|
||||
| 提交验证 | Y | 条件允许 | Y | N | N |
|
||||
| 关闭工单 | Y | 条件允许 | N | Y | N |
|
||||
| 查看审计 | Y | 条件允许 | 条件允许 | 条件允许 | N |
|
||||
| 查看看板 | Y | Y | 条件允许 | 条件允许 | 条件允许 |
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这张矩阵是课堂产出，不是讲师单方面给答案。
|
||||
AI 可以生成初稿，但最终必须由业务和团队确认。
|
||||
条件允许要写清条件，比如只能编辑自己负责的工单。
|
||||
“条件允许”不能只写四个字，必须落到条件：只能看自己创建的工单、只能处理指派给自己的工单、只能关闭待验证状态的工单，还是只能查看所在团队的数据。
|
||||
如果条件写不清，后端数据权限和测试用例就没法落地。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 条件允许要展开
|
||||
|
||||
<div class="mt-5 text-sm">
|
||||
|
||||
| 条件类型 | 示例 | 验收方式 |
|
||||
|---|---|---|
|
||||
| 数据范围 | 只能看本人、本人团队、本人负责的工单 | 不同账号列表数量不同 |
|
||||
| 状态限制 | 只有待验证才能关闭 | 非目标状态接口返回拒绝 |
|
||||
| 角色叠加 | 负责人兼管理员时按更高权限 | 用双角色账号验证 |
|
||||
| 字段限制 | 研发只能改处理说明，不能改优先级 | 提交非法字段被拒绝 |
|
||||
| 时间限制 | 已关闭工单超过窗口不能重开 | 超时重开失败 |
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这是原来矩阵里容易被忽略的知识点。
|
||||
RBAC 不是只有允许和拒绝，真实业务里大量规则都是条件允许。
|
||||
条件允许一旦不展开，AI 生成代码时就会把它理解成允许，测试时也不知道怎么验证。
|
||||
所以矩阵之后必须补条件表，让权限从“角色判断”扩展到“角色 + 数据 + 状态 + 字段 + 时间”的组合判断。
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -60,13 +117,15 @@ AI 可以生成初稿，但最终必须由业务和团队确认。
|
||||
管理员、负责人、研发、测试、只读用户。
|
||||
|
||||
功能点：
|
||||
查看列表、查看详情、新增、编辑、删除、指派、提交验证、关闭、驳回、查看审计记录、查看看板。
|
||||
查看列表、查看详情、新增、编辑、删除、指派、
|
||||
提交验证、关闭、驳回、查看审计记录、查看看板。
|
||||
|
||||
要求：
|
||||
1. 区分允许、禁止、条件允许。
|
||||
2. 条件允许必须说明条件。
|
||||
3. 每个敏感操作给出验收方式。
|
||||
4. 不要直接生成代码。
|
||||
1. 区分允许、拒绝、条件允许。
|
||||
2. 条件允许必须展开为数据、状态、字段或时间条件。
|
||||
3. 每个敏感操作给出后端接口验收方式。
|
||||
4. 标注哪些权限属于业务待确认。
|
||||
5. 不要直接生成代码。
|
||||
```
|
||||
|
||||
</div>
|
||||
@@ -74,4 +133,29 @@ AI 可以生成初稿，但最终必须由业务和团队确认。
|
||||
<!--
|
||||
这里训练学员不要直接让 AI 改代码。
|
||||
先生成矩阵，再确认业务边界，最后才进入权限控制方案。
|
||||
Prompt 里一定要写“不要直接生成代码”，因为这一页的目标是规则设计，不是实现。
|
||||
另外要让 AI 标注待确认项：谁能删除、谁能导出、谁能查看审计日志，这些不能让 AI 自己拍板。
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# AI 容易漏掉的权限风险
|
||||
|
||||
<div class="mt-5 text-sm">
|
||||
|
||||
| 风险 | 表现 | Review 问法 |
|
||||
|---|---|---|
|
||||
| 前端按钮替代权限 | 按钮隐藏，但接口可直接调 | 无权限账号直接请求会怎样 |
|
||||
| 数据范围缺失 | 所有人看到同一批工单 | 普通用户能否看到他人数据 |
|
||||
| 条件允许泛化 | “条件允许”被实现成允许 | 条件在哪里校验 |
|
||||
| 审计权限遗漏 | 审计日志对不该看的人开放 | 谁能看 old/new value |
|
||||
| 删除权限过宽 | 负责人或研发能删除工单 | 删除是否只限管理员 |
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一页是给后续 Review 铺垫。
|
||||
AI 很容易把权限理解成“有没有按钮”，但企业系统真正的风险在接口和数据范围。
|
||||
课堂里可以让学员拿这张表去追问 TRAE：这个权限风险在哪个文件、哪个接口、哪个测试账号可以验证。
|
||||
这样权限矩阵就不是一张漂亮表，而是 Review 和验收的入口。
|
||||
-->
|
||||
|
||||
Reference in New Issue
Block a user