audience-adapter

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