---

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 熟悉

结构模板：

# [主题] — 一句话结论

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

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

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

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

---

VP / 部门负责人

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

粒度调整：

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

语言风格：

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

结构模板：

# [主题] 进展同步

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

## 里程碑进展

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

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

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

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

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

---

技术负责人 / 架构师

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

粒度调整：

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

语言风格：

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

结构模板：

# [主题] 技术同步

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

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

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

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

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

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

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

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

---

运营 / 业务团队

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

粒度调整：

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

语言风格：

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

结构模板：

# [主题] 业务同步

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

## 具体变化

### 对用户的影响
- 变化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 句话内出现
• 需要对方采取的行动是否明确
• 数据/时间/人名等事实信息是否准确（与原始素材一致）
• 语言风格是否适配受众（无不当术语）
• 同一事件的多版本之间事实是否一致