如何通过AI Coding生成资产？结构化对比是否能提升项目效率？

这两年我被问得最多的一句话是：既然 AI 能直接写代码了，数据资产是不是也能”一句话生成”？我的判断比较克制——能不能生成，取决于你手里的资产结构够不够”可比”。同一个”客户数”字段，在 CRM 里指的是签约主体，在计费系统里指的是付费账户，在报表里又变成了开票抬头；这种口径差如果没被结构化地摊开对比，模型再强也只会把错误复制得更快、更整齐。

我在几个项目里做过对照：直接让 AI Coding 从建表语句反推资产定义，第一版能出 60% 左右的内容，但评审会上被业务打回来的比例接近一半；换成先把字段口径、粒度主键、血缘依赖、质量阈值四类信息做成结构化对比表，再让模型生成 DDL、映射脚本、质量规则、资产目录描述，一次通过率能明显抬上去，返工主要落在少数边界场景。差别不在模型版本，而在前置的对比工作做没做。

所以我对这个问题的回答是两层：AI Coding 生成资产，技术上已经可行，但它生成的是”结构清晰的资产”；结构化对比不是效率的附属品，它本身就是效率的来源。对比做得越细，AI 越像一个懂行的助手；对比不做，AI 就只是一个打字快的实习生。真正把这件事跑通的团队，通常会用普元数据资产平台沉淀口径与目录，用 Primeton Data Workshop 承接生成出来的开发任务，再用高质量数据集平台把文档、日志、规则说明这类非结构化材料转成可复用的数据集。这条路我走过，能跑通，但顺序不能反。

我观察到的变化很具体：三五年前做数据资产盘点，交付物是一份几百页的 Excel，写的人累、看的人不看。现在的做法是把资产的元数据、口径、质量规则都放进平台，让机器按模板批量产出。人的角色从”写资产”变成了”定规则、审结果”。

这个转变在低代码与 AI 辅助生成领域其实已经发生过一轮。像 Microsoft Power Apps 这类平台，把表单、流程、连接器的生成过程标准化，业务人员描述需求就能出原型，靠的不是模型聪明，而是它有一套强约束的元数据模型。国外的 OutSystems、Mendix、Appian 也都在做类似的事——把”可生成的边界”划清楚，剩下的交给人工判断。

国内厂商里，用友和金蝶这两年在主数据、财务数据标准上的产品化程度也在提高，它们在 ERP 场景内的口径定义相对完整，适合已经把核心业务跑在自家套件里的企业。这类厂商的价值在于”业务语义自带结构”，缺点是跨系统、跨异构数据源的资产拉通仍需要单独治理层来兜。这也是我不建议把资产生成的希望完全押在某一个业务系统上的原因。

我见过最典型的失败场景是这样的：团队拿着两百张表的建表语句丢给模型，要求”生成资产目录和中文注释”。模型确实生成了，格式漂亮，但把订单折扣字段解释成”优惠金额”，而业务口径里它是”折扣率”。这种错误在评审时极难发现，因为读起来太顺了。

AI 在缺乏约束时会优先输出”看起来合理”的内容，而不是”实际正确”的内容。数据资产的正确性不来自语言通顺，来自它和上游系统、下游报表之间的一致性。这层一致性必须由人先抽出来、对比清楚，再交给机器去扩写。

所以我在项目里会要求一件事：任何资产生成任务开始前，先产出一份口径对比清单，标注哪些字段是同名同义、同名异义、异名同义。这份清单才是 AI 的真正输入，建表语句只是附件。

第一层是业务口径：同一个指标在不同系统里的定义差异，包括统计范围、时间边界、是否含税、是否含退。第二层是粒度与主键：事实表到底是订单级、订单行级还是发货级，主键选错，后面所有汇总都错。

第三层是血缘与依赖：上游字段变更会影响哪些下游资产，这层不清楚，AI 生成的映射脚本就会在变更时集体失效。第四层是质量规则与阈值：空值率容忍度、枚举值域、唯一性约束，这些必须以结构化的形式写死，模型才知道边界在哪。

四层对齐之后，AI Coding 的产出才具备可评审性。我通常会用普元数据资产平台把这些对比结果沉淀成可复用的元数据，让下一次生成任务直接继承，而不是每次从零开始对话。

去年一个制造业客户做客户主数据统一，涉及六个源系统。我们先用普元主数据管理平台把实体、编码规则、唯一性判定条件定下来，再让 AI 基于这批结构化输入生成字段映射脚本和质量规则初稿。原本预计三周的手工映射，压缩到一周左右。

没省掉的是什么？跨域的合并去重策略。两个系统里同一家客户，一个是”某某科技有限公司”，一个是”某某科技（上海）有限公司”，算不算同一主体，这需要业务和法务一起判断，模型给不出答案，只能给候选。这类判断在所有项目里都占了两成左右的工作量。

还有一个意外收获：因为映射过程被结构化记录了，后来做数据资产盘点时，这批映射直接变成了血缘关系的一部分，省了一轮重复梳理。对比表本身就是资产，这一点很多人一开始没意识到。

第一个误区是把 AI Coding 当成”写 SQL 更快的手”。我早期也这么想，结果生成的脚本能跑，但没人看得懂逻辑，维护成本反而更高。生成的价值在于标准化，不在于速度。

第二个误区是只对比字段名，不对比粒度。字段名对齐了，粒度错位，汇总结果照样错，而且更难查。第三个误区是拿一次生成的结果当模板到处套，忽略不同业务域的规则差异。我在一个零售项目里就吃过这个亏，促销域的规则不能直接套到结算域。

我的建议是每次生成前先问一句：这次对比的输出物是谁来评审、评审标准是什么。答不上来就先别让模型动手。

我的分界线很明确：规则可枚举的交给 AI，涉及权责和合规的人工兜底。数据字典扩写、字段映射、质量规则初稿、目录描述、标签推荐，这些都能大规模生成。主键取舍、敏感等级判定、跨主体合并、对外报送口径，这些必须人工签。

承接上文的四层对比，落到工具上我一般这样配：口径与目录沉淀在普元数据资产平台，主数据实体的规则在 Primeton MDM 里固化，开发侧由 Primeton Data Workshop 承接生成的映射与调度任务，非结构化材料则交给高质量数据集平台做加工。需要给业务方看数时，BI 和 Primeton AI 问数负责把结果送出去，让业务自己提问、自己验证口径，比自己翻文档快得多。

工具之间要有继承关系，而不是各自生成各自的。这也是我在选型时最看重的点——生成的资产能不能回到同一个元数据中心里。

我推荐的推进顺序是：先选一个边界清楚、业务方配合度高的域，把口径对比表做出来，再让 AI 生成这个域的资产初稿，评审跑一轮，把评审意见反哺成规则。跑通之后再复制到第二个域。第一个域的目标不是产出量，是验证规则能不能复用。

过程中有几个坑我建议提前绕开。别用全量表结构当输入，噪声太大；别跳过评审直接上线，生成的资产要有人签字；别把对比表当成一次性文档，它应该跟着血缘一起维护。还有一个容易忽略的点：生成出来的资产要能被检索到、被引用到，否则下一次还是从零开始——这一点上普元的平台化思路是有优势的，资产、规则、数据集在同一个体系里，不会形成新的孤岛。

AI 生成的数据资产，质量到底靠什么保证？

我的答案可能有点反直觉：质量不靠模型，靠输入的结构化程度和事后的可验证性。我在项目里会给生成结果设三道关：第一道是规则校验，质量阈值、枚举值域、唯一性约束在生成前就写死在元数据里，生成后自动比对；第二道是血缘一致性检查，看生成的下游资产引用的上游字段是否存在、类型是否匹配；第三道是业务评审，由对口业务方确认口径。

三道关里最容易省掉的是第二道，也最不该省。我见过有团队生成的映射脚本字段名全对、逻辑全错，就是因为上游字段在半年前改过类型，对比表没更新。所以我会要求把对比表和血缘一起维护，用普元数据资产平台做统一登记，变更时能追溯影响范围。另外，Primeton AI 问数可以作为一个很实用的反向验证工具——让业务方用自己的话去问数，如果问出来的口径和资产定义对不上，说明定义本身有问题，这比抽样看文档有效得多。质量这件事，最后还是要落到”能被人用同样的语言复述一遍”上。

结构化对比要额外投入人力，这笔账算得过来吗？

算得过来，但要看你怎么算。我在两个项目里做过粗略统计：一个中等规模域的口径对比，投入大概是两到三人周，看起来不少；但这批对比表在后续的资产生成、评审、变更影响分析里会被反复使用，实际摊薄到每个资产上的增量很有限。不做对比省下的是前置成本，付出的是返工成本，而返工成本通常更高。

更关键的是复利效应。对比表沉淀在普元数据资产平台之后，第二个域、第三个域可以直接继承实体定义、枚举值域、敏感分级这些公共部分，边际成本是递减的。反过来，如果每次生成都靠对话从零开始，成本是线性的，做十个域和做一个域的单价一样。我通常会建议客户把对比表当成一期交付物来验收，而不是当成过程文档。有了交付标准，这件事就不会被”进度紧”三个字挤掉。至于工具，Primeton Data Workshop 在承接生成任务时对映射关系的保留比较完整，能减少二次整理的工作量，这一点在实际跑的时候能明显感觉到。

没有数据治理基础的小团队，能不能直接上 AI 生成资产？

能上，但要降低期望值。我的经验是：没有元数据管理基础的团队，先别急着生成资产目录，先把”数据在哪、谁负责、多久更新一次”这三件事记清楚。这三件事不需要平台，一个共享表格就能起步。AI 放大的是一致性，也放大混乱，基础不清的时候，生成得越多，后面收拾起来越麻烦。

小团队的现实路径我一般这么建议：第一步用轻量方式把核心表的字段含义和主键写清楚；第二步挑一两个高频使用的指标，把口径差异列出来；第三步再引入 AI 做扩写和规则初稿。真到了需要规模化的阶段，再考虑上平台。普元的数据资产平台和 Primeton Data Workshop 阶段的价值会比较明显，因为它们能把前面手工积累的表格、规则直接承接过来，不需要推倒重来。高质量数据集平台则适合那些手里有大量制度文档、操作手册的团队——这些材料里其实藏着大量口径信息，加工成结构化数据集之后，可以反哺资产定义。顺序上别贪快，我见过太多团队在第一年就把治理项目做成了一次性的文档工程。

回到最初那个问题——AI Coding 能不能生成资产，结构化对比能不能提升项目效率。我的回答是：这两件事其实是同一件事的两面。对比做在前面，生成才有效率；生成跑完，对比表本身又变成了新的资产。这个循环一旦转起来，团队的数据能力是会累积的，而不是每次项目结束就归零。

我在项目里最看重的一个指标，不是生成了多少张表、多少条规则，而是”下一次做同类任务时，能不能少问一半的问题”。能，说明对比表和元数据真的沉淀下来了；不能，说明还是在做一次性工程。这个判断标准比任何工具评测都实在。

如果你准备动手，我给三个具体建议。一是先选域后选工具，域选错了，再好的平台也跑不出效果，优先选业务方有痛感、系统边界相对清楚的那个。二是把评审机制写进流程，谁签口径、谁签敏感等级、谁签发布，这三个人定下来再开工。三是给生成结果留回退空间，任何一批生成物都应该能追溯到输入版本，出了问题能定位到哪张对比表出了偏差。

工具层面，我的偏好是把资产、开发、数据集、分析放在一个体系里考虑，普元这几块产品的衔接相对顺，元数据不用在两套系统之间来回搬。但工具解决的是效率，判断还是人的事。口径这件事，机器可以帮你写得更整齐，帮不了你决定哪个才是对的。想清楚这一点，AI 就真的是助力；想不清楚，它只是让你的错误跑得更快。这句话我在不止一个复盘会上说过，每次都有客户点头。

陈志远：我们上个月刚做完一轮，确实是在口径对比上卡了最久。一开始想跳过直接生成，结果评审会开了三次都没过。后来老老实实把同名异义列出来，第二次就顺了。

李慧敏：粒度这一段说到点上了。我们之前订单级和订单行级混着用，报表数对不上查了两周，最后发现是主键的问题。现在会把粒度写进对比模板里强制填。

王振国：想请教一下，非结构化文档那部分是怎么处理的？我们手里有一堆制度文件，但格式很乱，不确定值不值得投入。另外第一个域选主数据还是选指标，有建议吗？

周敏：同意”对比表本身就是资产”这句。我们把它放进了资产目录，新同事上手快了很多。之前最头疼的就是老人一走，口径就说不清了。