Audience Adapter

---
name: audience-adapter
description: "向上汇报与跨部门沟通助手，根据受众角色（CEO、VP、技术负责人或运营）自动调整信息粒度、语言风格和侧重点，生成邮件、汇报要点或文档。当用户提到向上汇报、跨部门沟通、stakeholder update、executive summary、管理层汇报、给老板/VP/CEO写邮件简报、技术团队同步、运营侧对齐、写汇报材料或项目进展同步时触发。"
license: MIT
---

# stakeholder-comms

根据受众角色自动调整沟通内容的粒度、语言和侧重点。支持 CEO、VP、技术负责人、运营四类典型受众，覆盖向上汇报和跨部门沟通场景。

## 使用流程

### 第一步：收集原始信息

向用户询问以下内容：

- **沟通主题**：要汇报/同步什么事（项目进展、问题升级、方案决策、成果汇报等）
- **原始素材**：用户掌握的所有细节（可以是散乱笔记、技术文档、数据报告、聊天记录等任何形式）
- **目标受众**：这份内容要给谁看（CEO / VP / 技术负责人 / 运营 / 其他角色——若受众不在上述四类中，让用户说明该角色的职能和关注点，然后参考最接近的受众策略进行适配调整）
- **沟通目的**：信息同步、争取资源、请求决策、风险预警、成果展示
- **输出形式**：邮件、会议口头汇报要点、Slack/飞书消息、PPT 大纲、正式文档

如果用户已在初始请求中明确部分信息，可跳过对应的确认。

### 第二步：确定受众画像与调整策略

根据目标受众，自动应用以下调整策略：

---

## 受众调整策略

### CEO / 创始人

**关注点**：战略影响、商业价值、关键决策点、风险与机会

**粒度调整**：
- 最高层抽象，只保留结论和决策项
- 整个汇报控制在 1 页或 3 分钟口头时间内
- 删除所有技术实现细节和过程描述
- 数据只保留最关键的 1-3 个指标

**语言风格**：
- 用商业语言而非技术术语
- "我们完成了微服务架构迁移" → "系统稳定性提升 40%，支撑下季度 3 倍流量增长"
- "数据库查询优化" → "用户体验提升，页面加载快了 2 秒"
- 避免缩写和行业黑话，除非确认 CEO 熟悉

**结构模板**：

```markdown
# [主题] — 一句话结论

## 核心结论
用 1-2 句话总结最重要的信息和建议的行动。

## 关键数据
- 指标1：数值 + 变化趋势（↑/↓ X%）
- 指标2：数值 + 与目标的差距

## 需要您的决策/了解（按需）
- 决策项1：选项 A vs 选项 B，推荐 X，原因一句话
- 决策项2：...

## 风险提示（如有）
- 风险描述 → 影响范围 → 应对方案
```

---

### VP / 部门负责人

**关注点**：部门目标达成、资源分配、跨团队依赖、里程碑进度、团队健康度

**粒度调整**：
- 中高层抽象，保留关键过程节点和决策背景
- 可展开到具体项目或工作流级别，但不到代码/操作级别
- 数据包含趋势和对比（环比、与目标对比）
- 资源和人力相关信息要具体

**语言风格**：
- 可使用部门内通用的专业术语
- 强调目标对齐和资源效率
- "API 重构完成了 70%" → "核心接口改造完成 70%，剩余部分需后端增加 1 人周，预计下周四交付"
- 问题描述要附带影响评估和资源需求

**结构模板**：

```markdown
# [主题] 进展同步

## 整体状态
一段话概括当前状态、是否按计划推进、主要成果。

## 里程碑进展

| 里程碑 | 状态 | 进度 | 预计完成 | 备注 |
|---|---|---|---|---|
| 里程碑1 | 进行中 | 70% | MM-DD | 按计划 |
| 里程碑2 | 延期 | 40% | MM-DD | 原因简述 |

## 关键成果
- 成果1：量化描述 + 业务影响
- 成果2：...

## 问题与需要的支持
- **问题1**：描述 → 对目标的影响 → 需要的资源/决策
- **问题2**：...

## 跨团队依赖
- 依赖方 → 事项 → 当前状态 → 期望时间

## 下阶段计划
按优先级列出 3-5 项重点工作及预期产出。
```

---

### 技术负责人 / 架构师

**关注点**：技术方案、架构影响、性能指标、技术债务、实现风险

**粒度调整**：
- 中低层抽象，可以包含技术方案对比和架构决策
- 需要给出具体的技术指标（QPS、延迟、错误率等）
- 可以讨论实现路径，但不需要逐行代码级别
- 技术风险要有具体的评估和缓解方案

**语言风格**：
- 可以自由使用技术术语和缩写
- 直接给结论和推荐方案，用数据支撑
- "建议用 Redis 做缓存" → "建议引入 Redis 缓存热点查询，预计 P99 延迟从 800ms 降到 200ms，需要 2 天开发 + 1 天压测"
- 方案对比要有明确的 trade-off 分析

**结构模板**：

```markdown
# [主题] 技术同步

## 概要
一句话说明技术变更的目的和当前状态。

## 技术方案 / 变更内容
描述做了什么、为什么这么做。如果涉及方案选型，给出选项对比：

| 维度 | 方案 A | 方案 B |
|---|---|---|
| 性能 | ... | ... |
| 复杂度 | ... | ... |
| 风险 | ... | ... |

推荐方案：X，理由：...

## 关键指标
- 指标1（如 QPS）：变更前 → 变更后
- 指标2（如 P99 延迟）：变更前 → 变更后

## 影响范围
- 受影响的服务/模块
- 是否需要数据迁移
- 是否有 breaking change

## 风险与缓解
- 风险1 → 缓解措施
- 风险2 → 缓解措施

## 排期与依赖
- 预计工时：X 人天
- 前置依赖：...
- 计划上线时间：MM-DD
```

---

### 运营 / 业务团队

**关注点**：用户影响、功能变化、上线时间、操作流程变更、数据口径变化

**粒度调整**：
- 中层抽象，聚焦用户可感知的变化和业务流程影响
- 删除所有技术实现细节
- 时间线要精确到天
- 如有操作流程变更，需要给出前后对比

**语言风格**：
- 用业务语言描述技术变更
- "接口迁移" → "XX 功能的数据来源切换，用户侧无感，但后台报表可能有 1 小时数据延迟"
- "发布回滚" → "XX 功能临时下线，预计 2 小时内恢复"
- 避免技术术语，如必须使用需加括号解释

**结构模板**：

```markdown
# [主题] 业务同步

## 一句话概要
用业务语言说明发生了什么、对用户/业务的影响。

## 具体变化

### 对用户的影响
- 变化1：用户会看到/感受到什么
- 变化2：...
- 无影响的部分（如需说明）

### 对业务流程的影响
- 流程变更1：之前怎么做 → 现在怎么做
- 流程变更2：...

### 对数据/报表的影响
- 数据口径变化说明（如有）
- 报表更新时间变化（如有）

## 时间线
| 时间 | 事项 |
|---|---|
| MM-DD HH:mm | 开始 XX |
| MM-DD HH:mm | 完成 XX / 用户可用 |

## 需要运营侧配合的事项（如有）
- 配合事项1：具体动作 + 截止时间
- 配合事项2：...

## 常见问题 FAQ（如有）
- Q：用户问 XX 怎么回复？
- A：...
```

---

## 第三步：内容转换与生成

拿到用户提供的原始素材后，按以下规则进行转换：

### 通用转换规则

1. **价值翻译**：将技术动作翻译为对应受众关心的价值维度
   - CEO：商业价值、收入、增长、风险
   - VP：目标达成、资源效率、团队产出
   - 技术：性能、稳定性、可维护性、技术先进性
   - 运营：用户体验、操作流程、数据准确性

2. **信息删减原则**：
   - 如果一条信息对该受众不会影响其决策或行动，删掉
   - 宁可少说、说准，不要信息过载
   - 被删掉的细节可以放在"附录"或"详情可联系 XX"

3. **数据呈现**：
   - CEO：只要结论数字 + 趋势方向
   - VP：要趋势 + 同比/环比 + 目标对比
   - 技术：要具体指标 + 监控截图链接（如有）
   - 运营：要用户可感知的变化 + 时间点

4. **行动导向**：每份沟通内容结尾要明确：
   - 需要对方做什么（决策、审批、配合、知悉）
   - 什么时候之前需要反馈
   - 如果不需要对方做任何事，明确说"仅供知悉，无需回复"

### 跨部门沟通附加规则

当沟通对象来自不同部门时，额外注意：

1. **背景补充**：不要假设对方了解你的项目背景，用 1-2 句话交代上下文
2. **术语翻译**：你部门的专业术语，对方可能不理解，需要翻译或解释
3. **利益对齐**：说明这件事为什么跟对方有关，对方能获得什么
4. **降低配合成本**：需要对方做的事情要尽可能具体、简单，最好能直接执行

## 第四步：输出与迭代

- 按用户选择的输出形式生成内容
- 输出后询问用户是否需要调整语气、补充信息或转换为其他受众版本
- 如果同一内容需要发送给多个不同受众，可以一次生成多个版本

## 多版本生成

用户可以要求对同一信息生成多个受众版本。此时：

1. 先生成信息最完整的版本（通常是技术版本）
2. 然后逐步抽象，生成其他版本
3. 确保各版本的核心事实一致，只是粒度和语言不同
4. 标注各版本之间被删减或简化的关键信息点

## 质量检查清单

每次生成内容后，自检以下项目：

- [ ] 信息粒度是否匹配受众认知层级
- [ ] 是否有对该受众无意义的技术/业务细节残留
- [ ] 核心结论是否在前 2 句话内出现
- [ ] 需要对方采取的行动是否明确
- [ ] 数据/时间/人名等事实信息是否准确（与原始素材一致）
- [ ] 语言风格是否适配受众（无不当术语）
- [ ] 同一事件的多版本之间事实是否一致