07-platform-governance

name	07-platform-governance
description	设计平台治理规则与生态体系。当用户说"平台治理"、"内容审核"、"社区规则"、"生态治理"、"平台规则"时使用。

Platform Governance

何时使用

• 需要设计平台的治理规则或社区准则
• 需要处理平台生态中的利益冲突
• 需要设计内容审核或信任安全机制
• 需要理解不同平台类型的治理重点

工作流程

Step 1: 分析平台类型与参与者

识别平台治理的基本框架：

• 平台类型：内容型/交易型/SaaS/创作者经济/API 开发者
• 参与者：供给方、需求方、平台方
• 各方利益诉求和潜在冲突点

Step 2: 设计治理规则

建立规则体系：

• 准入规则：谁能进来？
• 行为规则：什么能做/不能做？
• 激励规则：好行为如何奖励？
• 惩罚规则：违规如何处理？

Step 3: 合规与风控

确保满足监管要求：

• GDPR/DSA/网络安全法等适用法规
• 内容审核机制（AI 初审 + 人工复审）
• 用户申诉与透明度机制

Step 4: 输出治理方案

使用落地模板生成治理策略文档，包含：

• 平台规则框架
• 执行机制
• 监控指标与巡检方案

关键原则

原则	说明
规则一致 > 规则严格	选择性执法比没有规则更差
渐进式改变	大规则变更需要提前通知和过渡期
透明决策	用户要知道为什么被处罚
三方共赢	任何政策变更都要检查三方利益
预防 > 处罚	好的产品设计让违规行为更难发生

落地模板

# 平台规则设计：[规则名称]

## 1. 规则背景
- 要解决什么问题：[...]
- 当前现状：[问题的具体数据——投诉量/违规率/用户流失]
- 为什么现在要做：[触发因素]

## 2. 利益方分析
| 利益方 | 正面影响 | 负面影响 | 净影响 |
|--------|---------|---------|--------|
| 普通用户 | | | 正面/负面/中性 |
| 内容创作者/商家 | | | |
| 平台 | | | |

### 如果不做这条规则
- 用户端会怎样：[...]
- 创作者/商家端会怎样：[...]
- 平台会怎样：[...]

## 3. 规则设计
### 规则内容
- 明确的行为定义：[什么行为违规——要具体到用户能判断]
- 处理措施：[分级——警告/限流/封禁]
- 申诉机制：[怎么申诉/多久回复/谁来判]

### 分级处理
| 违规等级 | 行为举例 | 处理方式 | 恢复条件 |
|---------|---------|---------|---------|
| 轻微 | | 警告 | |
| 中等 | | 限流N天 | |
| 严重 | | 封禁 | |
| 极严重 | | 永久封禁 | |

### 预防设计（产品层面）
- 如何通过产品设计减少违规发生：[...]
- 是否可以在行为发生前拦截：[...]
- 是否可以通过引导替代惩罚：[...]

## 4. 过渡方案
### 时间线
| 节点 | 动作 | 沟通方式 |
|------|------|---------|
| T-14天 | 公告新规则 | APP弹窗+公告 |
| T-7天 | 提醒已有违规内容 | 站内信 |
| T | 新规则生效 | |
| T+7天 | 第一轮宽限执行 | 只警告不处罚 |
| T+14天 | 正式执行 | |

### 老数据处理
- 新规则是否追溯历史内容：[是/否/有条件]
- 如果追溯，给多久整改期：[...]

## 5. 监测与迭代
### 关键指标
| 指标 | 基线 | 目标 | 预警线 |
|------|------|------|--------|
| 违规率 | | | |
| 误判率 | | | |
| 申诉量 | | | |
| 用户满意度 | | | |

### 迭代计划
- a/b 周复盘数据
- 每月收集利益方反馈
- 每季度评估是否需要调整

参考资料

详细理论基础、原则解析和推荐书目见 references/knowledge.md。