Text-to-SQL演示只要一天，产品化那90%才是真正的工程挑战

原型真的只需要一个下午。从 information_schema 里拉出表结构，填进提示词，拼接用户的自然语言问题，调用模型，跑返回的 SQL，渲染结果行——现在每种技术栈都有教程，而且都跑得通。"让用户用自然语言问自己的数据"这个需求，从提需求到跑通原型，下班前就能搞定。这就是那 10%。

剩下的 90%，在第一个真实用户开始用之后才出现

原型的任务是生成 SQL。功能的任务是代表用户、无人工干预地，针对生产数据库运行模型生成的 SQL。这是两件不同的事，而它们之间的差距，是一整套教程从未提及的基础设施：

fail-closed 的校验器。模型迟早会写出有问题的操作——CTE 里的 DELETE、注释背后的 DROP、不该被提问者看到的表的 JOIN。你需要一个解析级别的白名单，拒绝除你明确允许的读操作之外的一切，同时拒绝一切无法解析的内容。正则黑名单是那张你还没收到的 bug 报告。

以"问题 + schema 版本"为 key 的执行计划缓存。同一个问题不应该花两次模型调用，所以你要缓存编译后的执行计划——但缓存的计划只在 schema 发生变化之前有效，因此 key 必须带上 schema 指纹，而失效处理就成了你的问题。不做这一步，每次仪表板加载都会让你在 p95 模型延迟下支付全新 token 费用。

基于标注集的评估框架。提示词会被修改，模型会被替换或静默升级，NL→SQL 的准确率会随着两者中任意一个的变化而波动。没有一套打分的"问题→标准答案"集合，回归总是在客户那里暴露出来。搭评估框架是一个项目；随着 schema 演进持续维护标注集，是一份没有终点的苦差事。

以上每一样都不稀奇——每一块都是可以搭的。问题在于，每一块都是需要维护的：那是生产级基础设施，on-call 轮转的工程师名字挂在上面，服务的是一个可能并不是你核心产品的功能。

诚实的自建 vs 购买判断

错误的问题是"我能不能从英文生成 SQL？"能——一个下午就行，这正是 demo 的意义。正确的问题是"我想不想要拥有那整套基础设施？"如果自然语言查询就是你的产品——你在搭 BI 工具、数据平台、或者 Agent 框架——那就自建；校验器和评估框架就是你的护城河。如果这只是报表页签、每个用户在自己数据上的搜索框、应用内的助手——一个更大产品的附带功能——那就买这条管线然后嵌入进去，就像你买认证和邮件服务，而不是自己去跑 SMTP 服务器一样。

（第二种情况正是 nlqdb 存在的意义：只需嵌入一个元素或一个 POST /v1/ask，英文语句针对实时 schema 编译，编译后的 SQL 在任何人信任它之前先展示出来，读操作经过 fail-closed 白名单，校验器/缓存/评估栈由我们维护而不是你。诚实的限制：这是一个你嵌入的托管管线，不是你 vendoring 的库——而且"多个用户各自查自己的数据"仍然意味着每个租户一个数据库或一个隔离范围，因为在一个共享数据库内部做逐用户的行级安全还没有发出来。）

通用教训：demo 定价的是第一个下午；功能定价的是之后的岁月。当一种 AI 能力把 demo 成本压到接近零——text-to-SQL 已经做到了——自建 vs 购买的选择并不会消失。它只是移到了 demo 从未展示给你的那部分架构上。