Single Source of Truth 是什麼？為什麼公司資料越多越要有唯一來源
一句話回答
Single Source of Truth（單一真實來源）指的是：同一件事實只在一個地方維護，其他要用到的地方都指向它，而不是各自複製一份。這樣要改的時候只改一處，不會有些地方更新了、有些還停在舊版。
先看一個每家公司都有的場景
一個商品的售價從 590 調成 620。你改了官網。然後呢？報價單範本裡還是 590，去年印的型錄 DM 是 590，客服的話術文件是 590，ERP 裡也還是 590。
過兩週，客人拿著型錄打電話來問為什麼官網比較貴。客服照著話術回 590，結果出貨單開 620。這不是誰不認真，是因為同一個數字被存了五份，而人不可能每次都記得五個地方都改。
所以 Single Source of Truth 是什麼
Single Source of Truth（SSOT，單一真實來源）的意思是：一件事實只在一個地方維護，其他所有要用到它的地方，都從那裡取，而不是各自抄一份。
重點不在「資料只能存在一個地方」，而在「只有一個地方是可以被修改的」。其他地方可以有副本、可以有快取，但那些都是拿來用的，不是拿來改的。要改就回到源頭改。
為什麼會變成各存一份
幾乎沒有人是刻意造成這種局面的。它是這樣長出來的：
- 當下最快的做法就是複製：要做一份報價單，打開舊的另存新檔最快。那一刻它是對的，問題在三個月後
- 工具之間本來就不通：官網在一個平台、ERP 在另一個、型錄在設計師的檔案裡。沒有人一開始就想過要打通
- 改的人跟用的人不是同一個：業務改了報價，行銷不知道。行銷改了文案，客服不知道
- 沒有人負責「這件事的正確版本在哪」：每個人都覺得自己手上那份是對的
一句話判斷你有沒有這個問題
挑一個公司裡常變動的資訊，問自己這句話：
「這個如果要改，我要改幾個地方？」
答案是一個，很好。答案是三個以上，那就是遲早會不一致。答案是「我不確定有幾個」，那代表現在很可能已經不一致了，只是還沒有人發現。
可以拿來自問的幾個項目：商品售價、運費規則、退換貨政策、公司地址與統編、員工職稱、服務方案內容、常見問答的標準答案。
怎麼做：三個層次，由淺到深
不用一次做到完美。這三個層次可以照順序來，第一層今天就能做：
- 第一層，指定一個地方是準的：先講清楚「價格以 ERP 為準」「SOP 以雲端硬碟那一份為準」。連結放出來，其他地方的舊檔案直接刪掉或標「已作廢，請看這裡」。這一步不用任何技術，但解決掉大半的問題
- 第二層，把複製改成參照：不要把數字抄進文件，而是放連結或嵌入。試算表可以跨表參照、文件可以嵌入區塊、網頁可以從同一支 API 拉。人看到的還是那個數字，但它是即時從源頭來的
- 第三層，自動同步：源頭一改，其他系統自動跟著更新。這一層要工程介入，做法可能是 API 串接、webhook 通知、或每天排程同步一次。不是每個項目都值得做到這層，先做「錯了會出事」的那幾個
在 AI 時代，這件事的代價變高了
以前資料不一致，頂多是人拿錯版本。現在多了一個會讀你所有文件的角色。
你把公司的資料丟給 AI，如果裡面同時有去年的 SOP、上個月的新版、還有主管在群組裡講的另一套，AI 不知道哪一份是最新的。它會挑一個回答你，而且語氣一樣肯定。
- AI 不會自己判斷新舊：檔案的修改日期它多半看不到，更不會知道哪一份是「正式的」
- 它會把矛盾的內容混在一起：有時候答案是兩個版本的拼裝，看起來合理但實際上不存在
- 錯誤會被放大：一份錯的 SOP 被人拿錯，影響一個人。被 AI 拿去回答，影響的是之後每一次問到這題的人
- 這也是整理資料最划算的時機：整理完，人跟 AI 同時受惠
在 AI 工具裡怎麼落實
如果你已經在用 AI 處理公司的事，下面這幾個做法就是 SSOT 的實作：
- 把規則寫成檔案，不要只講在對話裡：對話會被擠出脈絡視窗，檔案不會。規則改了就改那份檔案，不要在對話裡補充例外
- 用專案知識庫，不要每次重貼：把 FAQ、報價規則、品牌用語放進 Project 的知識區，每次對話它都讀得到。重貼的版本遲早會跟原始版本不一樣
- 一件事只放一份：同一份 FAQ 不要同時存在 Project 知識區、雲端硬碟、跟某次對話的附件裡。留一份，其他刪掉
- 在指令裡寫明資料的邊界：例如「只依照我給你的資料回答，資料裡沒有的就說不知道」。這句話讓它不會拿訓練資料裡的舊資訊來補
- 定期回頭看那份檔案還準不準：SSOT 的前提是那個唯一來源是對的。來源錯了，所有地方一起錯
最常見的破壞方式：複製貼上
一個好的 SSOT 制度，通常不是被推翻的，是被複製貼上慢慢磨掉的。
有人為了做簡報，把價格表貼進投影片。有人為了給客戶看，把 SOP 另存一份寄出去。這些當下都很合理，但每一次複製都多出一個之後不會被更新的版本。
實務上的折衷做法是：複製的時候順手標註來源與日期。像是在頁尾寫「資料來源：ERP，2026-09-17」。這樣至少下一個人看到會知道要去哪裡確認，也看得出來這份有多舊。
什麼時候刻意不要 SSOT
這個原則也不是無限上綱。有幾種情況反而該保留副本：
- 歷史紀錄要凍結：已經寄出去的報價單、已經成立的訂單，上面的價格就該是當下那個價格，不能因為之後調價就跟著變。這類資料要的是「當時的快照」，不是「現在的真相」
- 合約與法律文件：簽了就定版，不能連動
- 離線要能用：現場沒網路的時候，手上那份副本就是唯一能看的東西
- 判斷方式：問這份資料「應該永遠反映最新狀態」還是「應該永遠停在當時」。前者用 SSOT，後者就該是獨立的副本
今天可以先做的一件事
不用等系統整合。挑一個最常被問到、也最常出錯的資訊，做這三步：
- 找出它現在散在哪幾個地方，列出來
- 指定其中一個是唯一準的，其他全部改成連結過去，或直接標記作廢
- 在那個唯一來源上寫清楚「最後更新日期」與「誰負責維護」
常見問題
Single Source of Truth 一定要用系統整合才做得到嗎？
不用。最有效的第一步是「講清楚哪一份是準的，其他刪掉或標作廢」，這完全不需要技術。系統整合是後面的事，而且只值得做在「錯了會出事」的那幾項。
那資料備份算不算違反這個原則？
不算。備份是為了災難復原，不是拿來日常查詢或修改的。SSOT 講的是「可以被修改的地方只有一個」，備份沒有人會去改它。
已經散得很亂了，要從哪裡開始？
不要想一次收乾淨。挑一個「最常被問、最常出錯」的資訊先做，例如售價或退換貨規則。做完一個，團隊會有感，後面才推得動。
為什麼這件事對用 AI 特別重要？
因為 AI 會把你給它的所有版本一起讀進去，而且看不出哪份是最新的。它挑到過期的那份還是會講得很肯定。同一件事只留一份，AI 的答案才會穩定。
已經寄出去的報價單，價格調整後要一起改嗎？
不要。那份是當時的快照，改了反而有爭議。SSOT 適用的是「應該永遠反映最新狀態」的資料，不是歷史紀錄。
怎麼知道公司現在有沒有這個問題？
挑一個常變動的資訊，問「這個要改，我要改幾個地方」。答案超過一個就有風險，答不出來就代表現在很可能已經不一致了。
團隊不配合、還是各存各的，怎麼辦？
多半是因為「去源頭拿」比「自己存一份」麻煩。先把取得的路徑弄簡單，例如一個好記的連結、或直接嵌在他們本來就會開的文件裡。流程比規定有效。