如何在 Slack 找回舊決策（當搜尋不夠用時）
Slack 搜尋找不到舊決策？探討決策為何消失、決策紀錄為何常爛尾，以及有決策意識的知識圖譜該怎麼做。
By Ellis Keane · 2026-03-14
快問快答：你們團隊當初在哪裡決定用 webhook 而不是 polling？不是問你「做了什麼決策」，而是這個決策現在到底寫在哪裡，讓下個月新加入的人能找得到？
如果你跟我們一樣，最誠實的答案大概介於「應該在某條 Slack 討論串吧」和「我記得是在 #eng-backend，大概三週前，應該有兩三個人，但我真的記不起來是誰」之間。仔細想，這狀況滿荒謬的：這個決策重要到足以改變整個系統的運作方式，卻沒重要到被寫進一個不是按時間戳排序的地方。簡而言之，這就是在 Slack 找舊決策的核心痛點 – 資訊都在，只是它的組織方式沒辦法讓你把它當「決策」來取回。
我研究怎麼在 Slack 找舊決策已經有一陣子了。越挖越覺得根本問題不是紀律、習慣，或大家常怪的那些理由，而是架構問題。Slack 搜尋是為了找訊息而建的，但決策不是訊息 – 決策是透過訊息表達出來的語意。這聽起來像在咬文嚼字，但當你花 20 分鐘滑搜尋結果，試圖從 17 則提到「webhook」的訊息裡找出團隊真正拍板的那則，你就知道差別有多實際。
Slack 搜尋實際怎麼運作（以及它壞在哪）
先講精準一點，因為「Slack 搜尋很爛」不是正確診斷 – Slack 搜尋在它的本職上其實做得不錯。問題在於，它做的事跟你找決策時需要它做的事，本質上不同。
Slack 把訊息當文字加 metadata 來索引：時間戳、發送者、頻道，以及（付費方案的話）完整 thread 脈絡。你搜「webhook」，Slack 忠實回傳每則含這個詞的訊息，依新舊與相關度排序。你可以用搜尋運算子縮小範圍 – in:#eng-backend from:@sarah before:2026-02-15 – 但本質還是用 metadata 過濾同一份扁平訊息清單。這是關鍵字取回，用來找你半記得的某則訊息，沒問題。
但決策不是關鍵字。決策是一個問題、幾個選項、幾位參與者、以及團隊收斂到某個選項的那一刻之間的關係。決策文字可能是「對，直接走 webhook 吧，polling 快把 rate limit 吃完了」– 很口語、高度依賴脈絡，而且只有在你已經知道那條 thread 時才有意義。也可能只是「這樣可行，我來做個 prototype」，裡面連一個跟技術決策相關的關鍵字都沒有。
這就是架構不匹配：Slack 用時間序存訊息，用關鍵字取回。決策是語意型（關乎意義）且關係型（連到任務、人和結果）。你要一個時間序儲存系統做語意取回，它做不到，因為它本來就不是這樣設計。「可搜尋」和「找得到」之間的差距非常大 – 你歷史裡每則訊息技術上都可搜尋，但這不代表你需要的決策在實務上找得到。
「Slack 可能是史上最大的組織決策資料庫之一，但幾乎無法以『決策』形式被取回 – 每個字都被完美保存，卻幾乎完全找不到。」 – Ellis Keane
你真的在 Slack 找舊決策時會發生什麼
這個不匹配在實務上長這樣。假設三週前你們決定 GitHub 整合從 polling 改 webhook。你記得在 #eng-backend，有幾位工程師參與。所以你在該頻道搜「webhook」。
回來的是：#eng-backend 裡所有提過 webhook 的訊息。半年前的 bug 回報。有人在完全不同脈絡下問 webhook retry 邏輯。有人貼了一篇 webhook best practices 文章連結（很諷刺，搜尋結果排名可能還比旁邊的真正決策高）。決策本身 – 某條 thread 裡有人提到 polling 快撞 rate limit 的那則回覆 – 埋在第三頁，看起來跟周圍所有訊息一模一樣。
這還是你大概記得用詞的情況。更多時候，決策語句高度依賴脈絡，幾乎像加密。「走 option B 吧」根本沒寫 webhook，即使 option B 就是 webhook。「這樣可行，我來 prototype」連 option 這個字都沒有。真正拍板時刻常是整串裡最短、關鍵字最少的訊息，因為到那時大家都已有共享脈絡，只是在確認對齊。
作為資訊架構問題，我覺得這很有趣（好吧，當你是搜尋的人時，也很火大）。Slack 建出史上最大的組織決策資料庫之一，卻幾乎無法以決策形式取回 – 字字都在，幾乎找不到。
為什麼決策紀錄常變「指標做比較好的墳場」
你去找解法，最常見建議是做決策紀錄。Notion database、專用 Slack channel（推薦這招的人顯然沒意識到有多諷刺），或 wiki 頁面 – 總之做一個單一入口，決策發生就記進去。
我們試過。撐了大概六週。前兩週很漂亮 – 大家投入、紀錄完整、確實有用。第三週開始零零落落。第五週只剩一個人在更新，寫著像「決定了 auth 的某件事」這種內容，沒連結、沒脈絡、沒參與者。第六週大家默默不再演。
問題不是團隊不自律（也許有，但不是重點）。問題是決策紀錄在最不該課稅的時刻課稅。你剛結束高品質討論、已對齊、有人準備開始做了 – 現在還得停下來，開另一個工具，寫摘要、tag 人、連回原始對話。每個決策 3-5 分鐘。一個每天跨 channel 和 thread 有 5-10 個重要決策的團隊，這個成本很快失控，最後沒人願意接。
而且這套只在 100% 服從時才有用。只有 70% 覆蓋率的決策紀錄，有時比沒有還糟 – 你得查兩個地方，兩邊都不信。先看 log，找不到，再去搜 Slack，回到原點，還多浪費兩分鐘。
決策不是事件，是梯度
手動紀錄會失敗，部分原因是它預設決策是離散且可明確圈出的時刻。現實是，多數決策沿著對話逐步成形，「拍板瞬間」常常本來就模糊。
想像工程決策典型流程。有人在 Figma 留言提疑慮：「這個互動在 mobile 可能不行。」工程師在 Slack thread 回覆並貼原 comment：「我看過了，component library 不支援。」設計師在同 thread 提替代方案。工程師說「可行，我做 prototype。」兩天後 PR 上線實作替代方案，Linear issue 更新。
決策到底在哪發生？Figma comment 提出問題那刻？Slack 提方案那刻？工程師回「可行」那刻？還是 PR 落地那刻？實務上，決策分布在這四個時刻，跨兩個工具、橫跨三天。它不是可被單點記錄的事件，而是逐步收斂成結果的梯度。我們知道有決策發生，是因為程式碼改了。
這是我認為多數「決策追蹤」建議搞錯的地方。它把決策當成可直接抄下來的東西，像記電話號碼。現實裡多數決策是要回溯重建的 – 看有什麼改變，往回追導致改變的對話，事後拼出推理。你需要的不是 log，而是 graph。
Graph 能給你什麼 log 給不了的
知識圖譜把跨工具、跨時間的訊號串起來。不是靠人手動寫「我們因 rate limit 決定改 webhook」，而是把討論 rate limit 的 Slack thread、追蹤整合工作的 Linear issue、實作 webhook 的 PR，以及參與討論的人自動連起來。決策不是被「記錄」，而是可從既有連結被「重建」。 This is a single view of what the team is doing that actually deserves the name, enabled by building a searchable graph of decisions and tasks across tools rather than maintaining a separate log.
實務差異在這種情境最明顯。webhook 決策三週後，新工程師加入問：「為什麼 GitHub 整合用 webhook 不用 polling？polling 看起來比較簡單。」沒有連結系統時，通常有人說「我們之前決定過」，沒人記得哪個 channel，有人花 15 分鐘搜 Slack，最後找到或（更可能）靠記憶重建理由。這很危險，因為記憶不可靠，原始推理幾乎一定比三週後口述更細膩。
有知識圖譜時，工程師打開 GitHub 整合任務。所有碰過這個任務的訊號都已連好：rate limit 原始討論、評估 polling vs webhook 的 thread、落地變更的 PR。端到端決策軌跡一次到位，不必任何人手動搜，也不必任何人手動記。
差距不在「搜尋好」和「搜尋差」之間，而在「關鍵字取回」和「關係取回」之間。決策由它和任務、人、結果的連結定義，不是由字詞定義。
那些不會出現在任何儀表板的成本
我對號稱能精準量化這類軟成本的人一向保留（「每週浪費 X 小時」常看起來像先有結論再倒推），但就我們團隊觀察到的：
最明顯的成本是重啟舊戰。找不到原始決策時，團隊就會重開議題。有時真的忘了，有時是新同事提了合理質疑卻無法用具體脈絡回應。以前我們常重打已收斂的議題。每次重打都有成本：會議時間、為同一件事再辯一次的情緒疲勞，以及那種「原始推理應該比現在記得的更細」的不安。
更隱性的成本在入職。新同事每次問「為什麼這樣做」，都會打斷當年參與決策的人。答案每被重述一次就更偏離原始脈絡，像傳話遊戲，只是電話換成企業軟體，訊息是「架構為何長這樣」。還有可信度落差會累積：「我們當時選 webhook」的說服力，遠低於「我們選 webhook，是因 polling 吃掉 GitHub API rate limit 的 40%，尖峰時段已被節流」。推理本身才讓未來工程師能判斷決策在新條件下是否仍成立。而那段推理現在躺在某條 Slack thread，保存完整但幾乎不可見。
別再讓決策淹沒在 Slack 的滾動裡。Sugarbug 會自動把完整決策軌跡串起來 – 從 Slack 討論串到 Linear issue 再到 PR。
Q: 為什麼在 Slack 找舊決策這麼難？ A: Slack 按時間序儲存訊息，不是按語意。埋在討論串裡的決策看起來跟其他回覆一樣 – Slack 搜尋能比對關鍵字，但在不讀完整對話脈絡前，它分不出「我們決定用 Redis」和「我們要不要用 Redis？」。時間越久越難找，因為你會失去搜尋需要的脈絡線索（誰參與、哪個 channel、哪一週）。
Q: Sugarbug 會自動追蹤 Slack 裡做出的決策嗎？ A: 會。Sugarbug 會分類來自 Slack 與其他已連接工具的訊號，辨識出類似決策的 pattern – 引用任務、涉及被指派人、最終帶來狀態變更或 PR 的 thread。這些會被連到知識圖譜中的相關任務，你可從任務追決策，不用翻 Slack 歷史。
Q: 決策紀錄和用於決策的知識圖譜差在哪？ A: 決策紀錄要有人在當下手動記錄每個決策 – 發現它、停下來、摘要、tag、連結。知識圖譜則從工具中流動的訊號推斷決策，並自動連到任務、人和對話。前者依賴每個人長期一致的紀律，後者在背景從既有活動自動運作。
Q: Sugarbug 能整理 Slack 以外工具的決策嗎？ A: Sugarbug 可連接 Slack、GitHub、Figma、Linear、Notion、email 和行事曆。決策常跨多工具發生（一個 Figma 留言引出 Slack thread，再落地成 PR），知識圖譜會跨所有已連接介面把訊號串起來，不管對話從哪個工具開始，你都能看到完整軌跡。
Q: 這跟只用 Slack 內建搜尋有什麼不同？ A: Slack 搜尋找的是含特定關鍵字的訊息。知識圖譜找的是訊息、任務和人之間的關係。當你在找決策時，你通常不是在找某個字 – 而是在找團隊從多個方案中做出選擇的那個時刻，而那個時刻由它和其他訊號的連結定義，不是由字詞定義。
---
如果決策一直消失在 Slack 歷史裡，問題不在 Slack – 而是沒有系統在持續偵測那些重要時刻，並把它們連到被它們改變的工作。這就是我們做 Sugarbug 要補上的缺口。