一个需求，从提报到交付，动不动就等三五天，工单越堆越长。怎么破？
有人说，上 AI 编程。
嗯，AI 写 SQL 确实很快，可对着一大坨几十上百行的 SQL，你敢信吗？人工审一遍？那和手写也差不了太多，该排队还是排队。
那 AI 能自动改错吗？语法错误好解决，数据库会拒绝执行，让 AI 重来几次就行；业务逻辑对不对，就没法识别了。AI 编程通常要靠测试来兜底，这在许多反复运行的场景下问题不大：固定报表、定时任务，…；测试用例做一次，能复用一百次，成本摊薄了。
但这在数据分析工单的场景就不成立了，全是临时需求。问完一次就完了，造测试用例的成本比写代码还高，等于活干了两遍，工单更排不过来了。
让 AI 来生成测试用例呢？那只是把幻觉换了个位置而已，天知道它生成的测试是不是靠谱。

还是要降低审计代码的成本，让 AI+SQLazy 来搞定。SQLazy 是直白易懂的结构化数据计算语言，分步清晰、输出确定、便于审计：

t1=tb_fromto: 主键 id
t2=筛选 ((start_row 非空) 且 (end_row 非空))
t3=扩展 t1 命名 src_id; 拼接列 value 命名 src_value, ffrom 命名 src_ffrom, fto 命名 src_fto
t4=筛选 (src_id >= start_row 且 src_id <= end_row 且 (src_ffrom 等于 ffrom 或 src_fto 等于 ffrom))
t5=汇总 src_value 合计 命名 sumvals; 分组 id

全是秒懂的人话，一步一个动作，每步结果随时可看，对了错了，跑一下就知道。审计成本低到忽略不计。
然后呢？然后编译出 SQL 就完了：

WITH t2 AS (
		SELECT ffrom, fto, value, id, start_row
			, end_row
		FROM (
			SELECT ffrom, fto, value, id, start_row
				, end_row
			FROM tb_fromto
		) t_1
		WHERE (start_row IS NOT NULL
			AND end_row IS NOT NULL)
	),
	t3 AS (
		SELECT t2.ffrom, t2.fto, t2.value, t2.id, t2.start_row
			, t2.end_row, t1.id AS src_id, t1.value AS src_value, t1.ffrom AS src_ffrom, t1.fto AS src_fto
		FROM t2
			CROSS JOIN tb_fromto
	)
SELECT id, SUM(src_value) AS sumvals
FROM (
	SELECT ffrom, fto, value, id, start_row
		, end_row, src_id, src_value, src_ffrom, src_fto
	FROM t3
	WHERE src_id >= start_row
		AND src_id <= end_row
		AND (src_fto = ffrom
			OR src_ffrom = ffrom)
) t_3
GROUP BY id
ORDER BY id 

同样的逻辑，输出永远一样。SQL 由编译器生成，不是 AI 现编的，没有概率，没有幻觉。
临时工单也一样：看得懂、改得动、可审计，不用再造测试用例，也不用推倒重来。工单排队，不该是常态。