NL2SQL 并非新概念，它经历了从规则匹配到深度学习的序列到序列模型，再到大模型驱动的三代演进。第三代（GPT-4、Claude 等）带来了质变，能处理复杂 JOIN、嵌套查询，准确率显著提升，但依然面临幻觉、Schema 理解等工程难题。当前行业共识是“先数据、后模型”，小模型（3B-7B）配合微调与执行校验，在工程化落地中性价比更高。

很多人以为 NL2SQL 就是调一个 API，但实际落地准确率常卡在 60% 左右。核心瓶颈不在模型，而在三个工程化难点：Schema 理解（模型看不懂几十张表的关联）、SQL 生成准确性（幻觉问题）、结果校验（生成结果对错无法自动判断）。InfoQ 指出，企业落地需要先建立“AI-ready Data”，把元数据、业务语义做干净，再选小模型微调，而非直接上大模型。

文章主张的“先调研规划再写代码”正是 Spec Coding（规约编程）的核心思路。Vibe Coding 强调“感觉驱动”，让 AI 直接生成并迭代，但大项目容易失控；Spec Coding 要求在写代码前，人与 AI 先达成架构、边界、逻辑的共识文档（Spec），AI 严格按规约执行。百度百科指出，Spec Coding 在 2025 年末至 2026 年初备受关注，被视为将 AI 编程从“玄学”拉回“工程学”的关键路径。

Anthropic 2026 年趋势报告指出，AI 编程正从“工具辅助”转向“人人都是开发者”，但NL2SQL 在企业落地有明确路径：先建立“AI-ready Data”（元数据、业务语义、权限），再选 3B-7B 小模型微调，配合语法约束解码与执行校验。InfoQ 强调，评估维度应从 Exact Match 转向 Execution Accuracy（执行一致性），并建立“Schema 服务 → 计划器 → 安全沙箱 → 纠错回路”的 MVP 系统。

文章推崇让 AI 先做规划再执行，但这引发了一个关键追问：AI 生成的规划文档本身也可能出错（如选错技术栈、遗漏边界条件）。人类开发者如何判断 AI 规划的质量？是否需要在规划环节引入“规划验证”机制？这本质上是一个“谁监督监督者”的问题——如果规划错了，后续所有代码都会错，且比直接写代码更难发现根因。