如何用DeepSeek对账多站点IT资产台账

简而言之： 把各站点的资产表和Intune或AD设备清单一起导出，用大白话把字段含义和匹配规则描述给DeepSeek，让它统一序列号格式、跨来源匹配记录、并把每一处不一致标出来。你会在一天之内拿到一份站得住脚的一次性盘点结果。你不会因此得到任何能阻止这些台账再次分叉的东西。

问一位管着深圳、苏州、香港几个站点的IT经理：公司一共有多少台笔记本？你会得到一个数字。再问这个数字是怎么来的？你会得到三份格式各异的表格、一份Intune导出，以及财务那份和它们全都对不上的固定资产台账。

没有人在说谎。每一份来源都为不同目的而建、由不同的人维护、最后一次更新的时间也各不相同。站点清单存在，是为了让本地管理员能找到某台机器；Intune导出存在，是为了让设备能打上补丁；财务那份台账存在，是为了让资产能计提折旧。它们从来就不是为了互相对账而设计的，而在有人开口要一个全公司口径的数字之前，也没有任何力量逼它们对上。

在杂乱、来源不一致的记录之间做匹配，恰恰是语言模型真正擅长的事——不是因为它难，而是因为它是那种"人做一遍很容易、做一万遍必然出错"的容易。DeepSeek特别适合这件事，是因为源数据通常有一半是中文：站点表里"型号"和"使用人"这样的列，紧挨着英文序列号，日期格式各不相同，地点名称有三种写法。一个原生读得懂两种语言的模型省掉了一道翻译工序，而你每省掉一道工序，就少引入一类错误。

下面是一套可操作的方法——以及结尾处关于"它解决不了什么"的一句实话。

为什么没人说得清公司有多少台笔记本

四个原因，而且会叠加。

每个站点各记各的，格式还各不相同。 一个站点按序列号记，一个按资产编号记，还有一个按使用人姓名记。列不一样，表头语言不一样，而且至少有一份清单里有个合并单元格，把两台机器塞在了一行里。

这些清单是"出事才更新"的。 记录在采购时被添加，在出问题时被更新。而当一台笔记本被悄悄交给新入职的同事、被带到另一个站点、或者在某人离职后留在抽屉里时，没有任何机制会去更新它。

没有人对"总数"负责。 每个站点负责人对自己那份清单负责，而没有人对加总负责。一个没有任何具体的人被考核的数字，就是一个会漂移的数字。

本该解决这件事的系统，当初是为别的目的买的。 Intune和Active Directory知道的是那些会回连的设备——这就排除了关机的、被重装的、躺在库房柜子里的、以及压根没纳管过的。财务台账知道当初买了什么，之后发生了什么则一概不知。两者在各自的范围内都准确，出了范围就沉默。

后果不是抽象的。它表现为：因为没人信备机数量而重复采购；为两年前就报废的机器持续付许可费；以及一场内部的、ISO的或客户方的审计问询，花三周时间给出一个糟糕的答案。

把源数据整理成模型能对账的形状

准备工作占了大部分工作量，而且它并不技术。

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

先把你要比对的东西准确地点名，因为"我们有几张表"不算一个范围。

站点表格是"谁手上实际拿着什么"的事实来源，同时是其余一切信息里最不可靠的来源。它通常能把使用人和位置记对，因为那正是本地管理员需要的；而采购日期和型号名称往往记得很差。

Intune、Jamf或AD导出是"什么设备真的在运行、在回连"的事实来源。它在序列号、系统版本、最后在线时间上是权威的，而对一台从未纳管过的设备一无所知。

财务固定资产台账是"买了什么、账面价值多少"的事实来源。它在采购日期和成本上是权威的，经常把二十台笔记本记成一行，而且往往根本不带序列号。

在开始之前把这件事讲明白，因为它决定了当两份来源冲突时谁说了算——而正是这条规则、而不是模型，让产出站得住脚。

有哪些匹配规则必须显式写出来？

你不给规则，模型就会自己推断；而推断出来的规则，正是无声错误的来源。把它们写下来，放进提示词里。

序列号归一化。 去掉空格和连字符，明确大小写是否敏感，并说清楚那些被Excel加了前导单引号、或因列宽不够被截断的值该怎么处理。戴尔的服务编号、联想的序列号和苹果的序列号形状各不相同；说清楚你预期看到哪些。

跨语言的字段映射。 告诉它"序列号"和"Serial No."是同一列，"使用人"对应assigned user，状态列里的"已报废"意思是retired。这正是双语模型体现价值的地方——你是在描述一套映射，而不是把文件翻译一遍再祈祷中间什么都没错位。

什么才算匹配上。 序列号完全一致算匹配。资产编号相同但序列号不同是冲突，不是匹配。使用人相同、型号相同、但两边都没有序列号，那是候选——候选必须标记出来交给人判断，绝不能自动合并。

剩下的怎么办。 每一条没匹配上的记录都是一个发现，而这个发现是有类型的：在Intune里但不在任何站点清单上；在站点清单上但Intune从没见过；在财务账上但别处都没有。要求它按类型分开列出，因为每一类的后续动作都不一样。

让数据保持适度。一次硬件盘点不需要家庭住址、电话号码或HR工号——你导出的个人字段越少，之后要回答的合规问题就越小。

一次实际的对账流程——归一、匹配、标记、再人工复核

分四轮做，而不是问一个问题然后指望它。

第一轮——只做归一化。 一次只给模型一个文件，要求它输出一张干净的、统一表结构的表：序列号、资产编号、型号、使用人、站点、状态、采购日期、来源。先不要匹配。拿一个站点的输出跟原始文件核对一遍再往下走；如果归一化是错的，后面每一步都会继承这个错误。

第二轮——用强主键匹配。 要求它在归一化后的数据集之间做序列号完全匹配，并给出每个来源匹配上和没匹配上的条数。对不上的数字就是你的第一个真实发现，而且它通常指向归一化问题，而不是真的存在缺口。

第三轮——让它提出弱匹配。 现在要求它基于较软的信号给出候选匹配，每一条都要附上理由："资产编号相同、使用人相同，站点清单上缺序列号。"一定要坚持要理由。没有理由的候选清单是无法复核的；带理由的候选清单，一个称职的人大约每行一分钟就能过完。

第四轮——给异常分类。 要求把未匹配的记录按异常类型分组，每组附上建议的下一步动作：实地找机器、确认已报废、去追站点负责人、修正财务台账。

然后人工复核——而且要抽查匹配上的那部分，不只是异常。异常天然会被仔细看，因为它们看起来就不对；真正会被照单全收的，是那些看起来很有把握、其实是错的匹配。随机抽二十行匹配结果、回原始文件核对，这二十分钟会告诉你整轮结果值不值得信。

在四个站点上跑第一轮，现实的结果是：大部分记录能干净地对上，相当一部分落进候选池，还有顽固的一小撮是真正找不到的设备——那部分再怎么处理数据也解决不了，必须有人走进那个房间去看一眼。

一次性的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切片导出来，只在这个子集上跑那四轮。这大概花两个小时，而它会告诉你在投入更大动作之前值得知道的两件事：你的各个来源到底差多远，以及这个差距是数据问题还是实物问题。如果结论是数据清起来没问题、但没人说得清"总数"归谁管，那就是那场值得开始的对话——联系我们。