一、领导在群里甩了一张表
先讲一个上周刚发生的事。
领导在群里@我:"今年年初上报的资产表跟平台目前录入的有出入,请查明原因。"
按照三个月前的我,这事大概率要这么干——打开 Navicat、连上数据库、对照 Excel 一行行肉眼比对、写几条 SQL、再把结果整理成 Word 发回群里。运气好两小时,运气不好一下午。
但这次我没这么干。
我把那张资产表和领导的原话,直接丢给了 OpenClaw(中文社区里大家叫它"小龙虾")。它连上数据库跑了一圈,过了几分钟,给我返回了两个原因:
问题一:某栋大厦面积不一致,平台 106㎡ vs 检查表 140㎡,差了 34㎡。可能是口径问题——平台登记的是套内使用面积,检查表用的是建筑面积;也可能是 B1 和 B2 两个单元,平台只登记了其中一个,检查表把两个合起来了。账面原值也能印证这个推测:平台 655.07 万,检查表 638.93 万,接近但不完全一致。
问题二:有 2 处合计 31.81㎡ 的房产在检查表中完全缺失。这 2 处在平台上有完整登记,产权清晰、两证合一、有账面原值合计 268.78 万元,所属单位也写得明明白白。但检查表里(无论是具体填报还是汇总),全部 44 条记录翻遍了都没有。属于明显的漏报。
我拿着结论去线下核对了一下——就是这两个问题。
那一刻我突然意识到,我前两年熬夜加班搞的那个"智能问数"项目,可能从立项的第一天就走错了方向。
这篇文章想聊聊这件事。我会从三个角度展开:过去我体验过的工具、我自己折腾问数的那段血泪史、以及为什么我现在觉得 Agent 是这件事的最优解。
二、那些年我们追过的问数工具
第一次听到 Text2SQL 这个词的人,基本都会觉得这玩意儿神了——数据库工程师和分析师可以下课了。
用户问一句"某家公司有多少不动产?",大模型理解问题、自动写 SQL、数据库跑一下、答案出来,顺带还能给你分析一波数据和未来趋势。看起来非常丝滑。
这也是 Text2SQL 曾经很火的原因:它把"查数据库"这件事,包装成了一个非常自然的 AI 交互场景。不会写 SQL 的人,也能像聊天一样问数。
在 2026 年的今天之前,开源社区已经涌现过一大堆 Text2SQL 工具:国产的飞致云 SQLBot、国外的 Vanna.ai、AskYourDatabase 等等。
国产里 SQLBot 我个人体验下来算是最友好的。它采用了符合国人习惯的交互方式——类似 ChatGPT 的问答模式,支持快速配置数据源、后台术语和 SQL 示例,输出还能直接渲染成图表。普通业务人员稍微培训一下就能用。
至于 Vanna.ai 和 AskYourDatabase,当时确实给了小小的我一个大大的震惊 🤯。高深程度和愿景都很美好,但真上手——不是科班程序员出身的我,看到一堆 API 和代码配置就头大,真不如一剑杀了我痛快。更何况当时还没有 Claude Code、Codex 这种神器傍身,光看文档就心累,更别说真正落地了。
但话说回来,真正把这些工具放到业务现场之后,我反而越来越觉得:
Text2SQL 最难的地方,可能根本不是"把中文翻译成 SQL"。
真正难的是——怎么把一个业务问题,稳定地翻译成一条正确、可解释、可执行、可复盘的 SQL。
这两件事听起来很像,实际差很多。
比如用户问"富吉股份有多少不动产?",这句话里至少埋了几个坑:
-
"富吉股份"是不是数据库里的标准公司名?有没有同名、简称、别名?
-
"不动产"的业务口径到底是什么?
-
如果用户下一句追问"那江苏的呢?",系统还能不能接得住?
-
如果模型写错 SQL,会不会查出一个看起来很合理但其实完全错的结果?
后来我才慢慢意识到,问数系统不能只靠"模型会写 SQL"。
因为在真实业务里,最危险的不是模型不会答,而是它答得很像真的。
三、烂尾的 8000 块
今年春节后,中国互联网突然火了一个叫 OpenClaw 的东西。我下载玩了几天,觉得没啥意思就卸了——当时的我,还把它当玩具看。
然后我一头扎进了自研问数工具的大坑。
SQL 标准化、大模型返回内容的 SQL 提取、后台配置功能……一项一项硬磕。最离谱的是,我还跟公司申请了一台 8000 元/月的云服务器,准备搞本地化模型训练。那段日子,加班到一两点是常态,周末基本都给了显卡。
但是测试阶段我就开始有不祥的预感了:
-
大模型太"礼貌",时不时给你多生成点没让它写的内容;
-
SQL 飘忽不定,同一个问题问两次能给你两版完全不同的写法;
-
修正和补缺的工作量大到让人头皮发麻。
然后……我品尝到了开发生涯中第一次"项目烂尾"的滋味。那个项目现在还躺在我 Mac 的时间机器备份里,像一座小型墓碑。
8000 块的服务器,几个月的加班,换来一个我自己都不敢上线的玩意儿。
四、小龙虾的逆袭
不久后的某一天,公司发了一波 Token,本着"白嫖不嫖白不嫖"的心态,我把 OpenClaw 又下了回来。
一开始也没想搞什么大事,就跟它吐槽自研问数有多痛苦。聊着聊着我突然冒出一个念头:
如果让小龙虾连上数据库,它能做什么?
但彼时我对它的态度,仍然是"不信任、但愿意试试"。所以我没有让它自由发挥去写 SQL,而是给它做了一个叫 wen-shu 的 Skill 包,里面包含:
-
Skill.md主文件:问数工作流说明、工具调用方式、业务知识和术语 -
一份公司名单
-
之前本地训练用的"问答-SQL"对
-
几个我自己写的
.py脚本
插一句:个人玩家其实根本不用准备这么多。直接让 OpenClaw 连数据库、再把业务术语丢给它当 context 就行。我搞 Skill 包纯粹是因为想做得工程化一点,有点强迫症的味道。
我设计的核心链路是这样的:
用户提问 → 公司名标准化 → 模板召回 → 安全执行 SQL → 返回可理解结果
对应三个脚本:
normalize_company.py → find_template.py → query.py
听起来有点技术,我一段段拆给你看。
第一步:不是写 SQL,而是先搞清楚——你到底在问谁
回到那个例子,用户问:"富吉股份有多少不动产?"
系统不能马上开始写 SQL。因为"富吉股份"可能只是简称,不一定是数据库里真正存的全称。
normalize_company.py 会去公司名清单里做匹配,处理简称、别名、以及去掉"有限公司""集团"等后缀之后的写法。最后返回四种状态之一:
-
exact:完全匹配
-
resolved:通过简称/别名找到了标准名
-
ambiguous:有歧义,需要用户确认
-
no_company:没找到
如果能确定,就把问题改写成 {标准公司名}有多少不动产?;如果有歧义,就先停下来,不继续猜。
这一步是很多 Text2SQL Demo 直接跳过的。但在企业场景里,第一步从来不是写 SQL,而是确认对象——你到底在问哪家公司。
第二步:也不是让模型从 0 写,而是先找最像的业务模板
这是我这条路线和传统 Text2SQL 最大的不同。
在 wen-shu 里,find_template.py 会先从已有问数模板里找最接近的一条。我目前的本地实现里大概有:
-
505 个公司名参考
-
近 9 万条问数模板(绝大部分是让 Codex 基于真实业务问法批量扩写的,核心 SQL 经过人工校验)
这些模板里不只有自然语言问法,也有对应 SQL。也就是说,系统不是每次都让模型重新发明一遍 SQL,而是优先复用已经验证过的业务经验。
举几个例子:
-
"某公司有多少不动产?" → 数量类,套
COUNT(*)的模板 -
"某公司有哪些不动产?" → 明细查询
-
"某公司不动产总额是多少?" →
SUM(...) -
"排名前 5 的是什么?" →
ORDER BY ... LIMIT 5
模板召回这一步,本质上是把"模型会不会胡写 SQL"这个问题,变成了"系统能不能从已有经验里找对模板"。
压力不再全压在大模型身上。它更像一个业务助理:先识别问题、再匹配流程、最后才执行。
为什么这套在企业场景里更靠谱?因为领导真正关心的是这三件事:
-
这个口径对不对?
-
这条 SQL 能不能复用?
-
结果错了能不能查原因?
这三件事,单靠 Prompt 真的解决不了。
第三步:才是执行 SQL,而且我把它收得很紧
query.py 只允许执行一条 SELECT。不允许写操作、不允许多语句、数据库连接从固定配置里读。执行完之后,再按结构化结果返回。
目的很直接:
OpenClaw 可以帮我问数,但它不应该拥有"随便操作数据库"的自由。
很多人聊 Text2SQL 时,注意力都放在"生成 SQL"上。但真要落地,SQL 生成只是其中一环。更要紧的问题是:能不能安全执行?能不能限制权限?能不能避免模型乱跑?能不能在出问题时复盘?
一个问数系统如果只能在 Demo 里跑得很漂亮,但进了真实数据库就让人心里发毛——那它离生产可用还差一光年。
五、智能问数产品 vs Agent 问数
如果拿这条路和 SQLBot 这类产品对比,差别我觉得可以这么理解:
传统 Text2SQL 路线,做的是——让大模型直接学会问数。
OpenClaw + wen-shu 这条路,做的是——让大模型先学会遵守一套问数流程。
前者优点很明显:通用、灵活、冷启动快。只要 schema、字段说明、RAG 做得不错,大模型就能参与 SQL 生成。
但它的问题也很明显:一旦业务口径复杂、字段含义不稳定、多轮追问变多,系统就会在"看起来懂"和"实际答对"之间疯狂打滑。
后者牺牲了一部分自由度,换来的是:更稳、更可控、更容易解释、更容易排查。也更适合围绕某一类高频业务问题持续打磨。
这其实是个很现实的 trade-off。
如果你只是做 Demo,当然希望系统越自由越好。但你真要给业务方用,你会发现他们不需要一个"什么都敢答"的 AI,他们要的是一个在明确范围内能稳定答对的问数入口。
六、我的"小龙虾时刻"
聊了一堆方法论,最后讲一个真正让我细思极恐的小细节。
某次问数过程中,小龙虾像往常一样帮我分析完问题之后,在最后给我加了一句话——大意是:"顺便说一下,我注意到这两张表里好像有几条数据存在异常,要不要我帮你梳理一下?"
我当时愣了三秒。
如果说"AI 自己给自己装了语音识别插件"是 OpenClaw 发明者 Peter 的"OpenClaw 时刻",那这句话就是我的"OpenClaw 时刻"。我的第一反应是:
这玩意儿……不会还能干数据库日常维护和异常筛查吧?
抱着试试的心态,我给小龙虾下了个新指令:"帮我跑一下数据库,看看这两张表里有哪些明显有问题的数据,或者关联关系不一致的,给我列出来。"
结果它在飞书上给我返回了四份云文档:
-
数据核查 - pro_type 非标准值(6 条)
-
数据核查 - 空挂项目(3 条)
-
数据核查 - 分项面积大于总面积(132 条)
-
数据核查 - own_project 与 pro_name 不一致(53 条)
好家伙。
渺小的人类给伟大的 OpenClaw 爷磕一个。
七、规则是死的,业务是活的
聊到这里,顺便提个不容易被注意到的实操点:
实际把 Agent 接到数据库,直连就行,不用搞那么复杂的 Skill 包。但务必从数据库管理层面,给小龙虾分配一个只读账号,从根上掐死它乱改数据的可能。业务术语和领域知识,要么事前跟它聊一聊,要么整理一份文档投喂给它。
最后我想抛一个问题。
现在市面上的业务系统里都有自己的规则引擎。比如不动产系统会设定"闲置 180 天以上自动告警"这种规则。但现实里这套规则常常很尴尬——有些房子下个月就要出租了,这段真空期其实根本不需要告警,业务员不需要每次都跟领导解释一遍,领导也不需要再三追问。
规则是死的,代码是死的,但业务是活的。
过去我们把"灵活"这件事丢给业务员去人肉解释,丢给开发去硬编码兜底。在 Agent 铺开的未来,这些事情,会不会本来就该是 Agent 的活儿?
至少在我负责的那个数据库里,小龙虾已经开始替我干了。
