Back to Details

professional-communication

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Professional Communication

专业沟通指南

Overview

概述

This skill provides frameworks and guidance for effective professional communication in software development contexts. Whether you're writing an email to stakeholders, crafting a team chat message, or preparing meeting agendas, these principles help you communicate clearly and build professional credibility.
Core principle: Effective communication isn't about proving how much you know - it's about ensuring your message is received and understood.
本指南为软件开发场景下的高效专业沟通提供框架与指导。无论是给利益相关者写邮件、撰写团队聊天消息，还是准备会议议程，这些原则都能帮你清晰沟通并建立专业可信度。
核心原则： 高效沟通的关键不在于证明你懂多少，而在于确保你的信息被接收并理解。

When to Use This Skill

适用场景

Use this skill when:
  • Writing emails to teammates, managers, or stakeholders
  • Crafting team chat messages or async communications
  • Preparing meeting agendas or summaries
  • Translating technical concepts for non-technical audiences
  • Structuring status updates or reports
  • Improving clarity of written communication
Keywords: email, chat, teams, slack, discord, message, writing, communication, meeting, agenda, status update, report
在以下场景中使用本指南：
  • 给同事、经理或利益相关者撰写邮件
  • 撰写团队聊天消息或异步沟通内容
  • 准备会议议程或纪要
  • 为非技术受众解释技术概念
  • 整理状态更新或报告
  • 提升书面沟通的清晰度
关键词：email、chat、teams、slack、discord、message、writing、communication、meeting、agenda、status update、report

Core Frameworks

核心框架

The What-Why-How Structure

何事-原因-方法结构

Use this universal framework to organize any professional message:
ComponentPurposeExample
WhatState the topic/request clearly"We need to delay the release by one week"
WhyExplain the reasoning"Critical bug found in payment processing"
HowOutline next steps/action items"QA will retest by Thursday; I'll update stakeholders Friday"
Apply to: Emails, status updates, meeting talking points, technical explanations
运用这个通用框架来组织任何专业沟通内容：
组成部分目的示例
何事（What）清晰说明主题/请求"我们需要将发布推迟一周"
原因（Why）解释理由"在支付流程中发现严重漏洞"
方法（How）列出后续步骤/行动项"QA团队将在周四前重新测试；我会在周五同步给利益相关者"
适用场景：邮件、状态更新、会议讨论要点、技术说明

Three Golden Rules for Written Communication

书面沟通三大黄金法则

  1. Start with a clear subject/purpose - Recipients should immediately grasp what your message is about
  2. Use bullets, headlines, and scannable formatting - Nobody wants a wall of text
  3. Key messages first - Busy people appreciate efficiency; state your main point upfront
  1. 开篇明确主题/目的 - 收件人应能立刻明白你的沟通内容是什么
  2. 使用项目符号、标题和易读格式 - 没人愿意看大段密集文字
  3. 核心信息前置 - 忙碌的人更看重效率；把核心观点放在最前面

Audience Calibration

受众适配

Before communicating, ask yourself:
  1. Who are you writing to? (Technical peers, managers, stakeholders, customers)
  2. What level of detail do they need? (High-level overview vs implementation details)
  3. What's the value for them? (How does this affect their work/decisions?)
沟通前，先问自己三个问题：
  1. 受众是谁？（技术同行、经理、利益相关者、客户）
  2. 他们需要多少细节？（高层概述 vs 实现细节）
  3. 这对他们有什么价值？（这会如何影响他们的工作/决策？）

Email Best Practices

邮件沟通最佳实践

Subject Line Formula

主题栏公式

Instead ofTry
"Project updates""Project X: Status Update and Next Steps"
"Question""Quick question: API rate limiting approach"
"FYI""FYI: Deployment scheduled for Tuesday 3pm"
避免写法推荐写法
"项目更新""Project X: Status Update and Next Steps"
"问题咨询""Quick question: API rate limiting approach"
"仅供参考""FYI: Deployment scheduled for Tuesday 3pm"

Email Structure Template

邮件结构模板

markdown
**Subject:** [Project/Topic]: [Specific Purpose]

Hi [Name],

[1-2 sentences stating the key point or request upfront]

**Context/Background:**
- [Bullet point 1]
- [Bullet point 2]

**What I need from you:**
- [Specific action or decision needed]
- [Timeline if applicable]

[Optional: Brief next steps or follow-up plan]

Best,
[Your name]
markdown
**Subject:** [Project/Topic]: [Specific Purpose]

Hi [Name],

[1-2 sentences stating the key point or request upfront]

**Context/Background:**
- [Bullet point 1]
- [Bullet point 2]

**What I need from you:**
- [Specific action or decision needed]
- [Timeline if applicable]

[Optional: Brief next steps or follow-up plan]

Best,
[Your name]

Common Email Types

常见邮件类型

TypeKey Elements
Status UpdateProgress summary, blockers, next steps, timeline
RequestClear ask, context, deadline, why it matters
EscalationIssue summary, impact, attempted solutions, needed decision
FYI/AnnouncementWhat changed, who's affected, any required action
For templates: See 
references/email-templates.md
邮件类型核心要素
状态更新进度总结、阻塞问题、后续步骤、时间线
请求类明确的需求、背景信息、截止日期、重要性
升级上报问题概述、影响范围、已尝试的解决方案、所需决策
告知/公告类变更内容、受影响人群、任何必要行动
模板参考：请查看 
references/email-templates.md

Team Messaging Etiquette

团队消息沟通礼仪

Note: Examples use Slack terminology, but these principles apply equally to Microsoft Teams, Discord, or any team messaging platform.
注意：示例使用Slack术语，但这些原则同样适用于Microsoft Teams、Discord或任何团队消息平台。

When to Use Chat vs Email

何时用聊天工具 vs 邮件

Use ChatUse Email
Quick questions with short answersDetailed documentation needing records
Real-time coordinationFormal communications to stakeholders
Informal team discussionsMessages requiring careful review
Time-sensitive updatesComplex explanations with multiple parts
使用聊天工具使用邮件
简短答案的快速问题需要存档的详细文档
实时协作给利益相关者的正式沟通
非正式团队讨论需要仔细审阅的消息
时间敏感的更新包含多个部分的复杂说明

Team Messaging Best Practices

团队消息沟通最佳实践

  1. Use threads - Keep main channels scannable; follow-ups go in threads
  2. @mention thoughtfully - Don't notify people unnecessarily
  3. Channel organization - Right channel for right topic
  4. Be direct - "Can you review my PR?" beats "Hey, are you busy?"
  5. Async-friendly - Write messages that don't require immediate response
  1. 使用线程回复 - 保持主频道内容简洁易读；后续讨论放在线程中
  2. 谨慎使用@提及 - 不要无故通知他人
  3. 频道合理分类 - 合适的话题放在合适的频道
  4. 直接表达 - 用“能帮忙审阅我的PR吗？”代替“嘿，你忙吗？”
  5. 适配异步沟通 - 撰写无需即时回复的消息

The "No Hello" Principle

“无空问候”原则

Instead of:
text
You: Hi
You: Are you there?
You: Can I ask you something?
[waiting...]
Try:
text
You: 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]
避免这样写：
text
You: Hi
You: Are you there?
You: Can I ask you something?
[waiting...]
建议这样写：
text
You: 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]

Technical vs Non-Technical Communication

技术与非技术受众的沟通差异

When to Be Technical vs Accessible

何时使用技术术语 vs 通俗表达

AudienceApproach
Engineering peersTechnical details, code examples, architecture specifics
Technical managersBalance of detail and high-level impact
Non-technical stakeholdersBusiness impact, analogies, outcomes over implementation
CustomersPlain language, what it means for them, avoid jargon
受众沟通方式
技术同行技术细节、代码示例、架构说明
技术经理平衡细节与高层影响
非技术利益相关者业务影响、类比说明、关注结果而非实现过程
客户平实语言、说明对他们的影响、避免术语

Three Strategies for Simplification

简化表达的三大策略

  1. Start with the big picture before details - People process "why" before "how"
  2. Simplify without losing accuracy - Use analogies; replace jargon with plain language
  3. Know when to switch - Read the room; adjust based on questions and engagement
  1. 先讲全局再讲细节 - 人们会先理解“为什么”再关注“怎么做”
  2. 简化但不失准确 - 使用类比；用平实语言替代术语
  3. 懂得适时调整 - 观察受众反应；根据问题和互动情况调整沟通方式

Jargon Translation Examples

术语通俗化示例

TechnicalPlain Language
"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"
For more examples: See 
references/jargon-simplification.md
技术术语通俗表达
"Microservices architecture""我们的系统拆分为多个小型独立模块，可分别扩展"
"Asynchronous message processing""任务会被排入队列并在后台处理"
"CI/CD pipeline""自动测试和部署代码的流程"
"Database migration""更新数据的组织和存储方式"
更多示例：请查看 
references/jargon-simplification.md

Writing Clarity Principles

书面表达清晰性原则

Active Voice Over Passive Voice

优先使用主动语态

Active voice is clearer, more direct, and conveys authority:
Passive (avoid)Active (prefer)
"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"
主动语态更清晰、直接，且更具权威性：
被动语态（避免使用）主动语态（推荐使用）
"一个漏洞被团队发现""团队发现了一个漏洞"
"该功能将被实现""我们将实现该功能"
"测试过程中发现了错误""测试揭示了错误"

Eliminate Filler Words

去除冗余词汇

Instead ofUse
"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"
冗余表达简洁表达
"目前来说""现在"
"万一""如果"
"鉴于以下事实""因为"
"为了实现""为了"

The "So What?" Test

"那又如何？"测试法

After writing, ask: "So what? Why does this matter to the reader?"
If you can't answer clearly, restructure your message to lead with the value/impact.
写完内容后，问自己：“那又如何？这对读者来说重要吗？”
如果你无法清晰回答，就重新组织内容，优先突出价值/影响。

Meeting Communication

会议沟通

Before: Agenda Best Practices

会前：议程制定最佳实践

Every meeting invite should include:
  1. Clear objective - What will be accomplished?
  2. Agenda items - Topics to cover with time estimates
  3. Preparation required - What should attendees bring/review?
  4. Expected outcome - Decision needed? Information sharing? Brainstorm?
每一份会议邀请都应包含：
  1. 明确的目标 - 会议要达成什么结果？
  2. 议程项 - 要讨论的话题及时间预估
  3. 会前准备要求 - 参会者需要带什么/提前审阅什么？
  4. 预期成果 - 需要做出决策？还是信息同步？或是头脑风暴？

During: Facilitation Tips

会中：主持技巧

  • Time-box discussions - "Let's spend 5 minutes on this, then move on"
  • Capture action items live - Who does what by when
  • Parking lot - Note off-topic items for later
  • 给讨论设定时间限制 - “我们花5分钟讨论这个话题，然后进入下一项”
  • 实时记录行动项 - 谁在什么时候做什么
  • 待办清单（Parking lot） - 记录偏离主题的内容，后续再处理

After: Summary Format

会后：纪要格式

markdown
**Meeting: [Topic] - [Date]**

**Attendees:** [Names]

**Key Decisions:**
- [Decision 1]
- [Decision 2]

**Action Items:**
- [ ] [Person]: [Task] - Due [Date]
- [ ] [Person]: [Task] - Due [Date]

**Next Steps:**
- [Follow-up meeting if needed]
- [Documents to share]
For structures by meeting type: See 
references/meeting-structures.md
markdown
**Meeting: [Topic] - [Date]**

**Attendees:** [Names]

**Key Decisions:**
- [Decision 1]
- [Decision 2]

**Action Items:**
- [ ] [Person]: [Task] - Due [Date]
- [ ] [Person]: [Task] - Due [Date]

**Next Steps:**
- [Follow-up meeting if needed]
- [Documents to share]
按会议类型分类的结构参考：请查看 
references/meeting-structures.md

Quick Reference: Communication Checklist

快速参考：沟通检查表

Before sending any professional communication:
  • Clear purpose - Can the recipient understand intent in 5 seconds?
  • Right audience - Is this the appropriate person/channel?
  • Key message first - Is the main point upfront?
  • Scannable - Are there bullets, headers, short paragraphs?
  • Action clear - Does the recipient know what (if anything) they need to do?
  • Jargon check - Will the audience understand all terminology?
  • Tone appropriate - Is it professional but not cold?
  • Proofread - Any typos or unclear phrasing?
在发送任何专业沟通内容前，请检查：
  • 目的明确 - 收件人能在5秒内明白你的意图吗？
  • 受众正确 - 这是合适的沟通对象/渠道吗？
  • 核心信息前置 - 核心观点放在最前面了吗？
  • 易读性强 - 是否使用了项目符号、标题和短段落？
  • 行动明确 - 收件人清楚需要做什么（如果有的话）吗？
  • 术语检查 - 受众能理解所有术语吗？
  • 语气恰当 - 专业但不过于生硬吗？
  • 校对无误 - 有没有错别字或表达模糊的地方？

Additional Tools

额外工具

  • references/email-templates.md
    - Ready-to-use email templates by type
  • references/meeting-structures.md
    - Structures for standups, retros, reviews
  • references/jargon-simplification.md
    - Technical-to-plain-language translations
  • references/email-templates.md
    - 按类型分类的即用型邮件模板
  • references/meeting-structures.md
    - 站会、回顾会、评审会的结构模板
  • references/jargon-simplification.md
    - 技术术语到通俗表达的对照表

Companion Skills

配套技能

  • feedback-mastery
    - For difficult conversations and feedback delivery
  • /draft-email
    - Generate emails using these frameworks
Last Updated: 2025-12-22
  • feedback-mastery
    - 用于处理困难对话和反馈传递
  • /draft-email
    - 运用这些框架生成邮件
最后更新日期：2025-12-22

Version History

版本历史

  • v1.0.0 (2025-12-26): Initial release
  • v1.0.0（2025-12-26）：首次发布