# **权限与角色体系梳理报�?\- 审查反馈与修正建�?*

审查对象�?00-权限与角色体系梳理报告\_v1.0.md  
对比基准�?07-运营与机构管理端PRD\_v2.1.md  
审查结论�?总体通过 (Approved with Modification)。基础架构设计扎实，需补充少量针对业务场景（医院配额、Prompt调试）的字段设计�?
## **1\. 核心问题与差距分�?(Gap Analysis)**

虽然 v1.0 报告构建了坚实的 RBAC 基础，但在支�?PRD v2.1 的特定业务场景时，存在以下缺失：

### **1.1 缺失“精细化配额分配”模�?(Critical)**

* **现状**：报告中设计�?tenant\_quotas 表，看似是针对租户的总配额�? 
* **PRD 要求**：医院端需要将配额分配�?**科室 (Department)** �?**个人**�? 
* 修正建议�? 
  需要引�?PRD v2.1 中定义的 TenantQuotaAllocation 表结构，支持 targetType ('DEPARTMENT' | 'USER')�? 
  model TenantQuotaAllocation {  
    id          Int      @id @default(autoincrement())  
    tenantId    String   @map("tenant\_id") @db.Uuid  
    targetType  String   // 'DEPARTMENT' | 'USER'  
    targetKey   String   // DepartmentID �?UserID  
    limitAmount BigInt   // 分配额度  
    usedAmount  BigInt   @default(0)

    @@unique(\[tenantId, targetType, targetKey\])  
    @@map("tenant\_quota\_allocations")  
    @@schema("platform\_schema")  
  }

### **1.2 缺失“Prompt 工程化”相关权�?*

* **现状**：报告关注了通用的租户管理权限�? 
* **PRD 要求**：运营端需�?**Prompt 灰度预览** 功能。这意味着需要一个特殊的权限�?prompt:debug，允许用户在生产环境读取 Draft 数据�? 
* **修正建议**：在设计 permissions（如果打算做细粒度控制）或代码常量中，明确预�?PROMPT\_ADMIN �?DEBUGGER 角色能力�?
### **1.3 审计日志的合规性要�?*

* **现状**：报告提到了 admin\_operation\_logs�? 
* **PRD 要求**：药企端 (Pharma) 对审计日志有 FDA 21 CFR Part 11 的合规要求（数据修改痕迹）�? 
* **修正建议**：确�?Log 表包�?beforeData �?afterData (已包含，很好)，但建议增加 module 字段（区分是 IIT 模块的日志还是系统配置日志），以便药企端只查询自己相关的日志�?
## **2\. 数据库设计审�?(Schema Review)**

### **2.1 用户表统一策略 (User Table)**

你的决策：保�?platform\_schema.users，删�?public.users�? 
评价：✅ 完全正确�? 
提醒：迁移数据时，务必注�?public.users 中的 id 如果不是 UUID 格式（如果是旧系统生成的），需要做映射处理，否则关联外键会报错�?
### **2.2 租户成员表命�?(Naming Convention)**

你的设计：TenantUser / tenant\_users  
PRD 设计：TenantMember / tenant\_members  
建议：建议统一使用 TenantMember。因�?"User" 通常指登录账号实体，�?"Member" 指某种组织关系中的身份。这种语义区分在代码中（�?member.role vs user.role）会更清晰�?
### **2.3 部门表结�?(Department)**

你的设计：支持树形结�?(parentId)�? 
评价：✅ 优秀。这为未来支持大型三甲医院的复杂科室结构（内�?\-\> 心内�?\-\> 一病区）打下了基础�?
## **3\. 技术路线可行性评�?*

### **3.1 JWT 方案**

* **评价**：使�?jsonwebtoken \+ localStorage 是标准且成熟�?SPA 方案�? 
* **风险提示**：localStorage 容易受到 XSS 攻击。虽�?MVP 阶段可接受，但建议后续（特别是药企端上线前）考虑 **HttpOnly Cookie** 方案，或者在前端加强 XSS 防护�?
### **3.2 权限中间�?(requireTenantAccess)**

* **评价**：这是多租户隔离的核心�? 
* **补充建议**：除�?API 层的中间件，强烈建议按照我之前提供的 **Prisma Extension** 方案，在数据库访问层（ORM）再加一道锁�? 
  * *原因*：开发人员可能会忘记�?Controller 里加中间件，但很难绕过全局�?Prisma Client 扩展�?
### **3.3 品牌定制 (Branding)**

* **评价**：报告中已包�?api/public/tenant-config 接口�? 
* **提醒**：该接口务必加上 **缓存 (Cache)** 控制（如 Cache-Control: public, max-age=3600），因为每个用户打开登录页都会调用，高并发下不要直接打数据库�?
## **4\. 开发计划优化建�?*

报告中的 **8.5 Phase 4 (运营�?MVP)** �?**8.6 Phase 5 (专属登录)** 排期合理�?
**建议调整点：**

1. **Phase 0 (数据迁移) 必须有回滚方�?*�? 
   * 在删�?public.users 之前，先将其重命名为 public.users\_backup，保�?1 周，防止迁移脚本�?Bug 导致数据丢失�? 
2. **提前定义“超级管理员”种子数�?*�? 
   * �?Prisma Seed 脚本中，硬编码一个超级管理员账号（如 admin@yizhengxun.com），否则系统上线后你进不去后台�? 
3. **前端权限 Mock 的平滑过�?*�? 
   * �?Phase 3 对接时，不要直接删除 PermissionContext，而是修改其内部实现，�?API 获取数据替代 Mock 数据，这样可以最小化改动前端业务代码�?
## **5\. 总结**

这份《权限与角色体系梳理报告》是一个非常棒的工程起点。它没有过度设计，准确抓住了 MVP 的核心�?
**下一步行动指令：**

1. **采纳**：将表名 TenantUser 修改�?TenantMember�? 
2. **增加**：在 Schema 中增�?TenantQuotaAllocation 表（参�?1.1）�? 
3. **执行**：按照报告中�?Phase 0 \- Phase 6 开始执行�?
**结论�?* 文档质量高，风险可控�?*可以开始开�?*�