# 唐朝三省制协作流程

> **三省六部制**：中书省决策、门下省审核、尚书省执行，三省相互制衡。

---

## 📋 标准流程

```
皇帝（用户）
  ↓
【旨意】
  ↓
中书省（起草诏令）
  ↓
门下省（审核封驳）
  ├─ ✅ 通过 → 尚书省
  ├─ ⚠️ 补充 → 皇帝
  └─ ❌ 驳回 → 中书省修改
  ↓
尚书省（派发六部）
  ↓
六部执行（兵户礼工刑吏）
  ↓
汇总汇报
```

---

## 🔄 中书省↔门下省 打回协调机制

### 核心原则

**"反复打磨，追求完美"**

- 中书省起草 → 门下省审核 → 问题打回 → 中书省修改 → 门下省再审
- **不通过不罢休**，直到方案完美
- 这是**质量保证的关键**，不是效率障碍

---

### 打回流程示例

#### 第一轮

**中书省草案：**
```
【诏令草案】
任务：开发用户登录功能
执行：兵部负责
时间：3 天
```

**门下省驳回：**
```
【门下省审核·驳回】

❌ 驳回原因：
1. 【技术选型缺失】未说明使用什么技术栈
2. 【风险评估缺失】未评估安全风险（SQL 注入？XSS？）
3. 【成功标准模糊】"完成"的定义不明确

修改建议：
1. 补充技术栈（Node.js+JWT？Python+Flask？）
2. 补充安全风险评估和应对方案
3. 明确成功标准（通过测试？上线运行？）
```

---

#### 第二轮

**中书省修订草案：**
```
【修订诏令草案 v2】
任务：开发用户登录功能
技术栈：Node.js + Express + JWT
时间：3 天
安全：使用 bcrypt 加密密码
```

**门下省再次驳回：**
```
【门下省审核·驳回】

❌ 驳回原因：
1. 【技术选型理由不足】为什么选 Node.js 不选 Python？
2. 【安全评估不完整】
   - 只提到密码加密
   - 未评估：SQL 注入、XSS、CSRF、暴力破解
3. 【执行步骤模糊】"兵部负责"太笼统，需要拆解

修改建议：
1. 补充技术选型理由（性能？团队熟悉度？）
2. 补充完整安全评估和应对方案
3. 拆解执行步骤（数据库设计→API 开发→前端对接→测试）
```

---

#### 第三轮

**中书省修订草案 v3：**
```
【修订诏令草案 v3】

一、任务描述
开发用户登录功能，支持用户名密码登录

二、技术选型
- 后端：Node.js + Express（团队熟悉，生态丰富）
- 认证：JWT（无状态，易扩展）
- 加密：bcrypt（业界标准）

三、执行步骤
1. 数据库设计（兵部 - 架构组）- 0.5 天
2. API 开发（兵部 - 后端组）- 1.5 天
3. 前端对接（兵部 - 前端组）- 0.5 天
4. 安全测试（御史台）- 0.5 天

四、安全风险评估
| 风险 | 等级 | 应对方案 |
|------|------|----------|
| SQL 注入 | 高 | 使用参数化查询 |
| XSS | 中 | 输入验证 + 输出转义 |
| CSRF | 中 | 使用 CSRF Token |
| 暴力破解 | 高 | 限流 + 验证码 |

五、成功标准
- ✅ 通过所有单元测试
- ✅ 通过御史台安全审查
- ✅ 上线运行无故障
```

**门下省通过：**
```
【门下省审核·通过】

✅ 通过

意见：
- 技术选型理由充分
- 安全风险评估完整
- 执行步骤清晰
- 准予尚书省派发执行
```

---

## ⚠️ 特殊情况处理

### 三次打回仍无法达成一致

**升级机制：**
```
门下省：第三次驳回，请皇帝仲裁

【仲裁申请】
争议点：
1. 中书省认为 XXX 可行
2. 门下省认为 XXX 不可行

双方理由：
- 中书省：XXX
- 门下省：XXX

请皇帝裁决。
```

**皇帝裁决后：**
- 如支持门下省 → 中书省必须修改
- 如支持中书省 → 门下省必须通过（但可保留意见）

---

### 紧急任务（Hotfix）

**快速通道：**
```
皇帝：紧急！生产环境 bug，立即修复

中书省：【紧急诏令】
- 标注：🔴 紧急 Hotfix
- 简化流程：中书省→尚书省（跳过门下省）
- 事后补审：24 小时内补交门下省备案
```

---

## 📊 质量 vs 效率平衡

| 任务类型 | 流程 | 预计时间 |
|----------|------|----------|
| **重大功能** | 完整三省流程 | 2-3 轮审核 |
| **常规任务** | 标准流程 | 1-2 轮审核 |
| **紧急 Hotfix** | 快速通道 | 直接执行 |
| **简单问答** | 跳过三省 | 直接回答 |

---

## 🎯 成功标准

**好的三省协作：**
- ✅ 中书省草案质量高，门下省打回率低
- ✅ 门下省审核严格，问题全部暴露
- ✅ 尚书省执行顺利，返工率低
- ✅ 最终交付物质量高，用户满意

**差的三省协作：**
- ❌ 中书省草案模糊，门下省反复打回
- ❌ 门下省放水，问题方案流入执行
- ❌ 尚书省执行困难，频繁返工
- ❌ 最终交付物质量差，用户不满

---

## 💡 提示

- **三省制衡是质量保证，不是效率障碍**
- **门下省打回不是针对个人，是对事不对人**
- **中书省不要抵触打回，这是提升方案质量的机会**
- **尚书省发现方案问题，有权要求中书省重新起草**
- **三次打回仍无法一致 → 请皇帝仲裁，不要僵持**

---

**最后更新**：2026-03-22
