直接切入正题。ECC到S/4HANA的迁移最让人睡不着觉的不是停机窗口不是ABAP兼容性也不是新UI让业务不习惯——是数据搬过去之后对不上账、丢了明细、主数据重复、历史凭证断链。我在几个项目里见过太多迁移团队花80%的精力搞代码适配和功能测试最后死在一张对不上的余额表上。这个标题里的AI驱动不是赶时髦。数据完整性校验在传统迁移里是个体力活加赌运气的事抽样核对、人工写ABAP报表比对、靠业务顾问拍脑袋说差不多。AI在这件事里真正能落地的地方不是替代SAP标准迁移工具而是在数据口径、字段映射、分布异常、主数据去重这些环节做全量体检。这篇文章就把我自己在项目里跑通的这套AI数据完整性校验层完整拆开讲适合SAP Basis顾问、数据迁移团队成员、企业数据架构师参考。看完你能直接照搬这套思路到自己的迁移项目里。1. 项目全貌ECC到S/4HANA迁移为什么数据完整性是那个绕不过去的坎1.1 这不是一次搬家而是一次拆了重装很多人刚接触S/4HANA迁移时容易低估数据层的工作量以为就是把表结构Copy过去再做下接口适配。实际上ECC到S/4HANA的数据迁移技术上更接近一次数据库层面的拆了重装。举几个最典型的例子。物料主数据在ECC里分散在MARA、MARC、MARD等多张表里到了S/4HANA虽然核心表还在但新增了物料凭证、库存、财务视图整合的新逻辑。财务这边变化最大ECC里的BSEG会计凭证行项目和BKPF凭证抬头在S/4HANA里被大量合并到ACDOCA通用日记账这一张表里表结构完全不同。更不要说客户主数据从KNA1/KNB1变成CUSTOMER/但内部逻辑大幅调整供应商也是从LFA1/LFB1变成SUPPLIER。这意味着什么字段一对一的映射根本不存在。你没法写一个简单的SELECT * FROM ECC_TABLE然后INSERT INTO S4_TABLE。你要梳理的是字段级映射关系、值转换规则、新旧表主键关联逻辑、自定义增强字段的搬运策略。任何一个映射关系搞错轻则某个字段到目标系统后为空重则整个财务凭证断链、库存数量金额对不上账。再说数据量的变化。如果你做的是一次数据迁移非Greenfield全新实施源系统往往是跑了五到十年的生产系统主数据百万级、财务凭证几千万甚至上亿行都很常见。在这种数据量级下光靠人工抽样核对核心表数据基本等于拿手电筒照着一片大海找漏。这就是为什么需要一套系统化、自动化的数据完整性校验机制而不仅仅是最后跑几个报表看下数平不平。1.2 数据完整性在迁移项目里到底指什么好多项目组嘴上挂着数据完整性但各说各话。我建议大家在项目启动第一天就把这个概念拆成四个明确维度维度含义典型问题场景完整性数据有没有丢、有没有多迁移后某个月凭证行数对不上一致性数据之间逻辑关系是否自洽总账余额不等于明细之和库存数量与金额不同步准确性字段值是否按规则正确转换币别转换错误、日期格式错乱、自定义字段值丢失及时性数据是否在切换窗口内同步到位增量数据未同步完就切业务导致漏单传统做法是靠SAP标准工具自带的校验功能加人工ABAP报表比对再辅以业务顾问的抽样验证。这套做法最大的问题不是不严谨而是太慢、太被动。等到迁完、切了生产、业务开始录单之后才在月结时发现科目余额不平这时候再回头查源系统数据、查映射日志、查转换规则成本就高了。AI的介入点恰恰就在这里——不是取代做数据搬运的迁移工具而是在校验环节给团队装上一个全量X光机让问题在切换窗口之前就暴露出来。1.3 AI在这件事里的边界它能做什么不该让它做什么先说清楚AI的边界可以避免项目组走向两个极端一个极端是觉得AI是万能药扔给它一堆数据就指望它把完整性全部搞定另一个极端是不信任AI觉得数据校验必须完全靠人工规则。我自己跑下来比较务实的定位是AI的职责是全量体检筛查、语义映射推理、异常模式识别、重复数据匹配辅助而最终的数据正确性判定权要留在业务规则和人工审核手里。具体点说AI在数据校验过程中不该做的事情包括不能因为它推断某个映射关系是对的就直接采用映射结果必须过一层人工或规则审批不能因为它检测出大量异常就直接决定暂停迁移异常列表要经过业务定性。AI在这套体系里的价值是筛选漏斗——用低成本的机器计算把海量数据里值得人关注的差异缩小到几十条几百条而不是替代人去拍板。这样定位的好处很明显技术侧容易落地业务侧容易给信任。毕竟你让CFO签字确认迁移后财务数据完整你得拿出来的是一份AI全量校验业务规则复核人工抽样确认三层报告而不是一句AI跑过了没问题。2. AI驱动数据完整性的核心设计四个真正能落地的校验场景2.1 场景一字段映射语义校验让AI做翻译质检员ECC到S/4HANA的字段映射本质上是把旧世界的字段含义翻译到新世界。传统做法是实施顾问打开映射Excel凭经验一条条填。这张映射表是整个迁移的核心资产但它的质量往往完全取决于顾问的经验和细心程度。AI能做的事情是把校验从一个经验活变成半自动化流程。具体做法是把源字段的技术名、数据元素描述、域值、业务含义说明以及目标字段对应的数据元素、表字段文档一起丢给大语言模型让模型给每个映射关系打一个语义合理度评分。如果一个映射在语义层面就明显对不上——比如源端一个交货日期字段映射到了目标端的订单创建日期AI会给低分并提示理由人工重点复核这批低分映射。我在实际项目里跑这个方案时一个几千条的字段映射表AI初步筛出约10%~15%的高风险映射让人工复核把顾问花在逐条核对上的时间压缩了将近一半。2.2 场景二数据分布差异检测让AI做全量X光机这是整套AI校验体系里我自己觉得价值最大、也最容易被业务认可的模块。思路很简单迁移前后每个核心表的核心数值型字段都应该保持统计分布基本一致。比如BKPF的凭证金额字段迁移前各月的合计、均值、分位数在迁移后应该对得上BSEG行项目里每个科目、每家公司的金额分布也不该有显著变化。AI模型可以把这个校验从抽样对比几个汇总数升级为全字段分布漂移检测。具体实现上我给每个关键字段计算一套统计指纹包括均值、中位数、标准差、四分位数、空值率、唯一值数量、Top 10高频值占比。然后在源端数据快照和目标端数据快照之间做对比任何超出阈值的字段都会被标记为分布漂移异常。这个方法最大的优势是它不依赖任何业务规则——不管表结构怎么改、字段怎么挪只要数据本质没变分布就应该稳定。我遇到过最典型的一个案例某个自定义表的一个金额字段在映射的时候被配置成了除100的转换关系单看几条数据根本发现不了但整个字段的分布全部左移了两个数量级AI直接把它标成红色异常人工一查就定位到了转换规则错误。2.3 场景三主数据重复识别让AI处理人与物的匹配难题S/4HANA的客户、供应商、物料主数据模型都有调整很多在新版本里新增了BPBusiness Partner概念的统一主数据。迁移过程中最烦的问题是本来在ECC里就是多条相似记录的主数据到S/4HANA里因为主键重构、编码规则变化可能被识别成重复也可能本应合并的反而漏了。传统方案是写一堆模糊匹配SQL或者靠业务手工清理效率低还漏得多。AI可以做的事是基于字段相似度给全量主数据打分具体包括文本相似度客户名称、地址字段的相似度计算编码规则相似度自定义编码的相似段关联字段一致性同一客户的税号、银行账号是否一致跑完这个打分之后系统输出的是疑似重复对清单按置信度排序。业务主数据专员只需要处理置信度高的那几百对不用再靠运气扫描数据。而且这套模型的产出还能反哺后续的主数据治理日常运营不只是一次性的迁移工具。2.4 场景四业务规则校验AI辅助规则编写与规则挖掘SAP系统里有很多数据完整性约束是隐含的、没有硬性数据库约束的。比如财务凭证的借贷金额必须平衡、物料凭证的数量×价格应约等于金额、总账余额等于明细行项目之和、自定义表的外键关联不能有孤儿数据。这些规则在迁移之后全都要验证一遍。传统做法是让ABAP顾问写几十上百个校验报表每个报表对应一条规则跑一遍输出差异数据。问题在于规则遗漏——你不知道你还漏掉了哪些隐含规则。AI在这块能帮两件事。第一辅助规则编写把校验目标描述给大语言模型让模型生成初始校验SQL或Python逻辑ABAP顾问拿去改造成生产级代码省掉从零开始写的时间。第二规则挖掘用异常检测模型扫描全量数据找出那些没有被任何校验规则覆盖但存在数据模式异常的字段组合——这往往是隐藏的完整性约束所在。我在实际项目里管这个叫完整性约束的再发现——迁移一次不容易顺手把源系统里埋了多年没人管的数据规则问题一起挖出来。3. 实操过程搭建数据基线快照与AI校验层的完整步骤3.1 用SAP标准工具抽取数据构建迁移前基线快照在搭AI校验层之前一般要先把源系统的数据完整抽出来做基线快照。这里说的快照不是简单导个Excel而是按表级别、带时间戳的完整数据落盘存到迁移项目专用的数据湖或数据仓库里。这一步是整个分层策略里最关键的一环。ECC侧的数据抽取我建议用SAP提供了RFC接口的表记录抽取方式或者标准的OData服务。数据量大、表数量多的话用SAP Landscape TransformationSLT做实时增量抽取更合适。需要注意的点是抽取时间点要统一避免从凌晨不同时点抽取导致表间数据自相矛盾如果业务对源系统负载有严格限制要分批抽、限并发绝不能因为做数据校验把生产系统拖慢所有抽取作业要记录详细的运行日志包括抽取开始结束时间、受影响记录数、异常记录ID方面后续溯源基线快照建好之后这个快照里面存了迁移前的完整事实后面的源端和目标端的AI校验、差异核对、业务确认都基于这个快照展开。3.2 用Python构建AI校验管道的四个核心步骤在实际项目中我偏好用Python构建整个校验管道因为第三方库生态齐全无论是数据处理pandas、polars、机器学习scikit-learn、PyOD、还是LLM API接入OpenAI SDK或本地部署的模型都能很好地整合。步骤一字段映射语义校验核心思路是让大模型基于字段元数据判断映射合理性。给模型传入源字段的单元格技术名、描述、数据元素、值域说明和目标字段的对应信息让模型输出映射置信度0到1和理由。示例如下from openai import OpenAI import pandas as pd client OpenAI(base_url你的模型服务地址, api_keyyour_key) def semantic_check(source_meta, target_meta): prompt f 你是SAP数据迁移专家。请评估以下字段映射在语义上是否合理。 源字段信息: {source_meta} 目标字段信息: {target_meta} 请输出: 1. 映射合理性评分(0-1): 2. 评分理由(一句话): 3. 建议(可选): resp client.chat.completions.create( modelyour-model, messages[{role: user, content: prompt}] ) return resp.choices[0].message.content # 读取字段映射表 field_map pd.read_excel(ECC2S4_FieldMapping.xlsx) # 对低置信度映射进行批量检查 field_map[semantic_verdict] field_map.apply( lambda row: semantic_check(row[source_meta], row[target_meta]), axis1 )这里要特别注意LLM打分结果不能直接决定映射的对错它的价值在于把明显有问题的映射捞出来让人工按优先级复核。我一般按LLM打分的低分区、中低分区、其他分区三档处理低分区100%人工复核中低分区按业务表关键程度抽样复核。步骤二分布差异检测对源端和目标端同一业务表的所有数值字段分别计算统计指纹再计算差异指标。这里放一段处理逻辑import pandas as pd import numpy as np def calculate_stats(df, numeric_cols): stats_dict {} for col in numeric_cols: series pd.to_numeric(df[col], errorscoerce) stats_dict[col] { mean: series.mean(), median: series.median(), std: series.std(), q1: series.quantile(0.25), q3: series.quantile(0.75), null_rate: series.isna().mean(), nunique: series.nunique(), sum: series.sum(), } return pd.DataFrame(stats_dict).T def compare_distribution(src_stats, tgt_stats, field, threshold0.15): src_sum src_stats.loc[field, sum] tgt_sum tgt_stats.loc[field, sum] # 相对偏差超过阈值触发告警 rel_diff abs(src_sum - tgt_sum) / abs(src_sum) if src_sum ! 0 else 0 return rel_diff, rel_diff threshold实际跑的时候不要只看sum多个统计维度一起看。我遇到过一个场景某字段的sum完全一致但std和q1/q3发生了明显偏移——原因是映射时把一部分月份的数据接错位了总数歪打正着持平了。只做总量比对就会放过这种问题。步骤三主数据相似度匹配主数据去重这块文本相似度是最常用的手段。对于客户名称、地址这类字段可以先做中文分词的Jaccard相似度和编辑距离的加权融合。更深入一点可以用embedding模型对客户名做向量化计算余弦相似度。但注意embedding模型对短文本的效果不一定比传统方法好尤其是公司名称这种带有自创词的场景。我建议优先试传统方法效果不满意再上向量化。from rapidfuzz import fuzz def fuzzy_match_pairs(df, key_cols, threshold85): candidates [] # 对候选键值对做批量模糊匹配 for i in range(len(df)): for j in range(i 1, len(df)): score fuzz.token_sort_ratio( str(df.iloc[i][key_cols[0]]), str(df.iloc[j][key_cols[0]]) ) if score threshold: candidates.append({ left_id: df.iloc[i][customer_id], right_id: df.iloc[j][customer_id], name_a: df.iloc[i][key_cols[0]], name_b: df.iloc[j][key_cols[0]], similarity: score, tax_id_match: df.iloc[i][tax_id] df.iloc[j][tax_id] }) return pd.DataFrame(candidates)这里没有追求特别复杂的算法因为主数据匹配的最终判定要靠人去拍板机器做到捞出来按置信度排好序已经比原来SQL硬比对了强很多。步骤四业务规则校验业务规则校验这块建议把常见规则固化成规则集用脚本批量执行每条规则输出通过/失败/警告三态结果。比如财务模块的平衡性校验-- 检查每个会计凭证的借贷是否平衡 SELECT bukrs, belnr, gjahr, SUM( CASE WHEN shkzg S THEN dmbtr ELSE 0 END ) AS debit, SUM( CASE WHEN shkzg H THEN dmbtr ELSE 0 END ) AS credit, SUM( CASE WHEN shkzg S THEN dmbtr ELSE -dmbtr END ) AS balance FROM bseg GROUP BY bukrs, belnr, gjahr HAVING ABS(SUM( CASE WHEN shkzg S THEN dmbtr ELSE -dmbtr END )) 0.01;这种SQL写完挂在定时任务里每天跑一次输出所有不平的凭证清单。AI在这里的加持主要是让LLM根据你提供的SAP表结构描述和目标端表结构自动预生成候选校验规则你只需要把业务侧确认过的规则固化成脚本库。遇到一些我知道不正常但说不清具体规则的情况再用孤立森林等异常检测模型扫数据找线索。3.3 一个准不停服、不丢数据的切换节奏参考搜索词里提到准不停服、不丢数据地迁移到云上来这套思路在ERP迁移场景里同样适用。真正的大型ERP切换不可能做到绝对零停机但可以做到近乎零感知。以我们做过的一个迁移项目为例整体切换节奏分为三个阶段第一阶段是数据预迁移。在切换前四到六周用SLT之类工具把ECC的历史数据全量同步到S/4HANA目标环境核心主数据和未清项优先同步。这个阶段业务照常在ECC跑S/4HANA只是影子环境。每一轮全量同步完成后都跑一遍数据校验管道记录分布差异、主数据重复、业务规则异常。第二阶段是增量追赶。切换前最后一到两天停止ECC的接口写入或者用短时锁定窗口比如周末把增量数据追平到S/4HANA。这里说的准不停服是指业务在锁定窗口内无法做新的单据录入但对外的报表读取、历史数据分析等服务不停。真正的写锁定一般控制在8到12小时以内具体取决于数据量和网络带宽。第三阶段是切换验证与并行期。切换完成后业务在新系统上开始录单同时把旧系统的历史数据保留为只读方便回退和数据追溯。在这个并行期内AI校验管道还要继续运行针对新增数据做实时一致性监控直到业务确认稳定后再关闭源系统写入权限、归档历史数据。迁移到阿里云ECS这类云环境的场景和上述逻辑高度一致只是底层IaaS的差异——在ECS上部署S/4HANA时要注意磁盘IOPS和网络带宽是否满足数据同步的吞吐要求EBS型的普通云盘大概率扛不住亿级行数据的同步压力尽量用SSD类型的云盘并做吞吐压测。压测人员拿jmeter对云上的S/4HANA网关接口或Fiori应用做高并发验证本质上是确认这个云环境能承载生产切换后的真实用户负载。4. 常见问题与排查技巧实录4.1 AI校验报出大量假阳性怎么办AI这套体系上线第一天最容易让团队崩溃的是异常列表哗啦啦几百上千条真要一条条看根本看不完业务部门一看这个结果就不信任AI了。我后来总结了一套三层收敛的处理办法。第一层把AI告警里能用业务规则确定是误报的先自动过滤掉比如某些表设计上允许空值率100%、有些字段在目标端本来就是新增字段不参与镜像对比这些要维护白名单。第二层把AI告警按严重程度降序排序只人工处理Top N。第三层每月跑一次告警复盘看看这轮AI提的异常里真正被业务确认的问题占比是多少低于某个比例比如10%就说明阈值太灵敏了要调宽松。三维阈值怎么确定我的建议是先用正常迁移样本跑一遍把异常数量的P90作为初始边界再根据业务确认率迭代调优。不要一上来就追求零误报那多半会把真正的问题也漏掉。4.2 迁移后财务对不上账的定位思路真遇到对不上账的情况先冷静别急着翻数据。三条线索按顺序查第一查源端和目标端的抽取时间点。很多时候对不上根本是两边的数据时间窗口不一致源端抽到昨晚的增量数据目标端只同步到前天自然对不上。先把这个时间对齐了再说。第二查映射日志。字段映射Excel里每一格变更都最好留痕映射表经过谁修改、为什么修改、审批人是谁这些审计信息是定位映射错误的钥匙。我在一个项目里遇到过目标端的金额字段被某位顾问好心加了条件逻辑导致某些类别凭证的金额被重置为零AI分布检测早就标红了但因为当时业务没做逐月对比拖到月结才爆雷。第三查数据转换规则。S/4HANA的迁移过程天然带上很多转换逻辑像币别转换、公司代码标准化、资产编号重新分段等。如果源端和目标端的原始字段值都能对上但汇总数据对不上那大概率问题出在转换规则漏配或配错。排查工具方面我强烈建议所有校验脚本跑出来的差异结果都导出到一张审计表里包含异常类型、涉及表、涉及主键、源端值、目标端值、AI置信度、处理人、处理状态。这张表本身就是最有力的回溯证据。4.3 数据抽取时源系统负载过高怎么办做迁移校验最怕的一件事就是给源系统造成过大压力。你这边跑抽取作业抽得欢那边业务在催单录不进去锅肯定甩到你头上。我的实操经验是分三条线控制。第一并发控制抽取作业按表大小分优先级小表先抽、大表后抽同一时间段只跑有限个抽取并发。第二批处理窗口尽量把大表抽取放到业务低峰期凌晨或周末避免白天跟在线业务抢占数据库资源。第三通知机制上线前跟源系统管理员建立通知通道一旦源系统负载超过阈值就立即暂停抽取任务等回落再继续。SAP侧如果用了SLT做增量一定要注意SLT本身也会在源系统装触发器如果触发器写得不好或数量过大会影响源系统的DML性能。一个高质量的SLT配置触发器的开销应该是完全在可接受范围内的但如果源系统本身就是一台老爷机那就要考虑改用基于时间戳的增量轮询方案而不是直接上触发器。4.4 校验结果如何让业务部门签字确认数据完整性校验的报告最终是要让业务负责人签字的。你拿一份几千行的异常清单让人签人家肯定不签。要让流程顺畅校验报告需要分层设计便于阅读第一个层次是一页纸摘要。核心表总数、数据总行数、映射规则总数、异常总数、已确认的业务问题数、待复核数、风险等级判定。这一页直接钉在验收报告的封面上签字人只看这个就够做初步判断。第二个层次是问题明细清单。所有未关闭的异常项按业务模块分组逐条列出影响描述和当前状态。这一层给的是业务模块负责人去逐条确认。第三个层次才是全量比对结果背后的大型数据表给审计和后续追溯使用签字人一般不需要看。我的经验是凡是让业务签字确认的报告尽量展示AI辅助、人工复核、规则兜底三个要素。这样业务既觉得你用了新技术做得仔细又有明确的人工环节给它的信任背书。纯粹甩一份AI说没问题的报告业务是绝对不会给信任的。5. 一些工具选型与项目推动中的避坑心得5.1 迁移工具和AI校验层的关系别搞成谁替代谁SAP官方和第三方厂商提供了很多迁移工具比如S/4HANA Migration Cockpit、LTMC、LTMOM还有SNP的CrystalBridge等。有些项目组拿到一个工具就想把所有事都干完结果发现工具自带的校验功能都很基础——通常是对比记录数、对比关键汇总值最多做做字段必填检查。AI驱动数据完整性校验和这些工具不是替代关系而是互补关系。它们的定位是数据搬运和基础校验数据的深度校验工作交由AI层完成。我建议的架构是数据搬运通道用LTMC或SNP CrystalBridge做全量和增量基础校验层用迁移工具自带校验ABAP校验报表做必须的硬规则检查AI深检层用自建的Python管道字段语义映射、分布差异检测、主数据匹配、异常检测做全量兜底业务复核层AI标红的结果交给业务确认形成最终的数据完整性报告这套架构没有新造轮子也没有盲目堆技术每一层各司其职项目推动起来阻力最小。5.2 生成式AI写数据校验脚本能省一半时间但别跳过代码审查我在上个项目里用LLM辅助生成了差不多40%的校验脚本初稿。LLM在生成给定源表结构和目标表结构写一个字段级对比SQL这件事上效果确实不错。但用归用有两条红线必须守住第一LLM生成的SQL必须经过ABAP或数据开发人员review才能进生产。LLM对SAP特有的表结构理解经常有偏差比如对BSEG和ACDOCA的字段映射并不总是准确跑出来的SQL可能漏掉关键的租户字段。第二所有LLM生成的脚本必须纳入版本管理。你说不清后面哪条校验规则是AI写的、哪条是顾问手写的出问题的时候找谁review、谁backup都很混乱。版本管理挂钩到人责任才有归属。5.3 迁移后别忘了用压测验证数据环境双重承载能力数据搬到目标环境之后就算校验全过了也不代表系统真的能跑得动。这里特别提一下搜索词里提到的jmeter压测的场景——迁移完成后压测人员会用jmeter对核心接口做高并发测试验证云上环境的承载力。这条经验在ERP迁移上同样适用。S/4HANA切到生产环境后如果出现性能问题业务的第一反应就是数据迁移是不是搞坏了什么东西。实际上很多性能问题的根因是数据分布变了——S/4HANA的ACDOCA表汇聚了所有财务数据一张表的体量比ECC时代大了好几倍不提前做压测很容易在月结场景直接卡死。实操建议是迁移完成验证之后别急着关项目至少留出一到两周做切换后性能观察期。期间的核心任务是把月结、报表运行、接口批处理这些重负载场景在一台隔离测试环境上做全量压测压力模型尽量贴近真实生产比如并发用户数、接口请求频率、批处理数据量。压测发现的性能瓶颈该调索引的调索引、该调SAP参数的调参数、该扩ECS配置的扩配置都要在业务真正切过来之前调完。我见过一个客户因为漏了这一步切完第一个月结就死机资产负债表报表跑了十四个小时没出结果最后所有业务部门连夜加班补数教训太深刻了。5.4 完善数据完整性校验结果追溯表给项目留一条后路最后一定要建一张贯穿始终的数据完整性校验结果追溯表。这张表记录每一次校验跑批的时间、涉及数据范围、校验类型、异常数、处理责任人、关闭时间。它有几个作用项目结束后做数据完整性命门审查要它业务后续发现数据问题回溯时找它如果出了问题责任界定也要靠它。6. 写在后面实战下来最值钱的一条经验这套AI驱动的数据完整性校验体系我在第一个项目里花了快三个月才搭出雏形在后续项目里复制这套方案从零到跑通大概只需要两到三周。最大的成本不在模型不在代码而在业务规则的定义与人工复核流程的建立。如果业务部门不愿意分配资源做异常确认这套体系跑得再响也没人认。所以我特别想跟你分享的是一条经验把AI校验层当作业务部门的数据质检员而不是IT团队展示AI能力的玩具。尽量在设计阶段就拉业务进来看AI产出的异常样例让他们确认哪些异常是他们关心的、哪些是噪音。业务确认的越多这套东西的价值就越大越到后期越顺。另外一个细节如果你在项目里碰到那种AI跑出来的分布异常业务却说是历史遗留问题一直不改的情况别硬推。记录下来标成已知风险待关闭让业务在验收报告上签字确认这个风险已告知。这既是保护自己也是专业性的体现。数据完整性这件事实在是平时没人念你的好出问题全找你的事。把AI这层兜底做好迁移项目才会真正让人安心。