ReporterStationManagementSystem/req.md

# 全国记者站管理系统需求规格说明书

> 文档版本：V0.1（基于《全国记者站管理小程序初步设想修改版》整理）  
> 文档状态：需求初稿，供业务评审、原型设计和技术方案设计使用  
> 编制日期：2026-07-31

## 1. 文档说明

### 1.1 编制目的

本文档将初步设想转化为可讨论、可设计、可开发和可验收的系统需求。原文未明确的业务规则统一列入“待确认事项”，在确认前不作为最终实现依据。

### 1.2 术语

| 术语 | 定义 |
| --- | --- |
| 总部 / 总站 | 全国记者站管理工作的总部管理机构 |
| 记者站 / 分站 / 站点 | 纳入系统管理的 37 个记者站之一 |
| 总部管理员 | 负责规则、权限、复核、统计及全局监管的用户 |
| 分站负责人 | 负责本站人员管理、工作初审及考核汇总的用户 |
| 记者 | 负责工作填报、材料上传和个人信息查询的用户 |
| 工作记录 | 记者提交的一次稿件、作品、培训、临时工作等业务记录 |
| 考核 | 按规则对工作记录进行审核、计分、汇总和评价的过程 |

### 1.3 需求优先级

- P0：首期上线必需，缺失将导致核心业务闭环不可用。
- P1：重要能力，宜在首期或紧随其后的版本实现。
- P2：增强能力，可在核心流程稳定后建设。

## 2. 项目概述

### 2.1 建设背景

当前记者站管理存在数据分散、统计口径不统一、沟通链路长、档案查询不便、人工考核容易出错及决策数据不足等问题。系统面向全国 37 个记者站，将分散工作整合至统一平台。

### 2.2 建设目标

1. 实现人员、工作、考核、通知和统计的统一管理。
2. 实现日常工作线上填报、分级审核、自动统计和全程留痕。
3. 为每位记者建立长期保存、可追溯的个人电子档案。
4. 统一考核标准和统计口径，提高考核公平性与透明度。
5. 为总部掌握全国运行情况、考核评价和资源配置提供数据支持。

### 2.3 建设原则

- 统一管理：统一组织、人员、指标、数据和权限体系。
- 流程规范：核心业务按标准流程线上流转。
- 数据共享：同源数据在授权范围内复用，减少重复填报。
- 考核闭环：填报、审核、复核、计分、统计、归档全程贯通。
- 权限可控：按角色、组织和数据范围授权。
- 全程留痕：关键业务和管理操作可追溯。

### 2.4 系统边界

系统由以下部分构成：

- 小程序端：供记者和分站负责人移动填报、审核与查询。
- 后台管理系统：供总部管理员进行配置、复核、统计和系统管理。
- 服务端与数据库：承载业务逻辑、文件管理、统计计算、身份权限及日志。

首期不默认包含财务、人事薪酬、新闻采编发布、稿酬结算和外部媒体平台自动同步；如需建设，应另行确认接口及业务边界。

## 3. 用户与权限

### 3.1 角色职责

| 角色 | 主要职责 | 默认数据范围 |
| --- | --- | --- |
| 总部管理员 | 组织和制度管理、考核规则配置、总部复核、通知发布、全局统计、权限监管 | 全国全部站点及人员 |
| 分站负责人 | 本站人员维护、填报初审、本站考核汇总、通知落实 | 所属站点及本站人员 |
| 记者 | 工作填报、材料上传、通知查看、成绩和档案查询、个人资料维护 | 本人数据及授权公开信息 |

### 3.2 权限矩阵

| 功能 | 总部管理员 | 分站负责人 | 记者 |
| --- | --- | --- | --- |
| 站点管理 | 增删改查 | 查看本站 | 查看所属站 |
| 人员管理 | 全局管理 | 管理本站人员 | 查看/维护本人可编辑信息 |
| 工作填报 | 查看 | 可查看本站、按授权代填 | 新建、编辑草稿、提交本人记录 |
| 分站初审 | 查看/必要时干预 | 审核本站记录 | 查看本人审核状态 |
| 总部复核 | 复核、退回 | 查看结果 | 查看本人结果 |
| 考核规则 | 配置、发布 | 查看 | 查看适用规则 |
| 通知公告 | 全局发布与管理 | 接收、按授权转发/发布本站通知 | 接收与确认 |
| 数据统计 | 全局统计与导出 | 本站统计与导出 | 本人成绩与档案 |
| 账号与权限 | 全局管理 | 无或仅协助人员绑定 | 管理本人账号安全 |

权限应支持一人多角色、角色启停和站点数据隔离。具体授权粒度由业务评审确认。

## 4. 总体业务流程

### 4.1 日常考核主流程

1. 记者新建工作记录，填写业务字段并上传证明材料。
2. 记者保存草稿或提交；提交后记录进入“待分站审核”。
3. 分站负责人核验真实性和完整性，填写初审意见及初评分，选择通过或退回。
4. 初审通过后进入“待总部复核”；退回后记者修改并重新提交。
5. 总部管理员抽查或逐条复核，确认、调整或退回考核结果。
6. 复核通过后，系统依据生效规则计算得分并汇总统计。
7. 已确认结果自动归入记者个人档案，保留规则版本和审核轨迹。

### 4.2 建议状态机

`草稿 → 待分站审核 → 待总部复核 → 已通过/已归档`

异常分支：

- 分站退回：`待分站审核 → 已退回 → 草稿/重新提交`
- 总部退回分站：`待总部复核 → 退回分站 → 待总部复核`
- 总部退回记者：`待总部复核 → 已退回 → 草稿/重新提交`
- 撤回、作废、更正仅在权限和时限满足时允许，并记录原因及操作日志。

## 5. 功能需求

### 5.1 身份认证与账号

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| FR-AUTH-001 | P0 | 系统应支持小程序用户身份登录，并将账号绑定至系统人员档案。 |
| FR-AUTH-002 | P0 | 系统应识别用户角色、所属站点、账号状态和数据权限。 |
| FR-AUTH-003 | P0 | 后台管理系统应提供安全登录、退出和会话超时控制。 |
| FR-AUTH-004 | P0 | 未绑定、停用或离职账号不得访问受保护业务数据。 |
| FR-AUTH-005 | P1 | 系统应支持一名用户拥有多个角色，并可切换当前工作身份。 |
| FR-AUTH-006 | P1 | 系统应支持账号绑定、解绑、重置及异常登录处置。 |

### 5.2 组织与站点管理

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| FR-ORG-001 | P0 | 总部管理员应能维护总部、37 个记者站及其层级关系。 |
| FR-ORG-002 | P0 | 站点信息至少包括名称、编码、行政区域、地址、负责人、联系方式、状态和成立时间。 |
| FR-ORG-003 | P0 | 系统应支持人员调站、负责人变更和站点启停，并保存历史记录。 |
| FR-ORG-004 | P1 | 系统应展示全国地图及记者站分布，点击标记可进入站点详情。 |
| FR-ORG-005 | P1 | 总部可按地区、站点状态和人员规模检索、筛选站点。 |

### 5.3 人员管理

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| FR-USER-001 | P0 | 总部管理员可新增、编辑、查询、启停和导入人员信息。 |
| FR-USER-002 | P0 | 分站负责人仅可管理所属站点的人员信息，敏感字段受权限控制。 |
| FR-USER-003 | P0 | 人员信息至少包括姓名、人员编号、所属站点、职务、入站时间、联系方式、在职状态和账号绑定状态。 |
| FR-USER-004 | P0 | 系统应支持在职、离职、调动等状态，并保留任职及站点变更历史。 |
| FR-USER-005 | P1 | 支持按姓名、站点、职务、状态等条件组合查询和导出。 |
| FR-USER-006 | P1 | 记者可查看本人资料，并仅修改总部允许自助维护的字段。 |

### 5.4 个人电子档案

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| FR-PROFILE-001 | P0 | 系统应为每位记者建立唯一、长期保存的电子档案。 |
| FR-PROFILE-002 | P0 | 档案应聚合基本信息、文字稿件、视频作品、图片作品、培训、获奖和年度考核记录。 |
| FR-PROFILE-003 | P0 | 复核通过的工作和考核结果应自动归档，避免二次录入。 |
| FR-PROFILE-004 | P0 | 档案记录应显示来源、发生时间、审核状态、得分和证明附件。 |
| FR-PROFILE-005 | P1 | 档案应支持按年度、类型和状态筛选，并支持授权导出。 |
| FR-PROFILE-006 | P1 | 调站或离职后档案仍应保留，历史数据不得因组织变化丢失。 |
| FR-PROFILE-007 | P2 | 系统可形成个人成长轨迹和能力画像，为评优、培养与资源配置提供参考。 |

### 5.5 工作填报与材料管理

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| FR-WORK-001 | P0 | 记者可按业务类型新建工作记录，至少支持文字稿件、视频供稿、图片供稿、重要报道、培训参与、临时工作和其他。 |
| FR-WORK-002 | P0 | 系统应支持草稿保存、编辑、提交、查看详情及复制已有记录。 |
| FR-WORK-003 | P0 | 填报字段应可按工作类型配置，包括标题、发生/刊发日期、媒体/平台、链接、数量、说明及证明材料等。 |
| FR-WORK-004 | P0 | 系统应校验必填项、数据格式、附件类型/大小及重复记录风险。 |
| FR-WORK-005 | P0 | 提交后普通用户不得直接修改；被退回后可依据意见修改并重新提交。 |
| FR-WORK-006 | P0 | 支持图片、文档、视频或链接等材料上传/引用，并进行访问权限控制。 |
| FR-WORK-007 | P1 | 用户可按日期、类型、状态和关键词查询本人或权限范围内的工作记录。 |
| FR-WORK-008 | P1 | 系统应记录每次提交版本，保留修改前后内容、操作者和时间。 |

### 5.6 审核与日常考核

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| FR-ASSESS-001 | P0 | 分站负责人应在待办中接收本站待审核记录并完成初审。 |
| FR-ASSESS-002 | P0 | 初审应支持通过、退回，填写审核意见，并按规则完成初评分。 |
| FR-ASSESS-003 | P0 | 总部管理员应对初审通过记录进行复核，支持确认、调整和退回。 |
| FR-ASSESS-004 | P0 | 审核操作应记录处理人、处理时间、意见、处理前后状态和分数变化。 |
| FR-ASSESS-005 | P0 | 系统应按生效考核规则自动计算单项、月度和年度得分。 |
| FR-ASSESS-006 | P0 | 规则变更不得静默改变已归档结果；重新计算必须经授权并留痕。 |
| FR-ASSESS-007 | P0 | 记者可查看本人各项得分、审核意见、汇总成绩及适用规则。 |
| FR-ASSESS-008 | P1 | 分站负责人可查看本站考核进度、成绩汇总和异常记录。 |
| FR-ASSESS-009 | P1 | 总部可按配置采用逐条复核或抽查复核，并记录抽查策略。 |
| FR-ASSESS-010 | P1 | 系统应提供超时待办提醒和审核时效统计。 |
| FR-ASSESS-011 | P1 | 系统应支持授权更正、申诉或复议流程，原结果与更正结果均保留。 |

### 5.7 考核规则配置

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| FR-RULE-001 | P0 | 总部管理员可配置考核项目、指标、计分方式、上限/下限和适用范围。 |
| FR-RULE-002 | P0 | 规则应具有版本号、生效时间、失效时间和发布状态。 |
| FR-RULE-003 | P0 | 工作记录应绑定其计算时适用的规则版本，确保结果可追溯。 |
| FR-RULE-004 | P1 | 发布前应支持规则预览、试算和冲突检查。 |
| FR-RULE-005 | P1 | 规则发布、修改、停用应经过授权并记录审计日志。 |

### 5.8 通知公告与待办

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| FR-NOTICE-001 | P0 | 总部管理员可创建、编辑、定时发布、撤回和归档通知公告。 |
| FR-NOTICE-002 | P0 | 通知可指定全部人员、指定站点、指定角色或指定人员为接收对象。 |
| FR-NOTICE-003 | P0 | 小程序首页应展示最新通知，用户可查看详情及附件。 |
| FR-NOTICE-004 | P1 | 重要通知应支持已读/未读和确认回执统计。 |
| FR-NOTICE-005 | P0 | 系统应聚合待填报、待审核、被退回及其他待处理事项。 |
| FR-NOTICE-006 | P1 | 系统可通过小程序订阅消息等合规渠道提醒用户，具体渠道待确认。 |

### 5.9 数据统计与报表

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| FR-STAT-001 | P0 | 总部应能查看全国、地区、站点、人员、时间和工作类型等维度的统计。 |
| FR-STAT-002 | P0 | 统计指标至少包括填报数量、审核进度、通过/退回数量、考核得分和人员排名。 |
| FR-STAT-003 | P0 | 分站负责人仅可查看本站统计，记者仅可查看本人统计。 |
| FR-STAT-004 | P0 | 报表结果应与明细数据可下钻核对，并显示统计口径和数据更新时间。 |
| FR-STAT-005 | P1 | 支持按筛选条件导出标准报表，导出行为受权限控制并留痕。 |
| FR-STAT-006 | P1 | 支持形成月报、季报、年报及站点/个人对比趋势。 |
| FR-STAT-007 | P2 | 提供可视化驾驶舱，展示全国分布、核心指标、趋势和异常预警。 |

### 5.10 首页与个人中心

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| FR-HOME-001 | P0 | 首页应按角色展示常用入口，至少包括通知公告、工作填报、考核成绩、我的档案、待办事项和个人中心。 |
| FR-HOME-002 | P0 | 首页应显示待办数量和最新通知，点击可直达对应列表或详情。 |
| FR-HOME-003 | P1 | 不同角色的首页入口和数据摘要应按权限动态配置。 |
| FR-HOME-004 | P0 | 个人中心应提供个人资料、所属组织、账号设置和退出登录。 |

### 5.11 系统管理与审计

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| FR-SYS-001 | P0 | 系统应提供角色、菜单、功能和数据权限配置。 |
| FR-SYS-002 | P0 | 系统应记录登录、人员/组织变更、规则发布、审核、导出、删除和权限调整等关键操作。 |
| FR-SYS-003 | P0 | 审计日志至少包含操作者、时间、来源、对象、动作、结果及必要的变更摘要。 |
| FR-SYS-004 | P0 | 业务数据原则上采用逻辑删除；删除、作废和恢复须授权并留痕。 |
| FR-SYS-005 | P1 | 提供字典、附件策略、消息模板及业务参数配置。 |

## 6. 核心数据需求

### 6.1 核心实体

| 实体 | 关键字段（建议） |
| --- | --- |
| 站点 | 站点 ID、编码、名称、地区、地址、负责人、联系方式、状态、成立时间 |
| 用户账号 | 用户 ID、登录标识、绑定人员、角色、状态、最近登录信息 |
| 人员档案 | 人员 ID、姓名、编号、所属站点、职务、入站/离站时间、联系方式、状态 |
| 任职历史 | 人员、站点、职务、开始/结束时间、变更原因 |
| 工作记录 | 记录 ID、人员、站点、类型、标题、日期、业务字段、状态、当前版本 |
| 附件 | 文件 ID、关联对象、文件名、类型、大小、存储位置、上传人、校验值 |
| 审核记录 | 业务记录、审核层级、处理人、结果、意见、分数、时间 |
| 考核规则 | 规则 ID、版本、指标、计分公式、适用范围、生效区间、状态 |
| 考核结果 | 人员、周期、指标、原始值、得分、规则版本、确认状态 |
| 通知公告 | 标题、正文、附件、发布范围、发布时间、状态、发布人 |
| 阅读回执 | 通知、用户、已读时间、确认时间 |
| 操作日志 | 操作者、动作、对象、时间、来源、结果、变更摘要 |

### 6.2 数据规则

1. 每个站点、人员、工作记录和规则版本均应有全局唯一标识。
2. 工作记录同时保存填报时所属站点，避免人员调动影响历史统计。
3. 已归档考核结果保存规则版本、计算输入和审核链路，支持还原计算过程。
4. 附件与业务记录的访问权限保持一致，不得通过直链绕过鉴权。
5. 统计数据应可追溯至业务明细；离线汇总应明确刷新时间。
6. 手机号等个人信息应按最小必要原则采集和展示，并进行脱敏。

## 7. 非功能需求

### 7.1 安全与隐私

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| NFR-SEC-001 | P0 | 所有受保护接口必须完成身份认证和服务端权限校验。 |
| NFR-SEC-002 | P0 | 数据按总部、站点和个人范围隔离，禁止仅依赖前端隐藏实现权限。 |
| NFR-SEC-003 | P0 | 传输过程使用 HTTPS；密码、令牌及敏感配置不得明文存储。 |
| NFR-SEC-004 | P0 | 个人信息采集、使用、导出、留存和删除应符合适用的数据与个人信息保护要求。 |
| NFR-SEC-005 | P0 | 文件上传应校验类型、大小及安全风险，下载应鉴权。 |
| NFR-SEC-006 | P1 | 高风险操作宜支持二次确认或增强认证，并具备异常访问告警能力。 |

### 7.2 性能与容量

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| NFR-PERF-001 | P0 | 常规列表、详情和提交操作在正常网络及设计并发下，服务端 95 分位响应时间宜不超过 2 秒（文件上传和复杂报表除外）。 |
| NFR-PERF-002 | P0 | 月度/年度统计可采用异步计算；用户应能看到计算状态和数据更新时间。 |
| NFR-PERF-003 | P0 | 容量设计应覆盖 37 个站点的人员、业务记录、审计日志及多年附件增长，具体基线在调研阶段确定。 |

### 7.3 可靠性与运维

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| NFR-OPS-001 | P0 | 核心数据应实施定期备份，并通过恢复演练验证可用性。 |
| NFR-OPS-002 | P0 | 系统应具备应用、接口、数据库、任务和存储监控及故障告警。 |
| NFR-OPS-003 | P0 | 提交、审核和计分等关键操作应具备幂等或防重复机制。 |
| NFR-OPS-004 | P1 | 系统应明确可用性、RPO 和 RTO 指标，具体数值由业务与技术评审确定。 |

### 7.4 易用性与兼容性

| 编号 | 优先级 | 需求 |
| --- | --- | --- |
| NFR-UX-001 | P0 | 高频任务应尽量在少量层级内完成，表单需提供清晰校验和错误定位。 |
| NFR-UX-002 | P0 | 小程序应兼容项目确定的主流微信版本、iOS 和 Android 系统版本。 |
| NFR-UX-003 | P1 | 列表应提供搜索、筛选、分页/加载更多及空状态反馈。 |
| NFR-UX-004 | P1 | 用户提交中断时应尽量保存草稿，避免重复录入。 |

## 8. 首期范围建议（MVP）

### 8.1 纳入首期

1. 账号登录、人员绑定及三级角色权限。
2. 37 个站点和人员基础信息管理。
3. 工作分类填报、附件上传和记录查询。
4. 分站初审、总部复核、退回修改和流程留痕。
5. 基础考核规则、自动计分、月度/年度汇总。
6. 个人电子档案自动归集与查询。
7. 通知公告、待办事项和基础消息提醒。
8. 全国/站点/个人基础统计和报表导出。
9. 后台权限、参数和审计日志。

### 8.2 后续增强

- 全国地图和管理驾驶舱。
- 规则试算、抽查策略、申诉复议和复杂排名。
- 个人能力画像、人才培养和智能分析。
- 与统一身份、媒体采编、组织人事或其他外部系统集成。

## 9. 验收场景

### AC-01 记者完成工作填报

- 已绑定且在职的记者可以新建规定类型的工作记录。
- 必填项或附件不符合要求时，系统明确提示且不允许提交。
- 提交成功后状态为“待分站审核”，记者不可直接篡改已提交内容。
- 分站负责人待办数量同步增加。

### AC-02 分站初审并退回

- 分站负责人只能审核本站记录。
- 退回时必须填写原因，记者能在待办和记录详情中查看。
- 记者修改并重新提交后，历史版本和原审核意见仍可追溯。

### AC-03 总部复核并归档

- 分站通过的记录进入总部复核队列。
- 总部确认后，系统按绑定规则版本计算得分。
- 记录进入已通过/已归档状态，并自动出现在个人档案及统计中。
- 审核人、时间、意见和分数变化完整记录。

### AC-04 数据权限隔离

- 记者无法访问他人的非公开档案和成绩。
- 分站负责人无法访问其他站点的受限数据。
- 总部管理员按授权查看全国数据。
- 通过修改前端参数或直接访问接口不能绕过上述限制。

### AC-05 统计可核对

- 总部可按年度、站点、人员和工作类型筛选统计。
- 汇总值可下钻至构成该数值的已授权明细。
- 导出结果与当前筛选条件、统计口径一致，并记录导出日志。

### AC-06 历史数据可追溯

- 人员调站后，历史记录仍归属于发生时站点，同时个人档案连续保留。
- 规则升级后，既有已归档结果不被自动改写。
- 被授权的管理员可查询关键记录的版本、审核和操作轨迹。

## 10. 实施阶段建议

1. 需求调研：梳理现行表单、考核制度、审批权限、统计报表及历史数据。
2. 方案设计：完成功能原型、流程、数据模型、权限矩阵和接口设计。
3. 开发测试：分模块开发，开展功能、权限、安全、性能和兼容性测试。
4. 试点运行：选取代表性记者站试点，验证填报负担、审核效率和统计准确性。
5. 全面推广：修正试点问题，开展培训和数据初始化，分批覆盖全国记者站。

## 11. 待确认事项及建议方案

以下建议可作为首期需求基线。标记为“立项前”的事项会影响总体架构、预算或合规，应在项目立项和技术选型前确认；标记为“设计前”的事项应在原型及数据库设计前确认；标记为“上线前”的事项可在开发期间细化，但必须在试点上线前定稿。

### 11.1 组织与站点数据

**待确认：**“37 个记者站”的正式名单、组织层级、编码和地图坐标数据来源。  
**建议方案：**由总部提供并盖章/审批确认一份站点主数据表，采用总部统一编码且编码永久不复用。行政区划采用国家标准代码；地址由站点维护，总部审核。地图坐标在地址确认后通过合规地图服务获取，并允许人工校正。首期组织层级固定为“总部—记者站—人员”，预留上级站点字段但不启用更多层级。  
**理由：**组织主数据是权限隔离、统计和历史归属的基础，不能依赖开发人员自行整理。  
**决策时点：**设计前。

### 11.2 总部复核方式

**待确认：**总部采取全部逐条复核、按比例抽查，还是分类复核。  
**建议方案：**首期采用“分类复核”：高价值、高分值、获奖、重要报道、被退回后重提及系统命中异常规则的记录必须逐条复核；普通记录按站点和月份随机抽查，建议初始比例为 20%，总部可配置。抽查未通过时，可提高该站点当期抽查比例至 100%。  
**理由：**兼顾总部工作量与考核公信力，并能通过风险触发机制约束数据质量。  
**决策时点：**设计前；抽查比例可在试点后调整。

### 11.3 工作记录字段与材料

**待确认：**各工作类型的字段、必填项、证明材料、重复判定及附件限制。  
**建议方案：**先收集现行纸质/Excel 表单，形成“工作类型—字段—数据类型—必填—证明材料—计分指标”配置表并由业务负责人签字确认。通用字段包括标题、发生/刊发日期、媒体平台、作品链接、工作说明和证明材料。重复记录以“记者 + 类型 + 标题/链接 + 日期”组合预警，允许审核人确认非重复，不建议系统直接删除。单文件默认不超过 20 MB；视频首期优先提交合规链接或媒体资源编号。  
**理由：**字段直接决定表单、数据模型和计分逻辑；重复只能预警，避免误伤同题连续报道。  
**决策时点：**设计前。

### 11.4 考核规则

**待确认：**考核指标、公式、上限、周期、排名规则及规则变更审批。  
**建议方案：**由总部形成正式《考核指标字典》，每项明确指标编码、数据来源、计分公式、单项/周期上限、适用对象和例外条件。规则采用版本化管理，按自然月统计、年度汇总；新版本仅影响生效日后的记录。规则发布实行“业务部门拟定—管理负责人复核—授权管理员发布”，上线前必须用历史样本试算。  
**理由：**考核是系统核心，必须做到可解释、可重算、可追溯，不能把口头规则直接编码。  
**决策时点：**立项后立即启动，开发计分模块前定稿。

### 11.5 业务分类与统计口径

**待确认：**“报送”“采用”的定义，以及纸媒、新媒体、视频、图片的分类口径。  
**建议方案：**建立统一数据字典：“报送”指已向指定媒体/平台提交且有凭证；“采用”指已正式刊发/播出且可提供链接、版面、截图或平台记录。一次记录可有一个作品类型和多个发布渠道，但同一发布成果不得跨类型重复计分。纸媒、新媒体、视频、图片按主要成品形态分类，混合作品由业务规则指定主类型。  
**理由：**先统一口径才能保证跨站点统计和排名公平。  
**决策时点：**设计前。

### 11.6 代填、撤回与更正

**待确认：**分站负责人能否代记者填报、撤回或更正。  
**建议方案：**原则上由记者本人填报。仅在账号故障、离岗或经批准的特殊情况下允许分站负责人代填，必须选择原因并标注“代填”。记者可在分站尚未处理前撤回；进入审核后只能由当前审核人退回。归档后不得直接修改，应发起更正申请，经分站和总部确认后生成新版本。  
**理由：**既应对实际工作场景，又避免负责人代填导致责任不清或考核数据被静默修改。  
**决策时点：**设计前。

### 11.7 申诉与复议

**待确认：**记者是否可对考核结果申诉以及办理时限。  
**建议方案：**提供一次线上申诉机会。记者在结果发布后 5 个工作日内提交理由和材料，分站在 3 个工作日内提出意见，总部在 5 个工作日内作出最终决定。逾期关闭；特殊情况由总部管理员授权重开。申诉前后结果、处理意见和分数变化全部留痕。  
**理由：**申诉机制是考核公平和纠错能力的重要保障。  
**决策时点：**设计前。

### 11.8 通知发布与回执

**待确认：**分站能否发布通知，重要通知是否必须回执。  
**建议方案：**总部可向全局或指定范围发布；分站负责人只能向本站人员发布，且不能使用总部名义。通知分为普通、重要、紧急三级：普通通知仅记录已读，重要和紧急通知要求确认回执；紧急通知对未确认人员进行提醒，并向发布者展示名单。  
**理由：**分级发布可减少总部负担，回执仅用于重要事项可避免用户疲劳。  
**决策时点：**设计前。

### 11.9 身份认证

**待确认：**采用微信身份、手机号、统一身份平台或组合方式。  
**建议方案：**若单位已有统一身份平台，后台优先对接统一身份认证，小程序采用微信登录后与统一身份/人员编号绑定；若暂无统一身份平台，首期采用“微信身份 + 预置人员手机号/人员编号核验 + 管理员审核绑定”。不得仅凭微信昵称或手机号自动获得业务权限。后台管理员应使用增强认证，至少包括密码复杂度、登录失败锁定和二次验证。  
**理由：**微信只能证明平台账号身份，不能单独证明其对应的组织人员及岗位权限。  
**决策时点：**立项前。

### 11.10 小程序与后台用户边界

**待确认：**分站负责人是否使用后台管理系统。  
**建议方案：**记者只使用小程序；分站负责人以小程序完成日常审核和待办，并开放精简后台用于批量人员维护、集中审核、统计导出；总部管理员主要使用后台，必要时通过小程序处理待办。两个端共用同一权限和业务接口，不重复建设规则。  
**理由：**移动端适合即时处理，批量管理和复杂统计更适合电脑端。  
**决策时点：**原型设计前。

### 11.11 历史数据迁移

**待确认：**历史人员、档案、稿件和考核数据的规模、质量及迁移方式。  
**建议方案：**先开展数据盘点和抽样，分两批迁移：首批迁移在职人员、组织关系及最近 2 个完整年度的结构化考核数据；更早或质量较差的数据以只读附件/历史档案方式保存。提供标准导入模板，执行清洗、预校验、试迁移、业务核对和正式迁移，并保留迁移批次与错误报告。  
**理由：**全量清洗成本通常不可控，优先迁移高频使用数据更利于按期上线。  
**决策时点：**立项前完成盘点，试点前完成迁移方案。

### 11.12 报表、排名与公开范围

**待确认：**报表模板、统计口径、导出格式及排名公开范围。  
**建议方案：**首期以现行总部月报、年报为准，统一提供 Excel 导出，必要时增加 PDF 定版报表。报表必须显示周期、筛选条件、口径版本和生成时间。记者默认只看本人分数和分项明细，不公开完整个人排名；分站负责人看本站人员，总部看全局。若开展评优，可单独发布经审核的结果名单。  
**理由：**限制排名公开可降低不必要的个人信息暴露和内部争议，同时保留管理分析能力。  
**决策时点：**设计前。

### 11.13 大文件与视频存储

**待确认：**视频采用系统存储、外部链接还是媒体资源平台，以及保存期限。  
**建议方案：**首期不在业务数据库中存储视频文件。优先保存单位媒体资源平台编号或合规、稳定的访问链接，并上传封面/截图作为证明；确需上传时使用独立对象存储、受控临时访问地址和病毒/格式检测。视频原文件保存期限建议为 2 年，元数据、审核记录和归档证明长期保存，最终期限按档案制度调整。  
**理由：**视频会显著增加存储、带宽、备份和合规成本，应与结构化业务数据分离。  
**决策时点：**立项前。

### 11.14 留存、备份和可用性

**待确认：**数据保存年限、离职人员处置、备份周期、RPO/RTO 和可用性目标。  
**建议方案：**个人档案、考核结果和审计轨迹原则上长期保存；普通运行日志保存不少于 1 年，具体依档案和安全制度确认。离职账号立即停用，档案转为只读，不删除历史业务。数据库每日增量、每周全量备份，并进行异地/跨故障域保存及季度恢复演练。首期建议可用性目标不低于 99.5%，RPO 不超过 24 小时，RTO 不超过 8 小时；正式生产目标由预算和部署架构复核。  
**理由：**先设可执行的基线，再根据业务连续性和成本提高指标。  
**决策时点：**立项前。

### 11.15 外部系统集成

**待确认：**是否对接采编、人事、统一身份、短信/消息、电子签章等系统。  
**建议方案：**首期只纳入两类必要集成：身份认证（如已有统一身份平台）和小程序合规消息通知。人事数据先通过标准模板导入；采编平台在确认稿件唯一标识和开放接口后再对接；电子签章仅在存在正式签批法律效力需求时建设。所有集成采用独立接口层，避免核心业务绑定单一外部厂商。  
**理由：**控制首期依赖和工期风险，同时为后续集成保留边界。  
**决策时点：**立项前确认首期清单。

### 11.16 隐私、安全与部署合规

**待确认：**个人信息保护责任、部署位置、等保及其他安全合规要求。  
**建议方案：**立项阶段指定数据负责人和系统安全负责人，形成个人信息清单、处理目的、授权范围、保存期限和权限矩阵。系统及数据优先部署在单位批准的境内基础设施，生产、测试环境隔离，测试环境使用脱敏数据。正式定级应由主管部门和安全合规人员确认；考虑系统包含全国人员档案、考核及管理数据，建议至少按网络安全等级保护第二级要求进行设计和评估，若主管单位认定更高等级则按其要求执行。上线前完成安全测试、权限核验、日志审计和个人信息保护检查。  
**理由：**安全等级和部署位置会影响架构、采购、成本与验收，必须前置决策。  
**决策时点：**立项前。

### 11.17 建议决策顺序

1. 立项前确认：身份认证、历史数据规模、大文件方案、可用性/备份、首期外部集成、安全与部署合规。
2. 设计前确认：组织主数据、复核模式、表单字段、考核规则、统计口径、操作权限、申诉、通知及报表公开范围。
3. 试点期间校准：抽查比例、办理时限、附件大小、提醒频率和性能容量基线。
4. 试点验收后固化：形成正式业务制度、数据字典、权限矩阵、考核规则和运维指标，作为全面推广依据。

## 12. 需求追踪说明

本文档中的需求编号应在后续原型、设计、开发任务、测试用例和验收记录中持续引用。经业务评审确认后的新增、修改或删除需求，应记录版本、变更原因、提出人、批准人和影响范围。