SecondSourceAI 產業的第二來源

事故月摘

每個月一期,寫我們自己壞掉的地方:發生什麼、真正的原因是什麼、因此立了什麼新規則。不挑好看的講——一條事故都列不出來的清單,才是不該相信的那種。

看每天的運作數字 →

#1涵蓋期間:2026-07-18 – 2026-08-16發佈:2026-08-16

第 1 期:同一面牆,撞了一個月

這一期涵蓋 2026 年 7 月 18 日到 8 月 16 日,共 30 天。

這是我們自己撞的牆的清單。我們每天用自己這套系統做出這份刊物;

它壞的時候長什麼樣、我們花多久發現、修好了沒——都寫在這裡。

數字大是刻意的。 這不是「我們很穩」的宣傳品,是「我們什麼都不藏」的憑證。

一個每天自己跑的系統,30 天出兩千多次失敗訊號很正常;

不正常的是那種一條事故都列不出來的清單。

這 30 天我們逐條列出 43 件事故:21 件已修、17 件還沒修、另外 5 類由系統自己撐住。

底下挑五件講完整——每一件都照同一個格式:發生什麼 → 真正的原因 → 因此立了什麼新規則。

一、一篇通過審查的稿子被靜默換回舊版,六個半小時沒人發現

發生什麼:8 月 16 日,一篇已經通過品質審查的中文深度報導,只活在工作目錄裡沒有存檔。

有人清理目錄時它被靜默換回舊版本,6.7 小時沒有任何警示,

官網下午重建時直接拿舊版上了線。

真正的原因:同一個工作目錄同時有好幾個工作在動手,而版本控制工具的每一個指令

——暫存、還原、切換——動的都是整棵目錄樹,不是「我剛改的那幾行」。

當天下午一個「把改動先暫存起來」的指令一次收走了 230 個檔案,救回來的只有 1 個。

新規則:①通過品質審查的定稿,當場存一份進版本庫,不准只活在工作目錄;

②出貨前機器對帳「這次要發的檔」與「通過審查的那一份」,對不上就報紅停發;

③要單獨送出自己那幾段改動,一律走釘住版本的正式程序——結構上不可能夾帶到別人的東西。

二、線上服務少了兩塊功能三個半小時,監控全程顯示正常

發生什麼:同一天,線上服務有兩塊功能整整 3.5 小時不存在

(讀者問卷寫不回去、一個對外接口整個消失),而漂移監控一路顯示「同步中」,零紅字。

真正的原因:監控問的是「原始碼有沒有變」。原始碼確實沒變——

被換掉的是由原始碼產生出來的那個檔只量輸入、不量產出,就是結構性盲區。

新規則:監控的判準從「輸入變了嗎」改成「我上次產出的東西還在不在原位」。

產出物不見了就報紅,不管輸入動沒動。

三、在工作目錄跑一次前端建置,五分鐘後它就是線上版

發生什麼:同一天晚上,兩次純粹為了測試而做的前端建置,真的上線了。

不需要有人按發佈、不需要存檔、19 道品質檢查一道都不用過。

真正的原因:建置產物本身就是部署來源,中間沒有任何一道出貨閘。

「做出來」和「決定要發」在流程上是同一件事,所以任何一次手滑都是一次上線。

新規則:加一道出貨溯源檢查——版本章對不上實際內容、或工作目錄不乾淨,就不換版。

「做出來」與「決定發」從此是兩個動作。

四、每天中午準時響的警報,收件人是空的

發生什麼:主管版日報在這 30 天內有 16 天沒有送達

機器每天中午 12:00 準時對帳、準時記下這一筆——然後那一筆沒有人收。

真正的原因:對帳做完了,記錄也留了,但沒有任何一個角色被指定為這筆記錄的收件人

警報有在響,只是響給空氣聽。所以直到做這份清單的當天,

我們連「這 16 天是壞了還是刻意停發」都答不出來,因為沒有人逐日歸因過。

新規則:被擋掉、被過濾、被記下來的每一筆,都必須有明確的去向與收件人;

沒有收件人的紀錄不算處理完。做這份清單本身就是這條規則的第一個產物——

列清單,就是在找那些一直在響、卻沒人接的鈴。

五、一道防線做了一半,而綠燈說它做完了

發生什麼:先前有一起「圖表看起來被竄改」的事件,我們做了一道防線:

合法改版要在資料裡自我聲明是誰改的。防線的自我檢查全綠、線上實測也確實有那個欄位——

但畫面從頭到尾沒有把它顯示出來。於是同一個問題第二次發生,

使用者第二次只能把它讀成「數據被竄改」。

真正的原因:驗收的終點設在資料層,而不是使用者的眼睛。

綠燈量的是我們做了什麼,不是讀者看到了什麼。

新規則:防線的驗收終點一律設在「使用者眼睛看得到」。

資料層有了但畫面沒有,算沒做完。

我們沒修好的

這個月的四個主軸——整棵目錄樹被回捲、未經檢查就出貨、同檔互撞、送出時被別人的在製品連坐

——當天都有設防落地。但其中三個封的是症狀,不是根本:

  • 互斥鎖在「佔位」那一端補好了,「送出」那一端還開著;
  • 送出的碰撞源用「每張工作卡配一棵獨立目錄樹」繞開了,但檢查本身量錯對象這件事沒動;
  • 回捲的高風險檔案族群已經列冊,盤點還在進行中——而第三起就發生在同一天

17 件未修的事故每一件都已經被看見、被立案、有負責的卡號。

狀態是「還沒收斂」,不是「不知道」。我們把這個寫出來而不是只報那 21 件已修,

是因為「症狀已修」和「不會再發生」是兩件事,而要用這套系統的人需要知道我們分得清楚。

撐住這一切的東西

最後值得說的是:你在上面讀到的 43 件,是好幾層自動防護擋掉之後的殘量

同一段時間裡,送出時的搶鎖衝突被自動重試擋下一千多次;

七百多筆同型訊號被連鎖靜音,避免一個成因灌爆整個診斷佇列;

一百多次成果重疊沒有被硬併,而是原封放進隔離區等人審;

6 次服務額度撞頂時系統自動停工換手,沒有半途燒斷;

13 次不合格的稿子在寄出前被擋下來。

**一個系統的可靠度,不是它不出錯,是它出錯的時候有沒有東西接住,

以及接不住的時候有沒有人記下來。** 這份月摘是後半句的證據。

這些數字的限制(誠實揭露的一部分)

1. 「失敗訊號兩千多次」是訊號數,不是事故數;一個成因可能灌出幾百筆。

本期逐條列出的 43 件是人工歸併後的事故數,兩個數字不可互推。

2. 自癒分類的紀錄只有 8 月 6 日之後才完整,更早的部分靠其他紀錄回推,可能低估。

3. 教訓檔的日期取自檔案內文而非存檔時間——8 月 16 日有一批舊教訓被補存檔,

照存檔時間算會把它們全記成當天。

4. 「已修」= 有卡、有修法、有回歸測試;不等於「不會再發生」。

上面「我們沒修好的」那一段明列了三條症狀已修、根本未封的。

以上為本站自身的運作紀錄,不構成任何效果或品質保證,也不預示未來表現。