SA1-星图管理制度

来自星图

0. 制度目标

[编辑 | 编辑源代码]

本制度旨在规范星图项目的日常运营,确保:

  1. 内容质量:维持中性、可验证、描述性的写作标准
  2. 协作效率:明确分工、流程透明、决策有据
  3. 风险控制:防范法律风险、保护隐私、处理争议
  4. 可持续发展:建立迭代机制、培养编辑团队、积累知识资产

1. 组织架构与角色分工

[编辑 | 编辑源代码]

1.1 核心角色

[编辑 | 编辑源代码]

1.1.1 项目负责人(Project Lead)

[编辑 | 编辑源代码]
  • 职责
    • 制定项目整体方向与年度目标
    • 审批重大分类调整与制度修订
    • 处理重大争议与危机事件
    • 协调资源分配与团队建设
  • 权限:最高审批权、制度修订权、人员任免权

1.1.2 分类架构师(Taxonomy Architect)

[编辑 | 编辑源代码]
  • 职责
    • 维护L1-L3分类体系的一致性
    • 审核新增分类提案
    • 处理分类冲突与边界争议
    • 定期优化分类逻辑
  • 权限:分类体系调整权、L1-L3条目审批权

1.1.3 内容编辑(Content Editor)

[编辑 | 编辑源代码]
  • 职责
    • 撰写与编辑L4-L5条目
    • 执行质量检查清单
    • 收集社群反馈与更新需求
    • 协助新编辑培训
  • 权限:L4-L5条目创建与编辑权

1.1.4 审核员(Reviewer)

[编辑 | 编辑源代码]
  • 职责
    • 复核待发布条目
    • 检查证据来源与中性表述
    • 标注风险属性
    • 处理举报与修改请求
  • 权限:条目审核权、风险标注权

1.1.5 技术维护(Tech Maintainer)

[编辑 | 编辑源代码]
  • 职责
    • 维护知识库技术架构(Obsidian/MediaWiki等)
    • 开发自动化工具(链接检查、格式校验)
    • 数据备份与迁移
    • 权限系统管理
  • 权限:系统管理权限

2. 内容管理规范

[编辑 | 编辑源代码]

2.1 收录标准(必须同时满足)

[编辑 | 编辑源代码]
  1. 社群沉淀:存在可验证的持续性社群活动(时长要求见2.1.1)
  2. 文化机制:具有稳定的参与方式、话语体系或组织形态
  3. 可描述性:能用中性语言清晰界定边界
  4. 证据充分:至少2条B级或以上证据(见SA0总指南5.3)

2.1.1 时效性分级收录标准

[编辑 | 编辑源代码]

说明: 部分内容因其快速迭代特性,允许较短收录周期,但需严格验证传播路径和文化影响力。

2.2 排除标准(任一即排除)

[编辑 | 编辑源代码]
  1. 一次性热点事件,无社群延续
  2. 纯商业促销活动
  3. 无法验证的传闻或谣言
  4. 过度依赖个人隐私信息

2.3 敏感内容处理

[编辑 | 编辑源代码]
  • 未成年人相关
    • 不收录以未成年人为主体的圈层
    • 涉及未成年人参与的圈层需标注风险
    • 严禁收录任何性化未成年人的内容
  • 争议高风险内容
    • 需经审核员+分类架构师双重审核
    • 必须标注#争议高标签
    • 在"争议与风险"章节详细说明
  • 商业化内容
    • 区分"文化现象"与"商业推广"
    • 避免成为品牌宣传平台
    • 标注#商业化强标签

2.3.1 限制级内容制度

[编辑 | 编辑源代码]

部分内容虽符合收录标准,但需限制访问:

触发条件(满足任一即为限制级):

  • 描述的行为在现实中可能造成伤害(如跟踪、人肉搜索技巧)
  • 涉及高度争议的政治/宗教/伦理议题
  • 包含可能被模仿的危险行为

展示规则:

  • 页面顶部显示标准警示语:"本条目记录的是文化现象,不代表认可或鼓励相关行为。"
  • 需登录账号方可查看完整内容
  • 风险属性标注#限制级

商业合作零容忍声明:

星图项目不接受任何形式的商业赞助、付费收录或内容美化请求。如遇此类接触,项目负责人有权直接拒绝,无需说明理由。

2.4 隐私保护原则

[编辑 | 编辑源代码]
  • 个人信息脱敏
    • 不收录普通参与者的真实姓名、联系方式
    • 公众人物限于已公开信息
    • 截图需打码处理
  • 社群内部信息
    • 不公开私密群组的内部讨论
    • 引用需征得原作者同意或匿名化
  • 举报与删除
    • 当事人有权要求删除涉及自身的非公开信息

3. 编辑流程与权限管理

[编辑 | 编辑源代码]

3.1 标准编辑流程

[编辑 | 编辑源代码]

阶段1:提案(Proposal)

[编辑 | 编辑源代码]
  • 提交者:任何编辑或社群成员
  • 内容要求
    • 一句话定义
    • 拟分类路径(L1>L2>L3)
    • 至少3条证据来源
    • 说明收录必要性
  • 审批
    • L4-L5条目:内容编辑自审
    • L1-L3调整:分类架构师审批
  • 时限:3个工作日内给出反馈

阶段2:初稿(Draft)

[编辑 | 编辑源代码]
  • 撰写者:内容编辑
  • 要求
    • 按对应层级模板完成
    • 完成质量检查清单(SA0总指南10)
    • 标注证据等级
  • 协作:可邀请其他编辑共同撰写

阶段3:复核(Review)

[编辑 | 编辑源代码]
  • 复核者:审核员
  • 检查项
    • 分类准确性
    • 边界清晰度
    • 中性表述
    • 证据有效性
    • 风险标注
  • 结果
    • 通过:进入发布
    • 修改:退回编辑并说明理由
    • 拒绝:存档并说明原因
  • 时限:5个工作日

阶段4:发布(Publish)

[编辑 | 编辑源代码]
  • 操作:技术维护或内容编辑
  • 动作
    • 移入正式库
    • 建立双向链接
    • 更新索引
    • 记录变更日志

阶段5:迭代(Iteration)

[编辑 | 编辑源代码]
  • 触发条件
    • 社群反馈
    • 新证据出现
    • 分类调整
    • 季度例行更新
  • 流程:简化版(提案→修改→复核→发布)

3.2 快速通道(Fast Track)

[编辑 | 编辑源代码]

适用于:

  • 紧急更新(重大事件、风险预警)
  • 小幅修订(错别字、链接修复)
  • 技术性调整(格式统一、标签补充)

流程:编辑直接修改 → 事后通知审核员

3.3 权限分级

[编辑 | 编辑源代码]
角色 L1-L3 L4-L5 标签 审核 删除 系统
项目负责人
分类架构师 -
内容编辑 - - - -
审核员 - 只读 -
技术维护 - - - - -

3.3.1 跨界分类处理规则

[编辑 | 编辑源代码]

对于天然跨越多个L1/L2的圈层:

  • 主分类唯一:按参与动机优先级确定唯一主路径(见SA0总指南4.1)
  • 辅助分类:在MediaWiki中可添加多个[[Category:]]作为辅助索引,不影响主分类
  • 模板标注:使用模板:主分类模板在条目顶部明确主路径,其余分类仅作检索用途
  • 示例:VTuber应援行为主分类为D2,同时添加Category:C3辅助索引

3.3.2 AI辅助监督机制

[编辑 | 编辑源代码]

AI作为辅助工具参与以下场景,不作为最终裁决者

  • 分类一致性检查:检测新条目的分类路径是否与现有体系冲突
  • 中性度评分:标记可能含有价值判断的表述,供审核员参考
  • 证据有效性初筛:检测引用链接是否失效

人工复核要求: AI标记的所有问题须经审核员确认后方可处理,AI建议不自动生效。

3.4 权限申请与变更

[编辑 | 编辑源代码]
  • 新编辑加入
    • 提交申请(说明背景与动机)
    • 完成培训(阅读SA0总指南+试写1篇L5条目)
    • 试用期1个月(至少完成3篇条目)
    • 转正后获得完整编辑权限
  • 权限升级
    • 内容编辑→审核员:需6个月经验+推荐
    • 审核员→分类架构师:需1年经验+项目负责人任命
  • 权限撤销
    • 长期不活跃(>3个月无贡献)
    • 违反制度(视情节轻重)
    • 主动申请退出

4. 争议处理机制

[编辑 | 编辑源代码]

4.1 争议类型

[编辑 | 编辑源代码]

类型A:分类争议

[编辑 | 编辑源代码]
  • 表现:对条目应归属哪个L1/L2/L3存在分歧
  • 处理
    1. 编辑提出不同方案(各附理由)
    2. 分类架构师裁决
    3. 记录决策依据,更新分类判定规则

类型B:内容争议

[编辑 | 编辑源代码]
  • 表现:对描述准确性、中性性存在质疑
  • 处理
    1. 举报者提供反驳证据
    2. 审核员核查
    3. 编辑修订或维持原文
    4. 争议较大时可标注"存在争议"并列出不同观点

类型C:收录争议

[编辑 | 编辑源代码]
  • 表现:对是否应收录某圈层存在分歧
  • 处理
    1. 对照收录/排除标准
    2. 审核员+分类架构师联合评估
    3. 边界案例提交项目负责人决策
    4. 决策记录存档,作为后续参考

类型D:风险争议

[编辑 | 编辑源代码]
  • 表现:对内容是否涉及法律/伦理风险存在分歧
  • 处理
    1. 立即暂停发布
    2. 项目负责人+审核员评估
    3. 必要时咨询法律顾问
    4. 决定:修改/删除/标注风险/维持原文

4.2 举报与申诉

[编辑 | 编辑源代码]
  • 举报渠道
    • 内部:编辑群组/项目管理系统
    • 外部:公开邮箱/表单(需提供证据)
  • 处理时限
    • 一般举报:7个工作日
    • 紧急风险:24小时内响应
  • 申诉机制
    • 对审核结果不满可向项目负责人申诉
    • 申诉需提供新证据或指出程序问题
    • 项目负责人裁决为最终决定

4.3 冲突解决原则

[编辑 | 编辑源代码]
  1. 证据优先:以可验证证据为准,而非主观判断
  2. 中性立场:不偏袒任何圈层或观点
  3. 透明决策:重大争议的处理依据需公开
  4. 从严把关:存疑时宁可不收录,避免风险

5. 质量控制体系

[编辑 | 编辑源代码]

5.1 质量标准(三级)

[编辑 | 编辑源代码]

★★★ 优质条目

[编辑 | 编辑源代码]
  • 证据等级A或多条B级
  • 结构完整,逻辑清晰
  • 双向链接完善
  • 定期更新(<6个月)

★★ 合格条目

[编辑 | 编辑源代码]
  • 至少2条B级证据
  • 符合模板要求
  • 基本链接完整

★ 待完善条目

[编辑 | 编辑源代码]
  • 仅有C级证据或证据不足
  • 结构不完整
  • 需补充更新

5.2 质量检查机制

[编辑 | 编辑源代码]
  • 新条目发布前:必须通过质量检查清单(SA0总指南10)
  • 季度抽查:随机抽取10%条目进行复核
  • 用户反馈:建立反馈渠道,及时处理质量问题
  • 年度评估:评选优质条目,淘汰低质条目

5.3 常见质量问题与处理

[编辑 | 编辑源代码]
问题 处理方式 责任人
证据失效(链接失效) 补充新证据或标注"待更新" 原编辑
表述不中性 修改为描述性语言 审核员
分类错误 重新分类并更新链接 分类架构师
内容过时 补充最新发展或标注时效性 任意编辑
边界模糊 补充"不是什么"章节 原编辑

6. 技术与安全管理

[编辑 | 编辑源代码]

6.1 数据备份

[编辑 | 编辑源代码]
  • 频率:每日自动备份
  • 存储:本地+云端双重备份
  • 保留:至少保留近3个月的版本
  • 测试:每季度进行一次恢复测试

6.2 版本控制

[编辑 | 编辑源代码]
  • 工具:Git或类似版本控制系统
  • 提交规范
    • 格式:[类型] 简要说明
    • 类型:新增/修改/删除/重构/修复
    • 示例:[新增] L4-某圈子档案
  • 分支策略
    • main:稳定发布版
    • dev:开发分支
    • feature/*:功能分支

6.3 访问控制

[编辑 | 编辑源代码]
  • 内部编辑:需账号登录,权限分级
  • 公开访问
    • 只读模式
    • 敏感内容需登录查看
    • 风险内容需确认年龄

6.4 安全事件响应

[编辑 | 编辑源代码]
  • 数据泄露
    1. 立即评估泄露范围
    2. 通知受影响用户
    3. 修复漏洞
    4. 复盘并改进
  • 恶意篡改
    1. 回滚到最近备份
    2. 排查入侵途径
    3. 加强权限管理
  • 法律风险
    1. 立即下线相关内容
    2. 咨询法律顾问
    3. 配合调查
    4. 更新风险防控机制

7. 社群协作规范

[编辑 | 编辑源代码]

7.1 沟通原则

[编辑 | 编辑源代码]
  • 尊重:尊重不同观点,避免人身攻击
  • 建设性:提出问题时附带改进建议
  • 透明:重要决策公开讨论
  • 效率:避免无意义争论,及时达成共识

7.2 协作工具

[编辑 | 编辑源代码]
  • 文档协作:Obsidian/MediaWiki/Notion
  • 任务管理:Trello/GitHub Issues/飞书多维表格
  • 即时通讯:Discord/Slack/企业微信
  • 会议:腾讯会议/Zoom(录屏存档)

7.3 贡献激励

[编辑 | 编辑源代码]
  • 认可机制
    • 贡献榜(按条目数/质量评分)
    • 优秀编辑表彰
    • 署名权(条目创建者)
  • 成长路径
    • 新手编辑→资深编辑→审核员→分类架构师
    • 提供培训与指导
  • 非物质激励
    • 参与感与成就感
    • 专业能力提升
    • 社群归属感

7.4 资金困境应对方案

[编辑 | 编辑源代码]

当项目面临资金或资源短缺时,启动降级方案:

7.4.1 平台迁移预案

[编辑 | 编辑源代码]
  • 目标平台:Miraheze(免费MediaWiki托管)或GitHub Pages(静态站点)
  • 迁移触发条件:主站运营成本无法维持超过3个月
  • 迁移流程
    1. 提前1个月公告
    2. 导出全部条目(XML/Markdown格式)
    3. 在目标平台重建分类结构
    4. 保留原站只读访问(如可能)

7.4.2 捐款透明机制

[编辑 | 编辑源代码]

如开放捐款渠道:

  • 每月公开收支明细(托管费、域名费、工具订阅等)
  • 捐款仅用于基础设施,不支付人员报酬
  • 剩余资金滚存至下月,年度结余公示

7.4.3 最小维护模式

[编辑 | 编辑源代码]

当活跃编辑不足3人时,自动进入最小维护模式:

  • 暂停新增:停止收录新条目,仅维护现有内容
  • AI辅助:使用AI工具进行链接检查、格式校验等机械性工作
  • 社群自治:开放用户反馈通道,由社群标记错误和过时内容
  • 定期唤醒:每季度评估是否恢复正常模式

8. 制度维护与修订

[编辑 | 编辑源代码]

8.1 修订触发条件

[编辑 | 编辑源代码]
  • 实践中发现制度漏洞
  • 项目规模变化(人员/内容量)
  • 外部环境变化(法律法规/平台政策)
  • 年度例行审查

8.2 修订流程

[编辑 | 编辑源代码]
  1. 提案:任何成员可提出修订建议
  2. 讨论:核心团队讨论可行性
  3. 草案:起草修订版本
  4. 征求意见:全体编辑投票或反馈
  5. 审批:项目负责人批准
  6. 公示:提前7天公示新版本
  7. 生效:正式实施并存档旧版本

8.3 制度解释权

[编辑 | 编辑源代码]
  • 本制度最终解释权归项目负责人
  • 未尽事宜由核心团队讨论决定
  • 特殊情况可临时豁免,但需事后补充制度

9. 附则

[编辑 | 编辑源代码]

9.1 生效日期

[编辑 | 编辑源代码]

本制度自2026年4月19日起生效。

9.2 适用范围

[编辑 | 编辑源代码]

本制度适用于星图项目的所有参与者,包括但不限于:

  • 核心团队成员
  • 内容编辑与审核员
  • 技术维护人员
  • 外部贡献者

9.3 与其他文档的关系

[编辑 | 编辑源代码]
  • 本制度与《SA0-星图写作与分类总指南》配套使用
  • 总指南侧重"怎么写",本制度侧重"怎么管"
  • 如有冲突,以最新版本为准

9.4 联系方式

[编辑 | 编辑源代码]

10. 变更记录

[编辑 | 编辑源代码]
版本 日期 修订内容 修订人
v1.0 2026-04-19 初始版本发布 Lixx
v1.1 2026-04-19 补充:限制级内容制度、时效性分级、跨界分类规则、AI监督机制、资金困境应对、最小维护模式 Lixx
v1.2 2026-05-10 更改部分内容 Lixx

文档结束

本制度旨在为星图项目提供清晰的管理框架,确保项目的长期健康发展。所有参与者应认真阅读并遵守本制度,共同维护星图的质量与声誉。