结论：元数据同步只是第一步
把数据库表名和字段名读出来，并不等于得到 AI 可用的数据模型。完整路径至少包括限定反射范围、采集结构事实、生成数据画像、确认关系与业务语义、形成版本化清单，再通过测试发布。语义清单的目标是让下游 Agent 使用经过确认的上下文，而不是让模型每次重新猜测数据库。
BuildTable 的公开能力方向覆盖多源连接、结构与关联、字段语义、指标口径和权限治理。本文给出的是实现这类能力的一般技术方法，不把尚未公开的内部实现细节当作产品承诺。
第一步：限制元数据反射范围
大型数据库可能有数千张表。全库反射不仅慢，还会把系统表、临时表和敏感表暴露给后续流程。应先按数据源、schema、表白名单和权限确定范围，并记录同步游标、开始时间和失败状态。结构采集至少包括字段类型、可空性、主键、索引和显式外键。
反射任务要支持超时、取消和断点恢复。元数据变化应做差异比较，区分新增、删除、改名和类型变化；不能每次同步都把人工描述覆盖掉。技术事实与业务注释最好分层保存，便于分别更新。
第二步：用画像补充字段事实
字段名常常不足以判断用途，需要采样或聚合得到空值率、唯一值比例、最小最大值、常见枚举和时间范围。这些画像有助于识别候选主键、状态字段和时间字段，也能发现全空列、异常格式和重复记录。
画像必须受资源和隐私约束。优先使用数据库侧聚合，限制样本量和执行时间；敏感文本不应原样进入模型上下文。画像结果还要记录采集时间，因为枚举和分布会随业务变化。
第三步：生成并审核语义清单
清单可包含数据集、表、字段、关系、指标、术语、质量规则和权限引用。AI 可以根据名称、画像和查询历史提出描述或关系候选，但主外键基数、指标公式和业务规则需要负责人确认。尤其要警惕名称相似但粒度不同的字段，例如订单金额与订单明细金额。
每条语义应带来源、负责人、状态和版本。草稿不能直接服务生产 Agent；发布前应运行结构测试、关系测试、指标样例和自然语言问题集。发生破坏性变更时，清单要能标出下游影响并支持回滚。
验收清单
验收可检查：同步范围是否可控，失败能否恢复，人工描述是否保留，敏感字段是否被排除，关系是否通过基数测试，指标是否有标准样例，20 个真实问题能否稳定选择正确对象，以及版本变更后能否追溯。连接成功只能算开始，能够解释、测试和治理才算 AI 可用。