思考 on LeoChu Space

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，那么它不需要像财务系统一样严苛。因为分析师本身有判断力，答偏了也知道怎么纠回来。

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

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

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

模块地狱

Sun, 10 Dec 2023 00:00:00 +0000

个人理解: 有点类似依赖冲突,循环依赖

传递性依赖
遮蔽
版本冲突
复杂的类加载

技术债

Sun, 29 Oct 2023 00:00:00 +0000

关于技术债务的文章，尽管实践中会堆积技术债，但这个概念并不在我们的工作中频繁出现。这篇文章就系统性讲讲技术债，让大家避免知其然，不知其所以然。

一、技术债是什么

技术负债（英语：Technical debt），又译技术债，也称为设计负债（design debt）、代码负债（code debt），是编程及软件工程中的借鉴了财务债务的系统隐喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。

1992 年，沃德 · 坎宁安首次将技术的复杂比作为负债。第一次发布代码，就好比借了一笔钱。只要通过不断重写来偿还债务，小额负债便可以加速开发。但久未偿还债务会引发危险。复用马马虎虎的代码，类似于负债的利息。整个部门有可能因为松散的实现，不完全的面向对象的设计或其他诸如此类的负债而陷入窘境。

二、技术债表现

技术债与其他债务本身一样，是一种透支行为，通过牺牲未来来满足当下的一些需求。也跟其他债务一样，技术债务也有利息，而且随着时间利滚利，会成为埋在项目里的定时炸弹。如果产品长期的可持续的发展，那么技术债的重要性是毋庸置疑的。

技术债务的本质是产品的结构阻碍了进步，表现出来的症状有：无法轻易重构产品以满足市场需求；组件之间的依赖性过多，体系结构不良；缺陷太多，结构不良；难以理解，难以改变。

技术债务的后果有偿还技术债务造成时间浪费，员工满意度降低带来士气低落，因解决遗留代码问题而错过优质项目造成人才流失，产品质量降低造成客户满意度下降，技术债务限制创新能力、扼杀创造性等诸多问题。

技术债不单单是技术债，它就像一个垃圾堆，久而久之不处理，慢慢周围就会产生更多的垃圾，因此产生的 “破窗效应” 更加是会对未来的项目环境造成很大的影响，大家也会逐渐丧失维护环境的信心。所以在讨论技术债的时候不仅仅是讨论技术债本身，技术债对团队追求质量的信心、对大家维护环境整洁的积极性都会造成很大的影响。

MartinFowler 把技术债分为四个象限，如下图所示：

三、技术债产生的原因

●业务压力：为了满足业务的快速要求，在必要的修改并没有完成时就匆匆发布，这些未完成的修改就形成了技术负债。

●缺少过程和理解：业务人员不清楚不理解技术负债的概念，在决策时就不会考虑到其带来的影响。

●模块之间解耦不够：功能没有模块化，软件柔性不够，不足适应业务变化的要求。

●缺少配套的自动化测试：导致鼓励快速而风险很大的 “创可贴” 式的 BUG 修复。

●缺少必要文档：需求和代码都没有必要的支撑性文档或注释。

●缺少协作：组织中的知识共享和业务效率较低，或者初级开发者缺少必要的指导。

●重构延迟：在开发的过程中，某些部分的代码会变得难以控制，这时候就需要进行重构，以适应将来的需求变化。重构越是推迟，这些已有的代码被使用的越多，形成的技术负债就越多，直到重构完成。

●不遵循标准或最佳实践：忽略了已有的业界标准、框架、技术和最佳实践。

●缺少相关技能：开发人员有时候技能缺失，并不知道如何编写优雅的代码。

四、如何 “还债”？

技术债可视化

尽可能公开技术债，一开始就与团队，利益相关方一起权衡利弊，并明确告知影响与解决方案。平等沟通，相互理解。让技术债在业务层面、技术层面可见。

可以在组织资产负债表的财产债中新增两列：短期技术债和长期技术债。还可以用用跟踪开发速率的方式体现技术债对于产品的影响。

不同的债要对症下药

技术债的状态可以分类为偶然技术债、已知技术债和目标技术债。

偿还技术债时应遵循如下原则：

1）确定已知技术债必须还。

2）发现偶然技术债，立即还。

3）每个冲刺确定一定数量的已知技术债作为目标技术债，在当前冲刺中偿还。

4）无需偿还的技术债是行将就木的产品、一次性原型和短命产品。

五、如何避免 “欠债”

与其后期吭哧吭哧还债填坑，不如从一开始就尽量避免欠下技术债务。

避免使用过时的技术

遗留应用程序、过时的技术以及不同的平台和流程可能会使组织陷入沉重的技术债务，迫使其推迟基本的现代化计划。DNS 和流量管理技术提供商 NS1 的联合创始人兼首席执行官 Kris Beevers 说：“技术债务将大量金钱和宝贵的时间浪费在系统和应用程序上，而这些系统和应用程序并不是为现代企业所需的规模和速度而打造的。”

旧资产和老方法也往往充斥着安全漏洞，难以集成和自动化，并且很可能不再更新。 Beevers 指出：“寻找人才来管理基于复杂或过时的代码构建的遗留应用程序也是一个日益严峻的难题。坚持采用过时技术不仅会消耗宝贵的预算，而且还会阻碍公司创新和保持竞争力的能力。”

参考敏捷实践

有越来越多的组织渐渐接受敏捷软件开发，这是将方法交给协作、自行组织的团队和跨职能团队的一系列方法和实践。如果这种方法得到严格应用，敏捷开发使组织可以避免技术债务，其方法是快速且以迭代的方式创建和发布新产品。Dodd 说：“这一过程将新产品和新功能尽快并逐步地交到用户手中。” 随着新版本的交付，各种改进和问题都得到了解决，这使技术债务的积累不太可能产生。

敏捷方法认识到项目在生命周期中从未真正完成过，并且也从来都不是完美的。“同时，敏捷方法专注于…… 针对能力和质量的简化了的开发”，Dodd 说。重要功能往往要频繁地开发，测试并投入生产。敏捷团队可能不会发布软件的 “全面（Big Bang）” 方法，而是每年发布几次重大升级。Dodd 指出：“这可以使产品保持相当平稳的发展，还可以帮助用户避免重大的中断事件。”