先这样答
核心原则一句话：模型输出按不可信输入对待。模型生成的 SQL 和人手敲的 SQL 在风险上没有区别，区别在出错的方式：模型的错误更流畅，一条语法完美、逻辑跑偏的删除语句，比一条直接报错的语句危险得多。所以防线不在「让模型少犯错」，在「就算错了，也执行不出大事」。
防线分四层。第一层静态检查：执行前解析语句，只放行白名单内的类型，比如生产库连接上只准查询、删改类语句一律挡下，代码先过依赖和格式检查。第二层沙箱隔离：代码在容器或独立环境里运行，文件系统、网络、系统调用按需开放，跑崩了也不伤主机。第三层权限最小化：数据库用只读账号，能碰的表限定范围，就算语句失控，影响范围也被账号权限框死。第四层人审分级：低风险自动执行，中风险限制范围和频率，不可逆操作（删除数据、对外发送、花钱）必须人确认。
总结：这套机制和模型强弱无关，换了多强的模型都要有。面试官考察的是有没有「输出即风险」的意识，以及安全做在执行层而不是提示词层。
面试官会怎么追问
- 「每条都人工确认，效率太低怎么办？」 按风险分级而不是一刀切：高频只读查询自动放行，人工确认集中在写操作和不可逆动作。再配灰度执行，先在小范围数据上试跑，多数问题在试跑阶段就暴露。
- 「沙箱里跑还有什么漏网的风险？」 主要在沙箱与外界的边界：网络请求能不能出去、凭据有没有被沙箱内的代码读到。所以凭据要在执行时以临时最小权限的方式注入，不能把长期密钥直接给沙箱。
- 「怎么判断一条生成的 SQL 危不危险？」 静态规则加语义判断：先看语句类型和目标表，再让模型自己复述这条语句会影响哪些数据，两个判断不一致的降级给人审。
回答的坑
- 说「在提示词里写清楚不要执行危险操作」。提示词约束挡不住偶发错误，防线必须落在执行环境：白名单、沙箱、权限、人审。
- 只防 SQL 注入这类传统风险。模型输出的风险面更大：语法合法但意图错误的语句、代码里夹带的外部请求，都要覆盖。
—— 本题完 ——