------为什么要满足业务需求，必须进行定制化开发
随着生成式 AI 的快速发展，"自然语言直接生成 SQL"正在成为一个被频繁提及的话题。
看起来，只要把数据库表结构交给 AI，就能让业务人员用一句话查数据，似乎一切都会变得很简单。
但在真实的业务系统中，这种想法几乎一定会失败。
本文将结合传统业务系统的开发流程，说明一个核心结论：
自然语言 → SQL 并不是一个"即插即用"的 AI 能力，而是一项必须结合业务进行定制化开发的系统工程。
一个常见误解：有表结构，就能生成 SQL？
很多人对 Text-to-SQL 的第一反应是：
- 数据库表已经设计好了
- 表名、字段名都清楚
- 那自然语言生成 SQL 不就是把字段拼起来吗？
这个认知，其实和下面的想法非常类似：
"既然有了表结构，程序员应该就能直接写完业务功能吧？"
而现实中的系统开发，从来不是这样。
回顾一次正常的业务系统开发流程
假设你要让程序员实现一个业务功能，你会只给他表定义文档吗？
几乎不会。
一个正常的业务系统开发，通常至少需要：
- 需求说明 / 业务说明
- 功能列表 & 功能概要
- 功能详细设计说明书
- 画面流程图 / 画面迁移图
- 画面项定义书
- 代码定义书 / 业务规则说明
- 表定义书
- 异常场景与边界条件说明
原因很简单：
业务逻辑从来不写在表定义里。
表定义描述的是"数据结构"，不是"业务含义"
表定义只能说明：
- 有哪些表
- 有哪些字段
- 字段类型是什么
但程序员真正需要实现的是：
- 这个功能用哪张表
- 什么情况下取哪条数据
- 数据是否需要过滤、汇总、分组
- 某些状态是否要排除
- 不同场景下规则是否不同
这些内容，只存在于业务设计文档中。
自然语言 → SQL，本质上是同一件事
现在把视角切回自然语言转 SQL。
用户的一句话需求
"我想看看本月各部门的在职人数"
这句话并不能直接生成 SQL。
因为这里至少存在这些问题：
- "在职"如何定义？
- 使用哪一张部门表？
- 是否包含即将离职人员？
- 统计口径是月初还是月末？
- 是人事模块的数据，还是组织模块的数据？
如果这些规则没有被提前定义，那么：
- AI 每次生成的 SQL 可能都不一样
- 看似"正确"的 SQL，业务上却是错的
Text-to-SQL = 业务模型的实现
因此，自然语言转 SQL 并不是一个"语法问题"，而是：
把自然语言映射到业务功能、业务规则和数据模型上的过程
本质上等同于：
- 先定义业务模型
- 再把这个模型"翻译"为 SQL
这和让程序员写业务代码，并没有本质区别。
为什么一定需要定制化开发？
通用 AI 可以做到的事情是：
- 理解 SQL 语法
- 理解表和字段之间的结构关系
但它无法凭空知道：
- 你们公司里"在职"的准确定义
- 某个功能必须使用哪几张表
- 哪些查询是允许的，哪些是不允许的
- 不同业务模块的查询边界在哪里
因此，要想真正"可用"，必须额外提供：
- 业务术语与字段的映射关系
- 功能级别的查询规则
- 业务口径的统一定义
- 查询模板或约束规则
这些全部都属于 定制化设计与开发工作。
这不是替代开发，而是换一种形式的开发
生成式 AI 并没有让设计消失，而是让设计：
- 从"代码里"
- 转移到了"规则、约束和上下文"中
就像：
你不会只给程序员一份表定义，就要求他实现完整业务系统
同样地：
你也不能只给 AI 一份表结构，就要求它正确理解所有业务查询
总结
自然语言转 SQL 是一项非常有潜力的技术，但它：
- 不是万能功能
- 不是零成本接入
- 更不是"跳过设计"的捷径
它的成功，高度依赖于业务理解、系统设计和定制化开发能力。
在这一点上，AI 并没有改变软件工程的本质，
反而让"业务建模"和"设计质量"变得更加重要。