写邮件/团队消息/会议沟通时，如何让技术信息被正确接收和理解

适用于撰写面向同事、经理、干系人的邮件、即时消息、会议议程与状态更新，提升专业书面沟通的清晰度。

适用场景

解决思路

1. 用 What-Why-How 结构组织任何专业消息：What 清晰陈述主题/请求，Why 解释原因，How 列出下一步/行动项；适用于邮件、状态更新、会议要点、技术解释。
2. 遵循三条黄金法则：开头给出清晰的主题/目的；使用项目符号、标题和可扫读的排版；把关键信息放在最前面。
3. 发送前做受众校准，先问自己三个问题：写给谁（技术同事、经理、干系人、客户）？他们需要多深的细节（高层概览还是实现细节）？对他们有什么价值（如何影响他们的工作/决策）？
4. 写邮件主题行时用具体目的替换模糊标题，例如把 'Project updates' 改为 'Project X: Status Update and Next Steps'，把 'Question' 改为 'Quick question: API rate limiting approach'，把 'FYI' 改为 'FYI: Deployment scheduled for Tuesday 3pm'。
5. 按邮件结构模板写：主题为 [Project/Topic]: [Specific Purpose]；称呼后先用 1-2 句说明关键点或请求；再写 Context/Background 项目符号；再写 What I need from you（具体行动或决策、时间线）；可选写下一步或跟进计划；最后署名。
6. 按邮件类型套用关键要素：状态更新包含进度摘要、阻塞项、下一步、时间线；请求包含明确诉求、背景、截止日期、重要性；升级包含问题摘要、影响、已尝试方案、需要的决策；FYI/公告包含变化内容、受影响对象、需要采取的行动。
7. 区分聊天与邮件的使用场景：快速问答、实时协调、非正式团队讨论、时效性更新用聊天；需要留档的详细文档、给干系人的正式沟通、需要仔细审阅的消息、多部分复杂解释用邮件。
8. 团队消息遵循最佳实践：用 threads 保持主频道可扫读，后续回复放进 thread；谨慎 @mention，不要无谓打扰他人；把话题发到正确的频道；直接表达诉求，用 'Can you review my PR?' 而不是 'Hey, are you busy?'；写不要求立即回复的异步友好消息。
9. 遵循 'No Hello' 原则：不要只发 'Hi'、'Are you there?'、'Can I ask you something?' 然后等待；而应一次说清，例如 'Hi Sarah - quick question about the deployment script. Getting a permission error on line 42. Have you seen this before? Here's the error: [paste error]'。
10. 按受众调整技术程度：对工程同事用技术细节、代码示例、架构细节；对技术经理平衡细节与高层影响；对非技术干系人讲业务影响、类比、结果而非实现；对客户用平实语言、说明对他们意味着什么、避免术语。
11. 简化表达用三种策略：先讲大图景再讲细节（人先理解 why 再理解 how）；在不失准确的前提下简化（用类比、把术语换成平实语言）；知道何时切换（观察现场反应，根据提问和参与度调整）。
12. 把术语翻译成平实语言，例如 'Microservices architecture' 说成 'Our system is split into smaller, independent pieces that can scale separately'，'Asynchronous message processing' 说成 'Tasks are queued and processed in the background'，'CI/CD pipeline' 说成 'Automated process that tests and deploys our code'，'Database migration' 说成 'Updating how our data is organized and stored'。
13. 用主动语态替代被动语态：把 'A bug was identified by the team' 改为 'The team identified a bug'，把 'The feature will be implemented' 改为 'We will implement the feature'，把 'Errors were found during testing' 改为 'Testing revealed errors'。
14. 删除填充词：'At this point in time' 改为 'Now'，'In the event that' 改为 'If'，'Due to the fact that' 改为 'Because'，'In order to' 改为 'To'，'I just wanted to check if' 改为 'Can you'。
15. 写完做 'So What?' 测试：问自己 'So what? Why does this matter to the reader?'，如果答不清楚，就重构消息，把价值/影响放在最前面。
16. 会议前在邀请中写清：明确目标（要达成什么）、议程项及时间预估、需要做的准备（参会者应带/审阅什么）、预期结果（需要决策、信息同步还是头脑风暴）。
17. 会议中执行引导技巧：给讨论设定时间盒，例如 'Let's spend 5 minutes on this, then move on'；实时记录行动项（谁在何时前做什么）；用 parking lot 记下跑题事项留待后续。
18. 会议后按格式写总结：标题为 Meeting: [Topic] - [Date]；列出 Attendees；列出 Key Decisions；用复选框列出 Action Items（[Person]: [Task] - Due [Date]）；列出 Next Steps（后续会议、待分享文档）。
19. 发送任何专业沟通前过一遍检查清单：目的是否清晰（接收者能否 5 秒内理解意图）；受众/渠道是否合适；关键信息是否在最前；是否可扫读（项目符号、标题、短段落）；行动是否明确（接收者是否知道要做什么）；术语检查（受众是否都懂）；语气是否专业但不冷漠；是否校对过错别字和不清表述。
20. 需要现成模板时查阅 references/email-templates.md（按类型分类的邮件模板）、references/meeting-structures.md（站会、回顾、评审的结构）、references/jargon-simplification.md（技术到平实语言的翻译）。
21. 遇到困难对话和反馈传达时，配合使用 companion skill feedback-mastery；需要生成邮件时使用 /draft-email。