name: 专业沟通 description: 指导软件开发者的技术沟通。涵盖电子邮件结构、团队消息礼仪、会议议程，以及为技术与非技术受众调整消息。在起草专业消息、准备会议沟通或改进书面沟通时使用。 allowed-tools: 读取, 全局搜索, 查找

专业沟通

概述

这个技能提供框架和指导，用于在软件开发上下文中进行有效的专业沟通。无论您是写电子邮件给利益相关者、撰写团队聊天消息还是准备会议议程，这些原则帮助您清晰地沟通并建立专业信誉。

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

何时使用此技能

在以下情况下使用此技能：

写电子邮件给队友、经理或利益相关者
撰写团队聊天消息或异步沟通
准备会议议程或摘要
为非技术受众翻译技术概念
构建状态更新或报告
改进书面沟通的清晰度

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

核心框架

什么-为什么-如何结构

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

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

应用于： 电子邮件、状态更新、会议谈话要点、技术解释

书面沟通的三条黄金规则

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

受众校准

在沟通之前，问自己：

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

电子邮件最佳实践

主题行公式

而不是	尝试
“项目更新”	“项目 X：状态更新和后续步骤”
“问题”	“快速问题：API 速率限制方法”
“FYI”	“FYI：部署计划在周二下午3点”

电子邮件结构模板

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

嗨 [姓名]，

[1-2句话先陈述关键点或请求]

**背景：**
- [项目符号点 1]
- [项目符号点 2]

**我需要您做什么：**
- [具体行动或决策需要]
- [如有时间线，请注明]

[可选：简要后续步骤或跟进计划]

祝好，
[您的名字]

常见电子邮件类型

类型	关键元素
状态更新	进度摘要、障碍、后续步骤、时间线
请求	清晰询问、背景、截止日期、为什么重要
升级	问题摘要、影响、尝试的解决方案、需要的决策
FYI/公告	改变了什么、谁受影响、任何需要的行动

模板： 参见 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秒内理解意图吗？
[ ] 正确受众 - 这是适当的人/频道吗？
[ ] 关键信息优先 - 主要观点是否在前面？
[ ] 可扫描 - 是否有项目符号、标题、短段落？
[ ] 行动清晰 - 收件人知道他们需要做什么（如果有的话）？
[ ] 行话检查 - 受众能理解所有术语吗？
[ ] 语调恰当 - 是否专业但不冷漠？
[ ] 校对 - 有任何错别字或不清楚的措辞吗？

版本历史

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

专业沟通Skill professional-communication