前一篇我把正式知識庫的資料複製到本機隔離區，拿它來看舊條目在新畫面會怎麼呈現，也用另外建立的測試資料重現幾個問題。

在隔離區改程式時，我比較敢試。測試資料跑壞了，可以重新建立；
正式資料的副本也不會寫回雲端。
但最後要用的仍是雲端那份知識庫，所以只在本機看到測試通過，還不能說正式版已經修好。

這次我先挑一項上線：背景工作如何認領待分析的資料。其他在隔離區試過的修正，先留在本機。

為什麼先改認領

從網頁把資料送進知識庫時，系統會先把原文存進資料庫，標記為「待處理」，再由背景工作拿去做 AI 分析。我原本知道存入和分析不是同一步，這次查程式才注意到：背景工作要開始分析之前，還得先決定「這筆工作由誰拿走」。

原先的做法是先查出一筆待處理資料，再把它改成分析中。如果兩個背景工作剛好同時查，有機會都看到同一筆。這是從程式流程看出的風險，不能倒過來說正式版以前一定發生過重複認領。

本機修正把「選出資料」和「標成分析中」放在同一個資料庫交易裡。隔離測試讓多個程序同時認領三筆待處理資料，結果每筆只被拿到一次。這項修改的範圍比較清楚，我便先拿它作為這次正式部署的項目，沒有把其他修正一起帶上去。

要動正式版之前，先留一份可以回頭查的資料

正式知識庫跑在雲端主機上。我平常透過網頁或 AI 工具讀到的，也是那裡保存的資料。這和本機隔離區不同：正式版的程式與資料，會直接影響我之後查找的內容。

部署前，我先請 AI 協助保存正式版原有的程式、資料庫一致性快照，以及上傳檔。這次只更換包含認領修正的程式檔，再重新啟動網頁服務。

這份備份放在同一台主機，能作為這次修改的回復材料；它不是異地備份，我也還沒有做完整的還原測試。服務重新啟動、首頁打得開，也只能說服務有回應。我更想確認的是：原本存著的資料還在不在，讀出來有沒有變。

我先比對部署前的資料庫快照與目前正式庫。資料庫裡共有 164 筆條目，包含主資料與拆出的子章節；網頁首頁顯示的 89 筆是頂層資料，兩個數字代表的範圍不同。條目內容、標籤及關聯逐筆比對後，與部署前一致。

接著我從正式 API 讀取幾筆現有條目，確認回傳的標題、原文、摘要和處理狀態與資料庫相同；也實際打開正式網頁，看得到條目內容。這一步是在查「部署有沒有讓原有資料或讀取路徑出問題」，還不能拿來證明那些舊摘要本來就寫得正確。

三筆測試資料，真的進了正式版

舊資料核對完後，我才從正式 API 送入三筆短文字。每筆都有明確的測試標題，內容也寫明只是用來確認處理流程，不是要留在知識庫裡的正式資料。我刻意讓文字保持簡短，避免它被拆成多個主題；這次要看的，是存入後背景工作能不能接手，而不是測文章拆解能力。

API 回傳後，三筆資料都已經存進正式資料庫，狀態先是「待處理」。我接著看它們的狀態變化，也查服務紀錄：背景工作先拿到第一筆，把它改成「分析中」；完成後再處理下一筆。最後三筆都顯示「完成」，各自記下的認領次數都是一次。日誌裡也能對上每筆的一次「開始分析」與一次「分析完成」。

這次看到的「完成」，是系統記下的處理結果。我沒有因為這個狀態，就認定 AI 產生的摘要和標籤一定正確。三筆內容本來就很短，也沒有一般專案介紹會有的功能、限制和版本資訊；即使摘要看起來沒偏題，能說明的仍然有限。

另外，正式版背景工作這次是依序處理三筆。它能證明新資料有被接走，而且沒有在紀錄中看到同一筆被認領兩次；但它沒有重現兩個工作者同時搶同一筆的情況。那部分的並行測試，仍是先前在隔離資料副本上完成的。

刪掉測試資料後，還要再查一次

如果只看到三筆都完成，測試其實還沒結束。它們是在正式知識庫新增的，我得確認刪除後不會留下讓自己以後搜到的測試內容。

我先透過正式 API 刪除三筆條目，再查它們的編號與測試標題，確認條目已不存在。分析時可能產生標籤和關聯，所以我也檢查標籤對應、關聯及搜尋索引；這次新增而且沒有其他條目使用的標籤，也一併清理。最後重新產生 Markdown 匯出檔，確認裡面找不到測試標記。

我沒有只用「總數回到 164 筆」當作檢查結果。因為筆數相同，也可能是某筆內容被改了。這次另外把測試前保存的資料庫快照與清理後的正式庫逐筆比對：原有條目、標籤、標籤對應、關聯和搜尋索引的內容一致，資料庫完整性檢查也通過。正式庫沒有留下待處理或分析中的測試工作。

目前確認到哪裡

這三筆短文字在正式版走完了存入與背景分析，清理後也沒有查到測試資料殘留或原有資料變動。

不過，我平常更可能存的是 GitHub 專案或一般網頁連結。
那類資料還有正文能不能抓完整、摘要與標籤有沒有對上來源、後續補充是否偏離主題等問題。
這次的短文字測試沒有回答那些問題，得等真正的新資料進來後再看。

其他在隔離區試過的修正，目前也沒有跟著部署。
我打算一次處理一個範圍，再回正式版確認結果。
下一筆真正想收進來的連結，應該會讓我看到這次測試沒碰到的地方。