professional-communication

專業溝通

概述

本技能提供在軟體開發情境中進行有效專業溝通的框架與指引。無論是撰寫給利害關係人的電子郵件、草擬團隊聊天訊息，或準備會議議程，這些原則都能幫助你清晰溝通並建立專業信譽。

核心原則： 有效的溝通不在於證明你懂多少，而在於確保訊息被接收與理解。

何時使用此技能

在以下情況使用此技能：

• 撰寫給團隊成員、主管或利害關係人的電子郵件
• 草擬團隊聊天訊息或非同步溝通內容
• 準備會議議程或摘要
• 將技術概念轉譯給非技術受眾
• 結構化狀態更新或報告
• 改善書面溝通的清晰度

關鍵字： email, chat, teams, slack, discord, message, writing, communication, meeting, agenda, status update, report

核心框架

什麼-為什麼-如何結構

使用這個通用框架來組織任何專業訊息：

組成	目的	範例
什麼	清楚陳述主題/請求	「我們需要將發布延後一週」
為什麼	解釋理由	「在金流處理中發現重大錯誤」
如何	列出後續步驟/行動項目	「QA 將在週四前重新測試；我會在週五更新利害關係人」

應用於： 電子郵件、狀態更新、會議談話重點、技術說明

書面溝通三條黃金法則

1. 以明確的主旨/目的開頭 – 收件人應能立即掌握你的訊息內容
2. 使用項目符號、標題和易掃讀的格式 – 沒有人想看一大段文字
3. 重點訊息放前面 – 忙碌的人喜歡效率；先把主要觀點說清楚

受眾校準

在溝通前，問自己：

1. 誰是你的溝通對象？（技術同儕、主管、利害關係人、客戶）
2. 他們需要什麼詳細程度？（高層概述 vs 實作細節）
3. 對他們來說價值是什麼？（這如何影響他們的工作/決策？）

電子郵件最佳實務

主旨行公式

避免	改用
「專案更新」	「專案 X：狀態更新與後續步驟」
「問題」	「快速問題：API 速率限制方法」
「僅供參考」	「僅供參考：部署排定於週二下午 3 點」

電子郵件結構範本

**主旨：** [專案/主題]：[具體目的]

[姓名] 您好，

[1-2 句話陳述關鍵點或請求，放在開頭]

**背景/脈絡：**
- [項目 1]
- [項目 2]

**我需要您協助的事項：**
- [具體行動或決策需求]
- [若適用，請提供時程]

[可選：簡短的後續步驟或跟進計畫]

祝好，
[您的姓名]

常見電子郵件類型

類型	關鍵要素
狀態更新	進度摘要、阻礙、下一步、時程
請求	明確要求、背景、截止日期、為何重要
升級	問題摘要、影響、已嘗試的解決方案、所需決策
僅供參考/公告	變更內容、受影響對象、任何必要行動

範本請見： references/email-templates.md

團隊訊息禮儀

注意： 範例使用 Slack 術語，但這些原則同樣適用於 Microsoft Teams、Discord 或任何團隊訊息平台。

何時使用聊天 vs 電子郵件

使用聊天	使用電子郵件
簡短回答的快速問題	需要記錄的詳細文件
即時協調	給利害關係人的正式溝通
非正式的團隊討論	需要仔細審閱的訊息
時間敏感的更新	包含多個部分的複雜說明

團隊訊息最佳實務

1. 使用討論串 – 保持主要頻道易於掃讀；後續討論放在討論串中
2. 審慎使用 @提及 – 不要不必要地通知他人
3. 頻道組織 – 正確的頻道用於正確的主題
4. 直接表達 – 「可以幫我 review PR 嗎？」勝過「嘿，你忙嗎？」
5. 非同步友善 – 撰寫不需要立即回覆的訊息

「別只說嗨」原則

與其這樣：

你：嗨
你：你在嗎？
你：可以問你一件事嗎？
[等待中...]

不如這樣：

你：嗨 Sarah，關於部署腳本有個小問題。
    在第 42 行遇到權限錯誤。你之前看過這個嗎？
    錯誤訊息如下：[貼上錯誤]

技術 vs 非技術溝通

何時使用技術語言 vs 平易語言

受眾	方式
工程同儕	技術細節、程式碼範例、架構細節
技術主管	細節與高層影響的平衡
非技術利害關係人	商業影響、類比、結果而非實作
客戶	白話、對他們的意義、避免行話

簡化的三種策略

1. 先講大局再講細節 – 人們先處理「為什麼」再處理「如何」
2. 簡化但不失準確 – 使用類比；用白話取代行話
3. 知道何時切換 – 觀察現場；根據問題和參與度調整

行話轉譯範例

技術用語	白話
「微服務架構」	「我們的系統拆分為較小、獨立的元件，可以各自擴展」
「非同步訊息處理」	「任務會被排入佇列並在背景處理」
「CI/CD 管線」	「自動化流程，用於測試和部署我們的程式碼」
「資料庫遷移」	「更新我們資料的組織與儲存方式」

更多範例請見： references/jargon-simplification.md

寫作清晰原則

主動語態勝過被動語態

主動語態更清晰、更直接，且傳達權威感：

被動（避免）	主動（偏好）
「一個錯誤被團隊發現了」	「團隊發現了一個錯誤」
「該功能將被實作」	「我們將實作該功能」
「錯誤在測試中被發現」	「測試揭露了錯誤」

刪除填充詞

與其用	改用
「在目前的時間點」	「現在」
「在……的情況下」	「如果」
「由於……的事實」	「因為」
「為了要」	「為了」
「我只是想確認是否」	「可以請你」

「所以呢？」測試

寫完後問自己：「所以呢？這對讀者有什麼意義？」

如果你無法清楚回答，重新組織你的訊息，以價值/影響為開頭。

會議溝通

會前：議程最佳實務

每場會議邀請應包含：

1. 明確目標 – 將達成什麼？
2. 議程項目 – 要討論的主題及時間估計
3. 所需準備 – 與會者應攜帶/預習什麼？
4. 預期成果 – 需要決策？資訊分享？腦力激盪？

會中：引導技巧

• 時間盒討論 – 「我們花 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)：初始版本

---