多受众版本管理是什么
同一份测试结果要服务三类读者：技术团队需要完整复现步骤与修复细节，管理层需要业务影响与资源决策依据，合规团队需要控制域映射与整改状态。做法是从同一份数据源生成三个版本，只改变颗粒度与表达方式，结论与数字完全一致，版本号互相对应。
基本信息
| 技术版 | 完整证据、复现步骤与修复建议 |
|---|---|
| 管理版 | 业务影响、风险分布与决策事项 |
| 合规版 | 控制域映射与整改状态 |
| 同源要求 | 数字一致，版本号对应 |
| 更新规则 | 任一版本修订，其余版本同日更新 |
典型使用场景
- 向管理层汇报：用三页摘要说明风险分布与资源需求
- 向开发团队交付：提供完整复现与修复细节
- 向合规团队提交：提供控制域映射作为审计输入
- 同一项目多个接收方，一次性准备各自的材料
- 复测更新时按版本对应关系同步修订
版本对应示例
版本对应示例
主报告 v1.1（技术版：完整证据与修复建议）
├─ 管理摘要 v1.1（3 页：风险分布、业务影响、决策事项）
└─ 合规映射附录 v1.1（控制域表与整改状态）
规则：任一版本修订，其余版本同日更新并标注对应关系
分发：按受控分发流程分别投递，收件人清单分别登记版本差异对照
| 内容项 | 技术版 | 管理版 |
|---|---|---|
| 复现步骤 | 完整请求响应 | 不包含，仅说明影响 |
| 定级依据 | 含口径与证据 | 含等级分布与趋势 |
| 修复建议 | 具体配置与参数 | 优先级与资源投入 |
| 敏感细节 | 按脱敏规则处理 | 一律不出现 |
多版本只改变颗粒度与表达方式，不改变结论与数字：管理版里的高危数量必须与技术版完全一致，否则汇报会上立刻出现对不上的尴尬。
管理版不要混入未经复核的技术结论：省略上下文后的一句话判断最容易被误读，并转化为错误的资源决策。