开发者的 Slack 礼仪不成文规则

Source: Dev.to

（请提供您希望翻译的正文内容，我将为您翻译成简体中文，并保留原始的格式、Markdown 语法以及技术术语。）

不要说“嗨”然后等

这种情况如此常见，以至于甚至有专门的网站： . 然而每天，在全球的 Slack 工作区里：

You: “嗨，你有空吗？”

…然后… 什么也没有。没有上下文。没有问题。只是一条模糊、让人焦虑的消息，放在那里，而对方会放下手头的事等着。

Do this instead: 先提出你的问题，并在前面提供上下文。

You: “嗨！我正在进行 auth‑middleware 重构，遇到了一个奇怪的问题：在 401 响应时 token 刷新会静默失败。我尝试把它包装在重试逻辑里，但会无限循环。你之前见过这种情况吗，或者知道我应该查看哪里？”

现在，对方可以先对请求进行分类，决定何时回复，并在不需要来回五条信息的情况下给出有用的答案。

为你的回复使用线程

线程存在的原因是：让 #backend（或任何频道）不至于看起来像 Twitch 聊天室。

• 当有人发布问题或更新，而你有后续时，请在 线程中 回复。
• 当三个人一起排查问题时，请在线程中进行。
• 当你想分享相关链接或说 “我也是” 时，请在线程中发布。

在繁忙的频道中，未使用线程的对话真的很难跟上。你会滚动浏览 40 条信息，想弄清哪条回复对应哪个问题，而其中一半是两段独立对话交叉进行。就像同时听两个播客一样。

例外： 如果一个线程得出了对整个频道都有用的结论，请在主频道发布简短的摘要。讨论本身？仍然保留在线程中。

@channel 和 @here 是紧急开关，而不是扩音器

以下是一个粗略指南：

如果你使用 @channel 来询问是否有人想一起吃午饭，你会树立一个你不想要的声誉。人们会仔细配置通知，当你因非紧急事务而拉动 @channel 开关时，会让所有人完全忽视这些提醒，导致真正的紧急情况也会被错过。

请使用代码块

Slack 提供了非常好的代码格式化功能：

• 单个反引号用于内联代码：`code`
• 三个反引号用于代码块：

def please_format_your_code():
    your_teammates_will_thank_you = True
    return your_teammates_will_thank_you

当有人粘贴堆栈跟踪或配置文件的纯文本且没有任何格式时，它会变成一个难以阅读的块，缩进丢失，所有内容混在一起。只需多花两秒钟把它包裹在反引号中，就能决定这条信息是人们真正阅读的，还是他们眯着眼睛快速略过的。

如果超过大约 15 行，考虑使用代码片段或 Gist 链接。没有人想在 Slack 消息中滚动浏览 200 行的 JSON。

尊重 DND 和状态信息

当某人的状态显示 🎧 专注中，下午 2 点回来 时，这不是建议——而是界限。如果他们的状态被设为 Do Not Disturb，你的信息并不那么紧急，以至于需要打断他们正在深度专注的工作。可以等一下。几乎总是可以等。

另一方面： 实际使用你自己的状态。如果你正专注于某件事，设为 DND。如果你在吃午饭，就说明。如果你今天已经下班，标记出来。这有助于你的团队校准期望，减少私信中 “嘿，你在吗？” 的杂乱。

“Quick Call?” 信息

这件事很微妙。有时候，同步对话的确比来回 30 条消息更快。复杂的调试、架构讨论，或任何需要语气的场合：一次快速通话可以为大家节省时间。

但没有任何上下文的 “quick call?” 可能会让人感觉像被叫去校长办公室。如果你想发起通话，请给出理由：

“嘿，我在来回讨论如何构建新的事件系统，我觉得 10 分钟的通话可以帮我们省下一个小时的打字时间。你接下来有空吗？”

这很有礼貌。它给对方提供了选择的余地，比如说：“其实我可以直接发给你一张图示，我想那能把问题说明白”，而不是让他们觉得必须立刻放下手头的事去参加通话。

在按回车键之前先组织好你的想法

你一定认识那种发送信息的方式像下面这样的人：

hey
so
I was looking at the PR
and I think
there might be an issue
with the way we handle
the cache invalidation
actually nvm
wait no
yeah there's def a problem

这相当于十条通知，却本该只是一条信息。每一行都会触发一次提醒、徽章或振动。尤其在移动端，这种体验尤为残忍。稍作停…

Emoji Reactions Are Underrated

表情符号反应是 Slack 最能降低噪音的功能之一，但大多数团队并未充分利用它们。一个快速的表情符号就可以替代整条信息：

• 👀 – “我已经看到并正在处理。”
• ✅ – “完成”或“已处理。”
• 👍 – “已确认”或“听起来不错。”
• 🎉 – “恭喜”或“干得好”（而不是在频道里刷出 12 条单独的“恭喜！”信息）。
• ➕ – “我同意”或“我也是。”

当有人发布公告，15 个人各自回复“谢谢！”时，实际信息就被埋没了。一堆 🙏 反应可以传达同样的意思，却不会把频道变成一片单词回复的墙。多使用表情符号反应，看看你的频道会变得多么整洁。

默认使用公共频道

有一种自然的冲动想要私信（DM）别人提问，尤其是当你刚加入团队，觉得自己的问题可能很显而易见时。要克制这种冲动。大多数情况下，你的问题下周会有人也会问，如果在公共频道提问，答案就会被搜索到。

• DM – 适用于真正私密的事项：个人事务、敏感反馈、只涉及你们两人的事情。
• 公共频道 – 适合技术问题、项目进展、“有人知道 X 是怎么工作的吗？”之类的提问——这些应该放在频道里。你不仅是为自己获取帮助，还在为整个团队创建知识库。

例外情况是需要给某人直接反馈或讨论敏感事项时。自行判断，但如果不确定，优先选择公共频道而不是私信。

异步是默认，而非例外

你的跨时区同事在凌晨 3 点（你的时间）提出了一个问题。你不必因为等到早上才回复而感到内疚——他们懂的。这就是分布式团队的运作方式：你在自己方便的时候发送信息，对方在自己方便的时候回复。

这也意味着要编写不需要即时来回的消息才能发挥作用。不要只写 “我能问你一些关于部署的事吗？” 而是把完整的问题和所有上下文一次性写清，这样对方即使在六小时后也能一次性回答。把它想象成一封非常简短、结构良好的电子邮件，而不是对话。

提升异步沟通的技巧

1. 前置提供上下文。
2. 包含相关链接。
3. 让信息自成一体。

这是一项值得培养的技能，你的全球分布式同事会悄悄地因此而更喜欢你。

如何请求帮助（而不是让别人帮你做作业）

提问的艺术同样适用于 Slack 和 Stack Overflow。结构良好的求助请求大致如下：

我想要做的事情：
为支付服务搭建本地开发环境。

出现的情况：
Docker 构建在第 7/12 步因对 /var/run/secrets 的权限错误而失败。

我已经尝试的办法：

• 使用 --privileged 运行
• 清除 Docker 缓存
• 查看 README（最近一次更新于 8 个月前）

我的问题：
是否还有未在文档中说明的 secrets 卷的额外设置步骤，或者这是最新 Docker 版本的已知问题？

与 “支付服务坏了，帮忙？” 相比，前者往往在几分钟内得到有用的答案；后者则会引发长达 20 条信息的审问，只为弄清到底发生了什么。

Source: …

额外内容：最糟糕的 Slack 违规行为

一份并不完整的清单，列出会让你的团队成员深深叹气的行为：

• 在群组频道发送语音消息。 没有人想要戴上耳机去听你那两句话的提问，而这完全可以在 15 秒内打字完成。
• 在有人已经回复后编辑消息。 这时回复就显得毫无意义，大家都会感到困惑。如果需要更正，请另发一条跟进信息。
• 在回复线程的同时勾选“也发送到频道”。 只能选其一。这个复选框是为少数特殊情况准备的，而不是默认选项。
• 在 #random 中使用 @channel。 不行。
• 在活跃的对话中删除消息。 回复仍然存在，漂浮在空中，却引用了一条已消失的“幽灵”消息。
• 把所有事情都标记为紧急。 如果所有事情都是紧急的，那么就没有任何事情是真正紧急的。你就是 Slack 版的狼来了的孩子。

全部归结于同理心

大多数这些“规则”都归结为一个核心理念：在点击 Send 之前，先考虑一下信息接收者的感受。

• 这句话清晰吗？
• 这会打断对方吗？
• 对方是否拥有帮助我的必要信息？
• 我是在让他们的工作日稍微轻松一点，还是更困难一点？

良好的 Slack 礼仪并不是要保持正式或小心翼翼，而是在一个语气不可见、大家已经被通知淹没的环境中，表现出体贴与考虑。