ChatSQL之我见

Mon, 13 Apr 2026 00:00:00 +0000

这两年，AI技术越来越成熟，在很多场景上给不同的岗位提供了大量的生产力。但是作为数据行业从业人员，其中有个场景我想泼一下冷水。比如被讲得很热的ChatSQL。

接个大模型，挂上数据库，做个对话框，让业务一句话取数，仿佛传统 BI 的门槛一下子就要被抹平。

这种想象不是完全没有根据。只要场景足够干净，问题足够标准，今天的模型确实已经能生成一段相当像样的 SQL，甚至把结果也答得像模像样。

但我对 ChatSQL 的判断一直比较克制。不是因为它没用，而是因为它在企业里真正要解决的，从来都不是"写出一条 SQL"这么简单。

一，ChatSQL 最难的不是生成，而是语义

很多人第一反应是：模型还不够强，等下一代就好了。

这个判断的问题在于，它把 ChatSQL 的核心难点理解成了生成能力。

可在企业环境里，模型最先撞墙的地方往往不是不会写 SQL，而是不知道你们公司到底在说什么。

“活跃客户"怎么算？
“新增付费用户"包不包含试用转正？
“业绩下滑"看收入、利润，还是回款？

这些问题本质上都不是自然语言理解问题，而是业务语义问题。模型可以把一句话翻成查询，但它翻不了一家企业内部本来就没有统一好的口径。

所以 ChatSQL 如果一上来就做成"人话转 SQL”，最后大概率不是输在模型，而是输在语义基础太薄。

二，语义层很重要，但它不是银弹

讲到这里，很多团队会自然转向另一个答案：那就建语义层。

这个方向没错，但也很容易被误解。

语义层的价值在于，把常见指标、维度、实体关系和口径规则结构化，让模型不必每次从数据库字段里重新猜业务世界。没有这层东西，系统几乎很难稳定。

但语义层本身不是一个轻巧组件，它更像是一种治理成果的交付形式。

换句话说，语义层不是补丁，而是地基的外化。

如果企业本来就没有统一指标、没有稳定口径、没有明确的责任边界，那语义层也只是把混乱包了一层更漂亮的壳。它让问题显得更工程化，但并不会自动把问题解决。

所以我更愿意把它理解成入场券，而不是终局方案。没有它，很难上线；只有它，也过不了关。

三，Demo 证明不了产品成立

ChatSQL 最容易骗人的地方，就是 Demo 总是很好看。

因为 Demo 里的问题通常都被精心挑过：定义清楚，范围有限，口径提前对齐，数据表也知道该怎么连。这样的条件下，模型表现出色并不奇怪。

但产品成立的标准完全不是这个。

真正的用户问题通常带着模糊、跳跃和上下文缺失。很多人问的不是一个可以直接翻译的问题，而是一个需要先被澄清的问题。

比如：“最近业绩下滑的团队有哪些？”

一个靠谱的分析师听到这句话，第一反应不会是立刻写 SQL，而是先追问。最近是多久，业绩看什么，下滑按什么基线，异常值要不要去掉，外包团队算不算。

也就是说，真实分析过程本来就不是一次翻译，而是一段澄清和收敛的过程。

而大多数 ChatSQL 产品，目前只接住了"生成查询"这一步，却没有接住分析师原本承担的职责：澄清、解释、回退、修正、多轮一致性。

所以 Demo 证明的是模型有翻译能力，不等于产品已经具备交付能力。

四，ChatSQL 最脆弱的地方是信任，不是准确率均值

很多讨论喜欢问：“准确率做到 80% 多，能不能上线？”

这个问题本身问得就有点偏。

如果 ChatSQL 只是给分析师自己做探索，用来找方向、提假设、少写点重复 SQL，那么它不需要像财务系统一样严苛。因为分析师本身有判断力，答偏了也知道怎么纠回来。

但如果它要直接进入经营分析、财务对账、审计追责这种高责任场景，标准就完全不同了。

这些场景里，决定系统能不能活下来的，不是平均准确率，而是关键问题能不能稳定答对，答错了能不能被及时发现，发现之后能不能追溯。

因为用户对这类系统的信任建立得很慢，崩塌得却很快。十次答对未必能让人真正依赖它，但一次关键错误，足以让整个部门彻底弃用。

AI编程的本质不是写代码，而是GSD

Mon, 06 Apr 2026 00:00:00 +0000

很多人谈 AI 编程，谈到最后都会滑向两个方向：要么研究 prompt 话术，要么研究工具排行榜。可真正把项目做下来之后会发现，决定结果的往往不是模型有多强，而是任务有没有被稳定推进。

所以我越来越确信，AI 编程的本质不是写代码，而是 GSD: Get Shit Done。

这不是一句鸡血口号，而是一种工作判断。AI 最擅长的是局部生成，人最不可替代的是定义目标、控制边界、校验结果、决定下一步。谁负责把事情做完，谁就掌握了 AI 编程的核心。

什么是 GSD

GSD 本来就不是 AI 圈专属概念，它说的是一种执行方法：少空转，少沉迷完美方案，尽快把任务拆开、落地、验证、收口。

它在 AI 编程里尤其重要，因为 AI 把“产出代码”这件事变得太便宜了。过去写错一段代码，要付出几十分钟；现在模型可以在错误方向上连续输出三轮，还都看起来像那么回事。于是，真正稀缺的能力不再是“产出更多”，而是“识别什么值得继续推进”。

从这个角度看，AI 时代没有削弱软件工程，反而把它最硬的那一面暴露出来了：任务拆分、上下文管理、验收标准、回滚意识、重构节奏，这些东西一个都没消失。

AI 编程真正的问题

AI 编程当然快，但快不等于高效。它最常见的问题有三个。

低效

表面上，模型替你写了很多代码；实际上，你只是把时间从“自己写”换成了“审它、修它、补上下文”。如果生成规模大于验证能力，效率往往是下降的。

反复试错

很多人以为自己在迭代，实际上只是陷入了“生成一版、修一版、再修一版”的循环。每一轮都像在前进，但系统并没有更接近完成状态，只是在不断清理上一轮制造的噪音。

上下文失真

模型对项目的理解不是稳定存在的，它只是在当前上下文里做局部推断。上下文一长、一脏、一旧，就会开始忘约定、乱覆盖、重复犯错。很多所谓“模型不靠谱”，本质上是上下文早就失控了。

所以 AI 编程的问题，从来不只是模型问题，更是工作流问题。

GSD 的核心原则

拆任务

不要让 AI 一次处理一个模糊的大目标。大任务一旦没有边界，生成结果几乎注定失真。AI 适合吃小而明确的问题，不适合替你发明完整项目。

快速验证

每走一步，都要尽快确认这一步到底有没有真的往前。能不能运行，输出对不对，页面能不能打开，接口是不是污染了别的模块。这些检查越便宜，闭环越短，任务越稳。

循环迭代

AI 编程最好的节奏不是一次性生成大而全，而是持续压缩闭环：

给清晰目标
生成最小结果
立刻验证
根据结果继续下一轮

GSD 的价值，就在于它把“生成”放回“推进”之内，而不是把生成本身误当成进展。

一个够用的标准流程

如果要把 GSD 落到 AI 编程里，我觉得最实用的流程就是五步：

需求

先把目标说清楚。不是“我想做个什么”，而是输入输出是什么、约束是什么、做到什么算完成。没有完成标准，后面的每一轮生成都会发飘。

Prompt

Prompt 的重点不是修辞，而是约束。你至少要说清背景、任务、涉及范围、禁止事项和输出形式。不给边界，模型就会自动脑补。

AI on LeoChu Space