受众定义写法
受众定义要写清三件事：读者身份、已有知识、使用场景。模型据此决定术语解释到什么程度、步骤写到多细、举什么例子。同一份迁移方案，写给运维写的是命令与回滚步骤，写给产品写的是影响范围与时间点——差异不在措辞风格，而在保留的信息不同。只写「面向大众」几乎不提供信息，等于把决定权交回给模型。
三要素
| 身份 | 谁在读：值班运维、业务方、新同事、外部客户 |
|---|---|
| 已知知识 | 会什么、不会什么，决定术语解释密度与步骤颗粒度 |
| 使用场景 | 读完要做什么：照做、决策、转述给别人、存档备查 |
| 影响 | 术语解释密度、步骤颗粒度、示例选型 |
| 反例 | 「面向大众」这类表述几乎不提供信息 |
典型使用场景
- 运维文档：写给值班人员，要求步骤可直接照做、含回滚方式
- 对外通报：写给非技术读者，去掉内部系统名与实现细节
- 新人培训材料：假设零背景，术语首现处给解释
- 管理层汇报：保留影响、成本、时间点，删掉操作细节
- 多读者场景拆分：同一材料分别生成两份，而不是折中成一份
受众声明片段
受众声明片段
读者画像：
- 身份：入职 3 个月内的运维值班人员
- 已有知识：会基本 Linux 命令，不熟悉容器网络 # 决定解释深度
- 使用场景：值班时按步骤排查，无法联网搜索，需要能直接照做
# 场景写清后，「可直接照做」就替代了「写得详细一点」这类模糊要求不同受众的保留差异
| 受众 | 保留 | 可省略 |
|---|---|---|
| 值班运维 | 命令、判据、回滚步骤 | 背景与原理推导 |
| 业务方 | 影响范围、时间点、需要谁配合 | 内部实现与命令细节 |
| 新同事 | 术语解释、上下文、常见坑 | 历史沿革与内部缩写 |
| 管理层 | 结论、成本、风险 | 操作步骤与排障细节 |
受众知识与使用场景要一起写：只说身份（运维）不说不熟悉容器网络，模型仍会默认读者具备该领域常识。