用DeepSeek勾稽多據點IT資產台帳

簡而言之： 把各據點的資產表和Intune或AD裝置清單一起匯出，用白話把欄位含義與比對規則描述給DeepSeek，讓它統一序號格式、跨來源比對紀錄、並把每一處不一致標出來。你會在一天之內拿到一份站得住腳的一次性盤點結果。你不會因此得到任何能阻止這些台帳再次分歧的東西。

問一位管著深圳、蘇州、香港幾個據點的IT主管：公司一共有多少台筆電？你會得到一個數字。再問這個數字是怎麼來的？你會得到三份格式各異的表格、一份Intune匯出，以及財務那份和它們全都對不上的固定資產台帳。

沒有人在說謊。每一份來源都為不同目的而建、由不同的人維護、最後一次更新的時間也各不相同。據點清單存在，是為了讓當地管理員能找到某台機器；Intune匯出存在，是為了讓裝置能上修補程式；財務那份台帳存在，是為了讓資產能提列折舊。它們從來就不是為了互相勾稽而設計的，而在有人開口要一個全公司口徑的數字之前，也沒有任何力量逼它們對上。

在雜亂、來源不一致的紀錄之間做比對，恰恰是語言模型真正擅長的事——不是因為它難，而是因為它是那種「人做一遍很容易、做一萬遍必然出錯」的容易。DeepSeek特別適合這件事，是因為來源資料通常有一半是中文：據點表裡「型號」和「使用人」這樣的欄位，緊挨著英文序號，日期格式各不相同，地點名稱有三種寫法。一個原生讀得懂兩種語言的模型省掉了一道翻譯工序，而你每省掉一道工序，就少引入一類錯誤。

以下是一套可操作的方法——以及結尾處關於「它解決不了什麼」的一句實話。

為什麼沒人說得清公司有多少台筆電

四個原因，而且會疊加。

每個據點各記各的，格式還各不相同。 一個據點按序號記，一個按資產編號記，還有一個按使用人姓名記。欄位不一樣，表頭語言不一樣，而且至少有一份清單裡有個合併儲存格，把兩台機器塞在了一列裡。

這些清單是「出事才更新」的。 紀錄在採購時被新增，在出問題時被更新。而當一台筆電被悄悄交給新報到的同事、被帶到另一個據點、或者在某人離職後留在抽屜裡時，沒有任何機制會去更新它。

沒有人對「總數」負責。 每個據點負責人對自己那份清單負責，而沒有人對加總負責。一個沒有任何具體的人被考核的數字，就是一個會漂移的數字。

本該解決這件事的系統，當初是為別的目的買的。 Intune和Active Directory知道的是那些會回連的裝置——這就排除了關機的、被重灌的、躺在倉庫櫃子裡的、以及根本沒納管過的。財務台帳知道當初買了什麼，之後發生了什麼則一概不知。兩者在各自的範圍內都準確，出了範圍就沉默。

後果不是抽象的。它表現為：因為沒人信備機數量而重複採購；為兩年前就報廢的機器持續付授權費；以及一場內部的、ISO的或客戶方的稽核詢問，花三週時間給出一個糟糕的答案。

把來源資料整理成模型能勾稽的形狀

準備工作佔了大部分工作量，而且它並不技術。

到底是哪三份來源在互相打架？

先把你要比對的東西準確地點名，因為「我們有幾張表」不算一個範圍。

據點表格是「誰手上實際拿著什麼」的事實來源，同時是其餘一切資訊裡最不可靠的來源。它通常能把使用人和位置記對，因為那正是當地管理員需要的；而採購日期和型號名稱往往記得很差。

Intune、Jamf或AD匯出是「什麼裝置真的在運行、在回連」的事實來源。它在序號、系統版本、最後上線時間上是權威的，而對一台從未納管過的裝置一無所知。

財務固定資產台帳是「買了什麼、帳面價值多少」的事實來源。它在採購日期和成本上是權威的，經常把二十台筆電記成一列，而且往往根本不帶序號。

在開始之前把這件事講明白，因為它決定了當兩份來源衝突時誰說了算——而正是這條規則、而不是模型，讓產出站得住腳。

有哪些比對規則必須明確寫出來？

你不給規則，模型就會自己推斷；而推斷出來的規則，正是無聲錯誤的來源。把它們寫下來，放進提示詞裡。

序號正規化。 去掉空格和連字號，明確大小寫是否敏感，並說清楚那些被Excel加了前導單引號、或因欄寬不夠被截斷的值該怎麼處理。戴爾的服務編號、聯想的序號和蘋果的序號形狀各不相同；說清楚你預期看到哪些。

跨語言的欄位對映。 告訴它「序號」和「Serial No.」是同一欄，「使用人」對應assigned user，狀態欄裡的「已報廢」意思是retired。這正是雙語模型體現價值的地方——你是在描述一套對映，而不是把檔案翻譯一遍再祈禱中間什麼都沒錯位。

什麼才算比對成功。 序號完全一致算相符。資產編號相同但序號不同是衝突，不是相符。使用人相同、型號相同、但兩邊都沒有序號，那是候選——候選必須標記出來交給人判斷，絕不能自動合併。

剩下的怎麼辦。 每一筆沒對上的紀錄都是一個發現，而這個發現是有類型的：在Intune裡但不在任何據點清單上；在據點清單上但Intune從沒見過；在財務帳上但別處都沒有。要求它按類型分開列出，因為每一類的後續動作都不一樣。

讓資料保持適度。一次硬體盤點不需要住家地址、電話號碼或人資工號——你匯出的個人欄位越少，之後要回答的法遵問題就越小。

一次實際的勾稽流程——正規化、比對、標記、再人工複核

分四輪做，而不是問一個問題然後指望它。

第一輪——只做正規化。 一次只給模型一個檔案，要求它輸出一張乾淨的、統一表結構的表：序號、資產編號、型號、使用人、據點、狀態、採購日期、來源。先不要比對。拿一個據點的輸出跟原始檔案核對一遍再往下走；如果正規化是錯的，後面每一步都會繼承這個錯誤。

第二輪——用強主鍵比對。 要求它在正規化後的資料集之間做序號完全比對，並給出每個來源對上和沒對上的筆數。對不上的數字就是你的第一個真實發現，而且它通常指向正規化問題，而不是真的存在缺口。

第三輪——讓它提出弱比對。 現在要求它基於較軟的訊號給出候選比對，每一筆都要附上理由：「資產編號相同、使用人相同，據點清單上缺序號。」一定要堅持要理由。沒有理由的候選清單是無法複核的；帶理由的候選清單，一個稱職的人大約每列一分鐘就能過完。

第四輪——給例外分類。 要求把未對上的紀錄按例外類型分組，每組附上建議的下一步動作：實地找機器、確認已報廢、去追據點負責人、修正財務台帳。

然後人工複核——而且要抽查對上的那部分，不只是例外。例外天然會被仔細看，因為它們看起來就不對；真正會被照單全收的，是那些看起來很有把握、其實是錯的比對結果。隨機抽二十列比對結果、回原始檔案核對，這二十分鐘會告訴你整輪結果值不值得信。

在四個據點上跑第一輪，現實的結果是：大部分紀錄能乾淨地對上，相當一部分落進候選池，還有頑固的一小撮是真正找不到的裝置——那部分再怎麼處理資料也解決不了，必須有人走進那個房間去看一眼。

一次性的AI勾稽 vs 一套真正的資產管理系統

多快能拿到一個可信的數字 — AI勾稽完勝。一天的工作量，對上一個需要系統、需要推行、需要流程的專案。
啟動成本 — AI勾稽勝出。就是一筆API費用加上你自己的時間，沒有任何東西需要採購。
處理雜亂、雙語、格式不一的輸入 — AI勾稽勝出，而且差距很大。這恰恰是嚴格表結構的系統最不擅長的問題形狀。
防止下個季度再次分歧 — 一套受管的資產台帳決定性勝出。一次勾稽是一張照片；一套帶領用/歸還流程和Intune同步的台帳，是一個能維持現狀的流程。
稽核與法遵證據 — 台帳勝出。「這是我們的資產系統，有領用歷史和折舊計畫」能回答稽核人員；「這是我們三月用AI清理過的一張表」只會招來下一個問題。
授權與保固管控 — 台帳勝出。席次追蹤和到期提醒是持續性的工作，不是一次性的分析。

誠實的讀法是：用AI這一輪搞清楚問題到底有多嚴重、並產出一份乾淨的基線，然後把這份基線放進一個能自我維持的地方。只做前者不做後者，意味著明年還得再做一遍前者。

決定這件事值不值的，是最後那一步

之後由誰來管這份台帳。

一次勾稽產出的是某個特定日期上的一份乾淨清單。從那一刻起它就開始衰減，衰減速度大致等於你們組織搬動硬體的速度——而在一個有外包人員、有調撥、有正常人員流動的多據點中國營運裡，這個速度比多數人估計的要快。六個月後，你面對的又是三張表，外加第四張：那份對過帳的，現在也錯了。

這份乾淨清單只有在兩件事發生時才值回工夫。有一個人被指定為「總數」的負責人，而不只是各管各的據點。以及，每一件搬動裝置的事——領用、調撥、歸還、報廢——都在發生的當下寫進同一個地方，而不是事後靠回憶重建。

這就是「要系統而不是要一次活動」的全部理由。Brocent的FINOS IT資產管理正是為這個形狀的問題而做的：自動編號的資產紀錄，帶序號、資產標籤、使用人、位置、狀態和保固日期；領用與歸還流程，讓配發歷史在發生的當下就被記錄；Microsoft Intune同步，讓已納管裝置自動流入而不是重新鍵入；軟體授權席次追蹤，帶到期預警；以及財務當初自己另記一份台帳所要的那套折舊計畫。它隨Brocent託管IT服務一併提供，而不是單獨銷售的訂閱——這去掉了這類專案通常卡住的那個理由。

把這件事做對——資產資料、跨境傳輸，以及什麼時候該讓IT介入

在你上傳任何東西之前，有三點實務問題。

把這份匯出當成個人資料來對待，因為它就是。 一份帶「使用人」欄的硬體台帳，在中國《個人信息保護法》下屬於個人資訊——被識別的是裝置，但同時也識別了拿著它的那個人。緩解辦法是「夠用就好」而不是補文件：在檔案離開你的環境之前把使用人欄去掉或做假名化，用序號和資產編號來勾稽，事後在本地把姓名接回去。大部分勾稽邏輯本來就用不上姓名。

搞清楚處理發生在哪裡。 把據點台帳發給任何託管模型都是一次資料傳輸；如果檔案離開中國大陸，還可能是一次有額外要求的跨境傳輸。DeepSeek發布了可以在你自己掌控的基礎設施上運行的開放權重模型，這是「檔案不能離開本環境」時最乾淨的答案——如果你用的是託管API，請核對你實際所在層級的目前條款，而不是想當然，因為不同層級不同、條款也會變。

清楚你解決的是哪一半問題。 分析是便宜的那一半。實地把那些沒對上的裝置找出來、判斷哪些是真的不見了、修正財務台帳，然後把結果一直維持準確，才是真正的工作——而這正是我們的AI+支援服務和託管IT支援所承擔的。Brocent自2007年在北京創立以來一直在亞洲提供託管IT服務，總部位於新加坡，並自2016年起設有香港辦公室；每個據點各記一份清單的多據點中國資產盤子，是我們的常規領域。同樣的資料落地邏輯適用於任何內部AI工作負載——我們在中國合規的內部知識助理那篇裡講得更細。

常見問題

序號和使用人資料在PIPL下算個人資訊嗎？

「使用人」這一欄算，而且通常這一欄就足以把整個檔案帶進適用範圍。單獨的序號是裝置資料；緊挨著員工姓名的序號識別的是一個人。實務上的答案是：匯出前把姓名欄去掉，用序號和資產編號來勾稽——大部分比對邏輯本來就是這麼做的。如果姓名必須保留，就把檔案留在你自己的環境裡，用自架模型。

AI在資產序號上的模糊比對有多準？

正規化之後的完全比對非常可靠，因為它是決定性的——價值在正規化，而不在比對。基於部分序號、型號名稱和使用人姓名的模糊比對確實有用，但絕不能默默採信：要求每一筆候選都附上理由，並由人逐筆確認。把模糊比對的產出當成待複核的候選名單，而不是結論。

只出現在一份清單裡的資產該怎麼處理？

按它出現在哪份清單來分類，因為每一類的含義不同。在Intune裡但不在任何據點台帳上，說明台帳不完整；在據點台帳上但Intune從沒見過，說明這台裝置未納管、已報廢、或者已經不在了；只在財務帳上，通常意味著它被處分了卻沒人通知財務。前兩類是資料修正，第三類是一場沖銷對話。

這件事該多久做一次？

如果你是從表格出發勾稽，一季一次比較現實，一年一次則慢到沒有意義。但「多久做一次」本身就是個不該去最佳化的問題：一件你必須反覆做的勾稽，本身就是症狀。一旦領用和調撥在發生的當下就被記進同一個系統，這件事就從專案變成了抽查。

能不能不把資料發給託管的AI服務？

可以。DeepSeek發布了可以在你自己的硬體或你掌控的雲端執行個體上運行的開放權重模型，而勾稽這類工作負載很適合：它是批次處理、對延遲不敏感、也不需要用上最大的那個模型。在合約、法規或內部政策禁止把資產資料發給外部服務時，這就是標準答案。

這能取代一套資產管理系統嗎？

不能，而且把它當成替代品正是這件事最容易出錯的地方。它取代的是「在你能把資料裝進資產系統之前、本來要做的那一大堆人工清洗」——這本身價值很實在，因為通常正是這道清洗把專案卡住了。產出的是一份乾淨的基線；而系統，是讓這份基線一直為真的東西。

從哪裡開始

挑數字差得最離譜的那兩個據點，把它們的台帳和對應的Intune切片匯出來，只在這個子集上跑那四輪。這大概花兩個小時，而它會告訴你在投入更大動作之前值得知道的兩件事：你的各個來源到底差多遠，以及這個差距是資料問題還是實體問題。如果結論是資料清起來沒問題、但沒人說得清「總數」歸誰管，那就是那場值得開始的對話——聯絡我們。