自动发现常被当成 CMDB 数据质量的解药：只要扫描器足够勤快，配置项就能自动入库、自动更新，人工维护似乎可以退场。这个设想听起来高效，却混淆了一个关键问题——发现工具能保证的是“设备存在且在线”，而不是“这台设备支撑什么业务、归谁负责、变更后影响谁”。而后者，恰恰是 CMDB 真正要回答的问题。
自动发现的边界，首先体现在它能采集什么。IP 地址、主机名、操作系统版本、CPU 和内存规格，这些属于设备自身的属性，扫描网络或调用云平台接口就能拿到，准确度也较高。但配置管理数据库里真正有价值的字段，往往不在设备上：某个应用属于订单系统还是结算系统，由哪个团队负责运维，处于生产环境还是测试环境，这些业务归属信息无法从设备本身读出。一台服务器上可能跑着多个应用，也可能同一应用横跨多台主机，扫描器看到的是资源清单，看不到服务拓扑和业务语义。
更现实的问题是，自动发现只能反映“当前时刻”的快照，而配置关系是动态变化的。应用版本升级、架构调整、资源迁移，都会改变配置项之间的依赖关系。发现工具可以捕捉到新增了一台主机，却很难判断这次新增是正式上线、灰度试点还是临时扩容；它能看到某个端口停止了响应，却无法确认这是计划内变更还是故障。如果团队依赖自动发现的结果来评估变更影响，而这些关系恰恰因为变更而失真，决策依据就建立在错误的数据之上。
这并不意味着自动发现没有价值。对于硬件资产、云资源这类生命周期相对清晰、属性可自动读取的对象，它确实是高效的数据来源，能显著减少手工录入和台账滞后。问题在于，很多团队把自动发现的结果直接等同于 CMDB 的完整数据，忽略了业务归属和服务关系这些核心字段需要人工确认。正确的做法，是把自动发现当作数据采集层，而不是数据治理层：设备层面的信息交给工具去同步，业务归属、责任团队、服务依赖关系则必须由熟悉业务和架构的人员来维护和核验。
数据质量的关键，从来不是录入方式，而是维护机制。自动发现解决的是“数据从哪来”的问题，而 CMDB 更常失败在“数据由谁负责、何时更新、如何核验”。一个可持续的机制，通常需要明确哪些字段以自动发现为准，哪些字段以人工确认为准；关键配置项的业务归属是否有人定期复核；发现结果与已有记录冲突时，以哪个来源为权威。这些规则不建立，自动发现只会让 CMDB 里的数据看起来很多，却未必更准确。
对实际建设而言，更稳妥的判断标准是：自动发现的引入，应当服务于具体的使用场景。如果事件处理时需要快速定位某应用由哪些组件支撑，那么关键服务的依赖关系就必须经过人工确认；如果变更评估时需要识别受影响的范围，那么服务与配置项的关联就不能只靠扫描结果推断。先明确 CMDB 要支撑哪些决策，再倒推哪些数据必须准确、由谁保证准确，自动发现才能在正确的位置发挥作用。