RailWise 知识库文档审核流程

RailWise 知识库文档审核流程

文档说明：本文档定义 RailWise 知识库所有投稿内容的审核流程、质量标准与操作规范。适用于审核员、编辑、技术专家及投稿作者。 适用范围：技术文档团队、社区运营团队、外部审核志愿者

---

1. 审核体系概述

1.1 审核目标

目标	说明	衡量指标
内容准确性	技术内容正确、数据可验证	错误率 < 0.1%
信息安全性	不泄露敏感项目信息	安全事件 0 次
可读性	结构清晰、语言通顺	可读性评分 > 80
时效性	审核周期可控	平均审核时间 < 3 天
社区满意度	贡献者体验良好	满意度 > 4.5/5

1.2 审核类型

类型	触发条件	审核深度	典型耗时
快速审核	认证用户投稿、纠错补充	格式 + 敏感词 + 基本准确性	2-4 小时
标准审核	常规投稿、新作者首次投稿	完整技术审核 + 编辑审核	3-5 天
深度审核	重大技术文档、标准解读	专家审核 + 多方交叉验证	5-10 天
紧急审核	安全补丁文档、重大 Bug 修复	简化流程、快速通道	4-24 小时

---

2. 审核流程详解

2.1 流程总览

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  投稿提交   │ → │  自动检查   │ → │  技术审核   │ → │  编辑审核   │ → │  终审发布   │
│             │    │  (即时)     │    │  (1-2天)    │    │  (1天)      │    │  (半天)     │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
      │                  │                  │                  │                  │
      ▼                  ▼                  ▼                  ▼                  ▼
  多渠道接收        格式/敏感词/查重      技术准确性          语言/结构           最终确认
  GitHub/编辑器/邮件  自动拦截问题         专家审核            编辑润色            发布上线

2.2 阶段一：自动检查（即时）

2.2.1 检查项

检查项	工具	通过标准	失败处理
Frontmatter 完整	自定义脚本	必填字段齐全	返回补全提示
Markdown 语法	markdownlint	无语法错误	返回修复建议
敏感词检测	敏感词库	无敏感词命中	标记人工复核
重复检测	文本相似度算法	相似度 < 30%	标记人工复核
图片规范	图像分析脚本	格式/大小合规	返回压缩/转换建议
链接有效性	链接检查器	内部链接无死链	返回修复建议

2.2.2 自动检查脚本示例

# 运行自动检查
npm run lint:article -- path/to/article.md

# 输出示例
✅ Frontmatter: 通过
✅ Markdown 语法: 通过
⚠️ 敏感词: 检测到 "客户名称"，需人工确认是否脱敏
✅ 重复检测: 通过（相似度 12%）
❌ 图片规范: 图3 大小 2.1MB，超过 500KB 限制
❌ 链接检查: 死链发现：../批次2/nonexistent.md

2.3 阶段二：技术审核（1-2 天）

2.3.1 审核维度

维度	检查内容	审核工具	通过标准
技术准确性	技术概念、公式、参数是否正确	专家知识 + 标准查阅	无技术错误
数据可验证	数据是否有来源、是否标注典型值	人工判断	数据标注规范
安全性	是否泄露敏感信息	敏感信息检查清单	无敏感信息泄露
适用性	内容是否符合知识库定位	分类体系对照	分类正确
完整性	内容是否完整、步骤是否清晰	结构检查清单	结构完整

2.3.2 技术审核检查清单

## 技术审核检查清单

### 技术准确性
- [ ] 专业术语使用正确（参考术语表）
- [ ] 公式、计算过程无误
- [ ] 引用的标准编号正确且现行有效
- [ ] 产品功能描述与当前版本一致
- [ ] API 参数、返回值描述准确

### 数据规范
- [ ] 所有工程数据标注为"典型值"或"示例数据"
- [ ] 无真实项目敏感数据（坐标、设计参数、客户信息）
- [ ] 数据范围符合行业常识
- [ ] 单位使用规范（mm、m、kPa 等）

### 安全性
- [ ] 无客户名称、项目地点等敏感信息
- [ ] 无具体工程坐标、高程数据
- [ ] 无设计图纸、计算书截图
- [ ] 无合同金额、商务信息
- [ ] 代码示例无真实 API Key、密码

### 适用性
- [ ] 分类标签正确
- [ ] 适用场景描述准确
- [ ] 目标读者明确
- [ ] 难度等级合理

2.3.3 技术审核意见模板

## 技术审核意见

**审核人**：@审核人用户名
**审核日期**：YYYY-MM-DD
**审核结果**：通过 / 小修改 / 大修改 / 暂不采纳

### 审核意见

#### ✅ 优点
- 优点1
- 优点2

#### ⚠️ 需修改
1. **问题描述**：具体问题
   **建议**：修改建议
   **位置**：第 X 节 / 第 X 行

2. **问题描述**：具体问题
   **建议**：修改建议
   **位置**：第 X 节 / 第 X 行

#### ❌ 严重问题（如适用）
- 问题描述及原因

### 修改建议优先级

| 优先级 | 问题 | 建议修改方式 |
|--------|------|-------------|
| P0（必须） | 问题 | 修改方案 |
| P1（建议） | 问题 | 修改方案 |
| P2（可选） | 问题 | 修改方案 |

2.4 阶段三：编辑审核（1 天）

2.4.1 审核维度

维度	检查内容	通过标准
语言质量	错别字、语法、标点	无错别字，语法正确
结构清晰	标题层级、段落划分	层级合理，逻辑清晰
格式规范	Markdown 格式、表格、代码块	符合格式规范
可读性	句子长度、专业术语密度	可读性评分 > 80
一致性	术语统一、风格一致	与知识库风格一致

2.4.2 编辑润色权限

操作	是否需要作者确认	说明
修正错别字	否	直接修改
调整标点	否	直接修改
优化标题层级	否	直接修改
调整段落顺序	是	建议作者确认
增删内容	是	必须作者确认
修改技术表述	是	必须作者确认

2.5 阶段四：终审发布（半天）

2.5.1 终审检查项

- [ ] 技术审核和编辑审核均已通过
- [ ] 所有修改建议已处理或已沟通确认
- [ ] 作者已确认最终版本
- [ ] Frontmatter 信息完整正确
- [ ] 分类标签正确
- [ ] 相关文档链接有效
- [ ] 元数据标签完整
- [ ] 发布时机合适（无冲突发布）

2.5.2 发布操作

# 合并 PR（GitHub 投稿）
git checkout main
git merge --no-ff article/xxx

# 或发布（在线编辑器投稿）
# 点击"发布"按钮，选择发布时间

# 发布后操作
npm run build  # 重新构建站点
npm run deploy  # 部署更新

---

3. 审核角色与职责

3.1 角色矩阵

角色	职责	要求	人数
自动检查系统	格式、语法、敏感词、重复检测	7×24 运行	1 套
技术审核员	技术准确性、安全性审核	3 年以上监测/开发经验	5-8 人
编辑审核员	语言、结构、格式审核	技术写作经验	2-3 人
终审发布员	最终确认、发布操作	熟悉发布流程	1-2 人
审核协调员	进度跟踪、争议仲裁	熟悉全流程	1 人

3.2 技术审核员专业领域

领域	审核员背景要求	当前负责人
工程监测技术	注册测绘师 / 岩土工程师	@engineer-a
产品技术文档	产品经理 / 技术文档工程师	@doc-lead
开发技术	全栈开发工程师	@dev-lead
AI/算法	机器学习工程师	@ai-lead
标准规范	标准化工程师	@std-expert

3.3 审核员工作规范

提示

1. 时效性：承诺的审核时间内完成，如遇延迟提前通知
2. 建设性：反馈要具体、可操作，避免模糊评价
3. 尊重性：尊重作者劳动，先肯定优点再提建议
4. 一致性：同类问题处理标准一致，避免因人而异
5. 保密性：审核过程中接触的内容不外泄

---

4. 特殊情况处理

4.1 争议处理

场景	处理方式	决策人
技术观点分歧	引入第三位专家仲裁	领域专家
格式标准争议	参考已有文档，保持一致	编辑负责人
安全信息边界模糊	安全审核委员会裁定	安全负责人
作者不同意修改	沟通协商，必要时拒绝发布	审核协调员

4.2 紧急审核通道

触发条件：
- 安全漏洞修复文档
- 重大产品 Bug 修复说明
- 标准规范紧急更新解读
- 客户投诉相关文档

流程：
1. 投稿时标注 [紧急]
2. 通知审核协调员（企业微信/电话）
3. 协调员立即指派审核员
4. 简化流程：自动检查 → 技术审核（并行编辑审核）→ 终审
5. 目标：4-24 小时内完成

4.3 批量审核

场景	处理方式	示例
系列文档	指定同一审核员，保持风格一致	10 篇项目案例系列
翻译文档	技术审核 + 语言审核并行	15 篇英文翻译
活动投稿	统一审核标准，批量处理	技术征文活动稿件

---

5. 审核工具与系统

5.1 审核工作台

┌─────────────────────────────────────────────────────────┐
│  RailWise 审核工作台                                      │
├─────────────────────────────────────────────────────────┤
│  待审核 (12)  审核中 (5)  待修改 (3)  已通过 (156)        │
├─────────────────────────────────────────────────────────┤
│  文章标题                    作者        提交时间   优先级 │
│  ├─ 深基坑监测方案设计要点    @user1     2h前      P1    │
│  ├─ TSM API 批量采集脚本      @user2     5h前      P0    │
│  └─ ...                                                  │
├─────────────────────────────────────────────────────────┤
│  [开始审核]  [分配审核员]  [批量操作]  [导出报表]          │
└─────────────────────────────────────────────────────────┘

5.2 审核统计报表

指标	统计周期	目标值
平均审核时间	周/月	< 3 天
一次通过率	月	> 60%
作者满意度	季度	> 4.5/5
审核员工作量	周	人均 5-10 篇
紧急审核响应	次	< 4 小时

---

6. 审核质量持续改进

6.1 定期复盘

复盘类型	频率	参与人	内容
周例会	每周	审核团队	进度、问题、经验分享
月度质量	每月	审核团队 + 运营	质量指标、典型案例
季度优化	每季度	全团队	流程优化、工具改进
年度总结	每年	全团队 + 管理层	体系评估、资源规划

6.2 反馈闭环

作者反馈 → 审核团队讨论 → 标准更新 → 培训同步 → 执行验证
    ↑                                                        │
    └────────────────────────────────────────────────────────┘

---

7. 相关文档

• 如何投稿 — 投稿者指南
• 内容质量标准 — 质量评分细则
• 积分与激励体系 — 贡献奖励规则
• 优秀贡献者案例 — 优秀投稿参考

---

元数据标签

---

文档版本：v1.0.0 | 发布日期：2026-07-08 | 下次更新：2026-08-08