haomingz 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：...
第三步：内容转换与生成
拿到用户提供的原始素材后，按以下规则进行转换：
通用转换规则
价值翻译：将技术动作翻译为对应受众关心的价值维度
- CEO：商业价值、收入、增长、风险
- VP：目标达成、资源效率、团队产出
- 技术：性能、稳定性、可维护性、技术先进性
- 运营：用户体验、操作流程、数据准确性
信息删减原则：
- 如果一条信息对该受众不会影响其决策或行动，删掉
- 宁可少说、说准，不要信息过载
- 被删掉的细节可以放在"附录"或"详情可联系 XX"
数据呈现：
- CEO：只要结论数字 + 趋势方向
- VP：要趋势 + 同比/环比 + 目标对比
- 技术：要具体指标 + 监控截图链接（如有）
- 运营：要用户可感知的变化 + 时间点
行动导向：每份沟通内容结尾要明确：
- 需要对方做什么（决策、审批、配合、知悉）
- 什么时候之前需要反馈
- 如果不需要对方做任何事，明确说"仅供知悉，无需回复"
跨部门沟通附加规则
当沟通对象来自不同部门时，额外注意：
- 背景补充：不要假设对方了解你的项目背景，用 1-2 句话交代上下文
- 术语翻译：你部门的专业术语，对方可能不理解，需要翻译或解释
- 利益对齐：说明这件事为什么跟对方有关，对方能获得什么
- 降低配合成本：需要对方做的事情要尽可能具体、简单，最好能直接执行
第四步：输出与迭代
- 按用户选择的输出形式生成内容
- 输出后询问用户是否需要调整语气、补充信息或转换为其他受众版本
- 如果同一内容需要发送给多个不同受众，可以一次生成多个版本
多版本生成
用户可以要求对同一信息生成多个受众版本。此时：
- 先生成信息最完整的版本（通常是技术版本）
- 然后逐步抽象，生成其他版本
- 确保各版本的核心事实一致，只是粒度和语言不同
- 标注各版本之间被删减或简化的关键信息点
质量检查清单
每次生成内容后，自检以下项目：
- 信息粒度是否匹配受众认知层级
- 是否有对该受众无意义的技术/业务细节残留
- 核心结论是否在前 2 句话内出现
- 需要对方采取的行动是否明确
- 数据/时间/人名等事实信息是否准确（与原始素材一致）
- 语言风格是否适配受众（无不当术语）
- 同一事件的多版本之间事实是否一致