AI 数据库的发布会上，各家讲的是库内推理、向量检索、多模融合，性能数字一个比一个漂亮。但项目落地时最先卡住人的往往不是这些，而是库里的表没人写注释、口径没人定。
这篇把方法拆成三层，每层都给可执行的 SQL，最后给一组同模型对比数据。
一、问题不在模型，先看一个真实现象
第一个项目是政务数据平台，一百六十多张表，挑一个业务口试点。POC 那周演示很顺，领导问什么都能出一条 SQL，还能出个表。
第二周业务真用起来，投诉就来了。上机去看：SQL 语法没有任何问题，表名对、字段名对、能跑、有结果。问题是过滤条件用错了字段——业务问「有效用户数」，模型查的是 user_status = 1，而这张表里 user_status 存的是注册渠道编码，真正的状态字段是 is_valid。
模型没报错，它只是把这个字段当成了「用户状态」，因为这字段在库里连一句注释都没有，它只能靠名字猜。
报错的 SQL 你会去改，猜错的 SQL 会一路跑到会上。数字看着合理、格式规整、还标着来源库，业务同事根本看不出哪里错了。
把两年踩过的问题归类，其实只有三种：字段语义缺失、口径没有落处、指标没有归属。三件事里只有第三件勉强算模型问题，前两件纯粹是数据资产的事。
二、差距有多大，看一组公开评测
有一套现成数据能说明差距在哪：
| 评测场景 | 公开最好成绩 | 说明 |
|---|---|---|
| 学术数据集（干净 schema、字段名规范） | 约九成 | 常被引用来证明「NL2SQL 已解决」 |
| 真实业务库（脏数据、依赖外部知识） | 八成出头 | 人类数据工程师基线约九成三 |
| 真实企业数据仓（上千列、方言差异） | 六成上下 | 同一批模型，掉了三十个点 |
| 允许模糊提问、需要多轮追问 | 三成上下 | 问题一模糊就崩 |
同一批模型、同一套提示，从九成掉到三成。掉的不是 SQL 语法能力——现在的模型写语法几乎不出错；掉的是 schema 规模、方言碎片、问题歧义，而这三样正是企业真实环境最不缺的。
旁边还有一组扎人的对照：人工数据工程师在同一批真实题上做到九成以上。模型和人的差距，基本就是这个库里「有没有人把业务写清楚」的差距。
顺带说一句，榜单本身也有水分。2026 年有学术审计指出，部分公开评测集的标注存在相当比例的争议样本。榜单只能当方向，真正的准确率只能在自己库上跑出来。
三、第一层：把注释补上，两三天能见效
先补核心表，不用全库铺开，挑被问得最多的那十几二十张。我们团队的注释规范是这样：
| 项 | 写到什么程度 | 例子 |
|---|---|---|
| 表注释 | 一句话说清装什么、数据从哪来、多久更新 | 订单主表，来源交易库，日更 |
| 字段注释 | 业务含义 + 取值含义，枚举值必须列出 | 订单状态：0 待支付、1 已支付、2 已取消 |
| 单位与精度 | 金额是元还是分、是否含税 | 订单金额，单位元，含税 |
| 主外键关系 | 能对上的写清楚 | 关联客户表 customer_id |
| 废弃标记 | 不用的字段标出来，别让模型猜 | 已废弃，用 new_flag 代替 |
关键在枚举值。上面那个政务项目，只要在注释里写一句「注册渠道，1 官网 2 APP」，模型就不会把它当状态用。
补注释用的是普通 DDL，不依赖任何产品特性：
COMMENT ON TABLE biz_order IS '订单主表，来源交易库，T+1 更新';
COMMENT ON COLUMN biz_order.order_status IS '订单状态：0待支付 1已支付 2已取消 3已退款';
COMMENT ON COLUMN biz_order.amount IS '订单金额，单位：元，含税';
COMMENT ON COLUMN biz_order.user_status IS '注册渠道编码：1官网 2APP 3小程序，非用户状态';
COMMENT ON COLUMN biz_order.test_flag IS '测试单标记：1是 0否，统计时需排除';
字段多的时候别手写，用一段 SQL 把现状拉出来，生成待填清单，再分给熟悉业务的人填。
KES / openGauss / PostgreSQL 系：
SELECT c.relname AS 表名,
COALESCE(obj_description(c.oid), '') AS 表注释,
a.attname AS 字段名,
format_type(a.atttypid, a.atttypmod) AS 类型,
COALESCE(col_description(c.oid, a.attnum), '') AS 字段注释
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_attribute a ON a.attrelid = c.oid
WHERE n.nspname = 'public'
AND c.relkind = 'r'
AND a.attnum > 0
AND NOT a.attisdropped
ORDER BY c.relname, a.attnum;
MySQL：
SELECT t.table_name AS 表名,
t.table_comment AS 表注释,
c.column_name AS 字段名,
c.column_type AS 类型,
c.column_comment AS 字段注释
FROM information_schema.tables t
JOIN information_schema.columns c
ON c.table_schema = t.table_schema AND c.table_name = t.table_name
WHERE t.table_schema = DATABASE()
ORDER BY t.table_name, c.ordinal_position;
过滤「字段注释为空」的行，就是一张现成的任务清单。
四、第二层：把口径写成能被解析的形式
注释解决「这个字段是什么」，解决不了「销售额怎么算」。这层建一张指标定义表，把公式、时间窗、排除规则、归属人都写进去，再让语义层或提示词引用。
CREATE TABLE meta_metric (
metric_code VARCHAR(64) PRIMARY KEY, -- 指标编码
metric_name VARCHAR(128), -- 业务叫法
synonyms VARCHAR(512), -- 同义词，逗号分隔
formula TEXT, -- 计算逻辑
time_rule VARCHAR(256), -- 时间口径
exclude_rule VARCHAR(512), -- 排除规则
owner VARCHAR(64), -- 口径归属人
updated_at TIMESTAMP
);
INSERT INTO meta_metric VALUES (
'sales_amount', '销售额', '营收,销售收入,GMV',
'SUM(biz_order.amount)',
'按自然月，月初至月末',
'排除 test_flag=1；排除 order_status IN (2,3)',
'财务部-张', NOW()
);
这张表的价值不在技术，在于逼业务把话说清楚。以前口径散在 Word 和微信群里，现在至少能查到、有归属人、改过留痕。
举个真实的拆解。「上个月卖得最好的品类是哪个」，这句话有四个歧义点：卖得最好按 GMV、订单数、件数还是毛利？上个月按自然月、近 30 天还是财务月？退款单、测试单、赠品单算不算？品类取叶子类目还是二级类目？
四个点只要有一个没定义，答案就可能不一样。而模型不会问，它会猜。
五、第三层：语义放在哪，才开始谈选型
前两层都是数据活，这层才涉及产品选择。主流做法两类。
一类放在数据库外面，用独立语义层或指标平台承接。好处是跨源统一、指标治理成熟，代价是多一跳链路，权限要在第二套体系里再对齐一遍。
另一类把语义和元数据放回数据库这一侧。2026 年国内几家都在往这条路上走：金仓数据库 10 月发布的 KES AI 数据库把语义定义、向量推理、安全管控都做进了内核，元数据采集后由系统自动提建议、业务人员确认生效，语义和数据同库维护，表结构变更能同步感知。
六、同一个模型只改注释，结果差多少
最直接的对比来自第一个政务项目的一轮内部验证。同一套模型、同一批问题，只补注释和口径，模型侧一点没动。
| 阶段 | 可执行率 | 口径正确率 | 答案正确率 |
|---|---|---|---|
| 原始库（注释覆盖率约 30%） | 接近满分 | 六成上下 | 四成多 |
| 补完核心 20 张表的注释与枚举 | 接近满分 | 八成上下 | 七成多 |
| 加指标定义表 + 同义词 + 示例问题 | 接近满分 | 九成上下 | 八成五以上 |
说明两点：这是我们一个项目、一次内部验证，题量一百出头，样本不大，绝对数字别当基准。但趋势很清楚——可执行率一直是满的，掉的全在口径和答案上。
补注释那一步，两个人两周做完二十张核心表、一千一百多个字段。整个项目里投入产出比最高的就是这一段。
七、四个容易判断失误的地方
别一次补全库。我们试过，补到第三周就没人愿意干了。只补被问得多的表，剩下的按需补。
枚举值必须写。「状态」「类型」「标志」这类字段不写枚举等于没写注释，模型照样猜。
口径归属人写人名。写部门没用，出问题找不到人。
别把「SQL 能跑」当成「答案对」。这是验收阶段最常见的自我欺骗。建议拆三层验收：语法可执行、口径符合定义、结果与人工一致。第一层几乎必然满分，真正要盯的是后两层。
八、回到开头
这件事没什么技术含量，但它是 NL2SQL 从「能演示」到「敢用」之间绕不过去的一段。
模型每年都在变强，真实企业库上的成绩也一直在涨，但涨不到九成——库里没写下来的东西，模型永远猜不到，这部分只能靠人补。
如果问第一步该干什么：不是选模型，不是挑数据库，是打开你们的核心表，看一眼字段注释有多少是空的。那个数字，基本就是你 AI 数据库里 NL2SQL 这一块的天花板。
李白客，信创行业独立观察者。关注数据库、AI 基础设施与国产化替代。
