名称: 专业沟通描述: 指导软件开发者的技术沟通。覆盖电子邮件结构、团队消息礼仪、会议议程准备，以及调整消息以适应技术与非技术受众。用于起草专业消息、准备会议沟通或改进书面沟通。允许工具: Read, Glob, Grep

专业沟通

概述

这个技能为软件开发者提供有效的专业沟通框架和指导。无论您是向利益相关者写电子邮件、制作团队聊天消息，还是准备会议议程，这些原则帮助您清晰沟通并建立专业信誉。

核心原则: 有效的沟通不是证明您知道多少——而是确保您的消息被接收和理解。

何时使用这个技能

在以下情况下使用这个技能：

向团队成员、经理或利益相关者写电子邮件
制作团队聊天消息或异步通信
准备会议议程或摘要
将技术概念转化为非技术受众理解的语言
构建状态更新或报告结构
改进书面沟通的清晰度

关键词: 电子邮件、聊天、团队、Slack、Discord、消息、写作、沟通、会议、议程、状态更新、报告

核心框架

什么-为什么-如何结构

使用这个通用框架来组织任何专业消息：

组件	目的	示例
什么	清楚地陈述主题/请求	“我们需要将发布时间延迟一周”
为什么	解释原因	“在支付处理中发现关键错误”
如何	概述下一步/行动项	“QA将在周四前重新测试；我将在周五更新利益相关者”

应用于: 电子邮件、状态更新、会议讨论点、技术解释

书面沟通的三大黄金法则

从清晰的主题/目的开始 - 收件人应立即理解您的消息内容
使用项目符号、标题和可扫描的格式 - 没有人喜欢一堵墙式的文字
关键信息优先 - 忙碌的人欣赏效率；先陈述您的要点

受众校准

在沟通之前，问自己：

您写给谁？（技术同行、经理、利益相关者、客户）
他们需要什么级别的细节？（高层次概述 vs 实施细节）
对他们的价值是什么？（这如何影响他们的工作/决策？）

电子邮件最佳实践

主题行公式

避免使用	尝试
“项目更新”	“项目 X: 状态更新和下一步”
“问题”	“快速问题: API 速率限制方法”
“仅供参考”	“仅供参考: 部署计划于周二下午3点”

电子邮件结构模板

**主题:** [项目/主题]: [具体目的]

嗨 [姓名],

[1-2句话提前陈述要点或请求]

**背景/上下文:**
- [项目符号 1]
- [项目符号 2]

**我需要您做什么:**
- [具体行动或决策需要]
- [时间线如适用]

[可选: 简短下一步或跟进计划]

祝好,
[您的名字]

常见电子邮件类型

类型	关键元素
状态更新	进度摘要、障碍、下一步、时间线
请求	清晰请求、上下文、截止日期、为什么重要
升级	问题摘要、影响、尝试解决方案、需要决策
仅供参考/公告	更改内容、受影响人员、任何所需行动

对于模板: 参见 references/email-templates.md

团队消息礼仪

注意: 示例使用 Slack 术语，但这些原则同样适用于 Microsoft Teams、Discord 或任何团队消息平台。

何时使用聊天 vs 电子邮件

使用聊天	使用电子邮件
简短回答的快速问题	需要记录的详细文档
实时协调	向利益相关者的正式通信
非正式团队讨论	需要仔细审查的消息
时间敏感的更新	多部分复杂解释

团队消息最佳实践

使用线程 - 保持主频道可扫描；后续讨论放在线程中
@提及要体贴 - 不必要时不通知他人
频道组织 - 正确频道用于正确主题
直接 - "您能审查我的 PR 吗？“胜过"嗨，您忙吗？”
异步友好 - 写不需要立即回复的消息

"无打招呼"原则

而不是：

您: 嗨
您: 您在那里吗？
您: 我能问您点事吗？
[等待...]

尝试：

您: 嗨 Sarah - 关于部署脚本的快速问题。
     在第42行遇到权限错误。您之前见过这个吗？
     这是错误: [粘贴错误]

技术 vs 非技术沟通

何时保持技术性 vs 可访问性

受众	方法
工程同行	技术细节、代码示例、架构具体内容
技术经理	细节和高层次影响的平衡
非技术利益相关者	业务影响、类比、结果优于实施
客户	简单语言、对他们的意义、避免术语

简化的三个策略

从大局开始再到细节 - 人们先处理"为什么"再处理"如何"
简化但不失准确性 - 使用类比；用简单语言替换术语
知道何时切换 - 观察场景；根据问题和参与调整

术语翻译示例

技术性	简单语言
“微服务架构”	“我们的系统被分成较小、独立的部分，可以单独扩展”
“异步消息处理”	“任务在后台排队和处理”
“CI/CD 流水线”	“自动测试和部署代码的过程”
“数据库迁移”	“更新我们的数据组织和存储方式”

更多示例: 参见 references/jargon-simplification.md

写作清晰原则

主动语态优于被动语态

主动语态更清晰、更直接、传达权威：

被动（避免）	主动（偏好）
“一个错误被团队识别”	“团队识别了一个错误”
“该功能将被实施”	“我们将实施该功能”
“在测试中发现错误”	“测试揭示了错误”

消除填充词

避免使用	使用
“在此时点”	“现在”
“在…的情况下”	“如果”
“由于…的事实”	“因为”
“为了”	“为了”
“我只是想检查一下”	“您能”

"那又如何？"测试

写作后问：“那又如何？为什么这对读者重要？”

如果您无法清楚回答，重新构建您的消息以先陈述价值/影响。

会议沟通

会前：议程最佳实践

每个会议邀请应包括：

明确目标 - 将完成什么？
议程项 - 要涵盖的主题，附时间估计
所需准备 - 与会者应带来/审查什么？
预期结果 - 需要决策？信息共享？头脑风暴？

会中：引导技巧

时间盒讨论 - “让我们在这个问题上花5分钟，然后继续”
实时捕获行动项 - 谁在什么时候做什么
停车场 - 记录离题项以备后论

会后：摘要格式

**会议: [主题] - [日期]**

**与会者:** [名字]

**关键决策:**
- [决策 1]
- [决策 2]

**行动项:**
- [ ] [人员]: [任务] - 截止 [日期]
- [ ] [人员]: [任务] - 截止 [日期]

**下一步:**
- [如果需要，后续会议]
- [要分享的文档]

按会议类型的结构: 参见 references/meeting-structures.md

快速参考：沟通检查清单

发送任何专业沟通之前：

[ ] 目的清晰 - 收件人能在5秒内理解意图吗？
[ ] 正确受众 - 这是适当的人/频道吗？
[ ] 关键信息优先 - 要点是否提前？
[ ] 可扫描 - 是否有项目符号、标题、短段落？
[ ] 行动清晰 - 收件人知道他们需要做什么（如果有的话）吗？
[ ] 术语检查 - 受众能理解所有术语吗？
[ ] 语气适当 - 专业但不冷淡吗？
[ ] 校对 - 有任何拼写错误或不清晰措辞吗？

附加工具

references/email-templates.md - 按类型的现成电子邮件模板
references/meeting-structures.md - 站会、回顾、评审的结构
references/jargon-simplification.md - 技术到简单语言的翻译

配套技能

feedback-mastery - 用于困难对话和反馈交付
/draft-email - 使用这些框架生成电子邮件

最后更新: 2025-12-22

版本历史

v1.0.0 (2025-12-26): 初始发布

名称: 专业沟通 描述: 指导软件开发者的技术沟通。覆盖电子邮件结构、团队消息礼仪、会议议程准备，以及调整消息以适应技术与非技术受众。用于起草专业消息、准备会议沟通或改进书面沟通。 允许工具: Read, Glob, Grep