最近寫文章時，我比較常回頭打開知識庫。
以前看到資料找得到、摘要也出現了，我大致會認為它已經處理好。
現在我會再看原文、後來補進的內容，以及摘要能不能對得起來。

前面記下的幾個問題，我想試著修，但不太敢直接改正式版。
如果補查機制把已有的內容蓋掉，或背景分析把同一筆資料跑了兩次，等我在正式知識庫看到結果時就太晚了。

所以這次先在本機做隔離測試。
我也複製了一份正式知識庫的資料進來：只用自己編的幾筆資料，能測特定錯誤，卻不一定看得出現有條目放進新畫面後會是什麼樣子。
測試新增的資料只留在暫存副本，沒有寫回正式知識庫。

先打開現有資料看看

我先看了 Headroom 這筆資料。隔離區裡能讀到它原有的內容、後來的補強，以及補強寫回的時間。但「有補強時間」只能說明內容曾經附加進去，不能因此判定後面的分析都成功了。

這筆舊資料沒有留下這次新增的分析報告和結束時間，所以處理狀態顯示「未知」。一開始看到未知，可能會覺得這個欄位沒有幫上忙；但如果沒有紀錄，卻硬把以前的「完成」狀態顯示成每一步都做完，反而更容易讓我誤判。

我也找了一筆由真實 Markdown 檔案建立的 Wazuh SOP 條目。它在知識庫裡不是只剩一個檔名：畫面上可以看到從手冊拆出的章節、摘要，以及保存下來的章節內容。這比較接近我平常會拿來找資料的樣子。

不過，這張畫面只能證明隔離副本讀得到這筆檔案條目。原始檔案的下載連結，我沒有在這個隔離預覽裡完成驗證；摘要是否正確，也還是得拿原文逐項核對。

有內容，卻可能被當成沒內容

看完現有條目，我們回頭檢查先前記下的問題。有些網址第一次存入時抓不到正文，系統會先留下一行「無法取得內文」的說明。如果後來又補進真正的內容，分析時就應該讀後面的正文，不能只因為開頭是那行說明，就把整筆判成沒有內容。

本機版現在會略過開頭的系統說明，保留後來補入的正文給分析；如果整筆真的只有說明，仍然算內容不足。

這次複製的正式資料裡，沒有找到剛好符合「開頭是佔位說明，後面又補入正文」的條目。因此我不能說正式版已有哪一筆因此分析錯誤。這項修正是用隔離區內建立的測試條目驗證的。

補查找到正文時，原本的資料可能已經變了

知識庫還有一個補查機制，會重新尋找當初沒抓到的網頁正文。我們先修正它的清單，讓已經補入正文的資料不再被選成「只有連結」。

但我後來才知道，光在選清單時檢查一次仍然不夠。假設補查選中一筆只有連結的資料，接著到外部找正文；在它等待結果的這段時間，另一個程序先把內容補進去了。等補查結果回來，如果仍照最初的判斷直接寫入，就可能蓋掉剛補好的內容。

現在本機版在寫回前會再核對一次：資料內容必須和選中時完全一樣，才接受補查結果。隔離測試刻意讓內容在補查途中改變，較晚回來的結果沒有覆蓋新內容，也沒有被記成補查成功。

兩個背景工作，不能拿走同一筆

整理處理時間時，我們也發現同步寫入或手動重跑分析，原本可能記下結束時間，卻沒有更新這次的開始時間。這項已在本機補正。

再往背景分析看，原本的做法是先找一筆「待處理」，然後才標成「分析中」。如果兩個背景工作同時查，兩邊有機會看到同一筆待處理資料。我之前只知道系統會排隊分析，沒有想到「誰先拿到這筆工作」本身也需要處理。

本機版現在把查詢和標記放進同一個資料庫交易。隔離測試讓八個呼叫同時認領三筆待處理資料，三筆各被認領一次。這是本機測試結果，不能反過來說正式環境以前真的發生過重複認領。

圖說：左側是原先查詢與更新分開時的競爭風險；右側是本機修正後的交易流程。

還要等正式環境跑過，才能說修好了

這次先做隔離區，是因為我怕修改直接部署後才發現影響原有資料。測試資料幫我重現特定情況，正式資料副本則讓我確認現有條目在畫面上如何呈現。兩種資料各能回答一部分問題。

目前修正都還在本機。舊資料缺少的分析時間和步驟紀錄，也不會因為新增欄位就自動補出來。等到準備部署時，我還得先備份正式版，確認只送出這次要更新的程式，再實際看正式排程和 AI 分析的結果。