怎麼用文字給同事批評性的回饋，又不顯得苛刻？

共用提案的第四頁，留言框已經開著。你打了「這段說不通」，刪掉；又打了「這裡可以再精簡一點嗎？」，也刪掉，因為它什麼都沒要求。這一段是錯的。它漏掉了第二個方案的成本，星期四就要做決定，而作者是你每週都會一起工作的人。你試的每一個版本，不是讀起來像指控，就是輕到什麼都不會改變。

我是 Subtext 的共同創辦人，這是一款會讀你的草稿、標出可能讓人讀了不舒服的字詞的 App，所以我有利害關係，也希望你用它，而這裡的內容都不是人資或法律建議。這篇談的是同事之間的書面批評，不論是聊天、電子郵件、文件留言或程式碼審查，不是主管的績效考核。往下看，Subtext 讀一則談交接文件過於簡略的訊息，我會列出它回傳的兩個標籤和提供的三個版本。

回饋可以是對的，卻仍然讀起來像攻擊。研究指向的方向是：把評論對準工作，而不是對準人；給讀的人一件他們可以採取行動的事；不要假設他們寧可不知道。研究並不支持任何一套固定的說法，而我找到的、最接近同事之間書面批評的研究，用的是想像出來的程式碼審查留言¹。想直接跳到措辭，請看四件要做的事和五則訊息。

為什麼書面的批評讀起來特別苛刻？

依我的閱讀，一則批評聽起來有多苛刻，除了問題本身有多嚴重，很大一部分也取決於它是怎麼寫成的。研究提供了一個堪用的定義。Robert Baron 在 1988 年的論文裡，把批評分成建設性的和破壞性的：具體、體貼，而且不把不好的表現歸因於內在原因（我的理解是，指的是人本身的某些特質，而不是情境），就是建設性的；違反這些規則的，就是破壞性的²。

在他的第一項研究裡，83 位大學生拿到對自己作品的建設性或破壞性批評，拿到破壞性批評的人回報了更多的憤怒和緊張，並且表示未來在意見不合時，比較可能抗拒或躲避那位批評者。在第二項研究裡，106 位大學生當中，收到破壞性批評的人，在之後兩項任務裡設定的目標比較低，自我效能也比收到建設性批評或沒收到批評的人來得低²。這些是實驗室裡的學生，所以它們說明的是批評可能造成什麼，不是同事在收到一封苛刻的電子郵件之後會怎麼做，而且摘要並沒有報告對任務表現的影響，所以我不會宣稱有。

批評有幫助，還是常常適得其反？

回饋平均而言有幫助，但並非每一次都有。Kluger 和 DeNisi 在 1996 年針對回饋與表現做的統合分析，合併了 23,663 筆觀察中的 607 個效果量。平均而言，回饋讓表現提升了大約 0.4 個標準差（d = .41），但超過三分之一的介入降低了表現，而這既不能用樣本的隨機變異來解釋，也不能用回饋是正面還是負面來解釋³。我不會把它解讀成你的電子郵件有三分之一的機率適得其反。這些研究混合了不同的任務和情境，沒有一項是現代的職場聊天。

作者的解釋是，回饋改變了注意力放在哪裡。在他們跨研究的比較中，當注意力從任務轉向個人時，回饋的效果就變差³。這是我找到的、最強的研究依據，支持那個大家耳熟能詳的建議：針對工作，不針對人。要把它套用到同事的一則訊息上，仍然是一種推論，因為那是跨研究的比較，不是只在某一個特徵上有差別的訊息之間的比較。

後來有一項教育領域的統合分析，涵蓋 435 項研究、超過 61,000 位學習者，發現高資訊量的回饋，也就是糾正式回饋再加上學習者如何調節自己學習的資訊，平均效果最大（d = 0.99），相較之下，單純糾正式回饋（指出對錯和正確答案）是 0.46，單純獎勵或懲罰是 0.24⁴。這些類別是從研究摘要編碼出來的，而且比較的是跨研究的學生，不是同事。我會得出的推論只是一個寬鬆的推論：有可用資訊的評論，勝過一句定論。「總計那一列還包含已取消的訂單」讓讀的人知道該看哪裡。「總計要更仔細一點」就沒有。

對方真的想聽嗎？

一個可能的忍住不說的理由，是相信對方寧可不知道。Abi-Esber 和同事做了五項實驗，共 1,984 位參與者。給回饋的人往往低估了接收者有多想要建設性的回饋，不論是在假設的職場情境、回想的經驗，或是朋友、室友、情侶之間的即時回饋裡⁵。

這些實驗裡的回饋是建設性的，意思是具體、可執行，而且是為對方好才給的，談的是接收者不知道、但改得了的問題。大部分的證據是預測和回想，書面回饋沒有被測試過。所以它並不表示每一位同事都歡迎那種沒被徵求過的、有爭議的、或是很難改的批評，而接收者拒絕不正確、越界或不公平的批評，也是合理的。我把這個發現當成一個檢驗：換作是我，我會想知道嗎？它正確嗎？對方改得了嗎？

Abi-Esber 那篇論文的四位作者之一 Francesca Gino，被哈佛認定在另外四篇論文中有研究不當行為，她否認這項認定⁵。Crossref、OpenAlex 和 PubMed 都沒有列出這篇論文的更正、撤稿或關注聲明⁵。

這件事該不該由你來說，又該不該用寫的？

在談任何措辭之前，有兩個問題。第一個是關於你有沒有立場說。你所依賴的工作出了問題，而且是對照你們雙方都同意的標準來衡量的，這就是你可以提出來的。至於某個人整體表現的模式，或是他適不適合這份工作，我會留給管理他的人。如果主要只是你會用不同的做法，就說那是偏好。

第二個問題是要不要用寫的。關於書寫與談話的比較，最接近的證據談的是別的事情。寫的人高估了自己的語氣在電子郵件裡傳達得有多清楚，那是用學生和被指定語氣做的實驗⁶。在一個有爭議的話題上，大多是陌生人和大學生的參與者，用說的比用寫的，達成了更多的理解、也更少衝突，不過在另一個樣本中，多數人說他們寧可用寫的⁷。人們預期和老朋友通電話，會比寄電子郵件更尷尬，但實際上並不會⁸。這些都不是對某人工作的批評，也沒有一項顯示打電話比留言更好。關於在 Slack 上把話說得明確又不失禮的那一篇談了第一項研究，關於用訊息取消約定又不顯得愛放鴿子的那一篇談了第三項。

我自己的工作規則是：事實和你想要的改變都清楚的時候，用寫的；當事情有爭議、反覆發生，或可能引來一連串反駁的時候，先談，再把談定的內容寫下來。書寫讓你可以修改，讓對方可以按自己的步調回覆，也留下紀錄。如果你不知道對方偏好哪一種，就問。

訊息該說什麼，又該刪掉什麼？

一則書面批評有四件事要做，我會照這個順序來做。這是我自己的工作架構，建立在 Baron 的三條規則、上面談的注意力發現，以及下面的實務指引之上。

1. 具體的那件事。 指出文件、段落、事件，或是雙方同意的交付項目，以及它和約定的標準差在哪裡。把你觀察到的和你推論的分開。「總計那一列包含已取消的訂單」是觀察到的，「粗心」是推論的。
2. 它造成了什麼。 說出它對工作改變了什麼，從你自己這一邊說，不要宣稱大家都同意，例如「所以我沒辦法完成摘要」。
3. 一個請求。 一個對方做得到的改變，只有在真的有依賴關係時才附上時間。說清楚哪些是必須的、哪些是你的偏好，就像 Google 公開的程式碼審查指引，用 Nit、Optional 和 FYI 這類標籤來區分⁹，不過那是實務指引，不是試驗。具體不等於鉅細靡遺，所以先講最重要的改變，其餘的加上標示。在聊天裡，只傳一則訊息；在電子郵件裡，把請求放在前面，並寫一個清楚的主旨。
4. 留一扇門，以及一個你真心要給的提議。 在你可能缺少背景的地方，問一個真正的問題，不要把要求藏在一個假問題裡。只有在你會做的時候，才提議幫忙檢視或打一通電話。

針對第四頁的那則留言，可以這樣寫：「這一段沒有寫出第二個方案的成本，而星期四的決定要靠它。可以在那之前補上一個大概的數字嗎？如果其他地方已經有，是我漏看了，請告訴我在哪裡。」

然後是刪。刪掉形容他們而不是形容工作的字眼，例如粗心、懶惰、「你總是」、當成指控來用的「又」，還有「顯然」。刪掉反問、「還沒到位」這類模糊的定論、諷刺、用來緩和抱怨的笑臉、和點名同事的比較，以及關於大家怎麼想的說法。Baron 的定義只涵蓋模糊的、不體貼的和針對個人的，所以那份清單的其餘部分是我加的，而關於笑臉，那幾項表情符號的研究的結論方向不一。我不會把直接或簡短放進清單。

在傳出去之前，想想一位合理的讀者，能不能找到問題、理解標準、不必猜就知道該怎麼做，還有在你的描述有誤時能不能指正。我會用這個檢驗，來取代數你用了幾個客氣的字。

三明治、SBI、Radical Candor 和 NVC 有用嗎？

三明治式回饋，也就是先稱讚、再批評、再稱讚，有三篇論文，方向各不相同。在兩項針對醫學系三年級學生書面同儕回饋的研究（20 人和 350 人）裡，學生相信三明治對自己之後的表現有幫助，卻沒有證據顯示真的有幫助¹⁰。在一項有 91 位大學生的隨機實驗裡，夾在兩句一般正面陳述之間的更正，之後解出的數學題比只有更正的多，不過作者稱之為部分證據¹¹。在一項八位大學生做模擬辦公室任務的研究裡，每個人都試過每一種順序，平均而言，三明治並不是最有效的¹²。所以它既沒有被推翻，也沒有被證明有效。我的看法是，只稱讚真實、具體而且相關的事，因為唯一的功用是緩衝的稱讚，只會增加長度，還讓人開始猜接下來是什麼。

SBI、Radical Candor 和 NVC 是實務工作者的架構：情境（Situation）、行為（Behavior）、影響（Impact）；Kim Scott 把「個人層面的關心」和「直接的挑戰」配成一對的主張；以及非暴力溝通（Nonviolent Communication）。販售 SBI 訓練的 Center for Creative Leadership 稱它有研究基礎，但我讀到的那一頁並沒有顯示任何成效研究¹³。Radical Candor 的廠商頁面，同樣沒有引用這套架構的任何成效研究¹⁴。一項 2026 年 11 月 5 日發表、回顧 31 項 NVC 訓練研究的文獻，把證據的確定性評為極低到中等，發現大多數研究缺少適當的對照、且仰賴自陳，並認為這個模式比一般認為 NVC 能改善社交功能的假設來得有限¹⁵。其中許多是在監獄和醫院這類場域測試的訓練課程。

五則訊息，修改前與修改後

這五則是為這篇文章編的，沒有一則是標準答案。每一則都是其中一種走法。每個修改後，只用它的情境和它的修改前所給的事實，再加上一個請求，而請求是我的。

一份過於簡略的交接。 Owen 的交接文件缺少 staging 的登入資訊和未解決的 bug 清單，而你大部分內容都是自己拼湊出來的。

修改前 「謝謝你的交接文件，Owen。有點簡單耶 😅 大部分內容我都是自己拼湊出來的。下次可以加上 staging 的登入資訊和未解決的 bug 清單嗎？沒事啦，不用在意。」

修改後 「謝謝你的交接文件，Owen。裡面沒有 staging 的登入資訊和未解決的 bug 清單，所以大部分內容我是自己拼湊出來的。下次交接可以把這兩項補上嗎？如果它們放在我沒找到的地方，請告訴我在哪裡。」

「有點簡單耶 😅」是一句帶著笑臉的定論，而「沒事啦，不用在意」又把抱怨收了回去。修改後的版本指出兩樣缺少的東西，保留你說的代價，請對方補上，並且留下空間，以防它們其實放在別的地方。

一個讓你付出代價的截止日。 Callum 的測試報告星期一到期，星期三才交，所以發布從星期三延到了星期五。這是本季第二次，而 QA 需要在發布前兩天拿到報告。

修改前 「測試報告星期一就到期了。這是第二次。如果再遲交，我就要找你的主管談。」

修改後 「Callum，測試報告星期一到期，星期三才交，所以發布從星期三延到了星期五。QA 需要在發布前兩天拿到，所以我需要下一份也那麼早交。如果有什麼卡住了，現在就告訴我。」

日期和後果都留著。「第二次」是在一個談某一份報告的請求裡計分，所以拿掉；如果這個模式是真的，它應該另外談，就像下面的 Tobias 那樣。威脅也拿掉，因為我不會做一個自己可能不會執行的威脅。

一份沒說到重點的初稿。 Ingrid 的新人訓練指南草稿，開頭是公司歷史，漏掉了第一週。工具那一節寫得很清楚。你認為新人需要知道第一天要做什麼、有問題該問誰。

修改前 「很喜歡這股熱情。只需要稍微整理一下，就可以發出去了。」

修改後 「謝謝你交的草稿，Ingrid。工具那一節寫得很清楚。缺少的是第一週。我覺得新人需要知道第一天要做什麼、有問題該問誰，而這份指南是從公司歷史開始的。可以把第一週放到最前面，再把歷史移到後面嗎？」

這則看起來無害，而我認為它是五則裡風險最大的，因為「稍微整理一下」說的是草稿幾乎完成了，之後重新調整結構的要求，就可能突然冒出來。

會議裡的一個習慣。 連續三場規劃會議，Tobias 都重新翻開團隊在十月做的廠商決定，占用了團隊本來要談衝刺的時間。你正準備貼到團隊頻道。

修改前 「看來這裡從來沒有什麼事是真的決定了 🙃」

修改後 （以私訊傳送）「嗨 Tobias，最近三場規劃會議，我們都回頭討論十月已經定下來的廠商選擇，占掉了原本要談衝刺的時間。如果有新資訊，可以在會議前先傳給我，讓我們看看它會不會改變什麼嗎？」

修改前的版本貼給整個頻道，所以每個人都挨了這一下，而「從來沒有什麼事是真的決定了」是沒有人能查證的說法。修改後的版本只傳給 Tobias，數出有幾場會議，並請他做一個改變。針對一個習慣，我會先談，再把這則訊息當成紀錄傳出去。

一則審查留言。 Farah 的修改在清單為空時會當掉，因為迴圈沒有先檢查就讀取了第一項。這個一定要改，另外你也覺得有一個變數名稱 tmp 很難讀。

修改前 「為什麼這裡沒有檢查清單是不是空的？這是基本常識吧。」

修改後 「合併前必改：清單為空時這裡會當掉，因為迴圈沒有先檢查就讀取了第一項。可以加上空清單的檢查嗎？或者如果呼叫端已經排除了這種情況，請告訴我。Nit，非必要：tmp 這個名稱不太好讀。」

「這是基本常識吧」是在評斷 Farah，而那個問句要的，是一個沒有人想給的答案。修改後的版本標出哪些是必要的、哪些是非必要的，就像 Google 的指引那樣，評論的是程式碼，不是開發者⁹。

會隨資歷、文化或對方是誰而改變嗎？

職稱相同，不代表影響力相同。資深工程師可能掌握核准權，而資歷較淺的同事，可能很難對截止日提出異議。所以要說明這個請求帶有多大的權限：是發布的阻擋條件、團隊已經約定的要求，還是你的偏好，並且不要讓一個可有可無的建議，聽起來像命令。關於在 Slack 上把話說得明確又不失禮的那一篇談了寄件者的角色會怎麼改變訊息的讀法，哪些已知、哪些未知。

文化是一個提醒你去問的線索。Erin Meyer 為 INSEAD 撰文，描述直接的文化會用「絕對」這類字眼加強批評，而間接的文化則用「有點」這類字眼來軟化¹⁶。那是實務經驗，沒有測量過的樣本，而且描述的只是傾向。去問問你的團隊是怎麼處理更正的。

在某些資料裡，性別會顯現在人們收到什麼樣的回饋上。在英國一個公部門機構 4,328 位高階主管的 360 度評量中，女性收到的、關於優點的回饋比男性更具體，關於該發展的方面則比男性不具體。那份報告沒有經過同儕審查，而且其中的性別差異是觀察性的¹⁷。我把它解讀成一個理由，讓你檢查自己是否給了每個人同樣的具體內容，而不是把任何人當成易碎品。

神經多樣性不是單一一種溝通風格。一項彙整 34 篇談自閉症成人工作生活文章的綜合研究發現，回饋有時很難理解、也沒什麼用，而明確的期望則有幫助¹⁸。它不涵蓋 ADHD、閱讀障礙或其他狀況，所以要問。AuDHD 那一篇談了管道方面的證據。

如果對方防衛心很重，或根本不回呢？

防衛性的回覆，仍然是一個回覆。我會先檢查，底下有沒有事實上的分歧。「我可能漏掉了背景。時間軸的哪個部分，你的看法不一樣？」這樣問，既問了這件事，又沒有放棄那項要求。如果對方在某件事上是對的，就說出來，然後只重申一次共同的要求。如果你的第一則訊息裡有不公平的概括，就直接修補那一部分，怎麼用訊息道歉談了這一點。然後不要再追加書面的反駁，改成提議通話，或是一份簡短的書面議程。

沉默本身並不表示同意、敵意或拒絕。在工作所在的管道上，傳一則簡短的追問，說出它卡住了哪個決定，除此之外，就依你們團隊平常的回覆時間來等。

當問題牽涉到優先順序、歸屬、反覆沒有遵守的約定，或是你們身為平行同事無法解決的資源，就把能做決定的人找進來，附上事實、對工作的影響，以及你需要的決定。我會先告訴你的同事，除非牽涉到騷擾、安全或歧視，而且我會從你雇主自己的政策開始。

這串訊息裡不該有的，是對某人健康或動機的猜測、關於其他同事的機密資訊、你做不到或不打算執行的威脅，或是你沒有查證過的、關於團體怎麼想的說法。騷擾、歧視、報復或嚴重不當行為的指控，應該交給你雇主的通報程序。如果那個人讓你害怕，或威脅你，這就不再是措辭的問題。如果你正處於立即的危險中，請撥打你所在地的緊急電話。也請不要把那段對話放進 Subtext，或任何其他 AI 工具。

工具什麼時候有幫助

Subtext 是一個 AI 工具，所以最接近的證據，是關於 AI 協助寫訊息的研究，AI 訊息改寫工具真的有用嗎？談了這個。我沒有找到任何獨立研究，顯示 Subtext 或任何 AI 改寫工具，能改善同事回饋被接收的方式、公平程度，或是工作關係的走向。

有兩個習慣不花任何成本。私下把未經修飾的版本寫出來，再把每一個評斷，換成發生了什麼事、你要改變什麼。然後把它大聲念出來，用最苛刻的那位讀者會聽到的方式，這則訊息聽起來很無禮嗎？從最接近的受測形式談了這一點。

Subtext 會讀你寫的回饋草稿，標出可能讀起來像攻擊的字詞、「總是」或「從不」的評斷、居高臨下的口氣，或是用「應該」或「必須」強加的規定，每一個都附上一句簡短的理由。它用一個詞說出草稿裡的感受，並提供最多三個版本，其中一個貼近你的措辭，每個版本都標上「可放心傳送」或「再確認一下」，對於從你的草稿改寫而成的版本，還會估計它改動了你多少措辭。「可放心傳送」的標示，是 Subtext 憑眼前這些字詞做的估計，而「再確認一下」，是把那個版本再讀一遍的理由，不是出問題的證明。它不會傳送任何東西，所以你要自己複製想要的版本再傳出去。

Subtext 沒辦法判斷你的批評是否公平或正確，沒辦法告訴你同事是什麼意思（它的常見問題也這麼說），也沒辦法告訴你他們會怎麼看待。除了你給它的文字，以及你存在「記憶」裡的備註之外，它不知道你們之間的過往，或你們團隊的規範。依照指示寫出來的版本，例如要求更短或更溫暖，會偏向溫暖、平實和簡短，所以一則必須保持堅定的訊息，需要你再讀一遍，看它刪掉了什麼。它是寫作助理，不是心理治療、調解，或人資流程。

上面那份過於簡略的交接，是為了這次實測編的，拿去跑了一次 Subtext。草稿是這樣寫的：「謝謝你的交接文件，Owen。有點簡單耶 😅 大部分內容我都是自己拼湊出來的。下次可以加上 staging 的登入資訊和未解決的 bug 清單嗎？沒事啦，不用在意。」Subtext 把其中的感受命名為「失望」，並回傳兩個標籤。「訊息矛盾」標在最後一句「沒事啦，不用在意」上，理由是前面提出具體請求，最後卻把它收回，「讓對方不確定到底要不要補」。「被動攻擊」標在「有點簡單耶 😅」加上「不用在意」，註明它「可能被讀成委婉的不滿」。

三個版本全都標為「可放心傳送」。第一個「貼近原意」拿掉了「不用在意」，也就是 Subtext 剛標出來的那一句，並把請求寫成一個問句，還加了一句你原本沒寫的理由「這樣我會更好上手」，不過它把你的「大部分內容」改成「有些部分」，也留著「內容比較簡單」這個溫和的評斷。第二個「更溫暖」同樣把「大部分」改成「有些細節」，這讓草稿變柔和了，並先說「我已經拿到重點了」；它不是問句，而是「想請你下次如果方便，補上」，它的說明稱這樣「語氣柔和且不收回請求」，那是依文字做的估計，不是對 Owen 的了解。第三個「簡短直接」保留了你付出的代價，「我這次是自己補齊的」，只是把你的拼湊說成補齊，請求也是直接的「下次麻煩加上」，不是問句；它的說明稱它「簡短且重點明確」。三個版本都沒有提議檢視，或問對方是不是有你不知道的背景，所以第四件事，留一扇門和一個提議，仍然是你的工作。Subtext 自己的結語是：「我把『沒事啦，不用在意』拿掉了，因為它會讓請求變得不確定。想要更短或更溫暖嗎？」底下還有三個可以點的選項：「更短」、「更溫暖」和「更隨性」。以上是 App 實際的輸出，沒有經過修改。

在瀏覽器試用 Subtext在 App Store 下載在 Google Play 下載下載 App

用任何工具時，都請要求它保留事實、要求和截止日，不要加任何稱讚、承諾或道歉，然後把它回傳的內容和你的原稿比對，因為改寫可能在磨掉稜角的同時，也把一個事實軟化了，就像上面第二個版本那樣。

該把什麼貼進 Subtext 或任何 AI 工具？

貼進 Subtext 或任何其他 AI 工具的回饋草稿，可能含有機密的商業資訊，以及關於一個從來沒選擇這項服務的人的細節，而把名字拿掉，並不會移除每一個可辨識的細節。請先查你雇主的政策和你的合約，有核准的工具和帳號就用核准的，只貼你自己的回饋，用角色取代姓名，並且不要放進任務用不到的客戶名稱、數字或對話串歷史。和對方的健康、金錢或私生活有關的內容，一律不要放進去。

Subtext 的條款請你確認，你有權提交別人說的話，而且如果你是為了工作使用，你被允許這麼做。它的隱私權政策表示，你傳送的任何內容，Subtext 或它的供應商都不會拿來訓練 AI 模型，而你的文字會傳給它點名的 AI 供應商。一段對話會在你最後一次使用的五天後自動刪除，釘選的話則是 90 天，你也可以立刻刪除某一段對話¹⁹。存進「記憶」的備註會一直留著，直到你刪除。哪些 AI 寫作助理會拿你的訊息訓練模型有針對其他工具的完整版本。

大家常問的問題

怎麼在電子郵件裡有禮貌地批評同事的工作？ 指出具體的那件事，說出它造成了什麼，請對方做一個改變，並且為你不知道的部分留下空間。這裡的有禮貌，意思是精確而且尊重。多餘的鋪陳，兩者都不增加。

用 Slack 或電子郵件給批評性的回饋，到底可以嗎？ 可以，只要事實和你想要的改變都很清楚。當事情有爭議、反覆發生，或可能引來一連串反駁時，先談。

我該先稱讚一下嗎？ 只有在那句稱讚是真的、而且是關於工作的時候。三明治式回饋有三篇論文，指向不同的方向，而依我的看法，唯一的功用是緩衝批評的稱讚，只會增加長度，還讓人開始猜接下來是什麼。

傳出去之前，該等多久？ 我沒有找到任何研究給出一個時間間隔。如果你要停一下，我會利用這段時間，把每一個評斷換成發生了什麼事、你要改變什麼，並在更正變得不再重要之前傳出去。

依什麼順序做

先決定這是不是你該說的，以及用寫的是不是對的方式。如果事情有爭議、反覆發生，或可能引來一連串反駁，就先談。如果你要寫，就指出具體的那件事，說出它造成了什麼，請對方做一個改變，並且為你不知道的部分留下空間。

如果對方的回覆帶著防衛，先檢查有沒有事實上的分歧，修補你做錯的部分，然後只重申一次要求。如果什麼都沒有回來，就傳一則簡短的追問。如果牽涉到騷擾、歧視，或是讓你害怕的事，它就不再是措辭的問題。

寫出最小的那則訊息：點出工作、說出它造成了什麼、請對方做一個改變。然後傳出去。

資料來源

依文中出現的順序編號。如果某個數字無法對照原始來源查證，內文會直接說明。查證日期為 2026 年 11 月 6 日。

1. Gunawardena, S. D., Devine, P., Beaumont, I., Garden, L. P., Murphy-Hill, E., and Blincoe, K. (2022). Destructive Criticism in Software Code Review Impacts Inclusion. Proceedings of the ACM on Human-Computer Interaction, 6(CSCW2), 1 to 29. 針對 93 位軟體從業人員，對假設的建設性或破壞性程式碼審查留言的反應所做的調查；情境題和自陳。
2. Baron, R. A. (1988). Negative Effects of Destructive Criticism: Impact on Conflict, Self-Efficacy, and Task Performance. Journal of Applied Psychology, 73(2), 199 to 207. 三項研究：83 位大學生、106 位大學生，以及對一家食品加工公司 108 位員工的調查；實驗室操弄和自陳。
3. Kluger, A. N., and DeNisi, A. (1996). The Effects of Feedback Interventions on Performance: A Historical Review, a Meta-Analysis, and a Preliminary Feedback Intervention Theory. Psychological Bulletin, 119(2), 254 to 284. 607 個效果量（23,663 筆觀察）的統合分析：回饋平均而言改善了表現（d = .41），但超過三分之一的介入降低了表現。任務和情境混雜，沒有一項是現代的職場聊天；全文無法開啟，所以實驗室與現場研究的比例不明。
4. Wisniewski, B., Zierer, K., and Hattie, J. (2020). The Power of Feedback Revisited: A Meta-Analysis of Educational Feedback Research. Frontiers in Psychology, 10, article 3087. 435 項研究、994 個效果、超過 61,000 位學習者的統合分析，去除極端值後平均 d = 0.48；回饋類型是依原始研究的摘要編碼；對象是學生，不是同事。
5. Abi-Esber, N., Abel, J. E., Schroeder, J., and Gino, F. (2022). “Just Letting You Know …” Underestimating Others’ Desire for Constructive Feedback. Journal of Personality and Social Psychology, 123(6), 1362 to 1385. 五項實驗（N = 1,984）和一項校園前導研究：假設的職場情境、回想的經驗、朋友、室友或伴侶之間的即時回饋，以及一場與學生進行的演講比賽。關於共同作者 Francesca Gino 的紀錄，查證日期為 2026 年 11 月 6 日：哈佛對另外四篇論文做出研究不當行為的認定，以及她的否認，見 2024 年 3 月 15 日的 Harvard Crimson 報導。四份撤稿聲明可在 Crossref 查到，分別在 PNAS、Psychological Science、Psychological Science 和 Journal of Personality and Social Psychology。在 Crossref、OpenAlex 或 PubMed 上，這篇論文都沒有附上更正、撤稿或關注聲明，而期刊自己的頁面無法開啟。
6. Kruger, J., Epley, N., Parker, J., and Ng, Z.-W. (2005). Egocentrism Over E-Mail: Can We Communicate as Well as We Think? Journal of Personality and Social Psychology, 89(6), 925 to 936. 五項實驗，對象是美國大學生，用電子郵件；被指定的語氣，不是職場批評。
7. Bevis, B., Schroeder, J., and Yeomans, M. (2026). Spoken Disagreement Is More Constructive Than Written Disagreement. Nature Communications, 17, article 5792. 有 1,576 位對話夥伴和 1,432 位觀察者的隨機實驗，大多是陌生人和大學生，就有爭議的話題表達不同意見，不是對工作的批評；開放取用。
8. Kumar, A., and Epley, N. (2021). It’s Surprisingly Nice to Hear You: Misunderstanding the Impact of Communication Media Can Lead to Suboptimal Choices of How to Connect With Others. Journal of Experimental Psychology: General, 150(3), 595 to 607. 一項現場實驗，請 200 位 University of Chicago 的學生，用電話或電子郵件與老朋友重新聯絡（103 人完成追蹤），以及一些實驗室實驗，讓人們與陌生人透過視訊、語音或文字聊天。談的是重新聯絡和認識彼此，不是批評。
9. Google Engineering Practices. How to Write Code Review Comments. 實務指引，無標示日期，2026 年 11 月 6 日閱讀；不是對照研究。
10. Parkes, J., Abercrombie, S., and McCarty, T. (2013). Feedback Sandwiches Affect Perceptions but Not Performance. Advances in Health Sciences Education, 18(3), 397 to 407. 兩項研究（N = 20 和 N = 350），對象是撰寫病歷的醫學系三年級學生之間的書面同儕回饋；學生認為三明治對之後的表現有幫助，沒有證據顯示真的有。
11. Prochazka, J., Ovcari, M., and Durinik, M. (2020). Sandwich Feedback: The Empirical Evidence of Its Effectiveness. Learning and Motivation, 71, article 101649. 有 91 位大學生解數學題的隨機實驗；三明治組準備的時間較長，第二組題目也解出較多；稱讚是一般性的，和表現無關，作者稱這項證據為部分證據。
12. Henley, A. J., and DiGennaro Reed, F. D. (2015). Should You Order the Feedback Sandwich? Efficacy of Feedback Sequence and Timing. Journal of Organizational Behavior Management, 35(3-4), 321 to 335. 八位大學生（七位女性、一位男性）做模擬辦公室任務，每個人都經歷全部四種條件（三種回饋順序和沒有回饋），一半在每次作業之前給口頭回饋，另一半在之後給；三明治不是最有效的順序。樣本數已對照全文確認。
13. Center for Creative Leadership (2025). Use Situation-Behavior-Impact (SBI)™ To Understand Intent. 實務文章，2025 年 8 月 19 日；它稱這個方法有研究基礎，但沒有呈現這個方法本身的任何成效研究。
14. Radical Candor, LLC. Our Approach: Kim Scott’s Feedback Framework. 一家商業培訓公司的廠商頁面，2026 年 11 月 6 日閱讀；沒有引用這套架構本身的任何成效研究。
15. Lazzari, G., Jean, B. R., de la Sablonnière, R., and van Vugt, F. T. (2026). A Systematic Review of Quantitative Studies Testing Nonviolent Communication Training Interventions. Frontiers in Psychology, 17, article 1800455. 31 項研究；證據確定性評為極低到中等；大多缺少適當的對照或隨機分派，且仰賴自陳；2026 年 11 月 5 日在線上發表。
16. Meyer, E. (2015). Giving Negative Feedback Across Cultures. INSEAD Knowledge, 16 September 2015. 實務文章，取材自作者的教學、顧問工作和軼事；沒有測量過的樣本。
17. Burd, H., Bremner, G., Schein, A., and Rudzeviciute, M. (2021). Gender Bias and Performance Feedback: An RCT. Behavioural Insights Team research report, June 2021. 英國一個公部門機構 4,328 位高階主管的 360 度評量；被隨機分派到不同指示的是評量者，不是被評量的人；沒有經過同儕審查。
18. Thorpe, D., McKinlay, M., Richards, J., Sang, K., and Stewart, M. E. (2024). The Lived Experience of Autistic Adults in Employment: A Systematic Search and Synthesis. Autism in Adulthood, 6(4), 495 to 509. 對 34 篇文章的質性綜合；沒有經費，也沒有聲明利益衝突；它涵蓋的是自閉症工作者的敘述，不包括其他神經多樣性。
19. Subtext. Terms and privacy. 隱私權政策和條款最後更新於 2026 年 10 月 22 日。第一方來源。