公司中最好的想法和决策都发生在 Slack 里——然后消失在无尽的滚动中。一个月后，没有人能找到那个讨论架构决策的帖子了。以下是将 Slack 内容保存为 Markdown 的方法。

为什么要将 Slack 消息保存为 Markdown？

Slack 是知识的坟墓：

消息滚动消失 — 活跃频道将重要讨论掩埋
搜索有限 — 免费计划只能搜索 90 天的历史记录
帖子很脆弱 — 很容易失去对重要对话的追踪
没有结构化导出 — Slack 的数据导出是 JSON 噩梦
上下文丢失 — 在 Slack 中做出的决策没有在任何地方被文档化

Save 捕获的内容

在浏览器中查看 Slack（app.slack.com）时：

帖子内容

带作者姓名和时间戳的消息
带结构的帖子回复
代码块和行内代码
格式化文本（粗体、斜体、列表）
链接和共享内容
表情回应（以文字形式）

示例输出

# #engineering — 数据库迁移决策

---

## @alice — 2026年3月10日 上午10:15

团队，我们需要决定从 MySQL 迁移到 Postgres 的策略。目前有两个方案：

**方案 A：** 利用周末进行一次性迁移
- 优点：切换干净，无双写复杂性
- 缺点：长时间停机风险，回滚困难

**方案 B：** 通过双写逐步迁移
- 优点：零停机，回滚方便
- 缺点：2-3 周的复杂性，可能存在数据一致性问题

## @bob — 2026年3月10日 上午10:23

强烈支持方案 B。我在上家公司做过一次性迁移，实际耗时是预估的 3 倍。双写的额外开销值得为此换来的安全保障。

## @carol — 2026年3月10日 上午10:31

同意方案 B。我之前设置过双写方案，关键步骤是：

1. 从 MySQL 读取，同时向两个数据库写入
2. 在测试环境添加比对检查
3. 确认无误后切换读取到 Postgres
4. 最后移除 MySQL 写入

时间线：如果周一开始，约 2 周完成。

## @alice — 2026年3月10日 上午10:45

决定：采用方案 B（逐步迁移）。
@carol 负责，从 3 月 14 日周一开始。
追踪任务：LINEAR-4521。

使用场景

决策文档化

保存发生架构决策的帖子
归档推理过程，而不仅仅是结论
从 Slack 讨论构建可搜索的决策日志
将决策与工单和文档关联

知识保留

保存帮助频道中分享的技术解释
归档新成员入职问题的回答
从反复出现的问题中构建 FAQ 文档
在成员离职时保留机构知识

会议跟进

保存会议前的讨论帖子
归档 Slack 同步中的行动项和决策
从异步 Slack 对话构建会议纪要
追踪帖子中提及的承诺和截止日期

项目档案

在里程碑节点保存关键项目讨论
归档复盘帖子
通过分散的讨论记录项目演变历程
从分散的讨论构建项目历史

最佳使用技巧

使用 Web 版 — 在浏览器中打开 app.slack.com
打开完整帖子 — 点击进入帖子视图，而非内联预览
永久链接页面 — 右键点击消息 → 复制链接 → 在浏览器中打开，获得专注的捕获效果
Canvas 和帖子 — Slack Canvas 页面可作为独立文档很好地保存
搜索结果 — 保存搜索结果页面可捕获多条相关消息

开始使用

从 Chrome 网上应用店安装 Save — 从 Slack 中拯救知识。

有问题？请发邮件至 [email protected] 联系我们