浏览 AI使用教程
让 AI 写 SQL 时怎样限制范围并先做只读验证
让 AI 写 SQL 时，最危险的不是语法错误，而是语句正确地改错了数据。先用只读查询预览对象、主键和影响行数，再考虑审批执行。
按实际操作顺序推进
每完成一段就检查当前输出，确认结果符合预期后再继续。
删除“重复客户”之前，先证明这些记录真的重复
让 AI 写“删除重复客户”的 SQL，它根据姓名去重并准备执行 DELETE；同名客户实际属于不同公司，影响行数也没有预览。
- 只读预览和影响行数已确认
- 业务主键定义由负责人批准
- 写操作仍处于人工审批之后
动手前，把材料和不能改的部分定下来
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | PostgreSQL customers(customer_id,company_id,email,name)；下方4行假数据，候选键为 company_id 与去首尾空格、小写化的email。共享邮箱是否代表重复必须由业务确认。 |
| 不能越过的边界 | 先只读查询和小样本；写操作必须显式事务、审批与备份；表名和 WHERE 不确定时停止。 |
| 要交付的结果 | 只读预览、影响行数与审批记录 |
AI 写 SQL 注意事项，从“固定目标和范围”开始做
固定目标和范围
写要找或修改的精确对象、时间窗、租户和排除条件，确认主键与唯一约束。
先生成 SELECT
用与计划写操作完全相同的 WHERE 和 JOIN 预览主键、旧值、新值候选和总行数。
检查执行计划与锁
在合适环境评估索引、全表扫描、事务大小和并发影响，避免一次处理未知规模。
准备备份和事务
选择可恢复方式、批次、审计表和回滚 SQL；数据库不支持所需事务语义时重新设计。
批准后执行并复核
由责任人确认目标、影响行数和窗口；执行后重跑核对查询并保存日志。
四行数据足以看出跨公司误删
| customer_id | company_id | name | |
|---|---|---|---|
| 101 | A | [email protected] | 小王 |
| 102 | A | [email protected] | 王先生 |
| 103 | A | 小李 | |
| 201 | B | [email protected] | 另一家公司 |
候选报告应保留业务疑点
| 规范键 | 候选主键 | 暂定处理 | 需确认 |
|---|---|---|---|
| A / [email protected] | 101、102 | 候选重复；不执行删除 | 是否共享邮箱，关联订单如何处理 |
| A / 空 | 103 | 排除自动邮箱去重 | 缺失邮箱另行补充 |
| B / [email protected] | 201 | 独立客户 | 公司边界不可合并 |
这里没有14组、19行或17行的执行结论。数量是这4行教学输入的人工推导，不代表真实库规模。
让 AI 写 SQL 前，先限定只读范围和样例结果
AI适合起草查询与解释执行计划，不应直接操作生产库。
可复制使用
让 AI 写 SQL 前，先限定只读范围和样例结果
我需要一条只读 SQL 来回答指定问题。请先检查数据结构和口径，不能连接或执行数据库操作。 数据库类型/版本【】；脱敏表结构【】；几行脱敏样例【】；目标问题与时间区间【】；允许读取的表和字段【】；预期输出列【】。 先解释连接键、过滤条件、空值和重复行将如何处理。返回单条 SELECT、参数说明、可能的重复放大风险和最多一条用于核对行数的小查询。SQL 中禁止写入/更新/删除/建表语句；如果主键、时间区间或单位不足以定义问题，先问清，不要把猜测塞进查询。
使用范围：AI适合起草查询与解释执行计划，不应直接操作生产库。禁止INSERT、UPDATE、DELETE、DDL和无条件全表扫描；不要接收真实凭证。
完成后的只读预览、影响行数与审批记录
示例产生公司A的[email protected]候选组：101、102。公司B的201不能并入；空邮箱103不参与。只生成候选报告，尚未批准保留哪一行，更未生成或执行删除。
为什么“影响行数符合预期，语义仍可能错”还不能交付
影响行数符合预期，语义仍可能错
- 原因
- 数量正确不代表选中了正确对象
- 怎么改
- 抽查每组业务键和关联表，先在事务中验证约束与回滚