professional-communication
TraeWork 内置 skill —— 开发者职业沟通指南。邮件、团队消息、会议、技术 vs 非技术受众。核心：有效沟通不是证明你懂多少——是确保消息被接收并理解。
一、定位
| 字段 | 值 |
|---|---|
| 所属 | TraeWork 内置 skill（沟通类） |
| 触发条件 | 写邮件、团队消息、会议、技术解释 |
| 核心方法 | What-Why-How 结构 + 受众校准 |
| 核心理念 | Effective communication isn’t about proving how much you know |
二、核心框架
2.1 What-Why-How 通用结构
任何职业消息都可以用这个框架组织：
| 组件 | 作用 | 示例 |
|---|---|---|
| What | 说清主题/请求 | ”我们需要延期一周发布” |
| Why | 解释原因 | ”发现支付处理有严重 bug” |
| How | 列出下一步 / 行动项 | ”QA 周四前重测；我周五更新 stakeholder” |
适用：邮件、状态更新、会议要点、技术解释
2.2 书面沟通的 3 条黄金规则
- 主题/目的清晰 — 收件人立刻明白是什么
- 用 bullet、标题、可扫读的格式 — 没人想读一大段文字
- 关键消息先说 — 忙的人感激效率；先把重点说在前
2.3 受众校准
写之前问自己：
- 写给谁？（技术同级、技术经理、非技术 stakeholder、客户）
- 要什么详细度？（高层概览 vs 实现细节）
- 对他们的价值？（这怎么影响他们工作/决策）
三、邮件最佳实践
3.1 主题行
| 不好 | 好 |
|---|---|
| ”Project updates" | "Project X: 状态更新和下一步" |
| "Question" | "快速问：API 限流方案" |
| "FYI" | "FYI：部署定在周二下午 3 点” |
3.2 邮件结构模板
**Subject:** [项目/主题]: [具体目的]
Hi [姓名],
[1-2 句话说清关键点或请求]
**背景/上下文：**
- [要点 1]
- [要点 2]
**我需要你做的：**
- [具体行动或决定]
- [如果有期限]
[可选：简短的下一步或跟进计划]
Best,
[你的名字]3.3 4 种常见邮件类型
| 类型 | 关键要素 |
|---|---|
| 状态更新 | 进度总结、阻塞、下一步、时间线 |
| 请求 | 清晰请求、上下文、截止、为什么重要 |
| 升级 | 问题摘要、影响、尝试过的方案、需要的决定 |
| FYI/公告 | 变化了什么、谁受影响、需要什么行动 |
四、团队消息礼仪
注：示例用 Slack 术语，但这些原则适用于 Teams、Discord 或任何团队消息平台。
4.1 什么时候用 Chat vs Email
| 用 Chat | 用 Email |
|---|---|
| 短答的快速问题 | 需要记录的长文档 |
| 实时协调 | 给 stakeholder 的正式沟通 |
| 团队内非正式讨论 | 需要仔细审阅的消息 |
| 紧急更新 | 复杂的多部分解释 |
4.2 5 条最佳实践
- 用 threads — 主频道保持可扫；后续进 thread
- @提及要谨慎 — 不要无意义通知人
- 频道组织 — 对的话题放对的频道
- 直接 — “能 review 我的 PR 吗” 比 “嘿，你忙吗” 强
- 异步友好 — 写不要求立即回复的消息
4.3 「No Hello」原则
不要这样：
你: Hi
你: 在吗
你: 能问个事吗
[等...]
要这样：
你: Hi Sarah - 快速问部署脚本的问题。
第 42 行有权限错误。你见过吗？
错误是：[粘贴错误]
五、技术 vs 非技术沟通
5.1 什么时候用技术 vs 通俗
| 受众 | 方式 |
|---|---|
| 技术同级 | 技术细节、代码示例、架构细节 |
| 技术经理 | 细节和高层次影响的平衡 |
| 非技术 stakeholder | 业务影响、类比、结果而非实现 |
| 客户 | 通俗语言、对他们意味着什么、避免术语 |
5.2 3 个简化策略
- 先讲大图再讲细节 — 人们先处理「为什么」再处理「怎么」
- 简化但不丢准确性 — 用类比；用通俗语言代替术语
- 知道什么时候切换 — 看场合；根据问题和参与度调整
5.3 术语翻译示例
| 技术 | 通俗 |
|---|---|
| 「微服务架构」 | 「系统拆成更小的独立部分，可以分别扩展」 |
| 「异步消息处理」 | 「任务排队，后台处理」 |
| 「CI/CD 流水线」 | 「自动测试和部署代码的流程」 |
| 「数据库迁移」 | 「更新数据组织方式」 |
六、写作清晰度原则
6.1 主动语态优于被动语态
| 被动（避免） | 主动（推荐） |
|---|---|
| 「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」 |
6.2 去掉填充词
| 改为 | 用 |
|---|---|
| 「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」 |
6.3 「So What?」测试
写完问自己：「So what? Why does this matter to the reader?」
如果答不清楚，重构消息，把价值/影响放前面。
七、会议沟通
7.1 会议前：议程最佳实践
每个会议邀请都要包含：
- 清晰目标 — 要达成什么
- 议程项目 — 讨论话题 + 时间估计
- 需要准备 — 参会者要带/读什么
- 预期结果 — 决策？信息分享？头脑风暴？
7.2 会议中：主持技巧
- 时间盒 — “我们花 5 分钟聊这个，然后继续”
- 实时记录 action items — 谁在什么时间前做什么
- Parking lot — 记下离题项目供以后
7.3 会议后：摘要格式
**会议: [主题] - [日期]**
**参会者：** [姓名列表]
**关键决策：**
- [决策 1]
- [决策 2]
**行动项：**
- [ ] [人]: [任务] - 截止 [日期]
- [ ] [人]: [任务] - 截止 [日期]
**下一步：**
- [如果需要，跟进会议]
- [要分享的文档]八、发送前清单
发送任何职业沟通前：
-
目的清晰 — 收件人 5 秒内能理解意图？
-
对的受众 — 这是合适的人/频道？
-
关键消息先说 — 重点在前面？
-
可扫读 — bullet、标题、短段落？
-
行动清晰 — 收件人知道需要做什么（如果有）？
-
术语检查 — 受众能理解所有术语？
-
语气合适 — 专业但不冷漠？
-
校对 — 拼写错误或不清晰的措辞？
九、相关 skill
| Skill | 关系 |
|---|---|
difficult-workplace-conversations | 困难对话（处理冲突、绩效反馈） |
/draft-email | 用这些框架生成邮件 |
feedback-mastery | SBI 反馈模型（专注反馈场景） |
十、引用来源
- TraeWork 实际 skill 路径 —— 本文内容完全来自此文件
- 同目录的
references/email-templates.md/meeting-structures.md/jargon-simplification.md
十一、一句话总结
professional-communication 是「开发者职业沟通」指南——What-Why-How 结构、3 条黄金规则、受众校准、主动语态、「So What?」测试。核心不是证明你懂多少，是确保消息被接收并理解。