這篇文章被討論於 Hacker News 和 Lobsters

Gabriela Seabra 回應了這篇文章

[2026-03-16 Mon 03:09] 由於這可能被誤解為無禮的藉口，因此有必要澄清。直接並不等於無禮，而且這種溝通方式假設雙方之間已經建立了關係。事實上，我在文章中也強調了這一點，說不直接添加不必要的客套話，就意味著你不信任這段關係能夠保持直接。在與新人打交道，或者我試圖讓某人感到自在地與我合作時，我會努力做到盡可能遷就，對他們友善，我建議大家也這麼做。我還應該指出，這嚴格適用於基於文字的溝通。文字應該是最佳化、可搜尋且可追溯的，我希望它也能是直接的。口頭和面對面的互動是完全不同的事情，應該保持友善和人道。最後，我確實真誠地欣賞專業場合中的直接性，但在那之外的場合，我來自一個禮貌不僅受到讚賞而且是預期的文化，我無意將其拋諸腦後。

有一個概念叫做 Crocker 原則，如果你從未聽說過，簡而言之就是：你明確允許周圍的人對你極度直接，省略社交潤飾。引用 Crocker 原則的人實際上是在說：「你對我可能如何接收這條訊息的感受是你自己的問題，而不是我的，請直接給我資訊。」

因此，接收訊息的人要對其內容的情感反應負責。如果有人告訴你你的程式碼有問題，你對此的情感反應是你自己的問題，而不是他們需要預先消除的。這不是逃避殘酷的藉口，也不是侮辱人的邀請，這只是一個雙方都同意的協議，即雙方都在這裡有效率地交換資訊，任何一方都不會花費精力在對零訊號的社交表演上。

在實踐中，這意味著你的同事可以寫「這種方法是錯的，原因如下」而不是「嘿，希望你一切都好，我花了一些時間看了你的 PR，我只想分享一些小想法，請將這些僅視為一種觀點，當然你比我更了解程式碼庫，但我想知道我們是否可以考慮 [這裡有用的東西]」，然後將真正的重點埋在六段之後。兩條訊息包含相同資訊，但其中一條尊重了時間。

Slack 訊息以「嘿！希望你週末愉快 :)」開頭。在提出技術問題之前，請參閱 nohello.com，或者 PR 評論以「我不確定我是否遺漏了什麼，如果這是個愚蠢的問題，我很抱歉，但」開頭，然後提出一個完全有效擔憂，或者那段事件文字花費了整整兩段來解釋作者睡眠不足，有很多事情要做，監控工具出現了一個奇怪的怪癖，他們不知道，他們的領導三週前告訴他們一些模糊的事情，最後才說到底出了什麼問題以及為什麼。這完全是專業的反面，有時我認為這是焦慮在偽裝成禮貌。

我個人重視直接性，所以當有人以這種方式與我溝通時，這確實會影響我對他們的看法，即使是潛意識的。我還認為，這種效應發生在大多數人身上，包括那些不關心 Crocker 原則或不特別在意的人：

當你花費訊息的前三分之一來證明你是一個好人，並且出於好意時，你並不是在體貼，而是在讓接收者費力地瀏覽噪音來獲取訊號。你正在訓練他們略讀你的訊息，這意味著當你實際上需要他們仔細閱讀時，他們可能不會。你正在表明你不信任這段關係，不足以直接說出你想說的話，並且你正在發出一個不安全感層級的信號，這會損害你試圖建立的技術信譽。沒有人會讀「希望你週末愉快」並認為寫這句話的人更好，他們可能只是被訓練成將來對你更不認真，或者更糟的是，如果他們像我一樣是邪惡的 Crocker 原則愛好者，他們只會想到他們生命中那幾秒鐘再也回不來了。

另一種我認為與那種嘈雜的客套話高度相關的行為，我認為實際上更糟的是預先道歉，這是當事情出錯或需要解釋決定時，某人不僅解釋了決定；他們解釋了為什麼做出這個決定，然後解釋了影響該決定的背景因素，然後解釋了為什麼存在這些背景因素，然後解釋了為什麼期望他們預見這些因素的下游影響是不合理的，到最後你得到了一些肥胖的五段文字，其中可能只有一句話的資訊，讀起來像是一個知道自己有罪的人寫的法律辯護狀。

請不要這樣做。如果支付服務因為一個配置值錯誤而中斷，事件報告應該這樣說：支付服務中斷是因為配置值 X 被設置為 Y，而它應該是 Z。

你很緊張，或者你繼承了這個配置，或者文件不清楚。這是一個結構性因素的良好候選。或者你問了你的領導，他說可能沒問題，這些都與事件報告無關。你可以記錄促成因素，如果它們確實是可操作的，也就是說，如果有些結構性問題需要改變，請具體說明並附上建議的修復方案。但是，承認你的情緒狀態、你的推理過程和你的情有可原的理由不是文件記錄，而是自我寬恕，所有閱讀它的人都能分辨出區別。

更重要的是：這浪費了他們的時間，並且掩蓋了他們實際需要採取行動的資訊。

「我希望這沒關係提出來，很抱歉訊息很長，我只是想提醒一下，我一直在關注延遲數字，我不太確定，但似乎緩存層可能存在問題？」

「緩存層在冷請求時會導致 400 毫秒的開銷。這是追蹤記錄。」

第二條訊息更有用，閱讀速度更快，而且實際上對所有相關人員都更尊重。

「我知道這可能不是說這個的正確地方，我完全理解如果你不同意，但我認為目前錯誤處理的方法可能有一些潛在的缺點？」

「目前的錯誤處理會默默地吞噬異常，這使得調試變得非常困難。我們應該將錯誤傳播給呼叫者。」

第二個人聽起來像個工程師。第一個聽起來像是在徵求意見的許可，在對方說了類似「你能詳細說明一下嗎」之後，他們可能會開始提到靜默異常或其他問題。

如果你是一個初級工程師讀到這篇文章並感到防禦，那麼這種防禦值得審視。週末過得很好。沒人需要知道。寫下訊息。

禮貌有其位置，但我懇請你將清晰放在首位。一個無法容忍對現實的直接陳述的團隊，無法調試任何比錯字更大的問題。如果緩存層很慢，就說它很慢。如果設計是錯誤的，就說它是錯誤的。其餘的都是噪音。

另請參閱：不要為回覆我的電子郵件晚了而道歉。XY 問題。不要問是否可以問，直接問。# 相處之道

事實上，我在文章中也強調了這一點，說不直接添加不必要的客套話，就意味著你不信任這段關係能夠保持直接。

這不是逃避殘酷的藉口，也不是侮辱人的邀請，這只是一個雙方都同意的協議，即雙方都在這裡有效率地交換資訊，任何一方都不會花費精力在對零訊號的社交表演上。

這是一個結構性因素的良好候選。

這裡沒有評論框。寫下你的回覆，它會在你自己的實例上開啟一篇發文，發送給 Saleh 並附上此頁面的連結；或發送一封信。