核心定位
Text-to-SQL 是一项专门解决"业务语言→数据库查询"转换难题的技能。它的核心价值在于让不具备SQL编写能力的用户，仅凭自然语言描述就能获得可直接执行的SQL语句。
核心能力
该技能通过三层处理实现精准转换：
1. 模式识别：强制要求用户提供数据库结构（表名、列名、类型），绝不猜测字段，从根本上杜绝幻觉式查询
2. 意图映射：内置丰富的自然语言→SQL子句对照表（如"最近的"→ORDER BY date DESC LIMIT 1，"每个类别的"→GROUP BY）
3. 关系处理：智能识别多表关联场景，自动选择INNER/LEFT JOIN类型，强制使用表别名避免歧义
三种工作模式
- 默认模式：直接输出标准SQL
- 解释模式：逐行注释说明每个子句的作用，适合学习场景
- 替代方案模式：提供2-3种不同实现策略（如子查询vs CTE），帮助用户理解SQL的灵活性
显著优势
| 维度 | 表现 |
|------|------|
| 准确性 | 强制Schema校验，字段100%匹配 |
| 安全性 | 仅生成查询不执行，无数据泄露风险 |
| 教育性 | 附带自然语言翻译，输出即教程 |
| 规范性 | 禁用`SELECT *`，强制列名限定 |
局限性与注意事项
严重依赖Schema完整性：若用户未提供完整表结构，技能会主动中断并请求补充，而非冒险猜测。这在交互流程中可能显得"不够智能"，但恰恰是数据安全的关键设计。
方言差异：虽支持PostgreSQL/MySQL/SQLite语法调整，但复杂函数（如窗口函数、递归CTE）的跨方言转换仍需人工复核。
无法替代DBA：对于查询优化（索引建议、执行计划分析）、复杂业务逻辑（存储过程、触发器）无能为力。
适用人群
- 产品经理/运营：自助提取数据，减少依赖开发排期
- 数据分析师：快速生成查询骨架，再精细化调优
- SQL学习者：通过"说人话→看代码"的对应关系加速理解
- 非技术创始人：早期验证阶段自主探索数据
常规风险
| 风险类型 | 说明 | 缓解措施 |
|----------|------|----------|
| 查询性能风险 | 生成的SQL可能未利用索引导致慢查询 | 生产环境执行前用`EXPLAIN`分析 |
| 逻辑歧义风险 | "活跃用户"等模糊表述可能被字面翻译 | 关键业务术语需与Schema字段名对齐 |
| 注入风险（间接） | 若下游直接拼接用户输入执行 | 严格区分"生成"与"执行"边界，该技能仅负责前者 |