# 审核系统422错误修复报告（补充）

## 问题描述

创建审核规则时出现 422 错误：
```
POST http://localhost:8000/api/v1/custom-rules?project_id=8f969272-4ece-49e7-8ca1-4877cc62c57c 422 (Unprocessable Entity)
```

## 问题原因分析

### 根本原因：字段名称不匹配

**前端发送的字段名：** `category`（如 "character", "plot" 等）
**后端期望的字段名：** `dimension`（如 `DimensionType.character`, `DimensionType.plot` 等）

后端的 `CustomRuleCreate` 模型只接受 `dimension` 字段，不接受 `category` 字段，导致 FastAPI 验证失败。

## 修复方案

### 1. 修改后端数据模型（backend/app/models/review.py）

#### 修改 CustomRuleCreate 模型
```python
class CustomRuleCreate(BaseModel):
    """创建自定义规则请求"""
    name: str = Field(..., description="规则名称")
    description: str = Field("", description="规则描述")
    trigger_condition: str = Field(..., description="触发条件")
    dimension: Optional[DimensionType] = Field(None, description="所属维度")
    severity: SeverityLevel = Field(SeverityLevel.medium, description="严重程度")
    category: Optional[str] = Field(None, description="分类（前端使用）")  # 新增
```

#### 修改 CustomRuleUpdate 模型
```python
class CustomRuleUpdate(BaseModel):
    """更新自定义规则请求"""
    name: Optional[str] = None
    description: Optional[str] = None
    trigger_condition: Optional[str] = None
    dimension: Optional[DimensionType] = None
    severity: Optional[SeverityLevel] = None
    enabled: Optional[bool] = None
    category: Optional[str] = None  # 新增
```

### 2. 修改后端 API 路由（backend/app/api/v1/review.py）

#### 创建规则函数中的映射逻辑
```python
# 处理 category 到 dimension 的映射
if rule_data.category:
    # 映射 category 到 dimension
    category_to_dimension = {
        "character": DimensionType.character,
        "plot": DimensionType.plot,
        "dialogue": DimensionType.dialogue,
        "pacing": DimensionType.pacing,
        "emotion": DimensionType.emotional_depth,
        "theme": DimensionType.thematic_strength,
        "other": DimensionType.custom
    }
    dimension = category_to_dimension.get(rule_data.category, DimensionType.custom)
else:
    dimension = rule_data.dimension or DimensionType.custom
```

#### 更新规则函数中的映射逻辑
```python
# 处理 category 到 dimension 的映射
if 'category' in update_data:
    category_to_dimension = {
        "character": DimensionType.character,
        "plot": DimensionType.plot,
        "dialogue": DimensionType.dialogue,
        "pacing": DimensionType.pacing,
        "emotion": DimensionType.emotional_depth,
        "theme": DimensionType.thematic_strength,
        "other": DimensionType.custom
    }
    update_data['dimension'] = category_to_dimension.get(
        update_data['category'],
        rule.dimension or DimensionType.custom
    )
    # 移除 category 字段
    del update_data['category']
```

### 3. 修改前端错误处理（frontend/src/pages/ReviewConfig.tsx）

#### 创建规则错误处理
```typescript
} catch (error) {
  console.error('Create rule error:', error)
  const errorMsg = (error as any)?.response?.data?.detail ||
                   (error as any)?.message ||
                   '规则创建失败'
  message.error(`规则创建失败: ${errorMsg}`)
}
```

#### 更新规则错误处理
```typescript
} catch (error) {
  console.error('Update rule error:', error)
  const errorMsg = (error as any)?.response?.data?.detail ||
                   (error as any)?.message ||
                   '规则更新失败'
  message.error(`规则更新失败: ${errorMsg}`)
}
```

## 测试建议

### 1. 测试创建规则功能
1. 进入审核配置页面
2. 点击"添加规则"
3. 填写规则信息，选择分类（如"角色"）
4. 点击"创建规则"
5. 确认成功创建且无 422 错误

### 2. 测试更新规则功能
1. 编辑已创建的规则
2. 修改分类或其他信息
3. 点击"更新规则"
4. 确认成功更新且无 422 错误

### 3. 验证数据映射
- 创建规则后，检查后端数据库中的 `dimension` 字段是否正确映射
- 更新规则时，确保分类修改能正确反映到 `dimension` 字段

## 前后端数据映射关系

| 前端分类 | 后端维度 | 说明 |
|---------|---------|------|
| character | DimensionType.character | 角色相关 |
| plot | DimensionType.plot | 剧情相关 |
| dialogue | DimensionType.dialogue | 对话相关 |
| pacing | DimensionType.pacing | 节奏相关 |
| emotion | DimensionType.emotional_depth | 情感相关 |
| theme | DimensionType.thematic_strength | 主题相关 |
| other | DimensionType.custom | 其他 |

## 修复完成状态

✅ **已修复**：
- 后端数据模型支持 `category` 字段
- 创建规则时的 category 到 dimension 映射
- 更新规则时的 category 到 dimension 映射
- 前端错误处理改进，显示具体错误信息

## 总结

通过在后端添加对前端 `category` 字段的支持，并在创建/更新规则时进行到 `dimension` 的映射，解决了前后端字段名称不匹配导致的 422 错误。这种方案既保持了后端数据模型的规范性，又兼容了前端的实现方式。

建议全面测试审核规则的所有操作，确保没有引入新的问题。