执行摘要写给谁
执行摘要写给管理层与业务负责人：一段总体结论、一组关键发现（通常不超过五条）、修复优先级与建议时间窗，必要时加上与上期的对比。篇幅控制在一到两页，不堆砌技术术语，所有数字必须与正文统计逐一对齐——摘要与正文数字不一致会直接削弱整份报告的可信度。
基本信息
| 读者 | 管理层与业务负责人，非技术背景为主 |
|---|---|
| 内容 | 总体结论 + 关键发现 + 优先级与时间窗 |
| 篇幅 | 1-2 页，不含附录 |
| 纪律 | 数字与等级与正文逐一对齐 |
典型使用场景
- 评估报告开篇的决策摘要
- 向管理层单独汇报时的摘要页
- 与上期报告对比展示整改效果
- 为整改排期提供依据的优先级建议
- 验收评审中快速判断风险是否收敛
摘要骨架
摘要骨架
一段总体结论：本次评估覆盖 X 个系统，共发现 Y 个问题，整体风险等级为……
关键发现（不超过 5 条，用业务语言描述影响，例如“可获取其他用户订单信息”）
修复优先级与建议时间窗：高危 7 天内、中危 30 天内、低危随版本迭代
与上期对比（如有）：新增 / 已修复 / 遗留，并说明整体趋势
局限说明：本次未覆盖的资产或场景，避免读者误解为“已全部安全”内容与写作要求
| 内容块 | 要点 | 常见缺陷 |
|---|---|---|
| 总体结论 | 覆盖范围、问题数量、整体等级 | 只写等级不写依据 |
| 关键发现 | 业务语言、最多 5 条 | 罗列全部技术细节 |
| 优先级建议 | 按等级给出修复时限 | 只说“尽快修复” |
| 上期对比 | 新增与已修复数量 | 无对比数据时强行编造 |
| 局限说明 | 未覆盖范围与限制条件 | 完全不提测试限制 |
摘要要避免未复核的表述：一句夸大结论会让客户对整份报告的判断产生怀疑，宁可写得保守并附上依据。
关键发现建议控制在五条以内：条目过多会让管理层失去焦点，其余问题在正文清单里按等级呈现即可。